Timeline Forensics en Windows: Plaso, Log2Timeline y KAPE en la Practica
Como construir super-timelines de un Windows 11 comprometido en VM de prueba usando KAPE para recoleccion triada y Plaso parseando 200+ artefactos.
Tres de la manana, una llamada de incidente, y lo unico que tienes es una VDI Windows 11 con sospecha de ejecucion de payload a las 22:47 del dia anterior. Sin EDR decente, sin SIEM agregando logs, solo la maquina viva y cuarenta minutos para entregar una hipotesis. Ese es el escenario donde el timeline forensics deja de ser ejercicio academico y se vuelve la diferencia entre decir 'el atacante uso rundll32 cargando una DLL desde %AppData%\Roaming\winlog a las 22:47:13' y encogerse de hombros. El laboratorio que monto aqui replica esa presion en un Windows 11 aislado dentro de VMware Workstation, con snapshot limpio, snapshot post-infeccion simulada y un detonador controlado.
El stack que uso es simple y repetible: KAPE de Eric Zimmerman para coleccion triada (los Targets tipo !SANS_Triage tardan menos de tres minutos), Plaso 20240308 corriendo en un contenedor Ubuntu 24.04 con 16 GB de RAM dedicados, y Timeline Explorer mas Timesketch para navegar. El flujo estandar es: snapshot, detonar muestra (uso variantes inertes generadas en el lab descrito en Analisis de Malware en Lab Aislado: Setup Seguro con FlareVM y REMnux), recolectar con KAPE a un VHDX, montar read-only en el host de analisis, y disparar log2timeline.py contra el punto de montaje. En hardware modesto, un disco de 80 GB con 18 GB ocupados genera un plaso storage de ~1,2 GB y tarda unos 22 minutos.
El oro no esta en correr la herramienta, esta en saber filtrar. Una super-timeline cruda de Plaso devuelve facilmente 8 millones de eventos cuando incluyes parsers como winreg, prefetch, mft, usnjrnl, evtx, srum, amcache, shimcache y bam. Siempre arranco recortando una ventana de +-30 minutos en torno al indicador conocido con psort.py -o l2tcsv --slice '2026-01-14T22:47:13' --slice_size 30. Ese corte reduce a unas 14 mil lineas, luego filtro por sources de MFT, EVTX y Registry y lo cargo en Timeline Explorer con colorizacion por tipo. Las tecnicas de hunting que combino vienen directo de Hunting de Living-off-the-Land Binaries en Windows con KQL y Threat Hunting con Sigma y Elastic: Del Indicador a la Regla de Deteccion.
Un ejemplo concreto del ultimo lab: el detonador era un LNK apuntando a powershell.exe -enc, patron parecido al estudiado en Initial Access Simulado: Macros, LNK e ISO en un Lab Windows 11 Aislado. La primera pista no vino del EVTX, vino del Prefetch (POWERSHELL.EXE-7644F8E2.pf creado a las 22:47:09, cuatro segundos antes de la ejecucion logueada en Security 4688), y del Amcache.hve mostrando el hash SHA1 de la DLL satelite que entro via BITS. El UsnJrnl confirmo creacion del archivo en C:\Users\elias\AppData\Roaming\winlog\runner.dll a las 22:46:58, con timestamp del MFT $SI coincidiendo con $FN, o sea, sin timestomping en este caso. Ese cruce de tres artefactos independientes es lo que valida la hipotesis; uno solo miente facil.
Quien nunca uso KAPE extrana el modelo de Targets y Modules, pero es lo que vuelve la coleccion defendible en contexto legal. Mantengo un .tkape personalizado que agrega PowerShell\Operational, WMI-Activity, TaskScheduler ademas de los targets estandar de triage, y un module que ya corre RECmd con los batch files de Zimmerman para extraer UserAssist, ShellBags, TypedPaths y el conjunto de RunMRU. Eso me deja un directorio Triage\ listo para Plaso y otro Modules\ con CSVs ya parseados. Para incidente en endpoint segmentado en red de pivoting (escenario que cubro en Pivoting con Chisel y Ligolo-ng: Redes Segmentadas en Lab de Pentest), KAPE corre local y exporta a un share autenticado, evitando trafico pesado.
Tres trampas que cuestan horas si no las conoces. Primera: timezone. Plaso por defecto normaliza a UTC, pero el EVTX guarda en UTC y los artefactos de Registry a veces guardan en local time disfrazado de UTC. Siempre corro con --timezone UTC y documento el offset de la maquina. Segunda: VSS. Volume Shadow Copies esconden versiones anteriores del NTUSER.DAT y pueden mostrar persistencia que fue limpiada; KAPE recolecta con --vss y Plaso procesa con --vss-stores all. Tercera: el parser de EVTX en Windows con mucho ruido (Microsoft-Windows-Kernel-General genera millones de lineas) debe podarse via --parsers '!winevtx_kernel_general' o desperdicias analisis. Tecnicas defensivas relacionadas estan en Persistencia en Windows: 10 Tecnicas Documentadas y sus Contramedidas.
Para entregar el hallazgo, exporto la franja relevante a Timesketch (docker compose up, ingesto el plaso storage directo), creo sketch con tags como execution, persistence, c2_beacon y genero un reporte con la feature de stories. Eso se vuelve insumo directo para reglas Sigma que alimentan deteccion futura, cerrando el ciclo descrito en Purple Team en la Practica: Construyendo Ciclo de Feedback Red vs Blue. El takeaway practico: no intentes leer 8 millones de eventos, ancla en un IOC temporal, recorta una ventana de 30 minutos, cruza al menos tres artefactos independientes, y solo entonces escribe la narrativa. Timeline forensics no es coleccionar todo, es hacer que el tiempo atestigue contra la hipotesis equivocada.