Patchguard：基于Hypervisor的内省检测[P1]
过去2-3年间，微软在Patchguard中植入了多种虚拟化内省检测方法（高深术语）。当攻击代码在更高权限层级运行时，绕过内核补丁保护易如反掌，因此这一变化并不令人意外。虽然Windows在Hypervisor下运行良好，并开放了准虚拟化接口，但Patchguard会检测虚拟机监控程序（VMM）是否篡改了非虚拟机正常运行所必需的状态。例如：通过隐藏控制系统调用分支目标的MSR真实值来挂钩系统调用，或利用嵌套分页在关键控制路径获取执行权限。
尽管Patchguard包含比本文介绍的更多的检测机制，作者选择了几个特殊案例进行讲解，读者可自行探索更多内容。本文旨在帮助安全软件、反病毒和内省工具与内核补丁保护实现互操作性。
检测机制一：KiErrata704Present
该函数名看似无害，甚至像在检查某种硬件勘误。其工作原理如下：
- 保存FMASK MSR值并设置该MSR，确保SYSCALL操作不会修改TF（陷阱标志）。
- 通过PUSHFQ/POPFQ序列设置TF标志，触发后续指令执行时产生#DB（调试异常）。
- 通过检查#DB处理程序的IP地址，Patchguard可间接发现LSTAR MSR的真实内容，从而检测恶意虚拟机是否在RDMSR/WRMSR时伪造返回值。
检测机制二：KiErrataSkx55Present
这是作者的最爱，其灵感来自CVE-2018-8897漏洞。该机制利用POP SS/MOV SS漏洞的原理，通过类似方法检测Hypervisor。解决方案是设置异常位图在#DB异常时退出，检查客户机状态IP，并通过向量事件注入反射回客户机。
检测机制三：KiErrata361Present
该机制利用RFLAGS加载和SS加载的交互特性：
- 正常情况下，通过POPF变体加载TF标志后接SS加载，单步异常会在SS加载后的指令边界触发。
- 但INTn（软件中断）或INT3（软件异常）会丢弃待处理的TF异常。
- 当虚拟机因特权软件异常（如ICEBP）退出时，VMCS状态无法自然恢复，导致VMRESUME失败。解决方案是在符合条件的退出时检查特权软件异常，若MOV SS阻塞且TF=1，则确保待处理调试异常中BS位置1。
本文内容基于CVE-2018-1087漏洞，该漏洞公开前，Intel手册尚未明确说明特权软件异常就是ICEBP。
如果这些内容不够枯燥，请继续阅读第二部分，我们将讨论更多Patchguard检测机制，并用批判性思维设计自己的巧妙技巧！
版权声明：本文采用[X]许可协议，保留所有权利。原文内容仅限在发布地址阅读，未经作者书面许可不得复制或作其他用途。