ACL-Missbrauch und DCSync: Wie stille Rechte Domain Admin öffnen

Was sind ACL-Missbrauch und DCSync?

ACL-Missbrauch und DCSync gehören zu den gefährlichsten Berechtigungspfaden in Active Directory, weil sie weder eine CVE noch einen Softwarefehler brauchen. Es reicht, dass einem Konto auf einem sensiblen Objekt die falschen Rechte eingeräumt wurden. In der Praxis geht es meist um zwei Kategorien: zu breite Objektkontrolle wie GenericAll, WriteDacl, WriteOwner oder ResetPassword, und Replikationsrechte, mit denen sich ein Konto gegenüber dem Verzeichnis wie ein Domain Controller verhalten kann.

Gerade deshalb bleiben ACL-Missbrauch und DCSync oft lange unentdeckt. Viele Teams härten Endpunkte, schauen aber nie systematisch auf die DACLs hochwertiger AD-Objekte. Wer dort gefährliche ACEs übersieht, baut unabsichtlich einen stillen Pfad zu privilegierten Konten, Gruppen oder direkt zum Domain Root.

ACL-Missbrauch und DCSync: Welche Rechte wirklich kritisch sind

Entscheidend ist dabei nicht nur, welches Recht existiert, sondern auf welchem Objekt. GenericAll auf einem unkritischen Testobjekt ist unsauber. GenericAll auf einem Dienstkonto mit Admin-Rechten oder WriteDacl auf einer privilegierten Gruppe ist ein Angriffspfad.

Wie der Angriff praktisch funktioniert

1. Gefährliche Rechte inventarisieren

Ein Angreifer oder Verteidiger beginnt mit der Frage: Welche Principals halten zu starke Rechte auf hochwertigen Objekten?

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

2. Rechte gegen ein Zielobjekt ausnutzen

Mit GenericAll oder verwandten Rechten lassen sich oft sofort Aktionen auslösen:

$secPwd = ConvertTo-SecureString "NeueP@ssw0rd!" -AsPlainText -Force
Set-ADAccountPassword -Identity "zieladmin" -Reset -NewPassword $secPwd

Add-ADGroupMember -Identity "Domain Admins" -Members "angreifer"

3. Replikationsrechte für DCSync verwenden

DCSync ist besonders kritisch, weil das betroffene Konto keine interaktive Domain-Admin-Session braucht. Es braucht nur die nötigen Replikationsrechte am Domain Root.

lsadump::dcsync /domain:corp.local /all /csv

Die dabei relevanten Rechte-GUIDs sind insbesondere:

• 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2
• 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2

Was Sie zuerst prüfen sollten

Rechte auf privilegierten Gruppen und Benutzern

Prüfen Sie DACLs auf:

• Domain Admins
• Enterprise Admins
• Tier-0-nahe Service Accounts
• Konten mit GPO-, PKI- oder Replikationsnähe
• OU-Strukturen mit Domain Controllern oder Admin-Systemen

Rechte auf dem Domain Root

DCSync-Risiko sitzt nicht irgendwo im Verzeichnis, sondern typischerweise am Domain Root. Jedes Nicht-DC-Konto mit Replikationsrechten gehört sofort in eine Incident- oder Hardening-Besprechung.

Delegationen, die nie neu bewertet wurden

Historische Helpdesk-Modelle, Migrationen und Service-Konten hinterlassen häufig unsichtbare Berechtigungsreste. Gerade WriteDacl und GenericAll werden oft vererbt, ohne dass noch jemand deren Wirkung versteht.

Erkennung und Telemetrie

Relevante Signale

• 4662 bei sensiblen Objektzugriffen und Replikationsoperationen
• 4728 / 4732 bei Gruppenübernahmen
• 4738 bei Passwort-Resets und Kontenänderungen
• 5136 bei Änderungen an ACLs oder Schlüsselattributen

Beispiel für DCSync-nahe Erkennung

event.code == "4662" and winlog.event_data.Properties : ("*1131f6aa*" or "*1131f6ad*")

Wichtig ist dabei die Auswertung im Kontext: Ein Nicht-DC-Konto, das diese GUIDs gegen das Domänenobjekt nutzt, ist fast immer untersuchungswürdig.

Remediation und Härtung

1. Entfernen Sie Replikationsrechte von Nicht-DC-Konten

Das ist eine Zero-Tolerance-Kategorie. Wenn ein Konto kein legitimer Replikationspartner ist, sollte es diese Rechte nicht besitzen.

$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"
$replicationGuids = @(
  [guid]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
  [guid]"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"
)
$acl.Access | Where-Object {
  $_.ObjectType -in $replicationGuids -and $_.IdentityReference -notmatch "Domain Controllers"
} | ForEach-Object { $acl.RemoveAccessRule($_) }
Set-Acl "AD:\$domainDN" $acl

2. Reduzieren Sie Schreibrechte auf hochwertige Objekte

Entfernen Sie GenericAll, WriteDacl, WriteOwner und ähnliche Rechte von Konten, die diese Kontrolle nicht zwingend benötigen. Dokumentieren Sie jede Ausnahme mit Owner und Grund.

3. Überprüfen Sie Vererbung und delegierte Modelle

Viele riskante ACEs sind keine bewusste Entscheidung mehr, sondern Altlast. Prüfen Sie, aus welcher Delegation sie stammen und ob das Betriebsmodell noch existiert.

4. Kontrollieren Sie die Folgepfade

ACL-Missbrauch und DCSync stehen selten allein. Prüfen Sie immer auch Gruppenpfade, Sessions, GPOs und Dienstkonten, die an dieselben Principals angeschlossen sind.

Validierung nach dem Fix

• DACLs der Zielobjekte erneut lesen und mit dem alten Zustand vergleichen
• prüfen, ob das entfernte Recht über Vererbung oder ein anderes Objekt erneut auftaucht
• DCSync-nahe Konten gegen Domain Root und Replikationsrechte erneut inventarisieren
• Gruppenübernahmen, Passwort-Resets und 4662-Signale nach dem Change beobachten

Zusätzliche Review-Schritte

Für ACL-Missbrauch und DCSync lohnt sich ein zweiter Review-Lauf auf Objekten, die indirekt zu Tier 0 führen: GPOs mit breiter Verknüpfung, PKI-relevante Objekte, Service Accounts mit Administratorrechten und Gruppen, die zwar nicht Domain Admins heißen, aber operativ denselben Effekt haben. Gerade WriteDacl auf solchen Zwischenknoten ist gefährlich, weil daraus mit wenig Aufwand weitere Rechte entstehen. Prüfen Sie daher nicht nur direkte Treffer, sondern auch Objekte, über die sich Folgepfade bauen lassen.

Praktische Priorisierung für den Wochen-Review

Ein sinnvoller Wochen-Review beginnt meist mit drei Fragen: Welche neuen Principals haben seit dem letzten Lauf Schreibrechte auf privilegierten Gruppen erhalten? Welche Nicht-DC-Konten besitzen heute Replikationsrechte auf dem Domain Root? Und welche Service Accounts mit erweiterten ACL-Rechten tauchen gleichzeitig in BloodHound-Pfaden oder auf Administrationsservern auf? Diese drei Abfragen liefern oft schneller verwertbare Prioritäten als eine lange Liste aller ACEs im Verzeichnis.

Zusätzlich sollte jedes Team dokumentieren, welche Delegationen bewusst bestehen bleiben, weil sie betrieblich notwendig sind, und welche nur historische Altlast sind. Genau dort lassen sich oft die stillen Rechte entfernen, die später als DCSync- oder ResetPassword-Pfad wieder auftauchen.

Geschützte Objekte und AdminSDHolder gesondert prüfen

Bei ACL-Missbrauch reicht es nicht, nur die DACL der betroffenen Gruppe oder des Benutzerobjekts zu lesen. Microsoft schützt privilegierte Konten und Gruppen über AdminSDHolder und den SDProp-Abgleich. Änderungen an geschützten Objekten können deshalb später wieder auf den Sicherheitsdeskriptor von AdminSDHolder zurückgesetzt werden oder umgekehrt durch schwache Rechte am AdminSDHolder-Objekt erneut eingeführt werden. Für die Praxis heißt das: Wenn Domain Admins, Administrators, Account Operators, Backup Operators oder andere geschützte Objekte im Pfad liegen, muss der Review auch das AdminSDHolder-Objekt, vererbte Delegationen und historische Produktinstallationen einbeziehen.

Dieser Punkt ist wichtig, weil Teams sonst am falschen Objekt reparieren. Eine entfernte ACE auf einer einzelnen Gruppe hilft wenig, wenn dieselbe Berechtigung über AdminSDHolder periodisch zurückkommt oder auf ein anderes geschütztes Objekt verschoben wird.

Replikationsrechte enger als Ausnahme behandeln

Für Synchronisations- oder Identity-Management-Lösungen wird häufig nur Replicating Directory Changes benötigt. Das Recht DS-Replication-Get-Changes-All erlaubt dagegen die Replikation geheimer Domänendaten und ist genau deshalb DCSync-relevant. Aus Verteidigersicht sollten diese Rechte nie pauschal an Servicekonten delegiert werden. Jede Ausnahme braucht ein klar benanntes Produkt, einen Owner, den betroffenen Namenskontext und eine erneute Prüfung nach Produkt- oder Architekturänderungen. Fehlt diese Dokumentation, ist der sicherste Default, die Rechte zu entfernen und den legitimen Bedarf kontrolliert neu zu belegen.

Welche Objekte im Review oft vergessen werden

Viele Teams prüfen zuerst nur Domain Admins, den Domain Root und vielleicht noch einige Service Accounts. In realen Umgebungen sind aber auch GPOs mit Server-Scope, OU-Objekte mit DC- oder Admin-Host-Bezug, Certificate Templates, Backup-Gruppen und Plattformkonten für Virtualisierung oder Softwareverteilung kritisch. Ein WriteDacl auf einem solchen Zwischenobjekt wirkt im Graphen manchmal stärker als ResetPassword auf einem einzelnen Benutzer, weil von dort aus mehrere Folgepfade entstehen. Genau deshalb sollte jede ACL-Analyse die Frage stellen, welches betriebliche Änderungsrecht aus einem Directory-Recht praktisch wird.

Gruppen-, GPO- und PKI-nahe Rechte gemeinsam bewerten

Viele privilegierte Pfade wirken harmlos, solange sie in getrennten Silos bewertet werden. Das IAM-Team prüft Gruppen, das Workplace-Team prüft GPOs und das PKI-Team prüft Zertifikatobjekte. Für einen Angreifer sind das jedoch nur unterschiedliche Knoten desselben Graphen. Wenn ein Konto über ACLs eine GPO ändern, ein Servicekonto zurücksetzen oder ein PKI-nahes Objekt beeinflussen kann, gehört das in denselben Priorisierungs-Review wie DCSync-Rechte. Genau dort entstehen die stillen Wege, die im Alltag kaum auffallen, im Incident aber sofort kritisch werden.

Dokumentation für legitime Synchronisationskonten

Wo Replikationsrechte betrieblich wirklich nötig sind, sollte die Ausnahme schriftlich Produktname, verantwortliches Team, betroffenen Namenskontext, benötigte Rechte-GUIDs und das Abnahmedatum enthalten. Fehlt einer dieser Punkte, ist die Ausnahme operativ nicht belastbar. In der Praxis verschwinden viele „legitime“ DCSync-nahen Rechte, sobald Teams gezwungen sind, den Bedarf so konkret zu dokumentieren.

Ausnahme-Review nach Produkt- und Architekturwechseln

Gerade nach Migrationen, Backup-Wechseln oder dem Austausch von IAM-Produkten bleiben häufig Rechte zurück, die im neuen Zielbild niemand mehr braucht. Deshalb sollte jedes Team nach einem Produktwechsel nicht nur Servicekonten deaktivieren, sondern die ehemals delegierten ACLs am Domain Root, auf privilegierten Gruppen und auf Admin-nahen OUs erneut lesen. Viele alte DCSync-Risiken sind keine aktiven Entscheidungen mehr, sondern bloß nie entfernte Betriebsreste.

Validierung von Vererbung und Rückkehrpfaden

Nach jeder Bereinigung sollte zusätzlich geprüft werden, ob Rechte über OU-Vererbung, delegierte Hilfsgruppen oder periodische Admin-Prozesse unbemerkt zurückkehren. Besonders in größeren Umgebungen entstehen gefährliche ACEs nicht einmalig, sondern werden durch Provisioning-Skripte, Altprodukte oder Standarddelegationen immer wieder neu gesetzt. Ein sauberer Abschluss für ACL-Missbrauch und DCSync dokumentiert deshalb nicht nur den entfernten Eintrag, sondern auch die Quelle, aus der er entstanden ist, und die Kontrollstelle, die seine Rückkehr künftig verhindern soll.

Rückprüfung nach SDProp und Produktjobs

Wenn geschützte Gruppen betroffen waren, sollte der Review mindestens einen SDProp-Zyklus und den nächsten Lauf von Provisioning- oder IAM-Jobs abwarten. Erst dann zeigt sich, ob entfernte ACEs stabil verschwinden oder ein Altprozess dieselben Rechte erneut setzt. Für DCSync-nahe Ausnahmen gilt dasselbe: Nach jeder Korrektur sollten 4662-Signale, neue ACEs auf dem Domain Root und Produktkonten mit Replikationsrechten noch einmal gezielt geprüft werden.

Referenzen

• Microsoft Learn: Event 4662
• Microsoft Learn: Active Directory ACL and access rights concepts
• Microsoft Learn: Get-Acl / Set-Acl usage in AD provider scenarios
• Microsoft Learn: Protected Accounts and Groups in Active Directory / AdminSDHolder
• SpecterOps BloodHound documentation for ACL path analysis

Verwandte Beiträge

• AD-Angriffspfade: Wie Fehlkonfigurationen bis Domain Admin führen
• Kerberoasting: Wie Angreifer Dienstkonto-Passwörter knacken
• GPO-Fehlkonfigurationen als Angriffsvektor
• AD Sicherheitsüberwachung: Event IDs und SIEM
• AD Gruppenverschachtelung: Versteckte DA-Pfade
• AD-Trust-Angriffe: Wie Unterdomänen das Gesamtstruktur-Risiko erhöhen

ACL-Missbrauch und DCSync sollte jedes AD-Team regelmäßig wie einen Tier-0-Pfad behandeln. Sobald Directory-Rechte nicht mehr zum tatsächlichen Betriebsmodell passen, wird aus einer unsichtbaren ACE sehr schnell ein privilegierter Angriffsweg.