Timeline forense: reconstrucción cronológica

Cada módulo de la fase anterior (3 a 9) extrajo un tipo de artefacto por separado: MFT, registro, Prefetch, Event Logs, procesos en memoria. Un caso real rara vez se resuelve mirando cada uno de forma aislada: se resuelve cruzándolos en una sola línea de tiempo, como ya se adelantó en el módulo 4. Este módulo cierra la fase de forense de sistemas enseñando a construir exactamente esa timeline unificada.

1. Por qué una timeline unificada

Retomando el ejemplo del módulo 4: una entrada $FILE_NAME de la MFT (módulo 3), un Event ID 4624 de inicio de sesión (módulo 6), una clave UserAssist (módulo 5) y una conexión de red en memoria (módulo 9) pueden, cada una por separado, parecer ruido sin importancia. Ordenadas todas juntas por su marca de tiempo exacta, construyen una secuencia de hechos: quién entró, qué ejecutó, qué tocó y a dónde se conectó, en el orden en que realmente ocurrió. Esa secuencia ordenada, con evidencia de múltiples fuentes, es lo que se llama super timeline.

2. log2timeline.py (Plaso): un extractor, muchos parsers

Plaso (Plaso Langar Að Safna Öllu, "Plaso recolecta todo" en islandés) es el motor detrás de log2timeline.py. Su funcionamiento es simple de entender aunque internamente sea complejo: recorre una imagen forense completa con decenas de parsers especializados —uno para la MFT, uno para cada tipo de hive de registro, uno para .evtx, uno para Prefetch, uno para historiales de navegador, y muchos más— y vuelca cada evento que encuentra, ya normalizado a un formato común, en un fichero de almacenamiento .plaso.

$ log2timeline.py salida_caso.plaso evidencia_caso03.dd
Source path	: evidencia_caso03.dd
Processing started.
[INFO] Extracting events from: MFT, UsnJrnl, Prefetch, EVTX, Registry (NTUSER.DAT, SOFTWARE, SYSTEM)
Processing completed.
Number of events: 184302

184.302 eventos de un único disco de un único equipo es una cifra típica, no exagerada — y es precisamente la razón por la que el filtrado del punto 5 es tan importante como la propia extracción.

3. psort.py: filtrar, ordenar, exportar

El fichero .plaso no es directamente legible; psort.py lo procesa para producir una salida ordenada cronológicamente, en el formato que se necesite (CSV, JSON, o directamente un informe):

$ psort.py -o l2tcsv -w timeline_caso.csv salida_caso.plaso
Processing completed.
Events written: 184302  ->  timeline_caso.csv

4. Ejemplo: cruzando MFT, registro, Prefetch y Event Logs del mismo caso

Filtrando esa timeline a la ventana de la intrusión que venimos siguiendo desde el módulo 6, el resultado ordenado cronológicamente cuenta la historia completa sin que el analista tenga que reconstruirla manualmente artefacto a artefacto:

$ psort.py -o l2tcsv -w ventana_intrusion.csv salida_caso.plaso \
  "date > '2026-03-14 01:55:00' AND date < '2026-03-14 02:35:00'"
2026-03-14 02:01:44  EVTX     4625  Logon failure - administrator
2026-03-14 02:04:17  EVTX     4624  Logon success - administrator - LogonType 10
2026-03-14 02:04:19  EVTX     4672  Special privileges assigned - administrator
2026-03-14 02:08:55  REGISTRY  Run key written - UpdaterService -> svc_update.exe
2026-03-14 02:08:55  MFT       $FILE_NAME created - C:\Users\Public\svc_update.exe
2026-03-14 02:09:12  PREFETCH  svc_update.exe executed (run count: 1)
2026-03-14 02:09:41  PREFETCH  svc_update.exe executed (run count: 2)
2026-03-14 02:31:05  EVTX      1102  Security log cleared - administrator

Esta única tabla —generada automáticamente, sin interpretación manual— reúne en 90 segundos de diferencia máxima la autenticación por RDP, la escritura de la clave de persistencia, la creación del fichero en disco, sus dos primeras ejecuciones, y el borrado del log que intentaba ocultarlo todo. Es exactamente el tipo de evidencia que sostiene un informe final (módulo 20).

5. El error más común: zonas horarias

Plaso normaliza internamente a UTC por defecto; la recomendación es mantener ese estándar en todo el informe y anotar explícitamente la zona horaria de origen del sistema analizado, en vez de convertir a una zona horaria "cómoda de leer" a mitad del análisis.

6. Reducir el ruido

Una timeline de 184.000 eventos es inmanejable sin filtrar. Las estrategias más habituales, combinables entre sí:

• Ventana temporal: acotar a las horas o días alrededor del incidente conocido (como en el ejemplo del punto 4).
• Filtro por tipo de artefacto: quedarse solo con MFT + EVTX + Registro si la hipótesis actual no necesita Prefetch o historiales de navegador.
• Filtro por usuario o proceso: si ya se identificó una cuenta o un proceso sospechoso (módulos 6 y 9), filtrar solo los eventos relacionados con él.
• Exclusión de ruido conocido: descartar de antemano procesos y rutas que son actividad normal y verificada del sistema (actualizaciones automáticas, tareas de mantenimiento documentadas).

Autoevaluación

1. ¿Qué hace exactamente log2timeline.py y qué produce como resultado antes de poder leerlo?
2. ¿Para qué sirve psort.py y por qué no basta con el fichero .plaso directamente?
3. Un Event Log muestra un evento a las 14:00 hora local del analista, y un log de otro sistema en una zona horaria distinta muestra un evento relacionado a las 14:05 de su propia hora local. ¿Por qué no puedes concluir directamente cuál ocurrió antes sin más información?
4. Nombra tres estrategias para reducir el ruido de una timeline con cientos de miles de eventos.
5. En el ejemplo de la ventana de intrusión de este capítulo, ¿qué evento marca el intento de ocultación, y cuánto tiempo pasó entre la primera ejecución del malware y ese intento?