Was Ist Active Directory-Überwachung?
Active-Directory-Überwachung ist die Kombination aus Audit-Richtlinie, Event-Sammlung, Korrelation und Baseline-Analyse, die notwendig ist, um Identitätsangriffe gegen Domain Controller und privilegierte Konten zu erkennen. Viele AD-Umgebungen erzeugen Windows-Security-Events, aber deutlich weniger erzeugen die richtigen Events und leiten sie in Erkennungen, die ein Analyst tatsächlich nutzen kann.
Überwachung in AD bedeutet nicht nur Log-Aufbewahrung. Es ist die Disziplin, die relevanten Unterkategorien auszuwählen, nachzuweisen, dass die Events auf den Domain Controllern vorhanden sind, und Erkennungen rund um Angreiferverhalten statt um reines Volumen aufzubauen.
Ein sinnvolles AD-Überwachungsprogramm beginnt mit den Angriffspfaden, die Verteidiger tatsächlich sehen müssen: Missbrauch von Kerberos-Tickets, DCSync, Änderungen privilegierter Gruppen, Schreibzugriffe auf Verzeichnisobjekte, NTLM-Authentifizierung, Zertifikatsausstellung und laterale Bewegung auf sensible Server.
Wie Active Directory-Überwachung Funktioniert
Windows-Security-Auditing wird über die Erweiterte Überwachungsrichtlinie (Advanced Audit Policy) gesteuert und liefert nur dann brauchbare Daten, wenn die richtigen Unterkategorien aktiviert sind.
Eine praktische Überwachungs-Pipeline sieht so aus:
- Die Erweiterte Überwachungsrichtlinie aktiviert die benötigten Events
- Das Windows Event Log speichert die Security-Events lokal
- WEF oder ein Agent leitet die Events an eine zentrale Plattform weiter
- Die SIEM-Korrelation verwandelt diese Events in Erkennungen und Untersuchungen
Der häufigste Fehler bleibt Schritt eins: Collector und SIEM sind vorhanden, aber zentrale AD-Unterkategorien wurden auf den relevanten Domain Controllern nie aktiviert.
Die Dokumentation von Microsoft Defender for Identity unterstreicht diesen Punkt, indem sie die erforderlichen Windows-Events für Sensoren und zugehörige Infrastruktur auflistet. Die Liste umfasst zentrale Identitäts-Events wie 4662, 4728, 4732, 4756 und 4776. Wenn Ihre Domain Controller diese Events nicht erzeugen und weiterleiten, kann die nachgelagerte Erkennungslogik die fehlenden Beweise nicht nachträglich rekonstruieren.
Die Angriffskette Ohne Überwachung
DCSync – Keine Directory Service Access-Überwachung
Ohne Audit Directory Service Access liefert Event 4662 nicht die Sichtbarkeit, die Verteidiger für den Missbrauch von Replikationsrechten erwarten. Event 4662 wird erzeugt, wenn eine Operation auf einem Active-Directory-Objekt ausgeführt wird — Objekt-Auditing und SACL-Konfiguration bleiben aber entscheidend für eine brauchbare Abdeckung.
Kerberoasting – Keine Kerberos-Ticket-Sichtbarkeit
Ohne die Sammlung und Auswertung von 4769 verschwinden ungewöhnliche Service-Ticket-Anfragen im normalen Datenverkehr, und RC4-lastige Anfragen werden leicht übersehen. Microsoft dokumentiert Event 4769 als TGS-Anfrage-Event, das auf Domain Controllern erzeugt wird. Neuere Windows-Updates stellen zusätzliche Kerberos-Felder bereit, die die Untersuchung verbessern können, sofern verfügbar.
Missbrauch Privilegierter Gruppen – Keine Alarmierung Bei Mitgliedschaftsänderungen
Ohne Abdeckung von 4728, 4732 und 4756 kann ein Angreifer ein Backdoor-Konto zu einer privilegierten Gruppe hinzufügen und darauf vertrauen, dass Administratoren dies erst im Nachhinein bemerken. Diese Events entsprechen Mitgliedschaftsänderungen in globalen, lokalen und universellen Sicherheitsgruppen.
Delegations- Oder GPO-Missbrauch – Keine Änderungssichtbarkeit
Ohne 5136 und die zugehörige Änderungsüberwachung können folgenreiche Verzeichnisänderungen mit sehr wenig forensischem Kontext stattfinden. Event 5136 wird erzeugt, wenn ein Verzeichnisdienstobjekt geändert wird, und wird deutlich nützlicher, wenn es mit dem geänderten Attribut und dem Objektkontext kombiniert wird.
Erkennung
Wesentliche Audit-Richtlinien-Konfiguration
Über GPO deployen: Computerkonfiguration > Windows-Einstellungen > Sicherheitseinstellungen > Erweiterte Überwachungsrichtlinien-Konfiguration
| Kategorie | Unterkategorie | Einstellung | Wichtige Events |
|---|---|---|---|
| Kontoanmeldung | Kerberos-Authentifizierung | Erfolg/Fehler | 4768, 4771 |
| Kontoanmeldung | Kerberos-Dienstticket-Operationen | Erfolg/Fehler | 4769 |
| Kontenverwaltung | Benutzer-/Gruppenkontenverwaltung | Erfolg/Fehler | 4720, 4728, 4732, 4738 |
| DS-Zugriff | Verzeichnisdienstzugriff | Erfolg | 4662 |
| DS-Zugriff | Verzeichnisdienständerungen | Erfolg | 5136, 5137, 5141 |
| Anmeldung/Abmeldung | Anmeldung | Erfolg/Fehler | 4624, 4625, 4648 |
| Rechteverwendung | Verwendung Sensibler Rechte | Erfolg | 4672 |
| Richtlinienänderung | Änderung Der Überwachungsrichtlinie | Erfolg | 4719 |
| Objektzugriff | Zertifizierungsdienste | Erfolg/Fehler | 4886, 4887 |
Kritische Event-ID-Referenz
| Event-ID | Kategorie | Alarmpriorität | Was Es Erkennen Hilft |
|---|---|---|---|
| 4662 | DS-Zugriff | KRITISCH | Missbrauch von Replikationsrechten und DCSync-Untersuchung |
| 4769 | Kerberos | HOCH | Kerberoasting und verdächtige Service-Ticket-Aktivität |
| 4771 | Kerberos | MITTEL | Password-Spraying oder wiederholte Pre-Auth-Fehlermuster |
| 4728 / 4732 / 4756 | Gruppenverwaltung | KRITISCH | Änderungen an privilegierten Gruppenmitgliedschaften |
| 4720 | Kontenverwaltung | HOCH | Neue Kontoerstellung in sensiblen Kontexten |
| 4738 | Kontenverwaltung | MITTEL | Benutzerkontoänderungen wie riskante Flag-Umschaltungen |
| 5136 | Verzeichnisänderungen | HOCH | Änderungen an GPOs, Delegation oder sensiblen Objekten |
| 4887 | Zertifikatsdienste | HOCH | Zertifikatsausstellung, die ADCS-Missbrauch begünstigen kann |
| 4624 (Typ 3) | Anmeldung | MITTEL | Laterale Bewegung und ungewöhnliche Netzwerkanmeldungen |
| 4672 | Rechteverwendung | HOCH | Anmeldungen mit Sonderrechten |
| 4776 | Anmeldeinformationsprüfung | MITTEL | NTLM-Validierungsaktivität für Domänenkonten |
SIEM-Erkennungsabfragen (Elastic KQL)
DCSync-Erkennung:
event.code: "4662" AND
winlog.event_data.Properties: ("*1131f6ad*" OR "*1131f6aa*") AND
NOT winlog.event_data.SubjectUserName: ("*$")
Kerberoasting-Erkennung:
event.code: "4769" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
NOT winlog.event_data.ServiceName: ("krbtgt" OR "*$")
Änderung Privilegierter Gruppe:
event.code: ("4728" OR "4732" OR "4756") AND
winlog.event_data.TargetUserName: ("Domain Admins" OR "Enterprise Admins" OR "Schema Admins")
Tipp: Beginnen Sie mit einer kleinen Menge hochwertiger Erkennungen, die das Team tatsächlich untersucht. DCSync, Änderungen privilegierter Gruppen und Service-Ticket-Missbrauch liefern in der Regel deutlich mehr Wert als ein großes, ungepflegtes Regelwerk.
Feldzuordnung Und Parser-Validierung
Bevor Sie komplexe Erkennungslogik schreiben, validieren Sie die Feldzuordnung für Ihr SIEM. Dasselbe Windows-Event kann je nach Connector, Agent oder Normalisierungsschicht mit unterschiedlichen Feldnamen ankommen. Bestätigen Sie für jede kritische Erkennung:
- die Event-ID wird konsistent geparst
- Kontofelder trennen Benutzer-, Domänen- und Computerkonten
- Felder für Quell-Workstation und Client-Adresse bleiben erhalten
- Ticket-Verschlüsselungsfelder sind für Kerberos-Erkennungen vorhanden
- Verzeichnisobjekt- und Attributfelder bleiben für 4662 und 5136 erhalten
- Zertifikatanfrage- und Vorlagenfelder bleiben für AD-CS-Events erhalten
Eine Regel, die im Labor funktioniert, in der Produktion aber das kritische Feld verliert, ist keine Abdeckung.
Behebung
Schnelle Massnahme: Aktivieren Sie
Directory Service Access,Directory Service Changesund die Kerberos-Unterkategorien auf allen Domain Controllern, bevor Sie irgendetwas anderes tunen.
1. Erweiterte Audit-Richtlinie Per GPO Ausrollen
auditpol /get /category:*
auditpol /set /subcategory:"Directory Service Changes" /success:enable
auditpol /set /subcategory:"Directory Service Access" /success:enable
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable
auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable
2. Kapazität Des Security-Logs Erhöhen
Die Standardgröße des Security-Logs ist für stark ausgelastete Domain Controller oft zu klein.
wevtutil sl Security /ms:1073741824 /rt:false /ab:true
Die Log-Kapazität sollte anhand des tatsächlichen Event-Volumens dimensioniert werden. Kerberos-lastige Domänen und stark ausgelastete DCs können Beweise schnell überschreiben, wenn Security-Logs bei kleinen Standardwerten bleiben.
3. Domain-Controller-Events Zentral Weiterleiten
winrm quickconfig
wecutil cs subscription.xml
gpupdate /force
Die Weiterleitung sollte das Event-XML oder die für die Erkennung erforderlichen normalisierten Felder erhalten. Wenn Ihr Collector Properties, ObjectDN, TicketEncryptionType oder Quell-Workstation-Felder verwirft, degradieren hochwertige Regeln zu generischen Alarmen.
4. Baselines Vor Der Schwellenwert-Anpassung Etablieren
Get-WinEvent -ComputerName DC01 -FilterHashtable @{LogName='Security'; Id=4768} |
Group-Object {$_.TimeCreated.Hour} |
Select-Object Name, Count |
Sort-Object Name
Nutzen Sie diese Baselines, um das normale Kerberos- und Anmeldevolumen zu verstehen, bevor Sie Anomalie-Schwellenwerte einführen.
5. Erkennungen Auf Angriffspfade Abbilden
Überwachen Sie Event-IDs nicht isoliert. Ordnen Sie jede Erkennung dem Angriffspfad zu, den sie unterstützt:
- DCSync benötigt Events zu Replikationsrechten und privilegierte Verzeichnisänderungen
- Kerberoasting benötigt Service-Ticket-Sichtbarkeit, Verschlüsselungskontext und ein Inventar der Dienstkonten
- Delegationsmissbrauch benötigt Sichtbarkeit von Attributänderungen und ungewöhnliche Computerkonto-Authentifizierung
- NTLM-Relay benötigt NTLM-Validierung, Ziel-Anmeldungen und dienstspezifische Folgeaktionen
- ADCS-Missbrauch benötigt Kontext zu Zertifikatanfrage, -ausstellung und -vorlage
Diese Zuordnung verhindert, dass das Überwachungsprogramm zu einer zusammenhanglosen Liste von Events wird.
So Erkennt EtcSec Dies
EtcSec prüft die Audit-Richtlinien-Abdeckung, die Verteidiger benötigen, um die zentralen AD-Angriffspfade zu untersuchen, die an anderer Stelle im Report aufgezeigt werden.
Überwachungsbezogene Befunde heben fehlende Audit-Unterkategorien, unzureichende Aufbewahrung und andere Lücken hervor, die hochwertigen Identitätsmissbrauch unsichtbar oder schwer rekonstruierbar machen würden.
Zuerst Umzusetzende Erkennungen
Wenn das Überwachungsteam anfangs nur wenige hochwertige Regeln ausrollen kann, beginnen Sie mit den Angriffen, die sowohl häufig als auch operativ gut überprüfbar sind:
- Missbrauch von Replikationsrechten und DCSync-Versuche
- Änderungen an privilegierten Gruppenmitgliedschaften
- verdächtige Service-Ticket-Anfragen im Zusammenhang mit Kerberoasting
- hochwertige Verzeichnisobjektänderungen wie GPO- oder Delegationsschreibvorgänge
- Zertifikatausstellungsaktivität in ADCS-fähigen Umgebungen
- NTLM-Validierungs- und Netzwerkanmeldemuster für Relay- oder Lateral-Movement-Untersuchungen
Diese Erkennungen schaffen eine sinnvolle Grundlage, ohne Analysten mit minderwertigem Rauschen zu überfluten.
Aufbewahrung Und Abdeckungsprüfung
Active-Directory-Überwachung sollte auch eine Aufbewahrungsprüfung umfassen. Ein Domain Controller kann große Mengen an Kerberos-, Anmelde- und Kontenverwaltungs-Events erzeugen, und ein kleines lokales Security-Log kann genau die Beweise überschreiben, die während der Incident Response benötigt werden. Prüfen Sie die maximale Security-Log-Größe, die Weiterleitungslatenz, SIEM-Ingestion-Fehler und die Hot-Storage-Aufbewahrung gemeinsam. Wenn das SIEM 90 Tage durchsuchbare Daten vorhält, der Collector aber während stark ausgelasteter Zeiträume stillschweigend hochvolumige Event-IDs verwirft, entspricht die scheinbare Aufbewahrungsrichtlinie nicht der tatsächlichen forensischen Abdeckung.
Definieren Sie für Tier-0-Beweise, welche Events während des gesamten Reaktionszeitraums durchsuchbar bleiben müssen. Änderungen an privilegierten Gruppen, Verzeichnisobjektänderungen, Zertifikatausstellung, DCSync-relevante Objektzugriffe und hochwertige Kerberos-Events sollten nicht als verzichtbare Debug-Telemetrie behandelt werden. Sie sind die Beweise, die es Verteidigern ermöglichen zu rekonstruieren, was geändert wurde, wer es geändert hat und ob derselbe Pfad nach der Behebung erneut genutzt wurde.
Validierung Nach Änderungen Der Audit-Richtlinie
Bestätigen Sie nach Änderungen der Audit-Richtlinie, dass die Überwachungskette durchgängig funktioniert:
- prüfen Sie, dass die erwarteten Events auf den betroffenen Domain Controllern erscheinen
- bestätigen Sie, dass dieselben Events Ihren Collector oder Ihr SIEM ohne übermäßige Verzögerung oder stille Verluste erreichen
- testen Sie mindestens eine kontrollierte administrative Aktion und eine unbedenkliche Kerberos-Aktion, um Parsing und Feldzuordnung zu validieren
- prüfen Sie die Aufbewahrung, um sicherzustellen, dass kritische Beweise noch vorhanden sind, wenn Ermittler sie benötigen
- bestätigen Sie, dass 4662 und 5136 den Objekt- und Attributkontext enthalten, der für Verzeichnisuntersuchungen benötigt wird
- bestätigen Sie, dass 4769 die Verschlüsselungs- und Dienstinformationen enthält, die für Kerberos-Untersuchungen benötigt werden
- bestätigen Sie, dass AD-CS-Events vorhanden sind, falls Zertifikatsdienste in der Umgebung existieren
Verwandte Kontrollen
Dieser Beitrag passt natürlich zu AD-Passwortsicherheit: Fehlkonfigurationen die Angreifer Lieben, NTLM-Relay-Angriffe: Erkennung und Prävention, GPO-Fehlkonfigurationen als Angriffsvektor, Veraltete und Überprivilegierte Konten in AD und Kerberos-Delegation: unkontrolliert bis RBCD. Gute Überwachung ist das, was Teams beweisen lässt, dass diese Probleme behoben wurden, und erkennen lässt, wenn sie erneut auftreten.
Primärquellen
Entdecken Sie die Identity-Security-Seiten zu diesem Thema

