概述

2025年7月下旬，我们在VirusTotal上发现可疑勒索软件样本，这些样本从波兰上传，文件名包括notpetyanew.exe等，暗示与2017年袭击乌克兰等多国的破坏性恶意软件存在关联。NotPetya攻击被认为是史上最具破坏性的网络攻击，总损失超过100亿美元。尽管NotPetya与2016年3月首次发现的Petya勒索软件相似，但NotPetya的目的是纯粹破坏，因为无法从受害者的个人安装密钥恢复加密密钥。由于当前发现的样本与Petya和NotPetya都具有共同特征，我们将这一新发现命名为HybridPetya。

虽然ESET遥测数据显示HybridPetya尚未在野外活跃使用，但这些样本中的一个重要细节仍引起了我们的注意——与原始NotPetya（以及Petya勒索软件）不同，HybridPetya还能够通过向EFI系统分区安装恶意EFI应用程序来感染现代UEFI系统。部署的UEFI应用程序负责加密NTFS相关的主文件表（MFT）文件——这是包含NTFS格式分区上所有文件信息的重要元数据文件。

经过进一步挖掘，我们在VirusTotal上发现了更有趣的内容：一个包含整个EFI系统分区内容的存档，其中包括非常相似的HybridPetya UEFI应用程序，但这次捆绑在特殊格式的cloak.dat文件中，易受CVE-2024-7344攻击——这是我们团队在2025年初披露的UEFI安全启动绕过漏洞。

有趣的是，尽管VirusTotal上的文件名和当前样本中勒索票据的格式表明它们可能与NotPetya相关，但与原始NotPetya不同，用于生成受害者个人安装密钥的算法允许恶意软件操作员从受害者的个人安装密钥重建解密密钥。因此，HybridPetya可以作为常规勒索软件（更像Petya），而不是像NotPetya那样纯粹具有破坏性。

有趣的是，在2025年9月9日，@hasherezade发布了一篇关于UEFI Petya概念验证存在的帖子，并附有在启用UEFI安全启动的情况下执行恶意软件的演示视频。尽管视频中的样本明显不同于本博客中介绍的样本（显示了典型的Petya ASCII艺术头骨，这在我们发现的样本中不存在），但我们怀疑这两个案例之间可能存在某种关系，HybridPetya可能也只是安全研究人员或未知威胁行为者开发的概念验证。

在本博客中，我们专注于HybridPetya的技术分析。

HybridPetya技术分析

在本节中，我们提供HybridPetya组件的技术分析：引导工具包及其安装程序。我们还单独剖析了能够通过利用CVE-2024-7344绕过UEFI安全启动的HybridPetya版本。请注意，HybridPetya支持传统和基于UEFI的系统——在本博客中，我们将重点介绍UEFI部分。

有趣的是，负责生成受害者个人安装密钥的代码似乎受到RedPetyaOpenSSL概念验证的启发。我们知道至少还有一个UEFI兼容的NotPetya概念验证重写，名为NotPetyaAgain，用Rust编写；然而，该代码与HybridPetya无关。

UEFI引导工具包

我们获得了两个不同版本的UEFI引导工具包组件，两者非常相似但存在某些差异。执行时，引导工具包首先从\EFI\Microsoft\Boot\config文件加载其配置，并检查指示当前加密状态的加密标志——与原始Petya/NotPetya样本相同，加密标志可以具有以下值之一：

• 0 - 准备加密
• 1 - 已加密
• 2 - 已支付赎金，磁盘已解密

它根据加密状态标志继续执行，如图1所示。

图1. HybridPetya执行逻辑概述

磁盘加密

如果加密标志的值为0，引导工具包从配置数据中提取32字节长的Salsa20加密密钥和8字节长的随机数，随后重写配置文件，此时加密密钥被清零，加密标志设置为1。它继续使用配置中的密钥和随机数，通过Salsa20加密算法加密\EFI\Microsoft\Boot\verify文件。然后，在继续其主要功能——磁盘加密——之前，它在EFI系统分区上创建文件\EFI\Microsoft\Boot\counter；该文件的用途稍后解释。

磁盘加密过程从识别所有NTFS格式的分区开始。如图2所示，样本通过获取连接的存储设备句柄列表，通过检查EFI_BLOCK_IO_MEDIA->LogicalPartition为TRUE来识别各个分区，最后通过比较第一个分区扇区中数据的前四个字节与NTFS签名NTFS来验证分区是否为NTFS格式。

图2. NTFS分区识别的Hex-Rays反编译代码

一旦识别出NTFS分区，引导工具包继续加密主文件表（MFT）文件，这是包含有关其他文件及其数据在NTFS格式分区上位置信息的基本元数据文件。如图3所示，在加密过程中，引导工具包将\EFI\Microsoft\Boot\counter文件的内容重写为已加密磁盘簇的数量，并更新受害者屏幕上显示的虚假CHKDSK消息（如图4所示），提供当前加密状态的信息（尽管根据消息，受害者可能认为正在检查磁盘错误，而不是正在加密）。

图3. Hex-Rays反编译代码：MFT加密

图4. HybridPetya在磁盘加密期间显示的虚假CHKDSK消息（与NotPetya和Petya相同）

加密完成后，引导工具包重新启动机器。

磁盘解密

如果引导工具包检测到磁盘已加密，意味着配置文件中的加密标志值为1，它会显示图5或图6中的勒索票据（取决于引导工具包版本），并要求受害者输入解密密钥。请注意，虽然HybridPetya勒索票据的格式与原始NotPetya相同（如图7所示），但赎金金额、比特币地址和操作员的电子邮件地址不同。此外，通过UEFI安全启动绕过部署的版本使用不同的联系电子邮件地址（wowsmith999999@proton[.]me），而不是通过获得的安装程序部署的版本（wowsmith1234567@proton[.]me）。值得一提的是，两个版本中的比特币地址是相同的。

图5. 通过不带UEFI安全启动绕过的安装程序安装的引导工具包的勒索票据

图6. 通过利用CVE-2024-7344部署的引导工具包版本显示的勒索票据

图7. 原始NotPetya勒索票据

当输入正确长度——32个字符——的密钥并由受害者按Enter确认后，引导工具包继续验证密钥。如图8所示，通过尝试使用提供的密钥解密上述\EFI\Microsoft\Boot\verify文件，并检查明文是否仅包含值为0x07的字节来建立密钥有效性。请注意，通过UEFI安全启动绕过部署的引导工具包变体使用可能基于SPONGENT-256/256/16的算法对提供的密钥进行哈希处理，使用该哈希值作为解密密钥，而通过获得的安装程序部署的引导工具包则直接使用用户输入。

图8. Hex-Rays反编译代码：磁盘解密密钥有效性验证

如果输入了正确的密钥，引导工具包将更新配置文件，加密标志值设置为2，并填入解密密钥。然后它读取\EFI\Microsoft\Boot\counter文件的内容（包含先前加密的磁盘簇数量）并继续进行磁盘解密。对于解密，引导工具包进行与NTFS分区发现和MFT解密非常相似的过程（Salsa20加密和解密过程相同），如磁盘加密部分所述。当解密的簇数等于计数器文件中的值时，解密停止。在MFT解密过程中，引导工具包在受害者屏幕上显示当前解密过程状态，如图9所示。

图9. 输入有效密钥后向受害者显示的解密状态

接下来，引导工具包继续从安装过程中先前创建的备份文件\EFI\Microsoft\Boot\bootmgfw.efi.old中恢复合法的引导加载程序\EFI\Microsoft\Boot\bootmgfw.efi和\EFI\Boot\bootx64.efi。

最后，在解密过程完成并恢复合法的引导加载程序后，引导工具包提示受害者重新启动设备（图10）。如果一切顺利，设备在重新启动后应成功启动操作系统。

图10. 成功磁盘解密后提示重新启动受害者设备

部署UEFI引导工具包组件

在本节中，我们重点介绍发现的HybridPetya安装程序的引导工具包安装功能。请注意，我们能够获得的安装程序没有考虑UEFI安全启动。然而，如CVE-2024-7344利用部分所述，很可能存在具有此类改进的变体。

为了确定系统是否基于UEFI，安装程序检索磁盘信息（IOCTL_DISK_GET_DRIVE_LAYOUT_EX），检查是否使用GPT分区方案（PARTITION_STYLE_GPT），并遍历分区，直到发现PARTITION_INFORMATION_GPT.PartitionType设置为PARTITION_SYSTEM_GUID的分区，这是EFI系统分区的标识符。发现EFI系统分区后，它继续：

• 删除后备UEFI引导加载程序，存储在\EFI\Boot\Bootx64.efi中。
• 将磁盘加密相关配置以及加密标志放到EFI系统分区上的\EFI\Microsoft\Boot\config文件中；加密配置包含Salsa20加密密钥、8字节随机数和受害者的个人安装密钥（base58编码数据）。
• 将包含0x200字节值为0x07的加密验证数组放到EFI系统分区上的\EFI\Microsoft\Boot\verify文件中；该数组随后由引导工具包组件使用与磁盘加密相同的Salsa20密钥加密。该数组的目的是验证受害者是否输入了有效的解密密钥（通过使用输入的密钥解密数组，并验证明文包含值为0x07的字节数组）。
• 通过将基于Windows系统的默认引导加载程序\EFI\Microsoft\Boot\bootmgfw.efi复制到\EFI\Microsoft\Boot\bootmgfw.efi.old中来创建其备份。

完成后，它通过使用与Petya相同的方法——调用NtRaiseHardError API，ErrorStatus参数设置为0xC0000350（STATUS_HOST_DOWN），ResponseOption设置为值6（OptionShutdownSystem）——触发系统崩溃（蓝屏死机，BSOD），导致系统关闭。

上述更改确保在将Windows设置为主操作系统的系统上，一旦设备再次通电，引导工具包二进制文件将被执行。

CVE-2024-7344利用

在本节中，我们检查在VirusTotal上发现的存档，其中包含UEFI引导工具包部分中描述的UEFI引导工具包的变体，但这次捆绑在与CVE-2024-7344相关的特殊格式的cloak.dat文件中——这是我们团队在2025年初公开披露的UEFI安全启动绕过漏洞。

存档中存在的文件列表及其内容表明，此EFI系统分区是从已由此Petya/NotPetya模仿变体加密的系统复制的。请注意，我们尚未获得负责部署此带有UEFI安全启动绕过的版本的安装程序，但基于存档的内容（如图11所示），该过程将与上一节中描述的过程非常相似。具体来说，存档包含：

• \EFI\Microsoft\Boot\counter，一个已包含非零值的文件，表示先前由引导工具包加密的磁盘簇数量，
• \EFI\Microsoft\Boot\config，一个加密标志值设置为1的文件，意味着磁盘应该已经加密，引导工具包应继续显示勒索票据，
• \EFI\Microsoft\Boot\bootmgfw.efi.old，一个前0x400字节与值0x07进行XOR运算的文件，
• \EFI\Microsoft\Boot\bootmgfw.efi，一个合法但易受攻击（CVE-2024-7344）的UEFI应用程序，由微软签名（自2025年1月起在微软的dbx中撤销）；在本节中，我们将使用其原始名称reloader.efi来指代此文件，以及
• \EFI\Microsoft\Boot\cloak.dat，一个特殊制作的文件，可通过reloader.efi加载，并包含XOR运算的引导工具包二进制文件。

图11. 包含利用CVE-2024-7344的引导工具包版本的存档

如我们在2025年1月的报告所述，利用机制非常简单。cloak.dat文件包含特殊格式的数据，其中包含一个UEFI应用程序。当reloader.efi二进制文件（部署为bootmgfw.efi）在启动期间执行时，它搜索EFI系统分区上cloak.dat文件的存在，并以非常不安全的方式从文件中加载嵌入的UEFI应用程序，完全忽略任何完整性检查，从而绕过UEFI安全启动。

请注意，我们2025年1月的博客文章没有详细解释利用过程；因此，恶意软件作者可能基于反向工程易受攻击的应用程序自行重建了正确的cloak.dat文件格式。

在应用了微软2025年1月dbx更新的系统上无法利用此漏洞。有关如何保护和验证您的系统是否暴露于此漏洞的指导，请查看我们2025年1月博客文章的保护和检测部分。

结论

HybridPetya现在是至少第四个公开已知的真实或概念验证UEFI引导工具包，具有UEFI安全启动绕过功能，加入了BlackLotus（利用CVE-2022-21894）、BootKitty（利用LogoFail）和Hyper-V后门概念验证（利用CVE-2020-26200）的行列。这表明安全启动绕过不仅是可能的——它们正变得越来越常见，对研究人员和攻击者都更具吸引力。

尽管HybridPetya没有主动传播，但其技术能力——尤其是MFT加密、UEFI系统兼容性和安全启动绕过——使其在未来的威胁监控中值得关注。

有关我们在WeLiveSecurity上发布的研究的任何询问，请通过threatintel@eset.com联系我们。 ESET Research提供私有的APT情报报告和数据馈送。有关此服务的任何询问，请访问ESET威胁情报页面。

IoCs

全面的危害指标（IoCs）和样本列表可以在我们的GitHub存储库中找到。

文件

MITRE ATT&CK技术

此表使用MITRE ATT&CK框架版本17构建。