Análisis forense del $LogFile de NTFS: la guía completa

TL;DR. $LogFile es el diario de recuperación ante fallos de NTFS (entrada 2 de la MFT). Todo cambio que NTFS hace en sus propios metadatos —un registro FILE, un índice de carpeta, un bitmap— se registra antes como un par de operaciones: redo (cómo aplicarlo) y undo (cómo deshacerlo). Esos bytes contienen nombres de archivo, carpetas padre, referencias MFT y marcas de tiempo de antes y después. Por eso el diario es la mejor fuente para saber qué cambió en los últimos minutos u horas: creaciones, borrados, renombrados y movimientos, y reescrituras de $STANDARD_INFORMATION (timestomping). No tiene reloj propio, es circular y es de bajo nivel. Adquiérelo pronto, júntalo con el $MFT y correlaciónalo con $UsnJrnl:$J.

La mayoría de los analistas llegan tarde a $LogFile: cuando ya han analizado el diario USN, cuando ya tienen la línea temporal del $MFT y aún queda una pregunta sin respuesta. ¿Esta marca de tiempo siempre fue de 2019? ¿Cómo se llamaba este archivo antes del renombrado? ¿Qué contenía ese archivo de texto borrado? Esta guía es el mapa. Cada sección enlaza con un artículo más detallado de las series Fundamentos del $LogFile de NTFS e Investigar con el $LogFile.

Qué es el $LogFile

NTFS es un sistema de archivos recuperable. No registra en el diario el contenido de los archivos, sino los metadatos. El diseño tiene dos capas, bien descritas en «How the $LogFile works?» de dfir.ru:

• El Log File Service (LFS) gestiona un diario circular («infinito»). Asigna los log sequence numbers (LSN), escribe los registros en páginas de 4 KiB y mantiene un área de reinicio que indica dónde debe empezar la recuperación.
• El cliente NTFS del LFS escribe los registros propiamente dichos. Cada uno designa una operación redo y una operación undo y lleva los bytes de ambas.

Tras un fallo, Windows reaplica la parte redo de las transacciones confirmadas y aplica la parte undo de las que no llegaron a confirmarse. Para el investigador, esos mismos bytes responden a la pregunta «¿cómo era esta estructura justo antes y justo después de este cambio?».

$LogFile es el registro 2 de la Master File Table, junto a $MFT (0), $MFTMirr (1) y $Volume (3), como recogen la descripción de los metarchivos de NTFS de Microsoft y la documentación del formato de libfsntfs. Está en la raíz de todo volumen NTFS (C:\$LogFile, D:\$LogFile…) y permanece oculto y bloqueado mientras el volumen está montado.

Cómo está organizado el archivo

Cada página está protegida por un update sequence array, la misma protección contra escrituras parciales que usan los registros FILE. La diferencia entre versiones (1.1 frente a 2.0, páginas de cola frente a páginas rápidas) importa a partir de Windows 8 y se trata en $LogFile 1.1 frente a 2.0: qué cambió en Windows 8. El área de reinicio y la fórmula para pasar de LSN a desplazamiento están en $LogFile: el área de reinicio y los LSN, explicados.

Qué contiene un registro

Cada registro empieza con una cabecera LFS de 0x30 bytes, seguida de los datos del cliente NTFS. Los desplazamientos de los campos proceden del fslog.c del controlador ntfs3 de Linux:

Los datos del cliente empiezan con la cabecera del registro NTFS: opcode redo, opcode undo, desplazamientos y longitudes de los bytes redo y undo, el índice en la tabla de atributos abiertos del atributo destino, el VCN destino y los desplazamientos que sitúan el cambio dentro de un registro de la MFT o de un búfer de índice. Las operaciones redo/undo del $LogFile de NTFS, explicadas repasa los opcodes que importan.

Qué aporta al investigador

De los bytes redo/undo salen cuatro familias de evidencias:

Los archivos pequeños añaden una quinta categoría, oportunista: el contenido guardado dentro del registro FILE (datos residentes) puede aparecer en la imagen del registro o en los datos de un CreateAttribute. Tómalo como un extra, no como una garantía (ver los límites más abajo).

Los dos casos de uso que justifican el esfuerzo con $LogFile:

1. Timestomping. Un UpdateResidentValue sobre $STANDARD_INFORMATION lleva en sus bytes undo el valor anterior al cambio. Una fecha de creación reescrita a 2019 se ve como una reescritura, no solo como un valor extraño. Método y falsos positivos: detectar timestomping con el $LogFile de NTFS.
2. Archivos efímeros. Una herramienta que se deja caer, se renombra, se usa y se borra en menos de una hora puede no dejar registro FILE en el $MFT (entrada reutilizada) y solo unos escuetos códigos de motivo en el diario USN. El $LogFile aún puede conservar su nombre, su carpeta padre, sus tamaños y sus horas. Consulta $LogFile: recuperar evidencias de archivos borrados.

Su lugar junto al $MFT y el $UsnJrnl

En resumen: el $MFT es la instantánea, el diario USN es el historial y el $LogFile es la prueba de qué cambió exactamente. La comparativa completa, con escenarios, está en $LogFile, $UsnJrnl o $MFT: qué artefacto NTFS y cuándo. Para analizar el propio diario USN, usa el analizador del diario USN hermano.

Adquirirlo

En un volumen montado, $LogFile no se puede abrir con el Explorador ni con copy. Hace falta acceso NTFS en bruto: el target $LogFile de KAPE, el accessor NTFS de Velociraptor, FTK Imager, RawCopy o icat de The Sleuth Kit sobre una imagen (icat image.dd 2). Adquiere siempre a la vez el $MFT del mismo volumen: el diario se refiere a los archivos por su entrada de la MFT, y es el $MFT el que convierte [MFT #322] en \ProgramData\Intel\m64.exe. Comandos y trampas: cómo adquirir el $LogFile de NTFS.

Leerlo

El flujo de trabajo en la práctica:

1. Descomponer el diario en registros en bruto (LSN, transacción, opcode redo/undo, destino).
2. Reconstruir los eventos del sistema de archivos a partir de grupos de registros.
3. Resolver las entradas de la MFT en rutas con el $MFT.
4. Fechar los eventos con las marcas de tiempo contenidas en los datos y señalar los que quedan sin fecha.
5. Correlacionar con el USN, Prefetch y los registros de eventos.

El analizador de $LogFile en el navegador hace los pasos 1 a 4 en local (Rust compilado a WebAssembly, sin subir nada) y muestra cada registro en bruto junto a los eventos que ha construido con él. Sus marcas —borrado, renombrado, posible timestomping, ruta escribible por el usuario, ejecutable— son pistas de triaje, no veredictos. Tienes un recorrido paso a paso con los datos de ejemplo en cómo analizar un $LogFile de NTFS paso a paso y un caso ficticio completo en investigación con el $LogFile paso a paso.

Una nota de honestidad: hasta ahora, ese analizador se ha validado con diarios sintéticos construidos a partir del formato publicado, no con un corpus de diarios reales de Windows. Para todo lo que vaya a un informe, confírmalo con una segunda herramienta; las opciones se comparan en analizadores de $LogFile: LogFileParser, NTFS Log Tracker.

Dónde se queda corto

• La retención es corta. El diario es circular. En un volumen de sistema con mucha actividad, cuenta con minutos u horas; en las pruebas de dfir.ru con Windows 10, los datos antiguos se sobrescribieron a los 16 minutos en un caso y a las 5 horas y 20 minutos en otro.
• Sin reloj. Los registros llevan LSN, no horas. Las horas salen de los valores de $FILE_NAME / $STANDARD_INFORMATION contenidos en los datos.
• Solo metadatos. El contenido no residente de los archivos nunca pasa por el diario.
• Los nombres no siempre están. A menudo un registro solo designa una entrada de la MFT; el nombre aparece cuando el archivo se crea, se renombra o se borra, o a través del $MFT.

Detalles y soluciones: ¿hasta dónde llega el $LogFile? Límites y trampas

Preguntas frecuentes

¿Qué es el $LogFile de NTFS?

Es el diario de transacciones de metadatos de NTFS, guardado como entrada 2 de la MFT en la raíz de todo volumen NTFS. Antes de modificar sus propios metadatos, NTFS escribe un registro que describe el cambio como una operación redo y una operación undo, para poder reparar el volumen tras un fallo.

¿El $LogFile registra marcas de tiempo?

Los registros del diario no llevan hora de reloj propia. Las horas salen de los datos registrados: los valores de $STANDARD_INFORMATION y $FILE_NAME contenidos en los bytes redo y undo. Los eventos sin ninguno de esos valores solo pueden situarse respecto a sus vecinos por el LSN.

¿Hasta dónde llega hacia atrás el $LogFile?

Es circular y suele rondar los 64 MiB, así que cubre de minutos a horas de actividad en un volumen de sistema con mucho uso, y más en volúmenes de datos tranquilos. En una prueba publicada con Windows 10, los datos antiguos se sobrescribieron a los 16 minutos; en otra, a las 5 horas y 20 minutos.

Para saber más

• Maxim Suhanov, How the $LogFile works?: la mejor descripción pública del funcionamiento interno del LFS.
• Kernel de Linux, fs/ntfs3/fslog.c: una implementación funcional de la reproducción del diario, con los desplazamientos de las estructuras.
• libyal, documentación de NTFS de libfsntfs.
• Joakim Schicht, LogFileParser: el decodificador de código abierto de referencia, con un readme detallado.
• Gyu-Sang Cho, A computer forensic method for detecting timestamp forgery in NTFS, Computers & Security 34 (2013).

Artículos relacionados

• $LogFile, $UsnJrnl o $MFT: qué artefacto NTFS y cuándo
• Cómo adquirir el $LogFile de NTFS (en vivo y en frío)
• Detectar timestomping con el $LogFile de NTFS