APT41将恶意程序Moonbounce写入UEFI固件

2022-02-17

原创字数统计: 1.9k字 | 阅读时长: 7min

1. 概述

APT41早在2012年就开始活跃。据观察，该小组针对14个国家/地区的医疗保健，电信，技术和视频游戏行业,也进行一些经济私利驱动的入侵，尤其针对视频游戏产业，包括偷窃源代码和数字证书，虚拟货币操纵和尝试部署勒索软件。

卡巴斯基2022年曝光了恶意程序Moonbounce,并将其归因于APT41。恶意程序修改了UEFI固件中的dxe驱动文件。因为它不是存储在硬盘中,因此在格式化硬盘或者更换硬盘时不会清除恶意程序。

修改后的dxe驱动文件能够拦截和引导UEFI启动的流程,引入一个复杂的感染链,并且只在内存中运行,硬盘上没有留下攻击痕迹。这样的bootkit不仅更隐蔽而且更难以缓解。

2. 样本信息

UEFI固件中被修改的dxe驱动详细文件信息如下:

文件名	Core_dxe
Md5	2d4991c3b6da35745e0d4f76dffbca56
文件类型	EFI_BOOT_SERVICE_DRIVER

映射到内存的驱动

MD5	2ce20fbf09f74a819486a7815ae8e47d
文件类型	Kernel driver

驱动APC注入到svchost的dll文件

MD5	bcf786ac5cfe3b6e9ceacc6733827355
文件类型	Dll

3. 流程图

3. 详细分析

3.1 UEFI启动过程

UEFI启动操作系统的过程如下：

完成UEFI平台初始化,完成CPU和芯片初始化。加载UEFI平台模块。
UEFI boot manager枚举外部设备,加载UEFI设备驱动,加载boot应用。
Windows boot manager(bootmgfw.efi)加载winows boot loader。
Windows boot loader加载windows操作系统。

图1-来源:书籍 Rootkits and Bootkits

图1中标箭头的地方是bootkit攻击UEFI固件常用的攻击点,主要有以下几点:

修改未签名UEFI Option ROM里UEFI DXE驱动,使恶意代码能够在dxe stage执行。
修改UEFI固件中已经存在或者添加新的UEFI dxe驱动,使恶意代码能够在dxe stage执行。
替换windows boot manager,在UEFI固件将控制权交给系统bootloader时恶意代码得到执行。
添加新的bootloader

3.2 CORE_DXE

查看PE结构得知,subsystem为”EFI_driver_boot_service”,即64位的UEFI dxe驱动。

该dxe驱动编译时间为2014年,直到2022年1月份才被卡巴斯基曝光,由此可说明其隐蔽性。

从core_dxe发现一个字符串常量”E7846IMS.M30”,它就是core_dxe对应的UEFI固件名,由台湾微星公司硬件平台发布的固件更新。原core_dex文件与被修改的文件非常相似,除了三个被hook的函数。

1. EFI_BOOT_SERVICE hook

通过对efi_boot_service结构体中的三个函数进行hook,以下被hook的代码先恢复prologue,然后实现hook代码,然后返回原代码执行原流程。以下位各个被hook函数实现的hook代码。

coreAllocatePool用于分配存放驱动映射的shellcode的内存。
coreCreateEventEx用于创建传统启动方式的事件,将驱动映射的shellcode设为其回调函数。
ExitBootService 对函数OslArchTransferToKernel进行hook。

Hook后的代码如下,采用inline hook的方式将函数头部改为跳转到hook_dxe_code,三个函数都是跳转到同一个函数。

2. CoreAllocatePool函数分析

dxe驱动入口点函数为ModuleEntryPoint,创建全局结构体gDxeCoreST和gDxeCoreRT并为其分配内存时调用AllocateRuntimeCopyPool函数分配。

AllocateRuntimeCopyPool内部调用coreAllocatePool函数分配内存。

CoreAllocatePool为被hook的函数,因此进入hook_dxe_code函数。首先恢复prologue,现在rax指向的函数CoreAllocatePool没有被hook,使用”call eax”调用原函数分配内存存放用来映射windows 内核驱动的shellcode。

由于地址”rbx+0xB3”为函数CoreAllocatePool的第三个参数,分配内存成功时将该地址被覆盖成内存地址。

rbx+0xB3所在地址0x1801577EB的magic数字0x1122334455667788刚好被覆盖成刚分配的内存地址。

地址0x180157996(shellcode_1)处的shellcode第一条指令也有magic数字0x1122334455667788用刚分配的内存地址覆盖。

3. CoreCreateEventEx分析

首先恢复函数prologue,调用原函数创建针对EFI_EVENT_Legacy_BOOT的事件,回调函数被设置成地址0x1801577E7处的shellcode。当启动方式为传统启动方式时,以回调函数的形式执行0x1801577E7的shellcode,

传统启动方式启动时,直接执行驱动映射的shellcode将驱动映射并执行,如果是UEFI启动方式还需要做一些额外的工作。

4. CoreExitBootServices分析

首先恢复函数prologue。

查找函数OslArchTransferToKernel尾部指令,0xCB485541对应的指令为“push r13” 和”retfq”,将”retfq”指令修改成跳转指令”jmp 0x98000”。

5. OslArchTransgerToKernel分析

该函数的主要功能是将控制权从winload.exe或者winload.efi交接给内核入口点KiSystemStartup,在这里进行内核初始化。由于返回指令被修改,当初始化完准备返回时跳转到地址0x98000执行代码。Shellcode主要功能是找到ntoskrnl.exe的模块基址,保存到全局变量g_ntoskrnl_exe_image_base。
将地址0x18015791C处的shellcode拷贝到ntoskrnl的重定位表处,Inline hook函数ExAllocatePool跳转到shellcode2_hook。