Firmware dei Componenti: Component Firmware (T1542.002)

In un contesto di red team, simulare la manomissione del firmware di componente richiede prudenza estrema: un flash errato può trasformare un dispositivo in un fermacarte. Per questo il lavoro va confinato in laboratorio, su hardware sacrificabile e con backup delle immagini originali.

La catena tipica parte da un accesso privilegiato al sistema (root o SYSTEM), prosegue con l'enumerazione dei componenti flashabili e culmina nella riscrittura dell'immagine firmware. Il primo passo è mappare la superficie: su Linux si ispezionano i controller SPI e le periferiche PCI.

• lspci -vvv per elencare i dispositivi e le loro capacità
• lsusb -v per periferiche USB con firmware aggiornabile
• smartctl -i /dev/sda (pacchetto smartmontools, open source) per leggere modello e revisione firmware di un disco

Per il firmware SPI di flash montate su scheda, flashrom (open source) è lo strumento di riferimento. Un dump di baseline si ottiene con

flashrom -p internal -r backup.bin

mentre la scrittura di un'immagine modificata userebbe il flag -w. Su hardware dedicato conviene un programmatore esterno come un CH341A abbinato a flashrom con -p ch341a_spi, così da poter recuperare il chip anche dopo un flash fallito.

Sul versante dischi, la strada storica di Equation consisteva nel riscrivere il firmware HDD di specifici produttori tramite comandi vendor-specific inviati via interfaccia ATA. Questi comandi non sono standardizzati e la loro emulazione in lab richiede firmware toolkit del produttore, spesso non pubblici; per esercizi didattici ci si limita quindi a leggere e confrontare le revisioni con hdparm -I /dev/sda.

Per riprodurre lo scenario Cyclops Blink, dove il firmware legittimo veniva patchato durante il download e re-flashato al successivo aggiornamento del dispositivo WatchGuard, l'approccio lab-safe è simulare un aggiornamento firmware intercettato: si prepara un'immagine con una modifica benigna (ad esempio un marker riconoscibile), la si firma con chiavi di test e la si applica su un dispositivo di appliance dedicato.

A supporto dell'analisi statica dell'immagine estratta, binwalk (open source) scompone e identifica i filesystem embedded, mentre UEFITool (open source) è utile per esplorare volumi EFI. L'obiettivo dell'esercizio non è la weaponizzazione ma dimostrare la finestra di rischio: se l'attaccante controlla il canale di aggiornamento o dispone di accesso privilegiato, il piano firmware diventa un rifugio invisibile agli strumenti host.

Rilevare la manomissione del firmware di componente è difficile proprio perché l'impianto opera sotto il livello osservabile dagli strumenti host. La strategia vincente sposta l'attenzione sui precursori e sugli effetti collaterali: chi scrive firmware deve prima ottenere privilegi elevati e interagire con API o interfacce di basso livello.

Su Windows, la strategia di detection AN0916 raccomanda di correlare caricamenti di driver anomali con tentativi di accesso al firmware. Le sorgenti chiave sono WinEventLog:Sysmon e i feed di firmware:integrity. Concretamente conviene monitorare:

• EventCode 6 di Sysmon (Driver Loaded) per driver non firmati o fuori dalla allowlist
• EventCode 7 (Image Loaded) e EventCode 1 (Process Create) per tool di flashing eseguiti con privilegi SYSTEM
• Uso sospetto di API privilegiate che leggono o scrivono memoria di controller

La messa a punto è cruciale per contenere i falsi positivi. Servono tre riferimenti: una lista di hash di firmware noti-buoni (KnownGoodFirmwareHashes) come baseline di confronto, una allowlist dei driver approvati in produzione (DriverAllowList) e una finestra temporale di correlazione tra il tentativo di modifica firmware e il comportamento anomalo di driver o processi.

Su Linux (AN0917), l'attenzione si concentra su chiamate ioctl e accessi sysfs verso il firmware dei dispositivi, oltre all'esecuzione inattesa di utility di flashing. Le fonti sono auditd:SYSCALL e linux:syslog; un audit rule mirato su ioctl verso i device a blocchi, unito al monitoraggio degli errori SMART registrati dal kernel, evidenzia anomalie di checksum firmware. Le soglie (AlertThresholds) vanno calibrate sulla tolleranza agli errori SMART prima di generare l'alert, con una FirmwareImageBaseline come termine di paragone.

Su macOS (AN0918), si osservano manipolazioni EFI/firmware tramite caricamenti di driver anomali, kext non firmati o variabili NVRAM alterate. La sorgente è macos:unifiedlog, da confrontare con una ApprovedKextList di estensioni fidate e una EFIHashBaseline di immagini EFI note-pulite.

Sul fronte preventivo, i controlli di irrobustimento più efficaci sono la verifica d'integrità del firmware all'avvio, il boot misurato e la firma obbligatoria dei driver. I falsi positivi più comuni derivano da aggiornamenti firmware legittimi del vendor: per questo ogni finestra di manutenzione pianificata va comunicata al SOC e usata per aggiornare la baseline degli hash, così da distinguere il flash autorizzato da quello ostile.

L'analisi forense del firmware di componente ribalta le priorità abituali: gli artefatti più preziosi non risiedono nel filesystem ma nella memoria non volatile dei dispositivi, che va acquisita con dump dedicati. La timeline dell'investigazione parte quindi dalla raccolta delle immagini firmware e dal loro confronto con baseline note-pulite.

Il passo iniziale è estrarre l'immagine sospetta. Su Linux, un dump della flash SPI si ottiene con flashrom (open source) e il flag di lettura -r, generando un file da confrontare con l'immagine di riferimento del vendor. Per i dischi, smartctl -a /dev/sda (smartmontools, open source) documenta modello, revisione firmware e log SMART: una revisione firmware non corrispondente a quella ufficiale del produttore, o errori SMART anomali, sono indicatori di manomissione da inserire in timeline.

Su Windows, gli artefatti utili includono i log di Sysmon relativi al caricamento driver (EventCode 6) e i timestamp di installazione di componenti kernel, incrociati con eventuali dump del firmware UEFI/SPI. L'analisi statica dell'immagine estratta procede con binwalk (open source) per identificare filesystem e blob embedded, e con UEFITool (open source) per esplorare i volumi EFI alla ricerca di moduli DXE aggiunti o modificati.

Su macOS, gli elementi da acquisire sono le variabili NVRAM (leggibili con nvram -p), lo stato dei kext caricati e gli hash dell'immagine EFI, da confrontare con una baseline note-pulita. Voci NVRAM inattese o kext non firmati diventano marcatori temporali dell'intrusione.

Le campagne documentate offrono modelli investigativi concreti. Equation disponeva della capacità di sovrascrivere il firmware dei dischi rigidi di alcuni produttori: in un caso simile l'analista cerca revisioni firmware fuori catalogo e settori riservati non standard, perché l'impianto tende a nascondere il payload in aree del disco invisibili al sistema operativo. Cyclops Blink invece manteneva persistenza patchando il firmware legittimo dei dispositivi WatchGuard durante il download: qui l'indagine si sposta sul confronto byte-a-byte tra l'immagine installata e quella ufficiale, verificando la validità delle firme e la coerenza dei checksum.

Un aspetto che complica la timeline è la resistenza dell'impianto alla re-immagine del disco e ai riavvii: gli artefatti sopravvivono alle bonifiche standard, quindi la validazione va sempre condotta su firmware acquisito, non sullo stato del sistema operativo che potrebbe essere già stato ripulito. La conservazione dei dump originali come reperto è essenziale per l'analisi differenziale successiva.

Il panorama degli attori capaci di manipolare il firmware dei componenti è ristretto e riservato a operatori con risorse ingenti, competenze hardware e accesso a documentazione proprietaria dei produttori. I dati disponibili delineano un profilo netto: 1 gruppo APT e 1 famiglia malware associati alla tecnica, senza campagne codificate.

Il riferimento storico è Equation (G0020), noto per la capacità di sovrascrivere il firmware dei dischi rigidi di alcuni produttori. Si tratta di una delle dimostrazioni più avanzate mai documentate di impianto nel firmware di storage: riscrivere il microcodice del controller di un disco richiede la conoscenza di comandi vendor-specific non standardizzati, un livello di sofisticazione che colloca il gruppo in una fascia d'élite. L'obiettivo strategico è la persistenza a lungo termine: un impianto così collocato sopravvive alla formattazione e alla re-immagine, garantendo un accesso praticamente permanente al bersaglio.

Sul fronte malware, Cyclops Blink (S0687) rappresenta l'evoluzione della tecnica verso i dispositivi di rete. Questo impianto manteneva persistenza patchando il firmware legittimo dei dispositivi al momento del download, colpendo in particolare gli apparati WatchGuard. L'approccio è concettualmente diverso da quello di Equation: invece di riscrivere direttamente la flash del componente, intercetta e altera il legittimo canale di aggiornamento, così che la patch malevola venga applicata dallo stesso meccanismo fidato di manutenzione del dispositivo.

Da questi due profili emergono pattern ricorrenti nell'uso della tecnica. In primo luogo, il bersaglio privilegiato sono componenti con controlli di integrità deboli o assenti: dischi rigidi nel caso di Equation, appliance di rete nel caso di Cyclops Blink. In secondo luogo, entrambi convertono la difficoltà tecnica in vantaggio operativo, ottenendo un livello di stealth e resilienza irraggiungibile dagli impianti che vivono nel sistema operativo.

La lezione di threat intelligence è duplice. Gli apparati perimetrali di rete rappresentano una superficie d'attacco firmware sempre più appetibile, perché spesso non rientrano nei programmi di monitoraggio endpoint e ricevono aggiornamenti attraverso canali che, se compromessi, diventano vettori di persistenza. La difesa richiede attenzione all'intera supply chain del firmware — dall'integrità dei canali di distribuzione alla verifica delle firme — perché il modello Cyclops Blink dimostra che compromettere il processo di aggiornamento può essere più efficace che attaccare direttamente il componente.

MITRE ATT&CK: tecnica T1542.002 (Component Firmware), tattiche TA0003 e TA0005. Gruppo G0020 (Equation), software S0687 (Cyclops Blink), mitigazione M1051 (Update Software), strategia di detection DET0323 con analitiche AN0916 (Windows), AN0917 (Linux), AN0918 (macOS). Strumenti citati: flashrom, smartmontools, binwalk, UEFITool, OpenVAS, Ansible (open source); WSUS, ManageEngine Patch Manager Plus, SCCM (a pagamento). Parte dei comandi e degli artefatti forensi deriva da conoscenza professionale di cybersecurity verificata sulla documentazione ufficiale dei tool.