$LogFile, $UsnJrnl o $MFT: qué artefacto NTFS y cuándo
$LogFile, $UsnJrnl:$J y $MFT comparados desde el diario de transacciones: qué registra cada uno, cuánto abarca, qué solo prueba el $LogFile y cómo cruzarlos.
TL;DR. El $MFT te dice qué existe ahora. $UsnJrnl:$J te dice qué tipo de cambio sufrió cada archivo y cuándo, a lo largo de días o semanas. $LogFile te dice exactamente qué bytes cambiaron —nombres anteriores y nuevos, marcas de tiempo anteriores y nuevas—, pero solo para los últimos minutos u horas y sin reloj propio. Empieza por el $MFT y el diario USN, y recurre a $LogFile para las preguntas que esos dos no pueden responder: «¿cuál era el valor antes?» y «¿qué pasó en la última hora que los otros dos han perdido?».
Los tres están en el mismo volumen, describen los mismos archivos con las mismas referencias MFT y se suelen adquirir juntos. No son intercambiables. Elegir mal el primero cuesta horas; ignorar el tercero cuesta hallazgos.
Los tres en una tabla
$MFT | $UsnJrnl:$J | $LogFile | |
|---|---|---|---|
| Entrada de la MFT | 0 | en $Extend\$UsnJrnl, flujo $J | 2 |
| Finalidad | Índice de todos los archivos y carpetas | Diario de cambios para aplicaciones (copias de seguridad, búsqueda, replicación) | Recuperación de los metadatos ante fallos |
| Unidad | Registro FILE (1 KiB o 4 KiB) | Registro USN | Registro del diario (redo + undo) |
| Marca de tiempo por entrada | No (las horas del propio archivo) | Sí, hora del cambio | No |
| Nombres | Los $FILE_NAME actuales | El nombre en el momento del cambio | Cuando el nombre forma parte del cambio (creación, renombrado, borrado) |
| Valores de antes/después | No | No (solo flags de motivo) | Sí |
| Historial típico | Estado actual + entradas borradas no reutilizadas | De días a semanas | De minutos a horas |
| Se puede desactivar | No | Sí (fsutil usn deletejournal) | No |
La última fila importa en las intrusiones. El diario USN es una función opcional que un administrador —o un atacante con privilegios de administrador— puede borrar. $LogFile forma parte del funcionamiento de NTFS: no se puede desactivar en un volumen montado, solo redimensionar (chkdsk /L, según la referencia de chkdsk de Microsoft).
Qué ve cada uno cuando se renombra un archivo
Tomemos un evento: rc.tmp, en C:\Users\Public, pasa a llamarse rclone.exe.
$MFT, a posteriori: un registro FILE llamadorclone.execon carpeta padrePublic. El nombre anterior ha desaparecido, salvo que sobreviva una entrada antigua en el slack de$I30.$UsnJrnl:$J: dos registros con la misma referencia de archivo —RENAME_OLD_NAMEconrc.tmpy luegoRENAME_NEW_NAMEconrclone.exe—, cada uno con su marca de tiempo.$LogFile: unDeleteIndexEntryque quitarc.tmpdel índice de la carpeta padre, unAddIndexEntryque añaderclone.exey cambios del atributo$FILE_NAMEen el registro FILE. Las entradas de índice incluyen estructuras$FILE_NAMEcompletas, con sus cuatro marcas de tiempo.
Para un renombrado, el diario USN es más sencillo y está fechado. $LogFile solo gana si los registros USN han desaparecido o si necesitas los valores incluidos.
Qué ve cada uno cuando se reescribe una marca de tiempo
Ahora, el caso en el que $LogFile es único. Un atacante pone la fecha de creación de m64.exe en 2019-03-19.
$MFT: creación en$STANDARD_INFORMATION= 2019-03-19. Creación en$FILE_NAME= hoy. Esa discrepancia es un indicio clásico, pero solo un indicio: una copia, la extracción de un archivo comprimido o un instalador también pueden producir combinaciones raras.$UsnJrnl:$J: un registro con el motivoBASIC_INFO_CHANGEa la hora del cambio. Sabes que algo cambió en la información básica (horas o atributos), pero no qué.$LogFile: unUpdateResidentValuesobre$STANDARD_INFORMATIONcuyos bytes undo contienen la fecha de creación anterior y cuyos bytes redo contienen 2019-03-19. Es la propia reescritura.
Por eso el análisis de timestomping se apoya en el diario. El método, y sus falsos positivos, están en detectar timestomping con el $LogFile de NTFS. El artículo de Cho de 2013 (Computers & Security 34) dice lo mismo: los valores de tiempo anteriores hallados en $LogFile convierten una marca de tiempo sospechosa en una evidencia.
Cómo se enlazan
Los tres artefactos comparten claves; es lo que David Cowen llamó la NTFS TriForce:
| Clave | En el $MFT | En $UsnJrnl:$J | En $LogFile |
|---|---|---|---|
| Entrada de la MFT + número de secuencia | Número de registro, secuencia de la cabecera | Referencia del archivo, referencia del padre | Entrada destino (a partir del VCN + desplazamientos), entradas de índice |
| LSN | Cabecera del registro FILE 0x08: LSN del último cambio registrado | — | Todos los registros |
| USN | Último USN en $STANDARD_INFORMATION | Todos los registros | Las escrituras en el diario USN también quedan registradas |
Esa última fila es útil. El readme de LogFileParser señala que, cuando el diario USN está activo, los registros USN escritos durante la vida del diario de transacciones también están dentro de $LogFile, y los decodifica en un CSV aparte. En la práctica, el diario USN suele llegar más atrás, pero para la ventana más reciente el $LogFile puede tapar un hueco.
¿Por cuál empezar? Cuatro escenarios
«¿Qué archivos creó esta cuenta esta mañana?» Primero el diario USN (fechado, historial largo) y el $MFT para las rutas. $LogFile solo si la mañana sigue dentro.
«¿Se antedató este binario?» El $MFT para detectar la discrepancia $SI/$FN; después, $LogFile para encontrar la reescritura en sí y el valor original. El diario USN da la hora del BASIC_INFO_CHANGE.
«El atacante borró el diario USN.» $LogFile para los últimos minutos u horas; el $MFT para el estado actual y las entradas borradas pero no reutilizadas; las instantáneas de volumen (VSS) para copias más antiguas de los tres.
«¿Qué decía ese archivo de texto borrado?» Solo $LogFile tiene alguna posibilidad, y solo si el archivo era lo bastante pequeño para ser residente y los registros pertinentes siguen ahí. Consulta $LogFile: recuperar evidencias de archivos borrados.
Herramientas para cada uno
$MFT: cualquier analizador de la MFT (MFTECmd, analyzeMFT, suites comerciales).$UsnJrnl:$J: el analizador del diario USN hermano, en el navegador, o MFTECmd. usnparser.com tiene además su propia comparativa de los tres artefactos, escrita desde el punto de vista del USN.$LogFile: el analizador de $LogFile en el navegador (suelta el$MFTjunto a él para obtener rutas completas), LogFileParser, NTFS Log Tracker, TZWorks mala; todos comparados en analizadores de $LogFile: LogFileParser, NTFS Log Tracker.
Recuerda que los archivos del mismo volumen deben adquirirse juntos. Un $LogFile del lunes y un $MFT del martes resolverán algunas entradas de la MFT con nombres equivocados en cuanto se hayan reutilizado entradas.
Preguntas frecuentes
¿Qué diferencia hay entre el $LogFile y el $UsnJrnl?
$UsnJrnl:$J es un diario de cambios pensado para las aplicaciones: un registro por cambio con marca de tiempo, flags de motivo, referencia y nombre del archivo, y suele cubrir días o semanas. $LogFile es el diario de recuperación ante fallos de NTFS: bytes redo y undo de bajo nivel para cada cambio de metadatos, sin marcas de tiempo propias, y cubre de minutos a horas.
Si tengo el diario USN, ¿sigo necesitando el $LogFile?
Sí, cuando la pregunta es sobre valores y no sobre eventos. El diario USN dice que cambió la información básica de un archivo; el $LogFile puede mostrar las marcas de tiempo anteriores y nuevas. También ayuda, para la actividad más reciente, cuando el diario USN se ha borrado o desactivado.
Para saber más
- Microsoft Learn, Change Journals.
- David Cowen, NTFS TriForce — a deeper look inside the artifacts.
- Maxim Suhanov, How the $LogFile works?