Auditing & Detection: Signal statt Rauschen, tamper-resistente Pipeline, Angriffe erkennen
Einführung · 9 Abschnitte · ~9 Min Lesezeit · Stand
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.
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.
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. |
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.
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.
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
honeypot1benannter Köder in einer OUDecoyswird 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.
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. |
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.
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.