Skip to content
$LogFileparser

Detectar timestomping con el $LogFile de NTFS

Cómo delata el $LogFile el timestomping: valores de $STANDARD_INFORMATION antes y después, $SI frente a $FN, cuatro indicios, falsos positivos y cómo confirmar.

Publicado el 8 min de lectura
ntfslogfiletimestompingdfirwindows-forensics

TL;DR. Las herramientas de timestomping suelen reescribir $STANDARD_INFORMATION ($SI) mediante SetFileTime o NtSetInformationFile. La comprobación clásica —creación en $SI anterior a la creación en $FILE_NAME ($FN)— solo muestra una discrepancia. $LogFile muestra la reescritura: un UpdateResidentValue sobre $SI con las horas antiguas en los bytes undo y las nuevas en los bytes redo. Merece la pena marcar cuatro indicios: fecha de creación reescrita, un valor que retrocede, valores en segundos exactos y creación en $SI anterior a la de $FN. Los cuatro tienen explicaciones inocentes; confírmalos con el diario USN, los artefactos de ejecución y los registros de alrededor.

El timestomping (MITRE ATT&CK T1070.006) le sale barato al atacante y caro al analista: un binario antedatado desaparece de todos los filtros de «archivos creados durante el incidente». $LogFile es uno de los pocos artefactos que registran el cambio como tal.

Cómo se reescriben las marcas de tiempo

NTFS guarda dos juegos de cuatro marcas de tiempo por archivo (creación, modificación, cambio MFT, acceso):

AtributoQuién lo actualiza¿Fácil de fijar desde modo usuario?
$STANDARD_INFORMATIONLa mayoría de las operaciones con archivos; las aplicaciones mediante SetFileTimeSí, con permiso de escritura sobre el archivo
$FILE_NAMEEl sistema de archivos, sobre todo al crear, renombrar y moverNo directamente

La mayoría de las herramientas solo tocan $SI. Algunas van más allá y manipulan $FN de forma indirecta, por ejemplo fijando $SI y moviendo después el archivo para que NTFS copie los valores al nuevo $FN; Palmbach y Breitinger analizan siete herramientas de terceros y un método con PowerShell en Artifacts for Detecting Timestamp Manipulation in NTFS on Windows and Their Reliability (DFRWS EU 2020).

Las marcas de tiempo son valores FILETIME: intervalos de 100 nanosegundos desde el 1601-01-01 UTC. Por esa precisión llaman la atención los valores en segundos exactos.

Por qué no basta con el $MFT

El $MFT muestra el estado actual. De él sacas la comparación $SI/$FN y las comprobaciones de fracciones de segundo, nada más. No sabes:

  • cuál era el valor antes;
  • si cambió una vez o varias;
  • si también se manipuló $FN (en ese caso los dos juegos coinciden y la comprobación clásica no salta).

El artículo de Cho de 2013 (Computers & Security 34) construye un método de detección justamente sobre esto: los valores de tiempo anteriores recuperados del $LogFile, combinados con los patrones de marcas de tiempo esperados en las operaciones habituales con archivos.

Cómo se ve la reescritura en el diario

Una llamada a SetFileTime sobre un archivo existente suele producir un registro UpdateResidentValue cuyo destino es el atributo $SI del registro FILE de ese archivo:

CampoValor
Redo / undoUpdateResidentValue / UpdateResidentValue
Atributo destino$MFT:$DATA (el registro FILE)
Desplazamiento de registroDesplazamiento de $SI en el registro FILE (0x38 cuando es el primer atributo de un registro de NTFS 3.1)
Desplazamiento de atributoDesplazamiento del primer byte modificado dentro de $SI
Bytes redoNuevos valores de las marcas de tiempo
Bytes undoValores anteriores de las marcas de tiempo

El desplazamiento de atributo importa. Las actualizaciones pueden ser parciales —dfir.ru señala que una actualización de $SI puede empezar en la marca M (How the $LogFile works?)—, así que un analizador debe asignar los bytes a las casillas correctas. La actividad normal (escribir en un archivo) también genera estos registros: nuevos valores de modificación / cambio / acceso, con la creación intacta. El trabajo consiste en separarlos de las reescrituras.

Cuatro indicios y qué más los provoca

El analizador de $LogFile en el navegador marca un cambio de $SI como posible timestomping cuando se cumple al menos uno de estos indicios, y dice cuáles:

IndicioPor qué importaCausas inocentes
Se reescribió la fecha de creaciónLas escrituras normales no cambian la fecha de creaciónHerramientas de copia/restauración que conservan las fechas, instaladores, clientes de sincronización de archivos
Un valor retrocedióLa actividad normal hace avanzar las horasExtracción de archivos comprimidos que aplica las fechas guardadas, restauración de copias de seguridad, corrección del reloj
Valor en segundos exactos (.0000000)NTFS guarda 100 ns; las herramientas y scripts de tipo SetFileTime suelen pasar segundos exactosEl campo de hora DOS de ZIP tiene una resolución de dos segundos, así que los archivos extraídos pueden llevar horas en segundos exactos; archivos procedentes de FAT
Creación en $SI anterior a la de $FN$FN lo fija el sistema de archivos en la creaciónArchivo copiado o extraído conservando las fechas

Otra fuente inocente de fechas de creación antiguas: el tunnelling del sistema de archivos. Cuando se borra o renombra un archivo y poco después (15 segundos por defecto) se crea en la misma carpeta un archivo con el mismo nombre, Windows le da al nuevo la fecha de creación del antiguo. Los editores que guardan escribiendo un archivo temporal y renombrándolo lo provocan continuamente.

Una combinación dice más que cualquier indicio aislado. Un archivo en una carpeta escribible por el usuario cuya fecha de creación salta de hoy a una fecha en segundos exactos de hace años, sin ninguna extracción de archivos alrededor, merece atención. Mil archivos con fechas de modificación que retroceden, creados en el mismo segundo que un Prefetch de 7z.exe, son probablemente una extracción.

Ejemplo práctico (muestra sintética)

El diario de ejemplo del analizador (sintético, equipo ficticio FIN-WKS-07) contiene esta secuencia para la entrada 322 de la MFT:

  1. Creación de \Users\svc_backup\Downloads\tools\m64.exe: creación en $FN 2026-09-14 10:06:52.3551871.
  2. Renombrado / movimiento a \ProgramData\Intel\m64.exe: cambio en $FN 10:09:40.5560318.
  3. Cambio de $SI: antes, creación 10:06:52.3551871 y cambio MFT 10:09:40.5560318; después, las cuatro horas a 2019-03-19 07:14:22.0000000.

Saltan los cuatro indicios: creación reescrita, valores que retroceden, segundos exactos y creación en $SI (2019) anterior a la de $FN (2026). Fíjate en lo que hace el analizador con la hora del evento: como los nuevos valores retroceden, no los usa como hora del cambio. El evento toma la hora de su vecino (el movimiento de las 10:09:40) y se marca con ≈. La hora real de la reescritura saldría del registro BASIC_INFO_CHANGE del diario USN.

El mismo patrón visto solo en el $MFT mostraría $SI = 2019 y $FN = 2026: suficiente para sospechar, no para mostrar el valor original ni el orden de los hechos (primero se movió, después se antedató).

Confirmar un hallazgo

  1. Localiza el registro en bruto. Abre los registros del evento, comprueba que es un UpdateResidentValue sobre el $SI de la entrada correcta y lee tú mismo los bytes undo y redo.
  2. Revisa el diario USN. Un registro BASIC_INFO_CHANGE para la misma referencia de archivo fecha el cambio (analizador del diario USN).
  3. Busca la herramienta. Prefetch (analizador de Prefetch), Amcache (analizador de Amcache) y los registros de PowerShell y Sysmon (analizador de EVTX) pueden mostrar la ejecución de una utilidad de timestomping o de un script capaz de llamar a SetFileTime.
  4. Mira los vecinos. Una reescritura aislada sobre un ejecutable en ProgramData no es lo mismo que un lote de reescrituras durante una extracción.
  5. Contrasta con un segundo analizador si el hallazgo va a un informe: por ahora, el analizador en el navegador solo se ha validado con diarios sintéticos. Analizadores de $LogFile: LogFileParser, NTFS Log Tracker enumera alternativas; NTFS Log Tracker incluye sus propios patrones de manipulación de marcas de tiempo.

Límites

  • Retención. Si la reescritura se produjo hace horas en un volumen de sistema con mucha actividad, el registro probablemente ya no esté (¿hasta dónde llega el $LogFile?).
  • Falta de contexto. Si la creación del archivo quedó fuera del diario, los valores «antes» solo salen de los bytes undo, que pueden cubrir solo una parte de $SI.
  • Manipulación de $FN. Cuando el atacante también movió el archivo para propagar las horas a $FN, el indicio $SI/$FN desaparece; la reescritura y los registros del renombrado siguen siendo la evidencia.
  • Heurísticas, no veredictos. Todos los indicios anteriores tienen causas legítimas. En el informe, recoge la observación (valor antiguo, valor nuevo, LSN de los registros) y la corroboración, no la marca.

Preguntas frecuentes

¿Por qué es útil el $LogFile para detectar timestomping?

Porque el propio cambio queda registrado. Un UpdateResidentValue sobre $STANDARD_INFORMATION lleva las nuevas marcas de tiempo en sus bytes redo y las anteriores en sus bytes undo, así que puedes ver el valor antes y después de la reescritura en lugar de deducirlo de una discrepancia.

¿Una creación en $SI anterior a la de $FN prueba el timestomping?

No. Es un indicio fuerte, pero las copias, la extracción de archivos comprimidos, los instaladores y las restauraciones de copias de seguridad también pueden poner fechas pasadas en $STANDARD_INFORMATION. Busca la reescritura en el $LogFile, un BASIC_INFO_CHANGE correspondiente en el diario USN y evidencias de ejecución de una herramienta que cambie fechas.

Para saber más

Artículos relacionados

Artículos relacionados