Repositorio de investigación que documenta CVE-2026-79298, una remediación incompleta de omisión de UEFI Secure Boot en la ruta de arranque IA-32 de Howyar SysReturn, con materiales de ingeniería inversa y PoC.
Se parcheó una vulnerabilidad. Se revocó un binario. Pero solo se corrigió la mitad de la arquitectura. Dieciocho meses después, la ruta de arranque IA-32 seguía llevando el mismo cargador PE personalizado, la misma verificación de Secure Boot eludida y el mismo hash Authenticode revocado - distribuyéndose comercialmente en cada copia de SysReturn NetCopy hasta julio de 2026. Este es CVE-2026-79298.
Soy un investigador de seguridad ofensiva especializado en explotación de firmware UEFI, desarrollo de bootkits/rootkits e investigación de vulnerabilidades. Este es el campo al que he decidido dedicar mi carrera, y da forma a todo lo que publico.
Fui coautor de UEFI Bootkits and Kernel-Mode Rootkits Development - un libro pionero sobre el desarrollo de implantes ofensivos a nivel de firmware. Construí y publiqué Abyss, un bootkit UEFI completo para Windows, y Antarctic, el primer framework de bootkit UEFI disponible públicamente para Linux. Ambas son herramientas de código abierto diseñadas para que operadores de red team e investigadores de seguridad comprendan, simulen y se defiendan contra amenazas de firmware del mundo real. Junto a ellas, desarrollé Benthic, un rootkit en modo kernel para Windows, y Behemoth, una herramienta para el análisis automatizado de binarios UEFI.
Construir herramientas ofensivas a este nivel significa entender no solo cómo funcionan los bootkits, sino cómo se instalan. Ahí es donde entran las vulnerabilidades UEFI. Cada bypass de Secure Boot, cada bootloader firmado incorrectamente, cada cargador PE personalizado que omite la verificación - esas son las puertas por las que entra el malware a nivel de firmware. Investigar y explotar esas vulnerabilidades es una extensión natural del trabajo. No se pueden construir herramientas ofensivas realistas sin entender la superficie de ataque real.
Ese camino de investigación - desarrollar malware UEFI, y luego estudiar las vulnerabilidades que permiten su despliegue - es lo que me llevó a CVE-2024-7344 y, en última instancia, a los hallazgos documentados aquí.
En enero de 2025, Martin Smolár y el Equipo de Investigación de ESET publicaron la divulgación de CVE-2024-7344 (Under the cloak of UEFI Secure Boot), un bypass de Secure Boot que afectaba a múltiples productos de software de recuperación, incluido Howyar SysReturn. La vulnerabilidad fue causada por una aplicación UEFI firmada por Microsoft que implementaba su propio cargador PE personalizado (RxPE), eludiendo por completo los servicios estándar LoadImage y StartImage. En lugar de confiar en la verificación de Secure Boot integrada en el firmware, la aplicación analizaba y ejecutaba manualmente un payload sin firmar desde un archivo llamado cloak.dat, cifrado con XOR mediante una clave de un solo byte, sin verificación de firma, con total confianza a nivel de firmware.
Microsoft revocó los binarios afectados en la actualización del Patch Tuesday de enero de 2025. Se publicó el aviso. La comunidad de seguridad siguió adelante. Pero yo no.
He pasado años estudiando vulnerabilidades UEFI - no solo CVE-2024-7344, sino todo el panorama de bypasses de Secure Boot, cargadores PE personalizados y fallos de diseño en componentes UEFI firmados. Y hay un patrón que he visto una y otra vez: las mismas categorías de decisiones de diseño incorrectas reaparecen entre proveedores y a lo largo de los años. Se divulga una vulnerabilidad, se revoca un binario, y meses o años después aparece un fallo similar - a veces en el mismo producto, a veces en un producto diferente del mismo proveedor, a veces en el código de un proveedor completamente distinto que resulta compartir las mismas suposiciones arquitectónicas.
Ese patrón me hizo plantear una pregunta que creo que la industria de la seguridad no hace con la suficiente frecuencia:
¿Cómo se ve un producto después de un CVE? No durante la carrera por parchear - dieciocho meses después, cuando ya nadie está mirando.
Decidí averiguarlo. Y el producto que elegí fue Howyar SysReturn.
Contacté directamente con Howyar Technologies y obtuve una copia de evaluación de SysReturn para una evaluación profesional de adquisición - un contexto legítimo que se originó en trabajo real de evaluación de software de recuperación para despliegues educativos a gran escala.
Lo que encontré en SysReturn v11.2.031, publicado en abril de 2026 - más de quince meses después de la revocación de Microsoft - confirmó exactamente lo que el patrón había sugerido.
La ruta de arranque x64 había sido abordada. Pero la ruta de arranque IA-32 nunca había sido remediada. El binario BOOTia32.efi, distribuido como parte de la función SysReturn NetCopy, todavía contenía el mismo cargador PE personalizado (RxPE), todavía cargaba payloads sin firmar desde un archivo llamado cloak32.dat usando el mismo formato ALRM y cifrado XOR de un solo byte, y todavía llevaba el mismo hash Authenticode exacto que Microsoft había revocado en enero de 2025.
La causa raíz nunca se corrigió en la arquitectura IA-32. Lo que había cambiado era operativo - la ruta x64 se había actualizado, y la presión inmediata de la divulgación había sido atendida - pero la arquitectura subyacente persistía intacta en el componente de 32 bits, distribuyéndose comercialmente en cada copia del producto.
| Campo | Detalle |
|---|---|
| ID CVE | CVE-2026-79298 |
| Tipo de Vulnerabilidad | Remediación Incompleta del Bypass de UEFI Secure Boot (CWE-693: Fallo del Mecanismo de Protección) |
| Proveedor | Howyar Technologies Inc. |
| Producto | SysReturn (función NetCopy) |
| Versiones Afectadas | Versiones anteriores a 11.3.034 (confirmado en v11.2.031 y v11.3.033) |
| Versión Corregida | v11.3.034 (julio de 2026) |
| Componente Afectado | BOOTia32.efi (aplicación UEFI IA-32 firmada por Microsoft), cargador PE personalizado RxPE (UEFI\RxPE.cpp), cloak32.dat (payload cifrado con XOR en formato ALRM) |
| Tipo de Ataque | Local |
| Impacto | Ejecución de código arbitrario, escalada de privilegios |
| Vector de Ataque | Un atacante con acceso de escritura a la Partición del Sistema EFI (Administrador local en Windows, root en Linux) puede colocar BOOTia32.efi y un cloak32.dat manipulado en la ESP. Al reiniciar, el binario ejecuta el payload sin firmar mediante RxPE, eludiendo por completo la verificación de Secure Boot. Requiere un sistema UEFI IA-32 con Secure Boot habilitado que confíe en Microsoft Corporation UEFI CA 2011 y que no haya aplicado la actualización de revocación dbx de enero de 2025. |
| Reconocimiento del Proveedor | Confirmado. El proveedor reconoció durante la divulgación coordinada que la ruta de arranque IA-32 nunca fue incluida en la remediación original de CVE-2024-7344. |
El proceso de divulgación coordinada de esta vulnerabilidad se llevó a cabo directamente con Howyar Technologies durante un período de aproximadamente dos meses.
Resumen cronológico:
El bypass de Secure Boot se reprodujo dinámicamente usando QEMU/OVMF IA-32 con Secure Boot habilitado. Los artefactos completos de reproducción, la documentación de ingeniería inversa, la verificación del hash Authenticode, los materiales de prueba de concepto y cada correo electrónico intercambiado durante el proceso de coordinación están incluidos en el repositorio principal de investigación.
Este identificador CVE fue asignado después de que la investigación ya se hubiera realizado, documentado y compartido a través de dos repositorios dedicados. Esos repositorios contienen toda la profundidad técnica - los binarios vulnerables, la ingeniería inversa, la correspondencia con el proveedor, las herramientas de prueba de concepto y los materiales de reproducción. Este repositorio sirve como el punto de entrada indexado por CVE que conecta todo.
➡️ UEFI-Security-Research-Howyar-SysReturn-NetCopy
Este es el repositorio principal de investigación. Contiene:
BOOTia32.efi, cloak32.dat y componentes relacionados)BOOTia32.efi: el formato de payload ALRM, el descifrado XOR, el cargador PE personalizado RxPE, la verificación del hash Authenticode contra el binario revocado, y el análisis de lo que se cambió frente a lo que se dejó intactodecode_cloak.py, authenticode_hash.py, create_cloak.py)Este es el repositorio complementario que documenta la vulnerabilidad original de la que deriva CVE-2026-79298. Contiene:
¿Trabajas en algo similar? ¿Investigas UEFI, seguridad del kernel, explotación u otro tema de seguridad interesante? Si necesitas ayuda para desarrollar un exploit, explorar una técnica, o simplemente quieres intercambiar ideas, no dudes en contactarme. Siempre estoy abierto a discutir investigaciones, ayudar en lo que pueda y colaborar en proyectos interesantes.
No dudes en contactarme en LinkedIn.