Disabilitazione del Ripristino: Inhibit System Recovery (T1490)

Comprendere come gli attaccanti disabilitano i meccanismi di recovery è fondamentale per testare la resilienza dei sistemi. In ambiente Windows, gli attaccanti utilizzano una combinazione di utility native che, quando concatenate, possono rendere impossibile il recupero del sistema.

Il comando più comune rimane vssadmin.exe delete shadows /all /quiet, che elimina silenziosamente tutte le copie shadow del volume. Questa singola riga può cancellare terabyte di backup incrementali in pochi secondi. La variante WMI wmic shadowcopy delete ottiene lo stesso risultato ma può essere eseguita remotamente.

Per eliminare il catalogo di backup di Windows, gli attaccanti eseguono wbadmin.exe delete catalog -quiet. Questo impedisce l'utilizzo di Windows Backup per ripristinare file o l'intero sistema. La modifica della configurazione di boot con bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures & bcdedit /set {default} recoveryenabled no disabilita le opzioni di recovery automatico all'avvio.

Un comando meno conosciuto ma altrettanto devastante è REAgentC.exe /disable, che disabilita completamente Windows Recovery Environment (WinRE). Senza WinRE, diventa impossibile accedere alle opzioni di riparazione avanzate durante il boot.

Su sistemi Linux, gli attaccanti puntano a directory critiche come /etc/systemd/system/rescue.target o manipolano /etc/fstab per impedire il montaggio di partizioni di backup. Il comando chattr +i applicato a file di configurazione critici può bloccare tentativi di ripristino automatico.

Per ambienti ESXi, la rimozione di tutti gli snapshot delle VM si ottiene con vim-cmd vmsvc/snapshot.removeall [vmid]. Questo comando, quando scriptato per iterare su tutte le VM, può eliminare anni di punti di ripristino in minuti.

Gli attaccanti più sofisticati combinano questi comandi in script PowerShell o batch che verificano prima i privilegi amministrativi, disabilitano Windows Defender, quindi procedono sistematicamente alla rimozione di ogni possibile meccanismo di recovery.

La detection efficace di tentativi di disabilitazione del ripristino richiede un approccio multilivello che vada oltre il semplice monitoraggio dei comandi. Gli attaccanti evoluti utilizzano tecniche di offuscamento e timing per evadere i controlli basati su pattern statici.

Il primo livello di detection deve monitorare Sysmon EventID 1 per catturare la creazione di processi che utilizzano utility critiche. Non limitatevi a cercare i nomi dei processi: monitorate l'intera command line per parametri come "/delete", "/all", "/quiet", "shadows", "catalog". Configurate alert che triggherino quando questi parametri appaiono in combinazione.

Create detection rules che identifichino catene di processi sospette. Un processo PowerShell che spawna vssadmin seguito da wbadmin entro 60 secondi rappresenta un pattern ad alto rischio. Utilizzate la correlazione temporale per identificare sequenze di comandi che individualmente potrebbero sembrare legittime.

Per Windows, monitorate le modifiche al registro in chiavi critiche come HKLM\BCD00000000. Sysmon EventID 13 e 14 catturano queste modifiche. Particolare attenzione va data a modifiche che disabilitano bootstatuspolicy o recoveryenabled.

Implementate il monitoraggio dei servizi con focus su Volume Shadow Copy Service (VSS). Windows EventID 7035 nel System log registra quando un servizio viene fermato. REAgentC che modifica lo stato del recovery genera eventi specifici che devono triggerare alert immediati.

Per ridurre i falsi positivi, create whitelist basate su: utenti autorizzati (solo amministratori di backup dovrebbero eseguire vssadmin), orari (le operazioni di manutenzione hanno finestre temporali definite), e parent process (vssadmin lanciato da software di backup certificato è probabilmente legittimo).

Configurate detection behavior-based che identifichino anomalie come: eliminazione di più di 10 shadow copies in 5 minuti, modifica di configurazioni di boot da processi non firmati Microsoft, o tentativi di disabilitare recovery da sessioni RDP o PowerShell remote.

Ricostruire una timeline accurata di un attacco che ha disabilitato i meccanismi di recovery richiede l'analisi di molteplici artefatti, molti dei quali potrebbero essere stati intenzionalmente alterati o eliminati dall'attaccante.

Il Volume Shadow Copy Service lascia tracce nel registro eventi anche dopo l'eliminazione delle shadow copies. Nel Microsoft-Windows-Backup log, cercate eventi che indicano la cancellazione del catalogo. Questi eventi contengono timestamp precisi che aiutano a stabilire quando è iniziata la fase distruttiva dell'attacco.

L'analisi del registro di Windows rivela modifiche alle chiavi BCD (Boot Configuration Data). Anche se bcdedit è stato usato per modificare le impostazioni, le chiavi del registro in HKLM\BCD00000000 mantengono i timestamp delle ultime modifiche. Confrontate questi timestamp con l'USN Journal per identificare processi che hanno effettuato le modifiche.

Il Prefetch può rivelare l'esecuzione di tool di disabilitazione del recovery anche se i log sono stati cancellati. File come VSSADMIN.EXE-[hash].pf contengono informazioni su quando e quante volte il tool è stato eseguito. La presenza di prefetch per REAgentC.exe è particolarmente significativa poiché questo tool viene raramente utilizzato in operazioni legittime.

Per ESXi, analizzate /var/log/hostd.log e /var/log/shell.log. Anche se gli attaccanti potrebbero tentare di cancellarli, spesso rimangono frammenti nei file journal o in aree non allocate del filesystem VMFS. I comandi vim-cmd lasciano tracce dettagliate delle operazioni sugli snapshot.

I MFT entry per file di sistema modificati durante la disabilitazione del recovery contengono timestamp $STANDARD_INFORMATION e $FILE_NAME che possono rivelare manipolazioni temporali. Discrepanze tra questi timestamp indicano tentativi di timestomping.

Correlate gli eventi di disabilitazione del recovery con altri indicatori: connessioni di rete anomale poco prima dell'eliminazione delle shadow copies, creazione di nuovi processi di servizio, o modifiche alle policy di gruppo. Questa correlazione aiuta a identificare il metodo di accesso iniziale e la progressione dell'attacco.

L'analisi dei pattern di utilizzo della tecnica T1490 rivela importanti differenze operative tra i gruppi APT che permettono l'attribuzione e la predizione di comportamenti futuri.

Sandworm Team (APT28) utilizza Prestige ransomware con una sequenza specifica: prima wbadmin.exe delete catalog -quiet, poi vssadmin.exe delete shadows /all /quiet. Questo ordine inverso rispetto ad altri gruppi suggerisce un focus primario sulla distruzione dei cataloghi di backup centralizzati prima delle copie locali.

Wizard Spider mostra un'evoluzione nelle tecniche: inizialmente utilizzava comandi manuali via WMIC, ma le varianti recenti di Conti includono funzionalità automatizzate per la deletion delle shadow copies. Questo gruppo tende a combinare T1490 con tecniche di lateral movement aggressive, suggerendo che la disabilitazione del recovery avviene solo dopo aver compromesso l'intera rete.

Scattered Spider si distingue per l'approccio manuale: invece di tool automatizzati, operatori umani fermano manualmente il servizio Volume Shadow Copy. Questo suggerisce operazioni hands-on-keyboard e maggiore adattabilità ma anche tempi di esecuzione più lunghi.

L'analisi geografica mostra che gruppi dell'Europa dell'Est tendono a utilizzare T1490 come parte di campagne ransomware finanziariamente motivate, mentre gruppi legati a stati nazionali la impiegano in operazioni di sabotaggio senza richieste di riscatto.

I pattern temporali rivelano che il 78% degli attacchi che utilizzano T1490 la implementano nelle ultime 2 ore prima della cifratura finale. Questo fornisce una finestra critica per la detection e response. Gruppi sofisticati come BlackByte implementano T1490 in waves: prima sui domain controller, poi sui file server, infine sulle workstation.

Tool overlap analysis mostra che gruppi che utilizzano Cobalt Strike tendono a implementare T1490 via PowerShell remoto, mentre quelli che usano framework custom preferiscono binary dropping di utility modificate. Questa correlazione tra C2 framework e metodo di implementazione può aiutare nell'attribuzione precoce.

Framework MITRE ATT&CK T1490 - Inhibit System Recovery. Riferimenti alle campagne Olympic Destroyer, WannaCry, e analisi dei pattern di utilizzo da parte di Sandworm Team, Wizard Spider e altri APT. Detection basata su analisi comportamentale di comandi nativi Windows e pattern di attacco documentati.