.evtx-Dateien ohne Windows-Maschine lesen

Das Protokoll ist nie auf der Maschine, an der du sitzt

Das Muster ist immer dasselbe. Etwas ist passiert — ein vermuteter Kompromittierungsfall, ein Sturm von Kontosperrungen, ein Dienst, der um 03:00 gestorben ist —, und der Beweis ist ein Windows-Ereignisprotokoll, das jemand exportiert, in ein Abbild kopiert oder von einer Maschine gezogen hat, die du nicht booten kannst, auf der du dich nicht anmelden kannst oder die du nicht berühren darfst. Deine eigene Maschine ist ein Mac, eine Linux-Workstation oder ein abgesperrter Firmenlaptop ohne Windows-VM in Sicht. Die Ereignisanzeige wird nicht zur Hilfe kommen.

Die gute Nachricht: Eine .evtx-Datei ist ein dokumentiertes, in sich geschlossenes Binärformat. Alles, was die Ereignisanzeige dir zu einem Datensatz zeigt — mit einer wichtigen, unten behandelten Ausnahme — steckt in der Datei, und ein ordentlicher Parser kann sie überall lesen. Der EVTX-Viewer auf dieser Site führt diesen Parser (die Rust-Crate evtx, zu WebAssembly kompiliert) in deinem Browser-Tab aus, weil Ereignisprotokolle Benutzer, Rechner und IP-Adressen nennen und ebenso wenig auf irgendeine Konverter-Site hochgeladen gehören wie ein Paketmitschnitt. Was folgt, ist die Arbeitsmethode, nicht das Tool-Handbuch: worauf du schaust, in welcher Reihenfolge, und was die Felder dir sagen werden und was nicht.

Was wirklich in einer .evtx-Datei steckt

Eine .evtx-Datei ist eine 4096 Byte große Kopfzeile, gefolgt von einer Folge von Chunks mit je 64 KB. Jeder Chunk enthält eine Reihe von Ereignisdatensätzen, und jeder Datensatz ist als binäres XML (BinXML) gespeichert: ein System-Block, den das Betriebssystem ausfüllt, plus die eigene Nutzlast des Anbieters als EventData oder UserData. Öffne einen Datensatz, und du findest Felder, keine Prosa — EventID 4625, einen Zeitstempel, einen Kanal und benannte Werte wie IpAddress, TargetUserName und LogonType. Diese Felder sind das Beweismaterial. Sie sind auch alles, was dir ein Parser auf einer fremden Maschine ehrlich geben kann.

Hier ist die Ausnahme, und sie prägt alles Weitere in diesem Leitfaden: Der Satz, den die Ereignisanzeige zeigt — „Ein Konto konnte sich nicht anmelden“ — steht nicht in der Datei. Windows erzeugt ihn zur Anzeigezeit aus Meldungs-DLLs, die zu jedem Anbieter gehören und auf der Maschine liegen, die das Protokoll geschrieben hat. Darum sehen Datenwerte manchmal aus wie %%14592: Sie sind Verweise in eine Meldungstabelle, die die Datei nicht mitführt. Ein Viewer auf einer anderen Maschine kann dir jedes Feld zeigen, das das Ereignis aufgezeichnet hat, und sein rohes XML genau so, wie es gespeichert ist — aber ein Tool, das für die .evtx eines anderen einen polierten Meldungstext präsentiert, rekonstruiert ihn aus eigenen DLL-Kopien oder rät ihn. Felder zuerst, Prosa zuletzt — das ist die ehrliche Reihenfolge.

Eine weitere strukturelle Tatsache, die du kennen solltest, bevor du Zahlen zitierst: Die Chunks der Datei sind unabhängig. Ein Protokoll, das aus einem Datenträgerabbild herausgeschnitten oder von einem sterbenden Laufwerk kopiert wurde, hat oft einzelne Chunks, die sich nicht mehr parsen lassen. Ein guter Reader meldet jeden beschädigten Chunk mit seinem Byte-Offset und liest alles um ihn herum. Schweigen an dieser Stelle — ein Tool, das ein kürzeres Protokoll zurückgibt und nichts sagt — ist die Art, wie Datensätze still aus einer Untersuchung verschwinden.

Beginne mit dem System-Block

Der System-Block jedes Datensatzes trägt dasselbe Skelett: Provider (welche Komponente ihn geschrieben hat), EventID (was passiert ist, in der Nummerierung dieses Anbieters), Level (1 Kritisch bis 5 Ausführlich, mit 0 für Ereignisse ohne Ebene), Channel (Security, System, Application und die Hunderten von Betriebsprotokollen unter Microsoft-Windows-*), Computer, einen UTC-Zeitstempel und die EventRecordID. Die Triage beginnt damit, ein ganzes Protokoll in dieses Skelett zu sortieren: wie viele Datensätze, über welchen Zeitraum, aus welchen Kanälen, dominiert von welchen Ereignis-IDs. Ein Sicherheitsprotokoll, das zu 80 % aus einer einzigen Ereignis-ID besteht, ist meist eine Geschichte über genau diese eine Sache — eine Firewall, die entscheidet, ein Dienst, der sich in einer Schleife authentifiziert —, und die Zusammenfassung sagt dir das, bevor du einen einzigen Datensatz liest.

Zitiere die EventRecordID aus dem System-Block, wenn du auf einen Datensatz verweist. Dateien, die herausgeschnitten, ausgewählt oder erneut exportiert wurden, können ihre Datensatzkopfzeilen von dem Tool, das sie erzeugt hat, neu nummeriert bekommen haben, während der System-Block die ID behält, die die Maschine ursprünglich vergeben hat — der Unterschied zwischen „Datensatz 7 dieses Auszugs“ und „EventRecordID 319457858 im Originalprotokoll“ zählt in dem Moment, in dem jemand versucht, deinen Befund zu reproduzieren. Zeitstempel verdienen dieselbe Sorgfalt: In der Datei stehen sie in UTC, immer. Die Ereignisanzeige rechnet sie in die Ortszeit der Maschine um, die das Protokoll öffnet — darum können zwei Screenshots desselben Datensatzes um Stunden auseinanderliegen. Nimm UTC für den Bericht und sage das auch.

Vier Ereignis-IDs, die sich lohnen

1102 — das Überwachungsprotokoll wurde gelöscht. Das Sicherheitsprotokoll zeichnet seine eigene Löschung auf, als erstes Ereignis im neuen Protokoll. Seine Felder nennen den Benutzer, der es gelöscht hat. In einem Vorfall ist eine 1102 zugleich Beweis und Grenze: Alles davor in diesem Protokoll ist aus der Datei, die du hast, verschwunden, und die Löschung selbst ist eine Tatsache, die eine Zeile im Bericht verdient. Wenn der früheste Datensatz eines Protokolls eine 1102 mit einem Zeitstempel innerhalb deines interessierenden Zeitfensters ist, sage das, bevor jemand eine Theorie auf die Abwesenheit früherer Ereignisse baut.

4624 und 4625 — Anmeldungen, erfolgreich und fehlgeschlagen. Das sind die Arbeitstiere der Kontountersuchungen. Die Felder, die zählen, sind TargetUserName, IpAddress und vor allem LogonType: 3 ist eine Netzwerkanmeldung, 10 ist Remotedesktop, 2 ist eine interaktive Konsolenanmeldung, 7 ist eine Entsperrung. Ein Brute-Force-Muster liest sich als ein Schwall von 4625ern gegen ein Konto von einer Adresse, gefolgt — der Moment, der zählt — von einer 4624. Eine einzelne 4625 ist ein Tippfehler; die Form der Folge ist das Signal, und darum filtert und zählt man, statt zu scrollen.

4688 — ein Prozess wurde erstellt. Wenn die Überwachungsrichtlinie es aufzeichnet, nennt jede 4688 den neuen Prozess (NewProcessName), das Konto, das ihn gestartet hat, und oft den übergeordneten Prozess — das Rohmaterial für „was lief auf dieser Maschine, und wann“. Zwei Vorbehalte halten dich ehrlich: 4688 existiert nur, wenn „Prozesserstellung überwachen“ auf der Quellmaschine aktiviert war (ihre Abwesenheit beweist nichts darüber, was lief), und die Befehlszeilenerfassung ist noch einmal eine separate Einstellung. Behandle eine reiche 4688-Spur als Geschenk, nicht als Anspruch.

Diese vier sind ein Startset, kein Lehrplan — der Spezialanmeldungs-Bruder der 4624, die 4672, die Anmeldung mit expliziten Anmeldeinformationen 4648 und die Dienstinstallation 7045 im System-Protokoll sind die üblichen nächsten Stationen. Aber ein bemerkenswerter Anteil der Fragen des ersten Tages — wurde das Protokoll gelöscht, wer kam herein, woher, und was hat er ausgeführt — wird allein von 1102, 4624, 4625 und 4688 beantwortet.

Was die Felder dir nicht sagen können

Disziplin in Bezug auf Abwesenheit ist der größte Teil der Protokollarbeit. Die Datei kann dir keine Ereignisse zeigen, die die Quellmaschine nie aufgezeichnet hat: Die Überwachungsrichtlinie entscheidet, was existiert, und eine Maschine mit Standardkonfiguration protokolliert weit weniger, als ein Ermittler hofft. Sie kann dir keinen Meldungstext zeigen, wie oben behandelt — ein %%-Verweis ist ein Zeiger auf eine Zeichenfolge auf einer Maschine, die du nicht hast. Sie kann für sich allein weder Manipulation noch deren Abwesenheit beweisen: Lücken in den Datensatz-IDs kommen in ehrlich herausgeschnittenen Dateien ebenso vor wie in gelöschten, und darum ist der explizite 1102-Datensatz — und nicht eine Lücke — das Signal, auf das man sich stützen sollte.

Und ein Protokoll ist ein einziger Zeuge. Zeitstempel stammen von der Uhr der Quellmaschine, die falsch gegangen sein kann; Konten erscheinen unter den Namen, die die Maschine kannte; die IP einer Netzwerkanmeldung ist die Adresse, die die Maschine gesehen hat, NAT und VPNs eingeschlossen. Die Felder sind genau das, was die Maschine aufgezeichnet hat — nicht weniger, und die Disziplin besteht darin, sich zu merken: auch nicht mehr.

Eine Triage-Routine in fünf Minuten

Erste Minute: Öffne die Datei im EVTX-Viewer und lies die Zusammenfassung vor jedem Datensatz — Gesamtzahl, Zeitraum, Kanäle und die häufigsten Ereignis-IDs. Notiere alle Chunks, die der Viewer als unlesbar meldet, mit ihren Offsets; dieser Vorbehalt gehört von Anfang an in deine Notizen, nicht später als Fußnote.

Zweite Minute: Prüfe auf 1102. Wenn das Protokoll gelöscht wurde, ändert sich dein gesamtes Vorgehen, und Löschzeitpunkt und Konto sind deine ersten harten Fakten. Dritte Minute: Filtere 4625 und betrachte die Form — Anzahl pro Konto, pro Quelladresse. Ein Schwall, gefolgt von einer 4624 für dasselbe Konto von derselben Adresse, ist der Befund; notiere die genauen Zeitstempel. Vierte Minute: Filtere, mit dem verdächtigen Zeitfenster fixiert, 4688 (und 4624 Typ 10, falls Fernzugriff im Raum steht) innerhalb dieses Fensters und liste auf, was lief und wer sich angemeldet hat. Fünfte Minute: Exportiere die gefilterten Datensätze als JSON oder CSV und schreibe den Absatz, solange die Zahlen vor dir liegen — Datensatz-IDs, UTC-Zeiten, Konto, Adressen. Der Export ist dein Arbeitspapier; der Absatz, mit dem Vorbehalt zu unlesbaren Chunks und der Grenze beim Meldungstext, ist das Ergebnis.

Diese Routine schließt keine Untersuchung ab. Sie verwandelt eine fremde Binärdatei in fünf zitierte Fakten und eine vertretbare nächste Frage, auf welcher Maschine auch immer gerade vor dir steht — und das ist der größte Teil dessen, was Triage überhaupt je ist.

Häufige Fragen