Active Directory Security Audit: Angriffspfade in AD finden und schließen

“Wir wurden kompromittiert - der Angreifer hatte Domain Admin.” Dieser Satz steht am Ende der meisten Windows-Netzwerk-Kompromittierungen. Active Directory ist nicht nur das Herzstück der Windows-Infrastruktur - es ist das primäre Angriffsziel. Ein Angreifer der Domain Admin erlangt, kontrolliert alle Systeme, alle Passwörter, alle Daten im gesamten Windows-Umfeld.

Warum AD das bevorzugte Angriffsziel ist

Domain Admin ist der Generalschlüssel: Wer ihn besitzt, kann alle Windows-Systeme im Domain administrieren, alle Hashes aus der NTDS.DIT extrahieren (DCSync), Kerberos-Tickets für beliebige Accounts erstellen (Golden Ticket) und Trusts zu anderen Domains ausnutzen (Forest-Compromise).

Die Zahlen sprechen eine deutliche Sprache: 80 % aller Incidents hatten Active Directory als Einstiegspunkt oder als Weg zu Domain Admin. Die durchschnittliche Zeit von der initialen Kompromittierung bis zur Erlangung von Domain Admin beträgt laut CrowdStrike gerade einmal 1,5 Stunden. Die häufigsten Angriffsvektoren sind Kerberoasting (60 %), LLMNR Poisoning (50 %) und AS-REP Roasting (30 %).

Der typische AD-Angriff-Lifecycle folgt einem klaren Muster:

1. Initial Access (Phishing, Exploit)
2. Local Privilege Escalation (lokaler Admin)
3. Credential Harvesting (Mimikatz, LSASS)
4. Lateral Movement (Pass-the-Hash, Pass-the-Ticket)
5. Domain Privilege Escalation (Kerberoasting, AS-REP, DCSync)
6. Persistence (Golden Ticket, DCSync-Backdoor, Skeleton Key)

Phase 1: Audit-Vorbereitung und Scoping

Ein AD-Audit deckt folgende Kernobjekte ab:

• Domain-Struktur: Anzahl Domains, Trusts, Functional Level
• Privilegierte Accounts: Domain Admins, Enterprise Admins, Schema Admins, Account Operators
• Kerberos-Konfiguration: Verschlüsselungstypen, Delegation
• Password Policies: Länge, Komplexität, History, Lockout
• GPOs: Kritische GPO-Konfigurationen
• LDAP-Konfiguration: LDAP Signing, LDAP Channel Binding
• Service Accounts: SPNs, Passwort-Alter, Berechtigungen
• Inactive Accounts: Benutzer/Computer inaktiv > 90 Tage
• Local Admin Accounts: LAPS implementiert?

Für das Audit stehen folgende Tools zur Verfügung:

Tool	Zweck	Kosten
BloodHound + SharpHound	Angriffspfad-Visualisierung	kostenlos
PingCastle	AD Healthcheck Score	kostenlos
Semperis Purple Knight	Free AD Assessment Tool	kostenlos
Microsoft Defender for Identity	Erkennung AD-Angriffe in Echtzeit	lizenzpflichtig
ADACLScanner	ACL-Analyse für alle AD-Objekte	kostenlos
PowerView (PowerSploit)	AD-Enumeration (für Tester)	kostenlos

Für ein Schnell-Assessment bietet sich PingCastle an: Nach dem Download von pingcastle.com erzeugt pingcastle.exe --healthcheck --server dc01.firma.de einen HTML-Report mit einem Score von 0 bis 100 (100 = bestes Ergebnis) und priorisierten Findings in den Kategorien Privileged Accounts, Trusts und Account Anomalies.

Phase 2: Privilegierte Accounts analysieren

Der folgende PowerShell-Befehl listet alle Domain Admins mit ihren relevanten Attributen auf:

Get-ADGroupMember "Domain Admins" -Recursive |
  Get-ADUser -Properties LastLogonDate, PasswordLastSet, Enabled |
  Select-Object Name, SamAccountName, LastLogonDate,
                PasswordLastSet, Enabled |
  Sort-Object LastLogonDate

Bei der Analyse sind folgende Findings kritisch:

• Mehr als 5 Mitglieder in der Domain Admins-Gruppe (Best Practice: max. 2-3 echte DA-Accounts)
• DA-Accounts mit Passwörtern älter als 90 Tage
• DA-Accounts ohne LastLogonDate (nie genutzt, aber aktiv)
• DA-Accounts die als Mailbox-Accounts genutzt werden (Spear-Phishing-Risiko)
• DA-Accounts die täglich für normale Arbeit verwendet werden

Enterprise Admins und Schema Admins sollten grundsätzlich leer sein. Enterprise Admins werden nur bei Forest-Änderungen temporär befüllt, Schema Admins nur bei Schema-Erweiterungen.

Get-ADGroupMember "Enterprise Admins"
Get-ADGroupMember "Schema Admins"

Die Protected Users Group (ab Windows Server 2012 R2) bietet zusätzlichen Schutz: Mitglieder nutzen ausschließlich Kerberos (kein NTLM, kein CredSSP, kein Digest), nur AES-Verschlüsselung und kein Credential Caching auf Endpoints. DA, EA und Schema Admins müssen zwingend Mitglieder dieser Gruppe sein. Wichtig: Vor der Aufnahme testen, da Legacy-Apps brechen können.

Get-ADGroupMember "Protected Users"

Phase 3: Kerberoasting-Angriffsfläche

Kerberoasting ermöglicht das Offline-Cracken von Service-Account-Passwörtern. Das Funktionsprinzip: Jeder authentifizierte Domainuser kann SPNs (Service Principal Names) abfragen. Ein SPN markiert einen Account als Service-Account. Das Kerberos-Service-Ticket (TGS) wird mit dem Service-Account-Hash verschlüsselt und kann anschließend offline geknackt werden.

Kerberoastable Accounts werden mit folgendem PowerShell-Befehl identifiziert:

Get-ADUser -Filter {ServicePrincipalName -ne "$null" -and Enabled -eq $true} `
  -Properties ServicePrincipalName, PasswordLastSet, AdminCount |
  Select-Object SamAccountName, ServicePrincipalName, PasswordLastSet, AdminCount

Kritische Findings bei der Auswertung:

• Service Accounts mit AdminCount=1 (privilegiert und kerberoastable = kritischste Kombination)
• Service Accounts mit Passwörtern älter als 1 Jahr
• Service Accounts als Mitglied der Domain Admins-Gruppe
• SPNs auf USER-Accounts statt Computer-Accounts

Als Gegenmaßnahme sollten alle kerberoastbaren Accounts Passwörter mit mehr als 25 zufälligen Zeichen erhalten. Noch besser sind Group Managed Service Accounts (gMSA): Windows verwaltet das Passwort automatisch mit 240 Zeichen und rotiert es alle 30 Tage. Da kein Mensch das Passwort kennt, ist Kerberoasting praktisch unmöglich.

New-ADServiceAccount -Name "svc-webapp" -DNSHostName app.firma.de `
  -PrincipalsAllowedToRetrieveManagedPassword "Server-Gruppe"

Für AS-REP Roasting gilt: Accounts mit gesetztem Flag “Kerberos pre-authentication not required” können ohne gültiges Passwort angegriffen werden. Dieses Flag ist fast immer falsch konfiguriert und sollte auf $false gesetzt werden.

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} |
  Select-Object SamAccountName, DistinguishedName

Phase 4: Kerberos Delegation Risiken

Unconstrained Delegation ist das kritischste Delegations-Szenario: Der Account kann sich als beliebiger User bei beliebigen Services ausgeben. Der Angriff funktioniert, indem ein Domain Controller zur Authentifizierung gegenüber einem Server mit Unconstrained Delegation gezwungen wird, wodurch der DA-Hash erlangt werden kann.

Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties * |
  Select-Object Name, TrustedForDelegation
Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties * |
  Select-Object Name, TrustedForDelegation

Das erwartete Ergebnis: Ausschließlich Domain Controller. Jedes andere Ergebnis ist ein kritisches Finding.

Constrained Delegation (mittleres Risiko): Der Account darf sich nur bei spezifischen Services als User ausgeben. Bei Kompromittierung des Accounts sind alle erlaubten Services kompromittiert.

Get-ADUser -Filter {msDS-AllowedToDelegateTo -ne "$null"} `
  -Properties 'msDS-AllowedToDelegateTo' |
  Select-Object Name,'msDS-AllowedToDelegateTo'

Jeder gefundene Account sollte dahingehend geprüft werden, ob die Berechtigung tatsächlich notwendig ist.

Resource-Based Constrained Delegation (RBCD): Beim neueren RBCD-Modell steuert die Zielressource, wer sich delegieren darf. Ein Angriff über GenericWrite-Rechte auf ein Computer-Objekt ermöglicht einen RBCD-Angriff. BloodHound findet diese Pfade über die Abfrage “Principals with GenericWrite to computers”.

Phase 5: BloodHound Analyse

BloodHound (Community Edition) wird per Docker gestartet und ist unter http://localhost:8080 erreichbar:

git clone https://github.com/SpecterOps/BloodHound
docker compose up -d

SharpHound sammelt die Daten aus dem Active Directory:

.\SharpHound.exe -c All -d firma.de

Die wichtigsten BloodHound Cypher-Abfragen:

Shortest Paths to Domain Admin zeigt, wie viele Hops ein kompromittierter User bis zum Domain Admin benötigt:

MATCH p=shortestPath((n:User {name: "TESTUSER@FIRMA.DE"})-[*1..]->(m:Group {name: "DOMAIN ADMINS@FIRMA.DE"})) RETURN p

Users with DCSync Rights listet alle Accounts, die DCSync ausführen und damit alle Passwort-Hashes extrahieren können:

MATCH (n1)-[:MemberOf|GetChanges*1..]->(u:Domain) RETURN n1
MATCH (n1)-[:MemberOf|GetChangesAll*1..]->(u:Domain) RETURN n1

Kerberoastable Admins - ein kerberoastbarer Account der auch DA ist, ist das kritischste mögliche Finding:

MATCH (u:User {hasspn:true})-[:MemberOf*1..]->(g:Group {name:"DOMAIN ADMINS@FIRMA.DE"}) RETURN u

Computers with Unconstrained Delegation (außerhalb DCs):

MATCH (c:Computer {unconstraineddelegation:true}) WHERE c.name <> "DC01.FIRMA.DE" RETURN c

Die Standard-Abfragen in BloodHound (“Find all Domain Admins”, “Shortest Paths to Domain Admins from Owned Principals”, “Find Principals with DCSync Rights”, “Find Computers where Domain Users are Local Admin”) decken die wichtigsten Angriffspfade ab.

Phase 6: Credential Theft Prävention

Credential Guard isoliert LSASS in einem separaten Prozess über Hyper-V, sodass Mimikatz-Angriffe (lsadump::lsa) scheitern. Voraussetzungen sind UEFI Secure Boot und Virtualization-based Security.

GPO-Pfad: Computer Configuration → Admin Templates → System → Device Guard

• “Turn on Virtualization Based Security”: Enabled
• Platform Security Level: Secure Boot and DMA Protection
• Credential Guard Configuration: Enabled with UEFI lock

PPL (Protected Process Light) schützt LSASS auf Kernel-Ebene:

• Registry: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1
• Alternativ via GPO: Security Options → LSASS als geschützten Prozess ausführen

WDigest deaktivieren: WDigest speichert Klartext-Passwörter in LSASS und sollte in allen modernen Umgebungen deaktiviert sein:

• HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential = 0

NTLM einschränken: NTLM ermöglicht Pass-the-Hash-Angriffe. Vor der Einschränkung sollte ein Audit durchgeführt werden, welche Systeme noch NTLM verwenden:

Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" |
  Where-Object {$_.Id -eq 8004} |
  Select-Object TimeCreated, @{N="WorkstationName";E={$_.Properties[0].Value}},
                @{N="TargetName";E={$_.Properties[1].Value}}

GPO-Einstellungen: Security Options → Network Security: Restrict NTLM → Incoming NTLM traffic: Deny all accounts; NTLM authentication in this domain: Deny all.

AD-Audit Checkliste

Kritisch - sofort beheben

• Unconstrained Delegation auf Nicht-DCs
• Kerberoastable Domain Admins
• AS-REP Roasting auf privilegierten Accounts
• DCSync-Berechtigungen außerhalb von DA/EA
• Direkte Pass-the-Hash-Pfade zu Domain Admin (BloodHound)
• WDigest aktiviert (Klartext-Passwörter)
• Enterprise/Schema Admins nicht leer
• Default Domain Admin (Administrator) täglich genutzt

Hoch - innerhalb 30 Tage

• Domain Admins mit mehr als 5 Mitgliedern
• DA-Accounts als normale Benutzeraccounts verwendet
• Protected Users Group leer (DA/EA nicht darin)
• LAPS nicht implementiert (lokale Admin-Passwörter nicht verwaltet)
• NTLM nicht eingeschränkt
• Passwort-Policy mit weniger als 12 Zeichen Mindestlänge
• Credential Guard nicht aktiviert
• Inactive Accounts: mehr als 90 Tage ohne Login (aber aktiv)

Mittel - innerhalb 90 Tage

• Service Accounts ohne gMSA (manuell verwaltete Passwörter)
• Inaktive Computer-Objekte (> 90 Tage)
• GPO-Delegation nicht dokumentiert
• Domain Functional Level < 2016
• LDAP Signing nicht erzwungen
• LDAP Channel Binding nicht konfiguriert
• Tiered Administration nicht implementiert
• Privileged Access Workstations (PAWs) fehlen

Empfehlungen zur Härtung

Für eine strukturierte Absicherung empfiehlt sich das Tiered Admin Model mit Tier 0 (Domain Admins), Tier 1 (Server Admins) und Tier 2 (Workstation Admins). Microsoft ESAE (Enhanced Security Admin Environment) bietet hierfür einen bewährten Rahmen. Separate Admin-Accounts für privilegierte Aufgaben sowie JIT-Zugang für Domain Admin über Privileged Identity Management (PIM) runden das Konzept ab.

---

Active Directory Security ist kein einmaliges Projekt - Konfigurationen ändern sich, neue Service Accounts werden angelegt, Delegationen werden vergessen. AWARE7 führt regelmäßige AD-Sicherheitsaudits durch und hilft beim strukturierten Abbau von Angriffsflächen - von BloodHound-Analyse bis Tiered-Admin-Implementierung.

AD-Sicherheitsaudit anfragen | Penetrationstest Netzwerk