themalwareguardian/cve-2026-79298Repositório de pesquisa que documenta o CVE-2026-79298, uma remediação incompleta de bypass do UEFI Secure Boot no caminho de boot IA-32 do Howyar SysReturn, com materiais de engenharia reversa e PoC.
Uma vulnerabilidade foi corrigida. Um binário foi revogado. Mas apenas metade da arquitetura foi corrigida. Dezoito meses depois, o caminho de arranque IA-32 ainda carregava o mesmo carregador PE personalizado, a mesma verificação de Secure Boot contornada e o mesmo hash Authenticode revogado - sendo distribuído comercialmente em todas as cópias do SysReturn NetCopy até julho de 2026. Este é o CVE-2026-79298.
Sou um investigador de segurança ofensiva especializado em exploração de firmware UEFI, desenvolvimento de bootkits/rootkits e pesquisa de vulnerabilidades. Este é o campo ao qual decidi dedicar a minha carreira, e ele molda tudo o que publico.
Sou coautor de UEFI Bootkits and Kernel-Mode Rootkits Development - um livro pioneiro sobre o desenvolvimento de implantes ofensivos ao nível do firmware. Construí e lancei o Abyss, um bootkit UEFI completo para Windows, e o Antarctic, o primeiro framework de bootkit UEFI disponível publicamente para Linux. Ambos são ferramentas de código aberto concebidas para operadores de red team e investigadores de segurança compreenderem, simularem e se defenderem contra ameaças de firmware do mundo real. A par deles, desenvolvi o Benthic, um rootkit em modo kernel para Windows, e o Behemoth, uma ferramenta para análise automatizada de binários UEFI.
Construir ferramentas ofensivas a este nível significa compreender não apenas como os bootkits funcionam, mas como são instalados. É aí que entram as vulnerabilidades UEFI. Cada bypass do Secure Boot, cada bootloader indevidamente assinado, cada carregador PE personalizado que ignora a verificação - estas são as portas por onde o malware ao nível do firmware passa. Investigar e explorar essas vulnerabilidades é uma extensão natural do trabalho. Não é possível construir ferramentas ofensivas realistas sem compreender a superfície de ataque real.
Esse percurso de investigação - desenvolver malware UEFI e depois estudar as vulnerabilidades que permitem a sua implementação - foi o que me levou ao CVE-2024-7344 e, em última análise, às descobertas aqui documentadas.
Em janeiro de 2025, Martin Smolár e a Equipa de Investigação da ESET publicaram a divulgação do CVE-2024-7344 (Under the cloak of UEFI Secure Boot), um bypass do Secure Boot que afetava vários produtos de software de recuperação, incluindo o Howyar SysReturn. A vulnerabilidade era causada por uma aplicação UEFI assinada pela Microsoft que implementava o seu próprio carregador PE personalizado (RxPE), contornando por completo os serviços padrão LoadImage e StartImage. Em vez de confiar na verificação de Secure Boot incorporada no firmware, a aplicação analisava e executava manualmente um payload não assinado a partir de um ficheiro chamado cloak.dat, encriptado com XOR com uma chave de um único byte, sem verificação de assinatura, com total confiança ao nível do firmware.
A Microsoft revogou os binários afetados na atualização Patch Tuesday de janeiro de 2025. O aviso foi publicado. A comunidade de segurança seguiu em frente. Mas eu não.
Passei anos a estudar vulnerabilidades UEFI - não apenas o CVE-2024-7344, mas todo o panorama de bypasses do Secure Boot, carregadores PE personalizados e falhas ao nível do design em componentes UEFI assinados. E há um padrão que tenho visto repetidamente: as mesmas categorias de decisões de design incorretas ressurgem entre fornecedores e ao longo dos anos. Uma vulnerabilidade é divulgada, um binário é revogado e, meses ou anos depois, surge uma falha semelhante - por vezes no mesmo produto, por vezes num produto diferente do mesmo fornecedor, por vezes no código de um fornecedor completamente diferente que, por acaso, partilha os mesmos pressupostos arquiteturais.
Esse padrão levou-me a fazer uma pergunta que penso que a indústria de segurança não faz com frequência suficiente:
Como é um produto depois de um CVE? Não durante a correria da correção - dezoito meses depois, quando já ninguém está a prestar atenção.
Decidi descobrir. E o produto que escolhi foi o Howyar SysReturn.
Contactei diretamente a Howyar Technologies e obtive uma cópia de avaliação do SysReturn para uma avaliação profissional de aquisição - um contexto legítimo que teve origem em trabalho real de avaliação de software de recuperação para implementações educativas em larga escala.
O que encontrei no SysReturn v11.2.031, lançado em abril de 2026 - mais de quinze meses após a revogação da Microsoft - confirmou exatamente o que o padrão sugeria.
O caminho de arranque x64 tinha sido tratado. Mas o caminho de arranque IA-32 nunca tinha sido remediado. O binário BOOTia32.efi, distribuído como parte da funcionalidade SysReturn NetCopy, ainda continha o mesmo carregador PE personalizado (RxPE), ainda carregava payloads não assinados a partir de um ficheiro chamado cloak32.dat usando o mesmo formato ALRM e encriptação XOR de um único byte, e ainda continha exatamente o mesmo hash Authenticode que a Microsoft tinha revogado em janeiro de 2025.
A causa raiz nunca foi corrigida na arquitetura IA-32. O que tinha mudado era operacional - o caminho x64 tinha sido atualizado e a pressão imediata da divulgação tinha sido tratada - mas a arquitetura subjacente persistia intacta no componente de 32 bits, sendo distribuída comercialmente em todas as cópias do produto.
