Active Directory ACL DPAPI Tombstone Schema Berechtigungsaudit: 3 Rechte, die niemand prüft

Was ist ein Active Directory ACL DPAPI Tombstone Schema Berechtigungsaudit?

Ein vollständiges Active Directory ACL DPAPI Tombstone Schema Berechtigungsaudit prüft weit mehr als GenericAll und DCSync. Ein typisches ACL-Audit – ob manuell mit dsacls und PowerView oder mit einem Tool wie BloodHound durchgeführt – konzentriert sich auf eine bekannte Kurzliste: GenericAll, GenericWrite, WriteDACL, WriteOwner und die Replikationsrechte hinter DCSync. Diese Kurzliste ist richtig, aber nicht vollständig. Drei weitere ACL-nahe Rechte sind ebenso gefährlich und schaffen es selten in eine Checkliste: nicht standardmäßiger Zugriff auf den DPAPI-Domänen-Backup-Key, das erweiterte Recht Reanimate-Tombstones sowie nicht standardmäßige Berechtigungen auf das AD-Schema. Sie sind aus demselben Grund gefährlich wie GenericAll – ein Prinzipal außerhalb der erwarteten Admin-Ebene kann sie nutzen, um Geheimnisse zu lesen, veraltete Objekte wiederzubeleben oder einen Persistenzmechanismus zu platzieren, der Objektlöschungen und Passwort-Resets überdauert – aber sie tauchen in den meisten Inhalten zu ACL-Missbrauch nicht auf, weil es sich nicht um gewöhnliche Objekt-ACEs auf Benutzer- oder Computerobjekten handelt. Dieser Artikel behandelt, was jedes Recht tatsächlich gewährt, wie es missbraucht wird und wie man es erkennt und behebt.

Für die häufiger auditierten Pfade siehe ACL-Missbrauch und DCSync: Wie stille Rechte Domain Admin öffnen.

Recht Nr. 1 — Nicht standardmäßiger Zugriff auf den DPAPI-Domänen-Backup-Key

Die Data Protection API (DPAPI) von Windows schützt ruhende Geheimnisse – gespeicherte Browser-Passwörter, WLAN-Profile, RDP-Zugangsdaten, EFS-Zertifikate, Credential-Manager-Einträge – indem sie diese mit einem vom Benutzerpasswort abgeleiteten Schlüssel verschlüsselt. In einer Domäne wird der DPAPI-Master-Key jedes Benutzers zusätzlich mit einem domänenweiten DPAPI-Backup-Key verschlüsselt, damit ein verlorenes oder abgelaufenes Benutzerpasswort nicht zu dauerhaftem Datenverlust führt. Dieser Backup-Key wird einmalig bei der Domänenerstellung generiert und als BCKUPKEY_*-LSA-Secrets auf jedem Domänencontroller repliziert gespeichert (Microsoft Learn: DPAPI backup keys on AD domain controllers).

Wie Angreifer den Backup-Key abrufen

Standardmäßig erfordert das Abrufen des Backup-Keys Domain-Admin-äquivalente Rechte über das LSA-Policy-Objekt. Tools wie Mimikatz (lsadump::backupkeys) und SharpDPAPI holen ihn über die MS-LSAD/LSARPC-Aufrufe LsaOpenPolicy / LsaRetrievePrivateData; DSInternals dokumentiert denselben Abrufpfad mit Get-LsaBackupKey (DSInternals: Retrieving DPAPI Backup Keys from Active Directory). Die Audit-Frage lautet nicht „existiert der Backup-Key" – das tut er immer –, sondern „welche Prinzipale außer Domain Admins besitzen derzeit Rechte, die ihnen das Lesen erlauben." Dieser Zugriff wird meist indirekt gewährt: delegierte LSA-Secret-Rechte, eine zu weit gefasste GPO oder ein Dienstkonto, das aus einem anderen Grund zu einer privilegierten Gruppe hinzugefügt wurde.

Recht Nr. 2 — Das erweiterte Recht Reanimate-Tombstones

Active Directory erweitert das Standard-ACE-Modell um Control Access Rights – Berechtigungen, die nicht an ein bestimmtes Attribut oder Bit in einer Zugriffsmaske gebunden sind, sondern über eine GUID identifiziert und gegen das gesamte Objekt geprüft werden. Reanimate-Tombstones (GUID 45ec5156-db7e-47bb-b53f-dbeb2d03c40f) ist eines davon: Es erlaubt seinem Inhaber, ein gelöschtes (tombstoned) Objekt überall in einem Naming Context wiederherzustellen, und wird standardmäßig nur an der Naming-Context-Wurzel an Domain Admins / Enterprise Admins vergeben (Microsoft: Reanimate-Tombstones extended right, Microsoft: Restoring Deleted Objects).

Warum eine delegierte Vergabe ein Weg zur Rechteausweitung ist

Der Missbrauchsfall ist subtil, aber real: Ein tombstoned oder recycled Objekt kann die meisten seiner ursprünglichen Attribute – SID-History, Gruppenmitgliedschaften, SPNs – für die Dauer des Tombstone-Lebenszyklus behalten (oder unbegrenzt im Recycle Bin, falls dieser aktiviert, aber nicht geleert ist). Ein Prinzipal, dem Reanimate-Tombstones außerhalb der Standard-Admin-Ebene delegiert wurde, kann ein gelöschtes privilegiertes Konto oder eine Gruppe wiederherstellen und damit faktisch einen Zugriffspfad reanimieren, der als geschlossen galt. Die Recherche von CravateRouge zum AD Recycle Bin als Angriffsfläche für Rechteausweitung dokumentiert dafür konkrete Szenarien (Have You Looked in the Trash? Unearthing Privilege Escalations from the AD Recycle Bin). Das Recht wird leicht übersehen, gerade weil Auditoren aktuelle Objekt-ACLs betrachten und vergessen, an der Partitionswurzel delegierte erweiterte Rechte zu prüfen – genau dort befindet sich dieses. Mehr dazu, wie sich diese Art delegierter Zugriff mit der Zeit ansammelt, siehe Privilegierter Zugriff Drift Active Directory: Warum Adminrechte nach Audits zurückkehren.

Recht Nr. 3 — Nicht standardmäßige Berechtigungen auf das AD-Schema

Der Schema-Naming-Context definiert jede Klasse und jedes Attribut im Forest. Standardmäßig ist der Schreibzugriff darauf auf die Gruppe Schema Admins beschränkt (plus Enterprise Admins an der Forest-Root); das ist beabsichtigt, weil Schema-Änderungen forest-weit und weitgehend irreversibel sind – Attribute und Klassen können deaktiviert, aber nicht gelöscht werden (Semperis: NSA Top Ten Cybersecurity Misconfigurations — An AD Perspective).

Warum Schema-Schreibzugriff ein forest-weites Persistenz-Primitiv ist

Schreibzugriff auf das Schema ist ein größerer Gewinn, als es scheint. Ein Attribut insbesondere, defaultSecurityDescriptor auf einem classSchema-Objekt, definiert die DACL-Vorlage, die auf jedes künftig erstellte Objekt dieser Klasse angewendet wird – das heißt, ein Angreifer mit Schema-Schreibzugriff kann eine Backdoor-ACE (zum Beispiel WriteDACL für ein niedrig privilegiertes Konto) in den Default Security Descriptor der Klasse user oder group einbetten, sodass jedes danach erstellte Konto oder jede Gruppe ab dem Moment der Erstellung angreiferkontrollierte Berechtigungen erbt. Dies ist ein gut dokumentiertes Persistenz-Primitiv und überschreitet zudem Domänengrenzen innerhalb eines Forests, da das Schema forest-weit gilt (itm8: Schema change trust attack — from child to parent), (BorderGate: Active Directory Schema Modification Attacks). In der Praxis sind nicht standardmäßige Schema-ACEs meist Überbleibsel von Drittanbieter-Produktinstallationen (Exchange, bestimmte Backup-/AD-Management-Tools), die während der Einrichtung breitere als nötige Schema-Rechte angefordert haben und nie zurückgenommen wurden.

Erkennung

Alle drei Rechte benötigen die richtigen Audit-Policy-Subkategorien, die auf Domänencontrollern aktiviert sein müssen, bevor sie irgendetwas Nützliches im Security-Event-Log erzeugen.

Für das Event-4662-Auditing des Backup-Keys muss Success-Auditing für Audit Other Object Access Events auf jedem DC aktiviert sein – standardmäßig ist es deaktiviert (DSInternals: Detecting DPAPI Backup Key Theft). Die Subkategorie Directory Service Changes erzeugt 5136 (geändert), 5137 (erstellt), 5138 (wiederhergestellt), 5139 (verschoben) und 5141 (gelöscht) für jedes Objekt mit einem passenden SACL-Eintrag (Microsoft: Event 5136 — A directory service object was modified) – aber nur für Objekte und Attribute, auf denen Sie explizit eine SACL gesetzt haben. Deshalb müssen sowohl die Naming-Context-Root als auch der Schema-Container manuell eine erhalten (ADSI Edit → Properties → Security → Advanced → Auditing).

Weitere Event-IDs, die es sich lohnt, zusätzlich zu diesen drei einzurichten, werden in AD Sicherheitsüberwachung: Event IDs und SIEM behandelt.

Behebung

DPAPI-Backup-Key-Exposition beheben

Es gibt keine unterstützte Möglichkeit, den Domänen-Backup-Key zu rotieren (Microsoft Learn: DPAPI backup keys on AD domain controllers), behandeln Sie den Zugriff darauf daher genauso streng wie krbtgt. Prüfen Sie regelmäßig delegierte LSA-Secret-Rechte und die Mitgliedschaft in privilegierten Gruppen; falls der Key nachweislich kompromittiert wurde, ist Microsofts eigene Recovery-Anleitung begrenzt genug, dass bereits vor dem Ernstfall ein vollständiger Forest-/Domain-Recovery-Plan existieren sollte (SANS: Critical Confusion — Microsoft's Domain Compromise Recovery Guidance).

Reanimate-Tombstones-Delegation beheben

Ermitteln Sie die ACEs an jeder Naming-Context-Root für die Control-Access-Right-GUID 45ec5156-db7e-47bb-b53f-dbeb2d03c40f (dsacls oder PowerViews Get-ObjectAcl -ResolveGUIDs). Entfernen Sie jede Vergabe außerhalb von Domain Admins/Enterprise Admins und verlangen Sie für legitime delegierte Wiederherstellungen ein dokumentiertes Change-Ticket.

Nicht standardmäßige Schema-Berechtigungen beheben

Führen Sie dsacls gegen CN=Schema,CN=Configuration,DC=<forest-root> aus und bestätigen Sie, dass der Schreibzugriff auf Schema Admins (und Enterprise Admins an der Forest-Root) beschränkt ist. Achten Sie besonders auf jede ACE, die defaultSecurityDescriptor auf classSchema-Objekten von user, group oder computer betrifft – das ist das wertvollste Ziel für eine Persistenz-Backdoor.

SACLs für künftige Drift-Erkennung hinzufügen

Fügen Sie SACLs an der Naming-Context-Root und am Schema-Container hinzu, wie oben unter Erkennung beschrieben, damit künftiger Drift im Security-Log erscheint, statt erst beim nächsten manuellen Audit entdeckt zu werden. Für eine breitere Hardening-Baseline über diese drei Rechte hinaus siehe Active Directory härten: Was Sie zuerst absichern und wie Sie es validieren und Welche Sicherheitsfehlkonfigurationen in Active Directory sind am häufigsten?.

Wie EtcSec dies erkennt

EtcSec prüft alle drei bei jedem Active-Directory-Audit: DPAPI_KEY_NON_DEFAULT_ACCESS markiert Prinzipale, die Rechte über den Domänen-Backup-Key außerhalb der erwarteten Admin-Ebene besitzen, REANIMATE_TOMBSTONES_RIGHT markiert nicht standardmäßige Vergaben des Control-Access-Rechts an der Naming-Context-Root, und SCHEMA_NON_STANDARD_PERMISSIONS markiert ACEs auf dem Schema-Naming-Context außerhalb von Schema Admins/Enterprise Admins. Diese stehen neben der bekannteren ACL_GENERICALL-Prüfung, sodass derselbe Audit-Durchlauf sowohl die bekannten ACL-Missbrauchspfade als auch die von den meisten Tools übersehenen abdeckt. Zusammengenommen machen erst DPAPI-, Tombstone- und Schema-Prüfungen ein Active-Directory-ACL-Audit wirklich vollständig.