Il ransomware fa più o meno la stessa cosa su ogni host, ogni volta: enumera i file, legge ciascuno, scrive una copia cifrata, elimina l'originale. Ogni passo atterra in $MFT. Se conosci che forma ha, puoi confermare che un incidente è un giro di ransomware entro pochi minuti dall'aver ricevuto la MFT, senza mai trovare il binario o leggere il messaggio di riscatto.
Questo è il pattern, le variazioni che ho visto e come separo il ransomware da altre forme di attività di file di massa che sembrano superficialmente simili.
I tre segnali
Cambi di estensione di massa. Compare un nuovo file con la stessa directory padre e nome base di un file esistente, ma con un'estensione diversa. report.docx diventa report.docx.locked, report.encrypted, report.crypted_{guid} o report.docx.[victim_id].lockbit. Contare quante coppie del genere appaiono in una breve finestra è uno degli indicatori più puliti di ransomware in $MFT. Centinaia in un minuto, sul profilo di un singolo utente o su una condivisione, è la firma.
Una raffica di timestamp SI created di $STANDARD_INFORMATION raggruppati in pochi secondi. L'attività utente normale crea file in scatti di uno o due. Il ransomware li crea a migliaia. Plotta i timestamp SI created come istogramma sulla finestra sospettata e il giro di cifratura emerge come uno spike verticale che annega la baseline. La larghezza dello spike ti dice quanto velocemente è girato il ransomware (varianti moderne multi-thread finiscono il profilo di un utente in meno di un minuto; quelle vecchie single-thread richiedono più tempo e lo spike si allarga).
Originali eliminati corrispondenti ai duplicati cifrati. Per ogni report.docx.locked c'è tipicamente un corrispondente report.docx il cui flag IN_USE è ora azzerato. Il record eliminato resta in $MFT finché lo slot non viene riusato. Puoi recuperare nome, dimensioni e timestamp dell'originale direttamente dallo slot eliminato. Accoppia questo con i motivi FILE_DELETE di $UsnJrnl nella stessa finestra e l'ordine delle operazioni diventa inequivocabile.
Variazioni da conoscere
Non ogni famiglia segue lo stesso pattern. Le variazioni che vedo:
- Cifratura sul posto. Alcune famiglie (vecchie varianti di Sodinokibi, certi build di Conti) aprono il file originale, riscrivono i byte cifrati nello stesso file e rinominano. Non esiste un file "copia cifrata" separato; il pattern dell'originale eliminato scompare.
DATA_OVERWRITEdi$UsnJrnlper migliaia di file in un minuto è comunque rumoroso, e il rinomino lascia una coppiaRENAME_OLD_NAME/RENAME_NEW_NAME. - Cifratura intermittente. BlackCat e diverse famiglie recenti cifrano solo pezzi del file (ad esempio un blocco da 100 KB ogni due) per velocizzare il giro. La dimensione del file cambia appena, l'orario di modifica si aggiorna, ma i cluster
$DATAsono per lo più intatti. Sembra più leggero in$MFTma il journal USN mostra comunque le scritture. - Solo rinomino. Una manciata di wiper "finto ransomware" rinomina i file senza cifrarli. Il pattern MFT è identico a un vero giro di ransomware; solo l'analisi del contenuto separa i due.
- Impatto su drive di rete. Molte famiglie enumerano drive mappati e cifrano attraverso la rete. La MFT locale mostra meno cambiamenti di quelli che ti aspetteresti per un incidente reale; la MFT del file server porta il grosso.
Note di riscatto
La maggior parte delle famiglie rilascia una nota di riscatto in ogni directory colpita, con un nome come HOW_TO_DECRYPT.txt, README_FOR_DECRYPT.html, restore-files.txt o una variante specifica del brand. Le note hanno contenuto identico, dimensione identica e orari di creazione raggruppati nella stessa finestra della cifratura. Percorrere la MFT cercando molti file di testo o HTML di dimensione identica sparsi in molte directory padre spesso li trova prima di qualsiasi pattern di nome.
Le note sono anche utili forensicamente come baseline. Il loro orario di creazione è essenzialmente il timbro "primo momento in cui il ransomware è stato attivo in questa directory". Se una directory ha una nota datata 02:14 ma file cifrati datati 02:09 nella stessa directory, il ransomware ha enumerato e cifrato prima di rilasciare la nota. Quello ti dice qualcosa sul flusso della famiglia.
Cosa $MFT non ti dice
La MFT conferma il cosa e il quando. Non ti dice quale processo ha fatto la scrittura, da dove è entrato l'operatore o come il ransomware è arrivato sull'host. Per quelli:
- Prefetch, Amcache e Shimcache per prove di quale eseguibile è girato nella finestra.
- Sysmon Event ID 1 per creazione di processo con command line, padre e hash.
- Security Event 4688 per creazione di processo se l'audit della command line era abilitato.
- Journal USN
$Jper l'ordine preciso delle operazioni di apertura/lettura/scrittura/rinomino/eliminazione di file. - Dump RAM se la macchina è ancora viva e il processo di cifratura è ancora residente. A volte ottieni la chiave di cifratura in memoria.
- Cronologia browser e artefatti email per il vettore di accesso iniziale.
La sola MFT risponde alle domande operative urgenti: quando è iniziato il giro, quanto è diffuso e quali file sono stati toccati. Basta a prendere la decisione di recupero. L'attribuzione è un esercizio separato che usa la MFT come uno degli input.
L'eliminazione di VSS come indizio
La maggior parte delle famiglie di ransomware cerca di eliminare le Volume Shadow Copies prima di iniziare a cifrare, perché gli snapshot VSS permetterebbero alla vittima di ripristinare senza pagare. Il comando usuale è vssadmin delete shadows /all /quiet. Questo lascia:
- Una voce nel log eventi di sistema di Windows (
Event ID 8224per messaggi del servizio VSS). - Un Sysmon Event ID 1 per l'invocazione di
vssadmin.exese Sysmon è distribuito. - Lo stato VSS fresco-ma-vuoto sull'host.
vssadmin list shadowsnon restituisce nulla o solo snapshot post-incidente.
Se vedi un host senza snapshot VSS e numeri di sequenza del record MFT \$Extend\$UsnJrnl che indicano una ricreazione recente, hai una preparazione al ransomware anche se il giro di cifratura non è ancora visibilmente iniziato. Vedi VSS e $MFT per cosa potresti ancora recuperare.
La sequenza di triage che seguo
- Tira
$MFTe$UsnJrnl:$Jdall'host sospetto (o dallo snapshot, se VSS ne ha ancora uno precedente). - Parsa la MFT con MFTECmd o
mft_dump. Ordina SI created in modo discendente. Guarda le prime 1.000 voci. - Se le voci in cima si raggruppano in una finestra di minuti e molte hanno estensioni insolite, hai un'impronta di ransomware.
- Tira i record eliminati corrispondenti. I loro attributi
$FILE_NAMEti danno i nomi originali dei file. Ora sai cosa è stato cifrato. - Incrocia con il journal USN.
FILE_CREATEper il file cifrato piùFILE_DELETEper l'originale allo stesso istante conferma il pattern. - Identifica la nota di riscatto: un piccolo file con un nome insolito (HOW_TO_DECRYPT, RECOVERY, README_RESTORE) che appare in molte directory contemporaneamente. Il suo contenuto nomina la famiglia.
- Pivota dal nome della famiglia a IOC noti: hash di file, domini C2, persistenza nel registro e artefatti noti della kill chain nei tuoi altri log.
Quella sequenza di solito richiede meno di trenta minuti su un singolo host e ti dà abbastanza per decidere il contenimento e iniziare la pianificazione del recupero.
Letture aggiuntive
- I casi studio di ransomware di The DFIR Report. Ogni writeup accoppia prove MFT e di journal con il resto della kill chain.
- Analisi tecniche di LockBit, BlackCat, Cl0p su The Record e Microsoft Security Blog. Le impronte MFT specifiche delle famiglie differiscono nel dettaglio.
- MITRE ATT&CK, T1486 Data Encrypted for Impact. Il catalogo delle tecniche per ciò che fa il ransomware e gli artefatti che ogni comportamento lascia.