← Volver al blog

Journal USN vs $MFT vs $LogFile: ¿qué artefacto NTFS para qué pregunta?

Referencia comparativa de los tres artefactos de metadatos NTFS que toda investigación forense de Windows acaba tocando — qué registra cada uno, qué no, y cuándo recurrir a cuál.

4 min de lectura

NTFS le ofrece al analista forense tres grandes fuentes de metadatos, y la forma más rápida de perder un día es mirar la equivocada. Mapa rápido:

ArtefactoQué registraVentana temporalGranularidadUbicación
$MFTEl estado actual de cada fichero y directorio del volumen — nombres, tamaños, timestamps, padre"Ahora" más entradas borradas hasta ser reutilizadasPor ficheroEntrada MFT 0
$UsnJrnl:$JLog circular de cada creación/eliminación/renombrado/modificaciónDías a semanasPor operación\$Extend\$UsnJrnl:$J (flujo alternativo)
$LogFileLog de transacciones que NTFS usa para recuperarse de un crash — imágenes antes/después de escrituras de metadatosMinutos a horasPor transacción de metadatos\$LogFile (entrada MFT 2)

Este artículo da el árbol de decisión práctico: dada una pregunta, qué artefacto responde.

$MFT — "qué existe, ahora mismo"

La Master File Table es la columna vertebral de NTFS. Cada fichero o directorio tiene una entrada (normalmente 1024 bytes), con $STANDARD_INFORMATION, uno o más $FILE_NAME y los data runs. Microsoft documenta la estructura en la referencia de NTFS y File System Forensic Analysis de Brian Carrier es el tratamiento canónico en formato libro.

Úsalo para:

  • "¿Qué hay en este volumen?" — incluyendo timestamps de cada entrada.
  • Reconstruir rutas completas a partir de la cadena de entradas MFT padres (es como nuestro parser resuelve rutas para los registros del journal cuando también pasas $MFT).
  • Recuperar ficheros recientemente borrados — mientras la entrada no se haya sobrescrito, los data runs pueden estar intactos.

No te dirá:

  • Qué le pasó a un fichero el martes a las 14:32 — $MFT solo lleva los cuatro timestamps de $STANDARD_INFORMATION y $FILE_NAME, que son un estado final, no un historial.

Herramientas: MFTECmd de Eric Zimmerman es el parser de facto, con mft (Rust) y analyzeMFT (Python) como alternativas open source sólidas.

$UsnJrnl:$J — "qué pasó y en qué orden"

El journal Update Sequence Number registra cada creación, eliminación, renombrado, truncado, cambio de atributo y cierre que ocurre en el volumen. Para el contexto, ver nuestra introducción al formato y la referencia de códigos de razón.

Úsalo para:

  • Reconstruir el ciclo de vida de un fichero incluso tras su borrado.
  • Reconstrucción de timelines en respuesta a incidentes, sobre todo pares RenameOldName/RenameNewName y clusters de DataOverwrite.
  • Detectar patrones de ransomware a escala (ver nuestro artículo dedicado).

No te dirá:

  • Quién hizo qué — no hay usuario, proceso ni línea de comandos. Combinar con Security.evtx (event ID 4663) o con Sysmon.
  • El contenido de ningún fichero — solo que cambió.
  • Nada fuera de la ventana del buffer circular. Los tamaños por defecto van desde ~10 MB en un cliente hasta 1 GB+ en servidores, lo que se traduce en días/semanas de historial.

Herramientas: usnrs, PoorBillionaire/USN-Journal-Parser, el parser de este sitio.

$LogFile — "qué iba a hacer NTFS"

Es el log de metadatos que NTFS usa para recuperarse de crashes. Registra imágenes antes/después de cada escritura de metadatos — actualizaciones de INDEX_ALLOCATION, cambios de atributos, reescrituras de entradas MFT. El formato no está documentado pero está bien reingenierizado; el repo libfsntfs de Joachim Metz es la referencia abierta más completa.

Úsalo para:

  • Recuperar ficheros creados y borrados dentro de los mismos minutos — $LogFile puede aún tener la imagen "antes" del borrado, que contiene el nombre y el padre.
  • Detectar actividad anti-forense que tocó $MFT directamente — $LogFile registra la escritura aunque el estado visible parezca limpio.

No te dirá:

  • Nada fuera de las últimas miles de transacciones — $LogFile rota deprisa, a veces en menos de una hora en una máquina activa.
  • El contenido de ningún fichero. Solo se loguean los cambios de metadatos.

Herramientas: LogFileParser y los parsers construidos sobre libfsntfs.

El árbol de decisión

¿Conoces el fichero exacto?
├── Sí  → ¿Estado actual? → $MFT (ruta, timestamps, tamaño)
│         ¿Historial?     → $UsnJrnl (luego $LogFile para lo muy reciente)
└── No  → ¿Ventana temporal?
          ├── Últimos minutos    → $LogFile (la más granular)
          ├── Últimos días/semanas → $UsnJrnl (mejor señal/ruido)
          └── Más atrás           → solo $MFT (puede que solo te queden timestamps)

¿Estás correlacionando entre ficheros?
└── $UsnJrnl es el único con una timeline ordenable, por operación.

Combinarlos

Los tres artefactos componen bien:

  1. $MFT + $UsnJrnl es el par canónico — $MFT da el árbol de directorios para resolver rutas, $UsnJrnl da el historial de operaciones. Es exactamente lo que hace el parser de esta página cuando le pasas ambos ficheros.
  2. $LogFile es una red para el pasado muy reciente, útil sobre todo cuando $UsnJrnl es demasiado escaso (pequeño o deshabilitado).
  3. Para un contexto más amplio, añade Security.evtx (eventos proceso/objeto), Prefetch (evidencia de ejecución) y las ramas del registro — ver el poster SANS de Windows Forensic Analysis para la vista panorámica.