← Torna al blog

Individuare timestomping e anti-forense nel journal USN

Gli attaccanti che modificano i timestamp del MFT non possono nascondersi dal change journal. Come le discordanze $STANDARD_INFORMATION vs $FILE_NAME e i BasicInfoChange inattesi smascherano l'attività anti-forense.

5 min di lettura

Gli operatori sofisticati non si limitano a cancellare le prove — provano a camuffare ciò che lasciano. La tecnica più comune è il timestomping: editare i timestamp NTFS di un file perché appaia innocuo (o fuori dalla finestra di indagine). Funzionava. Con il journal USN attivo lascia un segnale chiaro.

Questo articolo descrive cosa il timestomping fa al disco, come il journal lo espone, e quali altre mosse anti-forensi si catturano con lo stesso artefatto.

Ripasso veloce sui timestamp NTFS

Ogni entry MFT porta timestamp in due attributi:

  • $STANDARD_INFORMATION (SI): i timestamp che gli strumenti userland e la maggior parte delle API possono cambiare. Quelli che dir, Esplora risorse e Get-ChildItem mostrano. Formato documentato nella reference NTFS di Microsoft.
  • $FILE_NAME (FN): i timestamp che NTFS imposta internamente su ogni attributo $FILE_NAME. Tipicamente uno per nome (il file può avere più nomi se hard-linkato). Sono molto più difficili da cambiare — richiedono accesso kernel o tool specializzati.

Gli strumenti di timestomping (SetMACE, lo storico timestomp.exe dal modulo anti-forense di Metasploit, vari impianti custom) di solito puntano ai timestamp SI. Alcuni ora puntano anche a FN. In entrambi i casi toccano il MFT — e quel tocco accende il journal.

Cosa il journal registra per una modifica di timestamp

Quando i timestamp SI vengono scritti, NTFS emette un record BasicInfoChange | Close. Quel record è la pistola fumante, perché:

  • Un «touch» legittimo produce un BasicInfoChange | Close insieme a un DataExtend o DataOverwrite dalla scrittura reale che ha innescato l'aggiornamento dei timestamp.
  • Un timestomp produce un BasicInfoChange | Close nudo, senza scritture precedenti sulla stessa FileReferenceNumber.

Quando vedi BasicInfoChange | Close senza DataOverwrite, DataExtend o FileCreate nella stessa sessione di handle, stai guardando manipolazione di metadati — quasi sempre timestomping o cambi di attributo (flag read-only/hidden).

Il confronto classico: SI vs FN

La rilevazione di timestomping più autoritativa confronta i timestamp $STANDARD_INFORMATION di ogni file con i suoi timestamp $FILE_NAME. Gli investigatori Mandiant ne scrivono da anni; il white paper storico Mandiant sul timestomping è la reference, e Brian Carrier lo tratta in File System Forensic Analysis.

Il journal completa più che sostituire il confronto:

  • Il confronto MFT dice che il timestomping è successo a un certo punto. Non può dire quando.
  • I BasicInfoChange | Close del journal dicono esattamente quando è avvenuta la scrittura SI, e quale contesto di processo la circondava (accoppiato con Security.evtx 4663).

Un file timestompato appare così nei tuoi dati:

  1. Il confronto MFT segnala SI < FN (o SI nel futuro di FN, ecc.).
  2. Il journal ha un BasicInfoChange | Close a, diciamo, 2026-04-12 03:08:14 senza scritture intorno.
  3. Quel timestamp è ciò che metti nel report.

$LogFile e journal in disaccordo sulle scritture MFT

Il journal registra le scritture a livello di file; $LogFile registra le transazioni MFT sottostanti. Un timestomp produce:

  • Una transazione di scrittura MFT in $LogFile (modifica $STANDARD_INFORMATION dell'entry bersaglio).
  • Un BasicInfoChange | Close nel journal.

Se trovi una transazione di aggiornamento MFT in $LogFile senza un BasicInfoChange | Close corrispondente nel journal, l'operatore può aver eliminato il record del journal — possibile con fsutil usn deletejournal seguito da createjournal, che lascia tracce sue.

Altre mosse anti-forensi catturate dal journal

Disabilitare il journal

fsutil usn deletejournal /D /N C: rimuove il journal. Dopo la chiamata:

  • Il file journal viene ricostruito vuoto. I record precedenti se ne sono andati.
  • La entry MFT di $UsnJrnl viene riscritta da capo — $LogFile registra la transazione.
  • Security.evtx, se erano configurate SACL, registra un Sensitive Privilege Use per SeRestorePrivilege o SeManageVolumePrivilege.

Il journal non può dirti cosa conteneva, ma l'atto stesso di disabilitarlo è un segnale forte di anti-forense. Vedi la reference fsutil usn di Microsoft per i comandi di gestione e i loro prerequisiti di privilegio.

Flussi di dati alternativi

Nascondere via ADS è più vecchio di me, e il journal lo registra pulito: un bit di razionale StreamChange scatta quando un flusso alternativo viene aggiunto o rimosso. Filtrare StreamChange e farai emergere ogni evento di create/modify di ADS sul volume. Falsi positivi includono i flussi Zone.Identifier legittimi dei download del browser — anche loro producono StreamChange, accoppiati al FileCreate del file originale.

Trucchi con hard link

HardLinkChange scatta quando vengono aggiunti o rimossi hard link. Gli operatori a volte li usano per rendere un file accessibile via due padri — utile per eludere controlli basati sul path. Tracciare HardLinkChange e pivotare su FileReferenceNumber per vedere tutti i padri.

Abuso di reparse point

I reparse point (junction, link simbolici, mount point) possono reindirizzare un percorso altrove. ReparsePointChange si accende quando uno viene aggiunto o modificato. Cercare reparse point in $Recycle.Bin, \Users\Default o altre posizioni «non dovrebbero essere toccate».

Cosa non puoi catturare così

Una breve lista di mosse anti-forensi che bypassano del tutto il journal:

  • Avviare da supporto esterno e riscrivere il disco — non ha mai toccato l'OS attivo.
  • Riscritture userland che preservano la stessa dimensione del contenuto (overwrite allo stesso offset, niente aggiornamento SI). Producono record DataOverwrite ma perdono il contenuto originale. Il journal vede la scrittura, non cosa c'era prima.
  • Disabilitare il journal prima che l'operatore faccia qualunque altra cosa. Il journal può registrare solo ciò che è successo mentre era acceso.

Per questi, servono o $LogFile, o le shadow copy, o telemetria fuori host. Il journal è un testimone forte, non l'unico.

Una scansione pratica

Il filtro più rapido per timestomping su un journal parsato:

  1. Filtrare record con razionale esattamente BasicInfoChange | Close.
  2. Per ognuno, guardare i 5 minuti precedenti di record sullo stesso FileReferenceNumber. Se non c'è DataOverwrite, DataExtend, FileCreate o rename, segnalare.
  3. Per le entry segnalate, calcolare il delta SI-vs-FN nel MFT. Ordinare per delta più grande.

In cima alla lista c'è di solito il tuo timestomping. Le entry restanti sono operazioni come Esplora risorse che toggla «Nascosto» o script che toccano gli attributi — dipende dal contesto, ma raramente interessanti per un'indagine tipica.