启用 内核完整性保护(HVCI) 和 受控文件夹访问(CFA) 是 Windows 操作系统中用于增强系统安全性的两项功能。它们的作用是防止恶意软件的攻击,保护系统的完整性,并帮助防止用户的文件被恶意程序篡改。
VBS(Virtualization-Based Security,基于虚拟化的安全)完整演进史
基础概念统一
hvix64.exe,利用 CPU VT-x/AMD-V + SLAT/EPT 硬件分层,将系统切分为两层硬件隔离信任域:- VTL0(不可信层):常规 Windows 内核、驱动、应用、网络服务全部运行于此,易被内核漏洞攻陷;
- VTL1(硬件安全世界 Secure World):独立安全内核,内存由 Hypervisor + CPU 硬件锁死,VTL0 完全无法读写、篡改 VTL1 内存,作为整机最高信任根。
VBS 承载三大核心安全组件:Credential Guard(凭据隔离)、HVCI / 内存完整性(内核代码完整性)、VBS 隔离用户态(IUM)、VBS Enclaves、Secure Launch 固件安全启动。
阶段一:技术原型铺垫(2008–2014,Hyper-V 底层基建)
- Hyper-V 虚拟化底层成型
微软重构轻量化 Type-1 虚拟机监控程序,实现 SLAT 二级地址翻译、CPU 虚拟化硬件调度,奠定 VBS 分层内存隔离底层硬件基础。
- 初代凭证隔离思路验证(Win8 / Server2012)
推出 Measured Boot、TPM2.0 测量启动链,但无独立 VTL 分层;LSA 凭据仍存放在 VTL0 普通内核,Mimikatz 可直接读取哈希,无深层隔离防护。
- 安全痛点驱动重构
全球大量域渗透攻击依靠抓取 LSA 内存凭证横向移动;传统内核代码完整性 KMCI 运行在内核,漏洞可直接篡改校验逻辑,微软规划 VBS 全新隔离架构,把安全校验、凭据存储移出常规操作系统。
- 2015 Ignite 正式对外发布 VBS、Credential Guard、Device Guard 整套技术栈。
阶段二:初代商用落地(Win10 1507 / Server 2016,2015)—— 企业专属,功能拆分
1. 架构里程碑:VTL0/VTL1 双层隔离正式落地
- 内置独立安全内核
securekernel.exe,VTL1 专属运行环境,SLAT 两套独立页表硬件隔离内存; - 同时发布两大核心 VBS 子功能:
- Credential Guard:
lsaiso.exe运行在 VTL1,NTLM 哈希、Kerberos 票据隔离存储,VTL0 完全无法读取,阻断 Mimikatz 类凭证窃取攻击Microsoft ...; - HVCI(Device Guard 附属模块):内核代码完整性校验引擎
skci.dll放入 VTL1,仅支持驱动 WHQL 签名校验,软件模拟 W^X,无硬件执行加速。
- Credential Guard:
2. 初代版本核心局限
- 硬件门槛高、兼容性极差
无 MBEC/GMET 硬件执行陷阱,依靠软件模拟 W^X,性能损耗 25%~40%;大量第三方工业驱动不兼容 HVCI,开启直接蓝屏。
- 部署渠道封闭
仅企业版 / 教育版支持,消费版隐藏;仅可通过域组策略、注册表开启,无 Windows 安全中心图形开关,普通用户无法配置。
- 能力残缺
- 无 KDP 内核数据保护,仅校验代码,内核权限结构体可被 VTL0 漏洞篡改;
- 无 Secure Launch 固件防护,UEFI 固件 Rootkit 可破坏 VBS 信任链;
- 不支持嵌套虚拟化,虚拟机内部无法启用 VBS;
- 无 DMA 硬件防护,外设 DMA 可直接篡改内核内存绕过防护。
- 默认状态:全局关闭,仅企业批量策略手动部署。
阶段三:成熟迭代、民用化、硬件加速(Win10 1607 ~ 20H2,2016–2020)
1. Win10 1607(2016,关键解绑 Device Guard)
- HVCI 正式独立定名,脱离 Device Guard 营销套件;Windows Defender 安全中心新增核心隔离 - 内存完整性图形一键开关,消费终端可见可操作。
- IUM 隔离用户态完善:支持 VTL1 运行独立安全用户进程,扩展 VBS 隔离边界。
- 完善 PowerShell、MDM/Intune 批量配置接口,适配企业终端统一管控。
2. Win10 1803(2018,硬件加速核心升级)
- 适配 Intel KabyLake MBEC、AMD Zen2 GMET 硬件执行陷阱:
- 新 CPU 硬件原生拦截 RWX 内存,性能损耗降至 5% 以内;
- 老旧 CPU 保留软件模拟兼容路径。
- HVCI 新增高危 BYOVD 驱动黑名单,加载驱动前拦截漏洞第三方驱动,阻断本地提权攻击链。
- VBS 日志标准化,区分凭据窃取、驱动校验失败、W^X 违规事件,支持 SIEM 日志转发审计。
3. Win10 2004(2020,补齐内核数据防护 KDP)
- KDP(Kernel Data Protection)内核数据保护:VTL1 Hypervisor 将内核令牌、特权数组、安全策略硬件标记只读,阻断篡改
SeDebugPrivilege、替换进程令牌等经典本地提权路径,HVCI 形成代码 + 数据双层防护。 - 新增 Secure Launch(DRTM 动态信任根):启动早期由 CPU 固件接管测量,隔离不可信 UEFI 固件代码,防范固件 Rootkit 破坏 VBS 信任链Microsoft。
- 服务器侧:Windows Server 2019 完整支持 VBS、Credential Guard、HVCI,适配数据库、文件服务器业务加固。
本阶段核心变化
阶段四:Win11 基线强制、硬件固件硬化、全域纵深联动(2021–2026)
1. Win11 21H2(2021,安全基线重构里程碑)
- 硬件准入强制锁死
VBS 运行硬性前置条件:UEFI Secure Boot、TPM2.0、VT-x/AMD-V+SLAT、IOMMU VT-d/AMD-Vi;老旧 Legacy BIOS 设备彻底无法启用 VBS。CPU 硬性门槛:Intel 11 代 +/AMD Zen2+,强制具备 MBEC/GMET 硬件执行拦截。
- 默认启用策略变更
全新合规硬件预装系统,VBS 底层 Hypervisor 默认加载,内存完整性(HVCI)出厂默认开启;S 模式 Windows 永久强制启用 VBS 全套能力,不可关闭Microsoft ...。
- Secured-core PC 安全核心整机标准落地:VBS、DMA 防护、Secure Launch、TPM/Pluton 芯片深度绑定,芯片到操作系统完整信任链。
- 嵌套虚拟化 VBS 支持:虚拟机内部可独立开启内存完整性,适配 Azure 云主机租户隔离加固。
2. Win11 22H2 / Server 2022(2022,Hardware‑enforced 硬件强制落地)
- 正式实现硬件强制代码完整性:SLAT/EPT 二级页表权限由 CPU 固件保护,Hypervisor 软件无法篡改,不再仅依赖虚拟化软件逻辑,VTL0 完全无任何绕过路径。
- 全域驱动黑名单硬化:无论是否开启 HVCI,所有 Windows 设备加载驱动时统一校验高危漏洞驱动列表,双重阻断 BYOVD 提权攻击。
- Kernel DMA Protection 硬件防护集成 VBS:阻断外设 DMA 直接读写物理内存、篡改 VTL0/VTL1 内核页面。
- Server 2022 Secured-core Server 标配 VBS,支持 Defender System Guard 远程健康证明,云端校验服务器 VBS 运行状态,适配等保、云安全基线。
3. 2023–2026 云原生、芯片级加固、VBS Enclaves 扩展
- VBS Enclaves 安全隔离区(2024 新特性)
在 VTL1 内部创建轻量化可信执行环境 TEE,保护密钥、加密业务逻辑、敏感应用代码,用于机密计算、本地身份验证,仅 Win11 24H2+、Server2025 完整支持,旧版系统移除该功能IT之家。
- Microsoft Pluton 安全处理器深度联动 VBS:TPM 功能集成 CPU 硅片内,固件测量、密钥存储与 VBS Secure Launch 无缝衔接,抵御主板总线硬件攻击Microsoft ...。
- ARM64 Windows(Azure ARM 云主机、Surface ARM)完整适配 VBS 分层隔离,ARM Secure Launch 固件链绑定 VBS 信任根。
- 多层安全纵深联动:VBS(HVCI+Credential Guard)+ CFA 受控文件夹访问 + Defender 篡改防护 + XDR 云端告警完整联动,形成「内核无法执行恶意代码、提权也无法加密业务文件」的勒索防御闭环。
- 性能持续优化:大内存 AI 负载、数据库服务器场景优化 VBS 内存池分配,开启全套 VBS 功能性能损耗进一步压低。
- Server 2025:Secured-core 服务器强制 VBS 基线,作为政企、云主机等保必选加固项,配套统一批量 MDM 策略管控。
配套硬件同步演进时间线
| 时间节点 | CPU / 固件硬件能力 | 对 VBS 的核心影响 |
|---|---|---|
| 2015 初代 VBS | VT-x/AMD-V + SLAT,无硬件执行陷阱 | 纯软件模拟 W^X,高性能损耗 |
| 2018 Win10 1803 | Intel MBEC / AMD GMET | CPU 硬件拦截非法执行,性能大幅优化 |
| 2021 Win11 21H2 | TPM2.0 + IOMMU + UEFI Secure Boot | 老旧硬件淘汰,统一硬件安全准入基线 |
| 2024–2026 现代平台 | CPU 固件保护 SLAT/EPT 页表、Pluton 安全芯片 | 实现 Hardware‑enforced 硬件强制,软件层无法绕过 VBS 防护 |
分版本 VBS 核心能力横向对比
| 系统版本 | VBS 定位 | 核心子组件 | W^X 实现方式 | 默认加载状态 | 部署范围 |
|---|---|---|---|---|---|
| Win10 1507 | 企业增值套件(Device Guard 附属) | Credential Guard、初代 HVCI | 软件模拟 | 关闭,仅组策略部署 | 企业终端 |
| Win10 1803 | 独立系统安全模块 | Credential Guard、HVCI、驱动黑名单 | MBEC 硬件 / 软件双路径 | 关闭,用户手动开启 | 企业 + 个人桌面 |
| Win10 2004 | 成熟终端安全底座 | 新增 KDP 内核数据保护、Secure Launch | 硬件优先 | 关闭 | 全类型桌面终端 |
| Win11 21H2 | Windows 默认安全基线 | DMA 防护、Secured-core 整机联动 | MBEC 硬件强制 | 合规新机 Hypervisor 默认加载 | 消费笔记本、品牌整机 |
| Win11 22H2+ / Server2022 | Hardware‑enforced 硬件强制安全底座 | 全域驱动黑名单、嵌套虚拟化 VBS | CPU 固件锁定 EPT 权限 | 合规设备内存完整性出厂开启 | 桌面、物理服务器、云虚拟机 |
| Win11 24H2 / Server2025 | 芯片到云全域安全根 | VBS Enclaves、Pluton 深度集成、XDR 联动 | CPU 原生内存权限管控 | Secured-core 设备全套强制启用 | 终端、服务器、超融合、机密计算主机 |
VBS 演进四大核心趋势总结
1. 信任边界:从软件虚拟化 → CPU 固件硬件强制
2. 部署范围:企业专属功能 → 全平台出厂默认安全基线
3. 防护边界持续扩张
4. 底层信任链闭环完善
VBS 演进安全核心价值
- 架构颠覆传统内核安全
传统安全机制(KMCI、LSA 本地存储)运行在可被攻陷的 VTL0;VBS 将校验、凭证存储下移至硬件隔离 VTL1,校验者本身不可被篡改,解决 “保护者自身可被攻陷” 底层缺陷。
- 完整覆盖主流攻击向量:http.sys 远程内核 RCE、BYOVD 第三方驱动本地提权、Mimikatz 凭证窃取、固件 Rootkit、DMA 硬件攻击、内核内存篡改、勒索病毒持久化。
- 统一整机安全信任根:所有高级安全功能(内存完整性、凭据隔离、机密计算)全部基于 VBS 分层虚拟化架构实现,是现代 Windows 内核安全底层基石。
VBS(Virtualization-Based Security,基于虚拟化的安全)完整底层原理
一、核心定义与硬件前置依赖
1. 核心定位
hvix64.exe,利用 CPU 硬件虚拟化能力,将物理内存通过 SLAT 二级地址翻译切分为两套独立页表,硬件强制划分两层完全隔离的信任域 VTL0 / VTL1。
2. 必备硬件基础(缺一不可)
- CPU 虚拟化:Intel VT‑x / AMD‑V,支持客户模式隔离;
- SLAT(Intel EPT / AMD NPT)二级地址翻译:Hypervisor 维护独立主机页表,内存权限由 CPU 硬件判决;
- MBEC(Intel)/ GMET(AMD)硬件执行陷阱:硬件拦截 RWX 可写可执行内存,实现 Hardware‑enforced 硬件强制 W^X;
- IOMMU(VT‑d / AMD‑Vi):阻断外设 DMA 直接读写物理内存,防止硬件侧绕过防护;
- UEFI Secure Boot + TPM2.0 / Pluton 安全芯片:锁定 Hypervisor、安全内核镜像签名,构建固件级信任链;
- DRTM Secure Launch:CPU 固件动态信任根,启动早期隔离恶意 UEFI 固件。
二、核心架构:VTL0 / VTL1 双层硬件隔离域
1. VTL 0(非信任普通层)
- 内核
ntoskrnl.exe、第三方驱动、系统服务(http.sys、WinRM、LSA); - 所有用户程序、脚本、网络业务逻辑;
安全短板:存在海量内核缓冲区溢出、远程 RCE、BYOVD 驱动提权漏洞;攻击者一旦控制 VTL0 内核,可随意修改本层页表、内存、权限结构体。
2. VTL 1(硬件隔离安全世界 Secure World)
skci.dll:HVCI / 内存完整性代码完整性校验引擎;lsaiso.exe:Credential Guard 隔离凭证进程,存储 NTLM 哈希、Kerberos 票据;- KDP 内核数据保护逻辑;
- VBS Enclaves 机密计算隔离容器;
- 固件测量、TPM 密钥交互模块。
3. Hypervisor(hvix64.exe)中间调度层
- 硬件虚拟化调度,切换 VTL0/VTL1 执行上下文;
- 维护两套独立 SLAT 页表(客户页表 VTL0、主机页表硬件判决标准);
- 拦截系统调用、内存权限修改、驱动加载事件,转发至 VTL1 安全引擎校验。
三、四大底层核心机制(VBS 防护根基)
机制 1:SLAT 双层独立页表,硬件强制内存权限隔离
- VTL0 仅持有客户页表,仅用于程序正常寻址,修改权限仅作用于客户页表;
- Hypervisor 维护全局主机 EPT/NPT 页表,是 CPU 访问内存的最终权限判定依据,硬件优先读取;
- 永久强制 W^X(写执行互斥)规则,写入主机页表固化:
- 内核代码、驱动镜像:标记 RX(只读可执行),永久禁止写入;
- 堆、栈、缓冲区、全局数据:标记 RW(可写不可执行);
- 不存在任何 RWX 页面,硬件直接拦截违规。
NtProtectVirtualMemory 修改页面执行权限时,仅更新客户页表,底层硬件主机页表不会同步变更。CPU 检测到 RWX 冲突,抛出 #VE 虚拟化异常,强制切换至 VTL1 处理,记录安全日志并蓝屏阻断攻击。机制 2:VTL1 前置拦截系统调用,全链路安全校验
场景 A:驱动加载(HVCI 内存完整性)
- VTL0 调用
NtLoadDriver加载第三方驱动; - Hypervisor 捕获调用,切至 VTL1;
skci.dll三重校验:WHQL 数字签名、镜像哈希完整、不在高危 BYOVD 驱动黑名单;- 校验通过:Hypervisor 在主机页表分配 RX 权限,允许映射进 VTL0;
- 校验失败:直接阻断加载、蓝屏、写入审计日志。
场景 B:LSA 凭证读写(Credential Guard)
- VTL0 进程(Mimikatz)尝试读取 LSA 内存凭证;
- Hypervisor 拦截内存读取系统调用,转发 VTL1;
lsaiso.exe拒绝 VTL0 访问隔离凭证存储;- 返回空数据,攻击者无法抓取哈希完成横向域渗透。
机制 3:KDP 内核数据保护(配套 HVCI,补齐提权攻击面)
- Hypervisor 将内核只读常量、令牌结构体、特权数组(
SeDebugPrivilege、SID 组、凭证指针)在 EPT 页表标记硬件永久只读; - VTL0 内核漏洞无法篡改权限配置、替换进程令牌、修改系统安全策略;
- 阻断经典本地提权路径:篡改内核权限、伪造管理员令牌、劫持 LSA 指针。
机制 4:Secure Launch + TPM2.0 固件信任链
- 开机流程:CPU 固件 DRTM → UEFI 测量 → TPM2.0 记录启动哈希;
- TPM 校验 Hypervisor、VTL1 安全内核镜像签名,任意组件被篡改直接终止启动;
- 隔离不可信 UEFI 驱动、固件 Rootkit,防止底层恶意程序破坏 VBS 隔离环境;
- Pluton 芯片机型:安全处理器与 VBS 深度联动,密钥、测量逻辑完全脱离主板总线攻击面。
四、VBS 两大核心上层安全组件底层运行逻辑
1. HVCI / 内存完整性(内核代码防护)
skci.dll + SLAT+MBEC 硬件 W^X,对抗内核 RCE、BYOVD 驱动、Rootkit 后门:- 所有内核驱动加载前置签名校验;
- CPU 硬件拦截缓冲区溢出生成的恶意 Shellcode 执行;
- 运行时代码页永久只读,禁止补丁篡改系统内核。
2. Credential Guard 凭据隔离
lsaiso.exe 独立凭证容器,阻断凭证窃取攻击:- NTLM 哈希、Kerberos 票据、域凭据全部存储在 VTL1 隔离内存;
- VTL0 所有进程、内核无读取权限,Mimikatz、ProcDump 等工具无法导出凭证;
- 凭据加密密钥存放 TPM,内存不落地明文。
五、完整攻击拦截时序示例(http.sys 远程内核 RCE)
- 攻击者发送畸形数据包触发 http.sys 缓冲区溢出,在 RW 数据缓冲区写入 Shellcode;
- 漏洞调用内存权限 API,试图将数据页改为可执行;
- CPU 读取底层 EPT 主机页表,检测 RWX 违规,抛出 #VE 虚拟化异常;
- Hypervisor 切换至 VTL1 安全引擎判定恶意行为;
- 系统立即蓝屏终止执行,Shellcode 永远无法运行,远程内核漏洞完全失效。
六、初代软件模拟 VBS VS Win11 硬件强制 VBS 底层差异
- Win10 早期无 MBEC 机型(软件模拟)
- W^X 依靠 Hypervisor 软件捕获执行异常,频繁上下文切换;
- 性能损耗 25%~40%;
- 存在复杂漏洞链绕过软件校验路径。
- Win11 Hardware‑enforced 硬件强制
- MBEC/GMET CPU 硬件原生拦截非法执行,硬件判决优先于软件;
- EPT 页表由 CPU 固件保护,Hypervisor、VTL0 均不可篡改;
- TPM+Secure Launch 锁死 VTL1 安全内核,无软件绕过路径;
- 性能损耗控制在 5% 以内,适配服务器、AI 大内存负载。
七、与其他 Windows 安全组件底层联动
- VBS + CFA 受控文件夹访问
VBS/HVCI 阻止恶意内核驱动执行;CFA 内核过滤驱动拦截 SYSTEM 权限程序加密受控目录,形成「无法提权、提权无法加密文件」勒索完整防御链。
- VBS + Defender 篡改防护
hvix64.exe、skci.dll受 HVCI 签名保护,无法卸载、替换、打补丁;VBS 相关注册表项添加内核 ACL 锁定,恶意程序无法关闭内存完整性、Credential Guard。 - VBS + IOMMU DMA 防护
阻断外设硬件 DMA 直接读写物理内存,防止绕过 SLAT 隔离篡改 VTL0/VTL1 内核页面,补齐硬件攻击向量。
八、底层性能优化设计
- 校验结果缓存常驻 VTL1 内存,重复驱动加载、权限查询无需重复切换 VTL 上下文;
- MBEC 硬件执行陷阱大幅减少 #VE 虚拟化中断,降低上下文切换开销;
- 微软自有系统驱动提前预信任,跳过完整签名校验;
- 常规业务读写仅 VTL0 运行,无跨层切换,几乎无性能损耗;
- 大内存服务器优化 VBS 内存池分配,数据库、AI 场景损耗进一步压低。
九、底层安全核心总结
- 信任架构颠覆性反转
传统安全组件(KMCI、原生 LSA)运行在可被攻陷的 VTL0;VBS 将校验、凭证存储下移至硬件隔离 VTL1,被保护系统完全无权触碰安全信任根,解决 “保护者自身可被劫持” 底层缺陷。
- 软硬件双层不可绕过防护
软件层:VTL1 独立安全引擎做签名、行为校验;硬件层:SLAT+MBEC+IOMMU 锁死内存执行与访问权限,内核漏洞、硬件攻击均无法突破隔离。
- Windows 现代安全底层总底座
内存完整性、凭据隔离、机密计算、固件防护全部基于 VBS 分层虚拟化架构实现,是终端、服务器、云主机对抗内核漏洞、凭证窃取、固件 Rootkit、勒索病毒的核心底层信任根基。
内存完整性(Memory Integrity / HVCI)完整演进史
术语统一说明
- 产品界面名称:内存完整性(核心隔离下开关)
- 官方底层标准名:HVCI = Hypervisor‑Protected Code Integrity(虚拟机监控程序保护代码完整性)
- 硬件硬化形态:Hardware‑enforced Code Integrity(硬件强制代码完整性,Win11 22H2 + 现代 CPU 原生硬件执行拦截)
底座统一依赖 VBS 基于虚拟化的安全,通过 CPU VT‑x/AMD‑V + SLAT/EPT 硬件分层隔离 VTL0(普通系统内核)、VTL1(安全隔离层)Microsoft ...。
整体演进四大阶段
阶段一:初代企业专属落地(Win10 1507 / Server 2016,2015)—— Device Guard 附属内核防护模块
1. 产品定位
2. 底层实现
- 首次将内核代码完整性校验引擎
skci.dll放入 VTL1 隔离安全内核,脱离可被攻陷的 VTL0 系统内核; - Hypervisor 维护两套独立 SLAT/EPT 页表,强制 W^X 读写执行互斥规则;
- 仅校验驱动 WHQL 数字签名,拦截未签名驱动加载;无运行时内核数据防护。
3. 致命短板
- 无 MBEC/GMET 硬件执行陷阱,依靠软件模拟 W^X(受限用户模式),性能损耗 25%~40%;
- 第三方驱动兼容极差,大量工业、外设驱动不满足 HVCI 规范,开启直接蓝屏;
- 仅支持桌面 Windows,服务器无原生支持;无高危驱动黑名单,BYOVD 本地提权仍可绕过。
4. 默认状态:全局关闭,仅企业批量策略手动开启。
阶段二:民用化成熟迭代(Win10 1607 ~ 20H2,2016–2020)—— 独立功能、图形化开关、硬件加速落地
1. Win10 1607(2016,里程碑解绑 Device Guard)
- 正式对外定名 HVCI,解绑 Device Guard 营销概念;
- Windows Defender 安全中心新增核心隔离 - 内存完整性图形一键开关,普通用户可独立启用,不再依赖域控;
- 完善 WHQL 驱动强制 HVCI 兼容性测试,减少蓝屏兼容问题。
2. Win10 1803(2018,硬件加速关键版本)
- 支持 Intel Kabylake 及更新 MBEC(模式基础执行控制)、AMD Zen2 GMET(来宾模式执行陷阱) 硬件指令;
- 老旧 CPU:软件模拟,高性能损耗;
- 新 CPU:CPU 硬件原生拦截非法执行,性能损耗降至 5% 以内,VM 退出次数大幅减少;
- 新增高危漏洞驱动黑名单,加载驱动前拦截已知 BYOVD 提权驱动;
- PowerShell、组策略完整配置 API,支持批量终端基线管控。
3. Win10 2004(2020,补齐内核数据防护 KDP)
- 新增 KDP 内核数据保护(Kernel Data Protection),HVCI 配套第二层防护;
Hypervisor 将内核常量、令牌结构体、权限数组硬件只读锁定,防止内核漏洞篡改
SeDebugPrivilege、安全策略; - 严格限制内核内存分配规则,默认所有内核堆、栈内存标记 RW 不可执行,彻底封堵 Shellcode 写入执行路径;
- 日志完整标准化,事件日志区分驱动拦截、W^X 违规、签名校验失败三类安全事件。
本阶段核心变化
阶段三:Win11 基线固化、服务器全域支持(2021–2022,21H2 / 22H2)—— 默认开启、硬件强制门槛锁死
1. Win11 21H2(2021,安全基线重构)
- 硬件准入强制锁死:
UEFI Secure Boot、TPM2.0、VT‑x/AMD‑V + SLAT、IOMMU(VT‑d/AMD‑Vi)全部硬性要求;老旧 Legacy BIOS 设备无法启用内存完整性;CPU 硬性门槛:Intel 11 代 + / AMD Zen2+,强制具备 MBEC/GMET 硬件执行陷阱;内存最低 8GB、SSD 存储。
- 全新合规硬件预装系统默认开启;S 模式 Windows 永久强制启用,不可手动关闭;Secured‑core 安全核心 PC 出厂标配开启Microsoft ...。
- 与 DMA 硬件防护联动,阻断外设 DMA 攻击篡改内核可执行内存;
- Server 2022 完整支持 HVCI,适配数据库、文件服务器、虚拟化集群业务场景。
2. Win11 22H2(2022,全域驱动黑名单硬化)
- 此前仅开启 HVCI 设备才加载高危驱动黑名单;22H2 升级为全 Windows 设备全局强制校验,无论内存完整性开关状态,双重阻断 BYOVD 攻击;
- 正式实现 Hardware‑enforced 硬件强制代码完整性:SLAT/EPT 页表权限规则由 CPU 固件保护,Hypervisor 软件无法篡改,不再仅依赖虚拟化软件逻辑;
- 扩展防护覆盖:WDF 过滤驱动、打印内核驱动、迷你过滤驱动全部纳入 VTL1 签名校验范围;
- 嵌套虚拟化支持:虚拟机内部可独立开启内存完整性,云主机租户隔离加固。
阶段四:云原生、硬件固件级加固、全域纵深联动(2023–2026,23H2~25H2、Server 2025)
1. 2023–2024 运维与云适配优化
-
发布官方
hvciscan.exe兼容性扫描工具,一键检测不兼容驱动、硬件短板,提前规避蓝屏故障IT之家;hvciscan.exe扫描界面 -
Azure、本地虚拟化集群支持虚拟机嵌套 HVCI,云端服务器远程健康证明(System Guard)校验内存完整性运行状态;
-
ARM64 Windows(Surface、Azure ARM 云主机)完整适配 VBS+HVCI,ARM Secure Launch 固件链绑定内存完整性信任根。
2. Win11 24H2 / 25H2(2025–2026,硬件固件级深度硬化)
- Intel 12 代 +、AMD Zen3 + 平台实现CPU 固件原生内存权限锁定,EPT 二级页表权限标记由 CPU 固件管控,Hypervisor、VTL0 均无法篡改,达成真正硬件强制防护;
- 多层安全深度联动:内存完整性 + CFA 受控文件夹访问 + Defender 篡改防护 + XDR 云端告警联动,形成内核提权也无法加密业务文件的纵深防御;
- 性能持续优化:大内存(≥32GB)AI 负载场景优化内核内存池分配,开启 HVCI 后大型 AI 模型运行性能损耗进一步降低;
- 离线终端本地硬件信任缓存,断网环境仍完整执行签名、驱动黑名单校验;
- Server 2025 Secured‑core 服务器强制基线,内存完整性作为服务器等保必选加固项,配套统一批量策略管控。
配套硬件同步演进时间线
| 时间节点 | CPU 硬件能力 | 对内存完整性的影响 |
|---|---|---|
| 2015 初代 HVCI | VT‑x/AMD‑V + SLAT,无硬件执行陷阱 | 纯软件模拟 W^X,高性能损耗 |
| 2018 Win10 1803 | Intel MBEC / AMD GMET | 硬件拦截非法执行,性能大幅优化 |
| 2021 Win11 21H2 | TPM2.0 + IOMMU + UEFI Secure Boot | 老旧硬件淘汰,统一安全硬件基线 |
| 2024–2026 现代平台 | CPU 固件保护 SLAT/EPT 页表 | Hardware‑enforced 硬件强制,软件层无法绕过 |
分版本核心能力横向对比表
| 系统版本 | 产品定位 | W^X 实现方式 | 核心附加防护 | 默认启用状态 | 适用场景 |
|---|---|---|---|---|---|
| Win10 1507 | Device Guard 企业子模块 | 软件模拟 | 仅驱动签名校验 | 全局关闭,仅组策略部署 | 企业内网终端 |
| Win10 1803 | 独立内存完整性功能 | MBEC 硬件加速 / 软件双路径 | 高危驱动黑名单 | 关闭,用户手动开启 | 企业 + 个人桌面 |
| Win10 2004 | 成熟终端防护 | 硬件优先 | KDP 内核数据保护 | 关闭 | 全类型桌面终端 |
| Win11 21H2 | Windows 安全基线组件 | MBEC 硬件强制 | DMA 硬件防护、Secured‑core 联动 | 全新合规硬件默认开启 | 消费笔记本、品牌整机 |
| Win11 22H2+ | Hardware‑enforced 硬件强制防护 | CPU 固件锁定 EPT 权限 | 全域驱动黑名单、嵌套虚拟化支持 | 合规新机出厂开启 | 桌面、服务器、云虚拟机 |
| 2024–2026 新版 | 全域纵深安全底座 | CPU 原生硬件内存管控 | XDR/CFA/ 篡改防护多层联动 | Secured‑core 设备强制开启 | 终端、服务器、超融合集群 |
演进四大核心趋势总结
- 信任边界从软件转向硬件强制
初代仅依靠 Hypervisor 软件逻辑实现 W^X,现代 Win11 依托 CPU 固件、MBEC/GMET、EPT 硬件层实现 Hardware‑enforced,即便 VTL0 内核完全沦陷也无法篡改内存执行权限,内核 RCE 漏洞利用成本指数级提升。
- 部署范围:企业专属 → 全平台默认安全基线
从仅域控批量部署的增值功能,变为 Win11 新机出厂默认开启、服务器等保强制加固的基础安全能力,覆盖桌面、物理服务器、云虚拟机、ARM 设备。
- 防护边界持续扩张
单一驱动签名校验 → 内核代码 + 内核数据 + DMA 硬件 + 驱动黑名单全链路防护,同时联动受控文件夹访问、Defender XDR 形成勒索、内核漏洞双层阻断。
- 兼容性与运维持续简化
从大量蓝屏、运维部署复杂,到配套
hvciscan.exe扫描工具、WHQL 强制驱动兼容、批量 MDM/Intune 策略,大幅降低企业落地成本。
安全演进核心价值
- 解决传统内核代码完整性(KMCI)致命缺陷:KMCI 运行在受攻击 VTL0 内核,校验逻辑可被漏洞篡改;HVCI 将校验引擎隔离至硬件保护的 VTL1 安全域,校验者本身不可被攻陷;
- 完整对抗主流内核攻击向量:http.sys 远程内核 RCE、BYOVD 第三方驱动本地提权、Rootkit 内核后门、内核内存篡改、DMA 硬件攻击;
- 从单一内核防护功能,升级为 Windows 整套虚拟化安全架构的核心信任根。
内存完整性(Memory Integrity / HVCI)完整底层原理
术语统一
- 界面名称:内存完整性
- 技术标准名:HVCI(Hypervisor‑Protected Code Integrity,虚拟机监控程序保护代码完整性)
- 硬件硬化形态:Hardware‑enforced Code Integrity(硬件强制代码完整性,Win11 22H2+)
底层底座:VBS(基于虚拟化的安全),依赖 CPU 硬件虚拟化 VT‑x/AMD‑V、SLAT 二级地址翻译、MBEC/GMET 硬件执行陷阱、TPM2.0、UEFI Secure Boot。
一、核心分层架构:VTL0 / VTL1 硬件隔离信任域
- VTL 0(不可信普通层)
- 承载完整 Windows 系统:ntoskrnl.exe、各类驱动、http.sys、应用、WinRM 等全部运行在此;
- 存在海量内核缓冲区溢出、本地提权、远程 RCE 漏洞,攻击者一旦拿到内核权限可任意修改 VTL0 内存、页表、权限标记;
- 所有常规系统调用、文件 IO、网络请求都在此执行。
- VTL 1(硬件隔离安全世界 Secure World)
- 极简独立安全域,仅运行校验核心
skci.dll、KDP 内核数据保护、VBS 凭证防护; - 内存、页表、执行权限由 Hypervisor + CPU 固件双重锁定,VTL0 无任何权限读写 VTL1 内存;
- 是内存完整性唯一信任根,所有内核代码校验、内存权限判决全部在此执行。
- 极简独立安全域,仅运行校验核心
必备硬件能力(Hardware‑enforced 硬件强制根基)
- SLAT(EPT/NPT)二级页表:Hypervisor 维护独立主机页表,作为内存权限最终判决依据;
- MBEC(Intel)/ GMET(AMD):CPU 硬件拦截「可写内存执行」,不依赖软件模拟;
- IOMMU VT‑d/AMD‑Vi:阻断外设 DMA 直接篡改内核内存;
- UEFI Secure Boot + TPM2.0:锁定 Hypervisor、SKCI 镜像签名,防止底层固件篡改。
二、三大底层核心机制(内存完整性防护根本)
机制 1:SLAT 双层页表 + MBEC 硬件强制 W^X(写 / 执行互斥)
- VTL0 仅持有客户页表,控制业务读写;
- Hypervisor 维护独立主机 EPT/NPT 页表,是 CPU 硬件访问内存的最终权限标准;
- 永久强制两条铁律,硬件直接拦截违规操作:
- 所有内核代码镜像(驱动、ntoskrnl):主机页表标记 RX 只读执行,永久禁止写入;
- 堆、栈、全局数据、缓冲区:主机页表标记 RW 可写不可执行;
- 系统不存在任何 RWX(同时可写 + 可执行)内存页面。
NtProtectVirtualMemory尝试修改页面执行权限时,只会修改客户页表,底层硬件 EPT 主机页表不会同步更新。CPU 硬件读取主机页表校验权限,一旦检测 RWX 违规,直接抛出 #VE 虚拟化异常,转交 VTL1 SKCI 引擎处理:记录安全日志、触发蓝屏阻断攻击。机制 2:VTL1 SKCI 内核代码签名校验引擎
skci.dll 运行在隔离 VTL1,所有内核模块加载流程被 Hypervisor 前置截获,加载前强制完整校验,未通过直接拒绝映射至内核地址空间。完整驱动加载校验时序
- VTL0 调用
NtLoadDriver加载第三方驱动 / 内核模块; - Hypervisor 捕获系统调用,强制切换至 VTL1 安全域;
- SKCI 从 TPM 可信存储读取系统信任签名库,三重校验:
1)文件必须携带微软 WHQL 可信数字签名;2)驱动不在高危 BYOVD 漏洞驱动黑名单;3)镜像哈希与签名匹配,无篡改;
- 校验通过:Hypervisor 在 EPT 主机页表分配 RX 只读执行权限,允许进入 VTL0 内核;
- 校验失败:直接阻断加载,写入安全审计日志,触发蓝屏 BSOD。
机制 3:KDP 内核数据保护(HVCI 配套底层防护)
- Hypervisor 将内核只读全局数据、安全策略、令牌结构体、特权数组(
SeDebugPrivilege/ 模拟令牌 / SID 组)硬件标记永久只读; - VTL0 内核漏洞无法篡改权限配置、凭证指针、页表元数据;
- 阻断经典本地提权链路:修改账户特权、替换进程令牌、篡改 LSA 凭证指针。
三、完整攻击拦截时序示例(http.sys 内核远程 RCE 漏洞)
- 攻击者发送畸形 HTTP 数据包,触发 http.sys 缓冲区溢出,在 RW 数据缓冲区写入恶意 Shellcode;
- 漏洞尝试调用内存权限 API,把数据页改为可执行以运行 Shellcode;
- CPU 读取底层 EPT 主机页表,发现违规 RWX 组合,触发硬件虚拟化异常;
- 切换至 VTL1 SKCI 引擎判定为违规执行行为;
- 系统直接蓝屏终止攻击链路,Shellcode 永远无法执行,远程内核 RCE 完全失效。
四、区分:初代软件模拟 HVCI VS Win11 硬件强制 HVCI 底层差异
- Win10 早期软件模拟(无 MBEC)
- W^X 靠 Hypervisor 软件捕获执行异常;
- 性能损耗 20%~40%;
- 极端漏洞链存在绕过软件校验路径。
- Win11 Hardware‑enforced 硬件强制
- MBEC/GMET CPU 硬件原生实现 W^X 执行拦截,硬件判决优先于软件;
- EPT 页表权限受 CPU 固件保护,Hypervisor、VTL0 均无法篡改;
- TPM+Secure Boot 锁死 VTL1 校验引擎,攻击者无法替换 SKCI;
- 攻击链路彻底断裂:控制 VTL0 内核也无法修改硬件内存执行权限,无法运行内核 Shellcode、无法加载未签名 Rootkit 驱动。
五、与其他安全组件底层联动
1. 与受控文件夹访问 CFA 纵深防御
- 内存完整性:阻止恶意内核驱动、内核代码执行;
- CFA 内核过滤驱动 WdNisDrv:即便拿到 SYSTEM 内核权限,未信任程序也无法加密受控目录文件;
二者组合实现:提权无法落地、落地无法加密完整勒索防护链。
2. 与 Defender 篡改防护联动
- SKCI 驱动 skci.dll、Hypervisor 镜像受 HVCI 签名保护,无法被卸载、替换、打补丁;
- 内存完整性开关、VBS 相关注册表项添加内核 ACL 保护,恶意程序无法关闭防护。
3. 与 IOMMU DMA 防护联动
六、底层性能优化设计
- 所有 EPT 页表权限判断、签名校验缓存常驻 VTL1 内核内存,极少切换 VTL0/VTL1 上下文;
- 系统核心驱动、微软自带模块提前缓存校验结果,重复加载免重复签名校验;
- MBEC 硬件执行陷阱大幅减少虚拟化 #VE 异常中断,现代 CPU 性能损耗控制在 5% 以内;
- 仅内核加载、内存权限变更触发完整校验,常规业务读写几乎无开销。
七、底层安全核心结论
- 信任边界反转
传统 KMCI(普通代码完整性)运行在 VTL0,校验器可被内核漏洞篡改;HVCI 将校验逻辑放入硬件隔离 VTL1,被保护系统完全无权触碰校验引擎。
- 双层不可绕过防护
软件层:VTL1 SKCI 签名校验拦截非法驱动加载;硬件层:SLAT+MBEC 锁死内存读写执行权限,阻断任意代码执行篡改。
- Hardware‑enforced 本质
安全规则不再单纯依赖 Hypervisor 软件代码,固化在 CPU 固件、二级页表硬件机制,内核 RCE、BYOVD 驱动提权、Rootkit 持久化攻击成本指数级提升,是 Windows 内核安全底层信任根。
HVCI(硬件强制代码完整性 / Hypervisor‑Protected Code Integrity)完整演进史
一、前置概念澄清
- 全称:Hypervisor‑Protected Code Integrity,市场界面名称为内存完整性(Memory Integrity),行业俗称 HVCI;题目中 Hardware‑enforced Code Integrity 是硬件强制代码完整性,二者同一技术栈,HVCI 是 Windows 官方标准命名learn.micr...。
- 底层底座:VBS(基于虚拟化的安全),依托 CPU VT‑x/AMD‑V + SLAT(EPT/NPT)硬件虚拟化,拆分两层信任域:
- VTL0:普通 Windows 内核(ntoskrnl,可被漏洞攻陷)
- VTL1:隔离安全内核(skci.dll 运行于此,HVCI 校验逻辑根信任,VTL0 无法篡改 hypervisor 内存权限规则)
- 核心防御逻辑:Hypervisor 强制全局 W^X(写 / 执行互斥),内核驱动加载、内存分配全部由 VTL1 签名校验,即使 VTL0 内核被攻破,也无法写入并执行恶意内核代码、无法加载未签名恶意驱动 /rootkit。
二、演进四阶段:前置技术铺垫 → 初代落地 → 功能迭代 → 硬件原生硬化 + 默认全域启用
阶段 1:前置技术铺垫(2006–2014,内核代码签名雏形)
1. Vista / Win7:基础内核代码签名 KMCI
- 仅在 VTL0 内核执行签名校验,存在致命缺陷:内核一旦被提权攻陷,攻击者可直接 Patch CI 校验逻辑、绕过签名加载恶意驱动;
- 无硬件虚拟化隔离,依赖 OS 自身保护,面对内核 RCE、驱动漏洞完全失效(MS15‑034 http.sys、各类驱动提权漏洞均可直接破坏 KMCI)。
2. Windows 8 / Server 2012:VBS 原型、Credential Guard 先行落地
- 微软完成 Hyper‑V 轻量化 hypervisor 重构,实现 VTL 隔离硬件基础;
- 推出 Credential Guard(VTL1 隔离凭证),验证 VBS 架构可行性,为 HVCI 铺路;
- 硬件基础定型:强制 64 位、SLAT 二级地址翻译、UEFI Secure Boot、TPM 2.0。
阶段 2:初代 HVCI 诞生(Windows 10 1507 / Server 2016,2015)—— Device Guard 附属功能
- 产品定位:作为Device Guard企业套件内置模块,无独立 UI 开关,仅企业域控通过组策略部署,消费机不可见。
- 核心实现
- 首次将代码完整性校验逻辑移入 VTL1 安全内核,脱离不可信 VTL0;
- Hypervisor 通过 SLAT/EPT 锁死内核内存 W^X 权限,VTL0 无法修改可执行页权限;
- 仅校验驱动数字签名,无运行时内核数据防护,无硬件辅助执行拦截。
- 局限
- 硬件兼容门槛极高,老旧 CPU 无 MBEC/GMET,性能损耗极大;
- 仅企业批量部署,普通用户无图形化开关;
- 大量第三方驱动不满足 HVCI 兼容规范,开启后蓝屏、设备失效。
阶段 3:独立成熟化迭代(Win10 1607 ~ 2004,2016–2020)—— 脱离 Device Guard、硬件加速、安全能力分层增强
1. Win10 1607(2016,关键更名节点)
- 正式定名HVCI(Hypervisor‑Protected Code Integrity),解绑 Device Guard 营销概念;
- Windows 安全中心新增图形化「内存完整性」一键开关,普通用户可独立启用,不再依赖域策略;
- 强制驱动开发规范:WHDK 强制 HVCI 兼容性测试,驱动禁止动态生成内核可执行代码。
2. Win10 1803(2018,硬件加速落地)
- 支持 Intel Kabylake 及更新 CPU MBEC(Mode‑Based Execution Control)、AMD Zen2 GMET硬件执行陷阱;
- 老 CPU 回退软件模拟 W^X,性能损耗 20%–40%;新 CPU 硬件拦截,性能下降控制在 5% 以内;
- 新增驱动漏洞黑名单校验,加载驱动前拦截已知高危漏洞驱动(BYOVD 攻击载体)。
3. Win10 2004(2020,数据防护补齐)
- 新增 KDP(Kernel Data Protection,内核数据保护),HVCI 体系第二层防护;
- hypervisor 隔离内核只读数据、全局常量,防止内核漏洞篡改系统安全配置、CI 校验结构体;
- 完善内核池分配限制:所有内核内存分配默认不可执行,彻底封堵 “写内存 + 执行” 经典提权链路。
阶段 4:硬件原生硬化、全域默认启用(Windows 11 21H2 ~ 22H2 + Server 2022 至今,2021–2026)
1. Windows 11 21H2(2021):硬件强制门槛,消费机默认开启
- 硬件准入锁死:
- UEFI Secure Boot、TPM2.0、VT‑x/AMD‑V + SLAT、IOMMU(VT‑d/AMD‑Vi)全部强制;Legacy BIOS 直接无法启用 HVCI;
- 强制支持 MBEC/GMET 现代 CPU,淘汰老旧 CPU 软件模拟模式;
- 默认策略:全新预装合规硬件设备,内存完整性(HVCI)出厂默认开启;S 模式 Windows 强制永久启用,不可关闭;
- 与 Secured‑core PC 深度绑定:安全核心主机将 HVCI、DMA 防护、VBS、TPM 链作为基础安全基线。
2. Win11 22H2(2022):驱动黑名单全域强制,攻击面大幅收缩
- 此前仅 HVCI 开启设备加载驱动时校验高危驱动黑名单;22H2 后所有 Windows 设备全局启用,无论 HVCI 开关状态,双重阻断 BYOVD 本地提权攻击;
- 扩展 HVCI 保护范围:内核打印驱动、WDF 过滤驱动、第三方迷你过滤驱动全部纳入 VTL1 签名校验。
3. Windows Server 2022 / 2025 服务器强化
- Secured‑core Server 标配 HVCI,支持远程健康证明(System Guard),云端校验服务器 HVCI 运行状态;
- 新增 DMA 防护联动 HVCI,阻止硬件 DMA 攻击篡改内核可执行内存;
- 支持虚拟机内 HVCI(嵌套虚拟化 VBS),云服务器租户隔离加固。
4. 2024–2026 最新演进:CPU 固件级硬件强制(Hardware‑enforced Code Integrity)
- CPU 硬件层原生 HVCI 辅助(对应题目 Hardware‑enforced Code Integrity)
Intel 12 代 +、AMD Zen3 + 平台引入固件级内存权限锁定,SLAT/EPT 表由 CPU 固件保护,hypervisor 之外固件不可篡改,真正实现硬件强制,不再仅依赖 hypervisor 软件逻辑;
- ARM64 Windows 优化:适配 Azure ARM 服务器、Surface ARM 设备,Secure Launch 固件链绑定 HVCI;
- 漏洞对抗增强:针对各类内核漏洞(http.sys、驱动溢出、本地提权)扩展 W^X 边界,封堵 ROP/JOP 辅助执行路径;
- 运维简化:WHQL 驱动强制 HVCI 兼容,第三方软件蓝屏兼容性问题大幅减少。
三、硬件配套演进时间线(HVCI 依赖硬件同步升级)
| 时期 | CPU / 固件能力 | HVCI 影响 |
|---|---|---|
| 2015 初代 | VT‑x/AMD‑V + SLAT,无硬件执行陷阱 | 全软件模拟 W^X,性能损耗高 |
| 2018 | Intel MBEC / AMD GMET | 硬件拦截非法执行,性能优化 |
| 2021 Win11 基线 | TPM2.0 + IOMMU + UEFI Secure Boot | 老旧硬件彻底淘汰,安全链路闭环 |
| 2024–2026 | CPU 固件保护 SLAT 页表、内存属性硬件锁定 | 实现 Hardware‑enforced 硬件强制代码完整性,hypervisor 不可被绕过 |
四、HVCI 演进核心能力对比(分版本)
| 版本 | 名称定位 | 校验隔离层 | W^X 实现 | 附加防护 | 默认状态 |
|---|---|---|---|---|---|
| Win10 1507 | Device Guard 子模块 | VTL1 安全内核 | 软件模拟 | 仅驱动签名校验 | 关闭,仅企业组策略部署 |
| Win10 1607 | HVCI 独立功能 | VTL1 SKCI | 软件 / 硬件双路径 | 图形开关、基础驱动黑名单 | 关闭,用户手动开启 |
| Win10 2004 | HVCI 成熟版 | VTL1 + hypervisor 双层锁 | MBEC 硬件加速 | KDP 内核数据保护 | 关闭 |
| Win11 21H2 | 内存完整性(HVCI) | CPU 硬件辅助 + VTL1 | 纯硬件拦截 | Secured‑core 联动、DMA 防护 | 合规硬件默认开启 |
| Win11 22H2+ | Hardware‑enforced HVCI | 固件 + hypervisor 双重隔离 | CPU 原生内存权限锁定 | 全域高危驱动黑名单、嵌套虚拟化支持 | 出厂默认开启,服务器强制 |
五、演进核心安全价值总结
- 架构颠覆:将代码校验从受攻击的 OS 内核(VTL0)下移至 hypervisor 隔离的 VTL1,解决传统 KMCI “校验者本身可被攻陷” 的底层缺陷;
- 从软件防护走向硬件强制:初代依赖 hypervisor 软件逻辑,新版依托 CPU 固件、EPT/MBEC 硬件指令实现 Hardware‑enforced 强制约束,攻击成本指数级提升;
- 部署模式转变:从企业专属增值功能 → 全平台默认基础安全基线,覆盖桌面、服务器、ARM 云主机;
- 防护边界持续扩张:单纯驱动签名校验 → 内核代码 + 内核数据 + 硬件 DMA + 第三方驱动全链路防护,完整对抗 rootkit、内核 RCE、BYOVD 本地提权、http.sys 类内核远程漏洞。
HVCI 硬件强制代码完整性底层完整原理
一、基础架构前置:VBS 虚拟化安全分层(HVCI 运行底座)
- VTL 0(非信任层,普通 Windows)
常规操作系统内核
ntoskrnl.exe、驱动、应用、所有网络服务(http.sys、WinRM)全部运行在此;该层存在大量内核漏洞(缓冲区溢出、UAC 提权、BYOVD 驱动漏洞),攻击者可完整控制 VTL0 内核内存、修改页表、篡改权限标记。 - VTL 1(高安全隔离层,安全世界 Secure World)
由独立极简 Hypervisor(hvix64.exe)调度,硬件 SLAT/EPT 页表隔离内存;HVCI 核心校验引擎
skci.dll、KDP 内核数据保护、凭证防护全部运行在 VTL1;VTL0 完全无法读取、修改、执行 VTL1 内存,硬件地址翻译机制阻断跨层篡改。
依赖硬件基础(Hardware-enforced 硬件强制核心条件)
- CPU 虚拟化:Intel VT-x / AMD-V;
- SLAT 二级地址翻译(Intel EPT / AMD NPT):Hypervisor 独立维护第二套内存页表;
- MBEC(Intel)/ GMET(AMD)硬件执行陷阱:CPU 硬件层面拦截「可写内存直接执行」,不依赖软件模拟;
- IOMMU VT-d / AMD-Vi:阻断 DMA 硬件直接读写内核内存;
- UEFI Secure Boot + TPM2.0:链根信任,防止篡改 Hypervisor、VBS 固件。
二、三大底层核心机制(HVCI 防护本质)
机制 1:SLAT/EPT 双层独立页表,内存权限硬件隔离
- VTL0:持有客户页表,控制程序、内核正常业务内存访问;
- Hypervisor 维护一套独立主机页表(EPT/NPT),作为硬件最终权限判决依据;
- 内存权限双锁规则:
- 内核驱动、系统镜像代码页:主机页表永久标记为 只读 + 仅执行(RX),禁止写入;
- 全局数据、栈、堆内存:主机页表永久标记为 可写不可执行(RW);
- 不存在任何同时可写 + 可执行(RWX)的内存页面,硬件直接拦截。
NtProtectVirtualMemory 修改页权限时,仅修改客户页表,底层硬件 EPT 主机页表不会同步更新;CPU 硬件读取主机页表做权限校验,任何 RWX 尝试直接触发 #VE 虚拟化异常,转交 VTL1 HVCI 引擎拦截、蓝屏拒绝执行。
机制 2:VTL1 SKCI 代码完整性签名校验引擎
skci.dll 运行在隔离 VTL1,是 HVCI 校验核心,所有内核模块加载流程被 Hypervisor 截获,强制校验:- 驱动 / 内核镜像加载拦截流程
- VTL0 调用
NtLoadDriver加载驱动; - Hypervisor 捕获加载事件,转发至 VTL1 SKCI;
- SKCI 从 TPM 安全存储读取系统信任签名库,校验文件:
- 必须带有微软 WHQL 可信数字签名;
- 不在高危驱动黑名单(BYOVD 漏洞驱动拦截);
- 镜像完整无篡改,哈希匹配签名;
- 校验通过:Hypervisor 在 EPT 页表分配 RX 只读执行权限,允许加载进内核;
- 校验失败:直接拒绝加载,记录安全日志,触发蓝屏。
- VTL0 调用
- 运行时代码防护
禁止 VTL0 动态生成内核代码:JIT 内核代码、驱动自解压 Shellcode、动态补丁内核均会被 VTL1 检测,硬件 EPT 阻止执行。
机制 3:KDP 内核数据保护(HVCI 配套底层防护)
- Hypervisor 将内核常量、安全策略、令牌结构体、页表元数据标记为硬件只读;
- VTL0 内核漏洞无法篡改安全策略、特权列表、LSA 凭证指针;
- 阻断经典提权路径:篡改
SeDebugPrivilege、替换系统服务令牌、修改 SID 权限组。
三、硬件强制 Hardware-enforced 与早期软件 HVCI 核心底层差异
1)初代 HVCI(Win10 1507~2004,软件模拟 W^X)
- 无 MBEC/GMET 硬件指令,依靠 Hypervisor 软件捕获执行异常;
- 仅靠软件逻辑限制 RWX,性能损耗 20%~40%;
- 若 VTL0 内核完全沦陷,存在极端路径绕过软件校验逻辑。
2)Hardware-enforced 硬件强制 HVCI(Win11 21H2+)
- CPU MBEC/GMET 硬件原生实现 W^X,内存执行权限由 CPU 固件硬件判决,Hypervisor 软件无法篡改;
- EPT/SLAT 页表本身受 CPU 固件保护,VTL0 甚至 Hypervisor 都无法改写页表权限标记;
- 根信任链固化在 UEFI+TPM,攻击者无法替换 SKCI 校验引擎;
- 攻击链路彻底断裂:
漏洞控制 VTL0 内核 → 无法修改硬件 EPT 权限 → 无法创建 RWX 执行内存 → 无法运行内核 Shellcode → 无法加载未签名 Rootkit 驱动。
四、完整内核驱动加载底层时序(直观流程)
1. 应用/服务发起加载驱动请求 NtLoadDriver(VTL0)
↓
2. Hypervisor 捕获系统调用,切换至VTL1安全域
↓
3. SKCI(VTL1)读取驱动镜像,校验数字签名、哈希、驱动黑名单
↓
├─校验失败 → Hypervisor 阻断加载,触发蓝屏 BSOD
└─校验通过 → 进入内存权限分配
↓
4. Hypervisor 修改硬件EPT主机页表:
代码段 = RX(只读执行),数据段 = RW(可写不可执行)
↓
5. 切回VTL0,驱动加载完成;CPU硬件持续监控所有内存访问
↓
6. 若漏洞尝试将数据页改为可执行:
CPU MBEC硬件抛出虚拟化异常 → 转交VTL1 HVCI拦截,系统终止执行并记录安全审计日志
五、对抗各类漏洞底层防护逻辑
1. http.sys 内核远程漏洞(缓冲区溢出 RCE/DoS)
2. BYOVD 本地提权(恶意驱动加载)
3. UAC 本地提权、令牌篡改
SeDebugPrivilege、模拟令牌等关键权限结构。4. Rootkit 内核后门、驱动补丁
六、底层安全边界核心结论
- 信任边界彻底反转
传统代码完整性(KMCI)运行在 VTL0,校验器本身可被漏洞篡改;HVCI 将校验逻辑下移至硬件隔离 VTL1,被保护系统无法触碰校验引擎。
- 分层双重防护
软件层:VTL1 SKCI 签名校验,拦截非法驱动加载;硬件层:CPU SLAT+MBEC 内存权限锁死,阻断任意内存执行篡改。
- Hardware-enforced 硬件强制的本质
安全规则不再仅依赖 Hypervisor 软件代码,而是固化在 CPU 固件、二级页表硬件机制,形成软硬件双层不可绕过防护,大幅抬高内核漏洞利用、持久化 Rootkit 攻击成本。
HVCI(Hardware-enforced Code Integrity,硬件虚拟化代码完整性)**是Windows系统中的一项安全技术,通过结合硬件虚拟化技术(如Intel VT-x和AMD-V)和操作系统的安全机制,增强代码完整性保护,以防止恶意代码或驱动程序被加载到系统中。HVCI 主要用于防止驱动程序和内核模式代码的攻击,它通过强制使用硬件级别的虚拟化和内存保护来提高防护能力。
HVCI 在 Windows 系统中的发展时间线如下:
1. Windows 10(2015年发布)
- 首次引入 HVCI:HVCI 技术首次在 Windows 10 中正式引入,作为 Device Guard 的一部分。Device Guard 是一个组合安全特性,旨在通过限制可以在设备上运行的代码,来增强系统的防御能力。HVCI 作为 Device Guard 的一项子功能,通过硬件虚拟化来强制执行内核模式的代码完整性。
- 技术实现:
- HVCI 依赖于支持硬件虚拟化的 CPU(如 Intel VT-x 和 AMD-V)以及启用了 Windows Defender Device Guard 的系统。HVCI 强制通过虚拟化技术验证内核代码和驱动程序的完整性。
- 主要作用是防止恶意的驱动程序或恶意代码在内核模式下运行,确保只有经过签名且经过验证的驱动程序才能被加载。
- Windows 10 在启用 HVCI 后,内核模式代码将运行在一个受保护的环境中,利用虚拟化技术来阻止对内存的恶意操作。
2. Windows 10 Fall Creators Update(2017年10月发布)
- HVCI 默认启用:在 Windows 10 Fall Creators Update 中,HVCI 的支持进一步增强,且开始在更多的设备和配置中默认为启用。此更新使得 HVCI 成为提高 Windows 操作系统安全性的标准之一。
- 硬件要求:此版本的 Windows 10 强化了对硬件虚拟化的要求,只有支持硬件虚拟化的 CPU 和启用了安全启动的设备才能启用 HVCI。
- 性能优化:为了在启用 HVCI 时不会影响系统性能,微软进行了优化,确保了即使在启用 HVCI 的情况下,系统性能依然保持在较高水平。
3. Windows 10 1903(2019年发布)
- 增强的硬件支持:在 Windows 10 1903 中,HVCI 功能得到了进一步的改进,特别是在对 AMD 处理器的支持上。Windows 10 1903 提供了对更多硬件平台的支持,尤其是对于 支持硬件虚拟化的 Intel 和 AMD 处理器。
- HVCI 性能和兼容性提升:
- 微软在此版本中继续优化了 HVCI 的性能,减少了启用该功能时可能出现的兼容性问题,特别是对一些第三方驱动程序和应用程序的兼容性测试。
- 进一步提升了对 内核代码和驱动程序的验证,防止未签名或恶意软件加载进系统。
4. Windows 10 2004(2020年发布)
- 更加全面的 HVCI 保护:在 Windows 10 2004 中,HVCI 得到了进一步的改进,特别是在安全性方面。例如,微软通过对新硬件的支持和增加更强的保护,进一步强化了 HVCI 的作用。
- 新增的内核保护功能:
- 在 Windows 10 2004 中,HVCI 与 Windows Defender Credential Guard 进行了整合,增强了对恶意攻击者的防护。Credential Guard 是一个用于保护用户凭据的安全功能,而 HVCI 则用于防止恶意代码和驱动程序在内核模式下运行。
- 系统能够通过 HVCI 加强对虚拟化保护代码(VBS)和 内存完整性 的控制,防止恶意软件通过绕过内存保护机制来获得对系统的控制。
5. Windows 10 21H1(2021年发布)
- 全面支持 HVCI:随着 Windows 10 21H1 的发布,HVCI 的默认启用更加普遍,特别是在 64 位的设备中,HVCI 成为更加标准的安全选项。该版本增强了 HVCI 和其他内核保护技术(如 Memory Integrity)之间的协同工作能力。
- 安全性改进:
- Windows 10 21H1 版本加强了硬件虚拟化和内核级保护的集成。通过提升 HVCI 与其他安全技术(如 Core Isolation)的互操作性,进一步提高了系统的防护等级。
- 该版本还加强了对第三方驱动程序的安全检测和验证,确保只有经过微软认证的驱动程序能够在系统中运行。
6. Windows 11(2021年发布)
- HVCI 成为默认安全要求:在 Windows 11 中,HVCI 得到了更为严格的要求和更深层的集成。Windows 11 强制要求所有受支持的设备启用硬件虚拟化,并且默认启用 HVCI 来增强系统的安全性。
- 硬件和功能要求:
- Windows 11 要求支持 TPM 2.0(受信平台模块)和 安全启动(Secure Boot),并且必须启用硬件虚拟化才能使用 HVCI。这确保了系统的启动过程和内核的安全性得到了强化。
- HVCI 在 Windows 11 中被强化为操作系统的核心安全功能之一,用于防止未经授权的驱动程序和恶意代码加载到系统中。
7. Windows 11 22H2(2022年发布)
- 进一步增强的内核保护:在 Windows 11 22H2 版本中,微软进一步加强了 HVCI 的性能和兼容性,提升了对新硬件架构的支持。HVCI 与其他内核保护功能(如 VBS 和 Memory Integrity)的集成得到进一步优化,确保系统对零日攻击和高级持久威胁(APT)的防护能力。
- 硬件支持扩展:Windows 11 22H2 提高了对各种现代硬件的支持,包括最新的 Intel 和 AMD 处理器。优化了硬件虚拟化的兼容性,使得即使在复杂的硬件配置下也能顺利启用 HVCI。
HVCI 在 Windows 系统中的发展经历了多个阶段,从最初的 Windows 10 引入,到在 Windows 11 中成为强制启用的核心安全功能,HVCI 已经成为现代操作系统安全防护的关键组成部分。它依赖于硬件虚拟化技术,通过强制内核代码完整性验证,有效地阻止恶意代码或未经授权的驱动程序在内核模式下运行,提升了系统的整体安全性。随着 Windows 系统版本的更新,HVCI 的性能、兼容性以及对硬件的支持不断得到增强,成为抵御现代高级威胁的重要工具。
启用 内核完整性保护(HVCI) 和 受控文件夹访问(CFA) 是 Windows 操作系统中用于增强系统安全性的两项功能。它们的作用是防止恶意软件的攻击,保护系统的完整性,并帮助防止用户的文件被恶意程序篡改。
1. 内核完整性保护(HVCI,Hypervisor-Enforced Code Integrity)
内核完整性保护(HVCI)是通过硬件虚拟化技术(Hypervisor)来增强操作系统内核的安全性。这项技术利用虚拟化的硬件层对内核代码进行完整性验证。它可以阻止未经授权的代码在内核模式下运行,从而避免一些典型的内核漏洞攻击。
HVCI的工作原理:
- HVCI 通过将内核代码加载到一个隔离的虚拟机环境中,确保内核的代码没有被篡改。
- 任何未经验证或已知的恶意代码无法在内核空间执行。
- 该技术依赖于硬件支持的虚拟化功能,如 Intel VT-x 和 AMD-V 技术。
启用HVCI的好处:
- 增强系统的防御能力,可以防止某些类型的内核级攻击。
- 有助于保护系统免受恶意软件通过内核漏洞进行的攻击,如驱动程序漏洞和内核模式的恶意代码注入。
受控文件夹访问 CFA(Controlled Folder Access)完整演进史
WDNisDrv.sys 实现文件系统回调监控,演进分为四大阶段:概念落地初代、企业运维成熟、服务器全域支持、云原生 + 硬件安全联动增强(2017–2026)。一、前置背景:2016 技术铺垫(CFA 诞生前夜)
- EMET 淘汰,微软重构 Windows Defender Exploit Guard 漏洞防护套件,规划四层防护:ASR 规则、CFA 受控文件夹、网络防护、内核缓解措施。
- 全球 WannaCry、NotPetya 勒索病毒爆发,传统特征码杀毒存在滞后缺陷,微软需要行为拦截型防护:不依赖病毒库,直接阻断未授权程序加密 / 覆盖文件。
- 文件系统过滤驱动底层接口完善,支持全局目录写入回调拦截,具备实现目录白名单管控底层条件。
二、阶段 1:初代落地(Win10 1709 秋季创意更新 2017.10,CFA 正式诞生)
核心定位
初代核心能力
- 默认保护目录:自动保护所有用户桌面、文档、图片、视频、音乐、收藏夹;系统关键目录强制保护、不可删除。
- 信任判定双逻辑
- 自动信任:微软云信誉、高流行度 WHQL 签名软件;
- 手动信任:管理员手动添加程序路径白名单,仅指定路径程序放行。
- 三种运行模式:启用(拦截 + 告警)、审核(仅记录不拦截)、关闭。
- 管理入口:Windows Defender 安全中心图形界面、组策略、PowerShell 三条配置渠道。
初代局限
- 仅支持本地文件夹,不支持网络共享目录;
- 仅监控文件写入、覆盖、删除,无底层磁盘扇区防护;
- 仅桌面 Windows 支持,无 Server 服务器版本;
- 白名单仅支持固定绝对路径,不支持环境变量通配符;
- 日志简陋,无统一终端安全平台汇总报表。
底层实现初代短板
三、阶段 2:功能成熟迭代(Win10 1809 ~ 20H2 2018–2020,企业运维全面优化)
1. Win10 1809(2018)关键升级
- 新增网络共享文件夹保护,支持添加内网 SMB 共享路径到受控列表;
- 信任路径支持环境变量:
%LOCALAPPDATA%、%USERPROFILE%,适配多用户终端; - 完善事件日志(EventID 1124 审核、1127 拦截),支持 SIEM 日志转发;
- PowerShell 完整 CFA 配置命令集,支持批量导入导出受保护目录 / 信任程序。
2. Win10 2004(2020)企业运维增强
- 白名单支持证书信任:匹配程序数字证书放行,无需固定文件路径;
- Defender for Endpoint(原 ATP)深度联动:CFA 拦截事件同步至云端门户,生成勒索攻击告警、设备时间线;
- 缓解大量 MSI 安装包、备份工具误拦截,优化信誉自动信任基线;
- 支持通过 MDM/Intune 批量下发 CFA 策略,适配移动办公终端。
阶段核心变化
四、阶段 3:服务器全域覆盖 + 底层防护扩容(2019–2022 Server/Win11 基线固化)
1. Windows Server 2019 新增 CFA 支持(2019)
- 服务器原生支持受控文件夹,保护数据库目录、网站根目录、备份共享;
- 适配服务账户后台进程管控,拦截恶意服务加密业务数据;
- 支持 Configuration Manager SCCM 批量服务器策略推送。
2. Windows 11 21H2(2021)安全基线升级
- 与 Secured-core PC 深度绑定:安全核心设备推荐默认开启 CFA,作为勒索基础防护基线;
- 底层扩展防护范围:新增磁盘扇区写入拦截,阻止恶意程序改写 MBR、分区表;
- 优化过滤驱动性能,后台文件读写监控 CPU 损耗大幅降低;
- Windows 安全中心 UI 重构,CFA 独立勒索防护分类,普通用户一键启用。
3. Windows Server 2022(2022)服务器加固强化
- 支持集群共享卷 CSV 保护,适配虚拟化集群文件服务器;
- 审核模式日志细化,区分勒索加密、批量覆盖、删除三类行为;
- 与 HVCI、VBS 虚拟化安全联动:内核提权漏洞拿到系统权限后,仍无法篡改受控目录文件。
本阶段里程碑
五、阶段 4:云原生、证书 / IoC 智能信任、全域闭环防护(2023–2026 当前最新演进)
1. 2023 Defender 平台大更新
- IoC 指示器放行:通过 Defender 端点 IoC 规则,基于程序哈希、证书批量信任合规软件,替代手动逐条添加路径;
- OneDrive 云同步目录原生兼容 CFA,修复云备份同步误拦截问题Microsoft ...;
- 篡改防护(Tamper Protection)锁定 CFA 策略:恶意程序、管理员本地无法关闭 CFA、清空信任列表,防止勒索病毒篡改安全配置。
2. Win11 22H2 ~ 24H2 多层防御联动
- 扩展脚本拦截:PowerShell、VBS、WSH 脚本批量写入受控目录统一拦截,对抗脚本型勒索;
- 容器支持:Azure 虚拟机、Windows 容器内支持嵌套 CFA,隔离容器内加密行为;
- 通配符路径优化,适配多版本软件目录自动匹配。
3. 2025–2026 最新硬件 + 云协同升级
- 深度集成 Microsoft Defender XDR:跨设备 CFA 拦截事件关联勒索横向移动告警,自动隔离受感染终端;
- ARM64 Windows(Azure ARM 服务器、Surface)完整适配 CFA 文件过滤驱动;
- 底层驱动加固:与 IOMMU、DMA 防护联动,阻止硬件 DMA 攻击绕过 CFA 篡改文件;
- 离线终端本地信誉缓存,断网环境仍可自动信任合规程序,不产生大量误拦截;
- 支持 Azure Stack HCI 超融合服务器集群统一 CFA 策略管控Microsoft ...。
六、CFA 四大演进核心维度对比表
| 版本阶段 | 保护目录范围 | 程序信任机制 | 部署渠道 | 配套安全联动 |
|---|---|---|---|---|
| Win10 1709 初代 | 本地用户库目录 | 路径白名单 + 云信誉 | 组策略、本地 UI | 仅 Exploit Guard 套件 |
| Win10 1809–20H2 | 本地 + SMB 网络共享 | 路径 + 环境变量 + 证书 | 组策略、Intune、PowerShell | Defender for Endpoint 云端日志 |
| Win11 21H2 / Server2022 | 本地、共享、集群 CSV、磁盘扇区 | 证书、路径、自动信誉 | MDM、SCCM、组策略 | HVCI/VBS、Secured-core |
| 2023–2026 最新版 | 本地、SMB、云盘、容器、集群 | 路径、证书、IoC 哈希指示器 | XDR 全域统一策略、离线缓存 | XDR 跨终端关联告警、DMA 硬件防护 |
七、演进底层逻辑总结
- 防护思路转变
初代:单纯目录白名单,事后拦截文件修改;新版:多层闭环防护 —— 行为拦截 + 策略防篡改 + 云端溯源 + 硬件安全联动,阻断勒索完整杀伤链。
- 部署范围扩张
仅个人桌面 → 企业终端 → Windows 服务器、虚拟化集群、ARM 云主机、容器全覆盖。
- 信任体系智能化
人工手动添加路径 → 自动云信誉、证书批量放行、IoC 哈希规则自动化管控,大幅降低运维误拦截工作量。
- 安全底座深度融合
独立文件防护功能 → 与 VBS/HVCI 内核虚拟化安全、DMA 硬件隔离、篡改防护联动,形成 “内核提权也无法加密文件” 的纵深防御。
受控文件夹访问 CFA(Controlled Folder Access)完整底层原理
一、整体架构总览
WdNisDrv.sys 实现内核层拦截,属于 Windows Filter Manager(FltMgr)过滤框架。
应用程序(PowerShell/勒索病毒/EXE)
↓ 用户态 Win32 API(CreateFile/WriteFile/SetFileInformationByHandle)
NtCreateFile / NtWriteFile 系统调用
↓
FltMgr 过滤管理器(内核层统一钩子框架)
↓
WdNisDrv.sys Defender 微型过滤驱动(CFA 核心逻辑载体)
↓
1. 匹配是否为【受控文件夹】
2. 校验发起进程是否为【受信任程序】
3. 允许/拦截写入、覆盖、删除、重命名操作
↓
拦截:生成安全事件日志、阻断IO操作、返回拒绝访问
放行:传递IO请求至文件系统(NTFS/FAT/SMB重定向器)
二、核心底层依赖组件
1. FltMgr 微型过滤管理器(Windows 内置内核框架)
- 全局挂载文件系统回调,在所有磁盘、SMB 网络共享、CSV 集群卷的 IO 路径插入钩子;
- 支持多层过滤:Defender CFA、第三方杀毒、备份软件共用过滤栈;
- 提供预操作回调
PreOperationCallback:文件打开 / 写入前触发校验,CFA 在此处做阻断。
2. WdNisDrv.sys 内核驱动(CFA 逻辑载体)
- CFA 受控文件夹访问校验引擎;
- ASR 攻击面缩减规则执行引擎;
- 勒索软件行为特征监控;
所有目录白名单、信任程序列表、审核 / 拦截模式全部缓存在内核内存,无需频繁切换用户态,性能损耗极低。
3. 用户态配置持久化存储
HKLM\SOFTWARE\Microsoft\Windows Defender\Windows Defender Exploit Guard\Controlled Folder Access
ProtectedFolders:受控目录路径数组;AllowedApplications:手动信任程序路径;AllowedCertificateSigners:信任证书签发者;EnableControlledFolderAccess:0 关闭 / 1 拦截模式 / 2 审核模式;系统启动时WdNisDrv读取注册表加载策略至内核。
4. Defender 云信誉服务(用户态辅助)
MsMpEng.exe 后台进程负责:- 上传未知程序哈希至微软云信誉库;
- 拉取高可信、广泛使用软件白名单,同步至内核驱动自动放行;
- 同步 IoC、证书信任规则,补充内核静态策略。
三、四层核心底层校验逻辑(IO 预拦截完整流程)
WriteFile、DeleteFile、RenameFile、SetEndOfFile 等修改类操作时,WdNisDrv 按顺序四层校验:步骤 1:判断目标路径是否属于受控文件夹
ProtectedFolders 列表:- 不在受控目录 → 直接放行,不做后续校验;
- 在受控目录 → 进入信任校验流程。
支持路径类型:
- 本地 NTFS 目录(桌面、文档、数据库目录);
- SMB 网络共享路径
\\server\share; - 集群 CSV 共享卷;
- OneDrive 本地同步目录。
步骤 2:校验发起操作的进程是否自动可信(云信誉基线)
- 微软 WHQL 签名、全球广泛分发的系统程序(explorer.exe、备份工具、Office);
- 云端信誉高分、无恶意标记的主流商业软件;
断网环境使用本地信誉缓存,避免批量误拦截。
步骤 3:匹配管理员手动信任规则(静态白名单)
- 程序绝对路径匹配
AllowedApplications; - 程序数字签发证书匹配
AllowedCertificateSigners; - IoC 哈希规则匹配(Defender XDR 批量哈希放行)。
步骤 4:模式分支处理(拦截 / 仅审计)
- 拦截模式(Enable=1)
四层校验全部不通过 → 内核直接终止 IO 操作,返回 Windows 错误码
ERROR_ACCESS_DENIED (0x5);同时写入安全事件日志:EventID 1127(CFA 操作被阻止)。 - 审核模式(Enable=2)
校验不通过不阻断 IO,仅记录 EventID 1124 审计日志,用于上线前基线调试、排查误拦截。
四、两种关键底层防护机制(对抗勒索病毒核心)
机制 1:内核前置阻断,权限无关性隔离
NT AUTHORITY\SYSTEM、SeTakeOwnershipPrivilege、内核提权权限,只要不在信任列表,写入受控目录依然被驱动拦截。
机制 2:全路径 IO 覆盖,网络共享同等防护
- 本地文件操作;
- SMB 远程共享读写;
- 集群 CSV 卷;
- 容器内挂载目录;
勒索病毒通过内网共享横向扩散加密服务器文件时,同样触发 CFA 拦截。
五、脚本 / 批量加密特殊拦截逻辑
- 脚本进程批量循环修改受控目录大量文件;
- 脚本直接调用加密 API、批量覆盖原文件;
满足行为特征时,即使基础路径未命中黑名单,也会触发临时拦截与告警。
六、策略防篡改底层保障(Tamper Protection 联动)
- 注册表 CFA 策略项添加内核 ACL 保护,普通管理员、勒索病毒无法删除 / 清空信任列表、关闭 CFA;
WdNisDrv.sys受 HVCI 代码完整性保护,无法被卸载、替换;- 服务
WinDefend启动类型固化,恶意程序无法终止防护驱动。
七、完整时序示例(勒索病毒加密文档)
- 勒索病毒进程调用
CreateFileW打开C:\Users\Admin\Documents\report.docx,意图覆写加密; - NtCreateFile 进入内核,触发 FltMgr 预操作回调;
- WdNisDrv 匹配路径:文档目录属于受控文件夹;
- 校验勒索程序哈希、证书,无自动 / 手动信任匹配;
- 当前为拦截模式,内核返回拒绝访问,IO 操作失败;
- 写入事件日志 1127,同步告警至 Defender for Endpoint/XDR 云端;
- 病毒无法获取文件写入句柄,加密流程直接中断。
八、底层性能优化设计
- 策略全部缓存在内核内存,无需用户态交互,单次 IO 校验耗时微秒级;
- 白名单 / 受控目录使用哈希快速匹配,非线性遍历;
- 不在受控目录的 IO 直接跳过全部校验,无性能开销;
- 读写大文件、备份程序等可信进程提前缓存标记,重复访问免重复校验。
九、底层核心安全优势总结
- 权限无关防护:不受管理员、SYSTEM、内核提权权限绕过;
- 内核前置拦截:文件写入磁盘前阻断,不存在加密文件落地风险;
- 全域文件覆盖:本地、SMB 共享、集群、容器统一管控;
- 软硬件纵深联动:可搭配 VBS/HVCI、篡改防护形成完整勒索防御链;
- 行为驱动而非特征码:新型无样本 0day 勒索病毒同样可拦截,无特征滞后缺陷。
受控文件夹访问(Controlled Folder Access,CFA) 是 Windows 系统中的一项安全功能,旨在保护重要文件夹免受恶意软件的攻击,尤其是针对勒索软件。CFA 通过限制应用程序对特定文件夹的访问权限,防止未授权的应用程序和恶意软件篡改或加密用户文件。以下是 CFA 在 Windows 中的发展时间线:
1. Windows 10 Creators Update(2017年4月发布)
- 首次引入 CFA:
- CFA 功能首次在 Windows 10 Creators Update 中正式引入。此版本的 Windows 10 专注于提升用户的安全性,并特别增强了对勒索软件等恶意软件的防护能力。
- CFA 的基本功能:CFA 允许用户指定一些关键的文件夹(如文档、桌面、图片等)作为受保护文件夹,并限制对这些文件夹的访问。只有经过用户批准的应用程序才能对这些文件夹中的文件进行修改,其他应用程序无法访问或更改这些文件。
- 主要保护目标:主要针对勒索软件和其他类型的恶意软件,防止它们加密或破坏重要文件。
2. Windows 10 Fall Creators Update(2017年10月发布)
- CFA 增强和默认启用:
- 在 Windows 10 Fall Creators Update 中,CFA 进行了增强,尤其是在用户体验和功能配置方面的改进。Windows 10 Fall Creators Update 中,CFA 变得更加直观,用户可以更方便地启用和配置受控文件夹访问功能。
- 这时,CFA 默认不启用,但可以手动开启,允许用户选择性地保护文件夹。
3. Windows 10 April 2018 Update(2018年4月发布)
- CFA 完全启用及集成:
- Windows 10 April 2018 Update 中,CFA 功能得到了进一步的完善和集成,提供了更多的用户控制选项。此版本中,用户可以更轻松地查看和管理哪些应用程序被允许访问受控文件夹。
- 该版本还引入了更高效的警报机制,当恶意软件尝试修改受保护文件夹中的文件时,用户会收到警告。
- 兼容性增强:微软加强了与第三方防病毒软件的兼容性,确保其他安全软件不会与 CFA 发生冲突。
4. Windows 10 1903(2019年发布)
- 更细致的控制和管理:
- 在 Windows 10 1903 中,CFA 进一步增强了对文件夹保护范围和权限控制的精细管理。用户可以通过 Windows 安全 中的 "病毒和威胁防护" 设置页面管理受控文件夹访问功能。
- 新增的通知和日志功能:当应用程序尝试修改受保护的文件夹时,系统会向用户发送详细的警告通知,并且提供日志记录功能,帮助用户了解哪些应用程序被阻止访问文件。
5. Windows 10 1909(2019年发布)
- 进一步提升了勒索软件防护功能:
- Windows 10 1909 增强了 CFA 在勒索软件防护方面的功能,尤其是在识别和阻止勒索软件变种的能力上。微软进一步优化了 CFA 的性能,减少了误报,确保只有真正的恶意软件才会被阻止访问受保护的文件夹。
- 改进的用户界面:此版本对 CFA 的界面进行了优化,使得普通用户也能轻松理解和配置安全设置,增强了用户体验。
6. Windows 10 2004(2020年发布)
- 强化的功能和改进的兼容性:
- 在 Windows 10 2004 版本中,CFA 进一步集成了 Windows Defender 和其他安全技术,增强了整体的防护效果。此版本通过与 虚拟化基础设施保护(VBS)和 硬件安全技术 的整合,使得勒索软件和恶意程序更难绕过系统保护。
- 改进的事件日志和警报:微软加强了受控文件夹访问的警报和日志记录功能,帮助用户更加精确地追踪对文件夹的访问请求,提升了安全性。
7. Windows 10 21H1(2021年发布)
- 优化和集成:
- Windows 10 21H1 版本中,CFA 继续优化,并与系统中的其他安全特性(如 Core Isolation 和 Memory Integrity)更好地集成。
- 该版本中的 CFA 功能继续增强防止勒索软件和其他恶意软件篡改重要文件的能力,尤其是在企业环境中,管理员可以更精细地控制哪些文件夹需要保护。
- 该版本加强了 Windows Security 中的受控文件夹访问管理界面,提供了更多的自定义选项,允许企业用户更好地配置和管理文件夹保护。
8. Windows 11(2021年发布)
- CFA 成为增强型防护的一部分:
- 在 Windows 11 中,CFA 功能得到了进一步的改进和加强。与 Windows 10 相比,Windows 11 将 CFA 与操作系统的其他安全功能(如 Windows Defender 和 BitLocker)进行了更加紧密的集成,提升了整体的文件夹保护能力。
- 默认启用:在 Windows 11 中,CFA 功能被更多地集成到默认的安全设置中,进一步增强了操作系统在保护用户文件方面的能力,尤其是通过与 硬件虚拟化 和 TPM 2.0 等硬件安全技术的结合。
- 用户界面改进:用户可以通过 Windows 安全 应用更方便地启用或禁用 CFA 功能,进一步提升了用户体验。
9. Windows 11 22H2(2022年发布)
- 增强的勒索软件防护:
- 在 Windows 11 22H2 中,CFA 被进一步强化,尤其是在面对新型勒索软件和复杂攻击时的防护能力。此版本加强了对勒索软件的检测和阻止,确保即使是更先进的恶意软件也难以绕过保护。
- 该版本还增加了对现代硬件架构和高级安全特性的支持,使得受控文件夹访问在各类设备上的表现更加一致。
受控文件夹访问(CFA) 从 Windows 10 Creators Update 开始引入,并随着每个版本的更新逐步增强。特别是在防护勒索软件和恶意软件方面,CFA 为 Windows 用户提供了重要的保护。随着时间的推移,CFA 的功能越来越强大,集成了更多的安全特性,并逐步向用户和企业提供更加便捷的配置和管理工具。
2. 受控文件夹访问(CFA,Controlled Folder Access)
受控文件夹访问是一项Windows Defender的安全功能,用于防止恶意软件访问和修改指定的文件夹中的文件。启用此功能后,Windows会限制未经授权的程序访问某些重要文件夹,只有受信任的应用程序才有权限访问这些文件夹。
CFA的工作原理:
- 用户可以定义受保护的文件夹,系统会将其标记为“受控文件夹”。
- 只有系统信任的应用程序才能在这些受控文件夹中进行写入操作。
- 如果恶意程序试图篡改这些文件夹中的文件,CFA 会阻止并报告这一行为。
启用CFA的好处:
- 防止勒索病毒等恶意软件篡改重要文件,如文档、图片和系统文件。
- 用户可以指定哪些文件夹需要保护,从而减少数据丢失的风险。
- 提供额外的安全层次,帮助保护用户文件和应用程序数据。
- 内核完整性保护(HVCI) 是通过虚拟化技术保护操作系统内核免受恶意软件的攻击,增强系统的安全性。
- 受控文件夹访问(CFA) 则专注于防止恶意程序篡改用户的重要文件或数据,确保数据的完整性和安全性。
启用这两项功能可以显著增强系统的安全性,减少来自恶意软件、病毒和勒索软件等威胁的风险。
内核完整性保护(HVCI,Hypervisor-Enforced Code Integrity)是 Windows 操作系统中用于增强系统安全性的功能,它依赖于硬件虚拟化技术,通过隔离和验证内核代码的完整性来防止恶意软件攻击。HVCI 的底层原理涉及操作系统的内核、虚拟化技术、硬件支持和代码完整性验证。下面将详细讲解其工作原理和底层实现:
1. 虚拟化技术的支持
HVCI 依赖硬件虚拟化技术来增强操作系统的安全性。虚拟化技术通过创建一个虚拟机监控器(Hypervisor)来控制和管理操作系统与硬件的交互。具体来说,HVCI 使用的虚拟化技术基于以下几个核心组件:
- 虚拟机监控器(Hypervisor):这是一个运行在操作系统之上但在硬件与操作系统之间的低级别软件层。Hypervisor 可以创建多个虚拟机并隔离它们,使得恶意代码即使在虚拟机内运行,也不能直接影响操作系统的核心部分。
- 硬件支持的虚拟化(如 Intel VT-x 和 AMD-V):这些硬件功能使得 Hypervisor 能够高效地管理系统资源,并为 HVCI 提供所需的隔离性和控制能力。
2. 代码完整性验证
HVCI 的核心功能是通过虚拟化保护来验证并确保内核代码的完整性。具体来说,HVCI 会将内核模式代码的加载和执行过程与操作系统的其他部分进行隔离,确保没有恶意软件能够修改或篡改内核代码。
- 代码签名验证:HVCI 会检查加载到内核中的驱动程序和模块是否有有效的签名。如果某个驱动程序或模块没有有效签名或者签名不符合要求,它将被阻止加载,从而避免恶意软件通过加载伪造的驱动程序来感染系统。
- 强制执行内核模式代码的完整性:HVCI 强制要求所有内核模式代码都必须通过 Hypervisor 层进行完整性检查。只有通过验证的代码才能运行,这样可以防止恶意代码注入到内核空间。
3. 虚拟化隔离内核执行
HVCI 通过虚拟化技术将内核模式代码的执行与其他应用程序的执行进行隔离。具体来说,当 HVCI 启用时,操作系统内核会在一个受保护的环境中执行,该环境由虚拟机监控器控制,从而阻止恶意程序直接访问或修改内核内存。
- 隔离执行环境:在启用 HVCI 的情况下,内核代码和数据会在一个虚拟化保护的环境中运行,这样即使恶意程序获得了系统级权限,也无法直接干预内核的执行。
- 内核内存保护:HVCI 会通过虚拟化隔离内核的内存区域,防止恶意代码通过直接修改内存或使用漏洞进行内核模式攻击。
4. 硬件加速的保护
HVCI 依赖硬件虚拟化技术(如 Intel VT-x 和 AMD-V)来提供更高效的保护。虚拟化硬件能够提供比传统软件解决方案更强大的隔离能力,确保内核完整性验证过程不会受到破坏。
- 硬件级别的安全性:虚拟化硬件提供的隔离能力比纯软件实现更强大,可以在硬件层面进行内存管理和执行控制,从而进一步增强内核完整性的保护。
- 性能优化:通过硬件虚拟化技术,HVCI 在提供高安全性的同时,不会显著影响系统性能,因为硬件虚拟化能够高效地管理资源分配和隔离任务。
5. 攻击防范机制
HVCI 可以防止多种类型的攻击,尤其是那些依赖于内核漏洞或恶意代码执行的攻击。常见的攻击方式包括:
- 驱动程序漏洞利用:恶意软件可能会通过利用驱动程序中的漏洞来执行恶意代码。HVCI 通过验证和签名要求,防止了未经授权的驱动程序加载,从而减小了此类攻击的风险。
- 内核模式代码注入:许多恶意程序通过注入内核模式代码来获得更高的权限,甚至完全控制系统。HVCI 通过虚拟化隔离和代码验证机制,阻止了这些恶意程序的执行。
内核完整性保护(HVCI)通过硬件虚拟化技术提供了一层额外的安全防护,确保系统内核的完整性不被恶意软件篡改。它的底层原理基于虚拟机监控器的控制与隔离能力,通过验证内核代码的签名、隔离内核执行环境、硬件加速的保护等多重措施,防止了多种内核级别的攻击。这种技术显著提高了系统的安全性,特别是在抵御恶意软件和攻击时。
内核完整性保护(HVCI,Hypervisor-Enforced Code Integrity)依赖于操作系统中的多个文件、驱动程序以及配置文件,这些文件和组件共同作用来确保内核代码的完整性和安全性。以下是一些与 HVCI 相关的关键文件和组件:
1. 驱动程序和模块文件
HVCI 的核心功能之一是验证加载到内核中的驱动程序和模块的完整性。这些驱动程序和模块通常会位于以下路径:
- C:\Windows\System32\drivers:存放系统驱动程序的文件夹。HVCI 会验证此文件夹中的驱动程序和内核模块的签名,以确保它们没有被篡改或注入恶意代码。
2. 内核模式代码的完整性验证文件
- C:\Windows\System32\ntoskrnl.exe:操作系统的内核文件,HVCI 会确保该文件未被修改,并且来自合法的签名源。
- C:\Windows\System32\bootcat.cache:启动时的内核加载信息文件,包含操作系统内核模块和驱动程序的元数据。
3. 代码完整性和配置文件
HVCI 依赖于一些与内核模式代码完整性验证相关的配置文件。这些配置文件指示操作系统何时启用或禁用 HVCI 功能:
- C:\Windows\System32\GroupPolicy:存储组策略设置的文件夹。管理员可以通过组策略启用或禁用 HVCI 功能,从而控制操作系统对内核代码的完整性保护。与 HVCI 相关的策略可能会在此文件夹中。
- C:\Windows\System32\drivers\codeintegrity.sys:这是一个内核模式的驱动程序,负责实现代码完整性检查。它是 HVCI 功能的核心组成部分之一,确保所有内核加载的驱动程序和模块符合完整性检查。
4. 硬件虚拟化支持的文件
由于 HVCI 依赖于硬件虚拟化技术(如 Intel VT-x 和 AMD-V),操作系统会与这些硬件特性进行交互:
- C:\Windows\System32\hyperv.dll:Hyper-V 相关的 DLL 文件,用于管理虚拟化技术。HVCI 需要与 Hyper-V 协同工作来提供内核级保护。
5. Windows 注册表配置
HVCI 相关的某些功能可能通过 Windows 注册表进行配置,特别是针对驱动程序签名和内核模式代码完整性检查。与 HVCI 配置相关的注册表键值可能包括:
- **HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CI**:此注册表路径下的配置项涉及代码完整性(Code Integrity)相关的设置。
- HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\HypervisorEnforcedCodeIntegrity:这个注册表项用于控制是否启用 HVCI 功能。
6. 组策略文件
通过组策略,管理员可以启用或禁用 HVCI。具体的组策略文件配置可能存储在:
- C:\Windows\System32\GroupPolicy:存放与 HVCI 和其他安全功能相关的组策略配置文件。
7. 系统日志和事件日志
系统日志文件记录了与 HVCI 相关的事件,例如驱动程序加载失败、代码完整性检查失败等。相关日志文件可以在以下路径找到:
- C:\Windows\System32\winevt\Logs\Security.evtx:包含操作系统安全相关事件的日志文件,记录了包括 HVCI 相关的事件。
- C:\Windows\System32\winevt\Logs\Application.evtx:包含应用程序事件的日志文件,可能记录了与代码完整性验证相关的信息。
HVCI 依赖于操作系统中的多个文件和组件,包括驱动程序文件、内核模块、配置文件、注册表设置和硬件支持文件。它通过对内核代码的严格验证,确保操作系统的安全性,防止恶意软件在内核模式下执行。
受控文件夹访问(Controlled Folder Access,简称 CFA)是 Windows 操作系统中的一项安全功能,旨在保护用户文件免受勒索软件和其他恶意软件的攻击。该功能通过限制对特定文件夹的访问,只有受信任的应用程序和进程可以访问这些文件夹,从而减少了恶意软件篡改文件的机会。CFA 是 Windows Defender 安全中心的一部分,并且与 Windows 10 和 Windows Server 2016 及更高版本兼容。
受控文件夹访问的底层原理
-
文件夹保护机制 受控文件夹访问通过保护特定的文件夹来防止未经授权的程序访问这些文件夹。默认情况下,Windows 会保护一些关键的文件夹,例如“文档”、“图片”、“视频”等用户文件夹。管理员可以通过设置来添加额外的文件夹保护。被保护的文件夹会受到严格的文件操作控制,只有符合条件的程序才能访问这些文件夹。
-
基于进程的访问控制 CFA 采用了一种基于进程的访问控制机制,只有经过 Windows Defender 签名认证的可信应用程序能够访问受保护文件夹中的文件。当文件访问请求被发起时,操作系统会检查请求发起进程是否符合白名单中的要求。未被允许的应用程序(通常是恶意软件)将被拒绝访问。
-
动态行为分析与监控 受控文件夹访问不仅仅是通过静态白名单来允许应用程序访问文件夹,它还依赖于 Windows Defender 的动态行为监控。通过监控进程的行为,操作系统能够检测到异常行为并做出响应。如果某个进程试图对受保护文件夹中的文件进行修改,而该进程不在受信任应用列表中,系统会立即阻止此操作并触发警报。这个过程依赖于:
- 实时防护:实时监控进程活动,确保文件夹中的文件不会被恶意软件修改。
- 行为检测:监控进程的行为模式,尤其是针对勒索软件等恶意程序的典型行为,如加密大量文件。
-
基于文件操作的拦截 CFA 会拦截对受保护文件夹的以下文件操作:
- 文件创建:恶意进程不能随意在受保护的文件夹中创建文件。
- 文件修改:勒索软件通常会加密文件,CFA 会阻止这种未授权的修改行为。
- 文件删除:只有受信任的进程才能删除受保护文件夹中的文件。
-
使用文件系统过滤驱动程序 CFA 的核心是 Windows 文件系统过滤驱动程序(File System Filter Driver)。该驱动程序在内核模式下工作,拦截所有文件操作请求。它会验证每个文件操作请求的源进程是否合法,并根据受控文件夹访问的配置策略进行授权或拒绝。如果进程未获得许可访问目标文件夹,驱动程序将拒绝该文件操作,并将事件记录到系统日志中。
-
白名单机制 受控文件夹访问使用白名单机制来管理可信应用程序的列表。Windows Defender 会定期更新并维护这个白名单,包含被认为是可信的应用程序(例如,Microsoft Office、常见的浏览器等)。此外,管理员可以手动添加或移除特定应用程序。只有白名单中的应用程序才能对受保护文件夹中的文件进行合法操作。
-
日志和告警机制 CFA 通过 Windows 事件日志记录所有的文件访问操作,特别是被拒绝的访问尝试。这些日志对于管理员来说是非常重要的,可以用于后续的分析和安全事件响应。此外,CFA 还可以配合其他安全产品发出告警,以便及时发现潜在的恶意活动。
受控文件夹访问的工作流程
-
启用受控文件夹访问:管理员通过 Windows Defender 安全中心或组策略启用受控文件夹访问功能,并指定哪些文件夹需要受到保护。
-
文件访问请求:当某个应用程序或进程请求对受保护文件夹中的文件进行操作时,Windows 文件系统过滤驱动程序会拦截该请求。
-
验证进程:操作系统会检查请求的进程是否在白名单中,或者是否符合防护规则。如果进程未被授权访问,则该操作被拒绝。
-
记录事件:所有被拒绝的文件操作会被记录到系统日志中,管理员可以随时查看这些事件。
-
实时保护:如果进程的行为符合勒索软件的特征(如大量文件的加密或删除),Windows Defender 会实时监控并采取措施进行防御。
受控文件夹访问是 Windows 中的一项非常有效的安全功能,它通过对特定文件夹的访问进行严格的控制和监视,有效地阻止了勒索软件等恶意软件篡改、加密或删除用户数据。其底层机制依赖于文件系统过滤、进程行为监控、白名单机制和动态防护分析。通过这些手段,CFA 提供了一层额外的保护,以提高用户数据的安全性。
受控文件夹访问(CFA)是 Windows 操作系统中的一项安全功能,其核心依赖于文件系统过滤驱动程序以及 Windows Defender 安全服务。为了实现文件保护,CFA 涉及多个文件和组件。下面是一些与受控文件夹访问相关的关键文件和组件:
1. Windows Defender 相关文件
- Msmpeng.exe:这是 Windows Defender 的核心进程,负责病毒和恶意软件扫描。CFA 功能由 Windows Defender 提供支持,因此它依赖于该进程来进行文件保护。
- Wdboot.sys:这是一种驱动程序,负责在系统启动时加载 Windows Defender。
- Wdfilter.sys:这是一个重要的过滤驱动程序,支持 Windows Defender 在文件系统层面拦截恶意行为。它在 CFA 中起到了文件访问控制和安全监控的作用。
- DefenderUI.exe:这是 Windows Defender 的用户界面,用于设置和管理安全选项,包括启用或禁用受控文件夹访问功能。
2. 文件系统过滤驱动程序(File System Filter Driver)
受控文件夹访问通过文件系统过滤驱动程序来拦截对受保护文件夹的所有文件操作请求。以下是关键的驱动文件:
- Cfw.sys:这是负责受控文件夹访问功能的过滤驱动程序,它监控文件系统中的文件操作。该驱动程序会根据文件的访问请求,决定是否允许该操作。Cfw.sys 是实现文件夹保护、拦截恶意进程的关键组件。
3. 注册表配置文件
受控文件夹访问的配置和管理依赖于注册表。通过编辑注册表,管理员可以配置受保护的文件夹以及其他相关的设置。
- **HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender**:这是 Windows Defender 设置的主注册表路径,其中包含受控文件夹访问相关的键值。
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Controlled Folder Access:这里存储着受控文件夹访问的具体配置信息,包括受保护的文件夹路径、白名单应用程序、文件操作日志等。
4. 事件日志文件
- Windows 事件日志:受控文件夹访问会记录所有文件访问请求,特别是被拒绝的操作。日志文件位于 事件查看器 中,可以用于查看受保护文件夹的访问情况和潜在的恶意行为。
5. 安全中心组件
- SecurityHealthService.exe:这是 Windows 安全中心的服务进程,负责处理和管理与系统安全性相关的任务,包括受控文件夹访问的启用或禁用。
- Windows Defender 安全中心:Windows Defender 安全中心提供一个用户界面,可以用来启用、配置和管理受控文件夹访问。
6. 组策略文件(如果启用)
如果管理员通过组策略启用受控文件夹访问,以下的组策略文件和设置会影响到 CFA 的行为:
- gpedit.msc:这是用于配置 Windows 组策略的工具。通过它,管理员可以设置受控文件夹访问的启用状态、保护的文件夹和受信任的应用程序。
7. 系统日志文件
- Windows 日志文件:操作系统通过日志文件记录各种事件,包括 CFA 操作。如果某个进程被拒绝访问受保护文件夹的文件,系统会将事件记录在日志文件中,通常是 应用程序和服务日志 中的 Microsoft/Windows/Defender 目录。
受控文件夹访问(CFA)功能依赖多个关键的系统文件、驱动程序、注册表配置文件和日志文件。这些文件和组件共同工作,以保护用户的数据免受勒索软件和恶意软件的侵害。关键的文件包括 Windows Defender 的核心进程和驱动程序(如 Wdfilter.sys 和 Cfw.sys),事件日志文件,以及相关的注册表项和组策略设置。

浙公网安备 33010602011771号