LoginHack The Box: Scepter Machine Walkthrough – Hard Difficulty
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:332049/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/AAnalysis:
- 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.65Output:
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.pfxbaker.crtbaker.keyclark.pfxlewis.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: WRITEThis 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:05After 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.
