AD-Angriffspfade: Wie Fehlkonfigurationen bis Domain Admin führen

Was sind AD-Angriffspfade?

AD-Angriffspfade sind Ketten von Beziehungen — Gruppenmitgliedschaften, ACL-Berechtigungen, GPO-Verknüpfungen, Delegationskonfigurationen, kerberoastbare Konten —, die einen wenig privilegierten Angreifer mit Domain Admin verbinden. Keine einzelne Fehlkonfiguration muss für sich genommen kritisch sein: Entscheidend ist, ob sie sich verketten lassen.

Moderne Angreifer nutzen nicht einzelne Schwachstellen isoliert aus. Sie kartieren die gesamte AD-Umgebung als Graphen, identifizieren den kürzesten Weg von ihrer aktuellen Position zu Domain Admin und folgen diesem Weg — einen Hop nach dem anderen. Jeder Hop nutzt eine andere Fehlkonfiguration aus: ein geknacktes Passwort, einen Gruppenverschachtelungspfad, eine missbrauchbare ACL oder ein gefälschtes Zertifikat.

Dieser Artikel behandelt die drei zuverlässigsten Pfadkategorien: ACL-Pfade, GPO-Pfade und Kerberoasting-Pfade zu Domain Admin.

Wie AD-Angriffspfade funktionieren

Die Angriffspfadanalyse behandelt AD als gerichteten Graphen:

• Knoten = Benutzer, Computer, Gruppen, GPOs, OUs, Domänen
• Kanten = missbrauchbare Beziehungen (MemberOf, GenericAll, WriteDACL, GpLink usw.)

Tools wie BloodHound (Open Source) sammeln diese Graphdaten und nutzen Neo4j, um kürzeste Wege zwischen zwei beliebigen Knoten zu finden. Ein Angreifer, der BloodHound von einem kompromittierten Standardbenutzerkonto aus ausführt, kann den gesamten Weg zu Domain Admin in wenigen Minuten visualisieren — oft findet er Pfade, die jahrelange, sich anhäufende Fehlkonfigurationen benötigt haben, um zu entstehen.

Häufige Pfadkategorien

Die Angriffskette

Schritt 1 – AD-Graphdaten sammeln

# Von Linux mit gültigen Anmeldedaten — BloodHound-CE-Collector (pip install bloodhound-ce)
bloodhound-ce-python -u [email protected] -p password -ns 10.10.0.1 -d corp.local -c All --zip

# bloodhound-python (pip install bloodhound) ist der Legacy-Collector: nur BloodHound 4.2/4.3

# Von Windows
.\SharpHound.exe -c All --zipfilename corp_bloodhound.zip

Schritt 2 – Kürzeste Wege zu Domain Admin finden

In der BloodHound-UI oder im Neo4j-Browser:

// Kürzester Weg von einem beliebigen Benutzer zu Domain Admins
MATCH p=shortestPath((u:User {enabled:true})-[*1..]->(g:Group {name:"DOMAIN [email protected]"}))
RETURN p ORDER BY length(p) ASC LIMIT 10

// Alle kerberoastbaren Benutzer mit Pfad zu DA finden
MATCH (u:User {hasspn:true})-[*1..]->(g:Group {name:"DOMAIN [email protected]"})
RETURN u.name, u.pwdlastset

// GPO-Bearbeitungsrechte-Pfade zu DCs finden
MATCH p=(u:User)-[:GenericAll|GenericWrite|Owns|WriteDacl|WriteOwner*1..]->(g:GPO)-[:GPLink]->(c:OU)
WHERE c.blocksinheritance = false
RETURN p

Schritt 3 – Dem kürzesten Weg folgen

Ein typischer Weg aus der Praxis:

1. Der Angreifer kompromittiert jsmith (Standardbenutzer) per Phishing
2. jsmith hat GenericWrite über svc_deploy (Überbleibsel eines Projekts)
3. svc_deploy ist kerberoastbar mit einem drei Jahre alten Passwort
4. Der Angreifer schreibt via GenericWrite einen SPN auf svc_deploy und knackt das resultierende Service-Ticket (gezieltes Kerberoasting) — oder schreibt msDS-KeyCredentialLink für Shadow Credentials, denn GenericWrite allein erlaubt keinen Passwort-Reset, der ForceChangePassword oder GenericAll erfordert
5. svc_deploy ist Mitglied der Gruppe IT_Admins
6. IT_Admins ist in Domain Admins verschachtelt
7. Vollständige Domänenkompromittierung — 3 Graph-Hops, keine Exploits

Schritt 4 – Persistenz aufrechterhalten

Sobald DA-Zugriff erreicht ist, etabliert der Angreifer Persistenz über Golden Ticket, neue Backdoor-Konten oder ADCS-Zertifikats-Backdoors — um Passwort-Resets und Remediation-Versuche zu überstehen.

Erkennung

Die Erkennung von Angriffspfad-Traversierung erfordert die Überwachung jedes einzelnen Hops — kein einzelner Log-Eintrag offenbart den gesamten Pfad.

Windows Event-IDs

SIEM-Korrelationsabfrage

KQL filtert nur Dokumente — es kann nicht aggregieren —, daher wird die Korrelation selbst in ES|QL ausgedrückt:

// Schnell aufeinanderfolgende Privilege-Escalation-Events derselben Quelle erkennen
FROM logs-*
| WHERE event.code IN ("4769", "4724", "4728", "5136")
    AND @timestamp > NOW() - 1 hour
| STATS event_count = COUNT(*) BY winlog.event_data.SubjectUserName
| WHERE event_count > 3

Remediation

1. Die kürzesten Pfade zuerst eliminieren

Führen Sie BloodHound aus und exportieren Sie die 10 kürzesten Pfade zu Domain Admin. Für jeden Pfad:

• ACL-Kante: Entfernen Sie die gefährliche ACE vom Objekt
• Gruppenverschachtelungs-Kante: Entfernen Sie die Gruppe aus der privilegierten Gruppe
• Kerberoastbare Kante: Rotieren Sie das Passwort oder migrieren Sie zu gMSA
• GPO-Kante: Entfernen Sie die Bearbeitungsrechte des Nicht-Admin-Kontos

2. Kontinuierliches Angriffspfad-Monitoring implementieren

# Wöchentliche BloodHound-Sammlung per geplantem Task
# SharpHound ist eine native ausführbare Datei: Flags explizit übergeben (Hash-Table-Splatting bindet
# nur an PowerShell-Cmdlets, nicht an eine .exe)
.\SharpHound.exe -c All `
    --outputdirectory "C:\BloodHound\Collections\" `
    --zipfilename "weekly_$(Get-Date -Format yyyyMMdd).zip"
# Mit den Daten der Vorwoche vergleichen und bei neuen DA-Pfaden alarmieren

3. Kerberoastbare Konten im DA-Pfad priorisieren

# Alle kerberoastbaren Konten mit beliebigem Pfad zu DA-Rechten finden
# -Filter erwartet einen String; krbtgt trägt einen SPN, ist aber praktisch nicht roastbar
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties MemberOf, PasswordLastSet |
    Where-Object { $_.SamAccountName -ne "krbtgt" } |
    Where-Object {
        $_.MemberOf | Get-ADGroup | Where-Object { $_.Name -match "Admin" }
    } | Select-Object SamAccountName, PasswordLastSet
# Diese Konten sofort zu gMSA migrieren

Wie EtcSec dies erkennt

EtcSec führt kontinuierliche Angriffspfadanalysen über Ihren gesamten AD-Graphen durch und identifiziert alle Pfade von wenig privilegierten Konten zu Domain Admin.

PATH_ACL_TO_DA kartiert jeden ACL-basierten Pfad von Standardbenutzern zu Domain Admin, einschließlich mehrstufiger Ketten über Zwischenobjekte.

PATH_GPO_TO_DA identifiziert Pfade, bei denen GPO-Bearbeitungsrechte auf mit Tier-0-OUs verknüpfte Richtlinien einen indirekten Weg zur Domain-Controller-Kompromittierung bieten.

PATH_KERBEROASTING_TO_DA kennzeichnet kerberoastbare Dienstkonten, die — direkt oder transitiv — Domain-Admin-Rechte besitzen, was den häufigsten Angriffspfad mit hoher Auswirkung in realen Umgebungen darstellt.

Review-Prioritäten

AD-Angriffspfade zu Domain Admin sollten als reale Exposition innerhalb Ihres Active-Directory-Bestands behandelt werden, nicht als isolierte Einzeleinstellung. Beginnen Sie mit der Abgrenzung des Review-Umfangs: welche privilegierten Gruppen, Dienstkonten, ACLs, GPO-Verknüpfungen, Trusts, Delegationseinstellungen, Zertifikatsvorlagen und Admin-Workstations betroffen sind, welche Geschäftsprozesse davon abhängen, welche Rechte sie exponieren und welche Notfall-Ausnahmen im Laufe der Zeit hinzugefügt wurden. Dieser Scoping-Schritt verhindert oberflächliche Remediation, denn das technische Symptom ist oft kleiner als der operative Wirkungsradius. Indem das Team den vollständigen Pfad von Konfiguration zu Privileg dokumentiert, kann es Änderungen priorisieren, die das Risiko schnell reduzieren, ohne den Produktivbetrieb zu unterbrechen. Das schafft zudem eine belastbare Baseline für spätere Validierung und liefert der Leitung eine klare Erklärung, warum das Thema jetzt relevant ist.

Angrenzende Kontrollen zur Überprüfung

Wenn Angreifer Ihren Active-Directory-Bestand erreichen, bleiben sie selten beim ersten Schwachpunkt stehen. Rund um AD-Angriffspfade zu Domain Admin prüfen sie üblicherweise, ob der exponierte Pfad sich mit veralteten privilegierten Konten, unsicherer Gruppenverschachtelung, exzessiver Delegation, schwachen Passwortrichtlinien, beschreibbaren GPO-Pfaden und vererbtem ACL-Missbrauch verketten lässt. Das bedeutet, Verteidiger sollten nicht nur die Hauptschwachstelle prüfen, sondern jede benachbarte Abhängigkeit, die aus Zugriff Persistenz oder Rechteausweitung macht. Bestätigen Sie, welche Identitäten, Rollen, Berechtigungen und Vertrauensannahmen von einem motivierten Angreifer wiederverwendet werden können. Wenn eine Korrektur nur ein Objekt schließt, während benachbarte Rechtepfade unangetastet bleiben, ändert sich das tatsächliche Risiko kaum. Eine disziplinierte Überprüfung der Verkettungsmöglichkeiten macht aus diesem Artikelthema eine praktische Härtungsübung statt eines einmaligen Checkbox-Abhakens.

Nachweise und Telemetrie zur Erhebung

Eine solide Reaktion auf AD-Angriffspfade zu Domain Admin benötigt Nachweise, die sowohl von Engineering- als auch von Detection-Teams überprüft werden können. Ziehen Sie die Event-IDs 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, SYSVOL-Änderungen sowie Zertifikats- oder CA-Aktivität heran, vergleichen Sie kürzliche Änderungen mit bekannten Wartungsfenstern und isolieren Sie Konten oder Systeme, deren Verhalten sich ohne klaren geschäftlichen Grund geändert hat. Nutzen Sie diese Nachweise, um drei Fragen zu beantworten: wann der riskante Pfad entstanden ist, wer ihn noch nutzen kann, und ob ähnliche Exposition anderswo in Ihrem Active-Directory-Bestand existiert. Eine gute Telemetrie-Überprüfung hilft außerdem, ererbte technische Schulden von aktivem Missbrauch zu unterscheiden. Diese Unterscheidung ist wichtig, denn der Remediation-Plan für veraltete Fehlkonfiguration unterscheidet sich vom Plan für einen Pfad, der bereits angreiferähnliche Aktivität oder wiederholte Richtlinien-Ausnahmen zeigt.

Angrenzende Schwachstellen, die eine Überprüfung wert sind

Nur wenige Umgebungen enthalten AD-Angriffspfade zu Domain Admin isoliert. In der Praxis enthält dasselbe Tenant- oder Verzeichnissegment oft auch veraltete privilegierte Konten, unsichere Gruppenverschachtelung, exzessive Delegation, schwache Passwortrichtlinien, beschreibbare GPO-Pfade und vererbten ACL-Missbrauch, und diese benachbarten Schwachstellen entscheiden, ob das Problem lediglich störend oder wirklich kritisch ist. Überprüfen Sie gemeinsame Owner, vererbte Berechtigungen, duplizierte Ausnahmen und langlebige administrative Abkürzungen. Prüfen Sie, ob dasselbe Team ähnliche riskante Muster an mehreren Stellen genehmigt hat, denn wiederholte Entscheidungen deuten meist auf eine Prozesslücke statt auf einen einzelnen technischen Fehler hin. Diese breitere Überprüfung verhindert eine unvollständige Bereinigung und erhöht Ihre Chance, den gesamten Angriffspfad zu entfernen. Sie verbessert zudem die Audit-Bereitschaft, denn der Endzustand lässt sich leichter erklären und über die Zeit leichter überwachen.

Weiterführende Artikel

Betrachten Sie dieses Thema zusammen mit ACL-Missbrauch und DCSync: Die stillen Pfade zu Domain Admin, Gefährliche Gruppenverschachtelung: Versteckte Pfade zu Domain Admin, Active-Directory-Trust-Angriffe: Von der Kind-Domäne zur Forest Root, GPO-Fehlkonfigurationen: Wie Group Policy zum Angriffsvektor wird und AD-Sicherheitsüberwachung: Sicherheitsrelevante Event-IDs. Diese verwandten Artikel zeigen, wie sich dieselben Identitätsschwächen bei einer echten Bewertung üblicherweise verketten, statt als isolierte Befunde aufzutreten.

• ACL-Missbrauch und DCSync: Die stillen Pfade zu Domain Admin
• Gefährliche Gruppenverschachtelung: Versteckte Pfade zu Domain Admin
• Active-Directory-Trust-Angriffe: Von der Kind-Domäne zur Forest Root
• GPO-Fehlkonfigurationen: Wie Group Policy zum Angriffsvektor wird
• AD-Sicherheitsüberwachung: Sicherheitsrelevante Event-IDs

Diese Referenzen halten die Remediation-Diskussion auf den vollständigen Angriffspfad fokussiert statt auf eine einzelne Kontrolllücke.

Validierungs-Checkliste

Führen Sie vor Abschluss der Überprüfung dieselben Prüfungen erneut aus, die das Problem aufgedeckt haben, und bestätigen Sie, dass der riskante Pfad aus Angreiferperspektive nicht mehr existiert. Verifizieren Sie die relevanten Identitäten, Rechte, Vererbungspfade und kompensierenden Kontrollen in der Produktion, nicht nur in der Staging-Umgebung oder in der Dokumentation. Erfassen Sie den technischen Owner, die erwartete Geschäftsabhängigkeit und den Nachweis, dass die neue Konfiguration sowohl sicherer als auch operativ nachhaltig ist. Dieser abschließende Validierungsschritt sorgt dafür, dass der Artikel in der Praxis verankert bleibt, wie Teams das Identitätsrisiko tatsächlich reduzieren.