Timeline Analysis: Como Reconstruir un Incidente Paso a Paso

Por que el timeline analysis es la columna vertebral de DFIR

Cuando un equipo de respuesta a incidentes recibe una alerta, la primera pregunta siempre es la misma: que paso y cuando. Sin una linea temporal precisa, cada hallazgo queda aislado. Un hash sospechoso en disco, una conexion a un C2, una cuenta comprometida. Son piezas de un puzzle que solo cobran sentido cuando se ordenan cronologicamente.

El timeline analysis transforma artefactos dispersos en una narrativa coherente. Permite identificar el vector de entrada inicial, rastrear el movimiento lateral, determinar que datos fueron exfiltrados y establecer la ventana exacta de compromiso. Es la diferencia entre decir "encontramos malware" y poder explicar "el atacante entro por phishing el martes a las 14:23 UTC, escalo privilegios a las 14:41 y comenzo la exfiltracion a las 15:02".

Este articulo cubre las tecnicas y herramientas para construir timelines forenses solidas, desde la extraccion de timestamps individuales hasta la creacion de super timelines con plaso.

Fuentes de timestamps en un sistema

Antes de construir una timeline, necesitas saber de donde vienen los datos temporales. Cada sistema operativo y aplicacion genera artefactos con marcas de tiempo, y no todos tienen la misma fiabilidad ni granularidad.

Timestamps del sistema de ficheros

En NTFS (Windows), cada archivo tiene una entrada en la Master File Table (MFT) con dos conjuntos de timestamps MACB:

El atributo Standard Information (SI) contiene los timestamps que el sistema operativo expone al usuario. Estos son modificables por aplicaciones en espacio de usuario, lo que los convierte en objetivo habitual de timestomping.

El atributo Filename (FN) es mas dificil de manipular porque requiere acceso directo a las estructuras internas de NTFS. Comparar los timestamps SI y FN de un mismo archivo es una tecnica clasica para detectar manipulacion temporal.

En ext4 (Linux), los inodos almacenan timestamps similares: atime (acceso), mtime (modificacion), ctime (cambio de metadatos) y crtime (creacion, desde ext4). La granularidad es de nanosegundos en kernels modernos.

Event logs de Windows

Los event logs de Windows son una de las fuentes mas ricas para timeline analysis. Los ficheros EVTX contienen timestamps con precision de 100 nanosegundos en formato FILETIME (nanosegundos desde el 1 de enero de 1601 UTC).

Los logs clave para reconstruccion de incidentes son:

Security.evtx registra autenticaciones (Event ID 4624, 4625), cambios de privilegios (4672, 4673), y accesos a objetos auditados. Es imprescindible para rastrear movimiento lateral y escalada de privilegios.

System.evtx documenta arranques y apagados del sistema (6005, 6006, 6008), instalacion de servicios (7045) y cambios en la configuracion de red.

PowerShell Operational (Microsoft-Windows-PowerShell/Operational) registra la ejecucion de scripts con Event ID 4104 (Script Block Logging) y 4103 (Module Logging). Muchos atacantes usan PowerShell para post-explotacion, asi que este log es critico.

Sysmon, si esta instalado, proporciona eventos de alta fidelidad: creacion de procesos (Event ID 1), conexiones de red (3), carga de DLLs (7), creacion de ficheros (11) y acceso a procesos (10).

Logs de aplicaciones y servicios

Los servidores web (Apache, Nginx, IIS) generan access logs con timestamps por cada peticion HTTP. Los servidores de correo registran envios y recepciones. Las bases de datos pueden tener audit logs habilitados. Cada aplicacion en el sistema es una fuente potencial de datos temporales.

Artefactos de ejecucion

Prefetch, Amcache, ShimCache y SRUM en Windows proporcionan timestamps asociados a la ejecucion de programas. Estos artefactos son especialmente valiosos porque persisten incluso despues de que el ejecutable ha sido eliminado del disco.

Normalizacion temporal: el problema de las zonas horarias

Un error comun en timeline analysis es mezclar timestamps de diferentes zonas horarias sin normalizarlos. Si un servidor en Madrid (UTC+1/+2) genera logs en hora local y un firewall en Virginia (UTC-5/-4) registra la misma conexion, la diferencia puede ser de 6 a 7 horas dependiendo del horario de verano.

La regla es simple: normalizar todo a UTC antes de correlacionar. Para ello:

Primero, documenta la zona horaria configurada en cada sistema. En Windows, esta informacion se encuentra en el registro: SYSTEM\CurrentControlSet\Control\TimeZoneInformation. En Linux, comprueba /etc/timezone o el enlace simbolico /etc/localtime.

Segundo, verifica si el sistema sincronizaba la hora via NTP. Los logs del servicio NTP (w32time en Windows, ntpd o chronyd en Linux) ayudan a determinar si el reloj del sistema era preciso en el momento del incidente. Una desviacion de varios minutos puede introducir errores graves en la correlacion.

Tercero, ten en cuenta que algunos logs usan hora local y otros UTC incluso dentro del mismo sistema. Los event logs de Windows almacenan timestamps en UTC pero herramientas como Event Viewer los muestran en hora local. Los logs de Apache pueden estar configurados en cualquier zona.

Analisis de la Master File Table (MFT)

La MFT es el corazon del sistema de ficheros NTFS. Cada archivo y directorio tiene al menos una entrada MFT que contiene sus metadatos, incluyendo los timestamps, permisos, nombre y ubicacion en disco.

Extraccion de la MFT

Para extraer la MFT de una imagen forense, puedes usar herramientas como MFTECmd de Eric Zimmerman o analyzeMFT:

# Extraer MFT con MFTECmd (Windows)
MFTECmd.exe -f "C:\evidence\$MFT" --csv "C:\output" --csvf mft_parsed.csv

# Extraer MFT con analyzeMFT (Python, multiplataforma)
analyzeMFT.py -f /evidence/\$MFT -o mft_output.csv -e

El resultado es un CSV con miles o millones de filas, una por cada entrada MFT. Cada fila incluye los ocho timestamps (cuatro SI + cuatro FN), el nombre del archivo, su ruta, tamano y atributos.

Deteccion de timestomping

El timestomping es la manipulacion deliberada de timestamps para ocultar la actividad del atacante. Las tecnicas de deteccion incluyen:

Comparar timestamps SI y FN. Si un archivo tiene una fecha de creacion SI de hace 3 anos pero una fecha de creacion FN de ayer, hay una discrepancia que requiere investigacion.

Buscar timestamps SI anteriores a FN. En condiciones normales, el timestamp FN se establece cuando se crea la entrada en el directorio, y SI se actualiza despues. Un SI anterior a FN es anomalo.

Identificar clusters de timestamps identicos. Los atacantes que modifican timestamps a menudo usan el mismo valor para multiples archivos, creando patrones no naturales.

Verificar la coherencia con otros artefactos. Si el prefetch muestra que un ejecutable se uso por primera vez ayer, pero su timestamp de creacion dice que lleva 2 anos en disco, algo no cuadra.

Creacion de super timelines con plaso

Plaso (Python Log2Timeline) es la herramienta de referencia para crear super timelines. Lee imagenes de disco, ficheros individuales o directorios completos y extrae timestamps de cientos de tipos de artefactos, generando una linea temporal unificada.

Arquitectura de plaso

Plaso funciona en dos fases. La primera fase (log2timeline) procesa las fuentes de evidencia y genera un fichero de almacenamiento intermedio en formato plaso. La segunda fase (psort) filtra, ordena y exporta la timeline en el formato deseado.

Esta separacion es importante porque la primera fase es la mas costosa computacionalmente. Una vez generado el fichero plaso, puedes aplicar diferentes filtros y exportaciones sin reprocesar toda la evidencia.

Ejecucion practica

# Fase 1: Procesar imagen de disco completa
log2timeline.py --storage-file caso001.plaso /evidence/disk.E01

# Fase 1 alternativa: Procesar solo ciertos artefactos
log2timeline.py --parsers "winevtx,prefetch,mft,webhist" \
  --storage-file caso001.plaso /evidence/disk.E01

# Fase 2: Exportar a CSV con filtro temporal
psort.py -o l2tcsv -w timeline.csv caso001.plaso \
  "date > '2026-01-15 00:00:00' AND date < '2026-01-20 23:59:59'"

# Fase 2: Exportar en formato Elasticsearch
psort.py -o elastic -w timeline caso001.plaso \
  --server 127.0.0.1 --port 9200

Seleccion de parsers

Plaso incluye mas de 300 parsers. Procesar todos contra una imagen de disco grande puede llevar horas o dias. Para optimizar, selecciona solo los parsers relevantes para tu caso:

Para investigaciones de malware en Windows, los parsers esenciales son: winevtx (event logs), prefetch (ejecucion de programas), mft (sistema de ficheros), amcache (ejecucion de programas), userassist (actividad del usuario), webhist (historial de navegacion) y winreg (registro de Windows).

Para investigaciones de red, anade pcap (capturas de trafico) y los parsers de logs de firewall o proxy relevantes.

Para servidores Linux, usa syslog, utmp, bash_history y los parsers de logs de servicios especificos.

Procesamiento del output

Una super timeline de un sistema Windows tipico puede contener millones de entradas. Trabajar con ese volumen requiere herramientas adecuadas:

Timeline Explorer de Eric Zimmerman es una aplicacion gratuita que maneja ficheros CSV de gran tamano con filtrado y busqueda rapidos. Es la opcion mas accesible para analistas que trabajan en Windows.

ELK Stack (Elasticsearch, Logstash, Kibana) permite indexar la timeline y crear visualizaciones interactivas. Es ideal para equipos que investigan multiples casos simultaneamente.

Timesketch (de Google) es una plataforma web especificamente disenada para analisis colaborativo de timelines forenses. Soporta importacion directa desde plaso.

Correlacion de eventos: tecnicas practicas

Tener una timeline ordenada es el primer paso. El segundo es correlacionar eventos para identificar patrones y cadenas de ataque.

Pivoting temporal

El pivoting temporal consiste en identificar un evento clave y buscar todos los eventos que ocurrieron en una ventana de tiempo alrededor de ese evento. Por ejemplo, si detectas la creacion de un servicio malicioso a las 14:23:05 UTC, busca todos los eventos entre 14:22:00 y 14:24:00 para encontrar el proceso padre, las conexiones de red asociadas y los cambios en el registro.

Una ventana de mas/menos 60 segundos suele ser suficiente para correlacionar eventos directamente relacionados. Para identificar reconocimiento previo o persistencia posterior, amplia la ventana a minutos u horas.

Cadenas de ejecucion

En Windows, reconstruir la cadena de ejecucion completa es critico. Un ejemplo tipico de ataque por phishing:

El usuario abre un adjunto de correo. Outlook (o el cliente de correo) escribe el fichero adjunto en disco. El fichero adjunto ejecuta un macro que lanza PowerShell. PowerShell descarga un loader. El loader inyecta codigo en un proceso legitimo. El proceso comprometido establece una conexion C2.

Cada paso deja artefactos con timestamps. El evento 4688 (creacion de proceso) en Security.evtx muestra la jerarquia padre-hijo. Sysmon Event ID 1 proporciona la linea de comandos completa. El prefetch confirma la ejecucion. Los eventos de red (Sysmon 3 o logs del firewall) documentan las conexiones salientes.

Correlacion entre multiples sistemas

Cuando un atacante se mueve lateralmente, la timeline de un solo sistema es insuficiente. Necesitas correlacionar eventos de multiples fuentes:

En el sistema origen, busca eventos de autenticacion saliente (Event ID 4648: logon explicito con credenciales alternativas) y el uso de herramientas como PsExec, WMI o RDP.

En el sistema destino, busca eventos de logon entrante (Event ID 4624 tipo 3 para red, tipo 10 para RDP), creacion de servicios (7045) y ejecucion de procesos sospechosos.

Los logs del controlador de dominio proporcionan una vista centralizada de las autenticaciones Kerberos (4768, 4769) y NTLM (4776) que complementan los logs locales.

Documentacion de la timeline

Una timeline forense bien documentada debe incluir:

Metadata del caso: identificador del caso, analista responsable, fecha de analisis, herramientas y versiones utilizadas.

Fuentes de evidencia: lista de imagenes, logs y artefactos procesados con sus hashes de verificacion.

Zona horaria de referencia: UTC, con documentacion de la zona horaria original de cada fuente.

Eventos clave anotados: no basta con listar miles de eventos. El analista debe marcar los eventos significativos (pivots) y explicar su relevancia para la narrativa del incidente.

Gaps temporales: periodos donde no hay datos (por ejemplo, porque los logs fueron borrados o rotados) deben documentarse explicitamente. La ausencia de evidencia tambien es informacion.

Errores comunes en timeline analysis

No normalizar zonas horarias antes de correlacionar. Este error puede hacer que eventos relacionados parezcan separados por horas, o que eventos independientes parezcan simultaneos.

Confiar unicamente en timestamps de Standard Information. Sin verificar contra Filename attributes u otros artefactos, el timestomping puede pasar desapercibido.

Ignorar la granularidad de las fuentes. Un log con precision de segundos y otro con precision de microsegundos no se pueden correlacionar con la misma confianza.

No documentar la herramienta y version usada para el parsing. Diferentes versiones de plaso pueden interpretar el mismo artefacto de forma distinta, y esto afecta a la reproducibilidad del analisis.

Procesar todos los parsers de plaso sin filtrar. Ademas de ser lento, genera ruido que dificulta el analisis. Selecciona los parsers relevantes para tu hipotesis y anade mas si es necesario.

Caso practico: reconstruccion de un ransomware

Para ilustrar el proceso completo, consideremos un escenario tipico. Una empresa detecta ficheros cifrados con extension .locked en varios servidores a las 03:15 UTC del domingo.

El analista crea la super timeline con plaso, filtrando por la ventana de 72 horas previas al cifrado. La timeline revela:

Viernes 16:42 UTC: un usuario abre un documento Word adjunto a un correo de phishing. El prefetch muestra la ejecucion de WINWORD.EXE seguida de cmd.exe.

Viernes 16:43 UTC: cmd.exe ejecuta un script PowerShell codificado en Base64 (visible en PowerShell Operational log, Event ID 4104).

Viernes 16:44 UTC: PowerShell descarga y ejecuta un loader desde un dominio sospechoso (Sysmon Event ID 3 muestra la conexion, Event ID 1 muestra el proceso hijo).

Viernes 16:50 UTC: el loader establece persistencia creando una tarea programada (Event ID 4698 en Security.evtx, Sysmon Event ID 1 mostrando schtasks.exe).

Sabado 02:00 UTC: la tarea programada se ejecuta y lanza Cobalt Strike (visible en Sysmon Event ID 1 con process injection detectada en Event ID 10).

Sabado 02:15 a 02:45 UTC: movimiento lateral via WMI a tres servidores (Event ID 4648 en el sistema origen, 4624 tipo 3 en los destinos).

Domingo 03:00 UTC: despliegue del ransomware en todos los sistemas comprometidos via PsExec (Event ID 7045: instalacion del servicio PSEXESVC).

Domingo 03:15 UTC: comienza el cifrado masivo (creacion de ficheros .locked visible en la MFT y en Sysmon Event ID 11).

Esta narrativa temporal convierte una masa de artefactos en una historia coherente que permite identificar el vector de entrada, la ventana de compromiso, los sistemas afectados y las acciones del atacante en cada fase.

Conclusion

El timeline analysis no es un paso opcional del proceso forense. Es el marco que da sentido a todos los demas analisis. Sin una timeline solida, los hallazgos individuales quedan desconectados y la reconstruccion del incidente es incompleta.

Las herramientas como plaso, MFTECmd y Timeline Explorer han automatizado gran parte del trabajo mecanico, pero la interpretacion sigue siendo humana. Saber que artefactos buscar, como normalizarlos y como correlacionarlos entre multiples fuentes es lo que distingue un analisis competente de uno superficial.

En los siguientes articulos de esta serie exploraremos los artefactos especificos de Windows y Linux que alimentan estas timelines, y las herramientas que facilitan su extraccion y analisis.