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.
