Reading view

There are new articles available, click to refresh the page.

Hack The Box: Mirage Machine Walkthrough – Hard Difficulity

By: darknite
Reading Time: 13 minutes

Introduction to Mirage:

In this writeup, we will explore the “Mirage” machine from Hack The Box, categorized as a Hard difficulty challenge. This walkthrough will cover the reconnaissance, exploitation, and privilege escalation steps required to capture the flag.

Objective:

The goal of this walkthrough is to complete the “Mirage” machine from Hack The Box by achieving the following objectives:

User Flag:

We kicked off with NFS, SMB, and Kerberos enumeration, mounted the open MirageReports share, and grabbed two internal PDFs. One revealed the missing hostname nats-svc.mirage.htb. We hijacked DNS with DNSadder.py, funneled all NATS traffic through our proxy, and snatched JetStream auth_logs messages — yielding valid credentials for david.jjackson. After syncing our clock with the DC, we scored a TGT, fired up Evil-WinRM, and landed on the domain controller as david.jjackson to claim the user flag.

Root Flag:

We started with david.jjackson’s ticket, and then kerberoasted nathan.aadam. After cracking his password, we gained his shell and subsequently discovered mark.bbond’s credentials. From there, we also retrieved the Mirage-Service$ managed password. With these pieces, we used Certipy to forge a DC01$ certificate, and as a result, we configured RBCD so mark.bbond could impersonate the domain controller. Once that was in place, we executed DCSync to dump all domain hashes, including Administrator. Finally, we obtained an Admin TGT and used Evil‑WinRM to open a shell as Administrator, which ultimately allowed us to claim the root flag.

Enumerating the Mirage Machine

Reconnaissance:

Nmap Scan:

Begin with a network scan to identify open ports and running services on the target machine.

nmap -sC -sV -oA initial 10.10.11.78 

Nmap Output:

┌─[dark@parrot]─[~/Documents/htb/mirage]
└──╼ $nmap -sC -sV -oA initial 10.10.11.78 
Nmap scan report for 10.10.11.78
Host is up (0.15s latency).
Not shown: 987 closed tcp ports (conn-refused)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-11-20 20:52:31Z)
111/tcp  open  rpcbind       2-4 (RPC #100000)
| rpcinfo: 
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/tcp6  rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  2,3,4        111/udp6  rpcbind
|   100003  2,3         2049/udp   nfs
|   100003  2,3         2049/udp6  nfs
|   100003  2,3,4       2049/tcp   nfs
|   100003  2,3,4       2049/tcp6  nfs
|   100005  1,2,3       2049/tcp   mountd
|   100005  1,2,3       2049/tcp6  mountd
|   100005  1,2,3       2049/udp   mountd
|   100005  1,2,3       2049/udp6  mountd
|   100021  1,2,3,4     2049/tcp   nlockmgr
|   100021  1,2,3,4     2049/tcp6  nlockmgr
|   100021  1,2,3,4     2049/udp   nlockmgr
|   100021  1,2,3,4     2049/udp6  nlockmgr
|   100024  1           2049/tcp   status
|   100024  1           2049/tcp6  status
|   100024  1           2049/udp   status
|_  100024  1           2049/udp6  status
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: mirage.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: mirage.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
|_ssl-date: TLS randomness does not represent time
2049/tcp open  nlockmgr      1-4 (RPC #100021)
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: mirage.htb0., Site: Default-First-Site-Name)
|_ssl-date: TLS randomness does not represent time
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: mirage.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.mirage.htb, DNS:mirage.htb, DNS:MIRAGE
| Not valid before: 2025-07-04T19:58:41
|_Not valid after:  2105-07-04T19:58:41
|_ssl-date: TLS randomness does not represent time
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: -22m05s
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
| smb2-time: 
|   date: 2025-11-20T20:53:32
|_  start_date: N/A

Analysis:

  • Port 53 (DNS) – Provides internal domain resolution. Useful for discovering hostnames and performing zone transfers if misconfigured.
  • • Port 88 (Kerberos) – Active Directory authentication endpoint. Key for attacks like Kerberoasting or AS‑REP roasting.
  • • Ports 111 & 2049 (NFS) – NFS running on a Windows DC is unusual. Could allow unauthenticated mounts or expose readable files.
  • • Ports 135 / 139 / 445 (MSRPC / SMB) – Standard Windows services. SMB signing is enforced, which prevents NTLM relay attacks.
  • • Ports 389 / 636 / 3268 / 3269 (LDAP / Global Catalog) – Full AD environment. LDAP enumeration is possible if permissions are misconfigured.
  • • Port 464 (kpasswd) – Kerberos password change service. Can provide insights for password‑spray attempts.
  • • Port 593 (RPC over HTTP) – RPC over HTTP interface. Typically used for Outlook Anywhere or AD RPC proxying.

Server Enumeration:

Perform web enumeration to discover potentially exploitable directories and files.

We scanned SMB and saw the service up, but mirage.htb blocked all NTLM logins (even dark:dark failed with STATUS_NOT_SUPPORTED). Kerberos only from now on.

We added the domain/realm to /etc/krb5.conf and used -k flags everywhere — no more passwords over the wire.

NFS Share Enumeration and Mounting Process on Mirage machine

The showmount -e mirage.htb command reveals that the target is exporting an NFS share named /MirageReports, and it is accessible to everyone. This means the share does not enforce host-based restrictions, allowing any machine to mount it. Since the export is world-accessible, it’s likely a good entry point for enumeration, as you can mount the share locally and inspect its contents for sensitive files, misconfigurations, or clues leading to further access.

The mount attempt failed because the local path /mnt/mirage doesn’t exist on our machine. NFS requires a valid directory to mount a remote share, so before accessing the exported /MirageReports share, we need to create a local mount point.

Creating the directory with mkdir -p /mnt/mirage resolves the issue, allowing us to mount the share and begin enumerating its contents.

The “failed to apply fstab options” error usually comes from stale mount settings or syntax issues. Just rerun the command cleanly or add -o vers=3,nolock – it fixes the problem in HTB.

We corrected the syntax (added -o vers=3,nolock when needed) and re-ran mount -t nfs mirage.htb:/MirageReports /mnt/mirage. The share mounted perfectly and gave us full access to the internal reports.

After mounting the NFS share, ls reveals two PDFs: Incident_Report_Missing_DNS_Record_nats-svc.pdf and Mirage_Authentication_Hardening_Report.pdf. These internal reports likely expose misconfigurations and are key for further enumeration.

This command copies all files from the mounted NFS share at /mnt/mirage into your current working directory using elevated privileges. It allows you to analyze the documents locally without needing to stay connected to the NFS share.

Discovery and Analysis of Internal Reports

After copying, the files should now be available in your current working directory for further analysis.

Reviewing the Incident_Report_Missing_DNS_Record_nats-svc.pdf file revealed an additional hostname: nats-svc.mirage.htb.

Exploiting Missing DNS Entry for NATS Interception on Mirage Machine

The Incident Report showed nats-svc.mirage.htb missing from DNS → internal clients failed to resolve it. We fired up DNSadder.py, added a fake record to our proxy, and hijacked all NATS traffic → full MITM on auth and JetStream (including auth_logs).

Enumerating and Interacting With NATS JetStream

NATS is a messaging system that helps different parts of a company’s software talk to each other. Instead of applications connecting directly, they send messages through NATS, which delivers them quickly and reliably.

To install the NATS command‑line interface on Parrot OS, you can use the Go toolchain included in the system. Simply run the command go install github.com/nats-io/natscli/nats@latest, which downloads and compiles the latest version of the NATS CLI and places it in your Go binaries directory for use.

To verify that the NATS CLI installed correctly, simply run the nats command in your terminal. If the installation was successful, it should display the available subcommands and usage information, confirming that the tool is ready to use.

Checking the auth_logs Stream

nats stream info auth_logs showed a small stream (max 100 messages) on subject logs.auth that currently held 5 messages — perfect for grabbing credentials.

Creating a Pull Consumer

We created a pull consumer named whare1 on the auth_logs stream using Dev_Account_A credentials. It fetches messages one-by-one with explicit acknowledgment, allowing us to retrieve all five stored authentication logs.

Grabbing the Credentials

We fetched the five messages from the auth_logs stream using our whare1 consumer. Every message (subject logs.auth) contained the same authentication event:

  • Username: david.jjackson
  • Password: pN8kQmn6b86!1234@
  • Source IP: 10.10.10.20

All messages were acknowledged and consumed successfully, confirming we now have valid domain credentials.

Extracting Credentials and Kerberos Ticket Operations

The leaked david.jjackson:pN8kQmn6b86!1234@ credentials let us request a Kerberos TGT with impacket-getTGT. The first try failed due to clock skew; after sudo ntpdate -s 10.10.11.78, the second attempt succeeded and saved david.jjackson.ccache

Initial Foothold – david.jjackson Access on Mirage Machine

After syncing time with sudo ntpdate -s 10.10.11.78, the second impacket-getTGT run succeeded and gave us a valid TGT.

This command sets the KRB5CCNAME environment variable to use the david.jjackson.ccache file as the active Kerberos ticket. It tells all Kerberos‑aware tools to use this ticket automatically for authentication instead of a password.

Try running the command again if it doesn’t work on the first attempt.

Lateral Movement Using Cracked SPN Credentials

With david.jjackson’s ticket, we ran impacket-GetUserSPNs -k -no-pass and discovered a crackable Kerberos service ticket ($krb5tgs$23$) for the SPN HTTP/exchange.mirage.htb, belonging to the high-privileged user nathan.aadam (member of Exchange_Admins group).

Cracking the TGS → Password: 3edc#EDC3

We cracked the TGS hash using John and the RockYou wordlist, recovering the password 3edc#EDC3 for nathan.aadam — a weak credential that immediately granted us access to this Exchange Admins group member.

BloodHound Collection and Domain Enumeration on Mirage machine

As nathan.aadam, we ran BloodHound and dumped the entire Active Directory structure for privilege escalation path hunting.

Mark.bbond is a member of the IT Support group, and he has the ForceChangePassword privilege over the user javier.mmarshall.

Javier.mmarshall has ReadGMSAPassword permission on the account Mirage-Service$.

nxc smb dc01.mirage.htb with nathan.aadam initially failed due to clock skew (krb_ap_err_skew). After syncing time again (ntpdate -s 10.10.11.78), authentication succeeded cleanly.

Same clock skew issue hit nxc smb. After ntpdate -s 10.10.11.78, it worked instantly and confirmed valid access as nathan.aadam : 3edc#EDC3 on the DC.

We used the cracked password 3edc#EDC3 to obtain a Kerberos TGT for nathan.aadam (impacket-getTGT). The ticket was saved as nathan.aadam.ccache, giving us full Kerberos access for the next steps

Accessing the DC as nathan.aadam

Connected instantly as nathan.aadam → full PowerShell access on the Domain Controller.

Grabbing the User Flag

We can read the user flag by typing the “type user.txt” command

Escalate to Root Privileges Access on Mirage Machine

Privilege Escalation Attempts and LogonHours Analysis

A screen shot of a computer

AI-generated content may be incorrect.

We checked AD LogonHours. javier.mmarshall had all zeroes → account completely locked out (can’t log in anytime). This hinted the account was disabled but still present for potential abuse.

A screen shot of a computer

AI-generated content may be incorrect.

No default password was detected.

You can transfer the WinPEAS executable to the compromised host by running the upload command inside your Evil‑WinRM session. This pushes the file from your attack machine directly into the victim’s system, allowing you to execute it afterwards for privilege‑escalation enumeration.

No usable credentials were identified.

This command verifies SMB access on dc01.mirage.htb using Kerberos authentication with the mark.bbond credentials. The scan shows the host details and confirms a successful login, indicating that the provided password is valid and SMB authentication for this account works correctly.

The command requests a Kerberos TGT for the user MARK.BBOND using the discovered password 1day@atime. By specifying the domain controller IP, the tool authenticates against the DC and generates a valid ticket. Once successful, the resulting Kerberos ticket is saved locally as MARK.BBOND.ccache for use in later Kerberos‑based operations.

Password Resets, Kerberos Tickets, and Service Account Abuse

A password reset for the account javier.mmarshall was performed using bloodyAD. By authenticating as mark.bbond with Kerberos (-k) and supplying valid domain credentials, the command successfully updated the user’s password to p@ssw0rd123, confirming the operation completed without issues.

Attempting to obtain a TGT for the account javier.mmarshall with impacket-getTGT results in a KDC_ERR_CLIENT_REVOKED error. This indicates the credentials are no longer valid because the account has been disabled or otherwise revoked in Active Directory, preventing any Kerberos authentication from succeeding.

Enabling javier.mmarshall (disabled account)

By running the command shown above, the password update completed successfully.

A screenshot of a computer screen

AI-generated content may be incorrect.

As mark.bbond, we used BloodyAD to read the msDS-ManagedPassword attribute of the Mirage-Service$ managed service account and instantly retrieved its current plaintext password + NTLM hash.

We used Impacket to request a Kerberos TGT for Mirage-Service$ with its leaked NTLM hash (pass-the-hash). This gave us a valid ticket without ever needing the plaintext password.

We asked the domain CA for a certificate using mark.bbond (now pretending to be dc01$). The CA accepted it and gave us a shiny dc01.pfx file that lets us log in as the real domain controller machine account.

After exporting the Kerberos ticket with export KRB5CCNAME=mark.bbond.ccache, a certificate request is made using Certipy


We requested a certificate for mark.bbond (UPN = dc01$@mirage.htb). The CA issued it without issues → dc01.pfx ready for authentication as the DC machine account.

We cleaned up by resetting mark.bbond’s UPN back to mark.bbond@mirage.htb with Certipy – leaving no obvious traces.

Certificate Abuse and Resource-Based Constrained Delegation (RBCD)

With the dc01.pfx certificate, Certipy authenticated us over LDAPS as MIRAGE\DC01$ – we now had full LDAP control as the domain controller itself.

We used Certipy to grant mark.bbond Resource-Based Constrained Delegation over DC01$ – now mark.bbond can impersonate anyone (including Administrator) to the domain controller.

As mark.bbond, we ran impacket-getST to impersonate DC01$ and request a CIFS ticket for the real DC. Delegation succeeded → valid ticket saved.

The Kerberos ticket was set as the active credential cache by exporting it to the KRB5CCNAME environment variable:

export KRB5CCNAME=DC01$@<a>CIFS_dc01.mirage.htb@MIRAGE.HTB.ccache</a>

With the delegated CIFS ticket, we executed impacket-secretdump -k dc01.mirage.htb and successfully dumped the entire NTDS.DIT — every user and machine hash, including Administrator’s, was now ours.

The impacket-getTGT command was executed using the Administrator NTLM hash to request a Kerberos TGT from the Mirage domain controller. The request completed successfully, and the resulting ticket was saved locally as Administrator.ccache.

The evil-winrm command was used to connect to dc01.mirage.htb with Kerberos authentication. Evil‑WinRM initialized successfully, displaying standard warnings about Ruby’s path‑completion limitations and noting that the provided username is unnecessary when a Kerberos ticket is already available. The session then proceeded to establish a connection with the remote host.

We can read the root flag by typing the “type root.txt” command

The post Hack The Box: Mirage Machine Walkthrough – Hard Difficulity appeared first on Threatninja.net.

Hack The Box: Scepter Machine Walkthrough – Hard Difficulty

By: darknite
Reading Time: 13 minutes

Introduction to Scepter

This write-up covers the “Scepter” machine from Hack the Box, a hard difficulty challenge. It details the reconnaissance, exploitation, and privilege escalation steps to capture the user and root flags.

Objective on Scepter

The goal is to complete the “Scepter” machine by achieving these objectives:

User Flag: The attacker cracked weak .pfx certificate passwords using pfx2john and rockyou.txt, Discovering that all shared the same password. After fixing time skew, they extracted d.baker’s NTLM hash via certipy. BloodHound revealed d.baker could reset a.carter’s password due to group privileges over the OU. By exploiting ESC9 and modifying the mail attribute, the attacker generated a spoofed certificate, authenticated as a.carter, and accessed the system to capture the user flag.

Root Flag: The attacker discovered that h.brown could modify p.adams’ certificate mapping, leading to an ESC14 vulnerability. By forging a certificate and binding it to p.adams using altSecurityIdentities, they authenticated as p.adams with Certipy. Since p.adams had DCSync rights, the attacker used secretsdump to extract domain hashes, then pivoted to the Administrator account via evil-winrm, Securing the root flag.

Enumerating the Scepter Machine

Establishing Connectivity

I connected to the Hack The Box environment via OpenVPN using my credentials, running all commands from a Kali Linux virtual machine. The target IP address for the Scepter machine was 10.10.11.65.

Reconnaissance:

Nmap Scan:

We scan the target at IP 10.10.11.65 to identify open ports:

nmap  -sC -sV 10.10.11.65 -oA initial 

Nmap Output:

Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-07-17 19:06 EDT
Nmap scan report for 10.10.11.65
Host is up (0.18s latency).
Not shown: 987 closed tcp ports (conn-refused)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-07-17 23:13:45Z)
111/tcp  open  rpcbind       2-4 (RPC #100000)
| rpcinfo: 
|   program version    port/proto  service
|   100000  2,3,4        111/tcp   rpcbind
|   100000  2,3,4        111/tcp6  rpcbind
|   100000  2,3,4        111/udp   rpcbind
|   100000  2,3,4        111/udp6  rpcbind
|   100003  2,3         2049/udp   nfs
|   100003  2,3         2049/udp6  nfs
|   100003  2,3,4       2049/tcp   nfs
|   100003  2,3,4       2049/tcp6  nfs
|   100005  1,2,3       2049/tcp   mountd
|   100005  1,2,3       2049/tcp6  mountd
|   100005  1,2,3       2049/udp   mountd
|_  100005  1,2,3       2049/udp6  mountd
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: scepter.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-07-17T23:14:50+00:00; +6m52s from scanner time.
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after:  2025-11-01T03:22:33
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: scepter.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-07-17T23:14:49+00:00; +6m51s from scanner time.
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after:  2025-11-01T03:22:33
2049/tcp open  mountd        1-3 (RPC #100005)
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: scepter.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-07-17T23:14:50+00:00; +6m52s from scanner time.
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after:  2025-11-01T03:22:33
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: scepter.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2025-07-17T23:14:49+00:00; +6m51s from scanner time.
| ssl-cert: Subject: commonName=dc01.scepter.htb
| Subject Alternative Name: othername: 1.3.6.1.4.1.311.25.1::<unsupported>, DNS:dc01.scepter.htb
| Not valid before: 2024-11-01T03:22:33
|_Not valid after:  2025-11-01T03:22:33
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: mean: 6m51s, deviation: 0s, median: 6m50s
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
| smb2-time: 
|   date: 2025-07-17T23:14:44
|_  start_date: N/A

Analysis:

  • 53/tcp (DNS): Simple DNS Plus running; possible subdomain enumeration or zone transfer.
  • 88/tcp (Kerberos): Kerberos service available; potential for AS-REP roasting or ticket attacks.
  • 111/tcp (rpcbind): RPC services exposed; confirms NFS and mountd usage on 2049.
  • 135/tcp (MSRPC): Windows RPC service; common on domain controllers, used for DCOM and remote management.
  • 139/tcp (NetBIOS-SSN): NetBIOS session service; legacy Windows file/printer sharing.
  • 389/tcp (LDAP): LDAP exposed; reveals domain scepter.htb, possible LDAP enumeration.
  • 445/tcp (SMB): SMB service running; check for shares, null sessions, and vulnerabilities.
  • 464/tcp (kpasswd5): Kerberos password service; often used with password change requests.
  • 593/tcp (RPC over HTTP): RPC over HTTP (ncacn_http); used in Outlook and domain services.
  • 636/tcp (LDAPS): Secure LDAP; same domain as port 389, check for SSL issues or AD leaks.
  • 2049/tcp (NFS): NFS file sharing active; can allow unauthenticated file access or mounting.
  • 3268/tcp (GC LDAP): Global Catalog LDAP service; useful for domain-wide user enumeration.
  • 3269/tcp (GC LDAPS): Secure Global Catalog LDAP; encrypted version of port 3268.

NFS Enumeration on Scepter Machine

To check for NFS shares, I used:

showmount -e 10.10.11.65

Output:

The command showed a /helpdesk share. I mounted it locally:

I create a local folder nfs with mkdir nfs to serve as a mount point. Then, using sudo mount -t nfs 10.10.11.65:/helpdesk nfs -o nolock, you connect the remote /helpdesk share to that folder, making it accessible locally. The -o nolock option prevents locking issues. Finally, sudo ls nfs lists the shared files—like accessing a USB drive, but over the network.

When I tried cd nfs/ with sudo, it failed since cd is a shell built-in. I resolved it by switching to root:

Handling NFS Access

I resolved it by switching to root.

Inside, I found several files:

  • scott.pfx
  • baker.crt
  • baker.key
  • clark.pfx
  • lewis.pfx

I copied them to a higher directory

Certificate Analysis

baker.crt

I viewed baker.crt

It belonged to d.baker@scepter.htb, issued by scepter-DC01-CA.

baker.key

The corresponding baker.key was encrypted and required a password.

clark.pfx

Viewing .pfx files like clark.pfx showed unreadable binary output. These files are password-protected containers.

OpenSSL and Certificate Recreation

I used OpenSSL to inspect two password-protected .pfx files. Without the correct passwords, access is denied due to strong SHA256 encryption. Cracking these passwords is essential to unlock their contents and advance in the challenge

Cracking PFX Passwords

I used pfx2john.py to extract the hash

Although I’m using Hashcat to crack scott.pfx’s password from scott.hash, I encounter an error because the hash format isn’t recognised. Fix it by specifying the correct mode (-m 13100) or verifying the hash file. This step is crucial to unlock the certificate and gain access.

Password Cracking with John the Ripper

Then, I cracked it using John and the password newpassword worked for scott.hash but I already tested on all *.pfx file and success.

OpenSSL, Certipy, and BloodHound Exploitation Techniques

I re-created baker.pfx and I used newpassword as the export password.

AD CS Exploitation

Certipy Authentication

Another approach was to re-create the baker.pfx file; this was necessary because the original one was either invalid or unusable.

I authenticated to the domain using the baker.pfx file, and this failed initially due to clock skew.

I fixed the time with the command ntpdate -s 10.10.11.65

After syncing, authentication succeeded. I obtained an NTLM hash and a Kerberos .ccache file.

Bloodhound enumeration on Scepter machine

I ran BloodHound with NTLM hash

BloodHound CE GUI Analysis for Privilege Escalation on Scepter Machine

This represents a relationship in BloodHound where the user d.baker@scepter.htb has the ability to force a password change for the user a.carrter@scepter.htb. This is a powerful privilege escalation path because it can potentially allow d.baker to take over a.carrter‘s account by resetting their password.

A.CARTER is a member of the IT SUPPORTSTAFF ACCESS CERTIFICATE group. This group has the modification rights over a specific Organizational Unit (OU).



A.CARTER, as a member of the IT SUPPORTSTAFF ACCESS CERTIFICATE group, not only has modification rights over the OU containing D.BAKER but also can directly manipulate D.BAKER’s mail attribute. As a result, this access consequently opens the door to abusing ESC9 (Active Directory Certificate Services escalation). Furthermore, this vulnerability creates a significant privilege escalation risk that attackers can exploit.

H.BROWN belongs to both the Remote Management Users group and the Protected Users group. As a result, H.BROWN enjoys permissions for remote management tasks, such as accessing servers. However, the Protected Users group imposes strict security restrictions. Consequently, these limitations may block certain authentication methods, like NTLM, or hinder lateral movement within the scepter.htb domain. Therefore, exploiting H.BROWN’s account requires bypassing these constraints, for example, by leveraging certificate-based attacks to achieve privilege escalation in the Scepter machine.

H.BROWN has write permissions over critical attributes, enabling DCSync operations to extract sensitive data, such as password hashes. As a result, they can target P.ADAMS by manipulating the altSecurityIdentities attribute. For instance, updating this attribute with a crafted certificate allows H.BROWN to authenticate as P.ADAMS without a password. Therefore, exploiting altSecurityIdentities is a key step in achieving full domain control in the Scepter machine.

Analysis of Certificate Templates

By using Certipy’s find command, I enumerated certificate templates in AD CS, specifically targeting misconfigurations like ESC1, ESC2, or ESC8 vulnerabilities. For example, these flaws allow attackers to request high-privilege certificates, enabling unauthorized access. Consequently, identifying such issues is critical for exploiting AD CS weaknesses. Additionally, this step facilitates privilege escalation by revealing templates with excessive permissions. Thus, Certipy’s enumeration plays a pivotal role in achieving domain compromise in the Scepter machine.

ESC9: ADCS Privilege Escalation

Exploit Overview:

ESC9 in Active Directory Certificate Services (ADCS) allows attackers to abuse misconfigured certificate templates for privilege escalation. If a template permits users to specify Subject Alternative Names (SANs) (e.g., UPNs) and the CA honours them without restrictions, a low-privileged user can request a certificate impersonating a high-privileged account (like a Domain Admin).

Source: ADCS ESC9 – No Security Extension

Troubleshooting BloodyAD Issues

We need to update the password using the command provided, but unfortunately, the password does not meet the required complexity rules.

The password was successfully changed after meeting the complexity requirements.

The “Invalid Credentials” error (LDAP error code 49) during an LDAP bind typically indicates a failure to authenticate due to incorrect credentials or configuration issues.

System Configuration Assessment

If the UserAccountControl attribute includes the DONT_EXPIRE_PASSWORD flag (value 65536 or 0x10000), the user’s password never expires. Consequently, this setting can disrupt LDAP authentication or password-related operations. For example, systems expecting periodic password changes or strict complexity rules may reject the account’s state. As a result, this could cause the “InvalidCredentials” error (LDAP error code 49) during an LDAP bind in the Scepter machine. Therefore, verifying the account’s configuration and server expectations is crucial for resolving authentication issues.

The screenshot provided displays the output of the ldapsearch command.

Running the bloodyAD command with sudo privileges resolved the issue, and it now functions perfectly.

Certificate Abuse for scepter machine

I used an existing template to request a certificate for h.brown. This gave me h.brown.pfx.

After exploiting AD CS vulnerabilities, the system provided H.BROWN’s NTLM hash and a h.brown.ccache file. Specifically, the .ccache file serves as a temporary access pass, enabling impersonation of H.BROWN across the network without re-entering credentials. For example, this allows discreet movement within the scepter.htb domain. Consequently, it facilitates information gathering, such as enumerating shares or services, for further exploitation. Thus, these credentials are critical for advancing privilege escalation in the Scepter machine.

After obtaining H.BROWN’s Kerberos ticket in the h.brown.ccache file, configure your system to use it. Then, connect to a Windows server, such as dc01.scepter.htb, bypassing password authentication. For instance, if the ticket is valid and the server accepts it, you’ll gain remote access as H.BROWN.

We retrieved the user flag by executing the type user.txt command.

Escalate to Root Privileges Access on Scepter Machine

Privileges Access

H.BROWN’s Permissions

Using H.BROWN’s Kerberos ticket (h.brown.ccache), the command bloodyAD -d scepter.htb -u h.brown -k –host dc01.scepter.htb –dc-ip 10.10.11.65 get object h.brown –detail queries the domain controller. Specifically, it reveals permissions, such as modifying users or groups. For example, the –detail flag provides precise control rights, including write access to P.ADAMS’s altSecurityIdentities. Consequently, this output identifies privilege escalation paths, like DCSync or certificate-based attacks. Thus, querying permissions is a key step in the Scepter machine’s AD exploitation.

altSecurityIdentities Manipulation

You discovered that h.brown has write permissions on the altSecurityIdentities attribute of the user p.adams in Active Directory, as indicated by:

distinguishedName: CN=p.adams,OU=Helpdesk Enrollment Certificate,DC=scepter,DC=htb
altSecurityIdentities: WRITE

This means h.brown can hijack p.adams’s identity by modifying their certificate mapping. With this, h.brown can request a certificate and authenticate as p.adams—no password needed. Moreover, if p.adams is highly privileged (e.g., Domain Admin), h.brown can launch a DCSync attack to dump domain password hashes. Consequently, this single write permission can lead to a complete domain compromise.

Abusing altSecurityIdentities and Certificate-Based Attacks in Active Directory

After using OpenSSL to extract the certificate from d.baker.pfx, the serial number shows up in its usual big-endian format, which is just the standard way it’s displayed.

Exploit ESC14 with User-to-User Certificate-Based Attack

62:00:00:00:05:2a:87:15:0c:cc:01:d1:07:00:00:00:00:00:05

After extracting the certificate serial number from d.baker.pfx using OpenSSL, it appears in big-endian format (e.g., 62:00:00:00:05:2a:87:15:0c:cc:01:d1:07:00:00:00:00:00:05). However, tools like Certipy and BloodyAD require little-endian format for certificate forgery. Therefore, reversing the byte order is crucial for accurate interpretation. For instance, this conversion ensures successful altSecurityIdentities manipulation in commands like bloodyAD set object p.adams altSecurityIdentities.

The command can be used as follows:

bloodyAD -d "scepter.htb" -u "h.brown" -k --host "dc01.scepter.htb" --dc-ip "10.10.11.65" set object "p.adams" altSecurityIdentities -v "X509:<RFC822>p.adams@scepter.htb"

By updating altSecurityIdentities, you link your certificate to p.adams’s account, letting you log in as them without a password. This is a key move in abusing certificate-based authentication in AD.

The command can be used as follows:

bloodyAD -d "scepter.htb" -u "a.carter" -p 'Password' --host "dc01.scepter.htb" set object "d.baker" mail -v "p.adams@scepter.htb"

This type of change can be used to manipulate identity mappings, paving the way for attacks like spoofing or malicious certificate requests.

Root Access via Pass-the-Hash

This Certipy command uses Kerberos to request a StaffAccessCertificate for p.adams from dc01.scepter.htb. If granted, it saves the cert as p.adams, letting you authenticate and act as p.adams within the domain.

This Certipy command uses the padams.pfx certificate to authenticate as p.adams to the AD domain at 10.10.11.65, enabling password-free access and resource control via certificate-based login.

This command uses p.adams’s NTLM hash to authenticate to the domain controller dc01.scepter.htb and extract the administrator’s password hashes. It targets only the admin account (RID 500), retrieving the LM hash (usually empty) and the NTLM hash—the latter can be used for pass-the-hash attacks to gain full admin access. This lets an attacker escalate privileges and take control of the domain controller.

After obtaining the Administrator’s NTLM hash via a DCSync attack, use Evil-WinRM to connect to the Windows machine at 10.10.11.65. Specifically, the command evil-winrm -i 10.10.11.65 -u Administrator -H authenticates via Pass-the-Hash, bypassing password requirements. If successful, it establishes a remote PowerShell session with full admin rights. Consequently, this access allows command execution, such as type root.txt, to retrieve the root flag. Thus, Evil-WinRM is critical for achieving domain control in the Scepter machine.

We retrieved the root flag by executing the type root.txt command.

The post Hack The Box: Scepter Machine Walkthrough – Hard Difficulty appeared first on Threatninja.net.

❌