Ein erfahrener Forensiker kann aus Windows Event Logs den vollständigen Ablauf eines Angriffs rekonstruieren — wenn die richtigen Audit-Policies aktiviert waren.
Kritische Event-IDs — die Nadel im Heuhaufen finden
Die Windows Security Event Logs umfassen über 600 verschiedene Event-IDs, aber nur eine Handvoll sind für die Forensik wirklich relevant. Die Herausforderung: Viele der wertvollsten Events werden nur generiert, wenn die entsprechende Advanced Audit Policy aktiviert ist — in einer Standard-Windows-Installation fehlen sie vollständig. Die Basis-Konfiguration über die alte „Audit Policy“ (secpol.msc → Local Policies → Audit Policy) kennt nur 9 Kategorien mit An/Aus — die Advanced Audit Policy Configuration (Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration) bietet 59 Unterkategorien mit granularer Kontrolle. Kritisch: Wenn beide konfiguriert sind, gewinnt die alte Basis-Policy und überschreibt die Advanced-Policy — ein häufiger Fehler, der dazu führt, dass Administratoren glauben, die Advanced Policy sei aktiv, während tatsächlich die Basis-Policy greift.
Die Logon-Events bilden das Rückgrat jeder Forensik-Analyse. Event 4624 (erfolgreicher Logon) enthält den Logon Type, der den Authentifizierungsmechanismus verrät: Type 2 (Interactive/Konsole), Type 3 (Network — SMB, RPC), Type 7 (Unlock), Type 10 (RemoteInteractive/RDP). Besonders wertvoll sind die Felder LogonProcessName und AuthenticationPackageName: NtLmSsp / NTLM deutet auf NTLM-Authentifizierung hin (potenziell Pass-the-Hash), während Kerberos auf eine Ticket-basierte Authentifizierung zeigt. Das Feld ImpersonationLevel zeigt, ob der anmeldende Benutzer Delegation erlaubt hat — ein Wert von Delegation in Kombination mit einem Service-Account ist ein starker Indikator für Unconstrained Delegation Abuse.
- Die 15 wichtigsten Security Event-IDs:
4624(erfolgreicher Login — mit Logon Type!),4625(fehlgeschlagener Login — Brute-Force-Erkennung),4648(Logon mit expliziten Credentials — RunAs, PsExec),4672(spezielle Privilegien zugewiesen — Admin-Login),4688(neuer Prozess erstellt — Command-Line!),4697(neuer Service installiert — Persistence),4698(Scheduled Task erstellt — Persistence),4720(neues Benutzerkonto erstellt),4732(Mitglied zu lokaler Gruppe hinzugefügt),4768(TGT Request — Kerberos),4769(TGS Request — Kerberoasting),4776(NTLM-Validierung — Pass-the-Hash),5145(Netzwerkshare-Zugriff — Lateral Movement),7045(System-Log: neuer Service — Malware-Persistence),1102(Audit-Log gelöscht — Anti-Forensik!). - Event 4688 mit Command Line Auditing: Standardmäßig enthält Event 4688 (Prozess-Erstellung) keine Kommandozeile. Aktivierung: GPO → Administrative Templates → System → Audit Process Creation → „Include command line in process creation events“. Dies ist die einzelne wertvollste Audit-Einstellung: Sie sehen jeden ausgeführten Befehl inklusive Parameter. Suchen Sie nach:
powershell -enc(Base64-kodierte Befehle),cmd /cmitwhoami/net user/net group(Reconnaissance),certutil -urlcacheoderbitsadmin /transfer(LOLBin-Downloads). - Logon-Korrelation für Lateral Movement: Kombinieren Sie
4624 Logon Type 3(Netzwerk-Login) mit4648(explizite Credentials) und5140/5145(Share-Zugriff). Ein Muster wie: System A → 4648 (RunAs mit anderen Credentials) → System B → 4624 Type 3 (Netzwerk-Login von System A) → 5145 (Zugriff auf ADMIN$ oder C$) ist der klassische PsExec-basierte Lateral Movement. Überwachen Sie speziell Zugriffe auf die SharesIPC$,ADMIN$undC$. - PowerShell-Logging (die drei Ebenen): 1) Module Logging (Event 4103) — protokolliert alle ausgeführten PowerShell-Module mit Ein-/Ausgabe. 2) Script Block Logging (Event 4104) — protokolliert den vollständigen Skripttext, auch nach Deobfuskation (PowerShell dekodiert Base64 und expandiert Variablen vor der Ausführung — das Ergebnis wird geloggt). 3) Transcription — schreibt die gesamte PowerShell-Session in eine Textdatei. Event 4104 ist die effektivste Einzelmaßnahme gegen PowerShell-basierte Angriffe: Selbst
Invoke-MimikatzoderInvoke-BloodHoundwerden im Klartext protokolliert.
Sysmon — die fehlende Telemetrie nachrüsten
Sysmon (System Monitor) ist ein kostenloses SysInternals-Tool von Microsoft, das detaillierte Telemetrie über Prozesse, Netzwerkverbindungen, Dateiänderungen, Registry-Operationen und DNS-Anfragen liefert — Informationen, die in den Standard-Windows-Event-Logs nicht enthalten sind. Sysmon läuft als Kernel-Treiber und Service und überlebt auch Versuche, den Service zu stoppen (es überwacht seine eigene Integrität). Die Konfiguration erfolgt über eine XML-Datei, die definiert, welche Events generiert werden und welche Filter angewendet werden. Die bekannteste Community-Konfiguration ist SwiftOnSecurity/sysmon-config — ein gut gepflegtes, produktionsreifes Regelwerk, das Rauschen minimiert und sicherheitsrelevante Events priorisiert.
Die 26 Sysmon Event-IDs decken Bereiche ab, die native Windows-Events nicht bieten: Event 1 (Process Create) enthält im Gegensatz zu Event 4688 auch den Parent Process, den File Hash (MD5/SHA256/IMPHASH) und die Original File Name (aus dem PE-Header — kann nicht durch Umbenennen getäuscht werden). Event 3 (Network Connection) zeigt, welcher Prozess eine Netzwerkverbindung herstellt — unverzichtbar für die Erkennung von C2-Kommunikation (Command & Control). Event 22 (DNS Query) protokolliert jede DNS-Anfrage mit dem anfragenden Prozess — perfekt für die Erkennung von DNS-basierter Datenexfiltration oder DNS-over-HTTPS (DoH) Tunnel.
- Sysmon Deployment:
sysmon64.exe -accepteula -i sysmonconfig-export.xmlinstalliert Sysmon mit der angegebenen Konfiguration. Updates der Konfiguration im laufenden Betrieb:sysmon64.exe -c sysmonconfig-new.xml. Deployment per GPO: Kopieren Siesysmon64.exeund die Config in SYSVOL, erstellen Sie ein Startup-Skript. Events erscheinen unterMicrosoft-Windows-Sysmon/Operational. - Wichtigste Sysmon-Event-IDs für DFIR:
1(Process Create — mit Hash und Parent),3(Network Connection — C2-Erkennung),7(Image Loaded — DLL-Sideloading),8(CreateRemoteThread — Process Injection),10(ProcessAccess — Mimikatz liest lsass.exe),11(FileCreate — Malware-Drops),13(RegistryValue Set — Persistence),15(FileCreateStreamHash — ADS-Nutzung),22(DNS Query — C2-Domänen),23(FileDelete — Anti-Forensik-Erkennung). - Sysmon Event 10 — der Mimikatz-Detektor: Event 10 (ProcessAccess) wird generiert, wenn ein Prozess auf den Speicher eines anderen Prozesses zugreift. Konfigurieren Sie einen Filter für Zugriffe auf
lsass.exemitGrantedAccess-Werten von0x1010oder0x1410(PROCESS_QUERY_LIMITED_INFORMATION + PROCESS_VM_READ). Jeder Zugriff auf lsass.exe außer von bekannten System-Prozessen (csrss.exe, services.exe) ist hochgradig verdächtig und ein starker Indikator für Credential-Dumping. - Event Log Forwarding (WEF): Windows Event Forwarding sammelt Events von allen Endpoints zentral auf einem Windows Event Collector (WEC). Konfiguration: 1) Auf dem Collector:
wecutil qc(Quick Config). 2) GPO auf den Quellsystemen: Computer Configuration → Administrative Templates → Windows Components → Event Forwarding → Subscription Manager URL:Server=http://collector:5985/wsman/SubscriptionManager/WEC. 3) Subscription erstellen:wecutil cs subscription.xml. Von dort können Events an ein SIEM (Splunk, Elastic, Wazuh) weitergeleitet werden.
Anti-Forensik & Log-Schutz — wie Angreifer Spuren verwischen
Erfahrene Angreifer wissen, dass Event Logs ihre größte Bedrohung sind — und versuchen aktiv, sie zu manipulieren oder zu löschen. Die einfachste Methode ist wevtutil cl Security (löscht das Security-Log) — aber dies erzeugt ironischerweise Event 1102 („The audit log was cleared“), das als letztes Event geschrieben wird, bevor das Log geleert wird. Ein leeres Security-Log mit nur einem Event 1102 ist der eindeutigste Beweis für einen Sicherheitsvorfall. Fortgeschrittene Angreifer verwenden daher subtilere Techniken: Event Log Service Manipulation — der Angreifer stoppt den EventLog-Service nicht direkt (das würde auffallen), sondern patcht den Event-Log-Thread im Speicher. Das Tool Phant0m identifiziert die Threads des Event-Log-Service und terminiert sie einzeln, während der Service-Prozess (svchost.exe) weiterzulaufen scheint. Neue Events werden einfach nicht mehr geschrieben — ohne dass der Service als „gestoppt“ markiert wird.
Eine noch raffiniertere Technik ist das selektive Löschen einzelner Events aus EVTX-Dateien. Das EVTX-Format speichert Events als verkettete Records mit Prüfsummen. Tools wie danderspritz-evtx (aus dem NSA-Leak) können einzelne Records aus einer EVTX-Datei entfernen und die Prüfsummen neu berechnen — das modifizierte Log sieht äußerlich intakt aus. Verteidigung: Echtzeit-Log-Forwarding an einen zentralen, gehärteten Log-Server. Wenn die Logs in Echtzeit an ein SIEM gesendet werden, kann der Angreifer die lokale Kopie löschen, aber die zentrale Kopie bleibt intakt.
- Event Log Größe erhöhen: Standard-Security-Log-Größe: 20 MB — bei aktivem Auditing in weniger als 24 Stunden voll. Überschreibungsmodus „Overwrite events as needed“ bedeutet, dass älteste Events verloren gehen. Empfehlung: Mindestens 1 GB für Security, 256 MB für System, 256 MB für Sysmon. GPO: Computer Configuration → Administrative Templates → Windows Components → Event Log Service → Security → Maximum Log Size = 1048576 KB.
- Manipulationserkennung: Prüfen Sie regelmäßig: 1) Lücken in der Event-ID-Sequenz — jedes Event hat eine RecordID, die monoton steigt. Lücken deuten auf gelöschte Events hin. 2) Zeitstempel-Anomalien — Events mit Zeitstempeln, die nicht zur Sequenz passen. 3) Event 1102 (Log cleared) — sollte nie in einer Produktionsumgebung auftreten. 4) Service-Status des EventLog-Service — regelmäßig prüfen, dass alle Threads aktiv sind.
- Gehärteter Log-Collector: Der zentrale WEF-Collector sollte ein dedizierter, gehärteter Server sein: Kein Domain-Join (oder in einer separaten Admin-Tier-OU), minimale Dienste, nur Inbound-WinRM (TCP 5985/5986), kein RDP, Festplatten-Verschlüsselung, physischer Zugang eingeschränkt. Alternativer Ansatz: Direkte Weiterleitung an ein Linux-basiertes SIEM (Wazuh, Elastic Security, Graylog) — der Angreifer müsste dann sowohl die Windows- als auch die Linux-Umgebung kompromittieren.
- Sigma-Regeln für automatische Erkennung: Sigma ist ein offener Standard für SIEM-Detection-Rules (ähnlich wie Snort für IDS). Die SigmaHQ-Regel-Sammlung enthält über 3.000 Erkennungsregeln für bekannte Angriffstechniken. Sigma-Regeln können mit sigma-cli in das Format Ihres SIEMs konvertiert werden: Splunk SPL, Elastic KQL, Microsoft Sentinel, QRadar, etc. Beispiel: Die Sigma-Regel
win_security_susp_failed_logons_single_sourceerkennt Brute-Force-Angriffe über Event 4625.
Sie benötigen Unterstützung?
Event-Log-Forensik ist die Grundlage jeder Sicherheitsuntersuchung. Wir konfigurieren Ihre Advanced Audit Policies, deployen Sysmon, richten Windows Event Forwarding ein und implementieren Sigma-basierte Erkennungsregeln in Ihrem SIEM.
Security & Firewall ansehen →
