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. Finden Sie die Ursache.“ „Prüfen Sie, ob jemand versucht, sich mit dem Konto eines ehemaligen Mitarbeiters anzumelden.“ „Können Sie sagen, wann und wer was auf diesem Server ausgeführt hat?“ — das sind die Anfragen, die unvermittelt bei den IT-Verantwortlichen eines kleinen oder mittleren Unternehmens oder bei einem Entwickler landen, der einem Kunden ein System ausgeliefert hat. Und worauf man sich dann stützt, ist das Security-Ereignisprotokoll von Windows.

Öffnen Sie die Ereignisanzeige, und zwei Realitäten warten. Entweder wurde das gewünschte Ereignis nie erfasst (die Überwachungsrichtlinie war nicht aktiviert), oder es geht in einer Flut von Ereignissen unter und ist unlesbar (das Protokoll ist voller Rauschen und aufgebläht). Sicherheitsüberwachung ist etwas, das man „bekommt, wenn man es einschaltet“, aber ohne ein Design, was in welchem Umfang aufgezeichnet wird, hilft sie im Ernstfall nicht.

flowchart TB
    accTitle: Die zwei Realitäten, die in der Ereignisanzeige warten
    accDescr: Öffnen Sie die Ereignisanzeige und es gibt zwei Realitäten, entweder war die Überwachungsrichtlinie nicht aktiviert und das gewünschte Ereignis wurde nie erfasst, oder das Protokoll ist voller Rauschen und aufgebläht und das Ereignis geht in einer Flut von Einträgen unter, deshalb muss man entwerfen, was in welchem Umfang aufgezeichnet wird
    open["Ereignisanzeige öffnen"] --> real{"Welche Realität wartet?"}
    real -->|Nicht erfasst| none["Das gewünschte Ereignis wurde nie erfasst"]
    real -->|Begraben| noise["Unlesbar unter einer Flut von Ereignissen"]
    none -.-> cause1["Überwachungsrichtlinie deaktiviert"]
    noise -.-> cause2["Voller Rauschen und aufgebläht"]
    none --> design["Entwerfen, was in welchem Umfang aufgezeichnet wird"]
    noise --> design

Abbildung 1: Entweder „nicht erfasst“ oder „begraben und unlesbar“. Beides kommt daher, dass der Umfang dessen, was aufgezeichnet wird, nie entworfen wurde.

Dieser Artikel trennt zwei Dinge: die Einstellungen, die die für eine Untersuchung nötigen Protokolle behalten, und das Verfahren, in den vorhandenen Protokollen die Ursache zu finden. Er behandelt, wie die Überwachungsrichtlinie funktioniert (die zwei Systeme, einfach und erweitert), die Unterkategorien, die eine kleine bis mittlere Umgebung mindestens aktivieren sollte, das Lesen von 4624/4625/4740/4688, die Kapazitätsplanung des Security-Protokolls und die Untersuchung mit PowerShell. Die technischen Erklärungen stützen sich auf Primärquellen mit Stand August 2026.

Wenn die bisher auf dieser Seite behandelten Artikel — NTLM-Überwachung, SMB-Signierung, BitLocker und die Firewall — vom Härten der Verteidigung handeln, handelt dieser Artikel davon, im Nachhinein feststellen zu können, was passiert ist, und er ist die Fortsetzung, die sie zusammenbindet.

1. Das Wichtigste zuerst

Damit Ihre Protokolle für eine Untersuchung taugen, müssen drei Dinge zusammenpassen: aufzeichnen, was Sie brauchen, das richtige Feld auf der richtigen Maschine lesen und es sichern, bevor es verschwindet. Wichtig ist, nicht beim Aktivieren der Überwachung stehen zu bleiben.

Wenn Sie die Überwachung einrichten: auf der erweiterten Seite vereinheitlichen und nur das Nötige aufzeichnen

• Die Überwachungsrichtlinie besteht aus zwei Systemen, „einfach“ und „erweitert“ (Advanced Audit Policy), und Sie dürfen sie nicht mischen. Microsoft schreibt ausdrücklich, dass die Verwendung beider Systeme die Überwachungsergebnisse in einen unerwarteten Zustand versetzt. Vereinheitlichen Sie auf der erweiterten Seite (über 40 Unterkategorien).¹
• Den aktuellen Zustand prüfen Sie mit auditpol /get /category:*. Das listet die gerade wirksamen Überwachungseinstellungen auf, unabhängig davon, ob sie von einem GPO oder von lokalen Einstellungen stammen.²
• Aktivieren Sie nicht „alles“. Unterkategorien, die riesige Ereignismengen erzeugen, begraben die wichtigen Ereignisse im Rauschen und beeinträchtigen auch die Leistung. Nehmen Sie Microsofts Basisempfehlungen als Ausgangspunkt und fügen Sie nur hinzu, was Sie brauchen.³⁴

Wenn Sie gerade untersuchen: prüfen Sie die Erfassungsmaschine und die Felder, nicht nur die Ereignis-ID

• Eine erfolgreiche Anmeldung ist 4624, ein Fehlschlag ist 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 verraten die Status-/Substatuscodes den Grund des Fehlschlags. Der Standardssatz ist 0xC0000064 = Benutzername existiert nicht, 0xC000006A = falsches Passwort, 0xC0000072 = Konto deaktiviert, 0xC0000234 = Konto gesperrt.⁶
• Auf welcher Maschine ein Ereignis erfasst wird, ist festgelegt. 4624/4625 gehen an die Maschine, auf die zugegriffen wurde, die Überprüfung von Anmeldeinformationen (4776) an die Maschine, die über die Anmeldeinformationen Autorität hat (bei einem Domänenkonto ein Domänencontroller), und der Kerberos-Vorauthentifizierungsfehler (4771) an einen Domänencontroller. Sehen Sie auf der falschen Maschine nach, diagnostizieren Sie fälschlich „es gibt kein Protokoll“.⁶⁷⁸

In beiden Fällen nötig: Vorhaltung der Protokolle und den Umgang mit Geheimnissen entwerfen

• Beim Security-Protokoll ist das Design des Behälters (maximale Größe und Vorhaltung) die halbe Arbeit. Steht die Vorhaltung auf Überschreiben, verschwinden die ältesten Ereignisse nacheinander. Prüfen Sie maximale Größe und Datensatzanzahl mit Get-WinEvent -ListLog Security und erweitern Sie sie rückwärts von der Zahl der Tage, die Sie vorhalten müssen.⁹¹⁰
• Die Befehlszeilenprotokollierung bei der Prozesserstellung (4688) ist mächtig, der Preis ist jedoch das Risiko, dass Geheimnisse im Klartext im Protokoll landen. Prüfen Sie Ihre Skripte, bevor Sie sie aktivieren.¹¹¹²

Wählen Sie den Lesepunkt nach Ziel oder Symptom

Wenn Ihnen bereits ein Untersuchungsauftrag vorliegt, sichern Sie das Protokoll nach dem Verfahren in 6.3, prüfen Sie die Hinweise zu Erfassungsmaschinen und Uhrensynchronisierung in Abschnitt 7 und lesen Sie dann das betreffende Ereignis in Abschnitt 4. Wenn Sie die Einstellungen aufräumen, prüfen Sie den aktuellen Zustand in den Abschnitten 2 und 5 und gehen Sie dann zu Abschnitt 3.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (34 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

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

2.1. Den Unterschied von Ort und Granularität verstehen

Die Windows-Überwachungsrichtlinie besteht aus zwei Systemen.¹

• Einfache Überwachungsrichtlinie: die neun Kategorieeinstellungen unter „Lokale Richtlinien > Überwachungsrichtlinie“. Das ist das ältere System von vor Windows Vista.
• Erweiterte Überwachungsrichtlinie (Advanced Audit Policy Configuration): die über 40 Unterkategorie-Einstellungen unter „Sicherheitseinstellungen > Erweiterte Überwachungsrichtlinienkonfiguration“. Jede einfache Kategorie ist in mehrere Unterkategorien zerlegt; die eine einfache Kategorie „Kontoanmeldeereignisse überwachen“ entspricht auf der erweiterten Seite beispielsweise vier Unterkategorien. Eine einfache Kategorie zu aktivieren wirkt so, als aktiviere man alle zugehörigen Unterkategorien, und erfasst riesige Mengen von Ereignissen, an denen Sie kein Interesse haben.¹

2.2. Auf der erweiterten Seite vereinheitlichen und verhindern, dass die einfache Seite überschreibt

Der wichtige Punkt ist, dass die zwei Systeme nicht kompatibel sind. Microsoft schreibt ausdrücklich, dass Sie nicht sowohl die einfache als auch die erweiterte Überwachungsrichtlinie verwenden sollen, weil die Überwachungsergebnisse in einem unerwarteten Zustand landen.

Wenn Sie die erweiterte Überwachungsrichtlinie per Gruppenrichtlinie anwenden, werden die vorhandenen Überwachungseinstellungen des Computers zuerst gelöscht und dann die erweiterten Einstellungen angewendet; ab diesem Zeitpunkt gibt Ihnen nur die erweiterte Seite eine zuverlässige Steuerung.

In einer Umgebung, die die erweiterte Seite nutzt, 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 einfache Seite Ihre Einstellungen nicht überschreibt (auf eigenständigen Maschinen ist sie standardmäßig aktiviert).¹⁴

flowchart TB
    accTitle: Die Beziehung zwischen einfacher und erweiterter Überwachungsrichtlinie
    accDescr: Einfache und erweiterte Überwachungsrichtlinie sind nicht kompatibel und die Verwendung beider versetzt die Überwachungsergebnisse in einen unerwarteten Zustand, deshalb auf der erweiterten Seite vereinheitlichen und das Erzwingen der Unterkategorieeinstellungen aktivieren, damit die einfache Seite nicht überschreibt
    basic["Einfache Überwachungsrichtlinie (9 Kategorien)"] --> both{"Beide verwenden?"}
    adv["Erweiterte Überwachungsrichtlinie (über 40 Unterkategorien)"] --> both
    both -->|Ja| bad["Überwachungsergebnisse in einem unerwarteten Zustand"]
    both -->|Nein| unify["Auf der erweiterten Seite vereinheitlichen"]
    unify --> force["Erzwingen der Unterkategorieeinstellungen aktivieren"]
    force -.-> guard["Verhindert, dass die einfachen Einstellungen überschreiben"]

Abbildung 2: Die zwei Systeme sind nicht kompatibel. Vereinheitlichen Sie auf der erweiterten Seite und verhindern Sie mit der Einstellung „Erzwingen“, dass die einfache Seite überschreibt.

2.3. Mit auditpol die tatsächlich wirksame Richtlinie prüfen

Den aktuellen Zustand zu prüfen ist ein einziger Befehl. Führen Sie ihn an einer administrativen Eingabeaufforderung aus.²

Das folgende Beispiel zeigt drei getrennte Vorgänge: den aktuellen Zustand anzeigen, vor einer Änderung sichern und wiederherstellen. Prüfen Sie zuerst die Anzeige und legen Sie vor Änderungen eine Sicherung an. Die Zeile /restore führen Sie aus, wenn Sie wiederherstellen müssen, nicht unmittelbar nach der Anzeige, um den aktuellen Zustand zu prüfen.

rem Die aktuell wirksamen Überwachungseinstellungen unterkategorieweise auflisten
auditpol /get /category:*

rem Vor einer Änderung sichern (CSV) und wiederherstellen
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv

Die Ausgabe von auditpol ist „die Richtlinie, die als Ergebnis wirkt“, unabhängig davon, ob sie von einem GPO oder von lokalen Einstellungen stammt. Deshalb eignet sie sich auch zum Abgleich, wenn Einstellungen, die Sie per GPO zu verteilen glauben, nicht gegriffen haben.

Beachten Sie, dass eine Änderung der Überwachungseinstellungen selbst Ereignis 4719 erfasst, sodass „die Überwachung war still deaktiviert worden“ nachträglich nachvollziehbar bleibt.¹²

flowchart TB
    accTitle: Was auditpol zeigt, ist die resultierende Richtlinie
    accDescr: Die Ausgabe von auditpol ist die als Ergebnis wirksame Überwachungsrichtlinie unabhängig davon, ob sie von einem GPO oder von lokalen Einstellungen stammt, deshalb kann sie zum Abgleich dienen, wenn GPO-Einstellungen nicht gegriffen haben, und Änderungen der Überwachungseinstellungen selbst bleiben über Ereignis 4719 nachträglich nachvollziehbar
    gpo["Per GPO verteilte Einstellungen"] --> eff["Die als Ergebnis wirksame Richtlinie"]
    local["Lokale Einstellungen"] --> eff
    eff --> get["Mit auditpol /get auflisten"]
    get -.-> diff["Zum Abgleich nutzbar, wenn das GPO nicht angewendet wurde"]
    change["Änderung der Überwachungseinstellungen selbst"] -.-> e4719["4719 wird erfasst und bleibt nachträglich nachvollziehbar"]

Abbildung 3: auditpol liefert „die wirksamen Einstellungen“ unabhängig von ihrem Ursprung. Änderungen der Überwachungseinstellungen selbst bleiben in 4719.

3. Eine Entscheidungstabelle der mindestens zu aktivierenden Unterkategorien

3.1. Warum „alles aktivieren“ falsch ist

Warum „einfach alles aktivieren“ ein Fehlgriff ist, liegt auf der Hand. Microsoft warnt zum Beispiel, dass die Überwachung der Unterkategorien zur Rechteverwendung bis zum Erfolg so große Ereignismengen erzeugt, dass andere Einträge schwer zu finden sind, und dass es auch Auswirkungen auf die Leistung gibt.⁴ Der Behälter des Protokolls (Abschnitt 5) ist endlich, je mehr Rauschen Sie aufzeichnen, desto weniger Vorhaltetage bleiben für die Ereignisse, die Sie wirklich brauchen. Überwachungsdesign heißt zu entscheiden, was Sie nicht aufzeichnen.

flowchart TB
    accTitle: Warum alles aktivieren ein Fehlgriff ist
    accDescr: Jede Unterkategorie zu aktivieren erzeugt riesige Ereignismengen, die die wichtigen Ereignisse im Rauschen begraben und die Leistung beeinträchtigen, und in einem endlichen Protokollbehälter frisst das auch die Vorhaltespanne der benötigten Ereignisse auf
    all["Jede Unterkategorie aktivieren"] --> flood["Riesige Ereignismengen"]
    flood --> noise["Die wichtigen Ereignisse werden begraben"]
    flood --> perf["Auswirkung auf die Leistung"]
    flood --> keep["Die Vorhaltespanne wird aufgefressen"]
    noise --> lesson["Überwachungsdesign heißt zu entscheiden, was Sie nicht aufzeichnen"]
    perf --> lesson
    keep --> lesson

Abbildung 4: „Alles aktivieren“ begräbt die wichtigen Ereignisse. Überwachungsdesign heißt zu entscheiden, was Sie nicht aufzeichnen.

3.2. Von der Basislinie aus die benötigten Nachweise wählen

Microsoft veröffentlicht Basisempfehlungen und stärkere Empfehlungen getrennt für Arbeitsplätze und Server, und das ist der Ausgangspunkt.³ Darauf aufbauend ordnet die folgende Tabelle die Dinge aus der Perspektive „mindestens das will ich bei einem Vorfall lesen können“ einer kleinen bis mittleren Umgebung. Es ist die Entscheidungstabelle dieses Artikels, gebaut auf Microsofts Empfehlungen als Ausgangspunkt, keine Einstellungsliste, die Sie einheitlich auf jede Umgebung anwenden.

3.3. Bei den in Masse erfassten die Ziele und das Zeitfenster einengen

Umgekehrt ist es sicherer, Objektzugriffsüberwachung für Dateisystem und Registrierung, Rechteverwendung oder die Paketfilter-Unterkategorien (5152 und ähnliche) standardmäßig nicht anzufassen. Die verdienen sich ihren Platz mit einer eng gezielten SACL-Konfiguration oder einem zeitlich begrenzten Fenster während der Triage; dauerhaft weit offen fressen sie Ihr Protokoll lebendig.⁴

flowchart TB
    accTitle: Wie Sie die volumenstarken Unterkategorien behandeln
    accDescr: Objektzugriffsüberwachung für Dateisystem und Registrierung, Rechteverwendung und die Paketfilter-Unterkategorien fressen das Protokoll lebendig, wenn sie dauerhaft weit offen bleiben, und verdienen sich ihren Platz nur mit einer eng gezielten SACL-Konfiguration oder einem zeitlich begrenzten Fenster während der Triage
    heavy["Volumenstarke Unterkategorien"] --> use{"Wie aktivieren Sie sie?"}
    heavy -.-> ex1["Objektzugriffsüberwachung"]
    heavy -.-> ex2["Rechteverwendung und Paketfilter-Unterkategorien"]
    use -->|Dauerhaft weit offen| eat["Frisst das Protokoll lebendig"]
    use -->|Eng gezielte SACL| ok1["Verdient sich ihren Platz"]
    use -->|Zeitlich begrenzt während der Triage| ok2["Verdient sich ihren Platz"]

Abbildung 5: Lassen Sie Objektzugriff oder Rechteverwendung nicht dauerhaft weit offen. Sie verdienen sich ihren Platz nur mit eingeengten Zielen und Zeitfenstern.

4. Wie Sie die Standard-Ereignis-IDs lesen

Prüfen Sie drei Dinge als Satz: welches Ereignis es ist, auf welcher Maschine es bleibt und welches Feld Sie ansehen. Anmeldungen beginnen in 4.1 und 4.2, Sperrungen in 4.3, Kontoänderungen in 4.4 und ausgeführte Vorgänge in 4.5 und 4.6. In einer echten Untersuchung sichern Sie das Protokoll zuerst nach dem Verfahren in 6.3.

4.1. 4624 — Erfolgreiche Anmeldungen nach Anmeldetyp sortieren

4624 ist „Ein Konto wurde erfolgreich angemeldet“ und wird auf der Maschine erfasst, auf der die Anmeldesitzung erstellt wurde, also der Maschine, auf die zugegriffen wurde.⁵ Weil es in großer Zahl erfasst wird, sortieren Sie es beim Lesen zuerst nach Anmeldetyp.⁵

Nach dem Sortieren nach Typ Konto, Quelle und Recht ansehen

Die weiteren Felder sind der Kontoname unter „New Logon“, die Quelladresse unter „Network Information“, das „Authentication Package“ (NTLM oder Kerberos) und das „Elevated Token“ (ob dies eine administrative Sitzung ist). Wenn Sie nur administrative Anmeldungen verfolgen wollen, können Sie auch 4672 (einer neuen Anmeldung zugewiesene Sonderrechte) nutzen, das mit derselben Anmelde-ID erfasst wird.⁵

flowchart TB
    accTitle: Das Verfahren zum Sortieren von 4624
    accDescr: Weil 4624 in großer Zahl erfasst wird, zuerst nach Anmeldetyp sortieren, dann Kontoname und Quelle, Authentifizierungspaket und erweitertes Token prüfen und administrative Anmeldungen mit dem 4672 derselben Anmelde-ID abgleichen
    ev["4624 erfolgreiche Anmeldung"] --> type["Nach Anmeldetyp sortieren"]
    type --> fields["Die wichtigsten Felder prüfen"]
    fields -.-> f1["Kontoname und Quelle"]
    fields -.-> f2["Authentifizierungspaket"]
    fields -.-> f3["Erweitertes Token"]
    fields --> admin["Administratives Recht verfolgen"]
    admin -.-> e4672["Das 4672 mit derselben Anmelde-ID"]

Abbildung 6: Sortieren Sie 4624 nach Anmeldetyp, bevor Sie die Felder lesen. Korrelieren Sie privilegierte Anmeldungen mit 4672.

4.2. 4625 — Den Fehlschlaggrund mit den Status-/Substatuscodes festmachen

4625 ist „Ein Konto konnte sich nicht anmelden“ und wird auf der Maschine erfasst, auf der die Anmeldung versucht wurde.⁶ Statt des Wortlauts im Feld „Failure Reason“ sind die hexadezimalen Status-/Substatuscodes der zuverlässige Weg. Der Standardssatz ist der folgende.⁶

Zuerst den Fehlschlaggrund aus Status/Sub Status lesen

• 0xC0000064: Benutzername existiert nicht. Eine Serie davon in einem kurzen Fenster ist ein Zeichen für einen Kontoaufzählungsangriff
• 0xC000006A: falsches Passwort. Eine Serie davon gegen ein bestimmtes Konto ist ein Zeichen für einen Passwortrateangriff
• 0xC000006D: ungültiger Benutzername oder ungültige Authentifizierungsinformationen
• 0xC000006F: außerhalb der erlaubten Stunden
• 0xC0000070: von einem nicht zugelassenen Arbeitsplatz
• 0xC0000072: Konto von einem Administrator deaktiviert (Versuche gegen das Konto eines ehemaligen Mitarbeiters erscheinen hier)
• 0xC000015B: der angeforderte Anmeldetyp ist auf dieser Maschine nicht gewährt
• 0xC0000193: abgelaufenes Konto
• 0xC0000234: Konto gesperrt

Zielkonto, Quelle und Fehlschlaggrund kombinieren

„Wer, von wo und warum es fehlgeschlagen ist“ machen Sie mit dem Dreiersatz fest: Zielkonto, Quelle (Arbeitsplatzname / IP-Adresse) und dieser Code. Abschnitt 6.2 hat PowerShell, das alle drei in einem Durchgang extrahiert.

flowchart TB
    accTitle: Der Ablauf, um den Grund eines 4625-Fehlschlags festzumachen
    accDescr: Den Grund eines 4625-Fehlschlags mit dem hexadezimalen Status-/Substatuscode festmachen, Angriffszeichen am Mustern der Codes lesen und dann mit dem Dreiersatz aus Zielkonto und Quelle identifizieren
    ev["4625 fehlgeschlagene Anmeldung"] --> code["Den Substatuscode prüfen"]
    code --> sign{"Wie ist das Muster der Codes?"}
    sign -->|Eine Serie von 0xC0000064| enum["Zeichen für Kontoaufzählung"]
    sign -->|Eine Serie von 0xC000006A| guess["Zeichen für Passwortraten"]
    sign -->|0xC0000072| disabled["Versuch gegen das Konto eines ehemaligen Mitarbeiters"]
    enum --> triple["Mit dem Dreiersatz festmachen"]
    guess --> triple
    disabled --> triple
    triple -.-> t1["Zielkonto + Quelle + Code"]

Abbildung 7: Machen Sie den Grund am Code fest und lesen Sie ihn zusammen mit Zielkonto und Quelle als Dreiersatz.

4.3. 4740 — Der Ursprung einer Sperrung ist der „Caller Computer Name“

Den Ursprung finden: der Name des aufrufenden Computers in 4740

4740 ist „Ein Benutzerkonto wurde gesperrt“ (die Unterkategorie ist Audit User Account Management). Das Feld, das dieses Ereignis treibt, ist „Caller Computer Name“ und erfasst, von welchem Computer der Anmeldeversuch kam, der die Sperrung ausgelöst hat.¹⁶ Der Standardzug ist, hier den Ursprungsarbeitsplatz zu identifizieren und dann diesen Arbeitsplatz nach noch vorhandenen alten Anmeldeinformationen zu durchsuchen.

In den meisten Fällen ist die Ursache etwas, das nach einer Passwortänderung weiter alte Anmeldeinformationen verwendet: gespeicherte Anmeldeinformationen, eine getrennte RDP-Sitzung oder ein Dienst oder eine Aufgabe mit dem alten Passwort.

flowchart TB
    accTitle: Der Standardzug zur Untersuchung einer Kontosperrung
    accDescr: Den Ursprungsarbeitsplatz am Namen des aufrufenden Computers in 4740 identifizieren und diesen Arbeitsplatz nach gespeicherten Anmeldeinformationen, getrennten Remotedesktopsitzungen und Diensten oder Aufgaben mit dem alten Passwort durchsuchen
    ev["4740 Sperrung aufgetreten"] --> caller["Den Namen des aufrufenden Computers prüfen"]
    caller --> src["Den Ursprungsarbeitsplatz identifizieren"]
    src --> sweep["Alte Anmeldeinformationen durchsuchen"]
    sweep -.-> c1["Gespeicherte Anmeldeinformationen"]
    sweep -.-> c2["Getrennte RDP-Sitzungen"]
    sweep -.-> c3["Dienste und Aufgaben mit dem alten Passwort"]

Abbildung 8: Identifizieren Sie den Ursprung am „Caller Computer Name“ in 4740 und durchsuchen Sie dann diesen Arbeitsplatz nach alten Anmeldeinformationen.

Die Spur des Fehlschlags finden: die Seite ansehen, die ihn angenommen hat, nicht den Ursprung

Es gibt einen Vorbehalt. 4625 wird auf dem Computer erfasst, der den Anmeldeversuch angenommen hat. Ist die Ursache eine Netzwerkanmeldung vom Ursprungsarbeitsplatz zu einem Dateiserver oder Ähnlichem, bleibt kein 4625 im Security-Protokoll des Ursprungsarbeitsplatzes selbst; die Spur bleibt im 4625 des Zielservers oder, bei einem Domänenkonto, in 4776 (NTLM) / 4771 (Kerberos-Vorauthentifizierungsfehler) auf dem DC.⁷⁸ Wenn „im Protokoll des Ursprungsarbeitsplatzes nichts ist“, sehen Sie auf der Seite nach, die angenommen hat.

Den Untersuchungsfluss können Sie so ordnen: den Ursprung am Aufrufer in 4740 finden, 4625 auf dem Ziel und 4776/4771 auf dem DC chronologisch abgleichen, dann gespeicherte Anmeldeinformationen, Dienste, Aufgaben und so weiter auf dem Ursprungsarbeitsplatz prüfen. Den Ursprung zu finden und zu finden, wo die Fehlschlagereignisse erfasst sind, sind zwei verschiedene Dinge.

flowchart TB
    accTitle: Die Maschinen, auf denen die Spur eines Fehlschlags bleibt
    accDescr: Ein Netzwerkanmelde-Fehlschlag bleibt nicht auf dem Ursprungsarbeitsplatz selbst, sondern wird im 4625 des Zielservers erfasst, der den Anmeldeversuch angenommen hat, und bei einem Domänenkonto bleibt die Spur auch in 4776 oder 4771 auf dem DC
    src["Ursprungsarbeitsplatz (kein eigenes 4625)"] -->|Netzwerkanmeldung| target["Zielserver"]
    target -.-> e4625["4625 wird erfasst"]
    src -->|Authentifizierung eines Domänenkontos| dc["Domänencontroller"]
    dc -.-> e4776["4776 (NTLM) / 4771 (Kerberos)"]

Abbildung 9: 4625 bleibt auf der Seite, die den Versuch angenommen hat. Ist auf dem Ursprungsarbeitsplatz nichts, sehen Sie auf dem Zielserver und dem DC nach.

4.4. Die 4720-Familie — Kontoerstellung, -änderung und Gruppenhinzufügungen

Kontoänderungen von Gruppenmitgliedschaftsänderungen trennen

Die Kontenverwaltungsereignisse laufen in Folge: 4720 (ein Benutzerkonto wurde erstellt)¹⁷, 4726 (gelöscht), 4738 (geändert) und dann die Mitgliederhinzufügungen und -entnahmen auf der Gruppenseite.

Beachten Sie, dass Gruppenmitgliedschaftsänderungen je nach Gruppentyp über Ereignis-IDs verteilt sind. Lokale Gruppen sind 4732/4733, globale Gruppen 4728/4729 und universelle Gruppen 4756/4757.¹⁴ Domain Admins ist eine globale Gruppe, eine Hinzufügung wird also in 4728 erfasst — machen Sie allein 4732 zu Ihrer Alarmbedingung und Sie verpassen genau das, was Sie am meisten sehen wollen.

Eine unerwartete Hinzufügung zu einer Administratorengruppe ist auch als Einzelfall untersuchenswert

Im Alltag sind das Nachweise der Helpdesk-Arbeit, aber „ein Standardbenutzer wurde plötzlich einer Administratorengruppe hinzugefügt“ oder „ein Konto, das niemand kennt, wurde erstellt“ ist auch als Einzelvorkommen sofort ein Untersuchungsgegenstand. Microsoft listet eine unerwartete Mitgliederhinzufügung zu einer privilegierten Gruppe ebenfalls als Beispiel für ein Ereignis, auf das einzeln alarmiert werden soll.³

flowchart TB
    accTitle: Gruppentypen und Ereignisse zur Mitgliederhinzufügung
    accDescr: Eine Mitgliederhinzufügung zu einer Gruppe verteilt sich je nach Gruppentyp auf Ereignis-IDs, erfasst in 4732 für lokal, 4728 für global und 4756 für universell, deshalb erscheint eine Hinzufügung zur globalen Gruppe Domain Admins in 4728
    add["Mitglied zu einer Gruppe hinzugefügt"] --> kind{"Welcher Gruppentyp?"}
    kind -->|Lokal| lg["Erfasst in 4732"]
    kind -->|Global| gg["Erfasst in 4728"]
    kind -->|Universell| ug["Erfasst in 4756"]
    gg -.-> da["Hinzufügungen zu Domain Admins landen hier"]
    lg -.-> miss["Nur 4732 zu beobachten verpasst sie"]

Abbildung 10: Die Ereignis-ID einer Mitgliederhinzufügung teilt sich nach Gruppentyp. Eine Hinzufügung zu Domain Admins ist 4728.

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

Was die Überwachung der Prozesserstellung Ihnen sagt

4688 ist „Ein neuer Prozess wurde erstellt“ und erfasst bei jeder Prozesserstellung das Konto, das ihn erstellt hat, den Pfad der ausführbaren Datei des neuen Prozesses, den übergeordneten Prozess und den Tokenerweiterungstyp.¹¹ Es ist ein Untersuchungsereignis von hohem Wert, das „wer hat was auf diesem Server ausgeführt“ beantworten kann.

Die Befehlszeile zu behalten erfordert eine getrennte Einstellung und zuerst eine Prüfung

Standardmäßig werden die Befehlszeilenargumente jedoch nicht erfasst. Erst wenn Sie die Gruppenrichtlinie „Befehlszeile in Prozesserstellungsereignisse einschließen“ (Administrative Vorlagen > System > Überwachung der Prozesserstellung) getrennt aktivieren, erscheinen die Argumente im Feld „Process Command Line“ von 4688.¹¹¹² Für das Verfolgen verdächtiger Starts wie powershell -EncodedCommand ... ist das praktisch Pflicht, aktivieren Sie es aber erst, nachdem Sie das in Abschnitt 7 beschriebene Risiko verstanden haben, dass Geheimnisse ins Protokoll gelangen. Lesen Sie zuerst Abschnitt 7, korrigieren Sie die Stellen, die Geheimnisse als Argumente übergeben, und konfigurieren Sie es dann.

flowchart TB
    accTitle: Die Beziehung zwischen 4688 und der Befehlszeilenprotokollierung
    accDescr: Das Aktivieren der Überwachung der Prozesserstellung erfasst Konto, Pfad der ausführbaren Datei und übergeordneten Prozess in 4688, Befehlszeilenargumente werden aber erst erfasst, wenn eine getrennte Gruppenrichtlinie aktiviert ist, was das Risiko birgt, dass Geheimnisse im Klartext erscheinen
    audit["Überwachung der Prozesserstellung aktivieren"] --> ev["4688 wird erfasst"]
    ev -.-> base["Konto, Pfad, übergeordneter Prozess"]
    ev --> args{"Wollen Sie die Argumente auch?"}
    args -->|Beim Standard belassen| none["Die Befehlszeile ist leer"]
    args -->|Die zusätzliche GPO aktivieren| cmd["Argumente werden erfasst"]
    cmd -.-> risk["Risiko von Geheimnissen im Klartext"]

Abbildung 11: Die Befehlszeilenprotokollierung von 4688 ist ein getrennter Schalter. Sie zu aktivieren erfordert zuerst die Prüfung des Risikos, dass Geheimnisse durchsickern.

4.6. 4698 — Eine geplante Aufgabe wurde erstellt

4698 ist „Eine geplante Aufgabe wurde erstellt“ und erfasst den Aufgabennamen und das vollständige XML der Aufgabendefinition (einschließlich des auszuführenden Befehls). Weil das Registrieren einer Aufgabe die Standardtechnik ist, mit der Malware einen Neustart überlebt, empfiehlt Microsoft, Ereignisse zur Aufgabenerstellung zu überwachen.¹⁵ Auch in Umgebungen, die Aufgaben geschäftlich intensiv nutzen, ist eine Erstellung kein Alltagsereignis, das Rauschen bleibt also gering.

flowchart TB
    accTitle: Persistenz durch Aufgabenregistrierung und 4698
    accDescr: Malware registriert routinemäßig geplante Aufgaben, um einen Neustart zu überleben, die Überwachung des bei der Aufgabenerstellung erfassten 4698 lässt die Aufgabendefinition bis zum ausgeführten Befehl verfolgen
    mal["Malware-Persistenz"] --> task["Eine Aufgabe registrieren, um zu überleben"]
    task --> ev["4698 wird erfasst"]
    ev -.-> xml["Vollständiges XML einschließlich des auszuführenden Befehls"]
    ev --> watch["Durch Überwachen der Aufgabenerstellung erkennen"]
    watch -.-> low["Erstellung ist kein Alltagsereignis, daher wenig Rauschen"]

Abbildung 12: Die Aufgabenregistrierung, die Standardtechnik für Persistenz, bleibt in 4698. Das vollständige Definitions-XML lässt sie bis zum Befehl verfolgen.

Um zu erkennen, ob das Protokoll selbst gelöscht wurde, prüfen Sie auch 1102

Ein Weiteres, das Sie im Kopf behalten sollten, ist 1102, „Das Überwachungsprotokoll wurde gelöscht“. Das Leeren des Security-Protokolls hinterlässt immer dieses Ereignis, sodass Sie bei „das Protokoll ist leer“ sagen können, ob es eine bewusste Aktion oder etwas Schiefgegangenes war.¹⁸

flowchart TB
    accTitle: 1102 nutzen, um ein geleertes Protokoll einzuordnen
    accDescr: Das Leeren des Security-Protokolls hinterlässt immer ein 1102, wenn das Protokoll leer ist, sagt die Anwesenheit eines 1102, ob das Leeren eine von jemandem ausgeführte Aktion oder etwas Schiefgegangenes war
    empty["Das Protokoll ist leer"] --> rule["Leeren hinterlässt immer ein 1102"]
    rule --> check{"Gibt es ein 1102?"}
    check -->|Ja| op["Jemand hat geleert"]
    check -->|Nein| acc["Vermuten, dass etwas schiefgegangen ist"]

Abbildung 13: Das Leeren des Security-Protokolls hinterlässt immer ein 1102. Bei einem leeren Protokoll trennt die Anwesenheit von 1102 eine bewusste Aktion von etwas Schiefgegangenem.

5. Den Protokollbehälter entwerfen — maximale Größe und Vorhaltung

5.1. Wenn er voll ist, was geht verloren, die alten Nachweise oder die neuen?

Bevor Sie Überwachungsrichtlinien hinzufügen, prüfen Sie das Gefäß, das sie auffangen muss. Das Security-Protokoll hat eine maximale Größe und einen Vorhaltemodus, und im Überschreibmodus (die de-facto-Standardkonfiguration) überschreiben neue Ereignisse die ältesten, sobald die maximale Größe erreicht ist. Im Vorhaltemodus (nicht überschreiben) werden umgekehrt die neuen Ereignisse verworfen, sobald das Protokoll voll ist.¹⁰ Beide Verhaltensweisen sind eine Ursache für „das Protokoll war weg, bevor ich es merkte“, deshalb kommt das Verstehen des aktuellen Zustands zuerst.

5.2. Die benötigte Kapazität aus den tatsächlich vorgehaltenen Tagen ableiten

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

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

Get-WinEvent -ListLog liefert Konfiguration und Datensatzanzahl des Protokolls zusammen.⁹ Die Lücke zwischen „dem Zeitstempel des ältesten Ereignisses“ und der Gegenwart ist die Vorhaltespanne, die Sie tatsächlich haben, und wenn sie hinter Ihrer eigenen Anforderung zurückbleibt (die Zahl der Tage, die Sie bei einer Vorfalluntersuchung zurückgehen wollen), erweitern Sie die maximale Größe. Die Einstellung lässt sich mit wevtutil sl Security /ms:<bytes> oder per Gruppenrichtlinie verteilen.¹⁰

Denken Sie Kapazität als „wie viele Tage wollen wir behalten“. Zusätzliche Überwachungsunterkategorien erhöhen das Ereignisvolumen, prüfen Sie die tatsächlich vorgehaltenen Tage deshalb nach einer Einstellungsänderung erneut. Sie brauchen außerdem die betriebliche Praxis, nach einem Zeitplan zu exportieren, bevor Ereignisse überschrieben werden, oder sie auf einer anderen Maschine zu bündeln.

flowchart TB
    accTitle: Kapazitätsdesign rückwärts von der Vorhaltespanne
    accDescr: Konfiguration und Datensatzanzahl mit dem ListLog-Parameter von Get-WinEvent prüfen, die tatsächlich verfügbare Vorhaltespanne aus dem Zeitstempel des ältesten Ereignisses ableiten und die maximale Größe erweitern, wenn sie hinter der Zahl der Tage zurückbleibt, die Sie bei einer Vorfalluntersuchung zurückgehen wollen
    check["Konfiguration und Datensatzanzahl mit ListLog prüfen"] --> oldest["Den Zeitstempel des ältesten Ereignisses prüfen"]
    oldest --> days["Die tatsächlich verfügbare Vorhaltespanne berechnen"]
    days --> enough{"Erfüllt sie die Anforderung?"}
    enough -->|Ja| keep["Die aktuelle Größe behalten"]
    enough -->|Nein| grow["Die maximale Größe erweitern"]
    grow -.-> how["Mit wevtutil sl oder GPO konfigurieren"]

Abbildung 14: Bestätigen Sie die tatsächlich vorgehaltenen Tage und setzen Sie die maximale Größe rückwärts von der Zahl der Tage, die Sie zurückgehen wollen.

5.3. CrashOnAuditFail ist keine Einstellung, die einen Kapazitätsengpass löst

Beachten Sie, dass die Sicherheitsoptionen „Überwachung: System sofort herunterfahren, wenn Sicherheitsüberwachungen nicht protokolliert werden können“ enthalten (gemeinhin CrashOnAuditFail). Ist sie aktiviert und können Sicherheitsüberwachungen nicht mehr erfasst werden, hält das System mit dem STOP-Fehler C0000244 an. Es ist eine Einstellung für Zertifizierungsanforderungen, bei denen der Überwachungspfad auf keinen Fall verloren gehen darf, und sie ist standardmäßig deaktiviert.

Microsoft selbst warnt, dass sie sich in eine DoS verwandeln lässt, bei der ein Angreifer einen Server durch Erzeugen riesiger Ereignismengen absichtlich anhält, deshalb ist sie in einer gewöhnlichen kleinen bis mittleren Umgebung nichts zum leichten Aktivieren.¹⁹

flowchart TB
    accTitle: Verhalten, wenn das Protokoll voll ist
    accDescr: Die Vorhaltekonfiguration gibt es in zwei Formen, Überschreibmodus und Nicht-Überschreiben-Modus, und wenn Überwachungen im Nicht-Überschreiben-Modus nicht mehr erfasst werden können, hält die getrennte Einstellung CrashOnAuditFail das System mit STOP-Fehler C0000244 an, sofern sie aktiviert ist
    full["Security-Protokoll erreicht die maximale Größe"] --> mode{"Wie ist die Vorhaltekonfiguration?"}
    mode -->|Überschreibmodus| ow["Die ältesten Ereignisse werden überschrieben"]
    mode -->|Nicht überschreiben| drop["Die neuen Ereignisse werden verworfen"]
    ow -.-> lost["Beides führt dazu, dass das Protokoll weg ist, bevor Sie es merken"]
    drop -.-> lost
    drop --> caf{"Ist CrashOnAuditFail auch aktiviert?"}
    caf -->|Ja| crash["System hält mit STOP-Fehler C0000244 an"]

Abbildung 15: Die Vorhaltekonfiguration ist entweder Überschreiben oder Verwerfen. CrashOnAuditFail ist eine getrennte Einstellung, die das System anhält, wenn die Überwachung nicht erfasst werden kann.

6. Untersuchung in der Praxis — Filter, Get-WinEvent und Export

Die Reihenfolge, in der Sie tatsächlich arbeiten, ist „in 6.3 sichern, dann in 6.1 oder 6.2 analysieren“. Dieser Abschnitt geht die Untersuchungswerkzeuge der Reihe nach durch. Für einen Einzelfall nutzen Sie die Ereignisanzeige; bei großem Volumen oder wiederholter Untersuchung PowerShell.

6.1. Filtern in der Ereignisanzeige

Für eine einmalige Untersuchung reicht die Ereignisanzeige. Öffnen Sie das Security-Protokoll und geben Sie unter „Aktuelles Protokoll filtern“ die Ereignis-ID (zum Beispiel 4625) und den Zeitraum an. Bedingungen, die Sie wiederholt ansehen, speichern Sie mit „Benutzerdefinierte Ansicht erstellen“, beim nächsten Mal sind sie einen Klick entfernt. Wenn Sie nach etwas anderem als der Ereignis-ID eingrenzen wollen, etwa einem bestimmten Konto, können Sie die XPath-Abfrage direkt auf der XML-Registerkarte des Filterdialogs bearbeiten.

6.2. Extraktion mit Get-WinEvent

Bei Untersuchungen mit großem Volumen, mehreren Bedingungen oder wiederkehrendem Zeitplan wechseln Sie zu PowerShells Get-WinEvent. Der Schlüssel ist -FilterHashtable, das den Filter serverseitig wirksam macht.⁹

flowchart TB
    accTitle: Die Wahl zwischen den Untersuchungswerkzeugen
    accDescr: Eine einmalige Untersuchung erledigt der Filter der Ereignisanzeige, Bedingungen, die Sie wiederholt ansehen, speichern Sie als benutzerdefinierte Ansicht, und Untersuchungen mit großem Volumen, mehreren Bedingungen oder wiederkehrendem Zeitplan wechseln zu Get-WinEvent
    q{"Welche Art von Untersuchung?"}
    q -->|Einmalig| viewer["In der Ereignisanzeige filtern"]
    q -->|Bedingungen, die Sie wiedersehen| view["Als benutzerdefinierte Ansicht speichern"]
    q -->|Groß, mehrere Bedingungen, geplant| ps["Zu Get-WinEvent wechseln"]
    ps -.-> hash["Mit FilterHashtable filtern"]

Abbildung 16: Ereignisanzeige für Einzelfälle, benutzerdefinierte Ansichten für Wiederholungen, Get-WinEvent wenn das Volumen groß ist.

Nach ID und Zeitraum eingrenzen, dann Zielkonto, Quelle und Fehlschlaggrund herausziehen

Die erste Hälfte unten holt die 4625-Ereignisse der letzten 24 Stunden. Die zweite zieht die einzelnen Felder aus dem XML und ist ein Beispiel, das die Vorkommen pro Kombination aus Konto, Status, SubStatus und Quelle zählt. Die abschließende Tabelle ist keine chronologische Liste einzelner Ereignisse; sie zeigt, wie oft jede Kombination aufgetreten ist, absteigend.

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

# „Wer, von wo 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

Das Muster zum Herauslesen der benötigten Felder aus dem XML auf andere Ereignisse wiederverwenden

Haben Sie dieses Muster, EventData aus der XML-Darstellung eines Ereignisses zu ziehen, können Sie es genauso für 4624 oder 4688 wiederverwenden. Das Design der Get-WinEvent-Filterung (wann FilterHashtable statt XPath, und wie eine langsame Abfrage zu beheben ist) ist ausführlich in „Ereignisprotokolle mit Get-WinEvent praxisnah untersuchen — Die Geschwindigkeit der Filterung entscheidet über die Dauer der Untersuchung“ behandelt.

flowchart TB
    accTitle: Das Formungsmuster zum Herausziehen von EventData
    accDescr: Ein mit Get-WinEvent abgerufenes Ereignis in seine XML-Darstellung umwandeln, jedes EventData-Feld herausziehen und in eine Tabelle formen, und dieses Muster genauso für 4624 und 4688 wie für 4625 wiederverwenden
    get["Mit Get-WinEvent abrufen"] --> xml["Das Ereignis in seine XML-Darstellung umwandeln"]
    xml --> pull["EventData herausziehen"]
    pull --> shape["In eine Tabelle formen und aggregieren"]
    shape -.-> reuse["Genauso für 4624 und 4688"]

Abbildung 17: Das Muster, EventData aus der XML-Darstellung in eine Tabelle zu ziehen, ist wiederverwendbar, wenn sich die Ereignis-ID ändert.

6.3. Exportieren mit wevtutil

In der Regel sollten die Protokolle der untersuchten Maschine zuerst exportiert und gesichert werden, bevor Überschreiben sie entfernt.¹⁰

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

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

Die gespeicherte evtx auf einer anderen Maschine analysieren

Die exportierte .evtx lässt sich auf einer anderen Maschine genau so analysieren, mit Get-WinEvent -Path C:\logs\security-20260801.evtx.⁹ Die Gewohnheit, vor dem Analysieren zu sichern, ist dasselbe Denken wie „zuerst den Dump sichern“ bei einer Absturzuntersuchung (siehe „Einführung in das Sammeln von Windows-Absturzabbildern - WER/ProcDump/WinDbg“).

flowchart TB
    accTitle: Der Ablauf, zuerst zu sichern und dann zu analysieren
    accDescr: Das Security-Protokoll der untersuchten Maschine mit wevtutil epl in eine evtx-Datei exportieren und sichern, dann auf einer anderen Maschine genauso analysieren, indem Get-WinEvent auf den Pfad zeigt
    target["Untersuchte Maschine"] --> export["Als evtx mit wevtutil epl sichern"]
    export --> copy["Auf eine andere Maschine mitnehmen"]
    copy --> analyze["Mit Get-WinEvent -Path analysieren"]
    export -.-> note["Sichern, bevor Überschreiben es entfernt"]

Abbildung 18: Zuerst sichern, dann analysieren. Einmal als evtx gesichert, können Sie es auf einer anderen Maschine genauso untersuchen.

7. Fallstricke — vier, in die man vor Ort leicht tritt

7.1. Geheimnisse, die auf der 4688-Befehlszeile mitfahren

Aktivieren Sie die Befehlszeilenprotokollierung und die Argumente jedes Prozesses gehen im Klartext ins Security-Protokoll. Microsoft schreibt ausdrücklich, dass „alle Benutzer mit Lesezugriff auf Sicherheitsereignisse die Befehlszeilenargumente jedes erfolgreich erstellten Prozesses lesen können und diese Argumente vertrauliche Daten wie Passwörter enthalten können“.¹² Startet auch nur eine Fachanwendung oder ein Skript etwas wie myapp.exe /user:admin /password:P@ssw0rd, ist das die Offenlegung des Geheimnisses an jeden, der das Protokoll lesen kann.

Bevor Sie sie aktivieren, finden und korrigieren Sie die Stellen, die Geheimnisse als Argumente übergeben. Dasselbe Schutzniveau ist dann überall nötig, wo die Protokolle gesichert und weitergeleitet werden.

flowchart TB
    accTitle: Die Reihenfolge zum Aktivieren der Befehlszeilenprotokollierung
    accDescr: Bevor Sie die Befehlszeilenprotokollierung für 4688 aktivieren, Fachanwendungen und Skripte finden, die Geheimnisse als Argumente übergeben, die Reihenfolge beibehalten, sie vor dem Aktivieren der Einstellung zu korrigieren, und dasselbe Schutzniveau für Sicherungs- und Weiterleitungsziele der Protokolle verlangen
    audit["Die als Argumente übergebenen Geheimnisse finden"] --> found{"Gibt es welche?"}
    found -->|Ja| fix["Die Stellen korrigieren, die sie übergeben"]
    found -->|Nein| on["Befehlszeilenprotokollierung aktivieren"]
    fix --> on
    on -.-> dest["Dasselbe Schutzniveau für Sicherung und Weiterleitung"]

Abbildung 19: Befehlszeilenprotokollierung heißt „finden, korrigieren, dann aktivieren“. Drehen Sie die Reihenfolge um und Sie legen die Geheimnisse offen.

7.2. Betrieb ohne Kenntnis des Verhaltens, wenn das Protokoll voll ist

Im Überschreibmodus verschwinden alte Nachweise still, bei deaktiviertem Überschreiben werden die neuen Ereignisse verworfen, und mit aktiviertem CrashOnAuditFail hält das System selbst an (Abschnitt 5).¹⁰¹⁹ Der richtige Weg ist, zu wissen, welches Verhalten Sie gewählt haben, und einen Mechanismus einzurichten, der „sie sammelt, bevor sie verschwinden“ (geplante Exporte oder eine Protokollsammelplattform).

7.3. Domänencontroller und Arbeitsplätze verlangen unterschiedliche Protokolle

4624/4625 werden auf der Maschine erfasst, auf die zugegriffen wurde.⁵⁶ Die Überprüfung von Anmeldeinformationen eines Domänenkontos (NTLMs 4776) wird dagegen auf der Maschine erfasst, die über die Anmeldeinformationen Autorität hat, bei einem Domänenkonto ein DC⁷, und der Kerberos-Vorauthentifizierungsfehler (4771) wird nur auf einem DC erfasst.⁸ „Es gibt kein 4625 auf dem Dateiserver“ heißt nicht „es gab keinen Angriff“; das vollständige Bild haben Sie erst, wenn Sie auch 4776/4771 auf dem DC abgleichen. Wie jedes Authentifizierungsprotokoll tatsächlich fließt, siehe „NTLM und Kerberos anhand von Diagrammen erklärt — Warum die Authentifizierung auf NTLM zurückfällt“.

7.4. Wenn die Uhren nicht synchron sind, können Sie nicht abgleichen

Protokolle mehrerer Maschinen aneinanderzulegen, um „welcher Arbeitsplatz unmittelbar vor diesem 4740 ein 4625 erzeugt hat“ zu verfolgen, setzt voraus, dass die Uhren dieser Maschinen übereinstimmen. In einer Domänenumgebung setzt Kerberos selbst eine Obergrenze für die Uhrabweichung (standardmäßig 5 Minuten), darüber beginnt die Authentifizierung selbst zu scheitern.²⁰ Aus Untersuchungssicht reicht eine Abweichung von wenigen Sekunden — von fünf Minuten ganz zu schweigen —, um die Reihenfolge der Ereignisse falsch zu lesen, setzen Sie deshalb eine Prüfung des w32time-Synchronisierungszustands ganz an den Anfang Ihres Untersuchungsverfahrens.

Außerdem werden Ereigniszeitstempel in UTC gespeichert und nach der Zeitzone der betrachtenden Maschine angezeigt, vergessen Sie beim Lesen einer evtx von einem ausländischen Standort oder einem auf UTC gesetzten Server also nicht die Zeitzonenumrechnung.

flowchart TB
    accTitle: Uhrensynchronisierung als Voraussetzung für den Abgleich
    accDescr: Eine Untersuchung, die Protokolle mehrerer Maschinen chronologisch aneinanderlegt, setzt voraus, dass die Uhren dieser Maschinen übereinstimmen, weil schon wenige Sekunden Abweichung die Reihenfolge der Ereignisse falsch lesen lassen und eine Abweichung über die standardmäßigen fünf Minuten die Kerberos-Authentifizierung selbst scheitern lässt, deshalb eine w32time-Prüfung an den Anfang des Verfahrens setzen
    merge["Protokolle mehrerer Maschinen abgleichen"] --> pre["Setzt voraus, dass die Uhren übereinstimmen"]
    pre --> skew{"Wie weit sind die Uhren daneben?"}
    skew -->|In Übereinstimmung| ok["Sie können sie chronologisch verfolgen"]
    skew -->|Wenige Sekunden daneben| misread["Die Reihenfolge der Ereignisse falsch lesen"]
    skew -->|Über die standardmäßigen 5 Minuten| kerb["Kerberos-Authentifizierung scheitert"]
    pre -.-> first["Die w32time-Prüfung an den Anfang des Verfahrens setzen"]

Abbildung 20: Der Abgleich mehrerer Maschinen setzt ausgerichtete Uhren voraus. Schon wenige Sekunden Abweichung führen dazu, die Reihenfolge der Ereignisse falsch zu lesen.

8. Zusammenfassung

Um das Windows-Security-Protokoll für eine Untersuchung zu nutzen, entwerfen Sie drei Dinge zusammen: den Umfang dessen, was Sie aufzeichnen, den Ort und die Felder, die Sie lesen, und den Mechanismus, der es sichert.

Wenn Sie die Einstellungen aufräumen

Mischen Sie „einfache“ und „erweiterte“ Überwachungsrichtlinie nicht; vereinheitlichen Sie auf der erweiterten Seite. Prüfen Sie den aktuellen Zustand mit auditpol /get /category:* und beginnen Sie mit der Entscheidungstabelle in Abschnitt 3, die um Anmeldung, Kontenverwaltung und Prozesserstellung gebaut ist, mit Microsofts Basisempfehlungen als Ausgangspunkt. „Alles aktivieren“ macht die Untersuchung durch Rauschen und Aufblähung schwerer.

Der Protokollbehälter (maximale Größe und Vorhaltemodus) ist die Hälfte des Überwachungsdesigns. Prüfen Sie die tatsächlich vorgehaltenen Tage, entscheiden Sie die Größe rückwärts von Ihrer Anforderung und exportieren oder bündeln Sie, bevor Ereignisse verschwinden. Aktivieren Sie die Befehlszeilenprotokollierung von 4688 erst nach der Prüfung des Risikos, dass Geheimnisse durchsickern.

Wenn Sie untersuchen

Zuerst sichern, dann analysieren. Sichern Sie das Protokoll mit wevtutil epl, prüfen Sie die Erfassungsmaschine jedes Ereignisses und die Uhrensynchronisierung und beginnen Sie erst dann zu lesen. Nutzen Sie den Filter der Ereignisanzeige für Einzelfälle und Get-WinEvent -FilterHashtable für Untersuchungen, die sich wiederholen.

Die Kernpunkte beim Lesen sind Anmeldetyp bei 4624, Status/Sub Status bei 4625, Name des aufrufenden Computers bei 4740 sowie übergeordneter Prozess und Befehlszeile bei 4688. Urteilen Sie nicht allein nach der Ereignis-ID: bestätigen Sie, welche Information wo erfasst wurde, und gleichen Sie die benötigten Protokolle ab.

Verwandte Artikel

• Ereignisprotokolle mit Get-WinEvent praxisnah untersuchen — Die Geschwindigkeit der Filterung entscheidet über die Dauer der Untersuchung
• 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-Channel-Binding — Die „andere Hälfte“ der NTLM-Abwehr in der Praxis schließen
• Einführung in Windows-Ereignisprotokoll und ETW ── Protokolle von Geschäftsanwendungen in die Standardmechanismen des Betriebssystems einordnen
• Einführung in das Sammeln von Windows-Absturzabbildern - WER/ProcDump/WinDbg

Verwandte Beratungsleistungen

Bei Komura Soft LLC übernehmen wir Beratung zu Überwachungsrichtlinie und Protokolldesign in Windows-Umgebungen, Untersuchungen von „wann, wer und was“ auf Basis von Ereignisprotokollen sowie die Ursachenanalyse der Probleme, die Fachanwendungen rund um Authentifizierung und Überwachung verursachen. Von „mir wurde gesagt, ich soll die Protokolle ansehen, aber wo fange ich an?“ zu starten ist völlig in Ordnung.

• 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 „Audit Logon“ 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?

Bestätigen 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 „Audit Logon“ aktiviert ist. Bei Domänenkonten bleibt 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 Einträge bereits durch Überschreiben verloren gegangen sind (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 diese 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 ist deshalb beruhigend, 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)?

Das Feld „Caller Computer Name“ des 4740-Ereignisses ist der erste Anhaltspunkt. 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 den Arbeitsplatz als Ursprung identifiziert, prüfen Sie dort alles, was nach der Passwortänderung noch alte Anmeldeinformationen hält: gespeicherte Anmeldeinformationen, getrennte Remotedesktopsitzungen und Dienste oder geplante Aufgaben, die mit dem alten Passwort konfiguriert sind. Wiederholen sich die Sperrungen, prüfen Sie zusätzlich, ob die Uhrensynchronisierung 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.