themalwareguardian/cve-2026-79298Forschungs-Repository, das CVE-2026-79298 dokumentiert, eine unvollständige Behebung der UEFI-Secure-Boot-Umgehung im IA-32-Boot-Pfad von Howyar SysReturn, mit Reverse-Engineering- und PoC-Materialien.
Eine Schwachstelle wurde gepatcht. Eine Binärdatei wurde gesperrt. Doch nur die Hälfte der Architektur wurde behoben. Achtzehn Monate später trug der IA-32-Boot-Pfad noch immer denselben benutzerdefinierten PE-Loader, dieselbe umgangene Secure-Boot-Verifikation und denselben gesperrten Authenticode-Hash - und wurde bis Juli 2026 kommerziell in jeder Kopie von SysReturn NetCopy ausgeliefert. Dies ist CVE-2026-79298.
Ich bin ein Offensive-Security-Forscher mit Spezialisierung auf UEFI-Firmware-Exploitation, Bootkit-/Rootkit-Entwicklung und Schwachstellenforschung. Dies ist das Feld, dem ich meine Karriere widmen möchte, und es prägt alles, was ich veröffentliche.
Ich war Mitautor von UEFI Bootkits and Kernel-Mode Rootkits Development - einem wegweisenden Buch über die Entwicklung offensiver Implantate auf Firmware-Ebene. Ich habe Abyss entwickelt und veröffentlicht, ein vollständiges Windows-UEFI-Bootkit, sowie Antarctic, das erste öffentlich verfügbare UEFI-Bootkit-Framework für Linux. Beide sind Open-Source-Tools, die für Red-Team-Operatoren und Sicherheitsforscher entwickelt wurden, um reale Firmware-Bedrohungen zu verstehen, zu simulieren und sich gegen sie zu verteidigen. Daneben habe ich Benthic entwickelt, ein Windows-Kernel-Mode-Rootkit, und Behemoth, ein Tool zur automatisierten UEFI-Binäranalyse.
Offensive Tooling auf diesem Niveau zu entwickeln bedeutet, nicht nur zu verstehen, wie Bootkits funktionieren, sondern auch, wie sie installiert werden. Genau hier kommen UEFI-Schwachstellen ins Spiel. Jede Secure-Boot-Umgehung, jeder unsachgemäß signierte Bootloader, jeder benutzerdefinierte PE-Loader, der die Verifikation überspringt - das sind die Türen, durch die Malware auf Firmware-Ebene geht. Diese Schwachstellen zu erforschen und auszunutzen ist eine natürliche Erweiterung dieser Arbeit. Man kann kein realistisches offensives Tooling entwickeln, ohne die tatsächliche Angriffsfläche zu verstehen.
Dieser Forschungsweg - die Entwicklung von UEFI-Malware und anschließend das Studium der Schwachstellen, die ihren Einsatz ermöglichen - führte mich zu CVE-2024-7344 und letztlich zu den hier dokumentierten Erkenntnissen.
Im Januar 2025 veröffentlichten Martin Smolár und das ESET Research Team die Offenlegung von CVE-2024-7344 (Under the cloak of UEFI Secure Boot), einer Secure-Boot-Umgehung, die mehrere Wiederherstellungssoftware-Produkte betraf, darunter Howyar SysReturn. Die Schwachstelle wurde durch eine von Microsoft signierte UEFI-Anwendung verursacht, die ihren eigenen benutzerdefinierten PE-Loader (RxPE) implementierte und dabei die standardmäßigen LoadImage- und StartImage-Dienste vollständig umging. Anstatt sich auf die integrierte Secure-Boot-Verifikation der Firmware zu verlassen, parste und führte die Anwendung manuell eine unsignierte Nutzlast aus einer Datei namens cloak.dat aus, XOR-verschlüsselt mit einem Ein-Byte-Schlüssel, ohne Signaturprüfung, mit vollständigem Vertrauen auf Firmware-Ebene.
Microsoft sperrte die betroffenen Binärdateien im Januar-2025-Patch-Tuesday-Update. Die Advisory wurde veröffentlicht. Die Sicherheitsgemeinschaft wandte sich anderen Themen zu. Ich jedoch nicht.
Ich habe Jahre damit verbracht, UEFI-Schwachstellen zu studieren - nicht nur CVE-2024-7344, sondern die gesamte Landschaft von Secure-Boot-Umgehungen, benutzerdefinierten PE-Loadern und Designfehlern in signierten UEFI-Komponenten. Und es gibt ein Muster, das ich immer wieder gesehen habe: Dieselben Kategorien fehlerhafter Designentscheidungen tauchen über Hersteller und Jahre hinweg immer wieder auf. Eine Schwachstelle wird offengelegt, eine Binärdatei wird gesperrt, und Monate oder Jahre später erscheint ein ähnlicher Fehler - manchmal im selben Produkt, manchmal in einem anderen Produkt desselben Herstellers, manchmal in der Codebasis eines völlig anderen Herstellers, die zufällig dieselben architektonischen Annahmen teilt.
Dieses Muster veranlasste mich, eine Frage zu stellen, die die Sicherheitsbranche meiner Meinung nach nicht oft genug stellt:
Wie sieht ein Produkt nach einem CVE aus? Nicht während des Patch-Sturms - achtzehn Monate später, wenn niemand mehr hinsieht.
Ich beschloss, es herauszufinden. Und das Produkt, das ich wählte, war Howyar SysReturn.
Ich kontaktierte Howyar Technologies direkt und erhielt eine Evaluierungskopie von SysReturn für eine professionelle Beschaffungsbewertung - ein legitimer Kontext, der aus realer Arbeit zur Bewertung von Wiederherstellungssoftware für groß angelegte Bildungsumgebungen stammte.
Was ich in SysReturn v11.2.031 fand, veröffentlicht im April 2026 - mehr als fünfzehn Monate nach Microsofts Sperrung - bestätigte genau, was das Muster nahegelegt hatte.
Der x64-Boot-Pfad war behoben worden. Doch der IA-32-Boot-Pfad war nie saniert worden. Die Binärdatei BOOTia32.efi, die als Teil der SysReturn-NetCopy-Funktion verteilt wird, enthielt noch immer denselben benutzerdefinierten PE-Loader (RxPE), lud noch immer unsignierte Nutzlasten aus einer Datei namens cloak32.dat unter Verwendung desselben ALRM-Formats und derselben Ein-Byte-XOR-Verschlüsselung und trug noch immer exakt denselben Authenticode-Hash, den Microsoft im Januar 2025 gesperrt hatte.
Die Grundursache wurde in der IA-32-Architektur nie behoben. Was sich geändert hatte, war operativer Natur - der x64-Pfad war aktualisiert worden, und der unmittelbare Druck durch die Offenlegung war adressiert worden - doch die zugrunde liegende Architektur blieb in der 32-Bit-Komponente unangetastet und wurde kommerziell in jeder Kopie des Produkts ausgeliefert.
