Saltar al contenido
Categoria: Forense8 min de lectura

Timeline Forensics en Windows: Plaso, Log2Timeline y KAPE en la Practica

Por Lucas Andrade ·

Como construir super-timelines de un Windows 11 comprometido en VM de prueba usando KAPE para recoleccion triada y Plaso parseando 200+ artefactos.

Timeline Forensics en Windows: Plaso, Log2Timeline y KAPE en la Practica

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 que el atacante uso rundll32 cargando una DLL desde %AppData%\Roaming\winlog a las 22:47:13, y encogerse de hombros. Este post monta el laboratorio que replica exactamente esa presion en un Windows 11 aislado dentro de VMware Workstation, y conduce Plaso, log2timeline y KAPE desde la coleccion hasta una narrativa defendible.

Por que el timeline forensics decide el caso

Un solo artefacto miente facil. Un evento EVTX puede borrarse, un timestamp puede sufrir timestomping, un log puede rotar. El timeline forensics gana porque fusiona fuentes independientes en una unica linea de tiempo: metadatos de filesystem desde la MFT, trazas de ejecucion desde Prefetch y Amcache, persistencia en Registry, eventos EVTX, uso de red en SRUM. Donde tres artefactos independientes atestiguan el mismo momento, la conjetura se vuelve evidencia. Esta mentalidad es el reverso defensivo de lo que describimos como caza proactiva en 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. Timeline no es coleccionar todo, es hacer que el tiempo declare contra la hipotesis equivocada.

El stack: KAPE, Plaso, Timesketch

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 para la vista rapida mas Timesketch para navegar en equipo. KAPE recolecta sin romper la cadena de custodia porque saca copias forensicamente limpias con hashes. Plaso luego normaliza decenas de tipos de artefacto en una unica super-timeline buscable. Timeline Explorer te da grid, filtros y colorizacion; Timesketch te da tags, stories y vistas compartidas para el equipo. Cada herramienta tiene su lugar, y la combinacion es mas poderosa que cualquiera sola.

El montaje del laboratorio

Monto el laboratorio en un Windows 11 aislado dentro de VMware Workstation, con snapshot limpio, snapshot post-infeccion simulada y un detonador controlado, totalmente host-only sin internet. El flujo estandar es: snapshot, detonar el sample (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 una 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 usados produce un storage plaso de alrededor de 1,2 GB en unos 22 minutos. El montaje aislado es obligatorio: un detonador sin bloqueo de red contacta C2 real y te vuelve parte del problema.

Coleccion con KAPE: Targets y Modules

Al principiante en KAPE el modelo de Targets y Modules le parece raro, pero es justo lo que hace la coleccion defendible en contexto legal. Los Targets copian artefactos crudos, los Modules los parsean con herramientas externas. Mantengo un .tkape propio que agrega PowerShell\Operational, WMI-Activity y TaskScheduler encima de los targets triada estandar, mas un modulo que corre RECmd con los batch de Zimmerman para extraer UserAssist, ShellBags, TypedPaths y el set RunMRU. Eso me deja un directorio Triage\ listo para Plaso y un Modules\ con CSVs ya parseados. Para un incidente en un endpoint segmentado detras de una 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.

Construir la super-timeline con log2timeline

Contra el montaje read-only disparo log2timeline.py --storage-file case.plaso /mnt/evidence. Plaso autodetecta artefactos, pero en triada habilito deliberadamente los parsers winreg, prefetch, mft, usnjrnl, winevtx, srum, amcache, shimcache y bam en vez de correr todo, lo que multiplica el runtime. Para VSS agrego --vss-stores all para levantar persistencia borrada desde shadow copies. El storage crece rapido: una super-timeline cruda devuelve facil ocho millones de eventos. Eso no es un bug, es materia prima. El valor solo aparece en el siguiente paso, el filtrado. La clave es generar el storage una vez limpio y despues solo cortar de el con psort.py en vez de correr log2timeline varias veces.

Filtrar y hacer slicing con psort

El oro no esta en correr la herramienta, esta en saber filtrar. Siempre empiezo cortando una ventana de mas/menos treinta minutos alrededor del indicador conocido con psort.py -o l2tcsv --slice '2026-01-14T22:47:13' --slice_size 30 case.plaso. Ese corte reduce de ocho millones a unas catorce mil lineas. Luego filtro por sources MFT, EVTX y Registry y cargo Timeline Explorer con colorizacion por tipo. Se puede estrechar mas con un archivo de filtro de psort que solo admita sources relevantes y un rango de tiempo. El reflejo de querer leer la super-timeline entera es el error de novato mas comun; el oficio es anclarse en un IOC temporal e irradiar desde ahi.

Cruzar artefactos: Prefetch, Amcache, MFT, UsnJrnl, EVTX

Ejemplo concreto del ultimo lab: el detonador era un LNK apuntando a powershell.exe -enc, un patron similar al estudiado en Initial Access Simulado: Macros, LNK e ISO en un Lab Windows 11 Aislado. La primera pista no vino de 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 de Amcache.hve mostrando el hash SHA1 de la DLL satelite que entro via BITS. UsnJrnl confirmo la creacion del archivo en C:\Users\elias\AppData\Roaming\winlog\runner.dll a las 22:46:58, con el timestamp MFT $SI igual a $FN, o sea sin timestomping en este caso. Ese cruce de tres artefactos independientes es lo que valida la hipotesis; uno solo miente facil.

Tres trampas que cuestan horas

Primera: timezone. Plaso normaliza a UTC por defecto, pero EVTX guarda en UTC y algunos artefactos de Registry guardan hora local disfrazada de UTC. Siempre corro con --timezone UTC y documento el offset de la maquina explicitamente en el reporte. Segunda: VSS. Las Volume Shadow Copies esconden versiones previas de NTUSER.DAT y pueden revelar persistencia que fue borrada; KAPE colecta con --vss y Plaso procesa con --vss-stores all. Tercera: los parsers EVTX ruidosos (Microsoft-Windows-Kernel-General genera millones de lineas) deben podarse o desperdicias tiempo de analisis. Tecnicas defensivas relacionadas viven en Persistencia en Windows: 10 Tecnicas Documentadas y sus Contramedidas.

Timesketch y la entrega

Para entregar el hallazgo, exporto el slice relevante a Timesketch (docker compose up, ingestar el storage plaso directo), creo un sketch con tags como execution, persistence, c2_beacon, y genero un reporte con la funcion de stories. Eso se vuelve input 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. Cada evento tageado se vuelve una afirmacion trazable, cada story una tesis con evidencia. Asi una triada nocturna produce no solo un reporte sino un artefacto de deteccion que hace visible el proximo incidente mas temprano.

Checklist practico

Primero: snapshot antes de detonar, todo host-only. Segundo: triada KAPE con un .tkape extendido (PowerShell, WMI, TaskScheduler). Tercero: montaje read-only de la evidencia en el host de analisis. Cuarto: log2timeline solo con los parsers relevantes mas --vss-stores all. Quinto: cortar una ventana de treinta minutos alrededor del IOC con psort --slice. Sexto: filtrar por MFT, EVTX, Registry, Prefetch y Amcache y colorizar en Timeline Explorer. Septimo: cruzar al menos tres artefactos independientes antes de afirmar algo. Octavo: documentar el timezone, incluir VSS, podar parsers ruidosos. Noveno: slice a Timesketch, taguear, escribir story, derivar regla Sigma. Camina estos nueve pasos con disciplina y entregas una hipotesis defendible en cuarenta minutos.

FAQ

Por que no tomar simplemente la alerta del EDR? Porque en un incidente real muchas veces no hay EDR corriendo, la alerta tiene huecos, o el atacante borro logs. El timeline forensics reconstruye la secuencia desde artefactos de filesystem y Registry mas dificiles de borrar por completo, y los cruza para que una sola manipulacion resalte.

Alcanza con KAPE o necesito Plaso? KAPE colecta y parsea de forma selectiva, pero la correlacion temporal a lo largo de decenas de tipos de artefacto es lo que entrega Plaso con la super-timeline. En la practica usas ambos: KAPE para la coleccion rapida y limpia, Plaso para la linea de tiempo unificada, Timesketch para entrega y deteccion.

Conclusion

El timeline forensics no es acumular, es disciplina: anclate en un IOC temporal, corta una ventana estrecha, cruza al menos tres artefactos independientes, y solo entonces escribe la narrativa. El stack de KAPE, Plaso y Timesketch lo hace reproducible y defendible legalmente. Takeaway practico: no intentes leer ocho millones de eventos. Anclate en el IOC, corta treinta minutos, cruza Prefetch, Amcache, MFT y EVTX, y haz que el tiempo declare contra la hipotesis equivocada. Eso es exactamente lo que separa una narrativa defendible de un encogerse de hombros a las tres de la manana.

Related posts

Nenhum comentário ainda

Seja o primeiro a comentar.

Deixe seu comentário

Entre com sua conta Canverly para comentar. Você pode usar a mesma conta em qualquer site da rede.

Entrar com Canverly