Bootkit: Compromissione del Processo di Avvio (T1542.003)

La simulazione di un bootkit in ambiente red team richiede rigore assoluto: si opera esclusivamente su macchine virtuali dedicate con snapshot pre-esecuzione, mai su hardware di produzione. L'accesso raw al disco richiede privilegi SYSTEM su Windows o root su Linux, quindi la catena d'attacco presuppone una escalation già completata.

Su Windows, l'accesso ai settori fisici avviene tramite l'API CreateFile con il path \.\PhysicalDrive0 seguito da WriteFile sui primi 512 byte per riscrivere l'MBR. In un lab, lo strumento più didattico è MBRFilter di FireEye (open source) per comprendere la protezione, mentre per emulare comportamenti tipo ROCKBOOT o BOOTRASH ci si può appoggiare a dd for Windows (open source) con sintassi tipo dd if=custom_mbr.bin of=\.\PhysicalDrive0 bs=512 count=1. Per lo studio di bootkit UEFI, il progetto Chipsec di Intel (open source) permette di enumerare la ESP con chipsec_util uefi decode e analizzare i moduli DXE caricati.

Su Linux la scrittura diretta al bootloader passa da dd if=/dev/zero of=/dev/sda bs=446 count=1 per azzerare l'area MBR pre-partition-table, oppure da grub-install --force per installare un GRUB modificato. La ESP viene tipicamente montata su /boot/efi e la manipolazione delle voci di boot avviene tramite efibootmgr -c -d /dev/sda -p 1 -L "Rogue" -l "\EFI\rogue\rogue.efi".

Per la fase di sviluppo, il framework EfiGuard (open source) mostra tecniche di patch del bootloader Windows a runtime e serve come base per capire come i bootkit reali disabilitano PatchGuard e DSE. Il repository LoJax analysis di ESET fornisce riferimenti tecnici sulle prime implementazioni UEFI persistenti in-the-wild.

Una catena red team realistica prevede: (1) initial access con phishing, (2) privilege escalation a SYSTEM tramite exploit locale, (3) disabilitazione temporanea di Secure Boot se possibile via bcdedit /set {bootmgr} nointegritychecks on (richiede Test Mode), (4) deploy del payload sul settore target, (5) reboot controllato con snapshot di rollback pronto.

Per validare la detection lato blue team, Atomic Red Team (open source) include test relativi a T1542.003 che modificano file nella ESP in modo sicuro. L'analisi post-esecuzione con Volatility 3 (open source) su un memory dump permette di verificare quali plugin identificano correttamente la presenza del bootkit.

La detection di un bootkit richiede visibilità su operazioni normalmente rare in un endpoint sano: accesso raw ai dispositivi a blocchi, scritture su settori di boot, modifiche a file nella ESP. La strategia DET0150 proposta da MITRE si articola su due analitiche parallele per Windows e Linux, entrambe centrate sulla correlazione tra esecuzione privilegiata e modifica low-level del disco.

Su Windows la sorgente primaria è Sysmon (gratuito). L'evento EventID 9 (RawAccessRead) rileva letture dirette a \.\PhysicalDriveN e va abbinato all'evento EventID 1 (ProcessCreate) per identificare il processo iniziatore. La configurazione sysmon-modular di Olaf Hartong (open source) include regole specifiche per questi eventi. Vanno inoltre monitorati gli eventi di scrittura su file all'interno del path *\Device\HarddiskVolume1\EFI* (EventID 11 FileCreate), correlati con il baseline degli eseguibili EFI approvati (tipicamente firmati Microsoft o dal vendor OEM).

Un secondo pillar è la correlazione con Windows Defender ATP o EDR equivalenti che espongono telemetria su chiamate NtWriteFile verso handle di volume fisico. I falsi positivi principali provengono da software legittimi: strumenti di backup come Veeam o Acronis (a pagamento), utility di partizionamento come GParted (open source) o Paragon (a pagamento), aggiornamenti firmware OEM (Dell Command Update, Lenovo Vantage) che scrivono legittimamente in ESP. Una whitelist per hash del binario e per firma digitale è indispensabile.

Su Linux il monitoraggio si basa su auditd con regole mirate. Una regola tipica è -w /boot -p wa -k boot_modification per intercettare write e attribute change sulla directory /boot, integrata da -w /boot/efi -p wa -k efi_modification. Sulle syscall, -a always,exit -F arch=b64 -S write -F path=/dev/sda -k raw_disk_write traccia scritture dirette al dispositivo. L'esecuzione di grub-install, efibootmgr, dd con target device va tracciata via -w /usr/sbin/grub-install -p x -k boot_tool.

Per i controlli preventivi tipo D3FEND Harden, verificare che Secure Boot sia attivo su tutti gli endpoint tramite query PowerShell Confirm-SecureBootUEFI e riportare lo stato nel SIEM come inventory continuo. Il TPM PCR 0-7 contiene misure del firmware e del bootloader: soluzioni come BitLocker con TPM attestation possono generare eventi EventID 1024 nel canale Microsoft-Windows-BitLocker-API/Management quando i PCR cambiano inaspettatamente, segnale forte di manomissione del boot chain.

Le soglie di alert vanno calibrate: ogni singola scrittura raw al PhysicalDrive0 fuori finestra di manutenzione deve generare incident ad alta severità, non alert informativo.

L'analisi forense di un sospetto bootkit inizia con l'acquisizione offline del disco, poiché un bootkit attivo può nascondere sé stesso al sistema operativo compromesso. L'imaging va effettuato con dc3dd (open source) o FTK Imager (gratuito) da un ambiente di boot esterno, tipicamente una distro live come CAINE o SIFT Workstation (open source).

L'artefatto primario è il Master Boot Record, i primi 512 byte del disco fisico. Si estrae con dd if=/dev/sdX of=mbr.bin bs=512 count=1 e si confronta l'hash SHA-256 con baseline noti. Il tool mbrscan e le utility del pacchetto sleuthkit (open source) permettono di disassemblare il codice del bootloader con mmls per verificare la partition table e mmcat per estrarre l'area di boot. Un MBR legittimo Windows contiene stringhe caratteristiche come "Invalid partition table" o "Missing operating system"; deviazioni o istruzioni assembly anomale in offset 0x000-0x1BE sono red flag.

Per i Volume Boot Record, ogni partizione ha il proprio VBR nei primi settori. Si estraggono con offset calcolati dalla partition table e si analizzano per codice iniettato. BOOTRASH documentato da MITRE opera esattamente a questo livello, sostituendo il VBR NTFS con codice malevolo che carica un filesystem virtuale.

Su sistemi UEFI, la EFI System Partition è normalmente formattata FAT32 e contiene la directory *\EFI\Microsoft\Boot* con bootmgfw.efi e altri moduli firmati. Il montaggio read-only via mount -o ro,loop offset=... image.dd /mnt/esp consente enumerazione dei file. Ogni .efi non firmato o con firma non riconducibile a Microsoft/OEM va estratto e analizzato con UEFITool (open source) per ispezionare la struttura dei volumi firmware, e con Ghidra (open source) o IDA Pro (a pagamento) per il reverse engineering del codice PE32+ EFI.

Su Linux, la timeline forense include controllo di /boot/grub/grub.cfg per entry sospette, checksum di vmlinuz-* e initrd.img-* confrontati con i pacchetti del package manager (debsums su Debian, rpm -V kernel su RHEL), e analisi di /boot/efi/EFI/ per moduli non standard. I log auditd archiviati precedenti all'incidente possono documentare l'esecuzione originale di grub-install o efibootmgr da parte dell'attaccante.

La memoria fisica del sistema live, se acquisita prima del reboot con WinPmem o LiME (entrambi open source), può essere analizzata con Volatility 3 per identificare hook nel boot loader o driver caricati fuori dalla catena legittima. Il plugin windows.driverirp aiuta a rilevare driver che intercettano IRP_MJ_READ/WRITE su disco.

Casi documentati come APT41 con bootkit MBR e WhisperGate come wiper mascherato da ransomware forniscono pattern di riferimento per l'analisi comparativa.

L'adozione di bootkit è appannaggio di un ristretto club di attori con capacità di sviluppo avanzate, dato il costo tecnico e il rischio di brick del sistema target. I dati MITRE identificano tre gruppi APT che hanno impiegato questa tecnica, ciascuno con motivazioni e pattern distintivi.

APT28, noto anche come Fancy Bear e attribuito a servizi di intelligence russi, ha deployato un bootkit in accoppiata con il downloader Downdelph per garantire persistenza sui target di alto valore. L'elemento tecnicamente rilevante evidenziato dai dati è la condivisione di codice con varianti di BlackEnergy, famiglia storicamente associata ad attacchi contro infrastrutture critiche ucraine. Questo riuso suggerisce una supply chain di sviluppo condivisa o un ecosistema di code sharing tra operazioni russe di alto profilo, coerente con l'ipotesi di team di sviluppo centralizzati che forniscono moduli a più unità operative.

Lazarus Group, cluster nordcoreano attribuito al Reconnaissance General Bureau, ha impiegato il malware WhiskeyAlfa-Three che modifica il settore 0 del disco. Il pattern di utilizzo è coerente con la doppia natura di Lazarus: da un lato spionaggio, dall'altro operazioni distruttive contro target come Sony Pictures e istituti finanziari. La modifica MBR in questo contesto serve sia persistenza sia potenziale distruzione, un dual-use ricorrente nell'arsenale nordcoreano.

APT41, attore cinese con doppio mandato di spionaggio statale e cybercrime finanziario, ha deployato bootkit MBR su sistemi Windows specificamente per occultare malware e mantenere persistenza. L'utilizzo di tecniche invasive come i bootkit su un ampio target set (APT41 è noto per operare su decine di verticali) indica maturità operativa e disponibilità di tool proprietari o acquistati sul mercato grigio.

Sul fronte software, i dati censiscono sei famiglie con approcci differenziati. ROCKBOOT e BOOTRASH rappresentano le implementazioni classiche rispettivamente MBR e VBR. FinFisher, tool commerciale venduto storicamente a governi da Gamma Group, incorpora in alcune varianti un rootkit MBR, testimoniando come la capacità bootkit sia disponibile anche via lawful intercept market. TrickBot ha evoluto la propria persistenza fino al livello firmware, capacità documentata nel modulo TrickBoot. Carberp, banking trojan il cui source code fu leaked nel 2013, ha democratizzato l'accesso a codice bootkit funzionante. WhisperGate, impiegato contro obiettivi ucraini a inizio 2022, riscrive l'MBR con un componente wiper mascherato da ransomware.

Il trend osservabile è la progressiva migrazione da bootkit MBR verso payload UEFI/ESP, coerente con la diffusione di Secure Boot che rende meno praticabili i vecchi approcci BIOS. Attori come APT28 con LoJax hanno già dimostrato capacità UEFI in-the-wild.

MITRE ATT&CK T1542.003 (Bootkit), tattiche TA0003 e TA0005. Gruppi G0007 (APT28), G0032 (Lazarus Group), G0096 (APT41). Software S0112 (ROCKBOOT), S0114 (BOOTRASH), S0182 (FinFisher), S0266 (TrickBot), S0484 (Carberp), S0689 (WhisperGate). Mitigazioni M1026 (Privileged Account Management), M1046 (Boot Integrity). Detection strategy DET0150 con analitiche AN0428 (Windows) e AN0429 (Linux). MITRE D3FEND per artefatti Boot Record e tecniche difensive. Integrata conoscenza professionale su tool forensi e di detection (Sysmon, auditd, Volatility, Chipsec, UEFITool, Sleuthkit) con verifica della sintassi operativa.