绕过PatchGuard及HVCI等在Windows x64系统中隐藏进程

ANY.LNK

原文地址：https://www.outflank.nl/blog/202 ... patchguard-in-2026/

前言

现代的Windows上包含多种安全措施，除了最开始的PatchGuard外，还包括HVCI和HyperGuard等多项安全措施。在启用了HVCI的Windows设备上，Microsoft Hyper-V将强制执行多层安全模型。此架构基于虚拟信任级别（Virtual Trust Levels，VTLs），在原有的Ring0-Ring3上进一步划分了新的隔离边界。

此种情况下，一般的Windows部分将运行在VTL0下，而各项安全相关的部分则交予VTL1实现（例如系统登录的安全凭据，对VTL0的安全监控和校验等）。VTL1的信任级别更高，可单向访问VTL0中的内容，而VTL0无权访问VTL1中的内容，只能有限的通过超调用同VTL1通信——最终选择权仍在VTL1。这样即使攻击者已进入VTL0内核并成功获取了Ring0权限，也无法访问保存在VTL1中的敏感数据。



Microsoft Hyper-V虚拟机监控程序是实际执行上述检查的部分，其权限优于内核，对于内核想要执行的敏感操作（修改页表、执行特定命令、访问特定内存）即使内核认为允许可行监控程序也有权拒绝。

硬件层（AMD-v或Intel-VT-x）提供了嵌套页表（NPT）或扩展页表（EPT），它们决定操作系统页表之下的二层内存地址转换。操作系统无权修改覆盖此层的设置。

VTL0无法修改自己的执行内容，任何VTL0对代码页的写入都将触发EPT违规，造成虚拟机退出并通过监控程序将违规情况转发至VTL1，并立即触发VTL1的BugCheck

---

操作

Windows通过存储在EPROCESS结构中的双链表跟踪活跃进程，进程终止时内核通过PspProcessDelete从列表中解绑，此函数会清理进程对象并将其从ActiveProcessLinks链中移除，还会对LIST_ENTRY结构进行完整性检查。

传统的尝试直接对此函数进行挂钩、写入均会因前述原因被阻止或直接触发BugCheck而失败，但结合公开的API——PsSetCreateProcessNotifyRoutineEx创建的回调却可在检查前修复被修改的链表结构进而避免BSoD。

修改LIST_ENTRY中的前向链路（Flink）和后向链路（Blink）可用来隐藏进程，但会在进程终止时的校验中失败，因为Flink和Blink的指针从ActiveProcessLinks中解绑，LIST_ENTRY不再指向链中有效的相邻元素，由此导致的不一致会使PspProcessDelete的完整性检查失败并立即抛出0x139错误。

进程终止时，包含进程信息的EPROCESS结构将作为唯一传入参数传递给内部函数PspProcessDelete。通过PsSetCreateProcessNotifyRoutineEx创建回调后，相同的结构和回调通知将在进程终止的校验前先一步发送到我们手中，这给予了我们修正LIST_ENTRY的窗口期，此时便可：

·通过检查CreateInfo是否为NULL确定是否为进程终止过程
·从EPROCESS结构中提取ActiveProcessLinks
·确认LIST_ENTRY是否损坏
·恢复有效的F/Blink指针
·令PspProcessDelete继续通过验证

于是在PspProcessDelete进行校验时将得到正常的LIST_ENTRY，因而不会触发安全检查

---

其他

进程的数据页在正常情况下即拥有读写权限且HVCI不对此进行检查，这提供了另一种思路，但能被此方法劫持执行流程的函数指针少之又少。


在线程状态转换时操控上下文可以做到完全在CPU寄存器上执行，不受EPT内存访问控制保护以及在不修改代码页的情况下执行操作，拦截并劫持任何函数的执行流，但此方法复杂度极高，需要极为恰到好处的时机且极易受环境（如系统版本）变化的影响，以及对调用链和执行路径的完美了解。

桔梗想见雪

看起来，很影响性能的样子