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

Was sind AD-Angriffspfade?

AD-Angriffspfade sind Ketten aus Beziehungen, über die ein wenig privilegiertes Konto schrittweise zu höherem Privileg gelangt, oft bis Domain Admin oder zu einem anderen Tier-0-Ziel. Der entscheidende Punkt ist: Nicht ein einzelner Fehler ist ausschlaggebend, sondern die Kombination aus ACLs, Gruppenmitgliedschaften, Admin-Sessions, GPO-Rechten, Dienstkonten und Delegationspfaden. Genau diese Kombination macht einen Graphen nützlich.

Angreifer denken nicht in Einzelfunden, sondern in Wegen. Wenn ein Benutzer GenericWrite über ein Dienstkonto hat, dieses Konto auf einem Server mit Admin-Session landet und dieser Admin wiederum Rechte auf DC-nahe Systeme hat, dann existiert ein AD-Angriffspfad bereits – unabhängig davon, ob Ihr Team ihn dokumentiert hat. Werkzeuge wie BloodHound helfen dabei, diese Pfade sichtbar zu machen, aber die eigentliche Aufgabe beginnt danach: Welche Kanten im Graphen reduzieren die Distanz zu Tier 0 am stärksten?

AD-Angriffspfade: Welche Kanten wirklich zählen

In realen Umgebungen reichen meist zwei oder drei dieser Kanten, um aus einem normalen Konto einen kritischen Angriffspfad zu bauen.

Wie AD-Angriffspfade praktisch kartiert werden

1. Graphdaten erfassen

bloodhound-python -u [email protected] -p 'Password123!' -ns 10.10.0.1 -d corp.local -c All --zip

Die Sammlung allein ist nicht das Ziel. Sie ist nur der Startpunkt, um wiederkehrende Muster sichtbar zu machen.

2. Kürzeste oder stabilste Wege identifizieren

MATCH p = shortestPath((u:User)-[*1..]->(g:Group {name:"DOMAIN [email protected]"}))
RETURN p LIMIT 10

Der kürzeste Weg ist nicht immer der wahrscheinlichste. Für Verteidiger ist aber beides relevant: der kürzeste Pfad und der Pfad, der mit der höchsten betrieblichen Stabilität immer wieder auftaucht.

3. Kanten priorisieren statt nur Funde zu zählen

Ein häufiger Fehler ist, jede riskante Berechtigung isoliert zu behandeln. Sinnvoller ist zu fragen:

• Welche ACL trennt einen normalen Benutzer von einem hoch relevanten Objekt?
• Welche Session macht einen Server plötzlich zu einem Tier-0-nahen Ziel?
• Welche GPO oder Gruppe taucht in vielen Pfaden immer wieder auf?
• Welche Dienstkonten verbinden Kerberoasting mit echter Eskalation?

Was Sie zuerst prüfen sollten

ACLs und Berechtigungsdelegation

Suchen Sie nach Schreibrechten auf:

• privilegierte Benutzer und Gruppen
• GPOs mit breiter Verknüpfung
• OU-Strukturen mit Server- oder Admin-Systemen
• Dienstkonten und gMSA-nahe Konten
• Objekte mit Replikations- oder Zertifikatsbezug

Sessions und Admin-Arbeitsplätze

Viele AD-Angriffspfade werden nicht durch LDAP allein kritisch, sondern erst durch Sessions. Prüfen Sie, wo sich Admins anmelden und welche Systeme dadurch plötzlich lohnend werden. Ein normaler Server mit Tier-0-Session ist kein normaler Server mehr.

Gruppenpfade und Altlasten

Historische Gruppenverschachtelungen, Projektgruppen, Helpdesk-Delegationen und Notfallkonten erzeugen oft stabile Pfade, die niemand absichtlich gebaut hat. Gerade diese Pfade überleben Jahre.

Dienstkonten und SPNs

Dienstkonten sollten nicht nur nach Passwortstärke geprüft werden, sondern nach ihrer Position im Graphen. Ein knackbarer Service Account ohne interessante Rechte ist unangenehm. Ein knackbarer Service Account mit Admin-Nähe ist ein Angriffspfad.

Erkennung und Telemetrie

Ein Graph wird primär durch Inventar sichtbar, nicht durch ein einziges SIEM-Signal. Trotzdem lohnt sich Telemetrie, um neu entstehende Kanten zu erkennen.

Typische Indikatoren

• 4728 / 4732 für neue Gruppenpfade
• 5136 für Änderungen an AD-Objekten und ACLs
• 4769 für Dienstkonten, die Kerberoasting-relevant werden
• 4624 für privilegierte Sessions auf ungeeigneten Hosts
• Änderungen an GPOs, Delegation oder lokalen Admin-Gruppen

Was regelmäßig gemessen werden sollte

• kürzeste Distanz zu Tier 0
• neue Principals mit Schreibrechten auf relevante Objekte
• neue privilegierte Sessions auf Servern außerhalb der vorgesehenen Admin-Zonen
• neue SPNs oder Änderungen an Dienstkonten
• neue oder veränderte GPO-Kanten

Remediation und Härtung

1. Brechen Sie zuerst die wichtigsten Kanten

Die besten Fixes sind oft die, die mehrere Pfade gleichzeitig zerstören:

• überbreite delegierte Gruppen reduzieren
• Schreibrechte auf Dienstkonten oder GPOs entfernen
• privilegierte Sessions aus unsicheren Hosts fernhalten
• anfällige Service Accounts auf gMSA oder bessere Betriebsmodelle migrieren

2. Behandeln Sie Sessions als Teil des Graphen

Viele Teams bereinigen nur LDAP-Beziehungen. Das reicht nicht. Wenn privilegierte Benutzer auf angreifbaren Hosts sitzen, bleibt der Graph gefährlich.

3. Wiederholen und vergleichen Sie die Erfassung

Ein einmaliger Scan ist nur eine Momentaufnahme. AD-Angriffspfade sollten über wiederkehrende Sammlungen, Diffing und feste Review-Zyklen kontrolliert werden. Entscheidend ist nicht nur, wie der Graph heute aussieht, sondern welche neue Kante seit letzter Woche entstanden ist.

Validierung nach dem Fix

• die Sammlung erneut ausführen und die kürzesten Pfade vergleichen
• sicherstellen, dass keine alternative Kante mit gleichem Effekt entstanden ist
• prüfen, ob privilegierte Sessions von ungeeigneten Hosts verschwunden sind
• schriftlich festhalten, welche Kanten bewusst akzeptiert, welche entfernt und welche architektonisch noch offen sind

Zusätzliche Prüfungen für den nächsten Review-Zyklus

Für AD-Angriffspfade lohnt sich eine zweite Priorisierungsschicht: Welche Pfade enden nicht direkt in Domain Admins, aber in Objekten, die Tier 0 indirekt stützen? Dazu zählen PKI-Systeme, GPO-verwaltete Admin-Hosts, privilegierte Dienstkonten und Backup-Systeme. Ein Pfad, der "nur" auf einen solchen Knoten zeigt, kann betrieblich gefährlicher sein als ein seltener direkter Pfad zu Domain Admins. Diese zusätzliche Sicht verbessert die Reihenfolge der Remediation spürbar.

Häufig übersehene Kanten

Übersehen werden oft lokale Administratorrechte auf Management-Servern, delegierte Rechte auf Gruppenrichtlinien mit breitem Scope und Service Accounts, die zwar nicht privilegiert aussehen, aber Softwareverteilung oder Backup-Prozesse steuern. Genau diese Kanten sollten im nächsten Review bewusst gegen Tier-0-Nähe geprüft werden. Das gilt besonders für Plattformen, die viele Server gleichzeitig ändern dürfen.

Geschützte Gruppen und AdminSDHolder im Pfadmodell

Nicht jeder gefährliche Pfad endet in einer normalen Gruppe mit vererbbaren ACLs. Microsoft schützt besonders privilegierte Konten und Gruppen über AdminSDHolder und den periodischen SDProp-Abgleich. Für die Praxis bedeutet das: Wenn ein Pfad in Domain Admins, Administrators, Account Operators, Backup Operators oder andere geschützte Objekte läuft, reicht es nicht, nur die OU-Vererbung oder ein einzelnes Gruppenobjekt zu prüfen. Das Team muss auch kontrollieren, ob am AdminSDHolder-Objekt selbst schwache Berechtigungen liegen oder ob eine Delegation auf geschützte Objekte regelmäßig wiederhergestellt wird. Gerade bei Altlasten aus Exchange-, Migrations- oder Helpdesk-Projekten erklärt das, warum ein vermeintlich bereinigter Pfad nach kurzer Zeit wieder auftaucht.

Für die Pfadanalyse heißt das: Markieren Sie Knoten mit AdminSDHolder-Bezug separat. Ein Pfad, der auf ein geschütztes Objekt oder auf eine Gruppe mit Einfluss auf geschützte Objekte zeigt, verdient in der Regel höhere Priorität als ein ähnlich langer Pfad zu einem weniger stabilen Ziel. Das gilt besonders dann, wenn derselbe Zwischenknoten in mehreren Pfaden wiederverwendet wird.

Management-Server, Backup-Systeme und Verteilungsknoten

Viele AD-Angriffspfade werden unterschätzt, weil der letzte Knoten vor Tier 0 kein Domänencontroller ist. In der Praxis sind aber Management-Server, Softwareverteilung, Backup-Systeme, Jump Hosts und Virtualisierungsverwaltung oft die eigentlichen Choke Points. Wer dort lokale Administratorrechte, Dienstkontenkontrolle oder Dateiverteilungsrechte gewinnt, kann neue Sessions, neue Credentials und neue Schreibpfade erzeugen, die im nächsten Sammellauf noch gar nicht sichtbar waren. Deshalb sollte die Priorisierung nicht nur auf Gruppenpfade zu Domain Admins schauen, sondern auf Systeme, die gleichzeitig viele privilegierte Sitzungen oder Änderungsrechte bündeln.

Ein typisches Beispiel ist ein Deployment- oder Backup-Server mit breitem Reach in die Umgebung. Selbst wenn der Graph zunächst nur lokale Adminrechte auf diesem Host zeigt, ist der operative Effekt oft größer als bei einem einzelnen Pfad in eine mittlere Admin-Gruppe. Die richtige Frage lautet daher nicht nur: „Wie kurz ist der Pfad?“, sondern auch: „Wie viel Folgeschaden erlaubt dieser Knoten im Betrieb?“

Validierung im Graph statt nur im Rechtevergleich

Nach einer Remediation sollten Sie nicht nur bestätigen, dass eine ACE entfernt oder eine Gruppenmitgliedschaft gelöscht wurde. Entscheidend ist, ob der Pfad im Graphen tatsächlich verschwunden ist. Ein sauberer Review prüft daher mindestens drei Dinge: Erstens, ob die vorherige Kante entfernt wurde; zweitens, ob ein alternativer Pfad mit ähnlicher Wirkung entstanden ist; und drittens, ob der betroffene Knoten weiterhin über Sessions, lokale Administratorrechte oder delegierte Betriebsrechte an Tier 0 anschließt. Gerade in größeren Umgebungen ist die Rückkehr eines Pfads oft kein Zeichen eines fehlgeschlagenen Changes, sondern eines anderen verbliebenen Knotenpunkts.

Berichtswesen mit Choke-Point-Kennzahlen

Reife Teams berichten AD-Angriffspfade nicht nur als Liste einzelner Kanten, sondern als Veränderung weniger kritischer Choke Points. Sinnvolle Kennzahlen sind zum Beispiel: Welche Knoten erscheinen in den meisten kürzesten Pfaden? Welche neue Kante hat die Distanz eines Standardbenutzers zu Tier 0 spürbar verkürzt? Und welche Management- oder Admin-Hosts bündeln aktuell die meisten privilegierten Sessions? Diese Sicht verhindert, dass sich Reviews in Hunderten isolierten Einzelrechten verlieren. Sie lenkt die Remediation auf wenige Knoten, deren Bereinigung den Graphen wirklich verändert.

Referenzen

• SpecterOps BloodHound documentation: shortest path analysis and collection
• Microsoft Learn: Group Policy permissions cmdlets
• Microsoft Learn: gMSA overview
• Microsoft Learn: Active Directory delegation and ACL concepts
• Microsoft Learn: Protected Accounts and Groups in Active Directory / AdminSDHolder

Verwandte Beiträge

• ACL-Missbrauch und DCSync: Die stillen Pfade zu Domain Admin
• GPO-Fehlkonfigurationen als Angriffsvektor
• Kerberoasting: Wie Angreifer Dienstkonto-Passwörter knacken
• Kerberos-Delegationsangriffe: Unkontrolliert bis RBCD
• AD Sicherheitsüberwachung: Event IDs und SIEM
• AD Gruppenverschachtelung: Versteckte DA-Pfade

AD-Angriffspfade lassen sich nicht sinnvoll priorisieren, wenn man nur Einzelbefunde sammelt. Relevanz entsteht erst dort, wo Berechtigung, Session, Delegation und Betriebsrealität denselben Weg zu Tier 0 verkürzen.