Die zehn wichtigsten auf einen Blick: 4624 (Anmeldung, auf den Typ achten), 4625 (Fehlschlag, in Serie), 4672 (Admin-Rechte auf Nicht-Admin-Systemen), 4688 (Prozess mit Befehlszeile), 4104 (PowerShell-Skriptblock), 7045 (neuer Dienst), 4698 (neue geplante Aufgabe), 4728/4732/4756 (Änderung privilegierter Gruppen), 4769 (Diensticket mit RC4, Kerberoasting) und 1102 (Security-Log gelöscht, immer ein Alarm). Ohne erweiterte Überwachungsrichtlinie, Befehlszeile in 4688 und Script Block Logging entstehen die Hälfte davon nicht.
Windows schreibt bei jeder Anmeldung, jedem Prozessstart, jeder Gruppenänderung und jedem gelöschten Protokoll ein Ereignis mit einer Event-ID ins Eventlog. Für die Sicherheit zählen davon vielleicht vierzig, und genau die entscheiden, ob dein SIEM einen Angreifer sieht oder nur Rauschen. Dieser Beitrag ist als Referenz gedacht: die wichtigsten Windows-Event-IDs für die Erkennung, nach Angriffsphasen sortiert, mit dem, wonach du in jedem Ereignis suchen musst, und mit den Einstellungen, ohne die die meisten dieser Ereignisse gar nicht erst entstehen.
Tipp: Zu den Event-IDs in den Tabellen gibt es ausführliche Einträge im Event-ID-Lexikon, jeweils mit allen wichtigen Feldern, Detection-Hinweisen, typischen Fehlalarmen, der nötigen Audit-Einstellung und einer Sigma-Regel. Ein Klick auf die ID in der Tabelle führt direkt dorthin.
Vorbereitung: ohne Audit-Richtlinie kein Log
Die wichtigste Erkenntnis zuerst: Windows protokolliert viele sicherheitsrelevante Ereignisse in der Standardkonfiguration nicht. Vier Einstellungen per Gruppenrichtlinie sind Pflicht, bevor die Tabellen unten etwas nützen.
- Erweiterte Überwachungsrichtlinie. Microsoft veröffentlicht Empfehlungen zur Überwachungsrichtlinie für Clients, Server und Domain Controller. Sie sind die Grundlage; ohne sie fehlen Kontoverwaltung, Anmeldeereignisse und Prozessverfolgung ganz oder teilweise.
- Befehlszeile in Prozessereignissen. Die Richtlinie „Befehlszeile in Prozesserstellungsereignissen einschließen“ sorgt dafür, dass Event 4688 die vollständige Kommandozeile enthält. Ohne sie siehst du, dass powershell.exe gestartet wurde, aber nicht, womit.
- PowerShell Script Block Logging. Protokolliert den tatsächlich ausgeführten Code, auch wenn er kodiert oder verschleiert übergeben wurde. Die wichtigste einzelne Logquelle gegen Angriffe, die keine Schadsoftware mitbringen.
- Sysmon. Der kostenlose Systemdienst von Microsoft ergänzt das Security-Log um Ereignisse, die Windows selbst nicht liefert: Netzwerkverbindungen pro Prozess, DNS-Anfragen, Zugriffe auf den LSASS-Prozess, geladene Treiber. Einrichtung und Konfiguration stehen im eigenen Beitrag; hier stehen die wichtigsten Sysmon-IDs mit dabei.
Dazu kommt die zentrale Sammlung. Ein lokales Eventlog mit 20 MB Größe ist nach einem Tag überschrieben; die Ereignisse müssen per Agent oder Windows Event Forwarding in ein SIEM, bevor der Angreifer sie löscht. Wie lange sie dort aufbewahrt und wie sie vor Manipulation geschützt werden, steht im Beitrag zu Log-Management und Aufbewahrung.
Anmeldungen: die Event-IDs 4624, 4625 und ihre Verwandten
Fast jeder Angriff in einer Windows-Umgebung läuft über Anmeldungen, und die Ereignisse dazu sind die ergiebigste Quelle im Security-Log.
| Event-ID | Bedeutung | Wonach du suchst |
|---|---|---|
| 4624 | Erfolgreiche Anmeldung | Anmeldetyp, Quelladresse, Konto. Typ 3 (Netzwerk) von Arbeitsplatz zu Arbeitsplatz, Typ 10 (RDP) außerhalb der Arbeitszeit, Typ 9 (NewCredentials) als Hinweis auf runas /netonly oder Pass-the-Hash. |
| 4625 | Fehlgeschlagene Anmeldung | Viele Fehlschläge für viele Konten von einer Quelle (Password Spraying), viele für ein Konto (Brute Force), Fehlercode 0xC000006A (falsches Passwort) gegen 0xC0000064 (Konto existiert nicht). |
| 4648 | Anmeldung mit expliziten Anmeldeinformationen | Ein Konto meldet sich als ein anderes an. Normal bei Admins, verdächtig bei Dienstkonten und außerhalb von Admin-Systemen. |
| 4672 | Besondere Rechte für neue Anmeldung | Ein Konto mit Admin-Rechten hat sich angemeldet. Auf einem Arbeitsplatzrechner, der kein Admin-System ist, ein starkes Signal. |
| 4776 | NTLM-Anmeldeversuch am Domain Controller | NTLM statt Kerberos dort, wo Kerberos möglich wäre; Fehlschläge in Serie. |
| 4740 | Konto gesperrt | Mehrere Sperrungen in kurzer Zeit deuten auf Spraying oder ein fehlkonfiguriertes Skript. |
Die Anmeldetypen in 4624 sind der Schlüssel zur Interpretation: 2 interaktiv an der Konsole, 3 über das Netz (Freigaben, WMI, PsExec), 4 Stapelverarbeitung, 5 Dienststart, 7 Entsperren, 9 neue Anmeldeinformationen, 10 Remote Desktop, 11 zwischengespeicherte Anmeldeinformationen ohne Domain Controller. Eine Regel, die Typ 10 für Konten außerhalb der Admin-Gruppe meldet, erzeugt kaum Fehlalarme und fängt einen erheblichen Teil der seitlichen Bewegungen.
Konten und Gruppen
| Event-ID | Bedeutung | Wonach du suchst |
|---|---|---|
| 4720 | Benutzerkonto erstellt | Jedes neue Konto, das nicht aus dem Provisionierungsprozess kommt. Angreifer legen sich gern ein unauffälliges zweites Konto an. |
| 4722 / 4725 / 4726 | Konto aktiviert / deaktiviert / gelöscht | Reaktivierung alter Konten, Löschungen kurz nach Nutzung. |
| 4724 | Passwort zurückgesetzt | Zurücksetzen durch ein anderes Konto als das Helpdesk-Konto. |
| 4728 / 4732 / 4756 | Mitglied zu globaler / lokaler / universeller Gruppe hinzugefügt | Jede Änderung an Domain-Admins, Enterprise-Admins, lokalen Administratoren und Gruppen mit Zugriff auf Backups oder Virtualisierung. |
| 4738 | Benutzerkonto geändert | Änderungen an Kontooptionen, etwa „Passwort läuft nie ab“ oder Aufhebung der Vorauthentifizierung (Vorbereitung für AS-REP-Roasting). |
| 4798 / 4799 | Gruppenmitgliedschaft eines Benutzers / einer Gruppe aufgezählt | Erkundungswerkzeuge fragen in kurzer Zeit viele Gruppen ab. |
Prozesse, Dienste, geplante Aufgaben
| Event-ID | Log | Bedeutung | Wonach du suchst |
|---|---|---|---|
| 4688 | Security | Prozess erstellt | Elternprozess und Befehlszeile. Office startet PowerShell, PowerShell mit -enc, certutil oder bitsadmin lädt aus dem Internet, rundll32 ohne Argumente. |
| 1 (Sysmon) | Sysmon | Prozess erstellt, mit Hashes und Elternkette | Wie 4688, aber mit Datei-Hash, Signatur und der vollständigen Prozessabstammung. |
| 4104 | PowerShell/Operational | Skriptblock ausgeführt | Schlüsselwörter wie Invoke-Mimikatz, DownloadString, FromBase64String, AMSI-Umgehungen, ungewöhnlich lange Skripte. Wie daraus eine Erkennung wird: Verschleierte PowerShell erkennen. |
| 7045 | System | Dienst installiert | Neue Dienste mit zufälligen Namen oder Pfaden in Temp-Verzeichnissen. PsExec und viele Tunnel-Werkzeuge hinterlassen genau das. |
| 4697 | Security | Dienst installiert (Security-Sicht) | Dasselbe mit dem auslösenden Konto. |
| 4698 / 4702 / 4699 | Security | Geplante Aufgabe erstellt / geändert / gelöscht | Aufgaben, die Skripte aus Benutzerverzeichnissen starten. Ein Klassiker für Persistenz. |
| 10 (Sysmon) | Sysmon | Prozesszugriff | Zugriff auf lsass.exe durch einen anderen Prozess als die bekannten Systemkomponenten: das Auslesen von Zugangsdaten. |
| 3 (Sysmon) | Sysmon | Netzwerkverbindung | Welcher Prozess spricht mit welchem Ziel. Ein Word-Prozess mit ausgehender Verbindung ist selten legitim. |
| 22 (Sysmon) | Sysmon | DNS-Anfrage | Anfragen an frisch registrierte, sehr lange oder zufällig wirkende Domains, zugeordnet zum anfragenden Prozess. Wie daraus eine Erkennung wird: DNS-Tunneling erkennen. |
Kerberos und Active Directory
| Event-ID | Bedeutung | Wonach du suchst |
|---|---|---|
| 4768 | Kerberos-TGT angefordert | Anforderungen für viele Konten von einer Quelle, Fehlercodes in Serie. Ein 4624 ohne vorheriges 4768 deutet auf ein Golden Ticket. |
| 4769 | Kerberos-Diensticket angefordert | Tickets mit Verschlüsselungstyp 0x17 (RC4) für Dienstkonten: das Muster von Kerberoasting. Viele Anforderungen für verschiedene Dienste in Sekunden. |
| 4771 | Kerberos-Vorauthentifizierung fehlgeschlagen | Das Kerberos-Gegenstück zu 4625. |
| 4662 | Vorgang an einem AD-Objekt | Replikationsrechte, die von einem Konto genutzt werden, das kein Domain Controller ist: DCSync, also das Abziehen aller Passwort-Hashes der Domain. |
| 5136 | Verzeichnisdienstobjekt geändert | Änderungen an Gruppenrichtlinien und Berechtigungen, die sich sonst nirgends zeigen. |
Spuren verwischen und seitliche Bewegung
| Event-ID | Log | Bedeutung | Wonach du suchst |
|---|---|---|---|
| 1102 | Security | Sicherheitsprotokoll gelöscht | Immer ein Alarm. Es gibt keinen legitimen Grund, das Security-Log auf einem Server zu leeren. |
| 104 | System | Protokoll gelöscht | Dasselbe für System- und Anwendungslog. |
| 4719 | Security | Überwachungsrichtlinie geändert | Ein Angreifer, der die Protokollierung abschaltet, bevor er weiterarbeitet. |
| 5140 / 5145 | Security | Netzwerkfreigabe / Freigabeobjekt zugegriffen | Zugriffe auf ADMIN$ und C$ von Arbeitsplatzrechnern aus: PsExec, Kopieren von Werkzeugen, Vorbereitung der Verschlüsselung. Die Erkennung dazu: Seitliche Bewegung erkennen. |
| 21 / 24 / 25 | TerminalServices-LocalSessionManager | RDP-Sitzung angemeldet / getrennt / wieder verbunden | RDP-Ketten von System zu System, Sitzungen zu ungewöhnlichen Zeiten. |
| 5861 (siehe Sysmon 19 bis 21) | WMI-Activity/Operational | Permanenter WMI-Ereigniskonsument registriert | Eine seltene, aber sehr hartnäckige Persistenzmethode. Jeder Treffer verdient einen Blick. |
| 1116 / 1117 | Windows Defender/Operational | Schadsoftware erkannt / Aktion ausgeführt | Nicht der Fund allein, sondern Häufung auf einem System oder Funde von Werkzeugen wie Mimikatz, die auf einen laufenden Angriff hindeuten. |
Linux: auth.log, auditd und das Journal
Linux kennt keine Event-IDs, aber dieselben Fragen. Die Antworten liegen in drei Quellen: dem Anmeldeprotokoll (auth.log bei Debian und Ubuntu, secure bei RHEL-Ableitungen, oder das systemd-Journal), dem Audit-Subsystem auditd, das mit Regeln jeden Systemaufruf, Dateizugriff und Befehl protokollieren kann, und den Logs der Dienste selbst, allen voran SSH und sudo. Ohne auditd-Regeln fehlt auf Linux das, was 4688 auf Windows liefert: die Befehlszeile jedes gestarteten Programms.
| Quelle | Ereignis | Wonach du suchst |
|---|---|---|
| auth.log, sshd | Accepted password / publickey, Failed password, Invalid user | Fehlschläge in Serie für viele Benutzer (Spraying), erfolgreiche Anmeldung nach vielen Fehlschlägen, Passwort-Anmeldung dort, wo nur Schlüssel erlaubt sein sollten, Anmeldungen als root |
| auth.log, sudo | COMMAND= | Jeder sudo-Aufruf mit Befehl; Ausführung von Shells, Editoren mit Shell-Escape, curl oder wget durch Dienstkonten |
| auth.log | useradd, usermod, groupadd, passwd | Neue Benutzer, Aufnahme in sudo oder wheel, Passwortänderungen außerhalb des Wartungsfensters |
| auditd, SYSCALL execve | Prozessstart mit Argumenten | Das Linux-Gegenstück zu 4688: verdächtige Befehlszeilen, Webserver-Prozesse, die Shells starten, Base64-Dekodierung in Pipelines |
| auditd, Dateiregeln | Zugriff auf /etc/passwd, /etc/shadow, /etc/sudoers, SSH-Schlüssel, Cron-Verzeichnisse | Schreibzugriffe durch andere Prozesse als die Systemwerkzeuge; neue authorized_keys als Persistenz |
| cron, systemd | Neue Cron-Einträge, neue Units und Timer | Persistenz über geplante Ausführung, Units in Benutzerverzeichnissen oder Temp-Pfaden |
| Kernel, auditd | Geladene Module, Capabilities | Neue Kernel-Module, Prozesse mit CAP_SYS_ADMIN, die es nicht brauchen |
Als Startpunkt für auditd-Regeln hat sich das öffentliche Regelwerk von Florian Roth bewährt, das nach demselben Prinzip wie eine gute Sysmon-Konfiguration filtert: ausführbare Aufrufe und sicherheitsrelevante Dateien protokollieren, Rauschen wie Zeitabfragen ausnehmen. Wazuh liest auditd und auth.log ohne weitere Konfiguration und bringt Regeln dafür mit; die Sigma-Sammlung hat einen eigenen Zweig für Linux-Auditd-Ereignisse.
Cloud-Identität: die Anmeldeprotokolle von Entra ID
Die Hälfte der realen Vorfälle beginnt heute nicht mit 4624, sondern mit einer Anmeldung in der Cloud, und dort gibt es keine Event-IDs, sondern Protokolle mit Feldern. In Microsoft Entra ID sind es das Anmeldeprotokoll (interaktive und nicht-interaktive Anmeldungen, Dienstprinzipale), das Überwachungsprotokoll (Änderungen an Benutzern, Gruppen, Rollen, Anwendungen) und die Risikoerkennungen, wenn die Lizenz sie einschließt. Die Ereignisse tragen Fehlercodes, die dieselbe Rolle spielen wie die Statuscodes in 4625.
| Protokoll | Was du ansiehst | Wonach du suchst |
|---|---|---|
| Anmeldeprotokoll | Fehlercode 50126 (falsches Passwort), 50053 (Konto gesperrt), 50076 und 50074 (MFA erforderlich oder fehlgeschlagen) | Viele 50126 für viele Konten von einer Adresse: Password Spraying. Erfolgreiche Anmeldung nach einer Serie 50126: Treffer |
| Anmeldeprotokoll | MFA-Ergebnis und Authentifizierungsmethode | Erfolgreiche Anmeldung mit MFA von unbekanntem Gerät und unbekannter Adresse nach Push-Bestätigung: Token-Diebstahl oder MFA-Ermüdung |
| Anmeldeprotokoll | Standort, Gerät, Anwendung, Konformität | Unmögliche Reisen, Legacy-Protokolle wie IMAP oder SMTP-Auth ohne MFA, Anmeldungen an Anwendungen, die das Konto nie nutzt |
| Überwachungsprotokoll | Authentifizierungsmethode registriert, Rolle zugewiesen, Benutzer angelegt | Neue MFA-Methode kurz nach einer verdächtigen Anmeldung, Zuweisung von Globaler Administrator, neue Benutzer außerhalb der Provisionierung |
| Überwachungsprotokoll | Zustimmung zu Anwendung, App-Registrierung, neue Anmeldeinformationen für Dienstprinzipale | OAuth-Zustimmungen mit weitreichenden Berechtigungen durch Benutzer, neue Geheimnisse an bestehenden Anwendungen: Persistenz in der Cloud |
| Exchange- und M365-Audit | New-InboxRule, Set-Mailbox mit Weiterleitung, Add-MailboxPermission | Postfachregeln mit Weiterleitung oder Löschung, Delegationen: die Spuren des Business Email Compromise |
Die Anbindung an das SIEM läuft über die Diagnoseeinstellungen des Tenants oder die Microsoft-Graph-API, und die Aufbewahrung im Tenant selbst ist ohne Zusatzlizenz auf 30 Tage begrenzt; spätestens das ist der Grund, die Protokolle zu exportieren. Wie aus einer verdächtigen Cloud-Anmeldung ein Vorfall wird und in welcher Reihenfolge reagiert wird, steht im Phishing-Playbook.
Womit du anfängst
Wer mit einem leeren SIEM startet, nimmt nicht alle vierzig, sondern die zehn, die den größten Teil der Angriffswege abdecken: 4624 mit Typ 10 außerhalb der Admin-Gruppe, 4625 in Serie, 4672 auf Nicht-Admin-Systemen, 4688 mit Befehlszeile für die bekannten verdächtigen Kombinationen, 4104 mit Schlüsselwörtern, 7045, 4698, 4728/4732/4756 für privilegierte Gruppen, 4769 mit RC4 und 1102. Jede dieser Regeln lässt sich einer ATT&CK-Technik zuordnen, und für fast alle gibt es fertige Sigma-Regeln, die nur noch an die eigene Umgebung angepasst werden müssen. Microsofts Liste der zu überwachenden Ereignisse für Active Directory ist die offizielle Ergänzung, mit einer Kritikalitätsbewertung pro Ereignis.
Typische Fehler
- Alles sammeln. Event 4688 auf jedem Client ohne Filter und 5156 für jede Netzwerkverbindung erzeugen Datenmengen, die das Budget sprengen, bevor eine Regel greift. Erst die Quellen mit hoher Aussagekraft, dann filtern, dann erweitern.
- Nur Domain Controller. Die Domain Controller sehen Anmeldungen und Kontoverwaltung, aber nicht, was auf dem Arbeitsplatzrechner passiert. Der Prozessstart, der den Angriff verrät, steht im Log des Clients.
- Ereignisse ohne Kontext. 4624 allein ist wertlos. Erst Anmeldetyp, Quelle, Konto und Uhrzeit zusammen ergeben eine Regel, die etwas aussagt.
- Nie getestet. Ob die Regel für Kerberoasting greift, weißt du erst, wenn jemand Kerberoasting ausführt. Dafür gibt es Purple-Team-Übungen.
Fazit
Windows-Event-IDs sind das Rohmaterial der Erkennung in fast jeder Unternehmensumgebung. Der Wert liegt nicht in der Menge, sondern in der Auswahl und im Kontext: die richtigen vierzig Ereignisse, mit Befehlszeile und Skriptblock, zentral gesammelt, zu Regeln kombiniert, die eine Angriffstechnik beschreiben statt ein Einzelereignis. Wer diese Liste einmal sauber umgesetzt hat, sieht die meisten Schritte, die ein Angreifer zwischen Einbruch und Verschlüsselung machen muss.