El Update Sequence Number Journal de NTFS — habitualmente llamado USN Journal o simplemente $UsnJrnl:$J — es uno de los artefactos más infravalorados de la forense de Windows. Cada vez que NTFS crea, elimina, renombra, trunca o toca de algún modo un fichero en un volumen, añade un registro a este log. Los registros son diminutos (unas decenas de bytes cada uno) y el journal se gestiona como un anillo de tamaño fijo, así que en una máquina activa conserva del orden de los últimos millones de operaciones sobre ficheros.
Dónde vive el journal
El journal no es un fichero normal. Es un flujo de datos alternativo llamado $J adjunto al fichero \$Extend\$UsnJrnl en la raíz del volumen. Desde una imagen forense lo extraes con una herramienta que entienda los streams de metadatos NTFS (FTK Imager, X-Ways, icat de The Sleuth Kit, etc.). El blob $J resultante es lo que consumen herramientas como el parser WebAssembly de este sitio o usnrs.
Estructura de un registro (USN_RECORD_V2)
Cada registro es una estructura USN_RECORD_V2:
| Campo | Bytes | Significado |
|---|---|---|
| RecordLength | 4 | Tamaño total del registro, nombre incluido |
| Major / Minor version | 2 + 2 | Actualmente 2.0 |
| FileReferenceNumber | 8 | Entrada MFT + secuencia del fichero |
| ParentFileReferenceNumber | 8 | Entrada MFT + secuencia del directorio padre |
| USN | 8 | Posición del registro dentro del journal |
| Timestamp | 8 | FILETIME de Windows (tics de 100 ns desde 1601-01-01) |
| Reason | 4 | Bitmask que describe el cambio (FileCreate, Close, ...) |
| SourceInfo | 4 | Pistas (p. ej. DATA_MANAGEMENT para cambios del SO) |
| SecurityId | 4 | Índice dentro de $Secure:$SII |
| FileAttributes | 4 | Atributos NTFS estándar |
| FilenameLength / Offset | 2 + 2 | Ubicación del nombre UTF-16 dentro del registro |
| Filename | n | UTF-16 LE, sin terminador nulo |
El campo "reason" es el más informativo: es un bitmask, y el ciclo de vida típico de un fichero produce una secuencia como FileCreate | DataExtend → DataExtend | Close → BasicInfoChange | Close → FileDelete | Close. Reconstruir esa secuencia es lo que permite, a posteriori, contar qué le ocurrió realmente al fichero.
Por qué importa en DFIR
Dos razones:
- Sobrevive al borrado. Incluso después de que un fichero desaparezca del sistema de ficheros (y de la papelera), su historia de operaciones sigue en el journal hasta que el anillo lo sobreescribe.
- Es barato de consultar. Un
$Jde 100 MB suele albergar millones de registros que cubren días o semanas de actividad, y cada registro es autodescriptivo.
Cuando correlas el journal contra el $MFT, puedes resolver rutas completas para casi todos los registros — el $MFT te da la cadena de padres vía el atributo $FILE_NAME de cada entrada. Es exactamente lo que hace por ti la opción «suelta tu $MFT» de este sitio.
Lo que sigue
Si nunca has mirado un journal, la forma más sencilla de hacerte una idea es coger uno de una máquina de test y soltarlo en la zona en lo alto de esta página. Los próximos artículos de la serie profundizarán en los bits de razón, los compromisos del journal-carving y el lugar del journal junto a los otros artefactos de timeline de Windows ($LogFile, Prefetch, ShimCache).