Category: APT攻击

摘要 Windows 安全引用监视器是对象访问的最后仲裁者，其访问检查逻辑沿 AuthzBasep 单向链表回溯安全描述符，为用户态权限评估提供“足够快”的缓存答案。然而，该缓存与内核态真实安全描述符之间存在可被精确操纵的传播延迟。攻击者通过在 NtSetSecurityObject 修改 DACL 与 AuthzAccessCheck 读取缓存之间制造 TOCTOU 窗口，可迫使 SRM 基于过期的权限授予访问令牌，造成“用户态通过、内核态拒绝”的悖论权限提升。 Windows 访问检查的分裂模型 安全引用监视器的两条路径 Windows 对对象（文件、注册表、进程）的访问控制由内核模式安全引用监视器集中裁决。当用户态应用程序请求 CreateFile 时，最终会调用 SeAccessCheck（内核态）进行权限评估。然而，大量的用户态授权框架（如 AuthzAccessCheck、AccessCheckByType）并不直接发起内核调用，而是依赖 AuthzBasep 内部的“安全描述符缓存”来模拟访问判断。 这种设计产生了天然的时间裂隙：内核真实安全描述符（位于 OBJECT_HEADER->SecurityDescriptor）由内核线程在 ObpReferenceSecurityDescriptor 中同步更新，而用户态缓存（AuthzBasepCachedSecurityDescriptor）的刷新是异步、节流的，甚至受制于单向链表遍历效率。 AuthzBasep 的单向链表缓存架构 AuthzBasep 是 Windows authz.dll 的核心引擎，内部维护一个单向链表（AuthzBasepSecurityDescriptorList），每个节点包含对象的引用名称、缓存的安全描述符副本、以及上一次刷新时间戳。当应用程序调用 AuthzAccessCheck 时，它遍历该单向链表，查找同名对象的最新缓存描述符，然后基于缓存执行访问检查，不会实时查询内核状态。 单向链表的天然缺陷在于：查找与刷新操作为 O(n) 复杂度，且没有原子性保证。刷新线程（AuthzBasepUpdateThread）周期性唤醒，逐个节点检查 LastUpdateTime，若超过阈值（默认 15 秒）则重新从内核拉取安全描述符。如果攻击者在刷新线程遍历到目标节点之前修改内核安全描述符并触发用户态访问检查，旧版缓存仍然被信任。 传播延迟 内核 SeAccessCheck 与 SepAccessCheck 的调用链分裂 理解分裂链条对于攻击窗口的精准打击至关重要。 用户态请求 →SeAccessCheck (ntoskrnl.exe)：直接读取对象内核安全描述符，基于调用者 Token 进行即时权限判定。任何修改（如 NtSetSecurityObject）均立即在此路径中体现。 用户态 Authz 请求 →SepAccessCheck (authz.dll)：是 SeAccessCheck 的用户态模拟。它使用缓存的 SecurityDescriptor 副本，并与内核 Token 句柄交互。SepAccessCheck 不与 SeAccessCheck 同步。 分裂意味着：同一对象在同一时刻，SeAccessCheck 可能返回“拒绝”，而 SepAccessCheck 可能返回“允许”。这正是缓存延迟攻击的根基。 AuthzBasepCachedSecurityDescriptor 的刷新触发器 AuthzBasepCachedSecurityDescriptor 结构的关键字段： typedefstruct _AUTHZ_BASEP_CACHED_SD { LIST_ENTRY Link;…

摘要 PCI Express 链路上传输的每一条 DMA 读写请求都被封装为 TLP（事务层数据包），携带设备标识符和目标物理地址。IOMMU 通过 BDF 编号和地址转换表对这些请求进行合法性检查，阻止未经授权的内存访问。然而，TLP 层存在一个容易被忽视的攻击面：高级错误报告（AER）允许设备向根复合体报告各类错误，而端到端 CRC（ECRC）本用于检测传输过程中的比特翻转，却可能被恶意设备主动操纵，迫使接收端进入错误恢复流程。在错误恢复的重传机制中，如果攻击者能够制造 TLP 的“合法重放”，并将其中的物理地址字段替换为攻击目标，便能在 IOMMU 检查之前完成 DMA 重定向。 PCIe TLP 与 DMA 的权限模型 TLP 的结构与路由 PCIe 采用分层协议，事务层负责在设备与主机之间传输数据。 每个 TLP 包含： TLP 前缀（可选）：用于扩展头信息。 TLP 头：包含格式（Fmt）和类型（Type）字段，决定 TLP 是存储器读写、配置读写、消息还是完成包。对于存储器写 TLP，头中还有地址字段（32 位或 64 位物理地址）。 数据载荷：实际传输的有效数据。 TLP 摘要：可选字段，包含 32 位的 ECRC，用于检测端到端的比特错误。 在 DMA 操作中，设备主动向主机内存发起读写请求。主机芯片组中的根复合体（Root Complex）根据 TLP 头中的 Requester ID（Bus/Device/Function，BDF）和地址进行路由，并由 IOMMU…

摘要 Certificate Transparency 通过 Merkle Tree 哈希链保证证书的不可抵赖性，SCT 记录了 CA 签发证书的精确时间，二者共同构成了现代 TLS 信任体系的审计根基。然而，CT 日志服务器的时间戳可信吗？如果攻击者能够操控 NTP 同步路径，便可在证书签发时间与 SCT 时间之间制造足以掩盖入侵窗口的差异，使证书吊销检查和 CT 监控双双失效。 Merkle Tree 与 SCT 的时间锚点 Certificate Transparency 的设计初衷 2011 年，荷兰证书颁发机构 DigiNotar 遭入侵，攻击者为其未控制的域名（包括 Google 和 CIA）签发了超过 500 张伪造证书，随后在伊朗用于大规模中间人攻击。事件曝光后，DigiNotar 宣告破产，浏览器厂商紧急撤销其根证书。这一事件暴露了 TLS 信任模型的结构性缺陷：CA 可以为其未被授权的域名签发证书，而依赖方（浏览器）无法实时获知滥用行为。 Certificate Transparency 正是为解决这一“CA 信任无限”问题而生。CT 要求 CA 将签发的每一张证书提交到至少一个公开的 CT 日志服务器，日志服务器将该证书追加到一条仅可追加、不可删除的 Merkle Tree 哈希链中，并返回 Signed Certificate Timestamp（SCT）作为证书已被记录的证明。依赖方（浏览器）在验证证书时检查其是否包含有效的…

摘要 Bring Your Own Vulnerable Driver（BYOVD）在2025-2026年间完成了一次根本性的攻击范式转移：从依赖已知漏洞驱动的黑名单对抗，进化为滥用未被标记、持有有效合法签名的驱动程序。攻击者不再寻找“有漏洞的驱动”，而是将任何具有内核级特权的签名驱动本身视为攻击面。 当签名成为攻击面 Bring Your Own Vulnerable Driver并非新概念，但其内涵在2025-2026年间已发生根本性漂移。传统定义下的BYOVD——攻击者携带一个已知存在漏洞的合法驱动程序，利用其内核级权限执行恶意操作——过于狭隘地聚焦于“漏洞”本身。BYOVD的核心在于“合法签名 + 漏洞”的组合利用——攻击者无需自行开发驱动，而是从公开渠道（如厂商官网、GitHub、驱动仓库）搜集已被微软WHQL签名、但存在任意写（Arbitrary Write）、UAF（Use-After-Free）等漏洞的旧版驱动（例如ASUS、EVGA等硬件厂商历史驱动）。 更精确的表述是：BYOVD攻击滥用了Windows驱动信任模型的一个根本性假设——签名等同于信任。由于这些驱动具备有效证书，即使在启用了Secure Boot和Driver Signature Enforcement的系统中，仍可被加载执行。Windows内核在加载驱动时验证的是数字签名的密码学有效性，而非驱动本身的安全性。这一信任传递的断裂构成了BYOVD的全部理论基础：攻击者不需要绕过签名验证，他们只需要找到一个签了名的驱动，然后滥用其合法功能。 BYOVD攻击正被广泛用于从勒索软件到国家支持间谍活动的各类隐蔽行动，而大多数公共沙箱仅检查用户态活动，导致此类内核级滥用通常无法被检测。 驱动签名验证的技术基础 要理解BYOVD为何如此难以根治，必须从驱动签名验证的底层机制入手。Windows从Vista开始引入的内核模式代码签名（KMCS）策略，要求所有内核驱动必须携带有效数字签名。签名验证的核心链路如下：驱动程序的PE文件经过哈希运算后，该哈希值使用发行者的私钥进行加密。当系统加载驱动时，验证模块首先检查证书是否由受信任的根证书颁发机构（CA）签发，然后验证证书是否在有效期内且未被吊销，最后验证PE文件的当前哈希值与签名中加密的哈希值是否匹配。 然而，签名验证仅限于验证签名本身的密码学有效性——它不验证驱动内部的代码行为是否存在漏洞，也不验证驱动暴露的IOCTL接口是否可以被用户态任意调用。这种“只管签名、不管行为”的信任模型，为BYOVD攻击提供了结构性的可乘之机。一个持有微软WHQL签名的硬件监控工具驱动，在签名验证层面与一个微软自家内核模块享有同等的信任等级。 从已知漏洞到合法证书 范式转移发生在攻击者不再满足于利用那些已被列入微软易受攻击驱动黑名单（Vulnerable Driver Blocklist）的已知驱动之时。2025-2026年，三个关键趋势标志着这一转变的完成： 第一，未知漏洞驱动的武器化。Silver Fox APT利用的WatchDog反恶意软件驱动（amsdk.sys）是一个典型样本——该驱动持有有效微软签名，但此前从未被报告存在漏洞，也未出现在任何公共黑名单中。Check Point Research于2025年8月首次披露了这一攻击活动。 第二，合法证书的独立滥用。HoneyMyte（Mustang Panda）APT组织使用了2015年过期的广州Kingteller Technology被盗证书来签署自己的内核级迷你过滤驱动——攻击者不再是“利用有漏洞的合法驱动”，而是利用被盗或失效的合法证书签署自己编写的恶意驱动。Huntress在2026年2月的一次入侵响应中发现，攻击者滥用了Guidance Software（EnCase）取证驱动的吊销证书——该证书于2010年到期并随后被吊销，但Windows仍然加载了该驱动。 第三，单字节翻转绕过哈希黑名单。这是范式转移中最精致的攻击手法。当WatchDog厂商发布了修复版本（1.1.100）并通过更严格的DACL限制特权提升漏洞后，Silver Fox迅速适应：仅翻转驱动文件中时间戳字段的一个字节，在完整保留微软数字签名的同时改变了文件哈希值，从而绕过了基于哈希的黑名单机制。 这三个趋势共同指向一个结论：攻击者的关注点已从“驱动内部的代码漏洞”转移到“签名信任体系的结构性缺陷”。 驱动签名本身——而非驱动代码中的bug——成为了最大的攻击面。 实验到工业化 双驱动 Check Point Research于2025年8月首次披露了Silver Fox APT组织利用微软签名驱动的大规模攻击活动。该组织自2024年以来已从经济动机的网络犯罪演变为复杂的APT式行动。Silver Fox采用了一种精巧的双驱动策略以覆盖不同Windows版本——在Windows 7系统上使用已知存在漏洞的Zemana驱动，而在Windows 10/11系统上则部署了此前未被报告的WatchDog反恶意软件驱动（amsdk.sys，版本1.0.600）。 为了使用该方法，攻击者需要将漏洞驱动加载到内核。典型方法如下： // 方法一：使用 SC 命令创建并启动内核服务…