Persistenza Pre-Boot: Pre-OS Boot (T1542)

Per un red team, la simulazione di T1542 richiede grande attenzione al perimetro di test: ogni modifica firmware o bootloader su hardware reale rischia di lasciare l'endpoint inutilizzabile. Il consiglio operativo è lavorare in laboratorio con macchine virtuali dedicate, snapshot pre-modifica e, dove possibile, board di sviluppo con socket SPI accessibile.

Su Windows, la catena più realistica parte da privilegi SYSTEM ottenuti tramite un'altra tecnica e prosegue con la scrittura diretta su settori raw del disco tramite l'API DeviceIoControl con IOCTL_DISK_WRITE. Il PoC classico è la riscrittura dell'MBR, replicabile in lab con dd for Windows (open source) puntando a \.\PhysicalDrive0. Per la componente UEFI il riferimento è Chipsec (open source), il framework di Intel che consente di enumerare la SPI flash, dumparla e analizzarla:

chipsec_util.py spi dump spi.bin

chipsec_main.py -m common.bios_wp

Queste due invocazioni permettono di verificare protezioni come BIOS Write Protect e di ottenere un'immagine da manipolare offline con UEFITool (open source) per iniettare un modulo DXE di test.

Su Linux, l'equivalente pratico è modificare grub o shim. Uno scenario da laboratorio prevede la sostituzione di grubx64.efi nella partizione ESP montata su /boot/efi, seguita da efibootmgr per riordinare la BootOrder. Il comando efibootmgr -v mostra la configurazione attuale ed è utile come baseline pre-attacco. Per test di persistenza a livello initramfs si può ricorrere a hook custom in /etc/initramfs-tools/hooks/ rigenerando l'immagine con update-initramfs -u.

Su macOS moderni (Apple Silicon) la superficie è drasticamente ridotta dalla Secure Boot policy e dal Signed System Volume; su Intel Mac legacy resta invece rilevante il comando nvram per manipolare boot-args e bless per cambiare volume di avvio.

Sul fronte network device, il pattern d'attacco simulato consiste nel caricare un'immagine firmware modificata via TFTP e alterare il boot pointer. Piattaforme come GNS3 (open source) o EVE-NG (freemium) permettono di riprodurre lo scenario senza toccare hardware di produzione. Tool di analisi firmware come binwalk (open source) sono essenziali per validare le immagini estratte. Regola d'oro: mai testare su hardware in produzione senza un percorso di ripristino documentato e una copia integra della flash originale.

La detection di T1542 richiede visibilità su artefatti che raramente rientrano nel monitoraggio standard. La consultazione della matrice D3FEND per questa tecnica indica come artefatti chiave il Boot Record, il Firmware e il Bootloader, con contromisure di tipo Boot Integrity Verification e System File Analysis che vanno tradotte in regole SIEM concrete.

Su Windows, la strategia analitica AN0774 identifica quattro segnali. Il primo è la modifica di MBR/VBR o della partizione EFI fuori dai cicli di patching legittimi: in Sysmon è utile abilitare l'Event ID 9 (RawAccessRead) e monitorare accessi a \.\PhysicalDrive0. Il secondo sono chiamate DeviceIoControl con IOCTL di scrittura raw da processi non firmati o con parent anomali. Il terzo è l'esecuzione di tool di firmware update — come utility OEM — da percorsi non standard o da parent inattesi (ad esempio un browser o Office). Il quarto è la sequenza modifica settore di boot → reboot → caricamento driver non firmati, correlabile su una finestra temporale ristretta. Le fonti da correlare sono WinEventLog:Security (in particolare 4697 per servizi) e WinEventLog:Sysmon (1, 9, 13).

Su Linux, la strategia AN0775 si basa su auditd con regole watch su /boot e /boot/efi:

auditctl -w /boot -p wa -k boot_integrity

auditctl -w /boot/efi -p wa -k efi_integrity

Gli eventi SYSCALL e EXECVE devono essere correlati con l'esecuzione di efibootmgr, dd, grub-install o update-grub da utenti diversi dagli account di patch management. Il tuning richiede una whitelist di aggiornamenti legittimi via apt, yum o rpm tracciati tramite /var/log/dpkg.log o /var/log/yum.log.

Su macOS, la strategia AN0776 si appoggia sull'Unified Log filtrando invocazioni di bless e nvram con predicati come process == "nvram" e verificando la firma del parent. Il caricamento di kext non firmati subito dopo modifiche a variabili EFI è il pattern più significativo.

Sui network device (AN0777), monitorare upload firmware via TFTP/FTP/SCP e ogni modifica ai boot pointer, correlandoli con le finestre di manutenzione ufficiali. I falsi positivi principali derivano da aggiornamenti BIOS pianificati, tool OEM come Dell Command Update o HP SoftPaq Manager, e cicli di patch Linux via unattended-upgrades: la baseline degli hash firmware approvati è indispensabile per abbattere il rumore.

L'analisi forense di un compromesso pre-boot richiede l'acquisizione di livelli che normalmente sfuggono all'imaging tradizionale. Il principio guida è: se il triage endpoint non evidenzia nulla ma i sintomi persistono attraverso reinstallazioni, sospetta il firmware.

Su Windows, la timeline parte dal dump della SPI flash. Chipsec (open source) esegue l'operazione in Live Response:

chipsec_util.py spi dump firmware_dump.bin

L'immagine risultante va confrontata con il firmware di riferimento del vendor tramite UEFITool (open source) o Binwalk (open source), cercando moduli DXE aggiuntivi, sezioni PE inattese o certificati non riconosciuti. In parallelo, il Master Boot Record e il primo settore del disco vanno acquisiti con FTK Imager (gratuito) o dd, e confrontati con l'MBR standard di Windows Boot Manager. Nel registry, la chiave HKLM\SYSTEM\CurrentControlSet\Control\BootDriverFlags e i log Microsoft-Windows-Kernel-Boot/Operational forniscono contesto sul caricamento driver in fase iniziale. Utile anche l'analisi di bootmgfw.efi e winload.efi nella ESP montata come lettera dedicata: hash SHA-256 e verifica firma Authenticode sono il primo controllo.

Su Linux, la ESP è tipicamente montata su /boot/efi e contiene EFI/BOOT/BOOTX64.EFI, EFI/ubuntu/grubx64.efi e shimx64.efi. La verifica di integrità confronta questi binari con quelli forniti dal package manager: dpkg --verify grub-efi-amd64 o rpm -V grub2-efi-x64 rivelano modifiche non tracciate. Log di auditd, journalctl -b -1 del boot precedente e la history di apt/yum completano la ricostruzione della timeline. Tool come Volatility 3 (open source) possono aiutare a estrarre indicatori dalla memoria se disponibile un dump antecedente al reboot.

Su macOS Intel legacy, gli artefatti chiave sono le variabili NVRAM (leggibili con nvram -p), i log unificati filtrati per processi bless e nvram, e i binari EFI in /System/Library/CoreServices/boot.efi. Su Apple Silicon la superficie è governata da LocalPolicy e 1TR, con artefatti forensi molto più limitati.

Per i network device, l'estrazione firmware richiede accesso console e comandi vendor-specific (show version, verify /md5 su Cisco IOS). La comparazione degli hash con quelli pubblicati dal vendor è il metodo primario. La correlazione tra timestamp di reboot, modifiche alla configurazione di boot e upload firmware via TFTP consente di posizionare l'evento nella timeline dell'incidente.

I dati MITRE ATT&CK forniti per T1542 non associano alla tecnica gruppi APT, software o campagne specifiche a livello di tecnica padre — le attribuzioni note sono generalmente mappate sulle sottotecniche (T1542.001 System Firmware, T1542.003 Bootkit, ecc.). Questo non significa che la tecnica sia teorica: al contrario, il fatto che ATT&CK la mantenga come categoria ombrello riflette la varietà di implementazioni osservate e la difficoltà di attribuzione, dato che gli impianti pre-boot vengono raramente pubblicati con dettagli sufficienti a costruire signature comportamentali di alto livello.

Dal punto di vista di un Threat Intelligence Officer, la lettura strategica di T1542 si articola su tre assi. Il primo è la soglia di capacità: sviluppare un impianto UEFI o un bootkit stabile richiede competenze di reverse engineering firmware, accesso a SDK proprietari e capacità di testing su hardware eterogeneo. Storicamente questo confina la tecnica a operatori con budget e tempo — attori state-sponsored e, in misura crescente, gruppi cybercriminali di fascia alta che riusano codice ereditato da leak passati.

Il secondo asse è il valore strategico del target. La complessità dell'impianto pre-boot non è economica per campagne opportunistiche: viene riservata a bersagli high-value dove la persistenza deve resistere a incident response completa, sostituzione del disco e reinstallazione dell'OS. Ambasciate, contractor difesa, telco e infrastrutture critiche sono i settori dove queste capacità emergono più frequentemente nella letteratura pubblica.

Il terzo asse è il trend di superficie. L'adozione di Secure Boot obbligatorio, Measured Boot con TPM 2.0, e su Apple Silicon del Signed System Volume ha alzato significativamente la barriera. La risposta degli attaccanti si è spostata su due direzioni: sfruttamento di vulnerabilità in bootloader firmati (bypass tramite componenti legittimi vulnerabili) e attacchi alla supply chain firmware, dove il codice malevolo viene iniettato a monte della catena di distribuzione.

Per una TI unit, i requisiti di raccolta prioritari sono: pubblicazioni di ricercatori firmware (ESET Research, Binarly, Kaspersky GReAT), advisory dei vendor su vulnerabilità bootloader, e monitoraggio di leak di codice sorgente firmware. Il framework mitigazioni MITRE (M1026, M1035, M1046, M1047, M1051) va tradotto in requisiti verso i fornitori hardware: attestazione remota, aggiornamenti firmware firmati e tempestivi, e supporto a strumenti di verifica indipendenti come Chipsec.

MITRE ATT&CK: T1542 Pre-OS Boot, tattiche TA0003 Persistence e TA0005 Defense Evasion. Mitigazioni M1026, M1035, M1046, M1047, M1051. Strategie di detection DET0278 con analytics AN0774-AN0777. MITRE D3FEND per artefatti Boot Record, Firmware, Bootloader. Contenuti su tool operativi (Chipsec, UEFITool, Binwalk, FTK Imager, Volatility, efibootmgr, auditd) integrati con conoscenza professionale di cybersecurity, riferita a progetti open source e documentazione vendor pubblica.