Windows-Sicherheitsüberwachungsrichtlinien und Ereignisprotokolluntersuchung in der Praxis — Zur IT-Abteilung werden, die Ereignis 4625 lesen kann

„Seit gestern Abend wird ein Konto immer wieder gesperrt. Bitte finden Sie die Ursache.“ „Ich möchte prüfen, ob sich jemand mit dem Konto eines ausgeschiedenen Mitarbeiters anzumelden versucht hat.“ „Können Sie mir sagen, wer wann was auf diesem Server ausgeführt hat?“ — solche Anfragen erreichen IT-Verantwortliche in kleinen und mittleren Unternehmen oder Entwickler, die einem Kunden ein System ausgeliefert haben, eines Tages ganz plötzlich. Und worauf man sich dann verlässt, ist das Security-Ereignisprotokoll von Windows.

Öffnet man dann tatsächlich die Ereignisanzeige, warten dort zwei Realitäten. Das gesuchte Ereignis wurde nie erfasst (die Überwachungsrichtlinie war nicht aktiviert), oder es geht in einer Flut von Ereignissen unter (verloren im Rauschen einer aufgeblähten Protokolldatei). Sicherheitsüberwachung lässt sich „aktivieren, um aufzuzeichnen“ — aber ohne ein Design, was in welchem Umfang aufgezeichnet wird, hilft sie im Ernstfall nicht weiter.

Dieser Artikel ordnet die Mechanik der Überwachungsrichtlinie (die zwei Systeme — einfach und erweitert), die in einer kleinen bis mittleren Umgebung minimal zu aktivierenden Unterkategorien, das Lesen der gängigen Ereignis-IDs — 4624/4625/4740/4688 und weitere —, die Kapazitätsplanung des Security-Protokolls sowie das Untersuchen mit PowerShell, gestützt auf Primärquellen mit Stand August 2026. Wenn die auf dieser Seite bereits behandelten Artikel zu NTLM-Überwachung, SMB-Signierung, BitLocker und Firewall alle vom „Härten der Verteidigung“ handeln, dann handelt dieser Artikel davon, „im Nachhinein feststellen zu können, was passiert ist“ — eine Fortsetzung, die sie zusammenbindet.

1. Das Wichtigste zuerst

• Die Überwachungsrichtlinie besteht aus zwei Systemen — „einfach“ und „erweitert (Advanced Audit Policy)“ —, und man darf sie nicht mischen. Microsoft schreibt ausdrücklich, dass die Verwendung beider Systeme die Überwachungsergebnisse in einen unvorhersehbaren Zustand versetzt. Vereinheitlichen Sie auf der erweiterten Seite (über 40 Unterkategorien).¹
• Der aktuelle Zustand lässt sich mit auditpol /get /category:* prüfen. Dies listet auf, was tatsächlich gerade wirkt — unabhängig davon, ob es von einem GPO oder einer lokalen Einstellung stammt.²
• „Alles aktivieren“ darf man nicht tun. Aktiviert man Unterkategorien, die riesige Ereignismengen erzeugen, gehen die eigentlich wichtigen Ereignisse im Rauschen unter, und auch die Leistung leidet darunter. Nehmen Sie Microsofts Basisempfehlungen als Ausgangspunkt und fügen Sie nur hinzu, was Sie tatsächlich brauchen.³⁴
• Eine erfolgreiche Anmeldung ist 4624, eine fehlgeschlagene 4625. Bei 4624 lesen Sie „um welche Art von Anmeldung es sich handelt“ am Anmeldetyp ab (2 = Interaktiv, 3 = Netzwerk, 10 = Remotedesktop und so weiter).⁵
• Bei 4625 verrät der Status-/Unterstatuscode den Grund des Fehlschlags. Die gängigen sind 0xC0000064 = nicht existierender Benutzername, 0xC000006A = falsches Passwort, 0xC0000072 = deaktiviertes Konto und 0xC0000234 = Konto gesperrt.⁶
• Wo ein Ereignis erfasst wird, ist festgelegt. 4624/4625 werden auf der zugegriffenen Maschine erfasst; die Überprüfung von Anmeldeinformationen (4776) und der Kerberos-Vorauthentifizierungsfehler (4771) werden auf dem Domänencontroller erfasst. Sehen Sie auf der falschen Maschine nach, schließen Sie fälschlich „es gibt kein Protokoll“.⁶⁷⁸
• Beim Security-Protokoll ist das Gefäß selbst — maximale Größe und Vorhaltung — die halbe Miete. Ist die Vorhaltung auf Überschreiben eingestellt, verschwinden alte Ereignisse zuerst. Prüfen Sie maximale Größe und Anzahl mit Get-WinEvent -ListLog Security, und erweitern Sie sie ausgehend von der benötigten Vorhaltedauer.⁹¹⁰
• Die Befehlszeilenprotokollierung bei der Prozesserstellung (4688) ist mächtig, hat aber ihren Preis: Geheimnisse landen im Klartext im Protokoll. Prüfen Sie Ihre Skripte, bevor Sie sie aktivieren.¹¹¹²

2. Grundlagen der Überwachungsrichtlinie — „einfach“ und „erweitert“ nicht mischen

Die Windows-Überwachungsrichtlinie besteht aus zwei Systemen.¹

• Einfache Überwachungsrichtlinie: die neun Kategorieeinstellungen unter „Lokale Richtlinien > Überwachungsrichtlinie“. Dies ist das ältere System, das bereits vor Windows Vista existierte.
• Erweiterte Überwachungsrichtlinienkonfiguration (Advanced Audit Policy Configuration): die über 40 Unterkategorien-Einstellungen unter „Sicherheitseinstellungen > Erweiterte Überwachungsrichtlinienkonfiguration“. Sie zerlegt jede einfache Kategorie in mehrere Unterkategorien — beispielsweise entspricht der einen einfachen Kategorie „Kontoanmeldeereignisse überwachen“ vier Unterkategorien auf der erweiterten Seite. Eine einfache Kategorie zu aktivieren wirkt genauso, als aktiviere man alle zugehörigen Unterkategorien, wodurch auch eine große Menge an Ereignissen erfasst wird, an denen man gar nicht interessiert ist.¹

Entscheidend ist, dass diese beiden Systeme nicht kompatibel sind. Microsoft schreibt unmissverständlich: „Verwenden Sie nicht sowohl die einfache als auch die erweiterte Überwachungsrichtlinie — das kann zu unerwarteten Überwachungsergebnissen führen.“ Wird die erweiterte Überwachungsrichtlinie per Gruppenrichtlinie angewendet, werden die vorhandenen Überwachungseinstellungen dieses Computers zunächst gelöscht, bevor die erweiterten Einstellungen greifen; ab diesem Zeitpunkt lässt sich die Überwachung nur noch zuverlässig über die erweiterte Seite steuern. In Umgebungen, die die erweiterte Seite nutzen, aktivieren Sie die Sicherheitsoption „Überwachung: Erzwingen von Unterkategorieeinstellungen für Überwachungsrichtlinien (Windows Vista oder höher), um Kategorieeinstellungen für Überwachungsrichtlinien zu überschreiben“, damit die einfachen Einstellungen nicht mehr überschreiben können (auf eigenständigen Rechnern ist dies standardmäßig aktiviert).¹⁴

Die Prüfung des aktuellen Zustands ist ein einziger Befehl, ausgeführt an einer administrativen Eingabeaufforderung.²

rem Aktuell wirkende Überwachungseinstellungen unterkategorieweise auflisten
auditpol /get /category:*

rem Sicherung der Einstellungen vor Änderungen (CSV) und Wiederherstellung
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv

Die Ausgabe von auditpol ist „die im Ergebnis wirksame Richtlinie“ — unabhängig davon, ob sie von einem GPO oder einer lokalen Einstellung stammt. Sie eignet sich auch zum Abgleich, wenn eine eigentlich per GPO verteilte Einstellung offenbar nicht greift. Beachten Sie: Eine Änderung der Überwachungseinstellungen selbst wird als Ereignis 4719 erfasst, sodass sich auch im Nachhinein nachvollziehen lässt, „die Überwachung wurde unbemerkt deaktiviert“.¹²

3. Entscheidungstabelle für die minimal zu aktivierenden Unterkategorien

Der Grund, warum „vorsichtshalber alles aktivieren“ der falsche Weg ist, liegt auf der Hand. Microsoft warnt beispielsweise, dass die Erfolgsüberwachung der Unterkategorien zur Rechteverwendung ein derart riesiges Ereignisvolumen erzeugt, dass es schwierig wird, andere Einträge im Sicherheitsprotokoll zu finden, und dass dies auch die Leistung erheblich beeinträchtigen kann.⁴ Das Gefäß des Protokolls (Kapitel 5) ist endlich, sodass jedes zusätzliche Rauschen die Vorhaltedauer der tatsächlich benötigten Ereignisse verkürzt. Überwachungsdesign bedeutet, zu entscheiden, was man nicht aufzeichnet.

Microsoft veröffentlicht nach Arbeitsplatz und Server getrennte Basis- und verschärfte Empfehlungen, die den Ausgangspunkt bilden.³ Darauf aufbauend zeigt die folgende Tabelle eine Auswahl aus der Perspektive kleiner und mittlerer Umgebungen: „Was möchte ich im Vorfall minimal lesen können?“

Umgekehrt ist es im Allgemeinen am sichersten, die Objektzugriffsüberwachung von Dateisystem und Registrierung, die Rechteverwendung sowie die Paketfilter-Unterkategorien (z. B. 5152) standardmäßig unangetastet zu lassen. Diese sind bei gezielter SACL-Konfiguration oder zeitlich begrenzter Eingrenzung wertvoll, nicht als dauerhaft eingeschaltete Standardeinstellung — dauerhaft aktiv frisst das Protokoll das komplett auf.⁴

4. Wie man die gängigen Ereignis-IDs liest

4.1. 4624 — Erfolgreiche Anmeldungen nach Anmeldetyp sortieren

4624, „Ein Konto wurde erfolgreich angemeldet“, wird auf der Maschine erfasst, auf der die Anmeldesitzung erstellt wurde (die zugegriffene Maschine).⁵ Da es ein Ereignis mit hohem Volumen ist, sortiert man beim Lesen zuerst nach Anmeldetyp.⁵

Zusätzlich zu prüfende Felder sind der Kontoname unter „Neue Anmeldung“, die Quelladresse unter „Netzwerkinformationen“, das „Authentifizierungspaket“ (NTLM oder Kerberos) sowie das „Erweitertes Token“ (ob die Sitzung Administratorrechte besitzt). Wollen Sie nur Anmeldungen mit Administratorrechten verfolgen, ist auch Ereignis 4672 (Zuweisung besonderer Rechte bei der Anmeldung), das unter derselben Anmelde-ID erfasst wird, hilfreich.⁵

4.2. 4625 — Fehlschlagsgrund über den Status-/Unterstatuscode bestimmen

4625, „Ein Konto konnte nicht angemeldet werden“, wird auf der Maschine erfasst, auf der die Anmeldung versucht wurde.⁶ Statt sich auf den Wortlaut im Feld „Fehlerursache“ zu verlassen, liest man zuverlässig über den hexadezimalen Status-/Unterstatuscode. Die gängigen sind:⁶

• 0xC0000064: Nicht existierender Benutzername. Häufen sich diese in kurzer Zeit, deutet das auf einen Kontenaufzählungsangriff hin
• 0xC000006A: Falsches Passwort. Wiederholt gegen dasselbe Konto deutet das auf einen Passwort-Ratenangriff hin
• 0xC000006D: Ungültiger Benutzername oder ungültige Anmeldeinformationen
• 0xC000006F: Außerhalb der erlaubten Zeit
• 0xC0000070: Von einem nicht zugelassenen Arbeitsplatz
• 0xC0000072: Vom Administrator deaktiviertes Konto (Versuche gegen das Konto eines ausgeschiedenen Mitarbeiters zeigen sich hier)
• 0xC000015B: Der angeforderte Anmeldetyp ist auf dieser Maschine nicht erlaubt
• 0xC0000193: Abgelaufenes Konto
• 0xC0000234: Gesperrt

„Wer, woher und warum fehlgeschlagen“ lässt sich über das Dreiergespann aus Zielkonto, Quelle (Arbeitsplatzname/IP-Adresse) und diesem Code bestimmen. Kapitel 6 enthält PowerShell, mit dem sich alle drei auf einmal extrahieren lassen.

4.3. 4740 — Der Ursprung einer Sperrung ist der „Name des aufrufenden Computers“

4740, „Ein Benutzerkonto wurde gesperrt“ (Unterkategorie: Benutzerkontenverwaltung). Das entscheidende Feld dieses Ereignisses ist „Name des aufrufenden Computers“ (Caller Computer Name), das den Computer verzeichnet, von dem der die Sperrung auslösende Anmeldeversuch ausging.¹⁶ Das übliche Vorgehen: die Ursprungsmaschine über dieses Feld identifizieren und dann auf dieser Maschine nach alten Anmeldeinformationen fahnden. Die Ursache ist meistens etwas, das nach einer Passwortänderung weiterhin die alten Anmeldeinformationen verwendet — gespeicherte Anmeldeinformationen, eine getrennte, aber noch offene RDP-Sitzung, oder ein Dienst beziehungsweise eine geplante Aufgabe mit dem alten Passwort.

Ein Punkt ist zu beachten. 4625 wird auf der Maschine erfasst, die den Anmeldeversuch entgegengenommen hat. Liegt die Ursache in einer Netzwerkanmeldung von der Ursprungsmaschine etwa zu einem Dateiserver, bleibt im Security-Protokoll der Ursprungsmaschine selbst kein 4625 zurück; die Spur findet sich stattdessen im 4625 des Zielservers oder, bei einem Domänenkonto, in 4776 (NTLM) beziehungsweise 4771 (Kerberos-Vorauthentifizierungsfehler) auf dem DC.⁷⁸ Ist „im Protokoll der Ursprungsmaschine nichts zu finden“, sehen Sie auf der empfangenden Seite nach.

4.4. Die 4720er-Familie — Kontoerstellung, -änderung und Gruppenerweiterungen

Die Kontoverwaltungsereignisse bilden eine Reihe benachbarter Nummern: 4720 (Benutzerkonto erstellt)¹⁷, 4726 (gelöscht), 4738 (geändert), und auf Gruppenseite Mitglied hinzugefügt/entfernt. Beachten Sie, dass die für eine Gruppenmitgliedschaftsänderung ausgelöste Ereignis-ID vom Gruppentyp abhängt. Bei lokalen Gruppen sind es 4732/4733, bei globalen Gruppen 4728/4729 und bei universellen Gruppen 4756/4757.¹⁴ Domain Admins ist eine globale Gruppe, eine Erweiterung dort zeigt sich also als 4728 — wer nur auf 4732 achtet, verpasst genau das Ereignis, das am wichtigsten wäre. Im Alltag ist das meist eine Aufzeichnung von Helpdesk-Arbeit, doch „ein Standardbenutzer wurde plötzlich einer Administratorgruppe hinzugefügt“ oder „es wurde ein Konto erstellt, das niemand kennt“ verdient schon als Einzelfall eine sofortige Untersuchung. Microsoft selbst nennt unerwartete Mitgliederhinzufügungen zu privilegierten Gruppen als Beispiel für ein Ereignis, das einzeln eine Warnung wert ist.³

4.5. 4688 — Prozesserstellung. Die Befehlszeilenprotokollierung ist ein separater Schalter

4688, „Ein neuer Prozess wurde erstellt“, erfasst bei jeder Prozesserstellung das erstellende Konto, den Pfad der ausführbaren Datei des neuen Prozesses, den übergeordneten Prozess sowie den Tokenerweiterungstyp.¹¹ Es ist ein Ereignis mit hohem Untersuchungswert, das die Frage „wer hat auf diesem Server was ausgeführt“ beantworten kann.

Standardmäßig werden Befehlszeilenargumente jedoch nicht erfasst. Erst wenn Sie zusätzlich die Gruppenrichtlinie „Befehlszeile in Prozesserstellungsereignisse einschließen“ (Administrative Vorlagen > System > Überwachung der Prozesserstellung) aktivieren, wird das Feld „Prozessbefehlszeile“ von 4688 mit den Argumenten befüllt.¹¹¹² Für die Verfolgung verdächtiger Starts wie powershell -EncodedCommand ... ist das praktisch unverzichtbar — aktivieren Sie es aber erst, nachdem Sie das in Kapitel 7 beschriebene Risiko der Geheimnisoffenlegung verstanden haben.

4.6. 4698 — Erstellung geplanter Aufgaben

4698, „Eine geplante Aufgabe wurde erstellt“, erfasst den Aufgabennamen sowie das vollständige XML der Aufgabendefinition (einschließlich des auszuführenden Befehls). Da die Registrierung geplanter Aufgaben eine gängige Methode ist, mit der Malware einen Neustart übersteht, empfiehlt Microsoft, Ereignisse zur Aufgabenerstellung zu überwachen.¹⁵ Auch in Umgebungen, die geplante Aufgaben geschäftlich intensiv nutzen, ist das Erstellen selbst kein tägliches Ereignis, sodass das Rauschen vergleichsweise gering bleibt.

Ein weiteres Ereignis, das man sich merken sollte, ist 1102, „Das Überwachungsprotokoll wurde gelöscht“. Das Leeren des Security-Protokolls hinterlässt stets dieses Ereignis, sodass Sie bei einem „das Protokoll ist leer“ zwischen einem Vorfall und einer routinemäßigen Aktion unterscheiden können.¹⁸

5. Design des Protokollgefäßes — maximale Größe und Vorhaltung

Bevor Sie weitere Überwachungsrichtlinien hinzufügen, prüfen Sie das aufnehmende Gefäß. Das Security-Protokoll besitzt eine maximale Größe und einen Vorhaltemodus: Im Überschreibmodus (die typische Konfiguration) überschreiben neue Ereignisse die ältesten, sobald die maximale Größe erreicht ist. Umgekehrt werden im Vorhaltemodus (nicht überschreiben), sobald das Protokoll voll ist, stattdessen die neuen Ereignisse verworfen.¹⁰ Beides kann dazu führen, dass „das Protokoll, das man braucht, einfach nicht da ist“ — die Kenntnis des aktuellen Zustands kommt deshalb zuerst.

# Gefäß des Security-Protokolls prüfen: Vorhaltemodus, maximale Größe, aktuelle Anzahl
Get-WinEvent -ListLog Security |
    Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount

# Wie viele Tage aktuell tatsächlich vorgehalten werden (Zeitstempel des ältesten Ereignisses)
Get-WinEvent -LogName Security -Oldest -MaxEvents 1 |
    Select-Object TimeCreated

Get-WinEvent -ListLog liefert Konfiguration und Anzahl des Protokolls zusammen zurück.⁹ Die Differenz zwischen dem „Zeitstempel des ältesten Ereignisses“ und der aktuellen Zeit ist die tatsächliche Vorhaltedauer; reicht diese nicht an Ihre Anforderung heran (wie viele Tage Sie für Untersuchungen zurückblicken möchten), erweitern Sie die maximale Größe. Konfigurieren lässt sich das mit wevtutil sl Security /ms:<Bytes> oder per Gruppenrichtlinie verteilen.¹⁰

Es gibt außerdem die Sicherheitsoption „Überwachung: Sofortiges Herunterfahren des Systems, wenn Sicherheitsüberwachungen nicht protokolliert werden können“ (gemeinhin CrashOnAuditFail genannt). Ist sie aktiviert und kann das System keine Überwachung mehr protokollieren, hält das System mit dem STOP-Fehler C0000244 an. Diese Einstellung existiert für Authentifizierungsanforderungen, bei denen ein Überwachungspfad unter keinen Umständen verloren gehen darf, und ist standardmäßig deaktiviert. Microsoft selbst weist darauf hin, dass sich dies zu einer DoS-Möglichkeit umfunktionieren lässt — ein Angreifer erzwingt absichtlich eine Flut von Ereignissen, um einen Server anzuhalten —, weshalb es in einer typischen kleinen bis mittleren Umgebung nicht leichtfertig aktiviert werden sollte.¹⁹

6. Praktische Untersuchung — Filtern, Get-WinEvent und Export

6.1. Eingrenzung in der Ereignisanzeige

Für eine einmalige Untersuchung reicht die Ereignisanzeige. Öffnen Sie das Security-Protokoll und geben Sie über „Aktuelles Protokoll filtern“ eine Ereignis-ID (z. B. 4625) und einen Zeitraum an. Bedingungen, die Sie wiederholt prüfen, speichern Sie als „Benutzerdefinierte Ansicht erstellen“ — beim nächsten Mal genügt ein Klick. Wollen Sie nicht nur nach der Ereignis-ID, sondern etwa nach einem bestimmten Konto eingrenzen, können Sie im XML-Tab des Filterdialogs direkt eine XPath-Abfrage bearbeiten.

6.2. Extraktion mit Get-WinEvent

Bei Untersuchungen mit vielen Datensätzen, mehreren Bedingungen oder geplanter Ausführung wechseln Sie zu PowerShells Get-WinEvent. Entscheidend ist die Verwendung von -FilterHashtable, das den Filter serverseitig anwendet.⁹

# Anmeldefehlschläge (4625) der letzten 24 Stunden abrufen
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
}

# „Wer, woher und warum“ in eine Tabelle bringen
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
        Time      = $_.TimeCreated
        Account   = "$($d.TargetDomainName)\$($d.TargetUserName)"
        LogonType = $d.LogonType
        Source    = "$($d.WorkstationName) $($d.IpAddress)"
        Status    = $d.Status
        SubStatus = $d.SubStatus
    }
} | Group-Object Account, Status, SubStatus, Source |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

Hat man dieses Muster, EventData aus der XML-Darstellung eines Ereignisses zu extrahieren, einmal parat, lässt es sich unverändert für 4624 oder 4688 wiederverwenden. Das Design der Get-WinEvent-Filterung — wann FilterHashtable und wann XPath, und wie man eine langsame Abfrage repariert — wird ausführlich in „Ereignisprotokolle praxisnah mit Get-WinEvent untersuchen“ behandelt.

6.3. Export mit wevtutil

Bei den Protokollen der zu untersuchenden Maschine gilt die Regel, sie zuerst zu exportieren und zu sichern, bevor sie überschrieben werden.¹⁰

rem Das gesamte Security-Protokoll als evtx sichern
wevtutil epl Security C:\logs\security-20260801.evtx

rem Nur 4625 per XPath eingegrenzt exportieren
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"

Ein exportiertes .evtx lässt sich auf einer anderen Maschine genauso mit Get-WinEvent -Path C:\logs\security-20260801.evtx analysieren.⁹ Die Gewohnheit, zuerst zu sichern und dann zu analysieren, folgt demselben Gedanken wie „zuerst den Dump sichern“ bei der Absturzuntersuchung (siehe „Einführung in das Sammeln von Windows-Absturzabbildern“).

7. Fallstricke — vier, die man in der Praxis leicht übersieht

(1) Geheimnisse landen in der 4688-Befehlszeile. Aktiviert man die Befehlszeilenprotokollierung, landen die Argumente jedes Prozesses im Klartext im Security-Protokoll. Microsoft schreibt ausdrücklich: „Jeder Benutzer mit Lesezugriff auf Sicherheitsereignisse könnte die Befehlszeilenargumente für jeden erfolgreich erstellten Prozess lesen. Befehlszeilenargumente können vertrauliche Informationen wie Passwörter enthalten.“¹² Startet auch nur eine Fachanwendung oder ein Skript etwas wie myapp.exe /user:admin /password:P@ssw0rd, ist das ein Geheimnis, das jedem offenliegt, der das Protokoll einsehen kann. Prüfen Sie vor der Aktivierung, wo Geheimnisse als Befehlszeilenargumente übergeben werden, und korrigieren Sie diese Stellen. Auch der Ort, an den das Protokoll exportiert oder weitergeleitet wird, braucht dasselbe Vertraulichkeitsniveau.

(2) Betrieb ohne Kenntnis des Verhaltens bei vollem Protokoll. Im Überschreibmodus verschwinden alte Beweise stillschweigend, im Nicht-Überschreiben-Modus werden neue Ereignisse verworfen, und bei aktiviertem CrashOnAuditFail hält das gesamte System an (Kapitel 5).¹⁰¹⁹ Der richtige Weg ist, zu wissen, welches Verhalten man gewählt hat, und einen Mechanismus einzurichten — regelmäßige Exporte oder eine Protokollsammelplattform —, der die Daten sichert, bevor sie überschrieben werden.

(3) Domänencontroller und Arbeitsplätze verlangen den Blick in unterschiedliche Protokolle. 4624/4625 werden auf der zugegriffenen Maschine erfasst.⁵⁶ Die Überprüfung von Anmeldeinformationen für ein Domänenkonto (NTLMs 4776) hingegen wird auf der Maschine erfasst, die Autorität über die Anmeldeinformationen besitzt — bei einem Domänenkonto ist das der DC⁷ —, und der Kerberos-Vorauthentifizierungsfehler (4771) wird ausschließlich auf einem DC erfasst.⁸ „Kein 4625 auf dem Dateiserver“ bedeutet nicht „es gab keinen Angriff“; erst der Abgleich mit 4776/4771 auf dem DC ergibt das vollständige Bild. Wie die einzelnen Authentifizierungsprotokolle tatsächlich ablaufen, erklärt „NTLM und Kerberos anhand von Diagrammen erklärt“.

(4) Ohne Zeitsynchronisierung lässt sich nicht abgleichen. Protokolle mehrerer Maschinen nebeneinanderzulegen, um zu verfolgen, „welcher Arbeitsplatz unmittelbar vor diesem 4740 ein 4625 erzeugt hat“, funktioniert nur, wenn die Uhren aller Maschinen übereinstimmen. In einer Domänenumgebung setzt Kerberos selbst eine Obergrenze für die Zeitabweichung (standardmäßig fünf Minuten), oberhalb derer die Authentifizierung selbst zu scheitern beginnt.²⁰ Aus Untersuchungssicht kann schon eine Abweichung von wenigen Sekunden — von fünf Minuten ganz zu schweigen — die zeitliche Reihenfolge falsch erscheinen lassen; die Prüfung des Synchronisierungsstatus von w32time sollte deshalb der allererste Schritt jeder Untersuchung sein. Beachten Sie außerdem, dass Ereigniszeitstempel in UTC gespeichert und gemäß der Zeitzone der betrachtenden Maschine angezeigt werden — vergessen Sie beim Lesen einer .evtx aus einem ausländischen Standort oder von einem auf UTC konfigurierten Server nicht die Zeitzonenumrechnung.

8. Zusammenfassung

• Die Überwachungsrichtlinie besteht aus zwei Systemen, „einfach“ und „erweitert“, und deren Vermischung erzeugt unvorhersehbare Ergebnisse. Vereinheitlichen Sie auf der erweiterten Seite, prüfen Sie den aktuellen Zustand mit auditpol /get /category:*, und entwerfen Sie von dort aus.
• „Alles aktivieren“ tötet die Untersuchung durch Rauschen und Aufblähung. Nehmen Sie Microsofts Basisempfehlungen als Ausgangspunkt und arbeiten Sie sich durch die Entscheidungstabelle aus Kapitel 3, die sich um Anmeldung, Kontenverwaltung und Prozesserstellung dreht.
• 4624 liest man am Anmeldetyp, 4625 am Status-/Unterstatuscode, 4740 am Namen des aufrufenden Computers, 4688 am übergeordneten Prozess und der Befehlszeile — jedes Ereignis hat ein bestimmtes Feld, das man prüfen muss.
• Das Gefäß des Protokolls (maximale Größe, Vorhaltemodus) ist die halbe Miete beim Überwachungsdesign. Prüfen Sie, wie viele Tage tatsächlich vorgehalten werden, bemessen Sie die Größe rückwärts aus Ihrer Anforderung, und exportieren oder bündeln Sie, bevor überschrieben wird.
• Prüfen Sie vor der Aktivierung der Befehlszeilenprotokollierung für 4688 das Risiko der Geheimnisoffenlegung. Wo welches Ereignis erfasst wird und die Zeitsynchronisierung sind Voraussetzungen für maschinenübergreifende Abgleiche.
• Beginnen Sie eine Untersuchung mit den Filtern der Ereignisanzeige, wechseln Sie bei Wiederholung zu Get-WinEvent -FilterHashtable, sichern Sie mit wevtutil epl. Halten Sie die Reihenfolge „erst sichern, dann analysieren“ konsequent ein.

Verwandte Artikel

• Ereignisprotokolle praxisnah mit Get-WinEvent untersuchen — Die Geschwindigkeit der Eingrenzung entscheidet über die Untersuchungsdauer
• Bringt die NTLM-Abschaffung Ihre Fachanwendungen zum Stillstand? — Wie Sie Audit-Protokolle erfassen und in welcher Reihenfolge Sie Abhängigkeiten beseitigen
• NTLM und Kerberos anhand von Diagrammen erklärt — Warum die Authentifizierung auf NTLM zurückfällt
• SMB-Signierung und LDAP-Kanalbindung — Die „andere Hälfte“ der NTLM-Abwehr in der Praxis schließen
• Einführung in Windows-Ereignisprotokoll und ETW — Die Protokolle einer Fachanwendung auf die Standardmechanismen des Betriebssystems bringen
• Einführung in das Sammeln von Windows-Absturzabbildern - WER/ProcDump/WinDbg

Verwandte Beratungsleistungen

Die KomuraSoft LLC übernimmt Beratung zu Überwachungsrichtlinien und Protokolldesign in Windows-Umgebungen, Untersuchungen von „wann, wer, was“ auf Basis von Ereignisprotokollen sowie die Ursachenanalyse von Problemen rund um Authentifizierung und Überwachung, die Fachanwendungen verursachen. Es ist kein Problem, von einem Stand wie „mir wurde gesagt, ich soll die Protokolle prüfen, aber ich weiß nicht, wo ich anfangen soll“ zu starten.

• Fehleruntersuchung und Ursachenanalyse
• Technische Beratung und Design-Review
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wir haben keinerlei Überwachungsrichtlinie konfiguriert — warum tauchen 4624 und 4625 trotzdem im Security-Protokoll auf?

Weil Windows Überwachungsunterkategorien besitzt, die standardmäßig aktiviert sind. Die Unterkategorie „Anmeldung“ beispielsweise hat seit Windows 10 Version 1809 sowohl Erfolg als auch Fehlschlag standardmäßig aktiviert, sodass 4624 (Erfolg) und 4625 (Fehlschlag) auch ohne jede eigene Konfiguration erfasst werden. Bei den Standardeinstellungen bleiben allerdings viele Ereignisse unerfasst, die man bei einer Untersuchung tatsächlich braucht — etwa die Überprüfung von Anmeldeinformationen (4776) oder die Prozesserstellung (4688). Was in der eigenen Umgebung aktiviert ist, lässt sich mit auditpol /get /category:* prüfen. Von dort aus ist es das übliche Vorgehen, die fehlenden Unterkategorien auf Seiten der erweiterten Überwachungsrichtlinie explizit zu aktivieren.

Ich möchte eine fehlgeschlagene Anmeldung untersuchen, finde aber kein Ereignis 4625 im Security-Protokoll des Zielservers. Wo sollte ich nachsehen?

Prüfen Sie zunächst das Grundprinzip: 4625 wird auf „dem Computer, auf dem die Anmeldung versucht wurde“ erfasst. Bei einer fehlgeschlagenen Anmeldung am Arbeitsplatz eines Benutzers ist das der Arbeitsplatz selbst, bei einem fehlgeschlagenen Zugriff auf einen Dateiserver ist es der Dateiserver. Prüfen Sie als Nächstes mit auditpol /get /category:*, ob die Fehlschlagüberwachung für die Unterkategorie „Anmeldung“ aktiviert ist. Bei Domänenkonten zeigt sich die Spur häufig stattdessen bei der Überprüfung von Anmeldeinformationen (4776) oder einem Kerberos-Vorauthentifizierungsfehler (4771) auf dem Domänencontroller, und wenn sich der betroffene Arbeitsplatz nicht eingrenzen lässt, ist es oft schneller, von der DC-Seite aus zu beginnen. Finden Sie weiterhin nichts, prüfen Sie, ob ältere Ereignisse bereits überschrieben wurden (vergleichen Sie die maximale Protokollgröße mit dem Zeitstempel des ältesten Ereignisses).

Sollten wir die Befehlszeilenprotokollierung für die Prozesserstellung (4688) aktivieren?

Der Untersuchungswert ist sehr hoch, aber es ist eine Einstellung, die Sie erst aktivieren sollten, wenn Sie das Risiko verstanden haben. Nach der Aktivierung werden die Befehlszeilenargumente jedes Prozesses im Klartext im Security-Protokoll erfasst. Wenn auch nur ein einziges Skript oder eine Fachanwendung ein Passwort oder einen API-Schlüssel als Befehlszeilenargument übergibt, wird dieses Geheimnis für jeden sichtbar, der das Security-Protokoll lesen kann. Microsoft selbst weist ausdrücklich auf diesen Punkt hin. Empfehlenswert ist die Reihenfolge: zunächst prüfen, ob die eigenen Skripte Geheimnisse als Befehlszeilenargumente übergeben, die betroffenen Stellen korrigieren, und erst danach die Einstellung aktivieren.

Wie groß sollte die maximale Größe des Security-Protokolls sein?

Der richtige Ansatz ist, rückwärts von „wie viele Tage wollen wir vorhalten“ zu rechnen — eine allgemeingültige Zahl gibt es nicht. Die aktuelle Einstellung und das tatsächliche Verhalten lassen sich mit Get-WinEvent -ListLog Security prüfen; die Differenz zwischen dem Zeitstempel des ältesten Ereignisses und der aktuellen Zeit ist „wie viele Tage tatsächlich gerade vorgehalten werden“. Zusätzliche Überwachungsunterkategorien erhöhen das Ereignisvolumen, prüfen Sie deshalb nach jeder Einstellungsänderung diese tatsächliche Vorhaltedauer erneut. Bei der Reaktion auf Vorfälle werden nicht selten Protokolle benötigt, die Wochen oder Monate zurückreichen — es lohnt sich daher, das Protokoll regelmäßig zu exportieren, bevor es überschrieben wird, oder es über eine Protokollsammlung auf einer separaten Maschine zu bündeln.

Wie untersucht man die Ursache einer Kontosperrung (4740)?

Der erste Anhaltspunkt ist das Feld „Name des aufrufenden Computers“ (Caller Computer Name) im 4740-Ereignis. Es verzeichnet den Computer, von dem die fehlgeschlagene Anmeldung ausging, die die Sperrung ausgelöst hat. Beachten Sie jedoch, dass der Fehlschlagsdatensatz selbst (4625) auf der Seite verbleibt, die den Anmeldeversuch entgegengenommen hat, nicht auf der Ursprungsmaschine. Stammt die Sperrung von einer Netzwerkanmeldung, verfolgen Sie sie chronologisch über 4625 auf dem Zielserver oder, bei einem Domänenkonto, über 4776/4771 auf dem Domänencontroller. Haben Sie die Ursprungsmaschine identifiziert, prüfen Sie dort alles, was noch alte Anmeldeinformationen von vor der Passwortänderung hält — gespeicherte Anmeldeinformationen, eine getrennte, aber noch offene Remotedesktopsitzung, oder einen Dienst beziehungsweise eine geplante Aufgabe, der/die mit dem alten Passwort konfiguriert ist. Wiederholen sich die Sperrungen, prüfen Sie zusätzlich, ob die Zeitsynchronisierung abgedriftet ist.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.