Cancellazione Disco: Disk Wipe (T1561)

In un contesto di red team autorizzato, la simulazione di Disk Wipe richiede ambienti completamente isolati — macchine virtuali con snapshot, mai sistemi di produzione. L'obiettivo non è distruggere dati reali ma validare le capacità di detection e di ripristino dell'organizzazione.

Su Windows, l'accesso raw al disco si ottiene aprendo handle sui device fisici tramite la notazione \.\PhysicalDrive0. Uno script PowerShell può utilizzare CreateFile via P/Invoke per aprire il dispositivo e scrivere zeri sui primi 512 byte, distruggendo il MBR. Un esempio didattico è l'utility dd for Windows (open source), invocabile come dd if=/dev/zero of=\.\PhysicalDrive1 bs=512 count=1 su un disco secondario di laboratorio. Per emulare wiper reali senza scrivere codice originale, il progetto Atomic Red Team (open source) include test mappati su T1561 che simulano l'invocazione di comandi distruttivi senza eseguirli realmente.

Su Linux, gli strumenti nativi sono già sufficienti: dd if=/dev/urandom of=/dev/sdb bs=1M riempie il dispositivo di dati pseudocasuali, mentre shred -vfz -n 3 /dev/sdb (fornito da coreutils, open source) esegue passaggi multipli di sovrascrittura. Il comando wipe (open source) offre pattern conformi a standard come Gutmann. Per il MBR è sufficiente dd if=/dev/zero of=/dev/sda bs=446 count=1, che preserva la tabella partizioni ma azzera il bootloader.

Su macOS, diskutil eraseDisk e asr (Apple Software Restore) sono le API native. Un red teamer può simulare la catena eseguendo diskutil list per enumerare e poi diskutil eraseDisk JHFS+ Test /dev/disk2 su un volume esterno di test.

Su dispositivi di rete Cisco IOS, la sequenza classica è enable seguito da erase startup-config e reload. Per simulazioni sicure conviene lavorare su emulatori come GNS3 (open source) o Cisco Modeling Labs (a pagamento), mai su hardware in produzione.

La componente worm-like si simula separatamente combinando Impacket (open source) per il movimento laterale via SMB con payload innocui che si limitano a scrivere un file marker. Caldera (open source) di MITRE consente di orchestrare l'intera catena — accesso iniziale, escalation, propagazione, wipe simulato — producendo evidenze utili per la valutazione della detection.

La detection di Disk Wipe si fonda su segnali comportamentali che precedono e accompagnano la scrittura distruttiva. Il framework D3FEND suggerisce di concentrarsi su artefatti come Process, File e Block Device, correlando creazione di processo, caricamento di driver e I/O anomalo su dispositivi a blocchi.

Su Windows (piano di rilevamento AN0384) le sorgenti chiave sono WinEventLog:Security e WinEventLog:Sysmon. L'indicatore più netto è l'apertura di handle con la notazione \.\PhysicalDrive da parte di processi non appartenenti alla whitelist di tool di backup o imaging. Sysmon EventID 1 per la creazione processo, correlato con EventID 6 (driver load) quando l'attaccante carica driver firmati ma abusati per ottenere accesso raw — pattern noto come BYOVD (Bring Your Own Vulnerable Driver) — fornisce la coppia di segnali più significativa. Scritture su offset zero di dispositivi fisici, catturate da EventID 9 (RawAccessRead) o dalle nuove capacità di file system minifilter, completano il quadro.

Su Linux (AN0385) auditd con regole su syscall SYSCALL ed EXECVE intercetta esecuzioni di dd, shred, wipe con target /dev/sd*, /dev/nvme*, /dev/mapper*. Una regola auditd efficace è -a always,exit -F arch=b64 -S open -F path=/dev/sda -F perm=w -k disk_wipe. L'analisi di entropia sul traffico I/O aiuta a distinguere sovrascrittura casuale da workload legittimi, sebbene richieda tuning per ambienti di backup o crittografia.

Su macOS (AN0386) il unified log traccia invocazioni di diskutil e asr, oltre a chiamate IOKit di basso livello. Un predicato utile è process == "diskutil" AND eventMessage CONTAINS "eraseDisk".

Sui dispositivi di rete (AN0387) i log CLI e syslog devono essere inviati a un collector centralizzato con alert su pattern erase startup-config, erase flash:, format disk0: o write erase. La correlazione con eventi di privilege escalation (passaggio a enable mode) nei secondi precedenti riduce drasticamente i falsi positivi.

I falsi positivi più frequenti derivano da attività amministrative legittime: imaging con Clonezilla, provisioning di nuovi host, decommissioning pianificato. La mitigazione consiste in whitelist per utente e finestra temporale, oltre a change management che registri preventivamente ogni operazione distruttiva autorizzata. L'orchestrazione della detection dovrebbe correlare accesso disco, load di driver ed esecuzione processo in una finestra di pochi minuti per emergere solo su sequenze realmente anomale.

L'analisi forense post-wipe è per definizione una corsa contro l'entropia: quando l'attacco riesce completamente, i dati residenti sono persi. Il valore dell'investigazione risiede quindi nella ricostruzione della catena esecutiva a partire da fonti esterne al disco compromesso e da artefatti sopravvissuti in memoria o su sistemi periferici.

Su Windows, se il sistema è stato acquisito prima del reboot forzato, la memoria RAM è la fonte primaria. Volatility 3 (open source) con plugin come windows.pslist, windows.cmdline e windows.filescan permette di recuperare il processo wiper, gli argomenti di lancio e i file mappati. Gli eventi Sysmon conservati su collector remoto — EventID 1, 6, 7, 9 — costituiscono la timeline autoritativa. Utili anche i log Security 4688 (process creation) e 7045 (service install) inviati a SIEM. Se il disco è stato solo parzialmente sovrascritto, Autopsy (open source) o X-Ways Forensics (a pagamento) possono recuperare frammenti da settori intatti, con particolare attenzione alle aree oltre lo spazio partizionato. Le Shadow Copies, se non esplicitamente cancellate con vssadmin delete shadows, offrono snapshot precedenti.

Su Linux gli artefatti chiave sono /var/log/audit/audit.log, /var/log/syslog e la history di shell (.bash_history, journal di systemd). Un timestamp di esecuzione di dd o shred correlato all'utente e al target device fornisce l'evidenza diretta. Se il rootfs è stato distrutto ma esisteva un'installazione di auditd con forwarding remoto, la ricostruzione è possibile. The Sleuth Kit (open source) con fls e icat estrae metadati residui da immagini raw.

Su macOS il unified log può essere estratto da un backup Time Machine o da un endpoint MDM che ne raccoglie porzioni. Il comando log show --predicate consente ricerche mirate su operazioni disco.

Sui dispositivi di rete, la forensica dipende quasi esclusivamente da syslog inviati a un server esterno. La sequenza tipica mostra login, elevazione a enable, comando erase e successivo reload. Configuration snapshot conservati su TFTP server o su piattaforme come RANCID (open source) permettono di ricostruire lo stato pre-attacco.

Gli elementi di timeline essenziali sono: primo accesso interattivo, caricamento driver o installazione servizio, apertura handle su dispositivo raw, prima scrittura distruttiva, propagazione laterale via SMB o SSH, tentativi di cancellazione backup (vssadmin, wbadmin delete catalog). La correlazione con i log del sistema di backup — se isolato correttamente secondo la mitigazione M1053 — è spesso l'unica fonte per stabilire il perimetro effettivo dell'incidente.

I dati MITRE ATT&CK forniti per questa tecnica non includono gruppi APT, software o campagne specificamente mappati, il che riflette una scelta strutturale del framework: le attribuzioni di operazioni wiper sono generalmente mappate alle sottotecniche T1561.001 (Disk Content Wipe) e T1561.002 (Disk Structure Wipe), oltre a T1485 (Data Destruction), piuttosto che al nodo padre T1561.

Dal punto di vista dell'analisi strategica, questo suggerisce all'analista di threat intelligence di consultare le sottotecniche per ottenere il quadro completo degli attori documentati. L'assenza di gruppi al livello padre non significa assenza di minaccia: al contrario, Disk Wipe è storicamente una delle tecniche più associate a operazioni state-sponsored e a campagne di sabotaggio con motivazioni geopolitiche.

Il pattern operativo ricorrente in questa categoria di tecniche si articola su tre elementi che l'intelligence officer deve monitorare. Il primo è la preparazione infrastrutturale: gli attori che dispiegano wiper investono in accesso persistente e in dumping credenziali prima dell'attivazione del payload, spesso con settimane o mesi di ricognizione. Il secondo è la finestra di attivazione: i wiper vengono tipicamente attivati in coincidenza con eventi esterni — scadenze politiche, festività, momenti di massima dipendenza operativa del bersaglio — per massimizzare l'impatto reputazionale ed economico. Il terzo è la combinazione con distrazione: molte operazioni wiper mascherano un obiettivo primario diverso, come esfiltrazione o cover-up di intrusioni pregresse, rendendo la componente distruttiva una tattica di negazione forense.

Per la produzione di intelligence actionable, l'officer dovrebbe correlare Disk Wipe con le tecniche abilitanti presenti nel framework: T1078 (Valid Accounts), T1003 (OS Credential Dumping), T1021.002 (SMB/Windows Admin Shares) e T1490 (Inhibit System Recovery). La presenza di queste tecniche in un incidente aumenta la probabilità che una fase wiper sia pianificata o già eseguita.

Un ulteriore vettore da monitorare è l'abuso di driver firmati vulnerabili per ottenere accesso raw al disco bypassando controlli kernel-mode. Il progetto LOLDrivers (open source) mantiene un catalogo di driver noti per essere abusati in questo contesto, utile per arricchire indicatori e regole di detection.

Sul piano dei trend, l'evoluzione osservabile nell'ecosistema delle minacce indica una crescita di wiper mascherati da ransomware — payload che simulano cifratura ma non conservano chiavi decrittabili — e di attacchi ibridi che colpiscono contemporaneamente endpoint e infrastruttura di rete tramite comandi CLI distruttivi. La mitigazione M1053 (Data Backup) con backup immutabili e isolati resta l'unica difesa realmente efficace contro l'esito finale della tecnica.

MITRE ATT&CK T1561 (Disk Wipe), tattica TA0040 (Impact), mitigazione M1053 (Data Backup). Strategia di detection DET0137 con analytics AN0384 (Windows), AN0385 (Linux), AN0386 (macOS), AN0387 (Network Devices). Framework MITRE D3FEND per artefatti difensivi correlati. Per approfondire gli attori specifici si raccomanda la consultazione delle sottotecniche T1561.001 e T1561.002. La sezione operativa integra conoscenza professionale su tool open source (Volatility, Autopsy, Sleuth Kit, Atomic Red Team, Caldera, LOLDrivers, RANCID, GNS3, Impacket) verificati come attivi e mantenuti.