← Torna al blog

Ricostruire una timeline di attività utente dal journal USN

Da tre minuti di record $UsnJrnl si può solitamente ricostruire cosa stava facendo un utente — Office, browser, download, codice. Come leggere il journal come un log di comportamento.

5 min di lettura

Buona parte della domanda «cos'è successo su questo computer fra le 14:00 e le 16:00» si risolve direttamente con il journal USN. I record non sono un log di syscall e non sono taggati con un utente — ma hanno qualcosa quasi altrettanto utile: un registro ad alta frequenza, per operazione, di ogni file toccato dalla macchina. Con un po' di conoscenza dei pattern, si può recuperare il comportamento dell'utente alla granularità di salvataggio Office, navigazione browser, rebuild IDE, pausa pranzo.

Questo articolo è la guida sul campo per leggere il journal come timeline comportamentale.

Perché funziona

Il journal USN registra quale file è cambiato, quando e come — e la maggior parte delle azioni visibili dell'utente su un desktop produce una firma riconoscibile di attività di file. L'utente clicca Salva in Word; Word scrive un temp, rinomina atomicamente e fa BasicInfoChange | Close sul risultato. Chrome apre una nuova scheda; la cache disco si estende. L'IDE ricompila; nascono mille file oggetto.

Queste firme non sono documentate ufficialmente — si imparano. Sotto un set iniziale, più i controlli del parser che le rendono trattabili.

Office in pratica

Quando un utente salva un Word, Excel o PowerPoint, vedi:

FileCreate | Close            ~$<filename>.docx     (file di lock)
FileCreate | Close            <filename>.tmp        (temp atomico)
DataExtend | Close            <filename>.tmp        × N
RenameOldName | Close         <filename>.docx
FileDelete | Close            <filename>.docx
RenameNewName | Close         <filename>.docx       (era <filename>.tmp)
FileDelete | Close            ~$<filename>.docx
BasicInfoChange | Close       <filename>.docx

Il file di lock ~$ è il segnale Office che un documento è aperto; il suo FileCreate e FileDelete dicono il momento di apertura/chiusura. La rinomina atomica .tmp.docx è il salvataggio stesso. I file ~$ in testa sono sorprendentemente utili perché esistono solo mentre il documento è aperto.

Trucco di pivot: filtrare i FileCreate il cui nome inizia con ~$ per enumerare tutti i documenti Office aperti dall'utente nella finestra. Sottrarre i FileDelete degli stessi nomi per trovare quelli ancora aperti al momento dell'acquisizione (un'immagine forense da una macchina viva può avere file di lock per documenti mai chiusi correttamente).

Attività browser

I browser moderni mantengono cache pesanti sul filesystem. Chrome e Edge usano \Users\<u>\AppData\Local\<browser>\User Data\Default\Cache\Cache_Data\ (o Code Cache\); Firefox usa \Users\<u>\AppData\Local\Mozilla\Firefox\Profiles\<id>\cache2\.

Cosa si vede durante la navigazione:

  • Un tasso basso e continuo di FileCreate | Close e DataExtend | Close nella directory di cache.
  • Occasionali FileDelete | Close mentre l'LRU sfratta vecchie entry.
  • Ogni pochi minuti, RenameNewName di file di cache mentre l'indice si compatta.

Le raffiche di scritture cache si correlano bene con la visita di siti pesanti di media o SPA. I periodi tranquilli si correlano con l'utente assente o su una pagina lunga da caricare.

I nomi dei file di cache non dicono quali URL siano stati visitati (è nel DB del browser stesso), ma la cadenza dell'I/O di cache dice che l'utente stava navigando. Combinare con gli eventi FileCreate del journal nella directory Downloads\ dell'utente per identificare download deliberati.

Attività di codice

Se l'utente è uno sviluppatore, i rebuild dell'IDE producono raffiche molto caratteristiche:

  • Webpack/Vite/Turbopack — molti FileCreate in node_modules\.cache\ e dist\, spesso centinaia per build.
  • Visual Studio C++FileCreate di file .obj e .pdb in sottoalberi Debug\ o Release\.
  • Cargo (Rust) — i build incrementali toccano molto target\debug\incremental\; i build completi toccano target\debug\deps\.

Una raffica di 5 minuti di FileCreate in node_modules\, seguita da uno sciame di DataExtend su un dist\bundle.js, è «ha lanciato il build, poi un dev server ha ricaricato».

Download e installazioni

Un download diretto produce:

FileCreate | Close             \Users\<u>\Downloads\<file>.crdownload   (Chrome)
DataExtend | Close             \Users\<u>\Downloads\<file>.crdownload  × N
RenameNewName | Close          \Users\<u>\Downloads\<file>
BasicInfoChange | Close        \Users\<u>\Downloads\<file>

Le estensioni .crdownload, .part, .download sono Chrome, Firefox, Edge rispettivamente. La rinomina atomica alla fine fa apparire il file come «completo».

L'installazione di un nuovo programma di solito segue: FileCreate di un installer .exe/.msi in Downloads, poi una raffica di FileCreate in \Program Files\ o \Program Files (x86)\ o \Users\<u>\AppData\Local\Programs\. L'istogramma minuto per minuto rende le installazioni banalmente identificabili.

Mettere tutto insieme: una timeline giornaliera

La ricetta per un report «cosa ha fatto oggi l'utente»:

  1. Tirare il journal parsato dell'utente per la giornata. Restringere ai record sotto \Users\<u>\ per togliere il rumore di sistema.
  2. Calcolare, per bucket da 10 minuti: numero di FileCreate, DataExtend, BasicInfoChange.
  3. Plottare le tre serie. La forma dice l'attività approssimativa:
    • Molti create + extend: scrittura/salvataggio di contenuti.
    • Solo molto BasicInfoChange: navigazione, scroll, editing leggero.
    • Molto extend con poco create: download grandi o riproduzione media.
    • Create continui in directory Cache\: navigazione.
    • Create continui in node_modules\ / Debug\ / target\: coding.
  4. Annotare i picchi ispezionando i nomi di file più frequenti in ogni bucket. I nomi dei file Office sono ottime ancore; i nomi di cache si possono di solito ignorare.

Il parser di questo sito espone l'istogramma per minuto nel suo componente timeline — cliccare una barra filtra la tabella su quella finestra, che è il workflow di sopra senza scrivere codice.

Trappole

  • Backup e scansioni AV producono raffiche di BasicInfoChange a livello di volume che superficialmente assomigliano ad attività utente. Di solito seguono orari pianificati e visitano tutte le directory, non solo quelle dell'utente, il che li rende facili da identificare ed escludere.
  • Agenti di sync (OneDrive, Dropbox) generano traffico di journal che sembra attività utente ma è lavoro dell'agente stesso. Filtrare a record il cui percorso è fuori dalla cartella di sync per concentrarsi sul lavoro iniziato dall'utente.
  • Indicizzatori in background (SearchIndexer.exe) toccano file in \Users\<u>\AppData\Roaming\Microsoft\Windows\Recent\ e \ProgramData\Microsoft\Search\ — facili da catalogare come rumore di sistema.

Dove andare poi

Il journal da solo non sostituisce una super-timeline a regola d'arte. Ma per l'80% delle indagini, «cosa stava facendo l'utente fra le 14:00 e le 16:00» è rispondibile solo con $J e $MFT, nel tempo che serve a trascinarli su questa pagina.