Group-IB：UEFI 的攻击与狩猎

0x00 摘要

大型黑客组织在bootkits的使用上有着长期的成功经验。bootkits是BIOS/UEFI中隐藏的特殊恶意代码，能够实现长期隐藏而不被发现，甚至在重新安装操作系统和更换硬盘驱动器后仍然存在。由于bootkits具有天然的隐蔽性，极难被检测发现，目前bootkits正被一些与经济动机相关的黑客组织（如Trickbot）所青睐。

本文描述了如何在本地网络中捕获此类威胁，以及如何使用最新的Mosaic Regressor UEFI bootkit搭建测试平台。

0x01 bootkit进化史

• 在2013年，QuarksLab的Sébastien Kaczmarek创建了一个名为Dreamboot的bootkit PoC，它利用UEFI攻击操作系统的引导加载程序，但是该攻击只有禁用安全引导机制后才能实现。之后，同年的黑帽大会上提出了“一种绕过Windows 8安全引导的方法”。自此，安全引导绕过机制被第一次公开提出。

• 在2014年，Rafal Wojtczuk和Corey Kallenberg发布了S3恢复机制中存在的Darth Venamis漏洞信息。计算机在从睡眠模式唤醒后可以使用这种机制继续工作。研究表明，存储S3 BootScript（计算机从睡眠模式被唤醒后初始化设备的一系列命令）的内存区域没有修改保护，引发了各种漏洞。

• 在2015年，Corey Kallenberg和另一位研究人员Xeno Kovah提出了LightEater。这是一种rootkit，可通过直接访问物理内存，使用签名进行逐页搜索来获取加密密钥等关键数据。同年，从HackingTeam泄漏的数据中发现了Vector-EDK框架。这种恶意软件可以向基于UEFI的固件中注入程序。该框架曾被用于开发Mosaic Regressor。

• 在2016年，Dmytro Oleksiuk开发了PeiBackdoor，这是第一个公开可用的UEFI Rootkit，它在PEI（即Pre-EFI初始化）阶段被加载。同年，黑客组织Equation Group泄漏的数据中出现了BANANABALLOT BIOS模块，该模块植入了某种特定程序以与CISCO路由器进行交互。

• 在2017年，WikiLeaks发布了有关DerStarke的信息，DerStarke是一种针对macOS平台的Triton后门的UEFI版本。

• 在2018年，ESET检测到并分析了LoJax UEFI Rootkit，这是信息安全公司首次发现的UEFI Bootkit。

• 在2020年10月，卡巴斯基实验室在调查攻击时发现了Mosaic Regressor，这是一种UEFI bootkit，由HackingTeam数据泄漏中获得的工具所创建。同年12月，一种新型的TrickBot版本被发现，其中嵌入了UEFI代码。

  上面的介绍虽然并不完整，但也显示了UEFI相关攻击的流行趋势和危险性。近年来，固件中公开披露的漏洞数量每年都会翻倍。由此可见，网络犯罪分子对于此类攻击方法的兴趣不断上升。

0x02 UEFI bootkit 测试平台搭建

Mosaic Regressor包含的几个模块如下表所述。

创建测试平台需要感染QEMU虚拟机的固件。该虚拟机使用OVMF（开放虚拟机固件）来对固件进行仿真模拟。固件存储在OVMF_CODE.fd文件中。

因此，要修改虚拟机固件，必须先更改OVMF_CODE.fd文件。这里需要用到跨平台开源工具 - UEFITool。它能够分析固件，从固件中提取模块。

要感染固件，必须向其中添加两个DXE驱动程序和两个UEFI应用程序。首先，需要找到包含所有被使用的DXE驱动程序的节（如下图所示，该节是GUID为8C8CE578-8A3D-4F1C-9935-896185C32DD3的部分）

在写入之前，每个现存的EFI文件都必须以FFS（固件文件系统）文件的格式显示。FFS格式的每个文件都包含多个节（在当前案例中，每个FFS文件有两个节）。第一个节包含可执行代码，第二个节包含模块名称。所有的驱动程序均被汇编为EFI_FV_FILETYPE_DRIVER文件。

所有应用程序都被汇编为EFI_FV_FILETYPE_APPLICATION文件。

为了进行汇编，需要用到EDK II GenSec和GenFfs组件。

可执行代码节的创建如下：

GenSec.exe -o pe32.sec .\Ntfs.efi -S EFI_SECTION_PE32

带有名称的节创建如下：

GenSec.exe -o name.sec -S EFI_SECTION_USER_INTERFACE -n "NTFS"

FFS格式的文件创建如下：

GenFfs-g "F50258A9-2F4D-4DE9-86AE-BDA84D07A41C" -ontfs_driver.ffs-ipe32.sec-iname.sec-tEFI_FV_FILETYPE_DRIVER

当创建带有名称的节时，必须更改-n参数后的文件名。

当创建可执行代码节时，需更改EFI文件的路径。

当创建FFS文件时，必须更改GUID（-g参数）、文件类型（-t参数：驱动程序为EFI_FV_FILETYPE_DRIVER，应用程序为EFI_FV_FILETYPE_APPLICATION）以及输出文件的名称（-o参数）。

最后获得四个FFS格式的文件，可以使用UEFITool将其添加到固件中。

添加时必须确保该节具有足够的空余空间。修改后的固件应如下所示：

在替换固件文件并启动虚拟机后，Mosaic Regressor开始创建文件；

该过程表明固件已被成功修改。这些文件包括％WINDIR％\setupinf.log以及％PROGRAMDATA％\Microsoft\Windows\开始菜单\Programs\Startup\IntelUpdate.exe。

第一个文件可以作为IOC，因为只有当setupinf.log文件不存在时才会创建IntelUpdate.exe文件；第二个文件从服务器下载攻击载荷：

虽然在当前案例中只是虚拟机被感染，但是攻击者可以利用此技术在现实中感染配置错误的计算机。

0x03 捕获Mosaic Regressor

有几种检测Mosaic Regressor的方法：

• 在固件中搜索指示器或与UEFI引用镜像进行比较

• 在操作系统级别搜索指示器

• 分析网络活动

  接下来将对每种方法进行详细介绍。

搜索固件中的指示器

通过对EFI文件SmmReset的分析，可以获得一个固件IOC。该可执行文件将创建一个名为“ fTA”的NVRAM变量。而在HackingTeam开发的rkloader中发现了具有相同名称和功能的变量，因此搜索该IOC指标可以找到基于rkloader的Mosaic Regressor，rkloader以及其他bootkits。

由英特尔发布和支持的多功能Chipsec应用可以检测此威胁。该应用执行固件安全性测试，获取固件转储。Chipsec也可以从操作系统中执行或引导到UEFI Shell后进行执行。本案例中选择了后一项。要创建可启动的闪存驱动器以启动Chipsec，应遵循以下步骤：

• 将闪存驱动器格式化为FAT-32文件系统。

• 保存计算机启动后在闪存驱动器上将要执行的UEFI Shell。为此，需要下载UEFI Shell，并将其命名为“Bootx64.efi”并保存至 /efi/boot。

• 下载Chipsec仓库。

• 将instal /UEFI/chipsec_uefi_x64.zip中的内容提取到闪存驱动器的根目录下。

• 将Chipsec仓库的其余内容复制到闪存驱动器的根目录下。

  当引导进入到UEFI Shell后，mount命令将被执行，该命令可以显示可用设备列表。

  在下图的这种情况下，闪存驱动器将被指定为FS0：

访问Chipsec目录后，可以使用如下命令检查固件中是否存在具有该名称的变量：

python chipsec_util.py uefi var-find fTA

若存在，其转储将被保存到文件中：

若需要对固件进行更深入的分析，可以用Chipsec获取转储。为此，需要执行以下命令：

python chipsec_util.py spi dump rom.bin

前面提到的UEFITool可用于打开转储并提取可疑模块，使用方法如下图所示：

若存在引用固件映像，Chipsec可以使用它来检测固件修改。为此，必须使用如下命令生成参考图像模块的列表：

python chipsec_main.py -i -m tools.uefi.scan_image -a generate,list_of_variables.json,firmware.bin

其中list_of_variables.json是保存执行结果的文件。下图的例子中，firmware.bin文件属于引用固件转储：

在接收到有关引用映像数据后，可以使用如下命令进行比较：

python chipsec_main.py -i -m tools.uefi.scan_image -a check，list_of_variables.json，suspected_firmware.bi

其中suspended_firmware.bin文件是被测固件的转储文件名称。

如上所述，可以从操作系统中使用Chipsec。为此，必须先安装Chipsec驱动程序，并且要用到python解释器运行相关py文件。通过这种方式，才能对收集到的固件映像进行进一步分析。

在操作系统级别搜索IOC

本节将介绍如何在操作系统级别上检测Mosaic Regressor固件感染。

当操作系统启动后，Mosaic Regressor攻击负载（IntelUpdate.exe文件）的行为与常见的恶意软件类似。可以利用分析EFI文件获得的数据、保存在％PROGRAMDATA％\Microsoft\Windows\StartMenu\Programs\Startup中的文件哈希、文件名称以及其他IOC来实现检测。但是，应该指出的是，文件创建事件的搜索将不会成功，因为文件是在加载操作系统之前创建的，这意味着使用EDR或类似解决方案将不会检测到该事件（唯一的解决方法：

可以在关闭计算机或使其进入休眠状态之前保存有关文件系统状态的信息，并将保存的状态与引导操作系统后的状态进行比较）。

％WINDIR％\setupinf.log文件也会发生类似情况，Mosaic Regressor将该文件用作UEFI变量的补充IOC。IntelUpdate.exe文件只会在setupinf.log文件不存在的情况下保存。

使用Huntbox中的以下查询字段，可以找到攻击载荷的痕迹，该痕迹由Mosaic Regressor EFI模块产生：

event_type: "Process creation" AND Payload.CommandLine: "Microsoft\Windows\Start Menu\Programs\Startup\IntelUpdate.exe"

IntelUpdate.exe文件是使用未修改的时间属性创建。若一个自启动文件开始运行但是没有产生对应的事件，这将是一种潜在的威胁暗示。

在启动时创建的所有文件都应在沙箱或恶意软件执行平台中进行检查。在本例中，Huntpoint将文件发送到Polygon进行分析，从而识别恶意文件。结果显示，该类文件的启动在所有主机上均被阻止。

使用EDR和恶意软件系统是一种通用解决方案，但在所有工作站上安装客户端并不一定可行。在这种情况下，使用已知的恶意主机分析网络流量连接可能会有所帮助。

这样可以检测发送攻击负载的服务器是否存在网络连接：

event_type: "Networkconnectionopening"  ANDPayload.RemoteAddress: "103.56.115.69"

dns_query: "myfirewall.org"

0x03 潜在的攻击媒介

涉及UEFI感染的情况通常有以下三种：

• 远程感染

• 物理访问感染

• 通过供应链感染

  要进行远程感染，攻击者必须提升权限才能安装将在操作系统内核级别运行的攻击负载。提升权限之后，攻击者需要利用SMM漏洞。这样就可以在SMM模式下执行代码，从而绕过各种固件保护机制（闪存写保护），并直接访问固件内存。

  在涉及物理访问感染的情况中，攻击者可以利用UEFI配置或固件更新机制中的错误。

  如果供应链被感染，攻击者可以将代码注入到固件中或对其进行更新，并绕过现有的保护方法。对于此类攻击，需要获得对固件源代码的访问权。

  Chipsec也可以用于基本UEFI配置检查或漏洞扫描。为此，需要使用下列python命令运行主模块：

python chipsec_main.py

该命令将运行各种安全检查，例如重写保护检查。

需要注意的是，因为Chipsec仅提供一组基本的安全检查，所以成功通过此测试并不表示系统未受到感染。但是，未通过测试意味着必须安装最新的UEFI更新，或者找到违反固件基本安全机制的原因。

0x04 总结

UEFI威胁是最严重的安全威胁之一，想要更加安全、可靠地加载操作系统，就不能仅依靠内置的保护机制。为了保护基础设备并有效地应对此类威胁，必须重视网络威胁情报数据的使用。此外，除了实现了相关安全策略的商业产品外，还可以使用开源工具（Chipsec）进行防护，该工具通过检测IOC，在一定程度上提供了捕获威胁的可能性，并有助于检查UEFI配置是否正确。

• End -

原文标题：Hunting bootkits on a local network and building your own test bench

原文链接：www.group-ib.com/blog/bootkits

本文为CNTIC编译，不代表本公众号观点，转载请保留出处与链接。