Active-Directory-ACLs prüfen, bevor es ein Angreifer tut

Gruppenrichtlinienhärtung und Patchen bekommen die meiste Aufmerksamkeit, doch ein großer Teil der realen Active-Directory-Kompromittierungen berührt nie eine CVE – er missbraucht Berechtigungen, die vergeben, vererbt oder vergessen wurden. Ein überberechtigtes Dienstkonto, eine veraltete Delegierung aus einem stillgelegten Helpdesk-Tool oder ein DCSync-fähiger Dienstprinzipal kann einem Angreifer die Kontrolle über die Domäne verschaffen, ganz ohne Exploit. Dieser Leitfaden zeigt, wie Sie diese Pfade finden und schließen, bevor es jemand anderes tut.

Die wichtigsten ACLs

Active-Directory-Objekte tragen wie Dateien benutzerdefinierte Zugriffssteuerungslisten (DACLs), doch die sicherheitsrelevanten Rechte sind eine kleine, gut bekannte Menge:

Jedes der ersten vier Rechte auf einer Gruppe wie Domain Admins oder auf dem Objekt AdminSDHolder selbst entspricht einer vollständigen Domänenkompromittierung. Die Replikationsrechte sind gerade deshalb gefährlich, weil sie selten geprüft werden – die meisten Admins denken nur an Gruppenmitgliedschaften, nicht an Replikationsberechtigungen auf dem Domänenobjekt.

ACLs mit PowerShell prüfen

Beginnen Sie mit dem Stammobjekt der Domäne selbst, denn dort liegen die DCSync-Rechte:

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

$acl.Access | Where-Object {
    $_.ActiveDirectoryRights -match "ExtendedRight" -and
    ($_.ObjectType -eq "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" -or  # DS-Replication-Get-Changes
     $_.ObjectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2")     # DS-Replication-Get-Changes-All
} | Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

Diese beiden GUIDs sind nicht der einzige Weg zu DCSync: GenericAll, AllExtendedRights (ein ExtendedRight-ACE mit leerem ObjectType) und WriteDACL auf dem Domänenstamm gewähren dieselben Rechte oder erlauben es dem Inhaber, sie sich selbst zu gewähren. Die Prüfung der DCSync-Rechte enthält die vollständige Abfrage und die standardmäßig erwarteten Inhaber.

Durchsuchen Sie dann hochwertige OUs (Domain Controllers, Tier-0-Admin-OU, privilegierte Gruppen) nach gefährlichen Rechten:

$targets = @("OU=Domain Controllers,DC=corp,DC=example,DC=com",
             "CN=Domain Admins,CN=Users,DC=corp,DC=example,DC=com")

foreach ($dn in $targets) {
    Write-Host "== $dn ==" -ForegroundColor Cyan
    (Get-Acl -Path "AD:\$dn").Access |
        Where-Object { $_.ActiveDirectoryRights -match "GenericAll|GenericWrite|WriteDacl|WriteOwner" } |
        Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType
}

Gleichen Sie jede zurückgegebene IdentityReference mit einer bekannten, einwandfreien Liste integrierter Prinzipale ab (SYSTEM, Enterprise Admins, Domain Admins, Administrators). Alles andere braucht eine dokumentierte geschäftliche Begründung.

AdminSDHolder, SDProp und adminCount

Active Directory schützt eine feste Menge privilegierter Gruppen (Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators und einige weitere) mit einem Mechanismus namens SDProp (SD Propagation). Alle 60 Minuten führt der Prozess Folgendes aus:

1. Er liest die ACL des speziellen Objekts AdminSDHolder.
2. Er wendet diese ACL auf jedes aktuelle Mitglied einer geschützten Gruppe an und überschreibt dabei alle direkt an diesen Konten vorgenommenen ACL-Anpassungen.
3. Er setzt adminCount=1 für jedes geschützte Mitglied und entfernt diesen Wert nicht automatisch, wenn das Konto die geschützte Gruppe verlässt.

Deshalb werden Berechtigungsänderungen, die Sie direkt am Benutzerobjekt eines Domänen-Admins vornehmen, immer wieder zurückgesetzt – SDProp überschreibt sie beim nächsten Durchlauf. Und deshalb wird adminCount=1 zu einem dauerhaften, wenn auch unvollkommenen Merkmal für „dieses Konto war irgendwann privilegiert“.

Um die wirksamen Berechtigungen geschützter Konten zu ändern, bearbeiten Sie die ACL von AdminSDHolder selbst (mit Vorsicht – sie wird auf alle übertragen), nicht die einzelner Konten.

$adminSDHolderDN = "CN=AdminSDHolder,CN=System," + (Get-ADDomain).DistinguishedName
(Get-Acl -Path "AD:\$adminSDHolderDN").Access |
    Where-Object { $_.ActiveDirectoryRights -match "GenericAll|WriteDacl|WriteOwner" } |
    Select-Object IdentityReference, ActiveDirectoryRights

Veraltete Objekte mit adminCount=1 finden und bereinigen

Konten, die aus privilegierten Gruppen entfernt wurden, behalten adminCount=1 und – entscheidend – eine ACL mit deaktivierter Vererbung. Sie erhalten also keine Berechtigungsänderungen auf OU-Ebene mehr, und ihre letzte privilegierte ACL bleibt auf unbestimmte Zeit erhalten. Das ist ein häufiger „Schatten-Admin“-Pfad: ein Konto, das nach Gruppenmitgliedschaft unauffällig aussieht, aber noch privilegierte ACL-Einträge trägt.

# Benutzer mit adminCount=1 finden, die aktuell NICHT Mitglied geschützter Gruppen sind
$protectedMembers = @()
foreach ($g in "Domain Admins","Enterprise Admins","Schema Admins","Administrators","Account Operators","Backup Operators") {
    $protectedMembers += (Get-ADGroupMember -Identity $g -Recursive -ErrorAction SilentlyContinue).SamAccountName
}

Get-ADUser -Filter "adminCount -eq 1" -Properties adminCount, whenChanged |
    Where-Object { $_.SamAccountName -notin $protectedMembers } |
    Select-Object SamAccountName, DistinguishedName, whenChanged

Für jeden veralteten Treffer: Bestätigen Sie, dass das Konto tatsächlich keine erhöhten Rechte mehr benötigt, aktivieren Sie dann die ACL-Vererbung wieder und lassen Sie es erneut von seiner OU erben:

$obj = Get-ADUser -Identity "svc_legacybackup"
$acl = Get-Acl -Path "AD:\$($obj.DistinguishedName)"
$acl.SetAccessRuleProtection($false, $true)  # Schutz aufheben, vom übergeordneten Objekt erben
Set-Acl -Path "AD:\$($obj.DistinguishedName)" -AclObject $acl
Set-ADUser -Identity "svc_legacybackup" -Clear adminCount

Gehen Sie dabei in Tranchen mit Änderungsprüfung vor – wer adminCount bei einem Konto löscht, das weiterhin legitim privilegiert ist (nur über eine verschachtelte Gruppenmitgliedschaft, die SDProp nicht sauber erfasst hat), entzieht ihm Schutzmechanismen, die es noch braucht.

BloodHound und PingCastle zur Verteidigung nutzen

Manuelle ACL-Prüfungen skalieren ab einigen Tausend Objekten schlecht. Für Angreifer gebaute Bewertungswerkzeuge funktionieren genauso gut, wenn man sie nach innen richtet:

• BloodHound liest AD-ACLs, Gruppenmitgliedschaften, Sitzungsdaten und GPO-Verknüpfungen ein und stellt Angriffspfade als Graph dar („kürzester Pfad zu Domain Admins“). Betreiben Sie es nur lesend mit einem dedizierten Erfassungskonto ohne Schreibrechte und behandeln Sie die Ausgabe als internes Audit-Artefakt, das nicht herumliegen darf – der Graph selbst ist eine Zielkarte.
• PingCastle erzeugt einen bewerteten Zustandsbericht zu veralteten Objekten, ACL-Fehlkonfigurationen, Risiken bei Vertrauensstellungen und AdminSDHolder-Anomalien, mit einem Trendwert, den Sie von Version zu Version verfolgen können.

Führen Sie diese Werkzeuge regelmäßig aus (monatlich ist für die meisten Umgebungen angemessen), bewahren Sie historische Berichte auf und verfolgen Sie die Anzahl „kritischer“ Funde als Kennzahl – nicht nur als einmalige Aufräumaktion.

Überprüfung

Führen Sie nach der Behebung eines Fundes genau die Abfrage erneut aus, die ihn gefunden hat, und bestätigen Sie ein sauberes Ergebnis:

# DCSync-äquivalente Rechte (Replikations-GUIDs, AllExtendedRights, GenericAll, WriteDACL) nach der Behebung erneut prüfen
$domain   = Get-ADDomain
$rootSid  = (Get-ADDomain (Get-ADForest).RootDomain).DomainSID.Value
$expected = @(
    'S-1-5-18',                        # SYSTEM
    'S-1-5-9',                         # Enterprise Domain Controllers
    'S-1-5-32-544',                    # Administrators (built-in)
    "$($domain.DomainSID.Value)-516",  # Domain Controllers
    "$($domain.DomainSID.Value)-512",  # Domain Admins (default WriteDACL)
    "$rootSid-519",                    # Enterprise Admins (default GenericAll)
    "$rootSid-498"                     # Enterprise Read-only Domain Controllers (Get-Changes only)
)
$repl = @([guid]'1131f6aa-9c07-11d1-f79f-00c04fc2dcd2', [guid]'1131f6ad-9c07-11d1-f79f-00c04fc2dcd2')
$acl  = Get-Acl -Path "AD:\$($domain.DistinguishedName)"
$acl.GetAccessRules($true, $true, [System.Security.Principal.SecurityIdentifier]) | Where-Object {
    $r = $_.ActiveDirectoryRights
    $_.AccessControlType -eq 'Allow' -and
    -not $_.PropagationFlags.HasFlag([System.Security.AccessControl.PropagationFlags]::InheritOnly) -and
    $_.IdentityReference.Value -notin $expected -and (
        $r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::GenericAll) -or
        $r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::WriteDacl) -or
        ($r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::ExtendedRight) -and
         ($_.ObjectType -in $repl -or $_.ObjectType -eq [guid]::Empty))
    )
}
# Keine Ausgabe erwartet, abgesehen von dokumentierten Ausnahmen wie dem AD-DS-Connector-Konto von Entra Connect

Was dabei kaputtgeht

• Legitime delegierte Verwaltung. Helpdesk-Gruppen, die Kennwörter in einer bestimmten OU zurücksetzen dürfen, Anwendungsteams, die ihre eigenen Dienstkonten verwalten, und Backup-Software, die replikationsnahe Rechte benötigt, können alle als „Fund“ auftauchen. Wer diese ohne Prüfung entfernt, legt reale Arbeitsabläufe lahm – stimmen Sie sich vor dem Entzug mit einem Änderungsverantwortlichen ab.
• AD-integrierte Drittanbieter-Tools (Backup, Identity Governance, PAM-Lösungen) benötigen mitunter konstruktionsbedingt weitreichende Rechte; prüfen Sie die Herstellerdokumentation, bevor Sie ihrem Dienstkonto Berechtigungen entziehen.
• Automatisierung, die sich auf das Löschen von adminCount verlässt – erwartet ein Skript oder Provisioning-Tool, dass adminCount die aktuelle Gruppenmitgliedschaft in Echtzeit widerspiegelt, muss es den einstündigen SDProp-Zyklus und das fehlende automatische Löschen berücksichtigen.

Kombinieren Sie dieses Audit mit den in Tier 0 & privilegierter Zugriff beschriebenen Identitätsgrenzen und wiederholen Sie es jedes Mal, wenn Sie ein delegiertes Admin-Tool oder einen Helpdesk-Ablauf außer Betrieb nehmen – das sind die häufigsten Quellen verwaister ACL-Berechtigungen.