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.
| Campo | Detalhe |
|---|---|
| ID CVE | CVE-2026-79298 |
| Tipo de Vulnerabilidade | Remediação Incompleta do Bypass do UEFI Secure Boot (CWE-693: Falha do Mecanismo de Proteção) |
| Fornecedor | Howyar Technologies Inc. |
| Produto | SysReturn (funcionalidade NetCopy) |
| Versões Afetadas | Versões anteriores à 11.3.034 (confirmado na v11.2.031 e v11.3.033) |
| Versão Corrigida | v11.3.034 (julho de 2026) |
| Componente Afetado | BOOTia32.efi (aplicação UEFI IA-32 assinada pela Microsoft), carregador PE personalizado RxPE (UEFI\RxPE.cpp), cloak32.dat (payload encriptado com XOR no formato ALRM) |
| Tipo de Ataque | Local |
| Impacto | Execução de código arbitrário, escalada de privilégios |
| Vetor de Ataque | Um atacante com acesso de escrita à EFI System Partition (Administrador local no Windows, root no Linux) pode colocar BOOTia32.efi e um cloak32.dat manipulado na ESP. Após o reinício, o binário executa o payload não assinado através do RxPE, contornando por completo a verificação do Secure Boot. Requer um sistema UEFI IA-32 com Secure Boot ativado que confie na Microsoft Corporation UEFI CA 2011 e que não tenha aplicado a atualização de revogação dbx de janeiro de 2025. |
| Reconhecimento do Fornecedor | Confirmado. O fornecedor reconheceu durante a divulgação coordenada que o caminho de arranque IA-32 nunca foi incluído na remediação original do CVE-2024-7344. |
O processo de divulgação coordenada desta vulnerabilidade foi conduzido diretamente com a Howyar Technologies ao longo de um período de aproximadamente dois meses.
Resumo cronológico:
O bypass do Secure Boot foi reproduzido dinamicamente usando QEMU/OVMF IA-32 com Secure Boot ativado. Os artefactos completos de reprodução, a documentação de engenharia reversa, a verificação do hash Authenticode, os materiais de prova de conceito e todos os emails trocados durante o processo de coordenação estão incluídos no repositório principal de investigação.
Este identificador CVE foi atribuído depois de a investigação já ter sido conduzida, documentada e partilhada através de dois repositórios dedicados. Esses repositórios contêm toda a profundidade técnica - os binários vulneráveis, a engenharia reversa, a correspondência com o fornecedor, as ferramentas de prova de conceito e os materiais de reprodução. Este repositório serve como ponto de entrada indexado ao CVE que liga tudo.
➡️ UEFI-Security-Research-Howyar-SysReturn-NetCopy
Este é o repositório principal de investigação. Contém:
BOOTia32.efi, cloak32.dat e componentes relacionados)BOOTia32.efi: o formato do payload ALRM, a desencriptação XOR, o carregador PE personalizado RxPE, a verificação do hash Authenticode em relação ao binário revogado e a análise do que foi alterado versus o que ficou intactodecode_cloak.py, authenticode_hash.py, create_cloak.py)Este é o repositório complementar que documenta a vulnerabilidade original da qual o CVE-2026-79298 deriva. Contém:
Está a trabalhar em algo semelhante? A investigar UEFI, segurança do kernel, exploração ou outro tópico de segurança interessante? Se precisar de ajuda a desenvolver um exploit, a explorar uma técnica ou apenas quiser trocar ideias, não hesite em contactar-me. Estou sempre aberto a discutir investigação, ajudar no que puder e colaborar em projetos interessantes.
Sinta-se à vontade para me contactar no LinkedIn.