Il journal Update Sequence Number di NTFS — comunemente chiamato USN Journal o semplicemente $UsnJrnl:$J — è uno degli artefatti più sottovalutati della forense di Windows. Ogni volta che NTFS crea, elimina, rinomina, tronca o tocca un file su un volume, aggiunge un record a questo log. I record sono minuscoli (qualche decina di byte ciascuno) e il journal è gestito come un buffer circolare di dimensione fissa: una macchina attiva conserva tipicamente gli ultimi milioni di operazioni su file.
Dove vive il journal
Il journal non è un file ordinario. È un flusso di dati alternativo chiamato $J, attaccato al file \$Extend\$UsnJrnl nella radice del volume. Da un'immagine forense lo estrai tipicamente con uno strumento che capisce gli stream di metadati NTFS (FTK Imager, X-Ways, icat di The Sleuth Kit, ...). Il blob $J risultante è ciò che strumenti come il parser WebAssembly di questo sito o usnrs consumano.
Struttura di un record (USN_RECORD_V2)
Ogni record è una struttura USN_RECORD_V2:
| Campo | Byte | Significato |
|---|---|---|
| RecordLength | 4 | Dimensione totale del record, nome incluso |
| Major / Minor version | 2 + 2 | Attualmente 2.0 |
| FileReferenceNumber | 8 | Entry MFT + sequenza del file |
| ParentFileReferenceNumber | 8 | Entry MFT + sequenza della directory padre |
| USN | 8 | Posizione del record all'interno del journal |
| Timestamp | 8 | FILETIME di Windows (tick da 100 ns dal 1601-01-01) |
| Reason | 4 | Bitmask che descrive cosa è cambiato (FileCreate, Close, ...) |
| SourceInfo | 4 | Suggerimenti (es. DATA_MANAGEMENT per cambi guidati dall'OS) |
| SecurityId | 4 | Indice in $Secure:$SII |
| FileAttributes | 4 | Attributi NTFS standard |
| FilenameLength / Offset | 2 + 2 | Posizione del nome UTF-16 nel record |
| Filename | n | UTF-16 LE, senza terminatore null |
Il campo "reason" è il più informativo: è un bitmask, e il ciclo di vita tipico di un singolo file produce una sequenza come FileCreate | DataExtend → DataExtend | Close → BasicInfoChange | Close → FileDelete | Close. Ricostruire questa sequenza è ciò che ti permette, a posteriori, di raccontare cosa è davvero successo a un file.
Perché conta in DFIR
Due ragioni:
- Sopravvive alla cancellazione. Anche dopo che un file è sparito dal filesystem (e dal cestino), la sua storia di operazioni resta nel journal finché il buffer circolare non la sovrascrive.
- Costa poco interrogarlo. Un
$Jda 100 MB contiene tipicamente milioni di record che coprono giorni o settimane di attività, e ogni record è autodescrittivo.
Quando correli il journal contro il $MFT, puoi risolvere percorsi completi per quasi tutti i record — il $MFT ti dà la catena parentale via l'attributo $FILE_NAME di ogni entry. È esattamente quello che fa per te l'opzione «trascina il tuo $MFT» di questo sito.
Cosa viene dopo
Se non hai mai guardato un journal, il modo più semplice per farti un'idea è prenderne uno da una macchina di test e trascinarlo nel riquadro in cima a questa pagina. I prossimi articoli della serie scaveranno nei flag di razionale, nei compromessi del journal carving e nel posto del journal accanto agli altri artefatti di timeline di Windows ($LogFile, Prefetch, ShimCache).