1. UEFI安全监控基础与威胁场景

1.1 UEFI在系统启动中的核心作用

UEFI（统一可扩展固件接口）作为传统BIOS的现代替代方案，承担着计算机系统从加电到操作系统加载前的所有初始化工作。与BIOS相比，UEFI提供了模块化设计、更快的启动速度以及更强的安全特性。其执行流程主要分为以下几个阶段：

1. SEC（安全验证）阶段：验证初始代码完整性
2. PEI（EFI前初始化）阶段：基本硬件初始化
3. DXE（驱动执行环境）阶段：加载驱动程序和服务
4. BDS（启动设备选择）阶段：准备启动设备
5. TSL（临时系统加载）阶段：操作系统加载器运行
6. RT（运行时）阶段：操作系统运行后UEFI服务调用

在DXE阶段，系统会构建Boot Services和Runtime Services两大核心服务表。这些服务表包含函数指针，供后续阶段调用关键功能如内存分配、图像加载等。正是这些服务表成为攻击者的主要目标。

1.2 UEFI面临的典型安全威胁

现代UEFI固件面临的威胁主要分为以下几类：

服务表钩子攻击： 攻击者通过修改Boot/Runtime服务表中的函数指针，将其重定向到恶意代码。例如Glupteba bootkit会挂钩LoadImage服务，在每次加载系统组件时注入恶意代码。这类攻击的技术特点包括：

• 修改服务表函数指针
• 伪造CRC校验值掩盖修改
• 通过非标准路径加载驱动（如ESP分区）

Secure Boot绕过： 利用签名验证漏洞或合法证书滥用，加载未授权组件。BlackLotus就是典型代表，其技术实现涉及：

• 利用CVE-2022-21894等漏洞
• 向MOK（Machine Owner Key）列表添加恶意证书
• 加载伪装成GRUB的恶意加载器

文件系统持久化： 在UEFI阶段访问文件系统植入持久化后门。LoJax rootkit采用的技术包括：

• 注册READY_TO_BOOT事件回调
• 加载NTFS驱动访问系统分区
• 在启动目录植入恶意组件

多组件协同攻击： 通过多个DXE驱动配合，使用NVRAM变量作为感染标记。MosaicRegressor的典型行为包括：

• 创建特定NVRAM变量（如'fTA'）
• 多个相关GUID的组件协同工作
• 在启动过程中投放用户态payload

1.3 传统防御方案的局限性

现有UEFI安全方案主要存在以下不足：

静态分析的局限：

• 基于签名的检测无法应对未知威胁
• 无法捕获运行时行为异常
• 对服务表钩子等动态攻击无效

动态分析的挑战：

• 缺乏轻量级的运行时监控机制
• 性能开销影响系统启动速度
• 日志完整性难以保证

企业集成缺口：

• 与企业安全运维体系（SIEM等）脱节
• 缺乏统一的威胁分析平台
• 难以实现跨设备关联分析

2. Peacock框架架构设计

2.1 整体技术架构

Peacock框架采用三层设计实现端到端的UEFI安全监控：

UEFI Agent：

• 作为首个DXE驱动加载
• 挂钩关键Boot/Runtime服务
• 记录服务调用参数、调用者等信息
• 将日志扩展至TPM PCR寄存器

OS Agent：

• 在操作系统启动后激活
• 收集UEFI阶段生成的日志
• 使用TPM进行远程证明
• 通过安全通道传输至Peacock Server

Peacock Server：

• 验证日志完整性
• 解析原始日志为结构化数据
• 转发至SIEM系统进行分析
• 生成统一安全事件告警

2.2 关键技术创新点

运行时服务监控： 通过修改EDKII代码，在以下关键服务中植入日志点：

EFI_STATUS EFIAPI LoggedLoadImage( IN BOOLEAN BootPolicy, IN EFI_HANDLE ParentImageHandle, IN EFI_DEVICE_PATH_PROTOCOL *FilePath, IN VOID *SourceBuffer OPTIONAL, IN UINTN SourceSize, OUT EFI_HANDLE *ImageHandle ) { LOG_ENTRY(LoadImage, BootPolicy, ParentImageHandle, FilePath); EFI_STATUS status = OriginalLoadImage(BootPolicy, ParentImageHandle, FilePath, SourceBuffer, SourceSize, ImageHandle); LOG_EXIT(LoadImage, status); return status; }

日志完整性保护： 采用TPM2.0的PCR扩展机制保证日志不可篡改：

1. 每个日志条目生成SHA256哈希
2. 将哈希值扩展到PCR[12]寄存器
3. 启动阶段生成TPM引用证明
4. 服务器端验证PCR值与重新计算的日志哈希是否一致

企业级集成方案： 通过以下流程实现与Splunk等SIEM系统的深度集成：

1. Peacock Server将日志转为JSON格式
2. 使用Splunk Universal Forwarder传输
3. 预置针对UEFI威胁的SPL检测规则
4. 支持与EDR告警关联分析

3. 核心实现与部署细节

3.1 UEFI Agent实现

日志条目结构设计：

内存管理策略：

• 使用UEFI内存池分配日志缓冲区
• 采用环形缓冲区设计防止溢出
• 每100ms或缓冲区50%满时触发PCR扩展
• 保留最后3次启动日志供取证分析

3.2 远程证明流程

证明数据包结构：

{ "tpm_quote": "base64编码的TPM签名", "ak_pub": "证明密钥公钥", "pcr_values": { "12": "PCR12当前值" }, "nonce": "随机数(防重放)", "log_digest": "日志计算的PCR预期值", "raw_logs": "加密的原始日志" }

服务器端验证步骤：

1. 验证TPM签名有效性
2. 检查nonce新鲜性（防止重放）
3. 重新计算日志哈希并与PCR值比对
4. 验证证书链完整性
5. 解密日志并执行结构化解析

3.3 物理设备部署实践

在System76 Adder WS设备上的部署要点：

硬件配置要求：

• 支持TPM2.0的芯片组
• 至少2MB空闲固件存储空间
• 预留50MB内存供日志缓冲
• 启用UEFI安全启动（验证Agent签名）

性能优化参数：

[PeacockConfig] LogLevel = 3 # WARNING级日志 MaxLogEntries = 100000 PCRExtendInterval = 100ms MonitorServices = LoadImage,StartImage,CreateEventEx

4. 威胁检测实战分析

4.1 Glupteba服务表钩子检测

攻击特征：

• 从ESP分区加载EfiGuardDxe.efi
• 修改LoadImage服务指针
• 重计算服务表CRC32校验值

SPL检测规则：

hooked_service=true hooked_by_driver="\\EFI*" whitelisted_hooking_driver=false | stats count by hooked_service, hooked_by_driver, event_type | sort -count

关键指标：

• 非白名单驱动修改服务指针
• 驱动加载路径包含ESP分区
• 短时间内多次服务表修改

4.2 BlackLotus Secure Boot绕过

攻击特征：

• 加载grubx64.efi（Windows环境）
• 访问ESP:\system32\非常规路径
• 修改MokList NVRAM变量

SPL检测规则：

(event_type="LoadImage" OR event_type="StartImage") args="*grubx64.efi*" | stats count by caller, args, status

关联分析：

• 结合TPM测量日志验证启动组件完整性
• 检测未签名的DXE驱动加载
• 监控NVRAM变量异常修改

4.3 LoJax文件持久化检测

攻击特征：

• 注册READY_TO_BOOT回调
• 密集查询DiskIo/BlockIo协议
• 快速连续访问多个分区

行为模式检测：

event_type="CreateEventEx" args="*7CE88FB3-4BD7-4679-87A8-A8D8DEE50D2B*" | stats count by caller, args | sort -count

时间序列分析：

• 回调注册后5秒内出现分区访问
• 非常规驱动加载NTFS协议
• 高频文件读写操作

5. 企业级部署最佳实践

5.1 规模化部署架构

集中式管理方案：

[设备] --HTTPS--> [区域Peacock代理] --TLS--> [中心Peacock集群] ↓ [本地SIEM实例] [企业SIEM]

关键配置参数：

# peacock-server.yaml attestation: max_clock_skew: 300s allowed_ak_certs: /etc/peacock/trusted_aks/ crl_refresh_interval: 1h logging: splunk: index: uefi_logs sourcetype: peacock:uefi local_storage: /var/lib/peacock/raw_logs

5.2 安全策略配置

访问控制策略：

1. 基于TLS双向认证的设备注册
2. TPM证明密钥轮换（建议90天）
3. 基于属性的访问控制（ABAC）模型：

   class AccessPolicy: def check(self, device): return (device.pcr_policy_match and device.cert_valid and device.in_allowed_geoip)

日志保留策略：

• 原始日志：加密存储30天
• 解析后日志：1年（压缩存储）
• 告警事件：永久保存

5.3 运维监控指标

关键性能指标：

健康检查脚本示例：

#!/bin/bash # peacock-healthcheck.sh # 检查服务状态 systemctl is-active peacock-agent || echo "Agent not running" # 检查日志堆积 LOG_COUNT=$(find /var/lib/peacock/ -name "*.log" | wc -l) [ $LOG_COUNT -gt 1000 ] && echo "Log backlog detected" # 检查TPM状态 tpm2_pcrread sha256:12 || echo "TPM communication error"

6. 高级分析与取证应用

6.1 时间线重建技术

取证分析流程：

1. 提取TPM签名的日志副本
2. 按session_id和uefi_timestamp排序
3. 标记关键事件（如驱动加载、服务调用）
4. 可视化异常事件时间序列

示例时间线片段：

6.2 内存取证集成

UEFI内存分析技术：

1. 通过CrashDump获取运行时内存
2. 扫描服务表指针异常
3. 检测未签名的DXE驱动
4. 验证日志与内存状态一致性

内存签名检测规则：

def detect_hooks(memory_dump): bs = locate_boot_services(memory_dump) for func in bs.functions: if not in_text_section(func.address): log_hook_violation(func.name, func.address)

6.3 威胁狩猎场景

假设驱动场景：

• 检测异常NVRAM访问模式
• 追踪跨多个设备的相似GUID
• 识别非常规的文件系统访问

狩猎查询示例：

event_type="SetVariable" args="*VariableName:'fTA'*" | stats count by caller, session_id | where count > threshold

7. 框架局限性与演进方向

7.1 当前技术限制

部署约束：

• 需修改固件集成UEFI Agent
• 对旧版TPM1.2支持有限
• ARM架构适配仍在进行中

安全边界：

• 无法防护Agent加载前的攻击
• 同权限级别的对抗可能绕过监控
• OS Agent可能被高级攻击者禁用

7.2 未来演进路线

硬件增强方案：

• 与Intel PTT/AMDfTPM深度集成
• 利用SGX保护日志处理流程
• 基于DPU的离线日志收集

检测能力提升：

• 机器学习驱动的异常检测

  class AnomalyDetector: def train(self, normal_logs): self.model = IsolationForest() self.model.fit(preprocess(normal_logs)) def predict(self, new_log): return self.model.score_samples(preprocess(new_log))

• 自动化规则生成引擎
• 跨设备威胁关联分析

管理功能扩展：

• 基于区块链的证明存证
• 细粒度策略管理控制台
• 与Kubernetes安全方案集成