Las cuatro marcas de tiempo de la MFT y cómo se manifiesta el timestomping en ellas

Cada registro MFT guarda cuatro marcas de tiempo en dos atributos separados. Eso son ocho números por registro. No están siempre sincronizadas. La relación entre ellas, y donde se rompe, es la base del análisis temporal NTFS. Si solo vas a aprender un detalle de la forense MFT, aprende este.

Los cuatro momentos que NTFS registra

Tanto $STANDARD_INFORMATION (SI, tipo de atributo 0x10) como $FILE_NAME (FN, tipo de atributo 0x30) llevan marcas de tiempo para los mismos cuatro eventos:

• Creado: cuándo se escribió el archivo por primera vez en el volumen.
• Modificado: cuándo cambió por última vez el contenido del archivo.
• Accedido: cuándo se leyó el archivo por última vez.
• MFT-modificado: cuándo se actualizó por última vez el propio registro (cualquier cambio de atributo, no solo de datos).

Las marcas se guardan como valores de 64 bits en formato Windows FILETIME (ticks de 100 nanosegundos desde 1601-01-01 UTC). Granularidad de 100 nanosegundos. Suficientes bits para que los eventos naturales dejen ruido en los dígitos inferiores.

Por qué existen dos conjuntos

$STANDARD_INFORMATION es el conjunto de marcas que ve el userland. La API Win32 SetFileTime escribe aquí. Cada operación rutinaria de archivo que toca una marca actualiza SI: escritura, lectura (según el ajuste de tiempo de acceso), renombrado, cambio de atributo.

$FILE_NAME se añadió por compatibilidad con el subsistema POSIX en los primeros NT y persiste por razones históricas. Solo se actualiza cuando cambia el nombre: creación (cuando el nombre se establece por primera vez), renombrado (cuando el nombre cambia) o traslado entre directorios (lo que renombra en el sentido NTFS). Después de eso, FN queda quieto mientras el archivo conserve ese nombre.

En la práctica eso significa que las marcas SI tictactean constantemente mientras las marcas FN permanecen estables. La asimetría es lo que hace que el timestomping sea detectable.

Qué hace el timestomping

Las herramientas que alteran marcas de tiempo suelen llamar a SetFileTime. Eso escribe en SI. No toca FN. Tras el timestomping:

• SI muestra lo que el atacante eligió. A menudo retrocedido años (para que una herramienta recién depositada parezca un archivo de sistema) o adelantado (para oscurecer la hora real de actividad).
• FN sigue reflejando la hora real de creación, posiblemente con un amplio margen.

Esto es lo que produce la firma canónica del timestomping: un archivo con SI creado en 2018 y FN creado hace seis minutos.

Dos patrones a vigilar durante el triage:

1. SI creado más antiguo que FN creado. Es imposible naturalmente. Los archivos no pueden existir antes de ser nombrados. Cualquier registro donde SI creado preceda a FN creado ha sido manipulado.
2. SI modificado muy lejos de FN modificado en un archivo que claramente no ha sido renombrado. FN modificado solo se mueve con renombrados; si SI dice 2017 y FN dice ayer, sin renombrado entre medias, algo va mal.

El truco del doble renombrado

Los operadores que saben que la divergencia SI/FN es detectable usan un atajo: renombrar el archivo (lo que obliga a NTFS a actualizar FN), luego llamar a SetFileTime en SI y en FN, luego renombrar de vuelta. Ahora ambos atributos muestran los valores retrocedidos.

Esto vence la comparación SI/FN. No vence:

• El diario USN. Cada renombrado escribe un par RENAME_OLD_NAME / RENAME_NEW_NAME. Los dos renombrados necesarios para el truco se ven en el diario. Sus marcas en el diario son las horas reales, no los valores falsificados de FN.
• $LogFile. Los registros de transacción alrededor del renombrado se quedan en el log.
• Instantáneas VSS. Las instantáneas más viejas tienen los valores FN previos al stomp. Cruza la MFT actual contra la MFT de la instantánea para el mismo registro.

El doble renombrado es más difícil de hacer en silencio. Sigue siendo común en kits de red team maduros.

Granularidad sub-segundo, la pista de la herramienta perezosa

NTFS guarda marcas de tiempo en ticks de 100 nanosegundos. Las operaciones nativas de Windows dejan ruido en los dígitos inferiores. El SO no cero la componente sub-segundo al escribir una marca; lo que el reloj del kernel devolvió se registra.

La mayoría de las herramientas de timestomping redondean al segundo más cercano antes de escribir. El resultado es una marca terminando en .0000000 UTC. Una sola marca así no llama la atención (eventos naturales ocasionales redondean). Una columna de sufijos .0000000 alineados a través de muchos archivos es una huella digital.

Esto es fácil de comprobar. Toma las columnas created, modified, accessed y MFT-modified de tu parseo MFT. Filtra cualquier registro donde las cuatro marcas SI terminen en .0000000. Compara con una línea base de actividad natural de Windows. El contraste es inmediato.

Qué le hace Windows a las marcas por sí mismo

Para usar la comparación SI/FN necesitas saber qué le hace Windows a los cuatro campos por su cuenta. La chuleta:

• SI creado: escrito en la creación. Actualizado por algunos instaladores cuando "crean" un archivo extrayéndolo.
• SI modificado: escrito en cada escritura de datos. Actualizado por SetFileTime. No actualizado por cambios solo de metadatos.
• SI accedido: por defecto deshabilitado en Windows 7+ (pon fsutil behavior set disablelastaccess 0 para habilitar). Si está deshabilitado, este campo aún se actualiza ocasionalmente por ciertas operaciones (software de backup, escaneos EDR), pero es poco fiable como señal de "última lectura" en cualquier dirección.
• SI MFT-modificado: escrito en cualquier cambio de atributo, incluyendo renombrados, cambios de ACL, creación de ADS y escrituras de datos.
• FN creado: escrito cuando el nombre se establece por primera vez (creación, creación de hard link, renombrado).
• FN modificado, FN accedido, FN MFT-modificado: escritos cuando se establece el nombre, luego en gran medida estables.

En una instalación limpia, las cuatro marcas de FN típicamente son iguales entre sí (todas se pusieron en el mismo instante cuando se asignó el nombre). Cuando ves FN con las cuatro marcas idénticas y las cuatro SI divergiendo, eso es normal.

Windows Update y binarios parcheados

Windows Update toca las marcas SI de los binarios parcheados. Tras una actualización acumulativa, la mitad de \Windows\System32\ tiene SI modificado en cuestión de minutos entre sí, y FN que ha sido estable desde el último service pack. Eso es normal. Trátalo como patrón base, no como actividad anómala.

Cruza con CBS.log y setupapi.dev.log para la ventana de parcheo. Si SI dice que svchost.exe se modificó a las 03:14 y el log CBS muestra una instalación de componente a las 03:14, eso es Windows Update, no un atacante.

Cómo escaneo en busca de timestomping

El cribado que ejecuto en un extracto MFT fresco:

1. Saca cada registro donde SI creado < FN creado. Revisa cada uno manualmente.
2. Saca cada registro donde SI modificado esté a más de 30 días antes de FN modificado y el archivo esté en un directorio escribible por el usuario. Revisión manual.
3. Saca cada registro donde las cuatro marcas SI terminen en .0000000 y el archivo no sea un binario de sistema de Windows. Revisión manual.
4. Cruza la MFT actual contra la instantánea VSS más reciente. Resalta los registros cuyas marcas SI se movieron hacia atrás. Revisión manual.

Esa secuencia pilla la mayor parte del timestomping en libertad. Los operadores sofisticados usando el truco del doble renombrado o eliminación de VSS necesitan las capas de diario y log de eventos para detectarlos, pero los cuatro chequeos de arriba los sacarán a la superficie de todos modos a través de otros artefactos (el renombrado en el diario USN, la eliminación VSS en el log de eventos).

Lecturas adicionales

• David Cowen, cobertura de Forensic Lunch sobre timestomping. Años de estudios de caso de practicantes.
• SANS, chuleta de Reglas de Tiempo de Windows. Referencia rápida para lo que cada operación de Windows hace a cada marca.
• Las notas de $STANDARD_INFORMATION y $FILE_NAME del proyecto linux-ntfs. Referencia de layout a nivel de campo.