Bootkit: Pre-Boot Compromise Bootkit (T1542.003)

L'implementazione di un bootkit richiede accesso privilegiato al sistema target. In ambiente Windows, la scrittura diretta sui settori di avvio può essere simulata utilizzando strumenti di basso livello come dd o API native di Windows.

Per accedere al MBR in Windows, si può utilizzare il comando dd if=\.\PhysicalDrive0 of=mbr_backup.bin bs=512 count=1 per creare un backup del primo settore. La modifica richiede poi la scrittura inversa con dd if=modified_mbr.bin of=\.\PhysicalDrive0 bs=512 count=1. È fondamentale operare con estrema cautela in quanto errori possono rendere il sistema non avviabile.

ROCKBOOT e BOOTRASH rappresentano esempi reali di implementazione. Il primo modifica il MBR per garantire persistenza, mentre il secondo opera sul VBR. In laboratorio, strumenti come Bootkit Disk Forensic possono aiutare a comprendere le modifiche apportate.

Per sistemi UEFI, l'approccio cambia significativamente. La manipolazione avviene attraverso la modifica di file nella partizione ESP, accessibile montando la partizione con mountvol S: /s in Windows. I file critici risiedono in *\EFI\Boot* e *\EFI\Microsoft\Boot*.

La catena d'attacco tipica prevede: ottenimento privilegi amministrativi, disabilitazione temporanea delle protezioni antivirus, backup del settore originale, iniezione del bootkit, e verifica della persistenza attraverso riavvii multipli. Tool come RootkitRevealer o GMER possono essere utilizzati per verificare la presenza di modifiche ai settori di boot.

Il rilevamento dei bootkit richiede un approccio multilivello che combini monitoraggio dei processi privilegiati con l'analisi delle modifiche ai settori di avvio. La strategia DET0150 fornisce indicazioni precise per Windows e Linux.

In ambiente Windows, Sysmon rappresenta la fonte primaria di telemetria. Gli eventi critici includono accesso raw ai dischi fisici (EventID 9 per RawAccessRead) e creazione di processi con privilegi elevati che interagiscono con \\.\PhysicalDrive0. È essenziale mantenere baseline hash dei settori MBR/VBR puliti per confronto automatico.

La correlazione temporale diventa cruciale: monitorate sequenze di eventi che includono elevazione privilegi, accesso raw disk, e modifiche nella partizione ESP entro finestre temporali ristrette (tipicamente 5-10 minuti). Processi legittimi come Windows Update possono generare pattern simili, quindi è fondamentale mantenere whitelist aggiornate.

Per sistemi Linux, auditd fornisce visibilità sulle syscall critiche. Monitorate write() e ioctl() verso /dev/sda o device block equivalenti. Comandi come dd, grub-install, o efibootmgr eseguiti con privilegi root richiedono particolare attenzione.

I falsi positivi più comuni derivano da aggiornamenti di sistema, installazioni di dual-boot, o utility di backup disk-level. Implementate eccezioni basate su hash dei processi noti e pattern temporali ricorrenti (es. patch Tuesday per Windows).

L'analisi forense di un'infezione bootkit richiede l'acquisizione immediata dei primi settori del disco. In Windows, utilizzate FTK Imager o dd per catturare almeno i primi 63 settori (32KB) che contengono MBR, partition table, e VBR delle partizioni attive.

WhisperGate fornisce un case study illuminante: il malware sovrascrive il MBR con un componente bootloader che esegue operazioni distruttive e mostra una finta nota di riscatto. L'analisi del MBR modificato rivela pattern caratteristici come jump instruction anomale e codice offuscato nei byte 0x1BE-0x1FE.

Gli artefatti chiave includono: backup MBR in System Volume Information, log di System Restore che mostrano modifiche ai settori di boot, e presenza di file sospetti nella ESP (tipicamente con timestamp anomali rispetto agli altri file di sistema). In Linux, verificate /boot/grub/grub.cfg per modifiche e controllate i log di grub-install.

La timeline reconstruction deve correlare: primo accesso con privilegi elevati, disabilitazione security software (controllate event log Security per modifiche policy), scrittura raw disk (Sysmon EventID 9), e successive esecuzioni del bootkit ad ogni riavvio. Carberp lascia tracce distintive nel registro di Windows prima dell'installazione del bootkit.

Tool essenziali includono: BootKitAnalyzer per l'analisi automatica, WinHex per l'ispezione manuale dei settori, e Volatility con plugin dedicati per l'analisi della memoria che può rivelare hook pre-boot persistenti.

APT28 (Fancy Bear) ha dimostrato capacità avanzate nell'uso di bootkit, deployando versioni custom insieme a Downdelph. Il gruppo condivide codice con varianti di BlackEnergy, suggerendo possibili collaborazioni o accesso a repository comuni di malware dell'Europa orientale.

Lazarus Group utilizza WhiskeyAlfa-Three che modifica il settore 0 del MBR. Questa scelta tecnica si allinea con il loro focus su distruzione e disruption piuttosto che solo spionaggio. Il gruppo tende a utilizzare bootkit in campagne mirate contro infrastrutture critiche.

APT41 rappresenta l'evoluzione cinese delle capacità bootkit, con deployment documentato su sistemi Windows per nascondere malware complessi. Il gruppo combina motivazioni finanziarie e di spionaggio, utilizzando bootkit principalmente in operazioni a lungo termine contro target high-value.

FinFisher, venduto commercialmente, include varianti con rootkit MBR, indicando la commoditizzazione di queste capacità. TrickBot ha evoluto le sue capacità includendo l'impianto di codice malevolo nel firmware, rappresentando l'evoluzione naturale oltre i tradizionali bootkit.

I pattern geografici mostrano concentrazione di sviluppo in Russia/Europa dell'Est (APT28, BlackEnergy heritage), Corea del Nord (Lazarus), e Cina (APT41). L'overlap di tool suggerisce possibili marketplace underground dove componenti bootkit vengono condivisi o venduti. La tendenza evolutiva punta verso firmware implant e UEFI rootkit persistenti, superando le limitazioni dei bootkit tradizionali.

Framework MITRE ATT&CK T1542.003. Campagne documentate: APT28 Downdelph operations, Lazarus WhiskeyAlfa-Three deployment, WhisperGate destructive attacks. Detection strategy DET0150 per configurazione Sysmon/auditd. Risorse: BootKit Disk Forensic documentation, UEFI Forum Secure Boot specifications.