一枚“野生”UEFI rootkit的分析报告

前言

安全厂商ESET的研究人员公布了一枚“野生”UEFI rootkit的分析报告。 UEFI rootkit 该允许黑客在目标计算机上植入长期存在的恶意软件，即使用户对硬盘驱动器全盘格式化后依然不能解决问题。

UEFI rootkit并不是新鲜事，例如曾经出现过的rkloader或面向macOS EFI/UEFI启动植入的DerStarke。但这些恶意软件均处于理论研究的阶段，没有在现实世界中大规模部署和传播过。此外相关信息基本上都是只言片语，也没有真实案例可以参考。ESET发现的这枚UEFI rootkit是从现实世界中首次获得的，Sednit团队“出品”，具备相当的传播能力和实用性。

接下来就让我们看看究竟是怎么回事。

背景

Sednit团队

Sednit团队从2004年组建以来就一直活跃在暗处，它还有几个名字：APT28、Sofacy、Strontium和Fancy Bear。它在过去几年中进行过多次大型攻击活动而声名鹊起， 例如， 2016年美国大选之前对民主党全国委员会（DNC）进行黑客攻击以及被认为是全球电视网络TV5Monde、世界反兴奋剂机构（WADA）电子邮件泄密等黑客攻击的幕后推手。 本次发现的UEFI rootkit也是该团队的第一款。

切入点/载体

一款名叫LoJack的笔记本防盗软件是该UEFI rootkit的切入点/载体，这款软件以前叫Computrace，由Absolute Software出品。用户安装该软件并激活服务后，计算机就可以回传信息到其C＆C服务器，如果计算机丢失或被盗，用户就可以通过回传的信息得到其地理位置。

解构

软件架构

LoJack/Computrace成为UEFI rootkit恶意软件的推手，主要是因为它通过写入系统的UEFI / BIOS固件来避免因重装系统或擦除/更换硬盘而导致设备不可追溯。来自多家OEM制造商的笔记本电脑UEFI / BIOS模块中都预装了该软件，用户只要更改BIOS选项即可激活功能，如图1所示：

图1 LoJack/Computrace 功能BIOS激活

下图为该产品的全局架构（来自2009年发布的信息），描绘了UEFI/BIOS模块如何工作并连接到Absolute Software控制的Web服务器。

图2  LoJack持久化机制

以下计算机启动时该软件开始运行的步骤说明：

1、计算机启动时，如果BIOS选项处于“Enabled”的状态，则执行UEFI/BIOS模块中的预置功能。软件将尝试查找FAT/FAT32/NTFS分区，然后使用NTFS驱动程序创建 autochk.exe 文件，并覆写系统中原有 autochk.exe 文件的内容。 autochk.exe 是一个Windows可执行文件，在Windows初始化早期运行，用于检查硬盘驱动器是否损坏。

2、系统加载并运行修改后的 autochk.exe ，其主要目的是释放 rpcnetp.exe 并将其添加到系统服务，以便在每次系统重启时启动。 操作完成后还原 autochk.exe 为原始版本。

3、 rpcnetp.exe 的作用是确保主代理程序能够正常运行。如果主代理程序失效，它会连接到Absolute Software的C＆C服务器来下载代理程序并执行。 rpcnetp.exe 的第一步是复制自身并修改PE头，变成动态链接库（DLL）。 然后将此DLL加载到内存中，生成一个 svchost.exe 进程并注入DLL。然后它将产生一个Internet Explorer iexplore.exe 进程并再次将其DLL注入。 最后一个过程是通过互联网与厂家的服务器进行通信。 rpcnetp.exe 将代码注入外部进程的行为常见于恶意软件，合法、信誉良好的软件极少采用这种方式。

4、全功能代理软件在系统上运行，并实现LoJack的整套跟踪和恢复功能。

2014年，LoJack/Computrace软件的完整运行过程以及代理软件与C＆C服务器之间使用的网络协议才得以详细披露。其中最大的问题在于代理软件与服务器之间的通信没有身份验证机制，如果攻击者可以控制代理软件与服务器之间的通信链路，则可以在目标计算机上下载任意代码并执行。

能够让攻击者直接与代理软件进行通信的方法有很多，这里是以代理如何检索C＆C服务器的地址为突破点。服务器地址信息包含在 rpcnetp.exe 的配置信息，经过加密。

图3 左侧为加密信息，右侧有部分解密

图3显示了加密和解密的 rpcnetp.exe 配置文件。使用的“加密”方法是基于单字节密钥的简单XOR操作。这个密钥0xB5对于所有 rpcnetp.exe 都有效。如图3所示，C＆C域名清晰可见。前面的四个字节构成C＆C服务器IP地址。由于整个过程中没有对配置文件内容进行验证环节，对％WINDIR％具有写访问权限的攻击者即可更改文件内容，让 rpcnetp.exe 连接到攻击者控制的C＆C服务器而不是合法服务器。只要知道网络协议用的是那种，就可以实现使用 rpcnetp.exe 下载并执行任意代码。

尽管这种风险已经存在很多年了，但直到最近针对性的恶意活动才出现在人们的视野里。

LoJack变成了LoJax

2018年5月，Arbor Networks发布的一篇博客文章描述了木马化LoJack解决方案中 rpcnetp.exe 的几个木马化样本。这些恶意样本使用了经过修改的配置信息，与攻击者的C＆C服务器进行通信。 配置信息中改为了Sednit团队使用的C＆C域名。 图4显示了修改过的 rpcnetp.exe 实例。

图4 左边为正常的配置文件，右边是修改后的配置文件

“李鬼” rpcnetp.exe 与正版之间的差异非常小，上方的这个图基本就反映了全貌。它们的编译时间戳一致，并且内容只有几十个字节的区别。除了对配置文件的修改外，其他更改还包括指定C＆C服务器连接间隔的计时器值。

在5月的博客发布后，ESET还发现了针对巴尔干、中欧以及东欧不同地区的LoJax恶意活动，安装方式目前没有明确的解释。有可能动用了Sednit团队掌握的一些后门。

组件探究

ESET实验室分析了所有从巴尔干半岛、中欧和东欧地区收集到的LoJax恶意软件样本，均包含Sednit团队的一些活动特征，如：

SedUploader，一阶后门。

XAgent，Sednit掌握的高级后门。

Xtunnel，一款网络代理工具，可以通过互联网中继C＆C服务器和本地网络内端点计算机之间的网络流量。

受攻击的计算机中大部分都存在Sednit团队专用工具的痕迹，但一小部分系统只有LoJax。也就是说，在某些情况下LoJax被用作一个单独的工具，以备其他工具失效情况下的不时之需。

而XAgent通常用于在系统上删除其他模块，和LoJack解决方案中的部分功能一样，也就是说如果在系统上发现XAgent存在的话，LoJax样本可能只用到了 rpcnetp.exe 代理软件的部分。

先保留这个猜测，继续对LoJax样本进行分析。

RWEverything驱动程序（RwDrv）和 info_efi.exe

第一条线索来自攻击者创建的自定义工具，该工具在执行时会将底层系统设置信息转储到文本文件中。部分设备上LoJax样本和该工具同时存在。下图展示了该工具生成的日志文件的片段，名称为 info_efi.exe 。

图5 由info_efi .exe生成的日志文件摘录

此外，该工具释放了 RwDrv.sys 用于读取上述信息。该内核驱动属于RWEverything，后者是一个正常的免费程序，用于读取计算机底层配置的信息，包括PCI Express、内存、PCI Option ROM等。该内核驱动包含RWEverything的签名，因此在系统上可以畅行无阻。

图6 RwDrv .sys签名证书

RWEverything软件提供GUI界面可供使用者访问所有数据。

图7 RWEverything GUI截图

info_efi工具是判断LoJax UEFI模块是否存在的第一个条件。获取系统硬件信息时攻击的第一部人，然后允许用户进程访问和修改存储UEFI模块SPI闪存的内容。

第二条判断该UEFI rootkit是Sednit团队“出品”的线索是用于SPI内存转储和写入的两个不同工具。

SPI闪存转储

第一个是 ReWriter_read.exe 文件，包含使用RWEverything驱动程序 RwDrv.sys 转储系统SPI闪存所需的所有代码。为了让设备驱动程序执行所需操作，转储工具必须发送正确的I/O控制（IOCTL）代码。虽然 RwDrv.sys 支持许多不同的IOCTL代码，但此处转储器和编写器工具仅使用四个即可满足需求。

ReWriter_read首先使用嵌入式内核驱动程序 RwDrv.sys 创建服务，并记录有关UEFI/BIOS配置的信息，即BIOS 控制寄存器（BIOS_CNTL）中包含的三个字段的值：BIOS锁定启用（BLE），BIOS写入启用（BIOSWE）和SMM BIOS写保护禁用（SMM_BWP）。虽然ReWrite_read没有利用这些值，但以下部分将重点介绍为什么需要该信息。

ReWriter_read的下一步操作是检索SPI闪存上的BIOS区域基地址及其大小。该信息包含在SPI主机接口寄存器“BIOS Flash Primary Region”中。所有SPI主机接口寄存器都在根复合寄存器块（RCRB）中进行存储器映射，其基址可以通过读取正确的PCI配置寄存器来检索。ReWriter_read使用RwDrv IOCTL 0×22840并读取正确的偏移量（在我们的例子中为0xF0）来获取此地址。一旦获得BIOS区域基址和大小信息后，转储工具就会读取SPI闪存的相关内容并将其写入磁盘上的文件。SPI闪存的读取过程如图8所示。

图8 读取SPI闪存的操作顺序

这些操作将重复执行直到从SPI闪存读取所有数据为止。然后，ReWriter_read验证转储镜像的大小。它将解析镜像Flash描述符以获取BIOS、千兆以太网（GbE）和管理引擎（ME）区域的内存范围。添加这三个区域的大小允许转储工具计算SPI闪存中完整内容的大小。如果镜像尺寸等于通过读取BIOS Flash主区域寄存器获得的尺寸信息，镜像被认为有效。

注入UEFI固件

第二个是 ReWriter_binary.exe 文件。该文件包含注入转储的UEFI镜像文件的代码，并将木马化的镜像覆写SPI闪存。本节将详细介绍此二进制文件的内部工作原理。

一旦闪存中的内容被上述转储器工具转储并成功验证，恶意UEFI模块就被添加到镜像中。 因此攻击者首先需要解析UEFI镜像来提取攻击所需的信息。

UEFI镜像中的数据使用固件文件系统（FFS）以卷的形式存储。顾名思义，它是专门为存储固件镜像而定制的文件系统。卷包含由GUID标识文件。每个文件通常由多个部分组成，其中一个部分包含真实的PE/COFF可执行文件，即UEFI镜像。使用UEFITool可以看到相关信息。

图9 使用UEFITool加载UEFI镜像文件

ReWriter_binary解析在SPI闪存的BIOS区域中找到的所有固件卷，搜索特定文件：

Ip4Dxe（8f92960f-2880-4659-b857-915a8901bdc8）
NtfsDxe（768bedfd-7b4b-4c9f-b2ff-6377e3387243）
SmiFlash（bc327dbd-b982-4f55-9f79-056ad7e987c5）
DXECore

图10 解析固件卷的例程的Hex-Rays反编译器输出

Ip4Dxe和NtfsDxe是DXE驱动程序。在UEFI固件中，DXE驱动程序是PE / COFF镜像，用于硬件抽象或生成可供其他DXE驱动程序或UEFI应用程序使用的服务。这些驱动程序由DXE Foundation在早期引导过程中通过DXE Dispatcher（DXE Core）加载。这个步骤完成后，UEFI应用程序（例如OS加载程序）可以使用的所有服务均已齐备。通常情况下，所有DXE驱动程序都存储在同一个卷中，但是DXE调度程序可能存在别的地方。

ReWriter_binary仅用于查找Ip4Dxe，表示正在解析的卷包含DXE驱动程序，该卷将用于安装的攻击者的恶意DXE驱动程序。它还会查找DXE Core并将其所在的卷添加为另一个候选卷，以便编写rootkit。每个卷上的可用空间在后续步骤中用于添加恶意驱动程序。

NtfsDxe是AMI NTFS DXE驱动程序。如果固件卷存在，则用于稍后从卷中删除文件。在之后的UEFI rootkit分析章节可以看到该工具为何删除此驱动程序。

而针对SmiFlash镜像，有关信息仅用于存储，不用于任何恶意活动。有趣的是，这个镜像本身问题也很多。ESET专家认为Sednit团队按兵不动的原因很有可能正在开发一些该镜像相关的漏洞，如果成功，哪怕是比较新的设备都可以被覆写SPI闪存。目前的工具只能写入配置错误或相当老旧BIOS系统中（2008年左右推出的芯片组的对应主板）。

在提取所需元数据之后，ReWriter_binary的下一步是注入和转储UEFI镜像，添加恶意DXE驱动程序。

首先，它会创建一个文件头部结构（EFI_FFS_FILE_HEADER）。

然后，根据Ip4Dxe和DXE Core的位置以及这些卷上的可用空间选择目标卷。 ReWriter_binary嵌入包含PE镜像的压缩部分和用户界面部分，用于指定文件的可读名称：SecDxe。 压缩部分将附加到文件头，并写入包含可用空间的卷尾。 图11展示了使用UEFITool查看的文件结构。

图11 SecDxe文件的UEFITool视图

最后，如果镜像中存在NtfsDxe驱动程序，则会将其删除。由于固件文件系统按顺序存储文件及其内容，因此这是一个相当简单的过程：

ReWriter_binary找到卷末尾的自由空间的偏移量；

NtfsDxe镜像被0xFF字节覆盖；

从NtfsDxe所在的偏移点开始复制固件卷的尾部；

文件系统的其余部分填充0xFF字节。

将修改的固件写回SPI闪存

成功修改转储的固件镜像后，下一步就是将其写回SPI闪存。在深入研究这个过程之前，需要先介绍一些与此案例相关的BIOS写保护机制。

BIOS系统包含多种保护机制，用于阻止未经授权的BIOS固件写入尝试。 但是，默认情况下这些机制并没有被启用。这些配置通过BIOS控制寄存器（BIOS_CNTL）启用或关闭。该寄存器包含BIOS Write Enable（BIOSWE）位，需要将其设置为1才能写入SPI闪存。IOS控制寄存器（BIOS_CNTL）还有另一个可用于保护BIOS的功能：BIOS锁定启用（BLE），该功能启用时会将BIOSWE位锁定为0。 但是，在现实情况中这种保护机制非常脆弱，当有请求将BIOSWE位设置为1时，BIOSWE先会被设置为1，然后系统发出系统管理中断（SMI），指令将BIOSWE位设置回0。

这种方式问题很大。 首先，需要固件开发人员专门构建一个SMI处理程序，如果没有，则BLE位无用。 其次，存在竞态条件漏洞时，即使SMI处理程序正常运行，也可能允许完全绕过此机制。要利用此漏洞，攻击者需要启动一个线程，该线程将BIOSWE连续设置为1，而另一个线程将数据写入SPI闪存。

为了解决此问题，通过BIOS_CNTL配置的新保护机制已经得到应用。它是在英特尔芯片组的平台控制器中心（PCH）系列中引入的。如果其配置位已设置，则仅当所有内核在系统管理模式（SMM）中运行且BIOSWE设置为1时，SMM BIOS写保护禁用（SMM_BWP）才能允许BIOS固件是可写的。这种机制能够有效保护系统免受竞态条件漏洞的影响。但是，与BLE的情况一样，SMM_BWP需由固件激活。因此，未能正确配置这些机制的固件会使系统面临未经授权写入BIOS区域的风险。

ReWriter_binary读取BIOS控制寄存器的内容以选择正确的路径。它首先检查BIOSWE是否已设置。如果是，则进入写入阶段。如果禁用BIOSWE，它将检查BLE位的值。如果未设置，则会翻转BIOSWE位并开始覆写已修改的固件。如果设置了BLE，则确保禁用SMM_BWP并利用上述竞态条件。如果SMM_BWP位置1，则失败。 图12说明了这个过程。

图12 写入过程的决策树

假设这里分析的ReWriter_binary的版本和用于部署UEFI rootkit的一致，我们可以得出结论，固件没有正确配置BIOS写保护机制，或者目标设备的芯片组比平台控制器中心更老旧。

ReWriter_binary无法在正确配置的新一代BIOS系统中覆写UEFI固件。但是，在解析UEFI固件空间时寻找易受攻击的SmiFlash UEFI镜像，这一举动表明攻击者可能在寻求更先进的技术绕过BIOS写保护。

与上述读操作非常相似，写入SPI闪存的顺序：

图13  写入SPI闪存的顺序

这些操作将循环重复，直到所有数据都写入SPI闪存。

写入过程完成后，SPI闪存的内容将再次转储到文件 image.bin 中。在新的转储镜像上执行同ReWriter_read操作过的相同完整性检查。然后，将从SPI闪存读取的镜像与内存中的修改镜像进行比较。如果某些字节不同，则会记录不同的地址，不同之处不会对恶意软件的执行有任何影响，只作记录用。

最后的步骤时设置此注册表项：

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ BootExecute =“autocheck autochk *”

然后，停止并卸载RwDrv服务。 设置Windows注册表值非常重要，因为UEFI Rootkit查找该字符串从而在Windows启动期间执行恶意软件。

LOJAX技术分析

虽然转储、修改和写入SPI闪存的工具是针对特定固件镜像定制的，并且无法在任何给定系统上轻松重复使用，但可以从中提取完整的UEFI模块。研究人员在提取到该模块后做的第一事是通过遥测来查看之前是否录入过这个模块的洗脑洗。使用新新一代ESET UEFI扫描器受发现有记录，表明Sednit团队的UEFI模块安装曾经安装在现实世界中的系统上，也就是说这款UEFI Rootkit是正经“野生”的，不仅停留在理论研究层面。

以下是研究人员对该“野生”样本的技术分析。

图14给出了在OS之前UEFI rootkit工作流的概述。 首先，DXD调度程序加载SecDxe DXE驱动程序。 它在 EFI_EVENT_GROUP_READY_TO_BOOT 事件组上设置Notify函数回调。 当固件即将选择引导设备并运行OS加载程序时调用Notify功能。回调做了三件事：

加载嵌入式NTFS DXE驱动程序，以便能够访问和写入NTFS分区；

将两个文件写入Windows NTFS分区： rpcnetp.exe 和 autoche.exe ；

修改此注册表项 'HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ BootExecute' ：

之前： 'autocheck autochk *'

之后： 'autocheck autoche *' 。

图14 被UEFI rootkit感染的系统的引导过程

SecDxe：恶意DXE驱动程序

上文已经介绍了UEFI rootkit的组件部署细节，本章的重点是介绍在目标设备上发生的事件详情。这里采用自下而上的方法，首先描述UEFI rootkit本身，然后跟踪事件链直到在操作系统级别部署的最终有效负载。

Sednit的UEFI rootkit是一个DXE驱动程序，由GUID 682894B5-6B70-4EBA-9E90-A607E5676297标识。该文件没有签名，因此无法在启用了安全启动的系统上运行。 一旦部署在一个固件卷中，DXE Foundation就会在每次系统引导时加载它。

SecDxe是一个小型DXE驱动程序，主要做两件事：安装一个从未使用过的GUID 832d9b4d-d8d5-425f-bd52-5c5afb2c85dc标识的协议；创建一个与Notify功能相关的事件。通知函数设置为在发信号通知 EFI_EVENT_GROUP_READY_TO_BOOT 事件组时调用。引导管理器通知事件组要启动的设备。

图15 创建事件的进程的Hex-Rays反编译输出

Notify功能实现了Sednit的UEFI rootkit的恶意行为。它将有效负载写入Windows的NTFS文件系统。由于UEFI固件通常仅处理EFI系统分区，通常不包括NTFS驱动程序，仅支持基于FAT的文件系统作为启动分区。因此，UEFI固件不必与NTFS驱动程序一起提供。所以SecDxe嵌入了自己的NTFS驱动程序。首先加载此驱动程序并将其连接到磁盘设备。这样一来它就能在NTFS分区的磁盘设备上安装EFI_SIMPLE_ FILE_SYSTEM_PROTOCOL，从而实现基于文件的访问。

图16 用于将文件写入磁盘的进程的Hex-Rays反编译输出

然后SecDxe打开 ％WINDIR％\ System32 \ config \ SYSTEM ，这是支持HKLM \ SYSTEM注册表配置单元的文件。然后解析文件，找到’autocheck autochk *’并用’e'替换’autochk’的’k'。将 'HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ BootExecute' 设置为 'autocheck autoche *' 。下次Windows启动时，将启动autoche .exe而不是 autochk.exe 。

黑客团队的NTFS驱动程序

如上文所述，SecDxe模块嵌入了NTFS驱动程序，表明Sednit团队很有可能自己编写驱动程序，而是直接集成了Hacking Team泄露的NTFS DXE驱动程序。

Hacking Team的NTFS驱动程序的核心是ntfs-3g开源项目，只是加了一个外壳作为UEFI DXE驱动程序。因此，Hacking Team的驱动程序的INF文件构建信息列出了来自ntfs-3g项目的文件名。SecDxe的NTFS驱动程序字符串还列出了许多这些文件名：

c:\edk2\NtfsPkg\NtfsDxe\ntfs\inode.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\volume.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\bootsect.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\unistr.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\attrib.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\mft.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\index.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\cache.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\misc.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\dir.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\runlist.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\logfile.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\uefi_io.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\ntfsinternal.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\mst.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\lcnalloc.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\compress.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\bitmap.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\collate.c c:\edk2\NtfsPkg\NtfsDxe\ntfs\security.c

另一个有意思的点是项目路径与Hacking Team的EFI开发项目中找到的路径相同，即Vector-edk。在vector-edk中，有一个子项目NtfsPkg具有完全相同的目录布局。ntfs-3g源代码文件位于同一路径中。虽然这些路径是通用的，但研究人员认为这不是巧合。

将泄漏的源代码与Hex-Rays反编译器输出进行比较，很明显它是同一个项目。图17是比较NtfsDriverBindingStart从vector-edk / NtfsPkg / NtfsDxe / Ntfs.c获取的函数的示例。为清楚起见，已从原始HT的源代码中删除了注释。函数调用的逻辑和顺序是相同的。两个项目甚至使用相同的变量（LockedByMe）来保持锁住的状态。

图17 Sednit的NTFS驱动程序（左）和HT的NTFS驱动程序（右）的Hex-Rays反编译器输出之间的比较

上面的比较显示了Hacking Team开发人员的代码，并没有出现在ntfs-3g开源代码中。

如ReWriter_binary部分所述，在解析固件文件系统时，可执行文件会尝试删除AMI NTFS驱动程序。研究人员想了解为什么删除它而不是使用它。

研究人员分析了驱动程序，发现它只能执行读操作。由于不支持写入文件系统，因此无法将其用于攻击目的。当固件中已经存在另一个NTFS驱动程序时，Sednit团队可能也遇到了一些问题，因此他们只是决定将其删除。除了实现读写操作外，Hacking Team的驱动程序不会强制执行文件权限，例如，覆盖只读文件而不会引发任何错误。

本文已经描述了UEFI rootkit为破坏主机操作系统而执行的各种操作，还讨论了为什么研究人员认为Sednit团队使用Hacking Team的vector-edk的源代码来构建他们的NTFS驱动程序来编写文件的原因。

下文将对SecDxe删除的有效负载进行分析。

autoche.exe与autochk.exe

恶意 autoche.exe 文件用于为 rpcnetp.exe 代理软件赋予长久存在的能力。如图18所示，它使用本机Windows API调用来创建此服务。

图18 恶意autoche .exe设置rpcnetp .exe持久性

服务名称与合法Computrace代理程序使用的名称相同。创建服务后，它会将BootExecute注册表项还原为其先前的值。

图19 恶意autoche .exe恢复BootExecute的原始注册表值

由于此过程在Windows启动时发生，因此用户几乎不会注意到BootExecute注册表项值修改。应该注意的是，autoche .exe与Compu-trace的autochk.exe模块有一些相似之处，例如使用的API调用和服务注册，但其余的则完全不同。Computrace的模块更大，而是恢复原始的autochk .exe可执行文件而不会更改注册表项，它还负责将代理程序置于磁盘中。

总结

修复基于UEFI固件的攻击是一个难题。没有简单的方法来保障系统免受这种威胁，也没有任何安全产品能够完全防御。如果发生本文中描述的情况，需要重新刷新SPI闪存以删除rootkit。对于普通计算用户来说，如果重刷UEFI固件不太可行或者压根找不到可用的BIOS固件，还是建议将主板换成新一点的。

*参考来源： thehackernews ，Freddy编译整理，转载请注明来自 FreeBuf.COM。