Timeline Forensics unter Windows: Plaso, Log2Timeline und KAPE in der Praxis

Drei Uhr morgens, ein Incident-Anruf, und alles, was du hast, ist eine Windows-11-VDI mit Verdacht auf Payload-Ausfuehrung um 22:47 Uhr am Vortag. Kein vernuenftiger EDR, kein SIEM, das Logs aggregiert, nur die laufende Maschine und vierzig Minuten Zeit, um eine Hypothese zu liefern. Genau hier hoert Timeline Forensics auf, akademische Uebung zu sein, und wird zum Unterschied zwischen 'der Angreifer hat rundll32 verwendet und eine DLL aus %AppData%\Roaming\winlog um 22:47:13 geladen' und einem Achselzucken. Das Lab, das ich in diesem Post baue, repliziert genau diesen Druck auf einem isolierten Windows 11 in VMware Workstation, mit sauberem Snapshot, simuliertem Post-Infection-Snapshot und kontrolliertem Detonator.

Der Stack ist simpel und reproduzierbar: KAPE von Eric Zimmerman fuer die Triage-Sammlung (Targets wie !SANS_Triage brauchen unter drei Minuten), Plaso 20240308 in einem Ubuntu-24.04-Container mit 16 GB dediziertem RAM, dazu Timeline Explorer und Timesketch fuer die Navigation. Der Standardablauf ist: Snapshot, Sample detonieren (ich nutze inerte Varianten aus dem Lab in Malware-Analyse im Isolierten Lab: Sicheres Setup mit FlareVM und REMnux), mit KAPE in eine VHDX sammeln, im Analyse-Host read-only mounten und log2timeline.py gegen den Mount-Point feuern. Auf bescheidener Hardware erzeugt eine 80-GB-Platte mit 18 GB Belegung einen plaso storage von etwa 1,2 GB in rund 22 Minuten.

Das Gold liegt nicht im Tool-Ausfuehren, sondern im Filtern. Eine rohe Plaso-Super-Timeline liefert leicht 8 Millionen Ereignisse, wenn du Parser wie winreg, prefetch, mft, usnjrnl, evtx, srum, amcache, shimcache und bam aktivierst. Ich schneide immer zuerst ein +-30-Minuten-Fenster um den bekannten Indikator mit psort.py -o l2tcsv --slice '2026-01-14T22:47:13' --slice_size 30. Dieser Schnitt reduziert auf rund 14.000 Zeilen, dann filtere ich nach MFT-, EVTX- und Registry-Sources und lade in Timeline Explorer mit Typ-Colorisierung. Die Hunting-Techniken, die ich kombiniere, kommen direkt aus Hunting von Living-off-the-Land-Binaries unter Windows mit KQL und Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel.

Konkretes Beispiel aus dem letzten Lab: Der Detonator war ein LNK, der auf powershell.exe -enc zeigte, ein Muster aehnlich wie in Initial Access Simuliert: Makros, LNK und ISO im Isolierten Windows-11-Lab untersucht. Die erste Spur kam nicht aus EVTX, sie kam aus dem Prefetch (POWERSHELL.EXE-7644F8E2.pf erstellt um 22:47:09, vier Sekunden vor der in Security 4688 protokollierten Ausfuehrung) und aus Amcache.hve, das den SHA1-Hash der ueber BITS nachgeladenen Satelliten-DLL zeigte. UsnJrnl bestaetigte die Dateierstellung unter C:\Users\elias\AppData\Roaming\winlog\runner.dll um 22:46:58, mit MFT-$SI-Timestamp gleich $FN, also kein Timestomping in diesem Fall. Diese Kreuzung dreier unabhaengiger Artefakte validiert die Hypothese; eines allein luegt leicht.

Wer neu in KAPE ist, findet das Targets-und-Modules-Modell seltsam, aber genau das macht die Sammlung im rechtlichen Kontext verteidigbar. Ich pflege ein eigenes .tkape, das PowerShell\Operational, WMI-Activity und TaskScheduler zusaetzlich zu den Standard-Triage-Targets aufnimmt, und ein Modul, das RECmd mit Zimmermans Batch-Files ausfuehrt, um UserAssist, ShellBags, TypedPaths und das RunMRU-Set zu extrahieren. Das hinterlaesst mir ein Triage\-Verzeichnis fuer Plaso und ein Modules\-Verzeichnis mit fertig geparsten CSVs. Bei einem Incident auf einem Endpoint hinter einem Pivoting-Netz (Szenario aus Pivoting mit Chisel und Ligolo-ng: Segmentierte Netze im Pentest-Lab) laeuft KAPE lokal und exportiert auf ein authentifiziertes Share, um schweren Traffic zu vermeiden.

Drei Fallen, die Stunden kosten, wenn man sie nicht kennt. Erstens: Timezone. Plaso normalisiert standardmaessig auf UTC, aber EVTX speichert in UTC und Registry-Artefakte speichern manchmal Local Time als UTC getarnt. Ich fahre immer mit --timezone UTC und dokumentiere den Maschinen-Offset. Zweitens: VSS. Volume Shadow Copies verstecken aeltere Versionen der NTUSER.DAT und koennen Persistenz aufdecken, die geloescht wurde; KAPE sammelt mit --vss und Plaso verarbeitet mit --vss-stores all. Drittens: rauschende EVTX-Parser (Microsoft-Windows-Kernel-General erzeugt Millionen Zeilen) muessen via --parsers '!winevtx_kernel_general' beschnitten werden, sonst verschwendest du Analyse. Verwandte Defensiv-Techniken stehen in Windows-Persistenz: 10 Dokumentierte Techniken und ihre Gegenmassnahmen.

Zur Uebergabe exportiere ich den relevanten Slice nach Timesketch (docker compose up, plaso storage direkt ingesten), erstelle ein Sketch mit Tags wie execution, persistence, c2_beacon und generiere einen Report mit der Stories-Funktion. Das wird direkter Input fuer Sigma-Regeln, die kuenftige Detection speisen, und schliesst den in Purple Team in der Praxis: Aufbau eines Red-Blue-Feedback-Zyklus beschriebenen Zyklus. Praktisches Takeaway: Versuch nicht, 8 Millionen Events zu lesen. Anker dich an einem zeitlichen IOC, schneide ein 30-Minuten-Fenster, kreuze mindestens drei unabhaengige Artefakte und schreib erst dann die Erzaehlung. Timeline Forensics heisst nicht alles sammeln, sondern die Zeit gegen die falsche Hypothese aussagen lassen.