Ricostruire una timeline di attività utente dal USN journal

Da tre minuti di record $UsnJrnl puoi di solito ricostruire cosa stava facendo un utente: Office, browser, download, codice. Come leggere il journal come un log di comportamento.

Di 7 min di lettura

Una gran parte di "cosa stava succedendo su questo computer tra le 14:00 e le 16:00" può essere risposta direttamente dal USN journal, senza nessun altro artefatto. I record non sono un log di syscall e non sono taggati con un utente, ma sono qualcosa quasi altrettanto utile: una registrazione ad alta frequenza, per-operazione, di ogni file che la macchina ha toccato. Con la conoscenza dei pattern che richiede pochi engagement per costruirsi, puoi recuperare il comportamento alla granularità di save di Office, navigazione browser, rebuild IDE, pausa pranzo.

Questo post è la guida sul campo per leggere il journal come una timeline di comportamento.

Perché funziona del tutto

La maggior parte delle azioni visibili all'utente su un desktop Windows produce una firma riconoscibile nel filesystem. Clicca Save in Word e Word scrive un file temp, lo rinomina atomicamente, e fa BasicInfoChange | Close sul risultato. Apri una nuova tab in Chrome e la cache disco si aggiunge. Esegui un npm install e mille file package.json sbocciano in secondi.

Queste firme non sono documentate in nessun riferimento Microsoft. Si imparano guardando journal di host di esperimenti controllati e abbinandoli ad attività note. Sotto c'è un set di partenza, ordinato per quanto spesso vedo ciascuno nei casi.

Office allo stato brado

Quando un utente salva un file 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 di Office che un documento è aperto. Il suo FileCreate e FileDelete racchiudono precisamente la finestra di apertura/chiusura. La rinomina atomica .tmp a .docx è il save stesso. Il BasicInfoChange alla fine è il nuovo file che si fa stampare la mtime alla chiusura.

Un trucco di pivot che uso in ogni engagement: filtra per record FileCreate il cui nome inizia con ~$. Ti dà ogni documento Office che l'utente ha aperto nella finestra. Sottrai FileDelete degli stessi nomi e hai tutti i documenti ancora aperti al momento dell'acquisizione, che su una cattura live corrisponde ai documenti che l'utente aveva aperti quando la macchina è stata imaged. Quell'ultimo bit è finito in più di un report come la risposta a "cosa stava davvero facendo l'utente nel momento in cui siamo entrati".

Attività browser

I browser moderni mantengono pesanti cache su filesystem. Chrome e Edge usano \Users\<u>\AppData\Local\<browser>\User Data\Default\Cache\Cache_Data\ (più Code Cache\). Firefox usa \Users\<u>\AppData\Local\Mozilla\Firefox\Profiles\<id>\cache2\. Durante la navigazione:

  • Un tasso basso sostenuto di FileCreate | Close e DataExtend | Close nella directory cache.
  • FileDelete | Close occasionali mentre l'LRU sfratta voci vecchie.
  • Ogni pochi minuti, RenameNewName di file cache mentre l'indice viene compattato.

Le raffiche di scritture cache correlano con la visita di siti pesanti di media o applicazioni single-page. I periodi tranquilli correlano con l'utente assente o su una pagina a caricamento lungo. La riproduzione video attiva produce una forma diversa — DataExtend sostenuto grande su un singolo file cache invece di molti piccoli create.

I nomi dei file di cache non codificano URL. Per quello, pivota ai database SQLite del browser via il tooling di forense del browser. Il contributo del journal è la cadenza — che l'utente stava navigando attivamente durante una finestra specifica — più gli eventi FileCreate espliciti in \Users\<u>\Downloads\ per download deliberati.

Attività di codice

Se l'utente è uno sviluppatore, l'attività IDE e di strumenti di build produce raffiche altamente caratteristiche:

  • Webpack, Vite, Turbopack — molti FileCreate in node_modules\.cache\, node_modules\.vite\, .next\ e dist\. Centinaia per build.
  • Visual Studio C++ — FileCreate di file .obj e .pdb in sottoalberi Debug\ o Release\.
  • Cargo (Rust) — Le build incrementali toccano target\debug\incremental\ molto; le build complete toccano anche target\debug\deps\.
  • Go — Raffiche corte e intense in $GOPATH\pkg\ e nella cache di build sotto \Users\<u>\AppData\Local\go-build\.
  • npm install e yarn install — Migliaia di record FileCreate sotto node_modules\ in decine di secondi. L'attività utente più rumorosa del journal.

Una raffica di cinque minuti di FileCreate in node_modules\ seguita da uno sciame DataExtend su dist\bundle.js è "ha lanciato il build, poi un dev server ha ricaricato". Leggi la sezione esclusioni sotto — quelle raffiche soffocheranno tutto il resto se non le filtri fuori per analisi non di sviluppo.

Download e installazioni

Un download diretto via Chrome:

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

Firefox usa .part, Edge usa .download. La rinomina atomica alla fine è ciò che fa apparire il file "completo" a Explorer e altri lettori.

L'installazione di un nuovo programma segue tipicamente: FileCreate di un installer (.exe, .msi, .appx) in Downloads, poi una raffica di record FileCreate sotto \Program Files\, \Program Files (x86)\ o \Users\<u>\AppData\Local\Programs\. L'istogramma al minuto rende le install banalmente identificabili. Incrocia con AmCache e Prefetch per il lato di esecuzione.

Mettendolo insieme: la ricetta della timeline quotidiana

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

  1. Tira il journal parsato dell'utente per la giornata. Restringi ai record il cui percorso risolto inizia con \Users\<u>\ (l'utente target). Questo elimina Windows Update, cache di sistema e rumore OS che altrimenti domina.
  2. Calcola, per bucket di 10 minuti: conteggi di FileCreate, DataExtend, BasicInfoChange.
  3. Traccia le tre serie. La forma ti dice l'attività grossolana:
    • Create alti più extend. Scrivendo o salvando contenuto.
    • BasicInfoChange alto da solo. Navigando, scrollando, modifiche leggere dove Office o l'editor tocca il file senza scritture significative.
    • Extend alto con create basso. Grande download o riproduzione multimediale.
    • Create sostenuti in percorsi Cache\. Navigazione.
    • Create sostenuti in node_modules\ o target\ o Debug\. Codifica.
  4. Annota i picchi ispezionando i cinque nomi top in ogni bucket. I nomi Office e i file di lock ~$ sono ottime ancore. I nomi di cache di solito li puoi ignorare.

Il parser di questa pagina espone l'istogramma al minuto sul suo componente timeline. Cliccare una barra filtra la tabella a quella finestra, che è il workflow sopra senza scrivere codice.

Per l'attribuzione — quale utente era alla tastiera — abbina la timeline del journal ai logon interattivi 4624 di Security.evtx (LogonType=2) e ai logoff iniziati dall'utente 4647 dal parser EVTX. Quello racchiude i confini di sessione e ti dà un nome da mettere sull'attività.

Esclusioni e insidie

Le scansioni di backup e AV producono raffiche BasicInfoChange a livello volume che superficialmente assomigliano ad attività utente. Seguono orari programmati e visitano ogni directory invece di concentrarsi su un sottoalbero. Facili da identificare per copertura di percorso ed escludere.

Gli agenti di sync (OneDrive, Dropbox, Google Drive Backup and Sync) generano traffico journal che sembra attività utente ma è il lavoro proprio dell'agente. Filtra ai record fuori dalla cartella di sync per attività iniziata dall'utente, o guarda specificamente dentro la cartella di sync per il pattern esfil-via-cloud documentato nel post di esfiltrazione.

Indicizzatori in background. SearchIndexer.exe tocca file in \Users\<u>\AppData\Roaming\Microsoft\Windows\Recent\ e \ProgramData\Microsoft\Search\. MsMpEng.exe (Defender) produce eventi BasicInfoChange quando scansiona. Entrambi facili da raggruppare come rumore di sistema.

Chrome Software Reporter, Edge updater, Windows Update. Tutti producono raffiche prevedibili di FileCreate e DataExtend in \Program Files\ e \Windows\SoftwareDistribution\. Filtra per percorso.

node_modules\ e altri output di build dominano qualsiasi timeline che li includa. Per casi non di sviluppo, escludi node_modules\, target\, Debug\, Release\, obj\, bin\, .next\, dist\, build\ per prefisso di percorso.

Cosa il journal non può ricostruire

  • L'identità dell'utente. Correla i timestamp con i logon 4624 di Security.evtx.
  • Le URL visitate dall'utente. I database di storia del browser le contengono — il journal conosce solo la cadenza delle scritture cache.
  • Il contenuto di qualsiasi file. Solo metadati.
  • Qualsiasi cosa fuori dalla finestra del ring buffer. Un $J da 32 MB copre pochi giorni su un desktop. Tutto ciò che è più vecchio è sparito da questo artefatto; tira le Shadow Copy e $LogFile se ti serve più portata.

Per l'80% delle domande "cosa stava facendo l'utente tra X e Y", $J e $MFT insieme rispondono direttamente. Il restante 20% vuole Sysmon, EVTX, SRUM per uso di rete e CPU a livello applicazione, e una super-timeline come si deve.

Letture aggiuntive