Sommario
La scoperta di HybridPetya da parte di ESET evidenzia un’evoluzione del ransomware orientata al firmware: il campione emula Petya e NotPetya, ma integra un bypass di UEFI Secure Boot legato a CVE-2024-7344, installa un bootkit nella partizione EFI e cifra la Master File Table (MFT) dei volumi NTFS. A differenza di NotPetya, che agiva come wiper senza via di ritorno, HybridPetya conserva una logica estorsiva classica e consente decrittazione tramite chiave di 32 caratteri. I primi campioni compaiono su VirusTotal a febbraio 2025, mentre la telemetria ESET non segnala ancora campagne in the wild. Il ceppo colpisce sistemi UEFI moderni e host legacy privi dell’aggiornamento dbx di gennaio 2025, sfruttando componenti di avvio revocati ma non aggiornati. Per SOC e IT la priorità diventa ripristinare la catena di fiducia del boot, rafforzare monitoraggio della EFI System Partition, e verificare configurazioni Secure Boot su tutta la flotta.
Che cos’è HybridPetya e perché è diverso?
HybridPetya combina la cifratura della MFT tipica di Petya con un flusso di pre-OS che sfrutta UEFI. Ripropone la schermata CHKDSK fittizia per nascondere la fase distruttiva e mostra una nota di riscatto con indirizzo Bitcoin ed email di contatto. L’obiettivo è bloccare l’accesso ai dati in modo rapido, conservando però la possibilità di ripristino a pagamento. Questa impostazione massimizza la pressione sulla vittima, evita l’attenzione diffusa generata dalle grandi epidemie e riduce la necessità di capacità worm-like. Il risultato è una minaccia mirata, capace di eludere difese basate soltanto su EDR e controlli post-avvio.
Catena d’infezione: dal dropper al bootkit
Gli installer attribuiti a HybridPetya, tra cui notpetyanew.exe e varianti simili, verificano la presenza di GPT/UEFI, rimuovono bootloader fallback e depositano componenti nella EFI System Partition. Vengono creati backup dei file di avvio, scritte configurazioni operative e preparato il materiale per l’aggiramento di Secure Boot. La sequenza culmina con un BSOD indotto per forzare il riavvio e demandare il controllo al bootkit. All’avvio successivo, il codice EFI malevolo intercetta la sequenza, legge flag e parametri nella directory \EFI\Microsoft\Boot, avvia la cifratura e prepara l’esposizione della nota.
Bypass di UEFI Secure Boot: cosa succede
Il bypass si appoggia a CVE-2024-7344 e a un reloader EFI capace di caricare un’app EFI non firmata, sfruttando una versione di bootmgfw.efi revocata in dbx ma ancora presente su sistemi non aggiornati. Su questi host, Secure Boot non ferma la catena di avvio alterata e il reloader passa il controllo al payload. La finestra di opportunità nasce quando la revocation list (dbx) non è aggiornata: l’intero modello di fiducia del pre-OS crolla e i controlli dell’OS o dell’EDR arrivano troppo tardi. Le varianti citano file come cloak.dat e componenti reloader.efi per orchestrare il caricamento.
Cifratura della MFT: impatti operativi
Il bootkit identifica i volumi NTFS, mappa le strutture e cifra la sola MFT usando una chiave Salsa20 di 32 byte e un nonce di 8 byte. La scelta di colpire la tabella dei metadati rende i file fisicamente presenti ma inaccessibili, causando blocchi immediati su workstation e server. Il malware aggiorna un contatore dei cluster cifrati, riducendo il rischio di corruzioni irreversibili, e visualizza una schermata tipo CHKDSK per rassicurare l’utente. Terminata la fase, appare la ransom note con istruzioni e il campo per la chiave.
Confronto con Petya e NotPetya
Come Petya, HybridPetya richiede un riavvio per attivare il bootloader malevolo e colpisce la MFT con un cifrario a flusso. Come NotPetya, riprende estetica e ritmo della nota e parte della messa in scena. Differisce però nell’intento: NotPetya era di fatto un wiper, mentre HybridPetya mantiene una logica di estorsione con recuperabilità condizionata. Diverge anche nei meccanismi di verifica: l’uso di SPONGENT-256/256/16 per il controllo in alcune varianti e la catena di keying ispirata a progetti come RedPetyaOpenSSL mostrano una base di codice ibrida, aggiornata e meno rumorosa rispetto ai grandi outbreaks del passato.
Meccanismi di chiave e recovery controllata
La configurazione in \EFI\Microsoft\Boot\config guida lo stato. Con flag 0 il bootkit avvia la cifratura, cifra un file di verifica (\EFI\Microsoft\Boot\verify) e inizializza il counter. Con flag 1 espone la nota e accetta l’input della chiave a 32 caratteri; nelle varianti con Secure Boot bypass, la validazione passa per un hash basato su SPONGENT-256/256/16. Con flag 2 esegue la decrittazione, ripristina i bootloader legittimi da backup e riavvia. Questa coreografia punta a una recuperabilità sotto controllo dell’attaccante, coerente con la massimizzazione dell’incasso.
Segnali e indicatori da monitorare
I segnali includono scritture insolite nella EFI System Partition, creazione o modifica di \EFI\Microsoft\Boot\config, verify e counter, e BSOD anomali seguiti da variazioni nel percorso di avvio. I nomi file osservati in fase di drop comprendono notpetyanew.exe, core.dll, F20000.mbam_update.exe e cloak.dat. Le regole EDR devono correlare download da sorgenti non affidabili con eventi ETW di sistema, accessi a volumi ESP, e comparsa di schermate CHKDSK fuori contesto. Il SIEM deve ingestare process tree, modifiche al registry, socket e DNS atipici per tracciare fasi preparatorie spesso silenziose.
Superficie d’attacco in azienda e sistemi legacy
La superficie cresce su host con dbx non aggiornato, Secure Boot disabilitato o firmware end-of-life. Ambienti VDI, stazioni CAD, postazioni creative e server con volumi NTFS risentono in modo critico della cifratura MFT. In queste realtà, la minaccia opera prima dell’OS, eludendo gli strumenti che si attivano post-boot. La presenza di fallback di avvio non governati e di BIOS legacy abilitati agevola persistenza e riattivazioni al primo riavvio utile.
Mitigazioni prioritarie: firmware e identità
La prima difesa è l’aggiornamento della revocation list (dbx) e delle patch relative a CVE-2024-7344. Occorre forzare UEFI Secure Boot su tutti gli endpoint, verificare che bootmgfw.efi non appartenga a revisioni revocate, proteggere con password UEFI robuste e disabilitare boot esterni non necessari. Lato identità, MFA resistente al phishing (FIDO2/U2F) riduce l’impatto delle fasi di installazione non autorizzata. La telemetria va estesa a Event Tracing, proxy, DNS e driver storage per incrociare download, scritture ESP e riavvii anomali. I backup immutabili con test di ripristino sulla MFT devono entrare in routine.
Hardening del boot e controlli
La lezione di HybridPetya è netta: la catena di avvio va difesa come un perimetro critico. Il ripristino del modello di fiducia richiede dbx aggiornata, UEFI Secure Boot sempre attivo, monitoraggio della EFI System Partition e blocco di ogni percorso di boot non firmato. La combinazione di telemetria profonda, EDR con analisi comportamentale, NDR sulle dorsali e backup immutabili riduce la finestra d’impatto. Policy di installazione basate su allowlist e verifica firma neutralizzano i dropper. In presenza di indicatori compatibili con EFI/Diskcoder.A o Win32/Injector.AJBK, la procedura corretta è isolare l’host, acquisire immagini forensi del disco e della ESP, rimuovere la persistenza, ripristinare i bootloader da backup verificati e validare la MFT. I bootkit ibridi impongono disciplina nel patching del firmware, nella gestione chiavi e nei controlli di integrità ad ogni ciclo di manutenzione.
