La primera vez que construí una línea temporal de Windows a partir de $MFT, emití ocho filas por registro, ordené por marca de tiempo, la abrí en Excel y me sentí como si hubiera reconstruido la realidad. No lo había hecho. Tenía un log ordenado de cambios de metadatos NTFS. Es algo útil. No es, por sí mismo, una investigación.
Este post es lo que ojalá alguien me hubiera dicho sobre timelining de MFT antes de entregar mi primer informe.
Qué es realmente una timeline de MFT
Cada registro MFT activo o eliminado lleva ocho marcas de tiempo que puedes extraer de forma fiable: cuatro en $STANDARD_INFORMATION (SI) y cuatro en $FILE_NAME (FN). Creado, modificado, accedido y MFT-modificado, en ambos atributos. Recorre la tabla, emite una fila por cada marca de tiempo no nula, ordena por hora, y tienes una línea temporal de cuándo NTFS escribió determinados bytes de determinados registros. Eso es el suelo.
El techo es una super-timeline que fusiona MFT con el diario USN, $LogFile, Prefetch, Sysmon, Shimcache, Amcache, hives del registro, historial del navegador y SRUM. La MFT es la columna vertebral porque es la más densa y la más difícil de falsificar por completo para un atacante. Todo lo demás se alinea con respecto a ella.
El layout que realmente uso
Olvida mactime como formato de destino. Úsalo como intermedio. La forma que aguanta en tribunal es una fila por evento con procedencia defendible:
timestamp_utc | source | attribute | mft_record | seq | path | event
2026-05-15T10:23:01.123Z | MFT | SI | 12345 | 3 | /Users/alice/notes.txt | created
2026-05-15T10:23:01.123Z | MFT | FN | 12345 | 3 | /Users/alice/notes.txt | name_created
2026-05-15T10:24:18.456Z | MFT | SI | 12345 | 3 | /Users/alice/notes.txt | modified
2026-05-15T10:24:18.501Z | USN | - | 12345 | 3 | /Users/alice/notes.txt | DATA_OVERWRITE | CLOSE
source y el par registro/secuencia son las columnas que los analistas se saltan y luego lamentan saltarse. El número de secuencia es lo que te dice si dos eventos que comparten un número de registro se refieren a la misma encarnación de un archivo o a un predecesor eliminado cuyo slot fue reutilizado. Sin él, tu timeline los confunde silenciosamente.
La salida CSV de MFTECmd es el layout listo para usar más cercano a esto. Pasa sus filas por un script delgado que añada source=MFT y emita una fila por marca de tiempo, y tendrás un corpus de trabajo.
Las marcas de tiempo según cuánto mienten
SI se mueve en prácticamente cada operación que Windows hace sobre un archivo. Las lecturas actualizan accessed si NTFS le apetece (Windows 7+ por defecto no actualiza accessed por rendimiento, salvo que fsutil behavior set disablelastaccess 0 esté puesto). Las escrituras actualizan modified y MFT-modified. Los renombrados actualizan MFT-modified. El timestomping con SetFileTime actualiza el que el atacante haya apuntado de los cuatro.
FN se actualiza al renombrar, al crear un hard link y en la creación inicial del archivo. Después de eso, FN se queda quieto en gran medida. La granularidad de las actualizaciones de FN por Windows es también más gruesa; muchos archivos terminan legítimamente en .0000000 si FN se fijó al crear y nunca más se tocó.
En la práctica:
- FN creado es la señal "este archivo apareció primero en este directorio" más fiable que tienes solo a partir de la MFT.
- SI creado es la más fácil de falsificar. Trátalo como pista, no como hecho.
- SI modificado es el caballo de batalla. Combinado con el correspondiente
DATA_OVERWRITEdel USN te dice que los bytes del archivo cambiaron realmente en ese instante. - SI accedido en Windows 7+ está deshabilitado por defecto. Si lo ves cambiando, o bien un admin lo reactivó, el volumen está en una SKU Server, o algo está montando volúmenes y recorriendo archivos (software de backup, escaneos AV, introspección EDR).
La granularidad sub-segundo es la pista. NTFS guarda las marcas de tiempo en ticks de 100 nanosegundos. Las operaciones nativas de Windows dejan ruido en los dígitos inferiores. Las herramientas de timestomping como SetMACE y el conocido timestomp.exe redondean al segundo. Una columna de sufijos .0000000 alineados pulcramente es una huella digital.
Fusión con el diario USN
La MFT te muestra el presente y un historial congelado de metadatos. El diario USN te muestra los verbos. Combínalos y una sola línea en tu timeline se convierte en una frase.
Cómo fusiono: parsea $UsnJrnl:$J por separado, emite una fila por registro con source=USN, luego ordena el flujo combinado por marca de tiempo. Los códigos de razón del USN (FILE_CREATE, DATA_OVERWRITE, RENAME_OLD_NAME, RENAME_NEW_NAME, FILE_DELETE, CLOSE) te dan la operación; la MFT proporciona el estado resultante. Un USN RENAME_OLD_NAME inmediatamente seguido por RENAME_NEW_NAME en el mismo USN revela el renombrado. Sin el diario, un diff de MFT entre dos snapshots podría decirte que el archivo se movió; no puede decirte el orden.
Una trampa: las marcas de tiempo del USN y las marcas SI de la MFT se desfasan en milisegundos para el mismo evento. No te obsesiones con la alineación. Ordena por segundo y usa el código de razón del USN como desempate.
Qué arruina las timelines de MFT
Adquisición fuera de orden. Si recoges MFT y USN con diez minutos de diferencia en un sistema vivo, el diario siguió corriendo. Combínalos desde el mismo punto en el tiempo, idealmente desde una instantánea VSS que tú mismo dispares.
Olvidarse del array fixup. Cualquier parser digno se ocupa de esto, pero si haces uno propio (por favor no lo hagas, salvo aprendiendo), leer trozos crudos de 1.024 bytes te da basura en los offsets 510 y 1022 de cada registro. Aplica los fixups primero.
Mezclar números de registro a través de fronteras de secuencia. El registro 12345 secuencia 3 no es el mismo archivo que el registro 12345 secuencia 5. El slot fue reutilizado. Si tu timeline agrupa solo por número de registro, vas a confundir un archivo eliminado con el que tomó su slot.
Confiar en SI en binarios del sistema. Windows Update toca SI de los archivos parcheados. Un SI modificado en C:\Windows\System32\svchost.exe casi siempre es una instalación CBS, no una intrusión. Cruza con setupapi.dev.log y CBS.log antes de hacer afirmaciones.
Tratar la timeline como la conclusión. Es el input del análisis. Aún necesitas saber qué significa cada evento en el contexto del host, del usuario y del caso.
Un flujo de trabajo que aguanta
- Adquiere
$MFT,$UsnJrnl:$J,$LogFiley las copias disponibles en snapshots VSS de los mismos. Hashea todo (SHA-256) inmediatamente. - Parsea MFT y USN con MFTECmd o
mft_dumpmás un parser de USN. Verifica que los parsers corrieron sin advertencias. - Emite filas normalizadas: una por marca de tiempo para MFT, una por registro para USN, con
source,mft_record,seqypathexplícitos. - Ordena por marca de tiempo en un único flujo. No deduplices todavía; los casi-duplicados llevan señal.
- Pivota al periodo de interés. Saca una ventana de dos horas antes y dos horas después del evento sospechoso.
- Superpón el resto: Prefetch, Amcache, Sysmon 1/11/15, artefactos LNK y jump list, registros
$Ide la papelera, SRUM para uso de recursos de red y proceso. - Busca ordenamientos imposibles. SI creado antes que FN creado. Una razón USN
DATA_OVERWRITEsin un cambio SI modificado correspondiente en la MFT. Dos eventosFILE_CREATEen el mismo número de registro con la misma secuencia (el parser está roto).
Ese último paso es donde las timelines de MFT ganan su sueldo. Exponen imposibilidades. Cada imposibilidad es o un bug del parser o un artefacto del atacante, y ambos merecen seguimiento.
Qué no puede decirte la MFT
No puede decirte qué proceso tocó un archivo. No puede decirte qué usuario. No puede decirte qué había dentro de un archivo mayor de unos pocos cientos de bytes que fue eliminado y parcialmente sobrescrito. Para eso necesitas los artefactos del entorno: 4688 con auditoría de línea de comandos (o Sysmon 1), la cadena de logon ID del log de seguridad y, en un buen día, un volcado de RAM que pillara al proceso aún residente.
La MFT es la espina dorsal. Los demás artefactos son los músculos. Ninguno camina sin el otro.
Lecturas adicionales
- Eric Zimmerman, MFTECmd. El layout CSV canónico y el parser sobre el que la mayoría de equipos IR estandarizan.
- SANS, Windows Forensic Analysis Poster. Encaja correctamente los eventos MFT en la timeline más amplia.
- Harlan Carvey, Investigating Windows Systems. Los capítulos sobre construcción de timelines siguen siendo la referencia práctica.