Rilevare l'esfiltrazione di dati e la copia su USB con il USN journal

Dopo il ransomware, la seconda domanda DFIR più comune è una variante di "qualcosa è uscito da qui?". Il USN journal è uno dei posti più economici per iniziare a rispondere. Ogni copia USB, ogni upload cloud-sync e ogni operazione di drop-everything-in-a-temp-folder-then-zip lascia una forma riconoscibile in $J — abbastanza riconoscibile che con due filtri e un pivot di percorso padre puoi di solito triagiare una finestra candidata di esfil in meno di venti minuti.

Questo post è il playbook per trovare quei pattern, suddiviso per canale di esfil.

Le unità USB lasciano la traccia più pulita

Quando un utente collega un volume rimovibile, Windows gli assegna una lettera di unità e, se il volume è NTFS, il dispositivo riceve il proprio $UsnJrnl. I file copiati verso l'USB atterrano nel journal di destinazione come FileCreate | Close più un flusso di record DataExtend | Close. I file copiati dal disco sorgente lasciano una traccia più morbida sul lato sorgente: eventi open e close che spesso producono BasicInfoChange | Close dallo scan AV e dal caching filesystem che seguono la lettura.

Cosa tipicamente hai in un engagement reale:

• Il journal del disco sorgente. Mostra cosa è stato aperto, qualsiasi file temp o archivio creato, e lo sweep finale di cancellazione se l'utente ha pulito.
• Le hive del registro. SYSTEM\MountedDevices, SYSTEM\CurrentControlSet\Enum\USBSTOR, NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 e setupapi.dev.log insieme identificano quale dispositivo fisico è stato collegato e quando. Parsali con il parser del registro.
• Il journal del volume di destinazione, se hai l'immagine USB. È qui che vivono le scritture file reali.

Il segnale decisivo sul lato sorgente è il pattern archive-before-copy, perché la maggior parte degli utenti con qualcosa da nascondere si rivolge a 7-Zip o alla compressione integrata di Explorer prima di portare via l'unità: un FileCreate di un .7z, .zip, .rar o file con nome casuale a un percorso temp, seguito da record sostenuti DataExtend | Close finché il file non raggiunge la dimensione finale. Il percorso è di solito \Users\<u>\AppData\Local\Temp\, \Users\<u>\Desktop\ o la radice del profilo utente.

Per il lato identificazione USB, incrocia i timestamp nel journal contro gli eventi Microsoft-Windows-DriverFrameworks-UserMode%4Operational.evtx per connessione/disconnessione — il parser EVTX lo rende un lavoro da pochi clic. Abbina con file LNK sotto \Users\<u>\AppData\Roaming\Microsoft\Windows\Recent\ e jump list per prove esplicite di utente-ha-aperto-da-USB.

Il pattern classico di staging-poi-archivio

Mappa su T1074 Data Staged in MITRE ATT&CK e appare così su disco:

FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\report.xlsx
DataExtend | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\report.xlsx
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\customers.csv
DataExtend | Close   ...
...
FileCreate | Close   C:\Users\bob\AppData\Local\Temp\sales_q3.zip
DataExtend | Close   ...           ← molti di questi, il file cresce
FileDelete | Close   C:\Users\bob\AppData\Local\Temp\sales_q3\*  (pulizia)

Tre segnali in sequenza:

1. Una raffica di FileCreate in una singola directory di staging.
2. Un successivo FileCreate più DataExtend rotolante su un singolo archivio, la cui dimensione finale approssima la somma dei file in staging.
3. Uno sweep di cancellazione della directory di staging poco dopo che l'archivio viene chiuso.

Ogni segnale da solo è rumoroso. Combinati sono diagnostici. Filtra per FileCreate in \AppData\Local\Temp\, \Users\Public\, \Downloads\ e altri percorsi scrivibili dell'albero utente, poi clusterizza per directory padre e cerca >50 create in 60 secondi. Quella cadenza cattura lo staging di furto da insider e la maggior parte dei carichi di infostealer. Togli percorsi di build noti (node_modules\, target\, Debug\, Release\, obj\, .next\, dist\) dal filtro; producono raffiche di forma identica e domineranno i tuoi risultati altrimenti.

Staging di cloud-sync

OneDrive, Dropbox, Google Drive e Box mantengono tutti una cartella di sync locale e spingono tutto dentro nel momento in cui l'agente lo raccoglie. Il journal espone due pattern diagnostici:

RenameNewName di massa nella cartella di sync. Il padre nuovo è \Users\<u>\OneDrive\, \Users\<u>\Dropbox\, \Users\<u>\Google Drive\ o \Users\<u>\Box\; il padre vecchio è Desktop\, Documents\ o Downloads\. La metà rename preserva il riferimento padre originale del file, il che significa che puoi provare la provenienza anche dopo che il file è sparito.

DataExtend | Close su file dentro la cartella di sync senza un corrispondente FileCreate di app utente. Queste sono le scritture dell'agente stesso — download dal lato cloud alla copia locale. I create sono ciò che vuoi per la direzione upload. Gli agenti di sync in background come OneDrive.exe e Dropbox.exe scrivono anche file di log nei loro sottodirectory AppData\Local\, il che ti dà un altro modo per delimitare l'attività se la prova di rename è scarsa.

Meno comune ma vale la pena saperlo: alcuni operatori scriptano un Copy-Item in una junction o symlink che punta alla cartella cloud, il che produce record ReparsePointChange oltre alla coppia rename.

BITS, strumenti di upload nativi e esfil living-off-the-land

Un pattern che ho visto più spesso in engagement ransomware recenti: l'operatore usa bitsadmin.exe o Start-BitsTransfer di PowerShell per spingere fuori file, a volte verso storage cloud controllato dall'attaccante con certificati validi. Il journal mostra:

• FileCreate di file di stato di job BITS sotto \ProgramData\Microsoft\Network\Downloader\ (corrispondenti a qmgr.db, qmgr0.dat, qmgr1.dat).
• Per gli upload, i file sorgente messi in staging in \Users\<u>\AppData\Local\Microsoft\BITS\ immediatamente prima del trasferimento.

Abbina con gli ID evento di Microsoft-Windows-Bits-Client%4Operational.evtx 59 (job creato), 60 (job trasferito) e 61 (job completo) — il ponte EVTX per esfil BITS è una delle correlazioni più pulite disponibili.

Storia simile per rclone.exe e MEGAsync.exe. Producono firme prevedibili di file-create nelle loro directory app e file di log; controlla \Users\<u>\AppData\Roaming\rclone\ per la configurazione che elenca la destinazione.

Euristiche che si guadagnano il posto

Dopo abbastanza engagement, le euristiche che segnalano costantemente esfil reale:

Raffica di create. Più di N eventi FileCreate in una singola directory in T secondi. Sintonizza sulla baseline; N=50, T=60 è il punto di partenza per host desktop.

Archivio dopo raffica. Un singolo FileCreate di un file con estensione .zip, .7z, .rar, .tar.gz, .tar.zst o .iso entro minuti da una raffica di create, con DataExtend rotolante che si accumula a diversi MB. La dimensione dell'archivio corrisponde approssimativamente alla dimensione cumulativa dei file in staging.

Rinomina di massa attraverso confini di directory. Record RenameNewName il cui percorso del padre nuovo è strutturalmente diverso dal vecchio — Documents\ a OneDrive\, Desktop\ a Users\Public\, Downloads\ a \AppData\Local\Microsoft\BITS\. Facile da esprimere come regex sui percorsi completi risolti dalla MFT.

Raffiche fuori orario. Una qualsiasi delle precedenti fuori dall'orario lavorativo normale dell'utente. Incrocia con logon 4624 di Security.evtx per i confini reali di sessione.

Sweep di cancellazione dopo archivio. Un cluster FileDelete sulla directory di staging dopo che l'archivio è chiuso. Questo è l'utente che cerca di pulire. La forma del cluster — molti file cancellati in secondi, tutti condividendo un padre — è insolita fuori dai workflow dev/build.

Il parser di questa pagina espone filtri per finestra temporale e per-ragione che rendono la rilevazione di raffiche e il clustering di rename un clic ciascuno. Per analisi fuori orario, esporta in CSV e pivota su ora-del-giorno.

Cosa non vedrai in $UsnJrnl

Alcune tecniche reali di esfiltrazione non producono segnale USN utile:

• Upload diretto dalla memoria via un POST del browser, Invoke-WebRequest -InFile da una variabile, o curl che pipa da Get-Content. Niente atterra su disco.
• Lettura da una condivisione di rete che il lato sorgente non possiede. Il journal sul tuo host non ha nulla perché il file non viveva lì.
• Cattura schermo come esfil. Solo i file di screenshot atterrano su disco; i dati effettivi escono via l'immagine renderizzata.
• Stampa. Lascia solo attività \Windows\System32\spool\PRINTERS\, che è un proprio artefatto forense.
• Tunneling DNS o ICMP. Niente tocca il disco; pivota a catture di rete ed evento 3 Sysmon.

Per queste, pivota a EVTX, connessioni di rete Sysmon (evento 3), storia del browser, SRUM per byte di rete per processo, dump RAM o artefatti PRINTERS spool. La pagina tattica Exfiltration di MITRE ATT&CK elenca ogni tecnica con note su dove lascia davvero residui.

Un esempio lavorato

Il tipo di CSV che potresti esportare da un engagement reale per dimostrare l'esfil:

Quella timeline è una pistola fumante. Senza il journal la ricostruiresti dal registro, Prefetch, shadow copy e i log propri di OneDrive — cinque volte il lavoro, metà della fiducia.

Letture aggiuntive

• MITRE ATT&CK — la tattica Exfiltration e T1074 Data Staged per la tassonomia completa.
• CISA, risorse insider threat — le assunzioni base e le soglie di rilevamento nel loro playbook sono vicine a ciò che regge in un ambiente corporate reale.
• The DFIR Report — molteplici intrusioni long-form documentano il pattern esfil-poi-cifra passo dopo passo, con prove USN nella timeline. La cosa più vicina a un corpus pubblico di ground-truth per come questi pattern appaiono in pratica.