← Active Directory

Auditing & Detection

Der gefährlichste Zustand einer Erkennungsregel ist nicht der laute Fehlalarm, sondern die stille Regel: Ein Ereignis wird nach einer Richtlinienänderung nicht mehr erzeugt, eine Weiterleitung bricht ab, ein Feld heißt nach einem Update anders — und das sieht exakt so aus wie „es ist nichts passiert“. Dieses Modul ist das Gegenstück zu den Angriffspfaden: Advanced Audit Policy gezielt statt „alles an“, Überwachungslisten auf den wenigen Objekten, die zählen, eine Log-Kette, die außerhalb der Reichweite eines kompromittierten Domain Controllers liegt, Köderobjekte mit extrem niedriger Fehlalarmrate, die fünf Bestandteile einer tragfähigen Regel — und die ehrliche Einordnung, welche Angriffe konstruktionsbedingt schlecht erkennbar sind und deshalb über die Voraussetzung bekämpft werden müssen.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-07-27

Warum Detection das Gegenstück zu den Angriffspfaden ist

Prävention verkleinert die Angriffsfläche, aber sie schließt nie jede Tür. Ein kompetenter Angreifer bewegt sich mit legitimer Mechanik durch die Domäne — genau die Pfade aus dem Modul attack-paths (Kerberoasting, DCSync, Golden Ticket, Delegation-Abuse). Detection ist die Wette, dass du ihn siehst und stoppst, bevor er Tier-0 erreicht. Die entscheidende Kennzahl ist nicht „haben wir Logs“, sondern Zeit bis zur Erkennung.

Detection in AD hat drei Bausteine, die alle sitzen müssen: erfassen (Audit Policy + SACLs erzeugen überhaupt die richtigen Events), hinschauen (Signal von Baseline-Rauschen trennen) und bewahren (eine Kopie außerhalb der Reichweite des Angreifers). Fehlt einer, ist die Kette wertlos — perfekt geloggt, aber lokal gelöscht ist genauso blind wie nie geloggt.

LeitfrageFür jede Detektions-Entscheidung: Erzeugt das überhaupt ein Signal, ist dieses Signal von der Baseline unterscheidbar, und liegt es außerhalb der Reichweite dessen, den ich fangen will? Wer den DC besitzt, besitzt auch dessen lokale Logs.

Advanced Audit Policy — gezielt statt „alles an“

Windows kennt zwei Auditing-Modelle: die alten Basic-Kategorien (grob, neun Kategorien) und die Advanced Audit Policy mit rund sechzig Subkategorien. Nur die Advanced-Ebene erlaubt, gezielt die wenigen aussagekräftigen Ereignisklassen zu aktivieren (z. B. Directory-Service-Access, Kerberos-Ticket-Operationen, Account-Management) statt eine ganze Grobkategorie.

Zwei Fallen: Erstens mischt man Basic und Advanced nicht — laufen beide, ist das Verhalten unvorhersehbar. Deshalb erzwingt man per Sicherheitsoption, dass die Subkategorien die Grobkategorien überschreiben, und steuert nur noch über Advanced. Zweitens ist „alles auf Success und Failure“ ein Anti-Muster: Es erzeugt Volumen, das die Pipeline überlastet und in dem das echte Signal untergeht. Auditing wird per GPO domänenweit durchgesetzt, nicht händisch je DC — sonst driftet es und überlebt keinen Neuaufbau.

Kurzcheck

Warum aktiviert man nicht einfach jede Audit-Subkategorie auf Success und Failure, um „nichts zu verpassen“?

  • Weil das Volumen die Pipeline und das SOC überlastet und das seltene, wertvolle Signal im Rauschen untergeht — mehr Events sind nicht mehr Detection.
  • Weil Windows technisch nur eine begrenzte Zahl von Subkategorien gleichzeitig aktivieren kann.
  • Weil Failure-Events grundsätzlich nutzlos sind und man nur Success braucht.

Treffer. Genau. Detection ist ein Signal-zu-Rausch-Problem. Ungezieltes Vollprotokoll kostet Speicher und Aufmerksamkeit und senkt die Erkennungsrate, statt sie zu heben.

SACL: Objekt-Level-Auditing dort, wo es zählt

Die Audit Policy sagt „ob Directory-Service-Zugriffe geloggt werden“. Welche Objektzugriffe ein Event erzeugen, entscheidet die System Access Control List (SACL) am Objekt selbst — eine Audit-Liste analog zur DACL, nur dass ihre Einträge nicht Zugriff erlauben, sondern Zugriff protokollieren. Ohne passende SACL bleibt selbst bei aktivierter Policy vieles stumm.

Man platziert SACLs nicht überall (das erzeugt genau das Volumenproblem), sondern auf den wenigen Objekten, deren Manipulation Tier-0 bedeutet:

Domänen-Root-Objekt
Die SACL auf den Directory-Replikationsrechten (Replicating Directory Changes / …All) ist die Voraussetzung, damit eine DCSync-Anfrage überhaupt ein auditierbares Ereignis erzeugt.
AdminSDHolder
Änderungen an diesem Schutzobjekt sind fast immer verdächtig (Persistenz-Technik). Eine SACL macht Schreibzugriffe sichtbar.
Kritische OUs / Tier-0-Gruppen
OUs mit privilegierten Konten und Gruppen wie Domain Admins: Auditing auf Mitgliedschafts- und Attributänderungen liefert früh Signal.
MerksatzAudit Policy ist der Hauptschalter, die SACL ist die Verkabelung zum einzelnen Objekt. Für DCSync-Erkennung brauchst du beides — die Policy allein erzeugt kein Event ohne die SACL am Domänenobjekt.

Was ist Signal? Prinzip statt auswendig gelernter Event-IDs

Konkrete Event-IDs (etwa 4662 für Objektzugriff, 4769 für Service-Ticket-Anfragen, 4768 für den AS-Exchange, 1102 für ein geleertes Security-Log) sind nützliche Beispiele — aber sie auswendig zu lernen ist die falsche Fähigkeit. Tragfähig ist das Prinzip, wovon ein Ereignis Signal ist:

  • Seltene, hochprivilegierte Zustandsänderungen sind Signal: Änderung an einer Tier-0-Gruppe, Schreibzugriff auf AdminSDHolder, neue Vertrauensstellung.
  • Abweichung von der Baseline ist Signal: Replikationsanfrage aus einer Nicht-DC-Quelle, ein Verschlüsselungs-Downgrade auf RC4, wo die Umgebung AES fährt, Authentifizierung eines Kontos, das nie benutzt wird.
  • Reines Volumen ist selten Signal: jeder erfolgreiche Logon (4624) ist Baseline. Auf das Rohvolumen zu alarmieren erzeugt nur Rauschen.
  • Die Abwesenheit von Logs ist selbst ein Signal: ein geleertes Security-Log oder eine Forwarding-Lücke außerhalb des Wartungsfensters ist Anti-Forensik, kein Zufall.
Warum nicht IDs auswendigAngriffe und Event-Nummern ändern sich; das Prinzip „seltene privilegierte Aktion + Abweichung von der Baseline“ überträgt sich auf jede neue Variante. Wer Detektion an einer festen ID-Liste festmacht, verpasst die nächste Abwandlung.

Die Log-Pipeline: off-host, tamper-resistent, lange genug

Ein Angreifer mit Kontrolle über einen DC kann dessen lokale Security-Logs löschen oder überschreiben — Anti-Forensik ist Standard-Teil jedes Playbooks. Detection, die sich auf lokal verbliebene Logs verlässt, verliert genau im Ernstfall. Deshalb ist die Pipeline zentral zu denken:

DC erzeugt Event (lokaler Kurzpuffer)→near-real-time Forwarding off-host (z. B. Windows Event Forwarding)→zentraler Collector / SIEM→append-only Aufbewahrung + Korrelation & Alerting
  • Off-host & near-real-time: Events verlassen den DC schnell, sodass eine Kopie außerhalb der Reichweite eines lokalen Angreifers liegt. Der DC-lokale Log ist nur Kurzpuffer, nicht die vertrauenswürdige Quelle.
  • Tamper-resistent: Die zentrale Kopie ist append-only / write-once, und kein Tier-0- oder Ops-Konto darf sie löschen oder ändern — sonst verwischt derselbe kompromittierte Zugang beide Kopien. Verschlüsselung schützt Vertraulichkeit, nicht gegen Löschung.
  • Retention über die Verweildauer: Angreifer sind oft Wochen bis Monate unentdeckt; Detection läuft häufig rückwirkend, wenn ein IOC erst später bekannt wird. Sieben Tage Aufbewahrung reichen dafür nicht.
MerksatzDie Vertrauensgrenze verläuft zwischen dem DC (Quelle, kompromittierbar) und dem zentralen Store (Anker der Detection). Was nur lokal auf dem DC liegt, ist im Ernstfall die Kopie, die der Angreifer als Erstes anfasst.

Canary: Honeytoken als Köder mit niedriger Fehlalarmrate

Ein Honeytoken (Canary) ist ein zweckgebautes Köder-Objekt, das niemand legitim benutzt. Sein Wert ist die extrem niedrige False-Positive-Rate: Weil ein echter Betrieb den Köder nie berührt, ist jede Interaktion damit per Definition verdächtig. Der klassische AD-Köder ist ein Dienstkonto mit SPN als Kerberoasting-Falle — jede Service-Ticket-Anfrage dafür ist ein Alarm.

  • Keine echten Rechte, keine echte Nutzung: Der Köder darf niemals Mitglied einer privilegierten Gruppe sein und nirgends produktiv verwendet werden. Sonst wird bei „Erfolg“ ein echter Pfad geöffnet oder es entstehen Fehlalarme.
  • Ununterscheidbar von echten Objekten: plausibler Name, glaubwürdiges Alter, in einer normalen OU, SPN wie ein reales Altkonto. Ein als honeypot1 benannter Köder in einer OU Decoys wird vom Angreifer erkannt und umgangen — dann liefert er kein Signal.
  • Die Alarmregel ist der eigentliche Köder: Ein Honeytoken ohne angeschlossenes Alerting ist wertlos. Das Signal ist die Anforderung/Authentifizierung, nicht die bloße Existenz des Objekts.

Kurzcheck

Was macht ein Honeytoken-Dienstkonto zu einem guten Kerberoasting-Köder?

  • Es hat einen SPN und sieht aus wie ein echtes Altkonto, besitzt aber keinerlei echte Rechte — jede Ticket-Anfrage dafür ist per Definition verdächtig und alarmiert.
  • Es liegt in Domain Admins mit einem starken Passwort, damit der Angreifer es priorisiert angreift.
  • Es ist klar als Köder benannt (decoy-svc) und in einer eigenen OU gruppiert, damit das SOC es leicht wiederfindet.

Treffer. Richtig. Tarnung sichert, dass der Köder überhaupt angefasst wird; die fehlenden Rechte machen ihn ungefährlich; und die niedrige FP-Rate macht jeden Treffer aussagekräftig.

Die Angriffe erkennen (Kopplung an attack-paths)

Jeder Pfad aus attack-paths hat ein Detektions-Gegenstück — aber nicht jeder ist gleich sauber erkennbar. Ehrlich zu sein, wie zuverlässig ein Signal ist, gehört zur Detektions-Reife dazu:

DCSync
Directory-Replikation ist eine reine DC-zu-DC-Operation. Eine Get-Changes(-All)-Anfrage aus einer Nicht-DC-Quelle ist ein starkes Signal (setzt die SACL am Domänenobjekt voraus). Portbasiertes Blocken hilft nicht — DRSUAPI läuft über dynamische RPC-Ports; die Identität der Quelle ist das Signal, nicht der Port.
Kerberoasting / AS-REP-Roasting
Anomalie im Ticket-Fluss: viele distinct SPNs kurzfristig von einem Konto, RC4-Downgrade in einer AES-Umgebung, oder ein Honeytoken-Treffer. Einzelne Anfragen sind Baseline — das Muster ist das Signal.
Golden Ticket
Nur heuristisch erkennbar: Service-Ticket-Nutzung ohne vorausgehenden AS-Exchange (das TGT wurde nie vom KDC ausgestellt), unplausible Ticket-Lebensdauern, nicht existierende/mismatchende Konten. Das gefälschte TGT ist kryptografisch gültig — es gibt keine deterministische Signatur zum Blocken.
DCShadow
Registriert einen rogue DC (neues nTDSDSA/Server-Objekt in der Configuration-Partition) und pusht Änderungen per Replikation. Signal: unerwartete Objektanlage in der Config-Partition bzw. Replikation aus einer unbekannten Quelle.
MerksatzDetection ergänzt Response, sie ersetzt sie nicht. Ein sicher signiertes Golden Ticket wirst du nie zuverlässig blocken — die eigentliche Gegenmaßnahme bleibt der zweifache krbtgt-Reset plus Schließen des Einbruchswegs.

Tuning: Alarm-Müdigkeit ist ein Detektions-Ausfall

Ein SOC, das täglich tausende Fehlalarme bekommt, ignoriert irgendwann auch den echten — Alarm-Müdigkeit ist ein Erkennungsausfall mit anderem Namen. Die falschen Reaktionen sind verlockend und beide gefährlich: Schwellen pauschal hochsetzen blendet gerade den leisen, gezielten Angriff aus (ein DCSync, ein Honeytoken-Treffer haben niedriges Volumen); laute Regeln abschalten entfernt ganze Detektionsklassen.

  • Baseline etablieren und auf Abweichung alarmieren statt auf Rohvolumen.
  • Gezielt allowlisten, was legitim laut ist (bekannte Sync-Konten, geplante Wartung) — statt die Regel zu killen.
  • Nach Tier-0-Relevanz priorisieren: ein Signal, das direkt zur Domänenübernahme führt, verdient mehr Aufmerksamkeit als ein Fehllogin auf einer Workstation.
PrinzipDie Lautstärke einer Regel sagt nichts über ihren Signalwert — nur über fehlende Baseline und Filterung. Tuning senkt Fehlalarme, ohne Signalklassen blind zu entfernen.

Was eine Erkennungsregel braucht, um zu tragen

Eine Regel zu schreiben ist der kleinste Teil der Arbeit. Damit sie nach sechs Monaten noch etwas wert ist, braucht sie fünf Bestandteile — und fehlt einer, verfällt sie leise, ohne dass jemand es merkt.

Signal
Welches Ereignis mit welchen Feldern? Ohne benanntes Ereignis ist die Regel eine Absicht, kein Detektor.
Baseline
Was ist normal? Ohne gemessenen Normalzustand ist jede Abweichung ein Fehlalarm oder gar keiner.
Erwartete Reaktion
Was soll jemand tun, wenn sie auslöst? Eine Regel ohne Handlungsanweisung erzeugt Ereignisse, keine Sicherheit.
Verantwortlicher
Wer entscheidet über Ausnahmen und Änderungen? Ohne Eigentümer verwaist die Regel bei der ersten Umgebungsänderung.
Prüfdatum
Wann wird nachgesehen, ob sie noch feuert? Eine Regel, die aus technischen Gründen still ist, sieht aus wie eine ruhige Lage.
Der gefährlichste ZustandNicht der laute Fehlalarm, sondern die stille Regel. Ein Ereignis wird nicht mehr erzeugt, weil eine Richtlinie geändert wurde; eine Weiterleitung bricht ab; ein Feld heißt nach einem Update anders. Die Regel meldet nichts — und das sieht exakt so aus wie „es ist nichts passiert“. Deshalb gehört zu jeder Erkennung eine Prüfung, dass sie überhaupt noch auslösen kann: eine kontrollierte Auslösung in festem Rhythmus, die belegt, dass die Kette von der Quelle bis zum Alarm intakt ist.

Erkennen heißt nicht verhindern

Es lohnt sich, ehrlich zu benennen, was Detection leisten kann und was nicht. Sie sitzt nach dem Ereignis, nicht davor — und einige Angriffe sind konstruktionsbedingt schlecht erkennbar.

  • Gut erkennbar: Zustandsänderungen an seltenen, privilegierten Objekten. Sie sind selten, sie sind eindeutig, und sie haben einen Verantwortlichen, den man fragen kann.
  • Mittelmäßig erkennbar: Ungewöhnliche Muster in häufigen Vorgängen — viele Ticketanfragen, ungewöhnliche Zeiten. Braucht eine Baseline und erzeugt ohne sie Rauschen.
  • Schlecht erkennbar: Verwendung eines gültigen, korrekt geschmiedeten Nachweises. Für den Dienst sieht er aus wie ein echter, weil er kryptografisch einer ist.
Was daraus folgtWo Erkennung schwach ist, muss Prävention stark sein — und umgekehrt. Ein Angriff, den man nicht zuverlässig sieht, wird über die Voraussetzung bekämpft: Wer die Schlüssel nicht bekommt, schmiedet keine Nachweise. Deshalb ist der Satz „wir haben eine Regel dafür“ bei dieser Klasse von Angriffen kein Trost, sondern eine Selbsttäuschung.
Der zweite ehrliche PunktDetection erzeugt Arbeit. Jede zusätzliche Regel bindet Menschen, die auslösende Ereignisse bewerten müssen — und diese Kapazität ist der eigentliche Engpass, nicht die Zahl der möglichen Regeln. Eine Regel, für deren Auslösungen niemand Zeit hat, ist keine Erkennung, sondern ein Protokolleintrag mit Alarmton.

Durchgerechnet: eine Regel für privilegierte Gruppenänderungen

Von der Absicht zur tragfähigen Erkennung

Szenario

Die Vorgabe lautet: „Wir wollen mitbekommen, wenn jemand einer privilegierten Gruppe hinzugefügt wird.“ Der Auditor will eine Regel sehen.

Anforderungen

  • Die Regel muss nach sechs Monaten noch funktionieren
  • Sie darf das Team nicht mit Auslösungen fluten

Schritte

  1. Signal festlegen: Nicht „privilegierte Gruppen“ als Kategorie, sondern eine benannte, kurze Liste von Objekten. Dazu die konkrete Ereignisart für Mitgliedschaftsänderungen — und die Prüfung, dass sie mit der aktuellen Richtlinienkonfiguration überhaupt erzeugt wird.
  2. Baseline messen: Wie viele solche Änderungen gibt es heute pro Woche, und von wem? In den meisten Umgebungen ist die Antwort einstellig — genau das macht dieses Signal so brauchbar.
  3. Legitime Quellen benennen: Gibt es ein Bereitstellungssystem, das solche Änderungen regulär vornimmt? Dann wird nicht die Regel abgeschaltet, sondern dieser eine Verantwortliche mit seinem erwarteten Umfang ausgenommen — und Abweichungen von diesem Umfang bleiben Signal.
  4. Reaktion festschreiben: Wer wird gefragt, in welcher Frist, und was passiert, wenn niemand die Änderung beauftragt hat? Ohne diesen Teil landet die Auslösung in einer Warteschlange.
  5. Auslösung prüfen: Einmal kontrolliert eine Teständerung vornehmen und belegen, dass sie ankommt. Danach in festem Rhythmus wiederholen — sonst weiß niemand, ob die Stille echt ist.

Merksatz: Der Wert der Regel entsteht nicht im Filter, sondern in der Baseline und im benannten Verantwortlichen. Beides kostet Gespräche statt Technik — und genau deshalb wird beides in der Praxis übersprungen.

Zusammenfassung — gleich im Check

Die Achsen dieses Moduls: Advanced Audit Policy gezielt statt „alles an“; SACLs auf den Tier-0-Objekten (Domänen-Root für DCSync, AdminSDHolder, kritische OUs); Signal-Prinzip (seltene privilegierte Aktion + Baseline-Abweichung statt ID-Auswendiglernen); die Log-Pipeline (off-host, tamper-resistent, ausreichende Retention); Canary/Honeytoken als Köder mit niedriger FP-Rate; die Erkennung von DCSync, Kerberoasting, Golden Ticket und DCShadow; und Tuning gegen Alarm-Müdigkeit.

Gleich im CheckDu entscheidest für konkrete Situationen die beste Detektions-Konfiguration oder Triage — und in einer Sortier-Mission ziehst du Verantwortlichkeiten an die richtige Vertrauensgrenze: DC-lokal, zentrales SIEM oder Tier-0-Management. Pro Option siehst du, warum sie trägt oder aus welchem benannten Grund nur ein Symptom trifft.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →
Quellen & Aktualität29 Primärquellen · zuletzt geprüft:
  1. 01Microsoft Learn — Audit Policy Recommendations (Best Practices for Securing Active Directory / Monitoring Active Directory for Signs of Compromise)
  2. 02Microsoft Learn — Advanced security audit policy settings und „Audit: Force audit policy subcategory settings to override audit policy category settings“
  3. 03Microsoft Learn — Appendix L: Events to Monitor
  4. 04Microsoft Learn — Use Windows Event Forwarding to help with intrusion detection
  5. 05MITRE ATT&CK — T1003.006 DCSync, T1558.003 Kerberoasting, T1558.004 AS-REP Roasting, T1558.001 Golden Ticket, T1207 Rogue Domain Controller, T1070.001 Clear Windows Event Logs
  6. 06learn.microsoft.com/en-us/windows-server/ident…ing-active-directory
  7. 07learn.microsoft.com/en-us/windows-server/ident…-in-active-directory
  8. 08Microsoft Learn — Advanced security audit policy settings
  9. 09Microsoft Learn — Audit policy recommendations
  10. 10Microsoft Learn — Monitoring Active Directory for signs of compromise
  11. 11Microsoft Learn — Audit: Force audit policy subcategory settings to override audit policy category settings
  12. 12Microsoft Learn — Audit directory service access
  13. 13MITRE ATT&CK — DCSync
  14. 14Microsoft Learn — Windows Event Forwarding intrusion detection
  15. 15Microsoft Learn — event log security
  16. 16Microsoft security guidance — honeytoken accounts
  17. 17MITRE ATT&CK — Kerberoasting
  18. 18Microsoft security guidance — alert tuning
  19. 19Microsoft Learn — monitoring privileged group changes
  20. 20Microsoft Learn — Windows Event Forwarding
  21. 21Microsoft security guidance — privileged access
  22. 22MITRE ATT&CK — Clear Windows Event Logs
  23. 23Microsoft Learn — Directory Service Access auditing
  24. 24Microsoft Learn — Kerberos service ticket auditing
  25. 25Microsoft Learn — Monitoring AD compromise
  26. 26MITRE ATT&CK — Golden Ticket
  27. 27MITRE ATT&CK — Rogue Domain Controller
  28. 28Microsoft Learn — Active Directory replication monitoring
  29. 29Microsoft incident response guidance