AD-ACL-Missbrauch erkennen: GenericAll, WriteDACL und WriteOwner

Die meisten Erkennungen in Active Directory sehen eine Anmeldung, einen Prozess oder ein Ticket. AD-ACL-Missbrauch erkennen sieht etwas Stilleres: die Änderung an einer Zugriffskontrollliste. Wer die DACL eines Objekts schreiben darf, braucht kein weiteres Exploit und kein Passwort, sondern trägt sich selbst oder ein unauffälliges Konto als Berechtigten ein und holt sich das Zielobjekt damit vollständig. Genau das machen die Angriffspfade sichtbar, die Werkzeuge wie BloodHound als Kanten zeichnen: GenericAll auf eine Gruppe, WriteDACL auf ein Dienstkonto, WriteOwner auf eine OU. Dieser Beitrag beschreibt, wie sich diese missbräuchlichen Berechtigungsänderungen von legitimer Delegation unterscheiden lassen, welche Windows-Ereignisse sie zeigen, wie der Sicherheitsdeskriptor im Log zu lesen ist, warum GenericAll und GenericWrite nicht als Klartext im Ereignis stehen, vier Sigma-Regeln, die Blindspots, die Härtung, den Lab-Test und die Checkliste. Er grenzt sich bewusst von den Nachbarthemen ab: Es geht nicht um die Replikationsrechte (das ist DCSync), nicht um AdminSDHolder und SID-History (das sind AD-Hintertüren) und nicht um die Delegations-Attribute msDS-AllowedToActOnBehalfOfOtherIdentity und msDS-KeyCredentialLink (das sind RBCD und Shadow Credentials), sondern um die allgemeine Erkennung missbräuchlicher Änderungen an Objektberechtigungen.

Was der Angreifer tut

Jedes Objekt in Active Directory trägt einen Sicherheitsdeskriptor, und darin eine DACL: eine Liste von Einträgen (ACEs), die sagen, welches Konto welches Recht auf das Objekt hat. Wer auf dieser DACL das Recht hat, sie zu schreiben, kann sie beliebig umbauen. Der Angriff besteht nicht darin, ein Recht auszunutzen, das schon da ist, sondern ein neues einzutragen: einem kontrollierten Konto GenericAll (Vollzugriff), GenericWrite (fast alle Attribute schreiben), WriteDACL (die Berechtigungsliste selbst ändern) oder WriteOwner (Besitz übernehmen, dann die DACL schreiben) auf ein Zielobjekt geben. Danach steht dem Konto der volle Zugriff auf das Ziel offen, ohne dass je ein Exploit lief.

Was mit so einem Recht möglich wird, hängt vom Ziel ab. GenericAll oder WriteDACL auf ein Benutzerkonto erlaubt ein Passwort-Reset (ForceChangePassword) oder das Setzen von msDS-KeyCredentialLink, also Shadow Credentials. Auf ein Computerkonto kommt zusätzlich Resource-Based Constrained Delegation ins Spiel. GenericWrite oder GenericAll auf eine privilegierte Gruppe wie Domain Admins erlaubt, sich selbst als Mitglied einzutragen (AddMember). WriteDACL oder GenericAll auf die Domänenwurzel erlaubt, sich selbst die Replikationsrechte zu geben und per DCSync alle Hashes zu holen. WriteOwner auf ein beliebiges Objekt erlaubt, zuerst Owner zu werden und als Owner die DACL neu zu schreiben. Diese Rechte sind oft nicht direkt vergeben, sondern das Ergebnis einer Kette: ein Recht auf eine OU vererbt sich auf alle Objekte darin, ein Recht auf eine Gruppe wirkt über die Mitgliedschaft. Der gemeinsame Nenner aller Fälle ist die Änderung des Sicherheitsdeskriptors, und genau die ist das Erkennungsziel.

Der schwierige Teil ist nicht, die Änderung zu sehen, sondern die missbräuchliche von der legitimen zu trennen. Delegation ist in jeder gewachsenen Domäne Alltag: Ein Helpdesk darf Passwörter in einer OU zurücksetzen, ein Provisioning-System legt Konten an und setzt Rechte, Exchange und Entra Connect tragen beim Setup ganze Blöcke von ACEs ein. Eine Erkennung, die jede Berechtigungsänderung meldet, ertrinkt am ersten Tag. Die Kunst liegt im Kontext: welches Objekt, welcher Principal, welches neu gewährte Recht, in welchem Änderungsfenster, und was danach geschah.

BloodHound: Angriffspfad, beobachtbare Änderung, Erkennung

Weil dieses Thema eng mit BloodHound verbunden ist, lohnt sich eine saubere Trennung von drei Ebenen, die oft durcheinandergeraten:

• Der Angriffs- oder Graph-Pfad. BloodHound liest die ACLs der Domäne aus und zeichnet Kanten wie GenericAll, GenericWrite, WriteDacl, WriteOwner, DCSync, ForceChangePassword, AddMember oder AllowedToAct. Eine solche Kante sagt: Dieses Konto könnte diesen Weg gehen. Sie ist eine Momentaufnahme der Möglichkeiten, keine Aussage darüber, dass etwas passiert ist.
• Die beobachtbare Änderung im AD. Wenn ein Angreifer eine solche Kante erst erzeugt, also ein Recht neu vergibt, entsteht ein Ereignis: Event 5136, Änderung des Attributs nTSecurityDescriptor am Zielobjekt. Das ist die tatsächliche, zeitpunktgenaue Spur. War die Kante schon immer da (eine Altlast oder eine fehlerhafte Delegation), gibt es kein Ereignis, nur den Graph-Befund.
• Die Erkennung im SIEM oder EDR. Die Sigma-Regeln unten setzen auf der beobachtbaren Änderung an, nicht auf dem Graphen. Sie melden, dass eine ACL geändert wurde, und liefern den Kontext für die Entscheidung.

Daraus folgt die wichtigste Regel im Umgang mit beiden Werkzeugen: Eine BloodHound-Kante ist kein Incident. Sie ist ein Expositionsbefund, der in die Härtung gehört (das Recht prüfen und, wenn unnötig, entfernen), nicht in die Alarmierung. Umgekehrt ist ein 5136 auf einem privilegierten Objekt ein Ereignis, das untersucht werden muss, auch wenn BloodHound die Kante noch gar nicht kennt. BloodHound und Purple Knight sind hier Analyse- und Expositionsquellen; die Detection kommt aus dem Ereignislog. Mehr zur Enumeration selbst steht unter BloodHound und SharpHound erkennen.

Welche Logquellen die Technik zeigen

Voraussetzungen. Wie bei DCSync entsteht die Spur nur mit der richtigen Konfiguration. Für 5136 braucht es die Unterkategorie "Verzeichnisdienständerungen überwachen" (Erfolg) auf allen Domain Controllern und eine SACL am betroffenen Objekt, die "Berechtigungen ändern" (Write DACL) protokolliert. Für 4662 braucht es "Verzeichnisdienstzugriff überwachen" und eine SACL für die entsprechenden Rechte. Diese SACLs sind nicht überall sinnvoll: flächendeckendes 4662-Auditing auf jedem Objekt erzeugt ein unbeherrschbares Volumen. Die tragfähige Strategie ist, die Unterkategorie für Verzeichnisdienständerungen (5136) domänenweit zu aktivieren und die teureren 4662-SACLs gezielt auf die wenigen schutzwürdigen Objekte zu setzen. Welche Unterkategorien welche Ereignisse freischalten, steht in der Referenz zu den Event-IDs.

Das Muster im Log: den Sicherheitsdeskriptor lesen

Der Kern jeder dieser Erkennungen ist, aus Event 5136 herauszulesen, welches Recht neu vergeben wurde. Das ist nicht trivial, denn das Ereignis nennt die Rechte nicht im Klartext. Vier Felder machen das Muster:

• ObjectDN und ObjectClass. Welches Objekt. Die Domänenwurzel, eine privilegierte Gruppe, ein Benutzer-, Computer- oder GPO-Objekt, eine OU. Das Ziel entscheidet, wie kritisch die Änderung ist.
• AttributeLDAPDisplayName. Bei einer Berechtigungsänderung immer nTSecurityDescriptor. Windows protokolliert DACL-, Owner- und SACL-Änderung nicht getrennt, sondern immer als Änderung dieses einen Attributs; der Unterschied steckt im Wert.
• OperationType. %%14674 ist der hinzugefügte Wert, %%14675 der entfernte. Für die Erkennung zählt der hinzugefügte Wert; manche Parser liefern den Code, andere den Text "Value Added".
• AttributeValue. Der neue Sicherheitsdeskriptor als SDDL-Zeichenkette. Hier stehen Owner (O:), Gruppe (G:), DACL (D:) und SACL (S:). Jede ACE in der DACL hat die Form (Typ;Flags;Rechte;Objekt-GUID;Vererbungs-GUID;SID). Aus diesem Feld wird abgelesen, welches Recht welchem Konto gegeben wurde.

Warum GenericAll und GenericWrite nicht als Wort im Ereignis stehen. Die Rechte in einer ACE sind ein Bitfeld, das die SDDL mit festen Kurzbezeichnern schreibt. GenericAll erscheint als GA, GenericWrite als GW, WriteDACL als WD (im Rechtefeld der ACE, nicht zu verwechseln mit der SID-Kurzform für "Jeder"), WriteOwner als WO. Volle Kontrolle kann auch ausgeschrieben als Kette einzelner Rechte stehen (etwa CCDCLCSWRPWPDTLOCRSDRCWDWO). Die effektiven Rechte, die BloodHound als GenericAll oder GenericWrite anzeigt, sind also nicht ein Feld im Ereignis, sondern das Ergebnis der Auswertung dieser Bits in der neuen ACE. Erweiterte Rechte (Control Access, Kurzform CR) sind ein Sonderfall: Sie tragen eine Rights-GUID, zum Beispiel die drei Replikationsrechte DS-Replication-Get-Changes (1131f6aa-9c07-11d1-f79f-00c04fc2dcd2), DS-Replication-Get-Changes-All (1131f6ad-9c07-11d1-f79f-00c04fc2dcd2) und DS-Replication-Get-Changes-In-Filtered-Set (89e95b76-444d-4c62-991a-0facbeda640c). Diese replikationsspezifische Vergabe ist in DCSync erkennen abgedeckt; dieser Beitrag konzentriert sich auf die Standardrechte GA, GW, WD und WO.

Die Grenze der Aussagekraft. 5136 liefert den neuen Wert des Attributs, nicht die Differenz. Der komplette Sicherheitsdeskriptor mit allen bestehenden ACEs steht im neuen Wert; welche ACE tatsächlich neu ist, ergibt sich erst aus dem Vergleich mit dem alten Wert (ein eigenes 5136 mit %%14675) oder einer Baseline. Eine Regel, die nur auf das Vorkommen eines Rechts für eine S-1-5-21-SID prüft, kann deshalb auch dann greifen, wenn ein bestehender Eintrag erhalten bleibt und nur etwas anderes geändert wurde. Das ist kein Fehler der Regel, sondern eine Eigenschaft des Ereignisses, und es ist der Grund, warum der Analyst im Zweifel alten und neuen Wert vergleicht.

Mehrstufig denken statt auf ein Einzelereignis. Der belastbarste Nachweis ist keine einzelne Event-ID, sondern eine Kette: ein sensibles Objekt, ein ungewöhnlicher Principal, eine Änderung am sicherheitsrelevanten Attribut, ein konkret neu gewährtes Recht und danach die passende Folgeaktivität. Folgt auf die Vergabe eines Replikationsrechts an der Domänenwurzel kurz darauf eine Replikation, ist das DCSync. Folgt auf GenericAll an einem Computerkonto ein Eintrag in msDS-KeyCredentialLink oder msDS-AllowedToActOnBehalfOfOtherIdentity, sind es Shadow Credentials oder RBCD. Folgt auf GenericWrite an einer Gruppe ein 4728/4756 (Mitglied hinzugefügt), ist es die Gruppenmanipulation. Diese Korrelation gehört ins SIEM, wo sich Ereignisse über Zeit und über dasselbe Konto verknüpfen lassen; eine einzelne portable Sigma-Regel kann die zeitliche Sequenz über mehrere Logquellen nicht zuverlässig abbilden, und der Versuch, sie dennoch in eine Regel zu pressen, erzeugt nur eine, die in keinem Backend sauber läuft. Die vier Regeln unten erkennen deshalb jeweils eine Stufe sauber; die Verkettung beschreibt die Checkliste.

Vier Sigma-Regeln

Die erste Regel ist die inhaltliche: Sie prüft, ob im neuen Deskriptor einem domänenspezifischen Konto (SID-Präfix S-1-5-21) eines der weitreichenden Rechte GA, GW, WD oder WO gegeben wurde. Das ist das Netz für die vier Rechte aus der Überschrift, unabhängig vom Objekt. Das SDDL-Muster ist eine Heuristik und setzt ein Backend voraus, das AttributeValue erfasst und reguläre Ausdrücke unterstützt; dasselbe Prinzip verwendet die Replikationsregel in DCSync erkennen.

title: Kritische AD-Rechte (GenericAll/GenericWrite/WriteDacl/WriteOwner) neu an ein domaenenspezifisches Konto vergeben
id: a785a1bb-8d0a-4faa-8ad4-492bf2647b9c
status: experimental
description: |
  Aenderung des Sicherheitsdeskriptors (Event 5136, Attribut nTSecurityDescriptor)
  an einem AD-Objekt, bei der der neue Wert einen hinzugefuegten Allow-ACE enthaelt,
  der einem domaenenspezifischen Konto (SID S-1-5-21-...) eines der weitreichenden
  Rechte GenericAll, GenericWrite, WriteDacl oder WriteOwner gewaehrt. In der
  SDDL-Darstellung sind das die Kurzbezeichner GA, GW, WD und WO im Rechtefeld eines
  Allow-ACE, etwa "(A;;GA;;;S-1-5-21-...)". Genau diese effektiven Rechte stehen
  hinter den BloodHound-Kanten GenericAll, GenericWrite, WriteDacl und WriteOwner und
  erlauben die vollstaendige oder teilweise Uebernahme des Zielobjekts (Passwort
  zuruecksetzen, msDS-KeyCredentialLink oder RBCD setzen, Gruppe erweitern, Owner
  uebernehmen). Die Begrenzung auf S-1-5-21-SIDs sorgt dafuer, dass die Standard-ACEs
  fuer Domain Controller und Administratoren (Kurzbezeichner ED, BA, DA, SY) nicht bei
  jeder ACL-Aenderung ausloesen. Voraussetzung: Unterkategorie
  "Verzeichnisdienstaenderungen ueberwachen" und eine SACL am betroffenen Objekt fuer
  "Berechtigungen aendern" (Write DACL). OperationType %%14674 ist der hinzugefuegte
  Wert. Das Muster ist eine Heuristik auf der SDDL und setzt ein Backend voraus, das
  AttributeValue erfasst und regulaere Ausdruecke unterstuetzt.
references:
  - https://attack.mitre.org/techniques/T1098/
  - https://learn.microsoft.com/en-us/windows/win32/secauthz/ace-strings
author: blue-team.net
date: 2026-10-10
tags:
  - attack.privilege-escalation
  - attack.persistence
  - attack.t1098
logsource:
  product: windows
  service: security
  definition: 'Audit Directory Service Changes auf dem Domain Controller'
detection:
  selection:
    EventID: 5136
    AttributeLDAPDisplayName: 'nTSecurityDescriptor'
    OperationType|contains:
      - '%%14674'
      - 'Value Added'
    AttributeValue|re: '\(A;[A-Z]*;[A-Z]*(GA|GW|WD|WO)[A-Z]*;[0-9a-fA-F-]*;[0-9a-fA-F-]*;S-1-5-21-'
  condition: selection
falsepositives:
  - Dokumentierte Delegierung durch das AD-Team oder ein IAM-/Provisioning-System im Wartungsfenster - ausfuehrenden Principal (SubjectUserName), Zielobjekt und Change-Ticket abgleichen
  - Verwaltungsprodukte (Exchange, Entra Connect, Tiering-Werkzeuge), die ACEs im Rahmen ihrer regulaeren Aufgaben setzen - Dienstkonto allowlisten
level: high

Die zweite Regel ist die objektbezogene: Jede Änderung des Sicherheitsdeskriptors an einem der explizit gelisteten privilegierten Objekte ist meldewürdig, unabhängig vom vergebenen Recht. Die Objektliste ist ein Platzhalter und wird je Umgebung mit den echten Distinguished Names gepflegt. Die replikationsspezifische Vergabe an der Domänenwurzel bleibt bei DCSync, die AdminSDHolder-Änderung bei den AD-Hintertüren; diese Regel ist das breitere Netz für die übrigen privilegierten Ziele.

title: ACL eines privilegierten AD-Objekts geaendert (nTSecurityDescriptor an sensiblem Ziel)
id: e4cd63b9-c0d2-4648-b459-b1392d6da9a5
status: experimental
description: |
  Aenderung des Sicherheitsdeskriptors (Event 5136, Attribut nTSecurityDescriptor)
  an einem explizit als sensibel eingestuften AD-Objekt. Wo Regel 1 am Inhalt des
  neuen ACE ansetzt, setzt diese Regel am Ziel an: jede Berechtigungsaenderung an der
  Domaenenwurzel, an privilegierten Gruppen (Domain Admins, Enterprise Admins,
  Administrators, Group Policy Creator Owners, Key Admins), am KRBTGT-Konto oder an
  einer schutzwuerdigen OU ist meldewuerdig, unabhaengig davon, welches Recht vergeben
  wurde. Die Objektliste in ObjectDN|contains ist bewusst ein Platzhalter und muss je
  Umgebung mit den tatsaechlichen Distinguished Names gepflegt werden; die Domaenenwurzel
  (DC=...) traegt keinen CN und ist hier ueber die uebrigen Eintraege mit abzudecken.
  Die replikationsspezifische Vergabe an der Domaenenwurzel ist in "DCSync erkennen"
  abgedeckt, die AdminSDHolder-Aenderung in "AD-Hintertueren erkennen" - diese Regel
  ist das breitere Netz fuer alle uebrigen privilegierten Objekte. Voraussetzung:
  Unterkategorie "Verzeichnisdienstaenderungen ueberwachen" und eine SACL fuer
  "Berechtigungen aendern" auf den gelisteten Objekten. OperationType %%14674 ist der
  hinzugefuegte Wert; SubjectUserName nennt, wer die ACL geaendert hat.
references:
  - https://attack.mitre.org/techniques/T1098/
author: blue-team.net
date: 2026-10-10
tags:
  - attack.privilege-escalation
  - attack.t1098
logsource:
  product: windows
  service: security
  definition: 'Audit Directory Service Changes auf dem Domain Controller'
detection:
  selection:
    EventID: 5136
    AttributeLDAPDisplayName: 'nTSecurityDescriptor'
    OperationType|contains:
      - '%%14674'
      - 'Value Added'
    ObjectDN|contains:
      - 'CN=Domain Admins'
      - 'CN=Enterprise Admins'
      - 'CN=Administrators,CN=Builtin'
      - 'CN=Group Policy Creator Owners'
      - 'CN=Key Admins'
      - 'CN=Enterprise Key Admins'
      - 'CN=krbtgt'
  condition: selection
falsepositives:
  - Geplante Administration privilegierter Objekte durch Domain Admins im Wartungsfenster (Change-Ticket abgleichen)
  - Tiering- oder Rollenprojekte, die ACLs an privilegierten Gruppen neu ordnen - Zeitraum und ausfuehrenden Principal pruefen
level: high

Die dritte Regel zielt auf die Owner-Übernahme: Privilegierte Objekte gehören im Normalfall den Standard-Trustees (in der SDDL als O:DA oder O:BA), nicht einem einzelnen Benutzerkonto. Ein als voller S-1-5-21-SID serialisierter Owner auf einem privilegierten Objekt ist das typische Ergebnis eines ausgeübten WriteOwner-Rechts. Weil neu angelegte Objekte regulär ihren Ersteller als Owner tragen, ist die Regel bewusst auf bestehende, privilegierte Objekte begrenzt.

title: Owner eines privilegierten AD-Objekts auf ein Benutzerkonto geaendert (WriteOwner-Folge)
id: aa4eb3b9-9734-46c1-912e-6f92f06f2125
status: experimental
description: |
  Aenderung des Sicherheitsdeskriptors (Event 5136, Attribut nTSecurityDescriptor) an
  einem sensiblen AD-Objekt, bei der der Owner-Teil der neuen SDDL auf ein
  domaenenspezifisches Konto (O:S-1-5-21-...) zeigt. Privilegierte Objekte gehoeren im
  Normalfall den Standard-Trustees Domain Admins oder Administratoren; diese erscheinen
  in der SDDL als Kurzbezeichner "O:DA" oder "O:BA". Ein als voller S-1-5-21-SID
  serialisierter Owner auf einem privilegierten Objekt ist deshalb auffaellig und das
  typische Ergebnis eines ausgenutzten WriteOwner-Rechts: Wer Owner eines Objekts wird,
  kann sich anschliessend selbst die DACL schreiben und das Objekt vollstaendig
  uebernehmen. Die Objektliste ist ein je Umgebung zu pflegender Platzhalter.
  Wichtiger Hinweis zur Aussagekraft: Beim Anlegen neuer Objekte wird der Ersteller zum
  Owner, sodass O:S-1-5-21 dort regulaer vorkommt - die Regel zielt bewusst auf
  Owner-Wechsel an bereits bestehenden, privilegierten Objekten und braucht deshalb die
  Objektbegrenzung. Voraussetzung: Unterkategorie "Verzeichnisdienstaenderungen
  ueberwachen" und eine SACL fuer "Besitz uebernehmen"/"Berechtigungen aendern" am
  Objekt. Das Muster ist backendabhaengig (AttributeValue plus regulaere Ausdruecke).
references:
  - https://attack.mitre.org/techniques/T1098/
  - https://learn.microsoft.com/en-us/windows/win32/secauthz/security-descriptor-string-format
author: blue-team.net
date: 2026-10-10
tags:
  - attack.privilege-escalation
  - attack.t1098
logsource:
  product: windows
  service: security
  definition: 'Audit Directory Service Changes auf dem Domain Controller'
detection:
  selection:
    EventID: 5136
    AttributeLDAPDisplayName: 'nTSecurityDescriptor'
    OperationType|contains:
      - '%%14674'
      - 'Value Added'
    AttributeValue|re: '^O:S-1-5-21-'
  filter_objekt:
    ObjectDN|contains:
      - 'CN=Domain Admins'
      - 'CN=Enterprise Admins'
      - 'CN=Administrators,CN=Builtin'
      - 'CN=Group Policy Creator Owners'
      - 'CN=Key Admins'
      - 'CN=krbtgt'
  condition: selection and filter_objekt
falsepositives:
  - Anlegen eines neuen privilegierten Objekts, bei dem der Ersteller regulaer zum Owner wird - mit dem Erstellungszeitpunkt (Event 5137) abgleichen
  - Dokumentierte Owner-Bereinigung durch das AD-Team (z. B. nach einer Migration) - Change-Ticket pruefen
level: high

Die vierte Regel ist die Ergänzung aus 4662: Sie belegt die Ausübung von WRITE_DAC oder WRITE_OWNER an einem Verzeichnisobjekt. Sie ist bewusst nur für gezielt mit SACL versehene, schutzwürdige Objekte gedacht, nicht für flächendeckendes 4662-Auditing, und ihre Aussagekraft steht und fällt mit dieser Begrenzung und mit der Korrelation zu 5136 und 4624.

title: WriteDacl- oder WriteOwner-Zugriff auf ein Verzeichnisobjekt ausgeuebt (4662)
id: 87306d0a-b903-4f0b-945b-f56ad477f22f
status: experimental
description: |
  Verzeichnisdienstzugriff (Event 4662) auf ein AD-Objekt, bei dem die Zugriffsmaske
  das Standardrecht WRITE_DAC (0x40000, "Berechtigungen aendern") oder WRITE_OWNER
  (0x80000, "Besitz uebernehmen") enthaelt. Waehrend Event 5136 die vollzogene
  ACL-Aenderung und ihren neuen Wert zeigt, belegt 4662 die Ausuebung des Rechts selbst
  und ist damit ein ergaenzendes Signal - vor allem, um festzuhalten, wer mit welchem
  Konto den Deskriptor angefasst hat. Wichtige Einschraenkungen: 4662 entsteht nur bei
  passender SACL und ist ohne gezielte Begrenzung extrem laut, weil die Zugriffsmaske
  ein kombiniertes Bitfeld ist und als Zeichenkette geloggt wird; kombinierte Masken
  (z. B. 0xC0000) werden von einer reinen contains-Pruefung nicht sicher erfasst und
  erfordern einen bitweisen Abgleich im Backend. 4662 nennt zudem keine Quell-IP und
  bedeutet fuer sich genommen weder DCSync noch einen ACL-Missbrauch - erst die
  Korrelation mit 5136 (was geaendert wurde) und mit der Anmeldung (4624, gleiche
  SubjectLogonId) ergibt ein belastbares Bild. Diese Regel ist deshalb fuer gezielt mit
  SACL versehene, schutzwuerdige Objekte gedacht, nicht fuer flaechendeckendes
  4662-Auditing.
references:
  - https://attack.mitre.org/techniques/T1098/
  - https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor
author: blue-team.net
date: 2026-10-10
tags:
  - attack.privilege-escalation
  - attack.t1098
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4662
    AccessMask:
      - '0x40000'
      - '0x80000'
  condition: selection
falsepositives:
  - Legitime Administration durch Domain Admins oder Verwaltungsprodukte, die Deskriptoren im Normalbetrieb schreiben - ausfuehrendes Konto allowlisten
  - Sicherungs- und Replikationsdienste, die mit weitreichenden Rechten auf Objekte zugreifen
  - Kombinierte Zugriffsmasken und Masken aus anderen Operationen, die 0x40000/0x80000 nur als Teilbit enthalten - im Backend bitweise pruefen
level: medium

Alle vier Regeln sind mit sigma-cli geprüft. Das heißt: syntaktisch korrekt und gegen das verwendete ATT&CK-Dataset validiert, nicht produktiv getestet. EventID, ObjectDN, ObjectClass, AttributeLDAPDisplayName, AttributeValue, OperationType, AccessMask und SubjectUserName entsprechen den nativen Feldern des Security-Logs in der Sigma-Windows-Taxonomie und müssen zum eigenen SIEM-Mapping passen. Die beiden Regeln mit AttributeValue|re sind backendabhängig: Das Feld mit der SDDL muss erfasst sein, und das Backend muss reguläre Ausdrücke beherrschen; fehlt beides, erkennt das SIEM die Änderung nur objektbezogen (Regel 2). Ob der Parser OperationType als Code (%%14674) oder als Text liefert, ist je Umgebung zu prüfen. Die Übersetzung in die eigene Abfragesprache steht im Beitrag zu Sigma-Regeln.

Blindspots

• Keine SACL, kein Ereignis. Der häufigste Blindspot ist die Konfiguration. Ist "Verzeichnisdienständerungen überwachen" aus oder fehlt die SACL für "Berechtigungen ändern" am Objekt, entsteht kein 5136. Die Regel ist dann korrekt und trifft nie. Der Lab-Test unten prüft genau das.
• Altlasten erzeugen kein Ereignis. Eine gefährliche Berechtigung, die schon vor der Protokollierung bestand, taucht in keinem 5136 auf. Sie findet nur die Expositionsanalyse (BloodHound, Purple Knight, ein ACL-Baseline-Vergleich), nicht die Detection. Beide Blickwinkel sind nötig.
• Vererbung statt direkter ACE. Ein Recht auf eine OU wirkt über Vererbung auf alle Objekte darin, ohne dass an jedem Kindobjekt ein 5136 entsteht. Die Änderung steht am OU-Objekt; wer nur Benutzer- und Gruppenobjekte überwacht, sieht sie nicht. OUs gehören in die Objektliste.
• Der neue Wert zeigt keine Differenz. 5136 liefert den vollständigen neuen Deskriptor, nicht die eine geänderte ACE. Ohne Vergleich mit dem alten Wert oder einer Baseline bleibt offen, was genau hinzukam. Das SIEM sollte beide Werte speichern.
• Das Ausgeübte, nicht das Vergebene. Wer ein bestehendes Recht nutzt (ein legitim delegiertes Passwort-Reset missbraucht), erzeugt kein 5136, weil er die ACL nicht ändert. Diese Fälle fallen in die Erkennung der jeweiligen Folgeaktivität, nicht in diese Regeln.
• Owner-Wechsel ohne DACL-Änderung. WriteOwner allein ändert nur den Owner; die DACL schreibt der Angreifer erst im zweiten Schritt. Regel 3 fängt den Owner-Wechsel, aber nur auf den gelisteten Objekten und nur, wenn der neue Owner ein S-1-5-21-Konto ist.

Fehlalarme und Tuning

• Legitime Delegation. Der Haupt-Fehlalarm. Helpdesk-, Tier- und Rollenmodelle vergeben Rechte an OUs und Gruppen bewusst. Die ausführenden Konten und die Zielobjekte gehören in eine gepflegte Allowlist; eine Vergabe außerhalb dieser Allowlist oder außerhalb des Änderungsfensters bleibt ein Alarm.
• IAM- und Provisioning-Prozesse. Identity-Management-Systeme legen Konten an und setzen Rechte automatisiert. Ihr Dienstkonto wird namentlich allowlistet; Änderungen unter diesem Konto außerhalb seines üblichen Musters (anderes Zielobjekt, anderer Host) bleiben auffällig.
• AD-Migration und Reorganisation. Migrationswerkzeuge und Tiering-Projekte schreiben ACLs in großer Zahl um. Sie bekommen ein befristetes Änderungsfenster; was danach noch eintrifft, ist zu prüfen.
• Exchange, M365 und Verwaltungsprodukte. Exchange setzt beim Setup umfangreiche ACEs, Backup- und Verwaltungsprodukte ebenso. Diese Dienstkonten werden allowlistet; ihre Vergaben sind an Zeitpunkt (Installation, Update) und Host gebunden.
• GPO- und OU-Administration. Die reguläre Verwaltung von Gruppenrichtlinien und OUs berührt deren Deskriptoren. GPO-spezifische Änderungen sind in GPO-Manipulation erkennen eigenständig behandelt.
• Der Kontext entscheidet. Für die Bewertung zählen immer dieselben Größen: das Änderungsfenster, der ausführende Principal, das Objekt, das neu gewährte Recht, Ausgangs- gegen Ziel-ACL, ein ungewöhnlicher Host und die nachfolgende Aktivität. Erst deren Zusammenspiel trennt Delegation von Angriff; das Volumen von 5136 und 4662 wird, wie im Beitrag zum SIEM beschrieben, durch gezielte SACLs und Vorfilterung beherrschbar.

Härtung

• Minimale Delegation. Rechte so eng wie möglich vergeben, an Gruppen statt Einzelkonten, auf OU-Ebene mit klarer Vererbung statt verstreut. Jede Delegation wird dokumentiert, damit die Detection sie als bekannt einordnen kann.
• ACL-Baselines. Den Sollzustand der Deskriptoren an den kritischen Objekten regelmäßig exportieren und mit dem Ist vergleichen. Eine neue ACE, die in keinem Change-Ticket steht, fällt so auch dann auf, wenn das zugehörige 5136 verpasst wurde.
• Tiering und separate Admin-Konten. Wer die ACL privilegierter Objekte schreiben darf, ist ein Tier-0-Konto. Solche Konten gehören getrennt von Alltagskonten, nur auf gehärteten Verwaltungssystemen, in Protected Users.
• Monitoring der kritischen Objekte. Domänenwurzel, privilegierte Gruppen, KRBTGT und die schutzwürdigen OUs bekommen die Unterkategorie für Verzeichnisdienständerungen und eine SACL auf "Berechtigungen ändern". Teure 4662-SACLs nur dort, wo die zusätzliche Sicht sie rechtfertigt; flächendeckendes 4662-Auditing ist nicht sinnvoll.
• Kritische ACEs regelmäßig analysieren. Wer hat GenericAll, WriteDACL oder WriteOwner auf ein privilegiertes Objekt? Die Antwort sollte eine kurze, erklärbare Liste sein. BloodHound- und Purple-Knight-artige Expositionsanalyse macht diese Pfade sichtbar, bevor ein Angreifer sie nutzt, und gehört als Prävention und Kontrolle in den Regelbetrieb, nicht in die Alarmierung.
• Change Management. Berechtigungsänderungen an kritischen Objekten laufen über ein Ticket mit Fenster und Freigabe. Das ist die Referenz, gegen die jeder 5136-Treffer abgeglichen wird; ohne sie bleibt jeder Treffer eine offene Frage.

Der Test

Der Test gehört ausschließlich ins Homelab. Er bleibt bewusst harmlos: Er setzt ein ungefährliches, kontrolliertes Recht auf ein Testobjekt, erzeugt damit das Ereignis und nimmt die Änderung wieder zurück. Er setzt keine echten Replikations- oder Vollzugriffsrechte produktiv.

1. Voraussetzung prüfen. Auf dem Lab-Domain-Controller die Unterkategorie "Verzeichnisdienständerungen überwachen" (Erfolg) aktivieren. An einem Testobjekt (etwa einer eigens angelegten Gruppe in einer Test-OU) mit (Get-Acl "AD:\CN=TestGruppe,OU=Lab,DC=lab,DC=local" -Audit).Audit prüfen, ob ein Überwachungseintrag für "Berechtigungen ändern" existiert; fehlt er, über "Erweiterte Sicherheitseinstellungen, Überwachung" anlegen.
2. Baseline der ACL festhalten. Den aktuellen Deskriptor des Testobjekts mit (Get-Acl "AD:\CN=TestGruppe,OU=Lab,DC=lab,DC=local").Sddl sichern. Das ist der Vorher-Wert für den Vergleich.
3. Kontrollierte Delegation eines Testrechts. Einem harmlosen Lab-Benutzerkonto auf dem Testobjekt ein ungefährliches Recht geben, etwa Lesen der Mitgliedschaft, über die Sicherheitseinstellungen des Objekts. Erwartung: 5136 mit AttributeLDAPDisplayName nTSecurityDescriptor, OperationType "Value Added" bzw. %%14674, im neuen Wert eine zusätzliche ACE für die S-1-5-21-SID des Lab-Kontos; Regel 2 greift, weil das Testobjekt in der (für den Test erweiterten) Objektliste steht.
4. Zweiter Test, strukturell wie eine kritische ACE. Dem Lab-Konto auf dem Testobjekt GenericWrite geben, ohne ein echtes Replikations- oder Domänenrecht zu setzen. Erwartung: Regel 1 greift, weil der neue Deskriptor GW für eine S-1-5-21-SID enthält. So lässt sich die inhaltliche Regel prüfen, ohne eine produktionsnahe Missbrauchslage herzustellen.
5. Vergleich vorher/nachher. Den neuen .Sddl-Wert gegen die Baseline aus Schritt 2 stellen und die hinzugekommene ACE benennen. Das ist genau die Arbeit, die der Analyst im Ernstfall macht.
6. Rücknahme. Die Test-ACEs wieder entfernen, den Deskriptor gegen die Baseline prüfen, Ergebnis und Datum in den Purple-Team-Navigator. Das Testobjekt bleibt isoliert; nichts davon berührt ein produktives, privilegiertes Objekt.

Analysten-Checkliste

• Welches AD-Objekt wurde geändert? ObjectDN und ObjectClass aus 5136. Domänenwurzel, privilegierte Gruppe, Benutzer-, Computer-, GPO-Objekt oder OU bestimmen die Kritikalität.
• Welches Attribut? nTSecurityDescriptor bestätigt eine Berechtigungsänderung. Ein anderes Attribut ist ein anderes Thema.
• Welcher Principal hat geändert? SubjectUserName. Ist es ein Konto, das Berechtigungen vergeben darf (Helpdesk, IAM, AD-Team), oder ein unerwartetes? Das 4624 mit derselben SubjectLogonId liefert den Host.
• Welche ACE kam hinzu oder fiel weg? Neuen Wert gegen alten Wert (bzw. Baseline) stellen und die geänderte ACE isolieren.
• Welches effektive Recht ergibt sich? Die Bits der neuen ACE lesen: GA, GW, WD, WO oder ein erweitertes Recht (CR mit Rights-GUID). Das ist das Recht, das BloodHound als Kante zeigen würde.
• Ist der Principal dafür vorgesehen? Abgleich mit Delegationsmodell und Allowlist. Ein nicht vorgesehener Principal ist ein Vorfall, bis das Gegenteil belegt ist.
• Betrifft es privilegierte Objekte? Domänenwurzel, Domain/Enterprise Admins, KRBTGT, Tier-0-Konten und -OUs heben die Priorität an.
• Wurden Replikationsrechte vergeben? Enthält die ACE eine der drei Replikations-GUIDs, ist es die DCSync-Vorbereitung; weiter nach DCSync erkennen.
• Gab es danach DCSync oder andere Folgeaktivität? Replikation, ein Eintrag in msDS-KeyCredentialLink oder msDS-AllowedToActOnBehalfOfOtherIdentity (RBCD und Shadow Credentials), ein 4728/4756 (Gruppenmitglied hinzugefügt), ein Passwort-Reset, ein Zugriff auf ein Dienstkonto.
• War die Änderung geplant? Change-Ticket und Änderungsfenster. Ohne Ticket bleibt der Treffer offen.
• Existiert dieselbe Änderung auf weiteren Objekten? Angreifer setzen Rechte oft auf mehreren Zielen. Ein gleiches Muster über mehrere Objekte ist ein starkes Signal.

Fazit

AD-ACL-Missbrauch ist die stille Form der Rechteausweitung: kein Exploit, kein gestohlenes Passwort, nur eine umgeschriebene Zugriffskontrollliste. Die Erkennung steht und fällt mit zwei Dingen, der Unterkategorie für Verzeichnisdienständerungen samt passender SACL und der Fähigkeit, aus dem Sicherheitsdeskriptor in 5136 das neu vergebene Recht herauszulesen. Wer GA, GW, WD und WO für domänenspezifische Konten im neuen Deskriptor erkennt, die kritischen Objekte gesondert überwacht, den Owner-Wechsel im Blick hat und 4662 gezielt statt flächendeckend einsetzt, trennt die seltene missbräuchliche Änderung von der täglichen Delegation. BloodHound und Purple Knight liefern dazu die Expositionssicht, aber eine Graph-Kante ist ein Härtungsbefund, kein Alarm. Die prominenten Spezialfälle haben eigene Beiträge: die Replikationsrechte in DCSync erkennen, AdminSDHolder und SID-History in AD-Hintertüren erkennen, die Delegations-Attribute in RBCD und Shadow Credentials erkennen und die Gruppenrichtlinien in GPO-Manipulation erkennen, die Delegationskonfiguration in Kerberos-Delegation erkennen. Dieselbe Lesart des Deskriptors trägt sie alle. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Privilege Escalation.