Rilevare attività ransomware nel USN journal

Il ransomware è uno dei segnali più puliti che leggerai mai nel USN journal. Qualunque cosa l'operatore abbia fatto a monte — furto di credenziali, movimento laterale, impianti di persistenza, cancellazione di shadow copy — la fase di cifratura tocca il filesystem con un pattern uniforme, ad alto volume, monotonamente crescente che si stacca dal rumore circostante anche mesi dopo. Ogni operatore a cui io abbia mai risposto ha provato a camuffare una parte della kill chain. Nessuno ha ancora capito come camuffare il cifrare decine di migliaia di file in cinque minuti.

Questo post è il playbook per trovare quel pattern. Il setup assume che tu abbia già tirato $J e l'abbia parsato, e che la bitmask Reason non sia più un mistero.

Il pattern canonico della fase di cifratura

La maggior parte dei ransomware moderni (LockBit 3.0, BlackCat/ALPHV, Royal, Akira, i vari spin-off post-Conti, Play, Black Basta) segue la stessa ricetta in tre passi per file:

1. Aprire il file in lettura.
2. Sovrascrivere il contenuto in loco, o scrivere un nuovo file accanto e cancellare l'originale.
3. Rinominare per aggiungere un'estensione marcatore (.locked, .lockbit, una stringa casuale da 8 a 16 caratteri, o in alcune famiglie nessuna).

Nel journal questo produce, per file:

DataOverwrite | Close
DataOverwrite | Close
...           ← uno per blocco di scrittura
RenameOldName | Close   (vecchio: document.docx)
RenameNewName | Close   (nuovo: document.docx.locked)

Su migliaia di file in pochi minuti. I due segnali diagnostici sono:

Raffiche di DataOverwrite in una finestra breve. L'attività Windows normale raramente produce DataOverwrite sostenuto su file che non siano database. Il save di Office, la compattazione della cache del browser e i rebuild di IDE producono picchi transitori; il ransomware produce un pavimento monotono che non molla finché l'host non rimane senza file da cifrare o l'operatore ferma il binario.

Eventi massivi RenameNewName con un suffisso nuovo-nome strettamente clusterizzato. Il rapporto di RenameNewName sul totale dei file attivi esplode durante la cifratura. La firma del cluster — stessa stringa fissa, o stesso pattern casuale .{8}, sull'80%+ delle rinomine nella finestra — è ciò che separa il ransomware da qualsiasi carico di lavoro legittimo.

Questo corrisponde principalmente a T1486 Data Encrypted for Impact in MITRE ATT&CK, con prove journal adiacenti che coprono T1490 (Inhibit System Recovery) e T1485 (Data Destruction).

Una ricetta di rilevamento che regge in tribunale

Lavorando attraverso un journal parsato:

1. Istogramma DataOverwrite al minuto. Raggruppa per minuto e cerca lo strapiombo. Un host Windows baseline gira a singole cifre di DataOverwrite al minuto. La cifratura sale a 50-500x e resta lì. Tracciala o pivotala in un foglio di calcolo — la forma te lo dice istantaneamente.
2. Clusterizza gli eventi RenameNewName per nuova estensione. Raggruppa sull'estensione del nuovo nome o su una regex sul nuovo nome. Se l'80%+ delle rinomine in una finestra condivide un suffisso identico o corrisponde allo stesso pattern casuale a lunghezza fissa, quello è un encryptor.
3. Abbina FileDelete | Close con FileCreate di stesso-stem-estensione-diversa. Alcune famiglie (le varianti più vecchie di LockBit tra esse) scrivono il cifrato in un nuovo file e cancellano l'originale. Cerca un FileCreate il cui stem corrisponda a un file recentemente cancellato, entrambi nello stesso secondo da orologio. Stesso FileReferenceNumber sul create di una rinomina recente è conclusivo.
4. Risali le directory padre via $MFT. Risolvi il riferimento padre per i file affetti. Il ransomware spazza i profili utente, i drive di rete mappati e Users\Public\. Un ambito limitato a una singola sottodirectory è molto più probabile che sia autosave di Office o uno strumento di backup andato storto.

Il parser su questa pagina espone il filtro per-reason direttamente. Mettilo su DataOverwrite per il passo 1 e RenameNewName per il passo 2. I passi 3 e 4 vogliono un export CSV e una pivot table.

Come appare su dati reali

Un estratto redatto da un caso LockBit 3.0 su cui ho lavorato:

2024-04-12T03:14:08Z  DataOverwrite Close   C:\Users\ana\Desktop\notes.docx
2024-04-12T03:14:08Z  DataOverwrite Close   C:\Users\ana\Desktop\notes.docx
2024-04-12T03:14:08Z  DataOverwrite Close   C:\Users\ana\Desktop\notes.docx
2024-04-12T03:14:08Z  RenameOldName Close   C:\Users\ana\Desktop\notes.docx
2024-04-12T03:14:08Z  RenameNewName Close   C:\Users\ana\Desktop\notes.docx.HLJkNskOq
2024-04-12T03:14:08Z  DataOverwrite Close   C:\Users\ana\Desktop\quarterly.xlsx
...

Ogni file nella directory cifrato all'interno dello stesso secondo da orologio. La nuova estensione è una stringa casuale uniforme di nove caratteri — un segnale forte di cluster per il passo 2 e il marker che LockBit 3.0 usa per legare il cifrato al keystream specifico dell'operatore.

Oltre la fase di cifratura

Il journal cattura anche comportamenti preparatori e di pulizia attorno alla raffica.

La cancellazione di shadow copy non è visibile direttamente in $J — lo stato VSS vive in namespace gestiti da $WSC — ma le invocazioni lanciate dall'operatore di vssadmin.exe, wmic.exe shadowcopy delete, wbadmin.exe delete catalog e bcdedit.exe /set toccano tutte file temp in \Windows\Temp\ o \Users\<u>\AppData\Local\Temp\. Questi record FileCreate appaiono pochi momenti prima della raffica di cifratura. Abbina con Sysmon evento 1 per l'albero processi reale.

Scansioni di discovery sono in gran parte invisibili al journal — le enumerazioni di directory in sola lettura non producono nulla. Ma i drop di strumenti sì. adfind.exe, PsExec.exe, l'output SharpHound di BloodHound e tooling simile producono eventi FileCreate nelle loro directory di lavoro, di solito in \ProgramData\, \Users\Public\ o \Users\<u>\AppData\Local\Temp\.

Consegna della nota di riscatto. Ogni famiglia moderna lascia una nota in ogni directory cifrata. README.txt, HOW_TO_DECRYPT.html, restore-my-files.txt, nomi specifici della famiglia. Un FileCreate dello stesso filename su molte directory padre nello stesso minuto è la regex pigra che cattura la stragrande maggioranza.

Staging pre-cifratura. Alcuni operatori mettono in staging l'esfiltrazione prima di cifrare — vedi il post sul rilevamento di esfil. Cerca eventi FileCreate di archivio con estensioni .zip, .7z, .rar nell'ora prima della raffica di cifratura.

Cosa il journal non ti dirà

Il journal registra cambiamenti, non attori. Per attaccare un utente o un processo alla raffica di cifratura:

• Evento 4663 (object access) di Security.evtx — richiede SACL configurate in anticipo, che quasi mai lo sono.
• Eventi 11 (file create) e 1 (process create) di Microsoft-Windows-Sysmon%4Operational.evtx — lo standard d'oro se Sysmon era distribuito.
• Prefetch e AmCache per il binario ransomware stesso, anche dopo che l'operatore lo cancella.

Per il playbook di risposta più ampio, la guida #StopRansomware di CISA è il riferimento autoritativo.

Distinguere il ransomware dalle raffiche legittime

Alcuni carichi di lavoro reali possono superficialmente assomigliare al ransomware con il filtro sbagliato:

La conversione iniziale BitLocker produce DataOverwrite continuo ma nessun RenameNewName. Il ransomware rinomina sempre. Se il tuo conteggio RenameNewName è piatto, non è ransomware.

Il software di backup (Veeam, Macrium, Acronis) produce DataOverwrite sul volume di destinazione, non sui Documents e Desktop dell'utente. Incrocia utente e percorso.

L'autosave Office e i rebuild Visual Studio picchiano per pochi secondi e si fermano. Il ransomware è monotono. L'istogramma al minuto lo rende ovvio.

Il ripristino di immagine disco scrive grandi quantità di dati ma a un percorso di dispositivo \\?\Volume{...}, non a un profilo utente. La risoluzione di directory padre lo cattura.

Se la tua logica di rilevamento produce zero alert su una baseline sana, è sotto-specificata. Il segnale che vuoi è la combinazione di tasso DataOverwrite, tasso RenameNewName e clustering di stessa estensione — non uno solo di essi.

Letture aggiuntive

• CISA, guida #StopRansomware — il playbook di risposta end-to-end autoritativo.
• Il walkthrough LockBit 3.0 di The DFIR Report e writeup di intrusione long-form simili — la migliore fonte pubblica per la cadenza da orologio da parete di un ingaggio ransomware reale.
• Microsoft Defender Research, Ransomware-as-a-service — utile come contesto lato operatore per ciò che la tua prova journal rappresenta davvero.