Ransomware HybridPetya hebelt UEFI Secure Boot aus

ESET Research hat HybridPetya auf der Sample-Sharing-Plattform VirusTotal entdeckt. Es handelt sich um einen Nachahmer der berüchtigten Petya/NotPetya-Malware, der zusätzlich die Fähigkeit besitzt, UEFI-basierte Systeme zu kompromittieren und CVE-2024-7344 als Waffe einzusetzen, um UEFI Secure Boot auf veralteten Systemen zu umgehen.

Die wichtigsten Punkte dieses Blogposts:

• Neue Ransomware-Samples, die wir HybridPetya genannt haben und die der berüchtigten Petya/NotPetya-Malware ähneln, wurden im Februar 2025 auf VirusTotal hochgeladen.
• HybridPetya verschlüsselt die Master File Table, die wichtige Metadaten über alle Dateien auf NTFS-formatierten Partitionen enthält.
• Im Gegensatz zum ursprünglichen Petya/NotPetya kann HybridPetya moderne UEFI-basierte Systeme kompromittieren, indem er eine bösartige EFI-Anwendung auf der EFI-Systempartition installiert.
• Eine der analysierten HybridPetya-Varianten nutzt CVE-2024-7344 aus, um UEFI Secure Boot auf veralteten Systemen zu umgehen, indem sie eine speziell gestaltete cloak. dat-Datei nutzt.
• Die ESET-Telemetrie zeigt noch keine Anzeichen dafür, dass HybridPetya in freier Wildbahn eingesetzt wird; diese Malware weist nicht die aggressive Netzwerkausbreitung auf, die beim ursprünglichen NotPetya zu beobachten war.

Überblick

Ende Juli 2025 stießen wir auf verdächtige Ransomware-Samples, die aus Polen auf VirusTotal hochgeladen wurden und verschiedene Dateinamen trugen, darunter notpetyanew.exe und andere ähnliche, was auf eine Verbindung mit der berüchtigten destruktiven Malware hindeutet, die die Ukraine und viele andere Länder im Jahr 2017 heimsuchte. Der NotPetya-Angriff gilt als der zerstörerischste Cyberangriff der Geschichte mit einem Gesamtschaden von mehr als 10 Milliarden US-Dollar. Trotz der Ähnlichkeit von NotPetya mit der Ransomware Petya, die erstmals im März 2016 entdeckt wurde, bestand der Zweck von NotPetya in reiner Zerstörung, da die Wiederherstellung des Verschlüsselungsschlüssels aus dem persönlichen Installationsschlüssel des Opfers nicht möglich war. Aufgrund der gemeinsamen Merkmale der aktuell entdeckten Muster mit Petya und NotPetya haben wir die neue Entdeckung HybridPetya genannt.

Obwohl die ESET-Telemetrie keine aktive Nutzung von HybridPetya in freier Wildbahn zeigt, erregte ein wichtiges Detail in diesen Beispielen dennoch unsere Aufmerksamkeit: Anders als die ursprüngliche NotPetya (und auch die Petya-Ransomware) ist HybridPetya auch in der Lage, moderne UEFI-basierte Systeme zu kompromittieren, indem eine bösartige EFI-Anwendung auf der EFI-Systempartition installiert wird. Die installierte UEFI-Anwendung ist dann für die Verschlüsselung der NTFS-bezogenen Master File Table (MFT)-Datei verantwortlich - eine wichtige Metadaten-Datei, die Informationen über alle Dateien auf der NTFS-formatierten Partition enthält.

Nach weiteren Nachforschungen entdeckten wir auf VirusTotal etwas noch Interessanteres: ein Archiv, das den gesamten Inhalt der EFI-Systempartition enthält, einschließlich einer sehr ähnlichen HybridPetya-UEFI-Anwendung, diesmal jedoch gebündelt in einer speziell formatierten cloak. dat-Datei, die für CVE-2024-7344 anfällig ist - die UEFI-Secure-Boot-Umgehungsschwachstelle -, die unser Team Anfang 2025 aufdeckte.

Interessanterweise erlaubt es der Algorithmus, der für die Generierung des persönlichen Installationsschlüssels des Opfers verwendet wird, im Gegensatz zum ursprünglichen NotPetya dem Malware-Betreiber, den Entschlüsselungsschlüssel aus den persönlichen Installationsschlüsseln des Opfers zu rekonstruieren, obwohl die Dateinamen auf VirusTotal und das Format der Lösegeldforderung in den aktuellen Proben darauf hindeuten, dass sie mit NotPetya verwandt sein könnten. Daher kann HybridPetya als reguläre Ransomware (ähnlich wie Petya) eingesetzt werden, anstatt wie NotPetya ausschließlich destruktiv zu sein.

Interessanterweise veröffentlichte @hasherezade am^9. September 2025 einen Beitrag über die Existenz eines UEFI-Petya-PoCs mit einem Video, das die Ausführung der Malware mit aktiviertem UEFI Secure Boot zeigt. Obwohl sich das Beispiel aus dem Video offensichtlich von dem in diesem Blogpost vorgestellten unterscheidet (es zeigt den typischen Petya-ASCII-Kunstschädel, der in den von uns entdeckten Beispielen nicht vorhanden ist), vermuten wir, dass es einen Zusammenhang zwischen den beiden Fällen geben könnte und dass HybridPetya auch nur ein von einem Sicherheitsforscher oder einem unbekannten Bedrohungsakteur entwickeltes Proof of Concept sein könnte.

In diesem Blogpost konzentrieren wir uns auf die technische Analyse von HybridPetya.

Technische Analyse von HybridPetya

In diesem Abschnitt bieten wir eine technische Analyse der Komponenten von HybridPetya: das Bootkit und sein Installationsprogramm. Außerdem analysieren wir separat eine Version von HybridPetya, die in der Lage ist, UEFI Secure Boot zu umgehen, indem sie CVE-2024-7344 ausnutzt. Beachten Sie, dass HybridPetya sowohl Legacy- als auch UEFI-basierte Systeme unterstützt - in diesem Blogpost konzentrieren wir uns auf den UEFI-Teil.

Interessanterweise scheint der Code, der für die Generierung der persönlichen Installationsschlüssel der Opfer verantwortlich ist, von dem RedPetyaOpenSSL PoC inspiriert zu sein. Uns ist mindestens ein weiterer UEFI-kompatibler PoC bekannt, der in Rust geschrieben wurde und den Namen NotPetyaAgain trägt; dieser Code hat jedoch nichts mit HybridPetya zu tun.

UEFI-Bootkit

Wir haben zwei verschiedene Versionen der UEFI-Bootkit-Komponente erhalten, die beide sehr ähnlich sind, aber gewisse Unterschiede aufweisen. Bei der Ausführung lädt das Bootkit zunächst seine Konfiguration aus der Datei \EFI\Microsoft\Boot\config und prüft das Verschlüsselungsflag, das den aktuellen Verschlüsselungsstatus angibt - wie bei den ursprünglichen Petya/NotPetya-Beispielen kann das Verschlüsselungsflag einen der folgenden Werte annehmen:

• 0 - bereit zur Verschlüsselung,
• 1 - bereits verschlüsselt, oder
• 2 - Lösegeld bezahlt, Datenträger entschlüsselt.

Die Ausführung wird auf der Grundlage des Verschlüsselungsstatus-Flags fortgesetzt, wie in Abbildung 1 dargestellt.

Festplattenverschlüsselung

Wenn der Wert des Verschlüsselungskennzeichens 0 ist, extrahiert das Bootkit den 32 Byte langen Salsa20-Verschlüsselungsschlüssel und die 8 Byte lange Nonce aus den Konfigurationsdaten und schreibt anschließend die Konfigurationsdatei neu, wobei der Verschlüsselungsschlüssel auf Null und das Verschlüsselungskennzeichen auf 1 gesetzt wird. Es fährt mit der Verschlüsselung der Datei \EFI\Microsoft\Boot\verify mit dem Salsa20-Verschlüsselungsalgorithmus unter Verwendung des Schlüssels und der Nonce aus der Konfiguration fort. Bevor es dann zu seiner Hauptfunktion - der Festplattenverschlüsselung - übergeht, erstellt es die Datei \EFI\Microsoft\Boot\counter auf der EFI-Systempartition; der Zweck dieser Datei wird später erläutert.

Der Festplattenverschlüsselungsprozess beginnt mit der Identifizierung aller NTFS-formatierten Partitionen. Wie in Abbildung 2 dargestellt, holt das Beispiel die Liste der Handles für angeschlossene Speichergeräte ein, identifiziert die einzelnen Partitionen, indem es prüft, ob EFI_BLOCK_IO_MEDIA->LogicalPartition TRUE ist, und überprüft schließlich, ob die Partition NTFS-formatiert ist, indem es die ersten vier Bytes der Daten im Sektor der ersten Partition mit der NTFS-Signatur NTFS vergleicht.

Sobald die NTFS-Partitionen identifiziert wurden, fährt das Bootkit mit der Verschlüsselung der Master File Table (MFT)-Datei fort, der wichtigen Metadaten-Datei, die Informationen über andere Dateien und den Ort ihrer Daten auf der NTFS-formatierten Partition enthält. Wie in Abbildung 3 dargestellt, schreibt das Bootkit während der Verschlüsselung den Inhalt der Datei \EFI\Microsoft\Boot\counter mit der Anzahl der bereits verschlüsselten Festplattencluster neu und aktualisiert die gefälschte CHKDSK-Meldung, die auf dem Bildschirm des Opfers angezeigt wird (siehe Abbildung 4), mit den Informationen über den aktuellen Verschlüsselungsstatus (obwohl das Opfer aufgrund der Meldung glauben könnte, dass die Festplatte auf Fehler geprüft und nicht verschlüsselt wird).

Wenn die Verschlüsselung abgeschlossen ist, startet das Bootkit den Rechner neu.

Entschlüsselung der Festplatte

Wenn das Bootkit feststellt, dass die Festplatte bereits verschlüsselt ist, d. h., dass der Wert des Verschlüsselungsflags in der Konfigurationsdatei 1 ist, zeigt es die in Abbildung 5 oder Abbildung 6 (je nach Bootkit-Version) dargestellte Lösegeldforderung an und fordert das Opfer auf, den Entschlüsselungsschlüssel einzugeben. Beachten Sie, dass die HybridPetya-Lösegeldforderung zwar dasselbe Format wie die ursprüngliche NotPetya-Lösegeldforderung hat (siehe Abbildung 7), der Lösegeldbetrag, die Bitcoin-Adresse und die E-Mail-Adresse des Betreibers jedoch unterschiedlich sind. Außerdem verwendet die Version, die mit der UEFI Secure Boot-Umgehung bereitgestellt wird, eine andere Kontakt-E-Mail-Adresse(wowsmith999999@proton[.]me) als die Version, die von den erhaltenen Installationsprogrammen bereitgestellt wird(wowsmith1234567@proton[.]me). Es ist erwähnenswert, dass die Bitcoin-Adresse in beiden Versionen die gleiche ist.

Wenn ein Schlüssel mit der richtigen Länge - 32 Zeichen - eingegeben und vom Opfer mit der Eingabetaste bestätigt wird, fährt das Bootkit mit der Verifizierung des Schlüssels fort. Wie in Abbildung 8 dargestellt, wird die Gültigkeit des Schlüssels festgestellt, indem versucht wird, die oben erwähnte Datei \EFI\Microsoft\Boot\verify mit dem angegebenen Schlüssel zu entschlüsseln und zu prüfen, ob der Klartext nur Bytes mit dem Wert 0x07 enthält. Beachten Sie, dass die Bootkit-Variante, die über die UEFI-Secure-Boot-Umgehung bereitgestellt wird, den bereitgestellten Schlüssel mit einem Algorithmus hasht, der wahrscheinlich auf SPONGENT-256/256/16 basiert, und diesen Hash-Wert als Entschlüsselungsschlüssel verwendet, während das Bootkit, das von den erhaltenen Installationsprogrammen bereitgestellt wird, die Benutzereingaben unverändert übernimmt.

Wenn der richtige Schlüssel eingegeben wird, aktualisiert das Bootkit die Konfigurationsdatei mit dem auf 2 gesetzten Verschlüsselungsflag und trägt auch den Entschlüsselungsschlüssel ein. Dann liest es den Inhalt der Datei \EFI\Microsoft\Boot\counter (die die Anzahl der zuvor verschlüsselten Festplattencluster enthält) und fährt mit der Entschlüsselung der Festplatte fort. Bei der Entschlüsselung geht das Bootkit mit einem sehr ähnlichen Prozess vor wie bei der Erkennung von NTFS-Partitionen und der MFT-Entschlüsselung (der Salsa20-Verschlüsselungs- und -Entschlüsselungsprozess ist derselbe), wie im Abschnitt Festplattenverschlüsselung beschrieben. Die Entschlüsselung stoppt, wenn die Anzahl der entschlüsselten Cluster gleich dem Wert aus der Zählerdatei ist. Während der MFT-Entschlüsselung zeigt das Bootkit den aktuellen Status des Entschlüsselungsprozesses auf dem Bildschirm des Opfers an (siehe Abbildung 9).

Als Nächstes fährt das Bootkit mit der Wiederherstellung der legitimen Bootloader \EFI\Microsoft\Boot\bootmgfw .efi und \EFI\Boot\bootx64 .efi aus der zuvor während des Installationsvorgangs erstellten Sicherungsdatei fort: \EFI\Microsoft\Boot\bootmgfw .efi.old.

Nachdem der Entschlüsselungsprozess abgeschlossen ist und die legitimen Bootloader wiederhergestellt wurden, fordert das Bootkit das Opfer auf, das Gerät neu zu starten (Abbildung 10). Wenn alles gut gegangen ist, sollte das Gerät nach dem Neustart das Betriebssystem erfolgreich starten.

Bereitstellen der UEFI-Bootkit-Komponente

In diesem Abschnitt konzentrieren wir uns auf die Bootkit-Installationsfunktionalität der entdeckten HybridPetya-Installationsprogramme. Beachten Sie, dass die Installationsprogramme, die wir erhalten konnten, UEFI Secure Boot nicht berücksichtigen. Wie im Abschnitt zur Ausnutzung von CVE-2024-7344 erläutert, gibt es jedoch wahrscheinlich eine Variante mit einer solchen Verbesserung.

Um zu entscheiden, ob das System auf UEFI basiert, ruft das Installationsprogramm die Festplatteninformationen ab(IOCTL_DISK_GET_DRIVE_LAYOUT_EX), prüft, ob das GPT-Partitionierungsschema verwendet wird(PARTITION_STYLE_GPT), und geht die Partitionen durch, bis es diejenige entdeckt, bei der PARTITION_INFORMATION_GPT.PartitionType auf PARTITION_SYSTEM_GUID gesetzt ist, was die Kennung der EFI-Systempartition ist. Nachdem die EFI-Systempartition gefunden wurde, wird der Vorgang fortgesetzt:

• Entfernen des Fallback-UEFI-Bootloaders, der in \EFI\Boot\Bootx64 .efi gespeichert ist.
• Ablegen einer festplattenverschlüsselungsbezogenen Konfiguration zusammen mit dem Verschlüsselungskennzeichen in der Datei \EFI\Microsoft\Boot\config auf der EFI-Systempartition; die Verschlüsselungskonfiguration enthält den Salsa20-Verschlüsselungsschlüssel, eine 8-Byte-Nonce und den persönlichen Installationsschlüssel des Opfers(base58-kodierte Daten).
• Ablegen eines Verschlüsselungs-Verifizierungs-Arrays bestehend aus 0x200 Bytes mit dem Wert 0x07 in der Datei \EFI\Microsoft\Boot\verify auf der EFI-Systempartition; dieses Array wird später von der Bootkit-Komponente mit demselben Salsa20-Schlüssel verschlüsselt, der auch für die Festplattenverschlüsselung verwendet wird. Der Zweck dieses Arrays besteht darin, zu überprüfen, ob das Opfer einen gültigen Entschlüsselungsschlüssel eingegeben hat (indem das Array mit dem eingegebenen Schlüssel entschlüsselt wird und überprüft wird, ob der Klartext ein Array von Bytes mit dem Wert 0x07 enthält).
• Erstellung eines Backups von \EFI\Microsoft\Boot\bootmgfw .efi, dem Standard-Bootloader für Windows-basierte Systeme, durch Kopieren in \EFI\Microsoft\Boot\bootmgfw .efi.old.

Anschließend löst er einen Systemabsturz (Blue Screen Of Death, BSOD) aus, indem er dieselbe Methode wie Petya verwendet - er ruft die NtRaiseHardError-API auf, wobei der Parameter ErrorStatus auf 0xC0000350(STATUS_HOST_DOWN) und die ResponseOption auf den Wert 6(OptionShutdownSystem) gesetzt ist, was zu einer Systemabschaltung führt.

Die oben genannten Änderungen stellen sicher, dass auf Systemen, auf denen Windows als primäres Betriebssystem eingestellt ist, das Bootkit-Binary ausgeführt wird, sobald das Gerät wieder eingeschaltet wird.

Ausnutzung von CVE-2024-7344

In diesem Abschnitt untersuchen wir ein Archiv, das wir auf VirusTotal entdeckt haben und das eine Variante des im Abschnitt UEFI-Bootkit beschriebenen UEFI-Bootkits enthält, diesmal jedoch gebündelt in einer speziell formatierten cloak.dat -Datei, die mit CVE-2024-7344 zusammenhängt - der UEFI Secure Boot-Umgehungsschwachstelle, die unser Team Anfang 2025 öffentlich bekannt gemacht hat.

Eine Liste der im Archiv enthaltenen Dateien und ihrer Inhalte deutet darauf hin, dass diese EFI-Systempartition von einem System kopiert wurde, das bereits von dieser Petya/NotPetya-Kopiervariante verschlüsselt wurde. Beachten Sie, dass wir das Installationsprogramm, das für die Bereitstellung dieser Version mit der UEFI Secure Boot-Umgehung verantwortlich ist, nicht erhalten haben, aber basierend auf dem Inhalt des Archivs, der in Abbildung 11 dargestellt ist, würde es dem im vorherigen Abschnitt beschriebenen Prozess ziemlich ähnlich sein. Das Archiv enthält im Einzelnen:

• \EFI\Microsoft\Boot\counter, eine Datei, die bereits einen Wert ungleich Null enthält, der die Anzahl der Festplattencluster angibt, die zuvor vom Bootkit verschlüsselt wurden,
• \EFI\Microsoft\Boot\config, eine Datei, in der der Wert für das Verschlüsselungskennzeichen auf 1 gesetzt ist, was bedeutet, dass die Festplatte bereits verschlüsselt sein sollte und das Bootkit mit der Anzeige der Lösegeldforderung fortfahren sollte,
• \EFI\Microsoft\Boot\bootmgfw.efi.old, eine Datei, bei der die ersten 0x400 Bytes mit dem Wert 0x07 geORgt sind,
• \EFI\Microsoft\Boot\bootmgfw.efi, eine legitime, aber anfällige (CVE-2024-7344) UEFI-Anwendung, die von Microsoft signiert wurde (in Microsofts dbx seit Januar 2025 widerrufen); in diesem Abschnitt beziehen wir uns auf diese Datei mit ihrem ursprünglichen Namen reloader.efi, und
• \EFI\Microsoft\Boot\cloak.dat, eine speziell gestaltete Datei, die über reloader.efi geladen werden kann und die XOR-verknüpfte Bootkit-Binärdatei enthält.

Wie in unserem Bericht vom Januar 2025 beschrieben, ist der Exploit-Mechanismus recht einfach. Die Datei cloak.dat enthält speziell formatierte Daten, die eine UEFI-Anwendung enthalten. Wenn die Binärdatei reloader.efi (die als bootmgfw.efi bereitgestellt wird) während des Bootvorgangs ausgeführt wird, sucht sie nach dem Vorhandensein der Datei cloak.dat auf der EFI-Systempartition und lädt die eingebettete UEFI-Anwendung auf sehr unsichere Weise aus der Datei, wobei jegliche Integritätsprüfungen völlig ignoriert werden, wodurch UEFI Secure Boot umgangen wird.

Beachten Sie, dass in unserem Blogpost vom Januar 2025 die Ausnutzung der Schwachstelle nicht detailliert beschrieben wurde; daher hat der Autor der Malware wahrscheinlich das korrekte Format der Datei cloak.dat durch Reverse Engineering der anfälligen Anwendung selbst rekonstruiert.

Die Sicherheitslücke kann nicht auf Systemen ausgenutzt werden, auf denen das dbx-Update von Microsoft vom Januar 2025 installiert ist. Eine Anleitung zum Schutz und zur Überprüfung, ob Ihr System von dieser Sicherheitslücke betroffen ist, finden Sie im Abschnitt Schutz und Erkennung in unserem Blogpost vom Januar 2025.

Fazit

HybridPetya ist nun mindestens das vierte öffentlich bekannte Beispiel eines echten oder Proof-of-Concept-UEFI-Bootkits mit UEFI-Secure-Boot-Umgehungsfunktion, nach BlackLotus (Ausnutzung von CVE-2022-21894), BootKitty (Ausnutzung von LogoFail) und dem Hyper-V Backdoor PoC (Ausnutzung von CVE-2020-26200). Dies zeigt, dass Umgehungen von Secure Boot nicht nur möglich sind, sondern auch immer häufiger vorkommen und sowohl für Forscher als auch für Angreifer attraktiv sind.

Obwohl sich HybridPetya nicht aktiv verbreitet, ist es aufgrund seiner technischen Fähigkeiten - insbesondere der MFT-Verschlüsselung, der UEFI-Systemkompatibilität und der Umgehung von Secure Boot - für die künftige Überwachung von Bedrohungen von Bedeutung.

Wenn Sie Fragen zu unserer auf WeLiveSecurity veröffentlichten Forschung haben, kontaktieren Sie uns bitte unter threatintel@eset.com.

ESET Research bietet private APT Intelligence Reports und Datenfeeds an. Wenn Sie Fragen zu diesem Service haben, besuchen Sie die ESET Threat Intelligence Seite.

IoCs

Eine umfassende Liste von Kompromittierungsindikatoren (IoCs) und Beispielen finden Sie in unserem GitHub-Repository.

Dateien

MITRE ATT&CK-Techniken

Diese Tabelle wurde mit Version 17 des MITRE ATT&CK-Frameworks erstellt.