themalwareguardian/cve-2026-79298Repository di ricerca che documenta CVE-2026-79298, una remediation incompleta del bypass di UEFI Secure Boot nel percorso di avvio IA-32 di Howyar SysReturn, con materiali di reverse engineering e PoC.
Una vulnerabilità è stata corretta. Un binario è stato revocato. Ma solo metà dell'architettura è stata sistemata. Diciotto mesi dopo, il percorso di avvio IA-32 portava ancora lo stesso loader PE personalizzato, la stessa verifica di Secure Boot aggirata e lo stesso hash Authenticode revocato - distribuito commercialmente in ogni copia di SysReturn NetCopy fino a luglio 2026. Questa è CVE-2026-79298.
Sono un ricercatore di sicurezza offensiva specializzato nello sfruttamento del firmware UEFI, nello sviluppo di bootkit/rootkit e nella ricerca sulle vulnerabilità. Questo è il campo a cui ho scelto di dedicare la mia carriera, e plasma tutto ciò che pubblico.
Sono coautore di UEFI Bootkits and Kernel-Mode Rootkits Development - un libro pionieristico sullo sviluppo di impianti offensivi a livello di firmware. Ho creato e rilasciato Abyss, un bootkit UEFI completo per Windows, e Antarctic, il primo framework bootkit UEFI disponibile pubblicamente per Linux. Entrambi sono strumenti open-source progettati per operatori di red team e ricercatori di sicurezza per comprendere, simulare e difendersi da minacce firmware del mondo reale. Accanto a questi, ho sviluppato Benthic, un rootkit kernel-mode per Windows, e Behemoth, uno strumento per l'analisi automatizzata di binari UEFI.
Costruire strumenti offensivi a questo livello significa comprendere non solo come funzionano i bootkit, ma anche come vengono installati. È qui che entrano in gioco le vulnerabilità UEFI. Ogni bypass di Secure Boot, ogni bootloader firmato in modo improprio, ogni loader PE personalizzato che salta la verifica - queste sono le porte attraverso cui passa il malware a livello di firmware. Ricercare e sfruttare tali vulnerabilità è un'estensione naturale del lavoro. Non si possono costruire strumenti offensivi realistici senza comprendere la reale superficie di attacco.
Quel percorso di ricerca - sviluppare malware UEFI, poi studiare le vulnerabilità che ne consentono il deployment - è ciò che mi ha portato a CVE-2024-7344 e infine ai risultati documentati qui.
A gennaio 2025, Martin Smolár e l'ESET Research Team hanno pubblicato la divulgazione di CVE-2024-7344 (Under the cloak of UEFI Secure Boot), un bypass di Secure Boot che colpiva molteplici prodotti software di ripristino, incluso Howyar SysReturn. La vulnerabilità era causata da un'applicazione UEFI firmata da Microsoft che implementava il proprio loader PE personalizzato (RxPE), aggirando completamente i servizi standard LoadImage e StartImage. Invece di affidarsi alla verifica Secure Boot integrata nel firmware, l'applicazione analizzava ed eseguiva manualmente un payload non firmato da un file chiamato cloak.dat, cifrato con XOR a chiave singolo byte, nessun controllo di firma, piena fiducia a livello di firmware.
Microsoft ha revocato i binari interessati nell'aggiornamento Patch Tuesday di gennaio 2025. L'advisory è stato pubblicato. La comunità di sicurezza è andata avanti. Ma io no.
Ho passato anni a studiare le vulnerabilità UEFI - non solo CVE-2024-7344, ma l'intero panorama dei bypass di Secure Boot, dei loader PE personalizzati e dei difetti a livello di progettazione nei componenti UEFI firmati. E c'è uno schema che ho visto ripetersi più e più volte: le stesse categorie di decisioni di progettazione errate riemergono tra vendor e tra anni. Una vulnerabilità viene divulgata, un binario viene revocato, e mesi o anni dopo appare un difetto simile - a volte nello stesso prodotto, a volte in un prodotto diverso dello stesso vendor, a volte nel codebase di un vendor completamente diverso che condivide le stesse assunzioni architetturali.
Quello schema mi ha spinto a pormi una domanda che credo l'industria della sicurezza non ponga abbastanza spesso:
Come appare un prodotto dopo una CVE? Non durante la corsa alla patch - diciotto mesi dopo, quando più nessuno guarda.
Ho deciso di scoprirlo. E il prodotto che ho scelto è stato Howyar SysReturn.
Ho contattato direttamente Howyar Technologies e ho ottenuto una copia di valutazione di SysReturn per una valutazione professionale di procurement - un contesto legittimo che è nato da lavoro reale di valutazione di software di ripristino per deployment educativi su larga scala.
Ciò che ho trovato in SysReturn v11.2.031, rilasciato in aprile 2026 - più di quindici mesi dopo la revoca di Microsoft - ha confermato esattamente ciò che lo schema aveva suggerito.
Il percorso di avvio x64 era stato sistemato. Ma il percorso di avvio IA-32 non era mai stato remediato. Il binario BOOTia32.efi, distribuito come parte della funzionalità SysReturn NetCopy, conteneva ancora lo stesso loader PE personalizzato (RxPE), caricava ancora payload non firmati da un file chiamato cloak32.dat usando lo stesso formato ALRM e la stessa cifratura XOR a chiave singolo byte, e portava ancora lo stesso identico hash Authenticode che Microsoft aveva revocato a gennaio 2025.
La causa principale non è mai stata corretta nell'architettura IA-32. Ciò che era cambiato era operativo - il percorso x64 era stato aggiornato, e la pressione immediata derivante dalla divulgazione era stata affrontata - ma l'architettura sottostante persisteva intatta nel componente a 32 bit, distribuito commercialmente in ogni copia del prodotto.
| Campo | Dettaglio |
|---|---|
| CVE ID | CVE-2026-79298 |
| Tipo di vulnerabilità | Remediatione incompleta del bypass di UEFI Secure Boot (CWE-693: Protection Mechanism Failure) |
| Vendor | Howyar Technologies Inc. |
| Prodotto | SysReturn (funzionalità NetCopy) |
| Versioni interessate | Versioni precedenti alla 11.3.034 (confermato in v11.2.031 e v11.3.033) |
| Versione corretta | v11.3.034 (luglio 2026) |
| Componente interessato | BOOTia32.efi (applicazione UEFI IA-32 firmata da Microsoft), loader PE personalizzato RxPE (UEFI\RxPE.cpp), cloak32.dat (payload cifrato con XOR in formato ALRM) |
| Tipo di attacco | Locale |
| Impatto | Esecuzione di codice arbitrario, escalation di privilegi |
| Vettore di attacco | Un attaccante con accesso in scrittura alla EFI System Partition (Administrator locale su Windows, root su Linux) può collocare BOOTia32.efi e un cloak32.dat appositamente creato sulla ESP. Al riavvio, il binario esegue il payload non firmato tramite RxPE, aggirando completamente la verifica di Secure Boot. Richiede un sistema UEFI IA-32 con Secure Boot abilitato che si fida della Microsoft Corporation UEFI CA 2011 e non ha applicato l'aggiornamento di revoca dbx di gennaio 2025. |
| Riconoscimento del vendor | Confermato. Il vendor ha riconosciuto durante la divulgazione coordinata che il percorso di avvio IA-32 non è mai stato incluso nella remediation originale di CVE-2024-7344. |
Il processo di divulgazione coordinata per questa vulnerabilità è stato condotto direttamente con Howyar Technologies nell'arco di circa due mesi.
Riepilogo della timeline:
Il bypass di Secure Boot è stato riprodotto dinamicamente usando QEMU/OVMF IA-32 con Secure Boot abilitato. Tutti gli artefatti di riproduzione, la documentazione di reverse engineering, la verifica dell'hash Authenticode, i materiali proof-of-concept e ogni email scambiata durante il processo di coordinamento sono inclusi nel repository di ricerca principale.
Questo identificativo CVE è stato assegnato dopo che la ricerca era già stata condotta, documentata e condivisa attraverso due repository dedicati. Quei repository contengono la piena profondità tecnica - i binari vulnerabili, il reverse engineering, la corrispondenza con il vendor, gli strumenti proof-of-concept e i materiali di riproduzione. Questo repository funge da punto di ingresso indicizzato per CVE che collega tutto insieme.
➡️ UEFI-Security-Research-Howyar-SysReturn-NetCopy
Questo è il repository di ricerca principale. Contiene:
BOOTia32.efi, cloak32.dat e componenti correlati)BOOTia32.efi: il formato del payload ALRM, la decifratura XOR, il loader PE personalizzato RxPE, la verifica dell'hash Authenticode rispetto al binario revocato e l'analisi di ciò che è stato modificato rispetto a ciò che è rimasto intattodecode_cloak.py, authenticode_hash.py, create_cloak.py)Questo è il repository complementare che documenta la vulnerabilità originale da cui deriva CVE-2026-79298. Contiene:
Stai lavorando a qualcosa di simile? Fai ricerca su UEFI, sicurezza del kernel, exploitation o un altro interessante tema di sicurezza? Se hai bisogno di una mano per sviluppare un exploit, esplorare una tecnica, o semplicemente vuoi scambiare idee, non esitare a contattarmi. Sono sempre aperto a discutere di ricerca, aiutare dove posso e collaborare su progetti interessanti.
Sentiti libero di contattarmi su LinkedIn.