NTFS le da al analista forense tres grandes artefactos de metadatos, y la forma más segura de perder un día es leer el equivocado para la pregunta que realmente tienes. La versión corta:
| Artefacto | Lo que registra | Periodo | Granularidad | Vive en |
|---|---|---|---|---|
$MFT | Estado actual de cada archivo y directorio: nombre, tamaño, timestamps, padre | "Ahora mismo" más entradas recientemente eliminadas | Por archivo | Entrada MFT 0 |
$UsnJrnl:$J | Log circular de cada creación/eliminación/renombrado/modificación de archivo | Días a semanas | Por operación | \$Extend\$UsnJrnl:$J (flujo de datos alternativo) |
$LogFile | Log de transacciones que NTFS usa para recuperación de crash: imágenes antes/después en bruto de escrituras de metadatos | Minutos a horas | Por transacción de metadatos | \$LogFile (entrada MFT 2) |
Sigue leyendo para el árbol de decisión que uso de verdad, y las razones por las que cada artefacto te dejará tirado por sí solo.
$MFT — "lo que existe, ahora mismo"
La Master File Table es la espina dorsal de NTFS. Cada archivo o directorio tiene al menos una entrada de 1024 bytes que contiene $STANDARD_INFORMATION, uno o más atributos $FILE_NAME y los data runs que apuntan al contenido real.
Tira de $MFT cuando la pregunta sea:
- Qué existe en este volumen ahora mismo, incluyendo entradas recientemente eliminadas antes de que se reutilicen.
- Cuáles son los cuatro timestamps NTFS (M/A/C/B tanto en
$STANDARD_INFORMATIONcomo en$FILE_NAME) para un archivo específico. - Puedo recuperar los bytes de un archivo eliminado cuya entrada sigue asignada.
- Cuál es la ruta completa de un registro que solo lleva un número de referencia padre — esto es exactamente cómo el parser de esta página resuelve registros USN cuando también sueltas
$MFT.
Lo que no te dirá, por mucho que entrecierres los ojos:
- Qué le pasó a un archivo el martes pasado a las 14:32. Los cuatro timestamps son un estado final, no una historia. Te dicen cuándo se creó el archivo y cuándo se tocó por última vez. No te dicen que fue renombrado, luego renombrado de vuelta, luego truncado, luego sobrescrito, luego eliminado, y luego se creó un archivo nuevo en la misma entrada MFT.
Tooling: MFTECmd de Eric Zimmerman es el parser de facto. La crate mft de Omer BenAmram en Rust y el script Python analyzeMFT de David Kovar cubren el lado open source.
$UsnJrnl:$J — "qué pasó, en qué orden"
El Update Sequence Number Journal registra cada creación, eliminación, renombrado, truncado, cambio de atributo y cierre que ocurre en el volumen. Como contexto, el post de introducción cubre el formato en disco y el post sobre Reason codes es la referencia de campo a nivel de bits.
Tira de él cuando la pregunta sea:
- Cuál fue el ciclo de vida de este archivo, incluidos renombrados, antes de ser eliminado.
- Algo cifró masivamente archivos en este volumen — mira detección de ransomware.
- Algo apiló y archivó masivamente archivos para exfiltración — mira detección de exfiltración.
- Se manipularon timestamps — mira timestomping.
- Qué estaba haciendo el usuario entre las 14:00 y las 16:00 — mira reconstrucción de timeline de actividad.
Lo que no te dirá:
- Quién hizo nada. Ni usuario, ni proceso, ni línea de comandos. Correla con Security.evtx
4663(solo si las SACL fueron configuradas) o evento 11 de Sysmon. - El contenido de ningún archivo. El journal registra que un stream cambió, no qué bytes había allí antes.
- Cualquier cosa más vieja que la ventana del ring buffer. Los defaults van de ~10 MB en un cliente recortado a 1 GB+ en un servidor bien dimensionado, lo que se traduce a días o semanas de historia.
Tooling: usnrs de Airbus CERT, USN-Journal-Parser de PoorBillionaire, MFTECmd de Eric Zimmerman (que también parsea $J), y el parser WebAssembly de esta página.
$LogFile — "lo que NTFS estaba a punto de hacer"
Este es el journal de metadatos que NTFS usa para recuperación de crash. Registra imágenes antes/después de cada escritura de metadatos: actualizaciones de INDEX_ALLOCATION, cambios de atributo, reescrituras de entradas MFT. El formato no está documentado pero está bien ingenierizado a la inversa; libfsntfs de Joachim Metz es la referencia abierta más exhaustiva.
Tira de él cuando:
- Un archivo se creó y eliminó dentro de las mismas pocas miles de transacciones y la entrada de directorio del padre ya fue sobrescrita.
$LogFilepuede aún tener la imagen "antes" con el nombre hoja y el padre. - Sospechas manipulación directa de
$MFT.$LogFileregistra la escritura en bruto incluso cuando el estado visible parece limpio después. - El journal es demasiado escaso (pequeño o recién rotado) para cubrir el momento de interés, pero ocurrió dentro de la última hora.
Lo que no te dará:
- Nada fuera de la ventana de rotación.
$LogFilees pequeño y se reutiliza mucho. En un file server activo todo el historial de transacciones puede rodar en menos de una hora. - Contenido de archivos. Las imágenes antes/después son solo metadatos.
Tooling: LogFileParser de Jonas Schicht y cualquier parser construido sobre libfsntfs.
El árbol de decisión que uso de verdad
¿Sabes QUÉ archivo?
├── Sí → ¿Quieres estado actual? → $MFT (ruta, timestamps, tamaño)
│ ¿Quieres historia? → $UsnJrnl primero, $LogFile para el pasado muy reciente
└── No → ¿Ventana de tiempo?
├── Últimos minutos → $LogFile (más granular)
├── Últimos días/semanas → $UsnJrnl (mejor señal/ruido)
└── Hace mucho → Solo $MFT, espera conformarte con timestamps de estado final
¿Estás correlando entre muchos archivos a la vez?
└── $UsnJrnl es el único de los tres con un timeline ordenable, por operación.
¿El archivo fue eliminado y necesitas probar que existió?
└── $UsnJrnl primero (el registro FileDelete lleva referencia padre y timestamp)
$LogFile como red de seguridad si la eliminación es fresca
$MFT solo si la entrada aún no ha sido reutilizada
Combinarlos es donde ocurre el trabajo de verdad
Los tres artefactos componen bien, que es la parte que nadie enfatiza hasta que la necesita.
$MFT + $UsnJrnl es el par canónico. La MFT proporciona el árbol de directorios para la resolución de rutas; el journal proporciona la historia de operaciones. El parser de esta página resuelve automáticamente las rutas completas para cada registro del journal cuando sueltas ambos archivos. Adquiérelos juntos; te ahorrarás un viaje de ida y vuelta nueve veces de cada diez.
$LogFile es la red de seguridad. Cuando el journal es demasiado pequeño para cubrir el momento de interés, o cuando sospechas manipulación directa de MFT, $LogFile es donde recurres.
Para contexto más amplio, empareja los tres artefactos NTFS con EVTX (eventos de proceso y objeto), Prefetch y AmCache (evidencia de ejecución), Shimcache (programa-corrió-en-algún-momento), hives del registro, archivos LNK y jump lists para evidencia de archivos abiertos por usuario, historial de navegador, SRUM para uso de recursos, y el RecentFileCache.
Lecturas adicionales
- Microsoft Learn — Master File Table y Change Journals.
- Brian Carrier, File System Forensic Analysis — sigue siendo la referencia de longitud de libro sobre internos NTFS.
- Joachim Metz, documentación de
libfsntfs— la referencia abierta más detallada sobre los internos de$LogFile. - SANS DFIR — el Windows Forensic Analysis poster es una sola página plastificada que pone toda la pila de artefactos en un lugar.