Shade BIOSUnleashing the Full Stealth of UEFI Malware

技术深度分析报告：Shade BIOS: Unleashing the Full Stealth of UEFI Malware

1. 摘要与背景设定 (Executive Summary & Stage Setting)

• 1.1 演讲元数据 (Talk Metadata):

  • 会议/活动 (Conference): Black Hat Briefings
  • 演讲标题 (Title): Shade BIOS: Unleashing the Full Stealth of UEFI Malware
  • 主讲人 (Presenter(s)): Kazuki Matsuo (@InfPCTechStack)
  • 年份/日期 (Year/Date): 2025/08/06

• 1.2 技术执行摘要 (Technical Executive Summary): 本次Black Hat演讲揭示了一种名为“Shade BIOS”的颠覆性技术，它彻底重塑了UEFI恶意软件的隐蔽性和通用性。长期以来，UEFI恶意软件虽拥有极高的特权等级，却始终受困于对操作系统（OS）和特定硬件的依赖，这使其在实际攻击中容易被检测，且难以广泛部署。Shade BIOS的核心突破在于，它成功地在操作系统启动后，仍然在内存中保留并激活完整的BIOS环境，使其能够独立于OS执行任意代码，并利用UEFI驱动程序与硬件进行交互。

  这项创新使得恶意软件首次实现了真正的“纯BIOS”运行，不仅能够完全规避操作系统层面的安全机制（如EDR/AV），还极大地降低了对特定硬件的依赖，实现了前所未有的设备无关性。Shade BIOS的出现，标志着UEFI恶意软件进入了一个全新的隐蔽时代，对当前的安全防御体系提出了严峻挑战，迫使业界重新思考和部署针对底层固件的检测与防御策略。

• 1.3 故事的开端：挑战与动机 (The Story Begins: The Challenge & Motivation): 在当今高度互联的数字世界中，UEFI（统一可扩展固件接口）的安全已成为国家安全和云安全领域不可忽视的基石。正如图3所示，BIOS作为计算机启动的第一道防线，其供应链涉及众多厂商，远比操作系统、虚拟机管理器（VMM）或CPU更为复杂。历史事件，如Vault 7和vector-edk等泄露的文档和工具包，都清晰地证实了UEFI安全在情报和攻击领域的重要性，它被视为安装持久性后门和实现云环境虚拟机全面控制的理想场所。

  然而，尽管UEFI拥有至高无上的权限，现有的UEFI恶意软件却面临着一系列固有的局限性。无论是野外发现的UEFI引导套件（如Lojax-BlackLotus），还是泄露的BIOS/UEFI后门（如Jetplow、vector-edk），它们的核心问题在于其恶意行为最终仍需在用户态或内核态执行，这意味着它们本质上并非“纯BIOS”恶意软件。图4和图5详细阐述了这种对操作系统层级安全的依赖性：这些恶意软件需要通过模式匹配等方式禁用DSE（驱动签名强制）或Patch Guard等OS安全机制，一旦OS更新或模式改变，它们就可能失效并被检测。攻击者渴望摆脱这种束缚，实现“我们不想关心操作系统！”的终极目标，正如图6所提出的疑问：“为什么不完全使用BIOS来实现所有功能？”

  

  除了操作系统依赖，现有UEFI恶意软件还普遍存在硬件依赖性。图8展示了诸如DEITYBOUNCE、DerStarke等泄露的BIOS后门，它们往往针对非常特定的硬件平台，需要设备特定的实现。即使是研究领域中一些纯SMM（系统管理模式）后门，如图9所示的USB键盘记录器，也需要直接读写USB主机控制器寄存器，这意味着攻击者必须深入理解特定设备的硬件规范。这种设备依赖性极大地限制了恶意软件的通用性和部署范围。

  

  更具挑战性的是，BIOS环境在操作系统启动后大部分会被销毁，如图7所示，引导服务（Boot Services）和协议（Protocols）等接口将不可用，使得设备访问和与C2服务器通信变得异常困难。直接进行I/O操作需要实现完整的驱动栈，这不仅复杂，而且同样导致设备依赖。这种“BIOS无所不能”的说法，在实际操作中却陷入了图10所描绘的困境：恶意代码在BIOS层级实现难度高，且易受OS和硬件依赖的制约，这严重压制了BIOS恶意软件的潜力。

  

  此外，最新的SMM隔离技术（ISRD & ISSR），如图11所示，进一步限制了SMM后门的有效性，非Intel模块的SMM访问受到严格限制，OS内存区域和SMM页表变得不可访问，I/O访问也受到限制。这使得攻击者的目光转向了运行时DXE模块，图12指出，运行时DXE模块在SMM隔离生效后，反而比SMM模块更具优势，因为它能够访问OS内存和所有I/O。面对这些挑战，研究者提出了一个大胆的设想：能否让一个“攻击者专属的迷你OS”——BIOS，在主操作系统启动后，仍然静默地并行运行？这正是Shade BIOS所要挑战的“巨龙”。

  

2. 核心技术探索之旅 (The Core Technical Journey)

面对上述困境，研究者提出了一个大胆的设想：在操作系统启动后，仍能让BIOS环境及其功能在内存中持续运作，从而实现一个完全独立于OS、且具备通用硬件交互能力的“迷你BIOS操作系统”。这趟旅程并非一帆风顺，首先摆在他们面前的就是如何“保留BIOS在内存中”的核心挑战。在常规的系统流程中，UEFI的DxeCore模块管理着实际的内存映射，图15清晰地展示了这一过程：操作系统加载器通过调用gBS->GetMemoryMap()获取内存映射副本，并根据其中的EFI_MEMORY_TYPE来决定哪些区域可用。遗憾的是，BIOS代码和数据所在的EfiBootServicesCode/Data区域在gBS->ExitBootServices()调用后，通常会被操作系统覆盖或释放，使得它们的持续存在成为一个障碍。

为了绕过这堵高墙，研究团队的突破口在于一个精妙的观察：虽然实际内存映射由DxeCore管理，但操作系统加载器所依赖的只是gBS->GetMemoryMap()返回的内存映射“副本”。基于此，他们设计了一种前所未有的技术方案。通过Hook（钩取）gBS->GetMemoryMap()函数，Shade BIOS能够在返回给OS加载器之前，修改这个内存映射副本。具体而言，它将原本属于BootServices类型的内存区域（如EfiBootServicesCode和EfiBootServicesData）重新分类为RuntimeServices类型，如图16所示。这种“魔法”所在：当OS加载器请求内存映射时，它会收到一个被篡改的副本，其中BIOS代码所在的区域被标记为运行时服务，从而欺骗OS认为这些区域是运行时可用的，并避免对其进行覆盖或释放。这种方法的高明之处在于，它并未修改DxeCore中实际的内存映射，因此不会影响BIOS自身的内存管理逻辑，同时又成功地让BIOS在操作系统启动后得以“幸存”。

解决了生存问题后，新的挑战接踵而至——如何让这些被保留的BIOS代码在运行时正常工作？这涉及到一系列复杂的内存管理、虚拟化、资源和设备控制问题，正如图17所列举的。

首先是运行时内存管理。BIOS自身的内存分配器（如gBS->AllocatePages()）在运行时会认为所有OS内存区域都是空闲的，并可能从中分配内存，这与OS的内存使用发生冲突，图18就很好地说明了这种潜在的冲突。为了解决这一问题，Shade BIOS采取了一种巧妙的策略：它在EfiConventionalMemory中预留出部分区域专供BIOS使用。具体做法是，在Hook gBS->GetMemoryMap()时，除了将BootServices类型改为RuntimeServices外，还会将这些预留的EfiConventionalMemory区域也标记为RuntimeServicesCode/Data。同时，它会从BIOS自身维护的实际内存映射（gMemoryMap）中“解链”那些将被OS使用的EfiConventionalMemory区域，如图19所示，但会保留那些被标记为RuntimeServicesCode/Data的预留区域。这样，OS会避开这些被标记的区域，而BIOS的内存分配器也只会从这些被保留的、未被OS占用的EfiConventionalMemory中进行分配，从而避免了冲突。

其次是虚拟化内存的挑战。非运行时BIOS代码通常假定它们在物理地址上执行，并可能包含硬编码的物理地址或全局指针。虽然不能简单地创建一个身份页表并将其设置为CR3（因为当前指令在虚拟地址上执行），但Shade BIOS借鉴了“部分身份映射”的思想。图20解释了这一策略：运行时DXE驱动程序通常使用高规范虚拟地址，不需要修改PML4[0]；而身份分页仅需操作PML4[0]。因此，Shade BIOS的运行时DXE驱动程序在正常情况下运行在虚拟地址空间，只有在访问物理地址时，才临时切换当前页表中的PML4[0]到身份映射，从而实现对物理地址的访问，兼顾了兼容性和效率。

再者是引导时资源的持久化问题。在操作系统启动后，许多UEFI引导时才存在的资源，如EFI SYSTEM TABLES和EFI BOOT SERVICES，会被释放或变得不可用；同时，许多UEFI变量缺乏运行时（RT）属性，导致在OS启动后无法读写。图21展示了解决方案：Shade BIOS在引导时复制这些关键的表和变量，并在运行时恢复它们。对于缺乏RT属性的UEFI变量，它Hook了gRT->SetVariable()函数，在写入新变量时为其添加RT属性，并将其保存到新的变量中，确保了这些变量在运行时仍可被正确访问和修改。

接下来是设备设置的控制。在操作系统启动后，OS的设备驱动程序会重新初始化设备，并覆盖掉BIOS在引导时设置的寄存器，如USB主机控制器中存储命令环地址的CRC寄存器，图22清晰地描绘了这一冲突。为了在不了解具体设备寄存器细节的情况下夺取设备控制权，Shade BIOS巧妙地利用了UEFI驱动模型。图23展示了UEFI驱动程序如何通过gBS->ConnectController()和gBS->DisconnectController()函数来初始化和重置设备，并安装相应的协议栈（如HTTP协议、网络协议）。Shade BIOS正是利用了这一通用接口，实现了设备无关的控制劫持。

图24详细拆解了劫持设备控制的两个关键步骤：首先，调用gBS->DisconnectController()来重置设备，这将断开OS对设备的控制；接着，调用gBS->ConnectController()来重新初始化设备，并为BIOS安装所需的协议栈（例如，网络驱动）。通过这种方式，Shade BIOS能够无缝地从OS手中接管设备控制权，而无需编写设备特定的代码。当然，在恶意行为完成后，还需要将设备控制权返还给OS。图25指出，幸运的是，OS驱动程序通常具备自修复能力，例如网卡连接在短暂中断后会自动恢复。然而，手动恢复MMIO空间（内存映射I/O）中的所有寄存器设置是极其困难的，因为某些寄存器触发的是设备动作而非仅仅存储数据，并且这会重新引入设备依赖性。因此，如何优雅地解决“设备控制返回问题”是Shade BIOS面临的一个关键挑战。

最后，也是至关重要的一点是独占控制。由于Shade BIOS会修改页表和设备设置，它必须确保在执行BIOS代码时，操作系统代码被完全排除在外。这意味着需要有效地抑制中断。图26解释道，传统的CLI/STI（清除/设置中断标志）指令并不可靠，因为BIOS代码中可能存在大量的STI指令会重新启用中断。因此，Shade BIOS选择了一种更强硬的手段：通过将CR8（任务优先级寄存器）设置为最大值0xF，从而阻塞所有外部中断，为BIOS代码的执行创造一个纯净的、不受干扰的环境。

然而，BIOS自身也需要中断，特别是定时器中断（用于gBS->SetTimer()注册的定时器事件）。虽然许多UEFI驱动程序依赖轮询机制，并且在没有实际中断的情况下也能正常工作，但Shade BIOS依然能够通过迭代定时器事件列表，并手动触发它们的NotifyFunction来模拟中断，如图27所示。这意味着Shade BIOS可以利用OS的IDT（中断描述符表）来模拟定时器事件，从而在不依赖真实中断的情况下，维持BIOS功能的正常运行。

图28总结了Shade BIOS实现OS与硬件独立性的关键步骤：通过Hook gBS->GetMemoryMap()来保留BIOS，并通过一系列精巧的内存管理（预留EfiConventionalMemory）、虚拟化（部分身份映射）、资源持久化（复制引导时资源）、设备劫持（Disconnect/ConnectController）和独占控制（阻塞中断、模拟定时器事件）技术，使得保留的BIOS代码在运行时能够正常且隐蔽地工作。

3. 成果、影响与对策 (Outcomes, Impact & Countermeasures)

• 3.1 技术成果的展现 (Showcasing the Outcome): Shade BIOS的最终成果是一套能够实现真正OS独立和设备无关的UEFI恶意软件框架。图29清晰地对比了现有UEFI恶意软件与Shade BIOS的差异：传统恶意软件在Ring 3或Ring 0与OS进行交互时（如NtCreateFile），会触发OS层面的检测（如ETW日志）或EDR/AV过滤驱动的拦截。而Shade BIOS则通过直接利用被保留的UEFI驱动（例如FileProtocol->Open），完全绕过了这些OS层面的安全机制，使得C2通信和文件访问等恶意行为对OS和安全产品而言是完全不可见的，实现了“无风险”的隐蔽性。

  

  更令人印象深刻的是其设备独立性。图30展示了Shade BIOS的核心代码，它通过gBS->ConnectController和gBS->DisconnectController等通用UEFI服务来控制网络接口卡（NIC），而无需直接访问I/O寄存器或编写设备特定代码。这意味着同一段恶意代码可以在不同厂商、不同型号的笔记本电脑上运行，例如图中所示的EPSON Endeavor笔记本，实现了极高的通用性。图31和图36的演示截图直观地展示了这一成果：一台受害者机器在运行Shade BIOS后，能够与C2服务器建立连接并进行数据传输，而C2服务器端则显示成功监听并接收数据，整个过程在OS层面无迹可寻。

  

• 3.2 现实世界的影响 (Real-World Implications): Shade BIOS的出现，深刻地改变了我们对UEFI恶意软件威胁的认知。它暴露了当前安全防御体系的根本性盲区：长期以来，安全产品主要聚焦于操作系统内部的检测和行为分析，而Shade BIOS则证明了恶意行为可以完全在OS的“眼皮底下”进行，使得这些被认为是安全的假设失效。它对开发者、运维人员和安全从业者发出了严峻警示：仅仅加固OS层面的安全已远远不够，对底层固件的威胁感知和防御能力亟待提升。

  尽管Shade BIOS在实现完全独立性方面仍有一个微小的限制——它仍需要调用Windows内核的nt!MmGetVirtualForPhysical()函数来获取页表的虚拟地址，但图32指出，BIOS可以通过复制和修补这段汇编代码来绕过OS的拒绝，从而消除这一依赖性。此外，图33强调，Shade BIOS通过隔离恶意行为中最可疑的部分（如内存属性修改、网络数据拦截），使得仅仅读取内存内容本身并不会触发OS层面的检测，进一步增强了其隐蔽性。

  

• 3.3 防御者的行动指南 (An Actionable Playbook for Defenders): 面对Shade BIOS这类纯BIOS恶意软件，传统的OS或AV/EDR产品几乎无法观察到其恶意行为，C2通信和文件访问等操作完全在OS的视野之外。因此，防御者必须转向更深层次的“预防性检查”和“内存取证”方法，正如图34所强调的。

  首先，最佳检测方法是内存取证。Shade BIOS作为运行时DXE驱动程序，会被映射到高规范地址空间。防御者可以从内核层面（例如使用类似kraft dinner的工具）将其内存映像Dump下来，然后进行静态分析。由于运行时服务和代码量相对较小，分析工作并非不可行。

  其次，需要警惕Shade BIOS可能带来的副作用。在Shade BIOS执行恶意行为后，被使用的设备可能会短暂冻结，直到OS驱动程序进行自修复。因此，频繁的设备错误或异常行为可能是Shade BIOS存在的迹象。然而，执行频率取决于攻击者的需求，这使得基于副作用的检测更具挑战性。

  对于更广泛的纯BIOS恶意软件，图35提供了更全面的检测指南：

  • 针对SMM模块实现的恶意软件： 检查SMM隔离是否启用。如果已启用，通过Windows的“系统信息”检查PPAM报告的SMM隔离级别。如果未启用，则需要分析SPI闪存并逆向工程所有UEFI模块。
  • 针对运行时DXE模块实现的恶意软件： 从高规范地址转储运行时DXE模块，并应用内存取证技术来识别异常。

  这些检查对于通过政府采购获得的系统尤为关键，因为这些系统可能面临更高风险的供应链攻击。演讲者也呼吁，目前BIOS安全研究仍然不足，需要探索更多的攻击和防御方法。

  

4. 总结与展望 (Conclusion & The Road Ahead)

• 4.1 核心洞见 (Core Insights):

  • 现有UEFI恶意软件受限于对操作系统和特定硬件的依赖，易于被检测。
  • Shade BIOS成功突破了这些限制，实现了真正的OS独立和低硬件依赖的UEFI恶意软件。
  • 传统OS层面的安全防御机制对Shade BIOS无效，无法观察到其恶意行为。
  • BIOS确实可以被改造为一个在操作系统启动后静默运行的“迷你OS”，这颠覆了传统安全边界。
  • 预防性检查和内存取证是检测纯BIOS恶意软件的唯一有效途径。

• 4.2 未来的探索方向 (Future Avenues of Exploration): Shade BIOS的成功仅仅是冰山一角，未来的研究方向广阔且充满挑战。为了进一步提升Shade BIOS的成熟度和能力，可以探索以下几个方面：

  • 加速OS设备设置的修复或探索替代策略： 优化设备控制权的交还机制，减少或消除对OS自修复的依赖，提升隐蔽性和稳定性。
  • 扩展硬件支持并测试多样化的BIOS实现： 确保Shade BIOS能在更广泛的硬件平台和不同的BIOS固件上稳定运行。
  • 支持不遵循UEFI驱动模型规范的UEFI驱动： 提升兼容性，使其能够利用更多非标准化的底层驱动。
  • 启用更多额外的UEFI功能： 进一步丰富Shade BIOS作为“迷你OS”的能力，使其能够执行更复杂的恶意任务。
  • 深入研究绕过SMM隔离的SMM后门： 尽管SMM隔离技术日益成熟，但SMM（Ring 0）后门仍可能提供比运行时DXE模块更深层次的隐蔽性。未来的工作应着重调查如何绕过SMM隔离，并开发相应的检测技术。

  正如演讲所强调的，这项工作“就像是制造一个小型操作系统”，它为未来的底层固件安全研究指明了方向，也预示着一场更为深远的攻防对抗即将展开。