# Auditing & Detection

> Das Gegenstück zu den Angriffspfaden: Advanced Audit Policy gezielt setzen, mit SACLs auf den richtigen Objekten auditieren, Signal von Rauschen trennen, eine tamper-resistente Log-Pipeline bauen, Honeytoken als Köder auslegen, DCSync/Kerberoasting/Golden-Ticket/DCShadow erkennen und Alarm-Müdigkeit durch Tuning bekämpfen.

Track: [Active Directory](https://physar.tech/learn/active-directory)  
Kanonische Fassung: https://physar.tech/learn/active-directory/auditing-detection  
Stand: 2026-07-27  
Interaktiver Teil: 14 Checks (nur im Browser)

## Auditing & Detection: Signal statt Rauschen, tamper-resistente Pipeline, Angriffe erkennen

### 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.

> **Leitfrage:** Fü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“?

- [x] 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.

> 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. |

> **Merksatz:** Audit 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 auswendig:** Angriffe 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.

> **Merksatz:** Die 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?

- [x] 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.

> 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. |

> **Merksatz:** Detection 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.

> **Prinzip:** Die Lautstärke einer Regel sagt nichts über ihren Signalwert — nur über fehlende Baseline und Filterung. Tuning senkt Fehlalarme, ohne Signalklassen blind zu entfernen.

### 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 Check:** Du 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.

## Quellen

- Microsoft Learn — Audit Policy Recommendations (Best Practices for Securing Active Directory / Monitoring Active Directory for Signs of Compromise)
- Microsoft Learn — Advanced security audit policy settings und „Audit: Force audit policy subcategory settings to override audit policy category settings“
- Microsoft Learn — Appendix L: Events to Monitor
- Microsoft Learn — Use Windows Event Forwarding to help with intrusion detection
- MITRE 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
- Microsoft Learn — Advanced security audit policy settings
- Microsoft Learn — Audit policy recommendations
- Microsoft Learn — Audit: Force audit policy subcategory settings to override audit policy category settings
- Microsoft Learn — Audit directory service access
- MITRE ATT&CK — DCSync
- Microsoft Learn — Monitoring Active Directory for signs of compromise
- Microsoft Learn — Windows Event Forwarding intrusion detection
- Microsoft Learn — event log security
- MITRE ATT&CK — Clear Windows Event Logs
- Microsoft incident response guidance
- Microsoft Learn — Directory Service Access auditing
- MITRE ATT&CK — Kerberoasting
- Microsoft Learn — Kerberos service ticket auditing
- Microsoft security guidance — honeytoken accounts
- Microsoft Learn — Monitoring AD compromise
- MITRE ATT&CK — Golden Ticket
- MITRE ATT&CK — Rogue Domain Controller
- Microsoft Learn — Active Directory replication monitoring
- Microsoft security guidance — alert tuning
- Microsoft Learn — monitoring privileged group changes
- Microsoft Learn — Windows Event Forwarding
- Microsoft security guidance — privileged access