2026-09-24 05:33:48 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 微软在Windows11预览版中发布wesp终端安全平台，将内核采集与执行能力收归操作系统，安全厂商检测逻辑留在用户态。wesp.sys提供46类事件采集、规则匹配及响应处置能力，通过espclient.dll供厂商下发规则。该架构降低内核稳定性风险，但存在扩展受限、复杂阻断能力不足、缺乏事后处置等问题，安全厂商需规划能力迁移。 综合评分： 88 文章分类： 安全建设,安全工具,安全运营,终端安全,安全开发

内核的退与守：微软 WESP 如何重划终端安全边界

腾讯科恩实验室

2026年9月23日 09:00 上海

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

2026 年 9 月，微软在 Windows 11 Insider Preview 中发布了 WESP（Windows Endpoint Security Platform，Windows 终端安全平台）的第一个可验证实现。这套框架将终端安全产品的内核执行能力收归操作系统，厂商的检测与响应逻辑留在用户态，内核侧由微软统一提供的 wesp.sys 提供事件的捕获能力、规则的解析匹配能力，以及一定程度的响应处置能力。本文将从安全研究人员的视角分析WESP 的技术细节，探讨其对终端安全产品的影响。

从蓝屏之夜到 WESP：一条二十年的演变线

过去二十年，安全厂商依托微软提供的内核回调和 Minifilter 构建防御能力，可自由地在内核中实现复杂的检测与阻断逻辑。然而2024 年 7 月 19 日 CrowdStrike 大规模蓝屏事件暴露了这一模式存在的风险，推动微软加快安全能力向用户态迁移：从同年 11 月宣布 WRI，到 2025 年 6 月公开介绍 WESP，再到 2026 年 9 月预览组件出现，逐步形成由平台承接内核采集与执行、厂商在用户态实现复杂安全逻辑的新架构即WESP。

WESP 技术细节

整体架构

WESP 由内核驱动 wesp.sys 和用户态客户端库 espclient.dll 组成：前者提供事件采集、规则匹配、事件投递及处置能力；后者面向第三方安全厂商，提供客户端注册、规则构造与下发、事件接收等接口。厂商通过 espclient.dll 将检测规则下发至内核，由 wesp.sys 完成匹配与响应处置。

驱动层：采集、匹配与处置

采集能力：46 类事件

当前驱动共定义 46个事件类型，具体采集范围如下。

规则匹配：从事件产生到命中规则

内核事件从回调产生到命中规则，需要经过事件订阅判断、事件对象初始化、事件对象分发和规则匹配四个环节。以下以进程创建事件为例，展示其在 wesp.sys 中的数据流：

用户态&nbsp;CreateProcessW →&nbsp;NtCreateUserProcess

│

▼

进程创建回调

ps::create_process_notify(Process,&nbsp;ProcessId,&nbsp;CreateInfo)

│

▼

① 事件订阅判断

进程创建订阅计数与计数更新保护状态均为零 → 跳过后续处理

跳过时不修改&nbsp;CreateInfo->CreationStatus

│

▼

② 事件对象初始化

记录当前执行上下文，构造&nbsp;ProcessCreate&nbsp;事件

│

▼

③ 事件对象分发（在规则引擎内部完成）

获取客户端集合快照，按客户端选取&nbsp;ProcessCreate&nbsp;规则集

│

▼

④ 规则匹配

RuleEngine::process_event<ProcessCreate>分组匹配

命中后按规则配置执行相关动作

响应处置：规则命中后的执行流程

在WESP中，安全厂商可以通过规则配置三类处理动作：上下文维护（ContextKeyUpdates）用于更新厂商自定义的上下文信息；事件状态修改（EventModify）用于调整访问权限等操作参数；规则动作（Action）用于指定阻断、通知及后续匹配流程。当规则命中后，wesp.sys 依次执行ContextKeyUpdates、EventModify、Action相关动作，需要注意的是Action类处理动作存在一定的约束要求，即每种类型的事件只能设置一定范围的Action动作，例如模块加载事件无法设置block动作。

ContextKeyUpdates

ContextKey 是用于维护厂商自定义上下文信息的键值对，如文件标签、规则命中次数等。安全厂商通过 ESP_CONTEXT_KEY_UPDATE 描述要更新的键值对，接着更新相关Rule，最后调用 espclient.dll 的 EspCreateRule``EspUpdateRules 创建下发规则。规则命中后由内核执行更新上下文信息。其典型使用场景是多事件关联告警，以一个典型的可疑进程访问敏感文件的场景为例：厂商创建并下发两条规则，第一条在进程满足可疑条件时更新该进程的 ContextKey，打上可疑标签；第二条针对文件访问事件，判断请求进程是否带有该标签、目标是否为敏感文件，命中后执行 Action.Notify，由用户态服务生成告警，两条规则通过进程上的 ContextKey 关联前后行为。

EventModify

EventModify 用于指定当规则命中后对事件参数的修改动作，当前事件参数主要为DesiredAccess。例如进程访问事件发生时，可以通过EventModify 删除DesiredAccess中的PROCESS_VM_WRITE 权限，使调用方无法通过该句柄执行相应操作。安全厂商通过 ESP_EVENT_MODIFY指定事件修改类型及对应的参数信息，更新相关Rule后通过EspCreateRule``EspUpdateRules 更新下发规则。其典型使用场景是关键模块的自保能力，通过权限访问控制实现产品核心进程、核心模块不受影响。

Action

Action 用于指定规则命中后的响应处置动作，包括：Block、Allow、Notify、NoNotify、Ignore、Match Subrules、NotifyOnCompletion等。安全厂商通过 ESP_RULE_DESCRIPTOR.Action 设置相关处置动作，最后调用 espclient.dll 的 EspCreateRule``EspUpdateRules 创建下发规则。下面以Notify``Block``Match Subrules这3个检测与响应场景的核心动作为例说明相关使用场景：

Notify 用于将命中事件异步投递给用户态，供安全厂商进一步关联分析。

Block 用于事件同步阻断操作，其使用场景限于部分动作的事前阻止，无法满足事后处置的需求。

Match Subrules 用于同一事件内的多层递进判断逻辑，父规则命中后才匹配子规则，例如文件写入时，父规则先判断请求进程是否可疑，子规则再根据目标文件类型选择 Block 或 Notify。

用户态：建立通信与下发规则

安全厂商通过 espclient.dll 提供的接口完成客户端注册、连接、事件队列配置及规则构造与下发，从而获取wesp.sys 提供的事件采集、规则匹配与响应处置能力。

连接：客户端调用 EspConnectClient后，驱动为该客户端分配运行时上下文，并确定它的能力层级。此后的所有操作都在这个会话上进行，会话断开时驱动会清理相关上下文。

建立事件队列：客户端调用 EspCreateEventQueue 创建队列，规则命中后产生事件投递至相关队列。

构造规则：客户端调用 EspCreateRule 结合命中条件、响应动作等信息创建规则对象。

下发规则：客户端调用EspUpdateRules 将规则投递至内核。

退出：客户端调用EspDisconnectClient 结束会话。

整个通信流程其数据流转如下：

WESP 的访问控制

WESP在建立连接的过程中存在一套访问控制机制：ConnectPort 是wesp.sys接收用户进程连接的入口。用户进程调用 FilterConnectCommunicationPort连接 \EspFilterPort 时，需要在连接参数 Context 中说明想建立哪一种会话。驱动完成端口权限、测试签名状态、连接参数和调用进程身份校验后，才会执行注册客户端、注销客户端、连接控制会话或绑定队列等操作。端口 ACL 只允许 SYSTEM 或具有有效管理员权限的进程进入连接回调。最多同时存在 512 个连接，六种连接类型共用这个上限。Context 开头的 Kind 决定连接的类型以及用途。不同 Kind 后面携带的字段也不同。具体见下表：

驱动还会检查各 Kind 所需参数是否完整，例如 GUID、字符串范围、目标客户端或队列是否存在，以及当前对象状态是否允许执行该操作。

除 Kind 5 外，其余连接都会读取当前进程主令牌中的 WESP://Permission：

当前预览版在开启 Test Signing 时，允许调用进程没有 WESP://Permission 仍完成连接。这可能是微软为了方便在测试环境中开发调试而留下来的。整个访问控制的流程如下：

WESP 的能力边界

WESP 将事件采集、规则匹配、状态维护及响应阻断能力整合为统一的平台接口，使安全厂商能专注于检测逻辑的运营，减少自建内核组件的开发维护负担，并降低第三方复杂逻辑在内核执行带来的稳定性风险，但当前WESP所提供的安全能力依旧存在不少值得商榷的问题：

采集与执行能力的扩展受平台约束：事件类型、事件参数、响应动作均由 WESP 定义，当现有能力接口无法满足安全需求或出现新威胁场景，安全厂商无法快速补齐相关安全能力，只能被动依赖平台更新，这将严重制约安全厂商应对新型&复杂威胁场景的能力。

复杂交互场景的同步阻断能力受限：当前 WESP 的阻断依据来自预先下发的内核规则，适合基于已有属性和上下文状态进行判断，难以覆盖需要复杂交互的检测流程。例如，主防场景中常见的内存扫描阻断策略：要求在进程创建阶段用户态引擎扫描目标进程内存，再根据结果决定是否阻断。

缺乏事后处置能力：当前WESP提供的响应能力 Block 和 EventModify均为事件发生前的阻断类动作，缺乏事件发生后的处置类能力，如结束进程、删除文件等。

兼容性与运行可靠性更依赖平台，在WESP体系中，安全厂商处于能力消费者的角色，如何保障安全能力高效、稳定的提供，其主动权将交由操作系统，这种新的供需模式当前可能无法满足传统的业务需求。

上述视角我们纵向对比了 WESP 与传统终端安全产品相比存在的能力边界，横向对比macOS ES机制当前WESP也有所缺失：ES依托AUTH机制能满足更为复杂的阻断场景需求，更为重要的是macOS较为严格的应用准入与运行时校验机制使得两个平台安全厂商所面临的安全场景是有着较大区别的，总体而言，WESP距离成为一套成熟的安全能力提供框架依旧还有一段路要走。

终端安全厂商将行至何方

结合前文信息，我们可以预见的是在相当长的一段时间内，安全厂商原有安全能力框架和WESP将会处于共存状态，在这种情形下，紧跟WESP能力演变、根据业务场景梳理安全能力需求、依据需求建立能力迁移清单、构建统一的数据语义及规则语义将成为下一阶段终端安全厂商需要逐个解决的问题。

参考

[1] Windows Endpoint Security Platform (WESP) preview analysis – xusheng6/windows-wesp-research

[2] A First Look Inside the Windows Endpoint Security Platform – jonny-jhnson.dev

[3] Windows Resiliency Initiative – Microsoft

[4] Preparing for what’s next: Windows security and resiliency innovations – Windows Experience Blog (2025-11)

[5] The Windows Resiliency Initiative: Building resilience for a future-ready enterprise – Windows Experience Blog (2025-06))

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：腾讯科恩实验室《内核的退与守：微软 WESP 如何重划终端安全边界》