【转载】MoonBounce UEFI Bootkit感染分析与取证检测

ANY.LNK

原文地址：https://mp.weixin.qq.com/s?__biz ... 8814193013948416#rd （作者：jishuzhain OnionSec）

CORE_DXE案例分析
D94962550B90DDB3F80F62BD96BD9858（可从VT上获取此样本-转载者注）


感染开始于主板上的SPI闪存，最终利用用户模式下的恶意软件实现通信与控制，整个感染过程本身不会在硬盘上留下任何痕迹，因为感染过程的组件只在内存中运行，因此可检测的方向只能是主板固件、内存与流量。鉴于固件类检测与取证存在不可预料的风险，因此检测的重点应当放置在内存与流量中，最后才是针对固件镜像进行取证检测。

从公开材料中得知位于某用户的主板固件的组件CORE_DXE已被攻击者进行了补丁与植入，后续将逐步引导执行恶意逻辑，因此初步安全检查中在对固件完整性取证校验时会出现存在异常。该组件在UEFI启动顺序DXE（驱动程序执行环境）阶段早期被调用，负责初始化基本数据结构和函数接口，其中包含EFI引导服务表（BootServices）属于CORE_DXE组件本身的一部分，可由其他DXE驱动程序调用。




通过对恶意的CORE_DXE组件的分析发现了内嵌的可疑字符串，经查询可以得知字符串E7846IMS.M30来源于台湾微星公司推出的主板UEFI固件，如下。





UEFI Bootkit分析

通过与上述摘取的启动服务表（BootServices）比对IDA反汇编后EFI_BOOT_SERVICES标注的函数顺序可以定位到三个被hook的函数名称为CreateEventEx（位于最后的sub_18001F10C），CreateEventEx实际调用过程中为CoreCreateEventEx，比对相关的输入参数与内部的协议值，可以确认属于CoreCreateEventInternal函数调用，同理可得到其余被hook的两个函数为AllocatePool与ExitBootServices。





AllocatePool函数（位于顺序第六位的sub_1800233B0），AllocatePool实际调用过程中为CoreAllocatePool，比对相关的输入参数与内部的协议值，可以确认属于CoreInternalAllocatePool函数调用，如下。



ExitBootServices函数（位于顺序第26位的sub_180009F4C），ExitBootServices实际调用过程中为CoreExitBootServices，比对相关的输入参数与内部的协议值，可以确认属于CoreExitBootServices函数调用，如下。



启动服务表（BootServices）提供的接口函数的执行顺序优先于运行时服务表（Runtime Service Table），不过在启动服务表（BootServices）提供的ExitBootServices函数执行之后，启动服务表（BootServices）的函数就不能使用了，但是运行时服务表（Runtime Service Table）的函数仍然可以使用。从DXE阶段开始，一直到操作系统的结束，运行时服务表（Runtime Service Table）一直存在，在操作系统中依然可以调用，因此对ExitBootServices函数进行hook还需进行实现后续驻留逻辑，而该UEFI Bootkit确实实现了后续驻留逻辑。

举例被hook的CoreCreateEventInternal函数，如下。




在运行过程中首先会调用AllocatePool函数，而AllocatePool继续调用CoreInternalAllocatePool，因此CoreInternalAllocatePool函数被插入的hook逻辑将被执行。在hook函数逻辑中会获取被插入hook的函数起始地址，之后比较当前被hook的函数后续字节数据来选择调度进入不同的逻辑流程里。




通过分析得到该处的逻辑主要是进入hook逻辑后，首先恢复CoreInternalAllocatePool函数被hook的字节数据，然后利用CoreInternalAllocatePool创建一个大小为4B000h的缓冲区，最后将内嵌的shellcode数据复制到已分配的上述缓冲区。



内嵌的shellcode数据内部嵌入了恶意的驱动程序（两种架构驱动程序，分别针对x86与x64平台），经过后续分析此处shellcode将在UEFI引导过程中触发传统引导模式（legacy mode boot）时被回调函数调用执行，如下。



第二个被执行的函数为CoreCreateEventEx，内部会调用CoreCreateEventInternal，该处的hook逻辑为首先还原CoreCreateEventInternal函数被hook的字节数据，然后利用CoreCreateEventInternal创建一个EFI_EVENT_LEGACY_BOOT事件并设置通知回调函数。



引导过程中一旦触发EFI_EVENT_LEGACY_BOOT事件将调用执行之前被hook的CoreInternalAllocatePool函数复制的shellcode。



第三个被调用的函数为ExitBootServices，查询对ExitBootServices函数进行hook的公开材料案例可以发现CIA泄露的Vault7材料提及了相关的利用文档。




Vault 7: CIA Hacking Tools Revealed提及的相关技术如下：

ExitBootServices Hooking

https://wikileaks.org/ciav7p1/cms/page_36896783.html

在winload.efi中会对这个函数进行调用，此函数的作用是结束启动服务（EFI Boot Service）标志着操作系统已经加载进内存准备就绪，调用ExitBootServices函数意味着将平台的控制权从UEFI固件转移到操作系统。




该处hook实现的逻辑为获取调用ExitBootServices函数后的下一个地址值，在调用ExitBootServices函数的winload.efi内存中搜索ExitBootServices函数后大小为158878h的范围数据是否匹配OslArchTransferToKernel函数的末尾指令41 55（push r13）与48 CB（retfq）。



在调用CoreExitBootServices函数时，操作系统加载器winload.efi会把控制权交给ntoskrnl.exe。此时winload.efi已被加载在内存中，因此搜索的字节序列41 55 48 CB，可定位到winload.efi中的函数OslArchTransferToKernel，详情如下。



复制sub_18015787E函数前229h大小字节数据到内存地址，接着对OslArchTransferToKernel函数进行补丁，一旦调用OslArchTransferToKernel函数就将执行刚复制的shellcode，如下。



往后执行退出hook函数逻辑，返回到继续执行已恢复的ExitBootServices函数流程。最终控制流将转移到winload.efi（Windows操作系统加载器），在调用OslArchTransferToKernel函数（该函数将控制从操作系统加载器传递到Windows内核（ntoskrnl.exe）），OslArchTransferToKernel函数在控制从操作系统引导加载器转移到内核时被调用，因此当操作系统内核镜像被映射到系统地址空间时，就会触发对OslArchTransferToKernel函数植入的hook，执行上述复制的shellcode代码。该处shellcode执行逻辑如下，主要是利用函数哈希比对获取三个函数地址，分别是ExRegisterCallback（0x42790710）、ExAllocatePool（0x2802057D）与MmMapIoSpace（0x1C88047D），接着修改ntoskrnl.exe的每一个节区的Characteristics字段属性，将CCh长度的shellcode代码复制到ntoskrnl.exe内存镜像的重定位表地址，最终修改ExRegisterCallback函数开头的字节数据，实现跳转到shellcode执行。



该处shellcode执行逻辑为当Windows内核ntoskrnl.exe第一次进入ExRegisterCallback函数内部触发hook调用时会执行shellcode逻辑，等第二次再次进入函数内部触发调用时就会恢复并执行正常的ExRegisterCallback函数逻辑，不再执行shellcode。



当第一次调用执行该处的hook逻辑时，首先将之前被覆写为shellcode_legacy_boot_callback的地址（之前引导阶段利用CoreInternalAllocatePool创建的4B000h大小的缓冲区区域）且长度为28000h的shellcode数据映射到到Windows内核的虚拟地址空间，跳转到已被映射的shellcode_legacy_boot_callback地址执行。

注释


非分页池区（*nt!MmNonPagedPoolStart ~ *nt!MmNonPagedPoolEnd）


非分页池区域紧随在 PFN 数据库之后。非分页池的起始地址存储在内核变量 nt!MmNonPagedPoolStart 中。当调用 MiObtainSystemVa() 时传入 MiVaNonPagedPool 类型的系统虚拟地址范围时，它就会在此区域中分配。内核位图——nt!MiNonPagePoolVaBitmap——控制从非分页池中分配虚拟地址空间的操作，并且，内核变量 nt!MiNonPagedPoolVaBitMapHint 存储其分配提示。这个区域可按需扩大，最多到 128 GB，此区域仅内核模式下能够访问。




该处的shellcode最终将实现从内存解析恶意驱动PE文件，然后加载并执行入口点，将感染流程转移到Windows内核区域，自此UEFI Bootkit感染植入流程结束。




释放并加载的恶意驱动程序会利用APC注入方式注入到svchost.exe进程中，并与C2地址进行交互通信下载下一阶段payload执行。

取证检测
整个感染过程流程如下：



因此根据本案例Bootkit实现与感染原理进行针对性取证检测的过程可分为四个阶段，如下：

第一个阶段
在感染的第一个阶段和以前分析过的固件植入类与ESP Bootkit取证检测流程类似，主要是针对主板固件的完整性扫描与威胁检测，排查是否存在异常的模块或者恶意的模块，可利用FWHunt对提取的固件镜像进行扫描检测是否存在已知威胁（需积累好相关案例特征，补充较为宽泛的恶意或可疑检测规则），利用ChipSec针对固件完整性进行检测。举例说明如下，假设存在待排查的机器，识别到该机器使用的主板型号后获取对应版本的官方固件文件（这里是E7846IMS.M30，来源于微星公司2014年释放的固件）。



获取原始的固件EFI文件列表

chipsec_main.py -i -n -m tools.uefi.scan_image -a generate,efilist.json,uefi.rom

利用原始固件文件列表数据比对核查可疑固件

chipsec_main.py -i -n -m tools.uefi.scan_image -a check,efilist.json,uefi.rom

本案例Bootkit实现原理利用了固件植入型攻击手法，被篡改的固件组件为CORE_DXE，因此利用上述方法可以定位到异常的模块。


第二个阶段

在感染的第二个阶段本案例Bootkit劫持了UEFI引导过程中的Windows操作系统加载器winload.efi以及Windows内核加载模块ntoskrnl.exe，不过Windows操作系统加载器winload.efi在引导过程中虽然内部函数OslArchTransferToKernel尾部被植入了hook，但是在将控制权转移到Windows内核加载模块ntoskrnl.exe后，Windows操作系统加载器winload.efi就已在内存中被卸载了，因此并不会产生可检测的痕迹。接着Windows内核加载模块ntoskrnl.exe加载Windows操作系统过程中对其内部函数ExRegisterCallback头部植入了hook来跳转执行shellcode，不过后续shellcode逻辑虽然恢复了对该函数的正常调用执行流程，但是对其植入的hook代码并未恢复，因此我们可以通过内存取证（检测内核钩子）的方式找到被hook的痕迹。



通过之前的分析得知在整个感染过程中存在多次的植入hook操作，利用ARK工具PCHunter检测内核钩子痕迹的结果存在很多，这在实际场景下需要借助比对才能定位到异常。





借助之前二次开发的相关工具可以定位到被hook的痕迹确实存在于Windows内核加载模块ntoskrnl.exe，如下。



由于在感染过程中Bootkit并未对ntoskrnl.exe进行新增数据操作，而是针对已有数据进行覆写，因此进一步深入调查如若想发现异常也可以通过比对正常系统内核内存dump后的ntoskrnl.exe来查找存在区域被覆写的痕迹，如下ntoskrnl.exe文件的重定位表区域一般情况下不应被改动，如出现较大范围的变动则表示Windows内核加载模块ntoskrnl.exe有可能遭到被覆写。



第三个阶段
在感染的第三个阶段该案例Bootkit会在内存中加载并执行恶意驱动，那么如何在提取整个物理内存dump文件中继续提取出PE文件？


针对中间阶段的恶意驱动文件内存加载执行的取证提出疑问，恶意驱动加载并不是被Windows内核正常流程加载，因此恶意驱动在内存中被加载执行后会不会退出并消除痕迹？

上述两种情况比较特殊，经过本地搭建模拟环境实验比对分析，恶意驱动程序仍旧会存在于内核内存区域。极端情况下，深度取证可在提取的全物理内存dmp文件中可以通过编码搜索PE文件特征确定并找到PE文件起始地址然后利用SizeOfImage字段数值进行数据dump得到内存加载展开后的PE文件，对其中发现的属于驱动程序的PE文件进行逐一排查（优先排除存在数字签名区段的PE文件）。




第四个阶段

在感染的第四个阶段属于用户模式阶段常规取证过程（属于大部分情况下取证场景），通过先前的逆向分析我们可以知道本案例Bootkit会利用在Windows内核加载阶段的ntoskrnl.exe将恶意驱动加载进内核内存执行来对系统的svchost.exe进程实现APC进程注入实现下一阶段驻留，因此检测的重点关注进程注入痕迹，这里由于攻击者并未应用较为深入的反检测手法，因此检测进程注入痕迹在用户模式层面较为简单，如下是手工与工具自动化检测过程。



大部分进程注入场景中，shellcode成功注入并执行后受害进程中会存在具有可执行权限保护的页面，因此针对系统运行的进程可逐一进行内存列表属性排查。



在用户模式场景下针对进程注入痕迹检测，可以利用相关工具进行自动化检测。



由于是比较常见的进程注入手法，工具检测的效果不错，确实提取了之前发现的异常内存区域数据。



常规检测中，如果出现在一定时期内异常流量持续或间断外连行为，可以直接利用进程内存字符串搜索的方式定位是否存在异常进程。



常规检测中，如果无法得知一定时期内异常流量持续或间断外连行为，可借助一些恶意文件经常出现的特征进行搜索排查，例如利用相关加壳痕迹UPX或者MPRESS等。

wwwab

@tdsskiller @wowocock 这是啥玩意儿











和卡巴斯基（Kaspersky）2022年1月份发布的某篇报告是同一个样本，甚至有相同的图片

ANY.LNK

wwwab 发表于 2023-1-11 23:33
@tdsskiller @wowocock 这是啥玩意儿

就是当初卡巴发布的MoonBounce，原文章作者将样本提取并自己再进行了一次分析

tdsskiller

@wowocock

wowocock

tdsskiller 发表于 2023-1-12 00:26
@wowocock

正在做检测工具，支持UEFI BIOS的检测，下次放出来，可以让大家先测试看看。先支持这些检测
typedef enum _UEFI_BOOTKIT_TYPE
{
        type_lojax,
    type_CosmicStrand,
        type_MoonBounce,
        type_unknown,
}UEFI_BOOTKIT_TYPE;

wowocock

wwwab 发表于 2023-1-11 23:33
@tdsskiller @wowocock 这是啥玩意儿

木马植入BIOS的DXE驱动
EFI_STATUS __fastcall ModuleEntryPoint(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
{
  EFI_HANDLE v3; // [rsp+40h] [rbp+8h] BYREF
  __int64 v4; // [rsp+48h] [rbp+10h] BYREF
  __int64 v5; // [rsp+50h] [rbp+18h] BYREF
  __int64 v6; // [rsp+58h] [rbp+20h] BYREF

  v3 = ImageHandle;
  gImageHandle = (__int64)ImageHandle;
  sub_18001C5F0(ImageHandle, SystemTable);
  sub_18001E840(&v3, &v6, &v5);
  qword_180050A90 = sub_180024A88(120i64, &unk_18004BF00);
  off_18004C008 = (void *)sub_180024A88(136i64, &unk_18004BF80);
  *(_QWORD *)(qword_180050A90 + 88) = off_18004C008;
  sub_18001C678();
  sub_180021934(v3);
  sub_18001EB64(&v3, v6, v5);
  gImageHandle = (__int64)v3;
  sub_180022A64(&EFI_DXE_SERVICES_TABLE_GUID_1, off_18004BF78);
  sub_180022A64(&TCG_EFI_HOB_LIST_GUID_3, v3);
  sub_180022A64(&EFI_MEMORY_TYPE_INFORMATION_GUID, &dword_18004D8A0);
  sub_180009EC4(&EFI_STATUS_CODE_RUNTIME_PROTOCOL_GUID, off_18004BCD0);
  sub_180024970(50597888i64);
  sub_180025EC8();
  sub_180025FA4(1i64, qword_180153AD8, qword_180153AD0);
  sub_18001EF44();
  if ( sub_180009EC4(&EFI_DECOMPRESS_PROTOCOL_GUID_0, &qword_180050A20) >= 0 )
  {
    v4 = 0i64;
    sub_1800206BC(&v4, &EFI_DECOMPRESS_PROTOCOL_GUID_0, 0i64, qword_180050A20);
  }
  if ( (sub_180009EC4(&EFI_TIANO_DECOMPRESS_PROTOCOL_GUID, &qword_180050A28) & 0x8000000000000000ui64) == 0 )
  {
    v4 = 0i64;
    sub_1800206BC(&v4, &EFI_TIANO_DECOMPRESS_PROTOCOL_GUID, 0i64, qword_180050A28);
  }
  if ( (sub_180009EC4(&EFI_CUSTOMIZED_DECOMPRESS_PROTOCOL_GUID, &qword_180050A30) & 0x8000000000000000ui64) == 0 )
  {
    v4 = 0i64;
    sub_1800206BC(&v4, &EFI_CUSTOMIZED_DECOMPRESS_PROTOCOL_GUID, 0i64, qword_180050A30);
  }
  sub_180009EC4(&EFI_PEI_FLUSH_INSTRUCTION_CACHE_GUID, &qword_180050A38);
  sub_180009EC4(&EFI_PEI_PE_COFF_LOADER_GUID, &qword_180050A40);
  sub_180009EC4(&EFI_PEI_TRANSFER_CONTROL_GUID, &qword_180050A48);
  sub_180024EA0();
  sub_18001CA8C(qword_180153AD0, qword_180050A90);
  sub_180025E88(qword_180153AD0, qword_180050A90);
  sub_180024EF8(qword_180153AD0, qword_180050A90);
  sub_18001C6C0();
  sub_18001D430();
  sub_18001D46C();
  if ( (sub_180024C8C() & 0x8000000000000000ui64) != 0 )
    sub_18001C7E4();
  sub_180024970(50597889i64);
  (*(void (__fastcall **)(__int64))qword_180050A78)(qword_180050A78);
  while ( 1 )
    ;
}