Blocco degli Indicatori: Indicator Blocking (T1562.006)

Quando un attaccante riesce a spegnere i fari di un'infrastruttura — log, telemetria, sensori — ogni azione successiva diventa invisibile. Indicator Blocking è la sotto-tecnica che descrive esattamente questo scenario: l'avversario interviene sui meccanismi di raccolta eventi per impedire che alert e indicatori raggiungano gli analisti. Si inserisce nella tattica Defense Evasion (TA0005), quella fase della kill chain in cui l'obiettivo non è muoversi lateralmente o esfiltrare dati, ma semplicemente restare nascosti.

Le superfici di attacco sono molteplici. Su Windows il bersaglio principale è Event Tracing for Windows (ETW), il motore che alimenta quasi ogni pipeline di telemetria: Sysmon, Defender, AMSI e decine di provider di sicurezza. Basta una modifica chirurgica al Registry o una chiamata a Set-EtwTraceProvider per silenziare interi canali di logging. Su Linux e ESXi il target diventa syslog e i suoi demoni: fermarli o riconfigurarne la destinazione equivale a tagliare il cavo tra l'host e il SIEM.

Il catalogo ATT&CK associa a questa tecnica 2 gruppi APT, 8 software documentati, 3 mitigazioni e una strategia di detection multi-piattaforma con analisi dedicate per Windows, Linux, macOS ed ESXi. L'ampiezza del fenomeno conferma che il blocco degli indicatori non è una manovra di nicchia: è un passaggio quasi obbligato per chi vuole operare a lungo in una rete difesa.

L'obiettivo in laboratorio è dimostrare al blue team che la telemetria può essere disattivata senza generare alert, se le detection non sono calibrate. Il primo vettore da testare è il patching in-memory di ETW: molti framework C2 lo fanno in automatico, ma capire il meccanismo sottostante è fondamentale.

La tecnica classica consiste nel sovrascrivere la funzione EtwEventWrite in ntdll.dll con un'istruzione di ritorno immediato (ret). In un contesto di test si può usare Brute Ratel C4 (a pagamento), che integra nativamente sia il bypass ETW sia il patching AMSI. In alternativa, il modulo PowerShell di SharPersist (open source) o semplici script C# caricati via reflection permettono lo stesso risultato.

Per simulare la manipolazione del Registry, il percorso più diretto è modificare il valore File nella chiave di configurazione del Security Event Log:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Security" /v File /t REG_EXPAND_SZ /d "C:\Windows\Temp\decoy.evtx" /f

Questa modifica reindirizza i log di sicurezza verso un file arbitrario, con effetto immediato e senza reboot. Il blue team che monitora solo il percorso standard perderà ogni evento. Per il canale ETW, il cmdlet nativo è altrettanto efficace:

Set-EtwTraceProvider -Guid "{GUID-del-provider}" -AutologgerName "EventLog-Security" -Enabled 0

Su Linux la simulazione punta a syslog. Un attaccante può fermare il demone con systemctl stop rsyslog oppure riconfigurare la destinazione dei log editando /etc/rsyslog.conf. Su ambienti ESXi il comando documentato è:

esxcli system syslog config set --loghost="" esxcli system syslog config reload

Questi due comandi azzerano l'host di destinazione syslog, isolando l'hypervisor da qualsiasi piattaforma di raccolta centralizzata.

Per un test completo, vale la pena concatenare il blocco degli indicatori con un'azione rumorosa (creazione utente, dump LSASS) e verificare se il SOC riceve l'alert. Se la catena di logging è stata interrotta correttamente, il silenzio sarà totale — ed è esattamente il punto che il report deve evidenziare.

Un tool utile per l'assessment è ETWSilencer (open source), uno strumento che filtra selettivamente i provider ETW intercettando le chiamate di scrittura. Va utilizzato esclusivamente in ambienti autorizzati e isolati.

Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?

Scarica la guida gratuita e segui il percorso corretto fin dal primo passo