TL;DR. Adquiere el $LogFile y el $MFT del mismo volumen. Suelta los dos en el analizador de $LogFile en el navegador. Lee primero la línea de cabecera (versión, desmontado limpio o no, rango de LSN, avisos). Después prioriza en la vista de eventos con Solo marcados, abre el panel de detalle de cada hallazgo para ver de dónde salen su hora y su ruta, salta a los registros en bruto para comprobar los bytes redo/undo y exporta a CSV/JSON. Las marcas son heurísticas; los registros en bruto son la evidencia. Confirma con una segunda herramienta todo lo que vaya a un informe.

Este recorrido usa el ejemplo integrado en el analizador: un diario LFS 2.0 y un $MFT sintéticos de una intrusión ficticia en una estación de trabajo llamada FIN-WKS-07. Pulsa Probar un ejemplo en la página de la herramienta para seguirlo. Todos los nombres, horas y contenidos del ejemplo son inventados.

Paso 1: adquirir los dos archivos juntos

El analizador puede leer un $LogFile solo, pero las rutas quedarán incompletas. Los registros del diario designan los archivos por su entrada de la MFT; el nombre solo aparece en el diario cuando el archivo se crea, se renombra o se borra. El $MFT completa todo lo demás.

Sin el $MFT, el tools.zip del ejemplo se resuelve como [MFT #61]\svc_backup\Downloads\tools.zip (la carpeta Users no aparece nombrada en ninguna parte del diario conservado). Con él, la ruta es \Users\svc_backup\Downloads\tools.zip.

Los comandos de adquisición para KAPE, Velociraptor, FTK Imager, RawCopy e icat están en cómo adquirir el $LogFile de NTFS (en vivo y en frío).

Paso 2: cargar los archivos

Suelta los archivos, elige una carpeta o suelta una colección ZIP de triaje (las estructuras de KAPE y Velociraptor funcionan tal cual). Cada $LogFile se empareja con el $MFT que esté en la misma carpeta, así que usa una carpeta por volumen.

Lo que ocurre a continuación no sale de la pestaña del navegador: el analizador es Rust compilado a WebAssembly y se ejecuta en un Web Worker. El $MFT se lee por bloques de 16 MiB para construir un índice de nombres, así que los MFT de varios gigabytes funcionan sin cargar el archivo entero en memoria. No existe ningún punto de subida.

Los archivos que el analizador no puede usar se listan con un motivo en lugar de descartarse en silencio: una copia que empieza con ceros (probablemente bloqueada al copiarla), un $UsnJrnl:$J (esta herramienta no lo analiza: usa el analizador del diario USN) o un $MFT sin un $LogFile al lado.

Paso 3: leer la línea de cabecera antes que los eventos

Para el ejemplo, la línea de cabecera dice, en esencia:

Campo	Valor del ejemplo	Qué te dice
Versión del diario	LFS 2.0	Windows 8 o posterior, volumen montado en el momento de la captura (1.1 frente a 2.0)
Tamaño	256 KiB	Inusualmente pequeño; los volúmenes de sistema reales suelen rondar los 64 MiB
Páginas de registros	5	Cuántas páginas circulares contienen registros
Rango de LSN	115720 → 117880	Registro más antiguo y más reciente encontrados (los LSN, explicados)
Desmontaje	no desmontado limpiamente	Captura en vivo o fallo
Páginas de cola / rápidas	1 página leída del área de páginas rápidas	La página más reciente solo existía ahí: típico de una captura en vivo

Lee también el recuadro de avisos del analizador. Una copia truncada, páginas que no superan la comprobación del update sequence array o una página de reinicio CHKD cambian cuánto puedes fiarte del resultado.

Paso 4: priorizar la vista de eventos

Los contadores de resumen dan el número de eventos por tipo. En el ejemplo: 14 creaciones, 2 borrados, 2 renombrados/movimientos, 6 cambios de $STANDARD_INFORMATION, 2 escrituras de datos residentes y 1 indicio de timestomping.

Después, acota:

Tipo de evento: Creado, Borrado, Renombrado / movido, Marcas de tiempo cambiadas ($SI), Datos residentes escritos.
Solo marcados: conserva los eventos con al menos una marca.
Búsqueda: ruta, nombre, contenido, LSN o fecha.

Las cinco marcas y lo que las activa:

Marca	Se activa cuando
Borrado	El evento es un borrado
Renombrado / movido	El evento es un renombrado o un movimiento
Cambio de marca de tiempo (posible timestomping)	Se reescribió la fecha de creación, un valor retrocedió, hay un valor en segundos exactos o la creación en `$SI` es anterior a la de `$FN`
Carpeta escribible por el usuario	Ruta bajo AppData/Downloads/Desktop/Documents de un perfil de usuario, `Users\Public`, `ProgramData`, `Windows\Temp`, `$Recycle.Bin` o `PerfLogs`
Ejecutable	El nombre termina en `.exe`, `.dll`, `.ps1`, `.bat`, `.js`, `.hta` o similares

En el ejemplo, Solo marcados más una ordenación por LSN deja ver la historia en una docena de filas: m64.exe creado en Downloads\tools, movido a \ProgramData\Intel y con las marcas de tiempo reescritas; rc.tmp dejado en \Users\Public y renombrado rclone.exe; creds.txt creado en el Escritorio y borrado.

Paso 5: abrir el panel de detalle

Al hacer clic en un evento se abre su detalle. Hay tres campos que merecen atención siempre:

Hora obtenida de. NTFS no registra la hora de reloj. El analizador fecha cada evento con datos contenidos en los registros: la creación de $FILE_NAME (creaciones), el cambio de $FILE_NAME (renombrados), el nuevo valor de $SI (cambios de marcas de tiempo) o la última hora conocida antes de un borrado. Los eventos sin ninguno de esos datos toman la hora del evento fechado más cercano y se marcan con ≈. El cambio de marcas de tiempo de m64.exe en el ejemplo es uno de ellos: sus nuevos valores apuntan a 2019, así que el analizador se niega a usarlos como hora del cambio.
Ruta obtenida de. Nombres encontrados en el diario, el $MFT, parcial (una carpeta antecesora es desconocida) o desconocido.
Por qué está marcado. Para m64.exe: se reescribió la fecha de creación, una marca de tiempo retrocedió, hay un valor en segundos exactos y la creación en $SI es anterior a la de $FN. El panel muestra $SI antes (2026-09-14 10:06:52.3551871) y después (2019-03-19 07:14:22.0000000).

Para valorar esos motivos, consulta detectar timestomping con el $LogFile de NTFS.

Paso 6: verificar con los registros en bruto

Cada evento enlaza con sus registros del diario (Mostrar estos registros). La vista de registros lista cada uno con su LSN, id. de transacción, operaciones redo y undo, atributo destino y entrada de la MFT o archivo destino. Su panel de detalle añade el LSN anterior, el LSN undo siguiente, el tipo de registro, el VCN destino, los desplazamientos de registro / atributo / bloque de clúster, el desplazamiento en el archivo, si el registro ocupa varias páginas y volcados hexadecimales de los bytes redo y undo.

Para el cambio de marcas de tiempo de m64.exe deberías ver un par UpdateResidentValue / UpdateResidentValue sobre $STANDARD_INFORMATION, con los valores nuevos en los bytes redo y los antiguos en los bytes undo. Para un renombrado, un DeleteIndexEntry* seguido de un AddIndexEntry* para la misma entrada. El significado de cada opcode se explica en las operaciones redo/undo del $LogFile de NTFS, explicadas.

Este paso es el que hace defendible un hallazgo. Un evento es la interpretación del analizador; un registro con sus bytes y desplazamientos es lo que puedes enseñar a otra persona y lo que una segunda herramienta debería reproducir.

Paso 7: exportar y correlacionar

Las dos vistas se exportan a CSV (con protección contra la inyección de fórmulas) o JSON. Las horas pueden mostrarse en UTC o en hora local, con una precisión de 100 ns. Exporta lo que hayas filtrado, no el diario entero, y conserva los LSN: son la clave estable para citar un registro.

Después, correlaciona:

$UsnJrnl:$J da registros fechados RENAME_*, FILE_CREATE, FILE_DELETE y BASIC_INFO_CHANGE (analizador del diario USN).
Prefetch muestra si m64.exe o rclone.exe llegaron a ejecutarse (analizador de Prefetch); el ejemplo incluso registra la creación de M64.EXE-1C9E54B7.pf.
Los archivos LNK y las Jump Lists muestran qué se abrió (analizador de LNK); el Payroll_2026.xlsx.lnk de Recent en el ejemplo es una pista en ese sentido.

Paso 8: confirmar con una segunda herramienta

El analizador se ha validado con diarios sintéticos escritos a partir del formato publicado (Linux ntfs3, libfsntfs, la descripción de dfir.ru), no todavía con un corpus de diarios reales de Windows. La agrupación de eventos usa una ventana de registros por entrada de la MFT en lugar de las transacciones. Para todo lo que acabe en un informe, vuelve a pasar el diario por LogFileParser o NTFS Log Tracker y compara los registros por LSN. Consulta analizadores de $LogFile: LogFileParser, NTFS Log Tracker.

Errores habituales

Analizar un $LogFile con un $MFT de otro día: las entradas de la MFT se reutilizan y los nombres salen mal.
Tomar las horas «≈» como hechos. Son horas de los vecinos.
Tratar una marca de timestomping como una prueba. Un valor en segundos exactos puede venir de un descompresor de archivos; un retroceso puede venir de una restauración legítima.
Quedarse en la vista de eventos. Algunos cambios no se reconstruyen como eventos; la vista de registros muestra todo lo que el diario aún conserva.

Cómo analizar un $LogFile de NTFS paso a paso