Corruzione del Firmware: Firmware Corruption (T1495)

La simulazione di questa tecnica richiede prudenza estrema: scrivere sulla flash BIOS/UEFI può danneggiare irreversibilmente l'hardware. Ogni test va condotto su dispositivi sacrificabili o in ambiente virtualizzato con firmware emulato, mai su asset di produzione.

Su Linux lo strumento di riferimento per leggere, verificare e riscrivere la memoria flash SPI è flashrom (open source). Un red team lab-safe inizia sempre con la sola lettura per creare un backup del dump originale, prima di qualsiasi scrittura:

flashrom -p internal -r backup.bin

Solo dopo aver conservato il dump si potrebbe simulare una riscrittura con -w, operazione che in un esercizio reale va sostituita da una verifica non distruttiva (-v) per evitare il brick. Per analizzare e manipolare immagini UEFI in laboratorio si usa UEFITool (open source) e il framework CHIPSEC (open source) di Intel, che valuta la configurazione di sicurezza della piattaforma, il lock del registro BIOS e la presenza di protezioni come SMM. Comandi come chipsec_main -m common.bios_wp verificano se la write-protection del BIOS è attiva: un flash non bloccato indica una superficie sfruttabile.

Gli esempi reali mostrano due catene distinte. Il modulo Trickboot di TrickBot interroga il registro di controllo del BIOS per determinare se la flash è scrivibile, aprendo la strada a scrittura o cancellazione del firmware UEFI su host già compromessi. Bad Rabbit adotta invece un approccio a livello di bootloader, installando un loader modificato che impedisce l'avvio normale — una tecnica riproducibile in lab modificando il Master Boot Record o la partizione di sistema EFI su una macchina virtuale.

Una catena d'attacco realistica prevede: acquisizione di privilegi elevati (SYSTEM su Windows, root su Linux), verifica dello stato di protezione della flash, e infine l'operazione di scrittura. Su ESXi e apparati di rete il vettore cambia: l'aggiornamento firmware avviene tipicamente tramite upload via TFTP o SCP e riavvio, per cui la simulazione consiste nel caricare un'immagine artefatta seguita da reboot controllato.

Per preparare l'ambiente conviene lavorare con hardware datato e programmatore esterno CH341A (a pagamento, economico), che consente di ripristinare via hardware la flash dopo un test distruttivo. Questo salvagente trasforma un esperimento potenzialmente definitivo in una prova ripetibile, permettendo di studiare comportamenti e artefatti senza perdere l'asset di laboratorio.

Il rilevamento della corruzione del firmware si basa sull'osservazione di comportamenti anomali attorno agli strumenti di flashing e alle modifiche della configurazione di boot, poiché l'operazione stessa lascia poche tracce a livello applicativo.

Su Windows l'indicatore chiave è l'invocazione di un'utility di flash con privilegi elevati, seguita da accesso raw al percorso del dispositivo firmware o da modifiche alla configurazione di avvio. Le fonti da correlare sono WinEventLog:Security, WinEventLog:Sysmon (in particolare gli eventi di process creation e raw disk access) e WinEventLog:Microsoft-Windows-Kernel-Boot, che segnala anomalie nella sequenza di boot. Un alert efficace incrocia la creazione di processi di flashing con l'elevazione a SYSTEM.

Su Linux il segnale forte è l'accesso in scrittura diretta a /dev/mem o a /sys/firmware combinato con l'uso di utility come flashrom. La telemetria proviene da auditd:SYSCALL, monitorando le syscall di scrittura verso quei percorsi. Su macOS l'attenzione va agli aggiornamenti EFI eseguiti fuori dalle finestre di patch attese o tramite pacchetti firmware non firmati, osservabili in macos:unifiedlog. Sugli apparati di rete il pattern è l'upload di un'immagine firmware via TFTP/SCP o interfaccia web seguito da riavvio o perdita improvvisa di connettività, rilevabile da NSM:Flow e dai log networkdevice:firmware.

I falsi positivi principali derivano dalle legittime attività di manutenzione. Le catene di tool di flashing autorizzati vanno inserite in allowlist tramite il ParentImage, mentre i flag di flash silenzioso o forzato nella CommandLine variano tra vendor e richiedono pattern matching aggiornato. Su Linux tool rinominati o personalizzati sfuggono al match sul nome, per cui conviene correlare anche il comportamento (accesso ai path firmware) e non solo il ToolName. Su macOS gli aggiornamenti firmware avvengono normalmente dopo un aggiornamento del sistema operativo: le esecuzioni out-of-band sono il vero segnale. Sugli apparati, i riavvii fuori dalle finestre di manutenzione e le dimensioni anomale dell'immagine caricata meritano indagine.

Sul fronte preventivo, i controlli D3FEND di indurimento sono decisivi. Abilitare UEFI Secure Boot per consentire solo bootloader firmati, sfruttare l'attestazione basata su TPM per rilevare modifiche alla sequenza di avvio e proteggere le impostazioni BIOS con password forti riduce drasticamente la superficie. Il monitoraggio dell'integrità a runtime completa la copertura, segnalando alterazioni di moduli kernel o componenti critici dopo il boot. Integrare la telemetria degli account privilegiati nel SIEM chiude il cerchio, dato che l'accesso alla flash richiede privilegi elevati.

L'analisi forense della corruzione del firmware è complicata dal fatto che l'artefatto principale — la memoria flash — risiede sotto il livello del sistema operativo e spesso il dispositivo non si avvia più. La priorità è acquisire un dump fisico della flash con un programmatore hardware esterno quando l'host è irrecuperabile, confrontandolo con l'immagine di riferimento del vendor per identificare regioni sovrascritte o cancellate.

Su Windows la timeline si ricostruisce dagli artefatti che precedono la corruzione: la creazione del processo dell'utility di flashing nei log Sysmon, gli eventi di WinEventLog:Microsoft-Windows-Kernel-Boot che documentano anomalie nell'ultima sequenza di avvio riuscita, e le modifiche alla Boot Configuration Data. Le voci di WinEventLog:Security relative all'elevazione dei privilegi collocano temporalmente l'accesso SYSTEM necessario all'operazione. Nel caso di TrickBot con modulo Trickboot, tracce del modulo caricato e delle query al registro di controllo del BIOS possono precedere la scrittura. Per Bad Rabbit, l'artefatto rivelatore è il bootloader modificato: l'analisi del MBR e della partizione EFI evidenzia il loader sostituito che blocca l'avvio normale.

Su Linux l'evidenza chiave sono i record auditd:SYSCALL di scrittura verso /dev/mem o /sys/firmware e l'esecuzione di flashrom, correlabili con la cronologia della shell e i timestamp dei binari. Su macOS il unifiedlog conserva le tracce degli aggiornamenti EFI, particolarmente sospetti se avvenuti fuori dalla normale finestra post-aggiornamento OS o con pacchetti non firmati. Sugli apparati di rete i log firmware e i flussi di rete documentano l'upload dell'immagine via TFTP/SCP e il riavvio conseguente.

Un ostacolo forense significativo emerge dalla campagna 2025 Poland Wiper Attacks, campagna russa che ha colpito oltre 30 impianti eolici e fotovoltaici, una centrale di cogenerazione (CHP) e un'azienda manifatturiera polacca. Gli attaccanti hanno eseguito un factory-reset sui dispositivi compromessi, azione che ha deliberatamente ostacolato le indagini cancellando gli artefatti locali. In scenari simili l'analista deve appoggiarsi a fonti esterne all'endpoint: telemetria di rete conservata a monte, log del SIEM centralizzato e immagini di backup del firmware. Al CHP plant l'accesso era mantenuto almeno da marzo 2025, sfruttato per raccogliere credenziali e muoversi lateralmente prima del tentativo di deployment dei wiper DynoWiper e LazyWiper, distribuiti via Group Policy Objects malevoli. La ricostruzione della catena richiede quindi di risalire ben oltre l'evento distruttivo finale.

La corruzione del firmware resta una capacità di nicchia nel panorama delle minacce, riservata ad attori con obiettivi distruttivi e risorse per operare sotto il livello del sistema operativo. I dati disponibili la associano a due strumenti e a una campagna di sabotaggio, con una chiara impronta di attività statale.

TrickBot, malware modulare originariamente nato come trojan bancario, ha esteso il proprio arsenale con il modulo Trickboot, capace di scrivere o cancellare il firmware UEFI/BIOS di un dispositivo compromesso. Questa evoluzione è significativa dal punto di vista dell'intelligence: dimostra come una piattaforma criminale diffusa abbia integrato una capacità di brick permanente, spostando la minaccia dal furto finanziario al sabotaggio hardware e alla persistenza sotto il sistema operativo.

Bad Rabbit, malware associato a operazioni di tipo ransomware/wiper, adotta un approccio a livello di bootloader: installa un loader modificato che impedisce l'avvio normale del sistema. Pur non riscrivendo la flash come Trickboot, ottiene un effetto analogo di negazione della disponibilità intervenendo sulla catena di boot.

Il caso più illuminante è la campagna 2025 Poland Wiper Attacks (C0063, marzo-dicembre 2025), operazione russa contro l'infrastruttura energetica polacca. Gli obiettivi comprendevano oltre 30 impianti eolici e fotovoltaici, una centrale di cogenerazione e un'azienda manifatturiera. Gli attacchi alle risorse energetiche distribuite (DER) hanno interrotto le comunicazioni tra gli impianti e l'operatore del sistema di distribuzione, senza però fermare la generazione elettrica o la fornitura di calore. Gli attaccanti hanno impiegato due wiper inediti — DynoWiper, basato su Windows, e LazyWiper, scritto in PowerShell — distribuiti tramite Group Policy Objects malevoli, e hanno eseguito factory-reset per ostacolare le indagini.

L'attribuzione è duplice e riflette l'ambiguità tipica delle operazioni russe: parte del reporting collega l'attività al gruppo dell'FSB Dragonfly (noto anche come STATIC TUNDRA), mentre altre fonti attribuiscono le azioni distruttive al gruppo del GRU ELECTRUM (tracciato anche come Sandworm Team). Al CHP plant l'accesso era mantenuto almeno da marzo 2025, sfruttato per raccogliere credenziali e muoversi lateralmente prima del deployment dei wiper.

Il pattern emergente è netto: attori statali che colpiscono infrastrutture critiche con strumenti distruttivi, combinando wiper e manipolazione della catena di boot per massimizzare i tempi di ripristino e complicare l'attribuzione forense.

MITRE ATT&CK: tecnica T1495 (Firmware Corruption), tattica TA0040. Software S0266 (TrickBot/Trickboot), S0606 (Bad Rabbit). Campagna C0063 (2025 Poland Wiper Attacks). Mitigazioni M1026, M1046, M1051. Detection DET0167 (AN0474-AN0477). Tool di verifica firmware: CHIPSEC, flashrom, UEFITool. Parte dei dettagli operativi su comandi e artefatti deriva da conoscenza professionale di cybersecurity, nel rispetto delle regole su tool reali e verificabili.