AdminSDHolder SDProp Active Directory Hintertür: Der stündliche Prozess für dauerhaften privilegierten Zugriff

Was sind AdminSDHolder und SDProp?

AdminSDHolder SDProp Active Directory verbirgt eine Hintertür-Technik für dauerhaften privilegierten Zugriff: Dieser Leitfaden schlüsselt vollständig auf, wie Angreifer sie einrichten, wie Verteidiger sie erkennen und wie sie sich beheben lässt, bevor sie zu einem dauerhaften Risiko wird. AdminSDHolder ist ein Container-Objekt, das in jeder AD-Domäne unter CN=AdminSDHolder,CN=System,DC=<domain>,DC=<tld> liegt, und SDProp — der Security Descriptor Propagator — ist der Hintergrundprozess, der dessen ACL standardmäßig einmal pro Stunde auf jedes geschützte Objekt kopiert (Microsoft Learn — Appendix C: Protected Accounts and Groups in Active Directory).

SDProp läuft standardmäßig alle 60 Minuten auf dem Domänencontroller, der die PDC-Emulator-Rolle (PDCE) innehat. Der Prozess vergleicht die Berechtigungen von AdminSDHolder mit denen der geschützten Konten und Gruppen der Domäne — und überschreibt bei Abweichungen die ACL des Objekts, sodass sie exakt der von AdminSDHolder entspricht. Das Intervall wird über den DWORD-Wert AdminSDProtectFrequency unter HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters auf dem PDCE gesteuert, gültig von 60 bis 7200 Sekunden; die meisten Umgebungen ändern ihn nie und laufen einfach mit dem 60-Minuten-Standardwert.

Die folgenden integrierten Gruppen und Konten werden in jeder AD-Domäne durch AdminSDHolder/SDProp geschützt:

Zwei Nebeneffekte kennzeichnen jedes geschützte Objekt: Das Attribut adminCount wird auf 1 gesetzt, und die ACL-Vererbung von der übergeordneten OU wird dauerhaft deaktiviert — bis sie explizit wieder aktiviert wird. Microsoft hat SDProp so konzipiert, dass privilegierte Konten nicht stillschweigend schwächere Berechtigungen erben, falls sie im Verzeichnis verschoben werden. Es ist derselbe zugrunde liegende Mechanismus, den Angreifer bereits für ACL-Missbrauch und DCSync auf einzelnen Objekten ausnutzen — diese Hintertür verlagert den Missbrauch nur eine Ebene höher, auf das Vorlagenobjekt, das jedes geschützte Konto gleichzeitig versorgt.

AdminSDHolder SDProp Active Directory Hintertür, Schritt für Schritt

Die Technik ist nicht neu — Sean Metcalf dokumentierte sie 2015 — und funktioniert heute noch exakt so wie beschrieben, weil sie einen beabsichtigten Mechanismus missbraucht und keinen Bug (AD Security — Sneaky Active Directory Persistence #15). Anders als andere AD-Angriffspfade, die mehrere Fehlkonfigurationen verketten, um Domain Admin zu erreichen, braucht diese Technik nur einen einzigen Schreibzugriff auf ein einziges Objekt.

Schritt 1 — Eine bösartige ACE zu AdminSDHolder hinzufügen

Ein Angreifer, der bereits Schreibrechte auf CN=AdminSDHolder,CN=System,DC=... besitzt — typischerweise weil er Domain Admin/Enterprise Admin ist oder sich WriteDacl/GenericWrite dort durch vorherigen ACL-Missbrauch verschafft hat —, gewährt einem niedrig privilegierten oder Wegwerf-Konto direkt auf dem AdminSDHolder-Objekt Full Control (oder GenericAll). In Metcalfs ursprünglichem Beitrag erhält ein gewöhnliches Benutzerkonto die volle Kontrolle über AdminSDHolder selbst. An diesem Konto ändert sich äußerlich nichts — es ist weiterhin kein Mitglied einer privilegierten Gruppe und fällt bei einer routinemäßigen Prüfung der Gruppenmitgliedschaften nicht auf.

Schritt 2 — Auf die Verbreitung durch SDProp warten (oder sie erzwingen)

Im nächsten Zyklus — bis zu 60 Minuten später — kopiert SDProp die ACL von AdminSDHolder inklusive der bösartigen ACE auf jedes Konto und jede Gruppe mit adminCount=1: Domain Admins, Enterprise Admins, das Benutzerobjekt jedes bestehenden Mitglieds sowie jedes Konto, das diesen Gruppen später hinzugefügt wird. Das Wegwerf-Konto muss dabei nie Mitglied der Domain Admins werden; es braucht lediglich Änderungsrechte auf den relevanten Objekten. Der Zyklus lässt sich auch sofort erzwingen — von einem Administrator, der eine Änderung testet, oder von einem Angreifer, der ungeduldig bestätigen will, dass die Hintertür gegriffen hat — über Ldp.exe, indem das Attribut RunProtectAdminGroupsTask auf der rootDSE auf 1 gesetzt wird (Microsoft Learn — Appendix C).

Schritt 3 — Rechte weiter nutzen, die nie als Gruppenmitgliedschaft sichtbar werden

Da die ACE auf dem Vorlagenobjekt liegt und nicht auf einem einzelnen Konto, kehrt sie bei jedem SDProp-Lauf zurück — selbst nachdem ein Verteidiger die bösartige Berechtigung auf dem Benutzerobjekt eines Domain Admins entdeckt und dort entfernt hat. Solange die Korrektur nicht an AdminSDHolder selbst vorgenommen wird, stellt der nächste SDProp-Zyklus sie überall stillschweigend wieder her. Genau das macht daraus Persistenz statt einer einmaligen Rechteausweitung: Passwortwechsel, das Deaktivieren von Konten oder das Entfernen des Angreiferkontos aus den Domain Admins bewirken nichts, weil das Konto nie Mitglied war — die Rechte wurden über die ACL-Vorlage vergeben. Das unterscheidet die Technik auch von gewöhnlicher gefährlicher Gruppenverschachtelung: Verschachtelung versteckt sich in der Gruppenmitgliedschaft, diese Technik versteckt sich in einer einzelnen ACL, die kaum ein Administrator routinemäßig prüft.

Verteidiger können mögliche Ziele und Überbleibsel dieser Technik mit einer einzigen LDAP-Abfrage inventarisieren:

Get-ADObject -LDAPFilter "(&(admincount=1)(|(objectcategory=person)(objectcategory=group)))" -Properties MemberOf,Created,Modified,AdminCount

Jedes Ergebnis, dessen MemberOf keine geschützte Gruppe mehr enthält oder dessen effektive Berechtigungen nicht zur tatsächlichen Rolle passen, sollte näher untersucht werden, bevor man es als legitimen Aufräumrückstand abtut.

Erkennung

Der Mechanismus betrifft nur ein einziges Objekt, weshalb die Erkennung eng gefasst, aber zuverlässig ist — vorausgesetzt, die richtige Audit-Richtlinie und SACL sind bereits vorhanden.

Zwei Voraussetzungen müssen erfüllt sein, bevor Event 5136 überhaupt ausgelöst wird: Die Unterkategorie Advanced Audit Policy → DS Access → Audit Directory Service Changes muss aktiviert sein, und auf dem AdminSDHolder-Objekt selbst muss eine SACL vorhanden sein, die den Security Descriptor (bzw. „Write All Properties“) abdeckt. In den meisten Umgebungen ist standardmäßig keines von beidem aktiv. Elastics veröffentlichte Erkennungsregel für genau diese Technik setzt beide Konfigurationen voraus, bevor sie auslösen kann — ihre Abfrage lautet event.code:5136 and host.os.type:"windows" and winlog.event_data.ObjectDN:CN=AdminSDHolder,CN=System*, zugeordnet zu MITRE ATT&CK T1098 (Account Manipulation) und T1078.002 (Valid Accounts: Domain Accounts), eingestuft als High Severity (Elastic — AdminSDHolder Backdoor detection rule). Splunks entsprechende Security-Content-Regel bestätigt dieselbe 5136/nTSecurityDescriptor-Logik und dieselbe SACL-Voraussetzung (Splunk Security Content — Windows AD AdminSDHolder ACL Modified).

Die ACL direkt prüfen

Ereignisprotokolle helfen erst, wenn das Auditing aktiviert ist — eine punktuelle ACL-Prüfung funktioniert unabhängig von der Audit-Richtlinie und ist ein sinnvoller erster Schritt in einer Umgebung, in der Directory Service Changes-Auditing noch nie aktiviert wurde:

Get-Acl -Path "AD:\CN=AdminSDHolder,CN=System,DC=corp,DC=local" | Select-Object -ExpandProperty Access

Vergleichen Sie jeden Eintrag in der Ausgabe mit der bekannten Baseline im Remediation-Abschnitt weiter unten. Alles, was kein bekannter integrierter Principal ist, sollte sofort eskaliert werden — unabhängig davon, ob das Logging bereits eingerichtet ist.

Remediation

Sofortmaßnahmen

1. Prüfen Sie jetzt die ACL von AdminSDHolder. Vergleichen Sie deren Trustees mit einer bekannten Baseline (Domain Admins, Enterprise Admins, Administrators, SYSTEM sowie ausdrücklich delegierte Dienstkonten) und entfernen Sie alles Unerwartete — wie Metcalf es formulierte: „these should be kept at the default“ (sie sollten beim Standard bleiben).
2. Erzwingen Sie nach der Behebung sofort einen erneuten SDProp-Lauf über Ldp.exe → RunProtectAdminGroupsTask=1 auf der rootDSE, anstatt bis zu 60 Minuten zu warten, um die Verbreitung der Korrektur zu bestätigen (Microsoft Learn — Appendix C).

Dauerhafte Härtung

3. Aktivieren Sie Directory Service Changes-Auditing und setzen Sie eine SACL auf AdminSDHolder, damit künftige Änderungen Event 5136 auslösen, wie im Erkennungsabschnitt oben beschrieben.
4. Inventarisieren Sie jedes Objekt mit adminCount=1 mit der zuvor gezeigten LDAP-Abfrage und gleichen Sie es mit der aktuellen Mitgliedschaft in geschützten Gruppen ab. Setzen Sie adminCount bei Konten, die nachweislich nicht mehr zu einer geschützten Gruppe gehören, zurück und aktivieren Sie die Vererbung erst wieder, nachdem Sie bestätigt haben, dass die Gruppenmitgliedschaft bereits entfernt ist — wird adminCount zuerst zurückgesetzt, macht SDProp die Korrektur im nächsten Lauf wieder rückgängig. Diese verwaisten Konten sind derselbe Aufräumrückstand, der in Veraltete privilegierte Konten behandelt wird.
5. Beschränken Sie, wer auf AdminSDHolder schreiben darf. Standardmäßig können nur Domain Admins, Enterprise Admins und Administrators es ändern oder die Eigentümerschaft übernehmen — belassen Sie es dabei. Jedes GenericWrite oder WriteDacl, das auf dem System-Container oder speziell auf AdminSDHolder delegiert ist, stellt ein dauerhaftes Risiko dar und sollte als Tier 0 behandelt werden.

Wie EtcSec dies erkennt

Das Active-Directory-Audit von EtcSec prüft mit ADMIN_SD_HOLDER_MODIFIED auf unerwartete Trustees oder gefährliche Rechte (Full Control, GenericAll, WriteDacl, WriteOwner) auf der ACL des AdminSDHolder-Objekts, mit ADMINSDHOLDER_BACKDOOR auf das spezifische Muster eines nicht privilegierten Principals mit diesen Rechten und mit ADMIN_COUNT_ORPHANED auf Konten, die nach dem Verlassen einer geschützten Gruppe weiterhin als adminCount=1 markiert sind — ein Aufräumrückstand, der sowohl echte Hintertüren verdeckt als auch die Zahl der privilegierten Konten künstlich erhöht. Diese Hintertür tritt selten allein auf: Sie findet sich häufig zusammen mit umfassenderer privilegierter Zugriffsdrift, weshalb sich beide Prüfungen im Rahmen eines Routine-Audits gemeinsam lohnen, statt sie als getrennte Einzelfunde zu behandeln.