Inibizione del Ripristino di Sistema: Inhibit System Recovery (T1490)

In un esercizio red team la simulazione di T1490 serve a verificare se il SOC rileva la cancellazione dei meccanismi di ripristino prima che il ransomware completi la cifratura. L'obiettivo non è distruggere, ma generare telemetria e validare le detection rule. Lavora sempre in ambiente lab isolato, con snapshot di ripristino pronti prima dell'esecuzione.

La catena di comandi classica su Windows segue una sequenza prevedibile. Si parte dalle shadow copy, si prosegue con il catalogo backup e si chiude disabilitando il recovery automatico. In un terminale con privilegi elevati:

vssadmin.exe delete shadows /all /quiet

Questo comando elimina tutte le Volume Shadow Copy senza richiedere conferma. Lo stesso risultato si ottiene via WMI con:

wmic shadowcopy delete

Per il catalogo di Windows Backup:

wbadmin.exe delete catalog -quiet

La disabilitazione del ripristino automatico all'avvio richiede la modifica del BCD (Boot Configuration Data):

bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures bcdedit.exe /set {default} recoveryenabled no

Un passaggio meno noto ma altrettanto efficace è la disabilitazione di Windows Recovery Environment tramite REAgentC.exe /disable. Per testare il vettore diskshadow.exe, si può usare uno script inline:

diskshadow delete shadows all

Su ambienti ESXi, la simulazione si sposta sulla rimozione degli snapshot VM. Il comando da ESXi shell è:

vim-cmd vmsvc/snapshot.removeall

dove <vmid> è l'identificativo della macchina virtuale target. In laboratorio, crea uno snapshot di test e verifica che il comando lo elimini correttamente.

Per ambienti Linux, la simulazione può includere la rimozione di configurazioni di recovery come la cancellazione di backup della partizione di boot o la modifica dei target di systemd. Usa auditd per verificare che l'attività venga registrata — configura regole di audit su path critici come /boot/efi e /etc/fstab.

In ambienti cloud AWS, simula la cancellazione di snapshot EBS tramite AWS CLI:

aws ec2 delete-snapshot --snapshot-id

Tool come Atomic Red Team (open source) includono test atomici specifici per T1490 che eseguono queste operazioni in modo controllato e reversibile. Il test T1490 nella libreria Atomic esegue la sequenza completa vssadmin/wbadmin/bcdedit e genera la telemetria necessaria per validare le regole SIEM.

Dopo ogni test, verifica che il SIEM abbia generato alert, documenta il tempo di detection e ripristina l'ambiente dallo snapshot pre-test.

La detection di T1490 ha un vantaggio raro nella cybersecurity: i comandi utilizzati dagli attaccanti sono estremamente specifici e raramente eseguiti in contesti operativi legittimi. Un server di produzione non dovrebbe mai cancellare le proprie shadow copy se non durante finestre di manutenzione pianificate. Questo rende il rapporto segnale-rumore favorevole, a patto di configurare le sorgenti corrette.

Le log source primarie su Windows sono tre: Sysmon (EventID 1 per process creation con command line completa), il canale Microsoft-Windows-Backup per eventi legati a wbadmin, e il canale System dove compaiono gli eventi del servizio VSS. Sysmon è imprescindibile: senza la command line catturata in EventID 1, non è possibile distinguere un'invocazione legittima di vssadmin da una malevola.

La regola di detection comportamentale primaria (AN0933) si basa sul monitoraggio delle catene di processo che coinvolgono vssadmin, wbadmin, diskshadow, bcdedit, REAgentC e wmic con argomenti distruttivi. Il pattern chiave è la combinazione di utility + flag specifici: delete shadows, delete catalog, recoveryenabled no, shadowcopy delete. Il tuning è fondamentale: imposta una finestra temporale di 5-10 minuti per correlare più comandi di recovery-killing eseguiti in rapida successione, perché il ransomware li lancia tipicamente tutti insieme. Filtra per contesto del parent process — una catena powershell.exe → vssadmin.exe è molto più sospetta di services.exe → vssadmin.exe durante un backup schedulato.

Su Linux (AN0934), la detection si appoggia su auditd con regole SYSCALL e CONFIG_CHANGE. Monitora la cancellazione di file in /etc/systemd/system/rescue.target, modifiche a /etc/fstab e operazioni su /boot/efi. Limita il rilevamento ad attività eseguite da utenti root o via sudo per ridurre i falsi positivi.

Per ESXi (AN0935), il log hostd è la sorgente critica. Monitora invocazioni di vim-cmd vmsvc/snapshot.removeall e comandi rm su path di snapshot. Filtra sulle VM critiche per contenere il volume di alert.

In ambienti cloud IaaS (AN0937), configura alert su AWS CloudTrail per chiamate API come DeleteSnapshot, DeleteVolume, DisableBackup e disabilitazione del versioning su bucket S3, specialmente quando provengono da user agent non riconosciuti o da account con privilegi appena escalati.

Per i dispositivi di rete (AN0936), la sequenza erase → format → reload in una sessione AAA privilegiata è il segnale d'allarme. Correla i comandi in una finestra temporale stretta e filtra per livello di privilegio dell'utente.

I falsi positivi principali derivano da operazioni di manutenzione IT legittime: team di backup che ridimensionano le shadow copy, amministratori che riconfigurano il BCD dopo aggiornamenti. La soluzione è una whitelist basata su account di servizio e finestre di manutenzione programmate.

L'analisi forense di T1490 è spesso il punto di partenza per ricostruire la timeline di un attacco ransomware, perché la cancellazione dei meccanismi di recovery precede quasi sempre la cifratura. Individuare il timestamp esatto di questi eventi permette di delimitare la finestra in cui l'attaccante aveva già il controllo ma non aveva ancora eseguito il payload finale.

Su sistemi Windows, gli artefatti principali sono molteplici e complementari. I log Sysmon con EventID 1 (Process Create) catturano la command line completa di vssadmin, wbadmin, bcdedit e le altre utility abusate. Il canale Microsoft-Windows-VSSVC registra l'arresto e l'avvio del servizio Volume Shadow Copy — l'EventID 7036 nel System log indica il cambio di stato del servizio VSS. Se il servizio viene disabilitato (come fa HermeticWiper tramite il Service Control Manager), troverai evidenza anche nel registro di sistema alla chiave HKLM\SYSTEM\CurrentControlSet\Services\VSS.

Il BCD store modificato da bcdedit lascia traccia nel file \Boot\BCD. Un confronto tra il BCD attuale e un baseline noto rivela le modifiche a bootstatuspolicy e recoveryenabled. Usa il comando bcdedit /enum all su un sistema di analisi per estrarre la configurazione corrente.

I Prefetch file (C:\Windows\Prefetch) di vssadmin.exe, wbadmin.exe, bcdedit.exe e diskshadow.exe forniscono timestamp di esecuzione, numero di run count e path dei file referenziati. Su sistemi con Prefetch abilitato (tipicamente workstation, non server), il file VSSADMIN.EXE-*.pf indica quante volte e quando il tool è stato eseguito. Tool come PECmd di Eric Zimmerman (open source) permettono di parsare i file Prefetch in modo strutturato.

La Master File Table (MFT) e il journal $UsnJrnl mostrano la cancellazione dei file di snapshot VSS e dei cataloghi di backup. Analizzando il journal con tool come MFTECmd (open source), è possibile ricostruire la sequenza precisa di cancellazioni.

Per la ricostruzione della timeline, l'ordine tipico osservato in campagne reali prevede: disabilitazione del servizio VSS → cancellazione shadow copy → eliminazione catalogo backup → modifica BCD → esecuzione del ransomware. Se trovi i comandi bcdedit prima della cancellazione VSS, potrebbe indicare un operatore manuale piuttosto che un ransomware automatizzato.

Su ESXi, esamina i log hostd.log e shell.log nella directory /var/log/. Le invocazioni di vim-cmd e i comandi shell diretti con rm su file .vmdk snapshot sono gli artefatti primari.

Su Linux, verifica i log auditd per chiamate di sistema legate alla cancellazione di file critici. Il file /var/log/audit/audit.log con regole di watch su path sensibili registra unlink e rename sui file di configurazione di recovery.

In ambienti cloud, i log di CloudTrail (AWS) o Activity Log (Azure) registrano ogni chiamata API di cancellazione. Storm-0501 per esempio targettizza operazioni specifiche come Microsoft.Compute/snapshots/delete e Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/delete — cerca queste stringhe nei log di attività Azure.

L'inibizione del ripristino è una tecnica quasi universale nel panorama ransomware, ma i gruppi che la implementano mostrano pattern operativi distinti che permettono attribuzione e previsione.

Wizard Spider è uno dei gruppi più consolidati nell'uso di T1490. Impiega sia WMIC sia vssadmin per la cancellazione manuale delle shadow copy durante operazioni hands-on-keyboard, ma ha anche integrato la funzionalità direttamente nel ransomware Conti, che elimina le shadow copy automaticamente. Questa duplice modalità — manuale e automatizzata — suggerisce un gruppo maturo con operatori di diverso livello di competenza. L'ecosistema Wizard Spider include anche Ryuk, che non si limita a cancellare le shadow copy ma usa vssadmin resize shadowstorage per forzare l'eliminazione anche di quelle create da applicazioni di terze parti, un accorgimento tattico che rivela attenzione per i software di backup enterprise.

Sandworm Team utilizza T1490 in un contesto diverso: non estorsione, ma distruzione. Attraverso il malware Prestige, esegue la sequenza completa wbadmin (catalogo) + vssadmin (shadow copy) usando i path completi dei binari di sistema (C:\Windows\System32\). Questo pattern di specificazione del path assoluto è un indicatore utile per distinguere l'automazione di Sandworm da operatori manuali che tipicamente si affidano alla variabile PATH.

Storm-0501 rappresenta l'evoluzione cloud-native di questa tecnica. Oltre alle classiche operazioni on-premise, questo gruppo colpisce direttamente le risorse Azure: snapshot compute, restore point collection, storage account e vault di Recovery Services. La lista specifica delle API targettizzate — Microsoft.Compute/snapshots/delete, Microsoft.Storage/storageAccounts/delete e le relative operazioni sui vault — fornisce indicatori precisi per policy di detection cloud.

Scattered Spider adotta un approccio minimalista: anziché cancellare le shadow copy, ferma direttamente il servizio Volume Shadow Copy sugli host compromessi. È un metodo più silenzioso che potrebbe eludere detection basate esclusivamente sul monitoraggio dei comandi vssadmin.

BlackByte aggiunge una variante tecnica interessante: ridimensiona i file delle shadow copy prima di cancellarli, una tattica che garantisce la distruzione anche in caso di interruzione parziale del processo di cancellazione.

Medusa Group segue il pattern classico con cancellazione delle shadow copy tramite vssadmin.exe, operando attraverso il ransomware Medusa Ransomware.

Il dato aggregato dei 48 software che implementano T1490 mostra una convergenza quasi totale su vssadmin.exe come strumento primario, seguita da wmic e bcdedit. Famiglie come WannaCry e Olympic Destroyer combinano tutte le utility native in sequenza, mentre ransomware più recenti come Diavol utilizzano interfacce COM (IVssBackupComponents) per eliminare le snapshot, un approccio programmatico più difficile da rilevare tramite command line monitoring. L'emergere di varianti come Embargo, che svuota anche il cestino tramite SHEmptyRecycleBinW(), indica un'evoluzione verso la copertura di ogni possibile canale di recupero dati.

Framework MITRE ATT&CK: tecnica T1490, tattica TA0040 (Impact). Gruppi: G1051, G1053, G0102, G1043, G1015, G0034. Software citati: S0575, S0446, S1058, S0697, S0366, S0365, S0496, S0659, S1247, S1068. Detection: DET0329 (AN0933–AN0937). Mitigazioni: M1038, M1028, M1018, M1053. Tool di detection: Sysmon, auditd, PECmd, MFTECmd, Atomic Red Team. Integrato con conoscenza professionale per tool e procedure operative.