边界重划之后：WESP 如何重构终端遥测与阻断

长期以来，Windows 终端安全产品依赖自研内核驱动挂载系统回调、过滤文件与注册表操作，在内核中直接完成数据采集与行为阻断。WESP 正在改变这一格局：微软在内核中内置统一的平台驱动 wesp.sys，配合用户态客户端接口 espclient.dll，将原本由各家安全驱动自行实现的事件采集、条件过滤与同步阻断收拢为标准化的系统原语。上一篇《内核的退与守：微软 WESP 如何重划终端安全边界》讨论了这一架构演进带来的职责重划，Windows 承接通用的内核采集与执行能力，安全厂商将检测、关联分析和运营逻辑退回用户态。

而当核心逻辑回到用户态之后，安全产品面对的是一个更具体的工程问题：依靠 WESP 交付的原语，如何搭建起一套完整可用的终端安全框架？

为此我们基于 WESP 接口构建了一个示例客户端。通过规则下发与实际系统行为触发，可以看到 WESP 是如何依靠两个核心平面与一层状态机制协同运转的：数据面负责结构化的终端遥测采集，策略面由系统内核在操作路径上直接执行阻断（Block）与修改（EventModify），而中间的ContextKey则将跨事件的对象状态持久化在内核对象上，把两个平面串联成闭环：

基础底座：用同一套规则模型同时驱动采集与执行

WESP 一共提供了 46 类事件，其中 45 类发生在系统运行期间，BOOT_LOAD_DRIVER 发生在启动阶段。进程创建、注册表设值、文件访问和句柄创建本身都不是新的系统活动，WESP 真正核心的改变在于，安全产品可以用同一种规则模型去同时描述“采集什么遥测”和“执行什么控制”。

一条规则模型主要用于描述 5 个维度的特征：

当系统事件发生时，这 5 个特征在内核中按以下顺序起作用：

系统事件
  → 匹配事件类型、对象和条件
  → 命中规则
      ├─ 更新 ContextKey 或应用 EventModify
      ├─ 执行该事件支持的 Action，或进入子规则
      └─ 按配置组织属性并投递异步通知

无论是单纯订阅事件做遥测上报，还是在内核路径上拦截高危操作，底层运转的都是同一套匹配与执行管线。在这个底座之上，终端安全框架的能力自然展开为数据采集、状态关联与内核控制三个层次。

数据面：结构化的终端遥测采集

选取进程创建、注册表设值和句柄创建三类典型行为，足以看出 WESP 是如何组织终端遥测的：它向用户态交付的不再是扁平的日志字段，而是带有明确角色关系的对象集合。

进程创建：拿到一组对象关系，而非孤立 PID

传统的进程日志通常只保留映像路径、命令行和 PID。而在 WESP 的进程创建事件中，执行上下文、待创建进程、父进程、创建线程和映像文件被拆分为独立的角色槽位分别表达：

公共执行上下文：当前进程、当前线程
事件参数：      新进程、创建线程、映像文件、原始命令行
对象关系：      新进程 → 父进程
                创建线程 → 所属进程

在内核执行环境中，不同角色槽位可能指向同一个底层对象——例如发起操作的“当前进程”通常也是“创建线程”的所属进程。因此在构建检测模型时，必须保留每个槽位的角色含义，不能假定每个槽位都对应一个彼此独立的物理对象。

在示例客户端中，我们通过通知属性及后续对象查询，完整获取了新进程与父进程的 PID、创建时间和命令行，同时拿到创建线程的 TID、创建时间及所属进程信息，并采集到映像文件的规范化路径。以下是规则订阅与通知解析的核心代码示意：

// ── 1. 规则订阅：声明关注 PROCESS_CREATE 事件及返回属性 ──
ESP_RULE_DESCRIPTOR descriptor{};
descriptor.EventType = ESP_EVENT_TYPE_PROCESS_CREATE;
descriptor.Action    = ESP_RULE_ACTION_NOTIFY;
ESP_PROCESS_CREATE_CONFIG createConfig{};
// 新进程：请求返回 PID、命令行、映像路径
createConfig.ProcessConfig.EventObjectConfig
    .IncludeInNotification = TRUE;
createConfig.ProcessConfig.Properties =
    (ESP_PROCESS_PROPERTY_ID[]){
        ESP_PROCESS_PROPERTY_ID_PID,
        ESP_PROCESS_PROPERTY_ID_COMMAND_LINE,
        ESP_PROCESS_PROPERTY_ID_IMAGE_FILE_DOS_PATH
    };
// 父进程与映像文件：同步返回父进程信息及规范化 DOS 路径
createConfig.ProcessConfig.ParentProcessConfig =
    &parentConfig;
createConfig.FileObjectConfig.Properties =
    (ESP_FILE_OBJECT_PROPERTY_ID[]){
        ESP_FILE_OBJECT_PROPERTY_ID_NORMALIZED_DOS_PATH
    };
descriptor.RuleConfig.EventConfig.EventTypeConfig =
    &createConfig;
// 向 wesp.sys 内核注册规则
EspCreateRule(&descriptor, &rule);
// ── 2. 通知解析：从异步队列回调中逐角色提取对象 ──
void OnNotification(ESP_EVENT_NOTIFICATION_DATA_V1* data) {
    // 公共执行上下文：当前进程与当前线程
    UINT32 currentPid = data->CurrentProcess.ProcessId;
    UINT32 currentTid = data->CurrentThread.ThreadId;
    auto* params = (ESP_PROCESS_CREATE_PARAMETERS*)
        data->EventParameters;
    // 事件参数：新进程
    UINT32 newPid      = params->Process.ProcessId;
    // 对象关系：父进程
    UINT32 parentPid   = params->Process.ParentProcessId;
    // 事件参数：创建线程
    UINT32 creatingTid = params->CreatingThread.ThreadId;
    // params->FileObject → 提取映像文件的规范化 DOS 路径
}

安全产品在一次事件通知中拿到的是一组可以直接送入检测模型的关系图谱，而不是一个孤立的 PID。这种按角色拆分的设计也直接决定规则语义：按“待启动程序的路径”匹配时，条件应落在进程映像对应的文件对象上；若把相同条件写到“当前进程”配置中，实际约束的则是“谁发起了这次创建”。两种写法都能通过接口校验，但表达的是截然不同的安全规则。

注册表设值：一次通知带来变化前后

对于注册表监控，仅知道“某个键被改成了什么”往往不够，检测逻辑还需要知道它原本的值。在 REG_SET_VALUE_KEY 事件中，WESP 支持在一条通知里同时提供注册表键对象、值名称、旧数据和新数据，并允许过滤器直接检查旧值。

在示例客户端对字符串键值的修改测试中，单次通知直接带回了修改前后的对照：

Value Name: TestValue
Old Data:   WESP_SAMPLE_OLD_VALUE
New Data:   WESP_SAMPLE_NEW_VALUE

旧值与新值同批到达，意味着用户态引擎无需为了前后对比而在本地维护高成本的注册表基线快照，状态比对在事件到达时即可完成。

句柄创建：看清谁在向谁申请什么权限

跨进程操作通常始于句柄申请。WESP 的句柄创建事件可返回目标对象、当前 DesiredAccess、原始请求的 OriginalDesiredAccess 以及是否为内核句柄，请求方的进程与线程信息则由公共执行上下文一并提供。

在采集示例中，通知带回了目标进程对象以及两个均为 0x00001400 的访问掩码（因该规则仅做通知、未修改权限，当前掩码与原始掩码一致）。这组数据直接回答了访问控制的两个基础问题：谁在尝试访问目标进程，以及它申请了哪些操作能力。后文的细粒度权限削减，正是建立在这组对象与访问掩码之上。

状态桥接：ContextKey 把跨事件状态留在对象上

一次完整的攻击往往跨越多个系统事件。若完全依赖用户态用 PID、路径或时间窗口做跨事件关联，不仅容易受对象销毁和 PID 复用干扰，也很难把关联结论及时反馈给内核用于后续拦截。

为此，WESP 提供了 ContextKey 机制，允许客户端将自定义状态直接挂载到内核事件对象、单个事件实例或客户端自身之上。不同客户端使用隔离的命名空间，当前提供跟随连接会话的 CLIENT_SESSION 和跟随系统启动周期的 BOOT_SESSION 两种生命周期。

通过示例客户端，可以看到这套状态机制的两种典型工作方式：

第一种是由内核规则自动驱动的状态传递。我们在进程创建规则中向目标进程写入字符串标签，在进程退出规则中读取同一标签。进程退出通知成功带回了创建阶段写入的 WESP_SAMPLE_CONTEXT_VALUE，证明状态可跟随内核对象跨越从创建到退出的完整生命周期：

┌──────────────────────────────────────────────────────────────────┐
│                   跨事件 ContextKey 状态传递                      │
├──────────────────────────────────────────────────────────────────┤
│  ❶ PROCESS_CREATE 事件命中                                       │
│     规则动作: CONTINUE_MATCHING_NEXT_RULE                         │
│     ContextKey 更新: ContextKey(200) ← "WESP_SAMPLE_CONTEXT_VALUE"│
│     写入目标: 新进程 EPROCESS 关联上下文 (CREATE_OR_REPLACE)       │
│              ↓                                                   │
│     [ 进程运行期间，ContextKey(200) 持久挂载在内核对象上 ]          │
│              ↓                                                   │
│  ❷ PROCESS_TERMINATE 事件命中                                    │
│     规则通知属性包含 ContextKey(200)                               │
│     通知带回: "WESP_SAMPLE_CONTEXT_VALUE" ← 与创建阶段写入一致    │
└──────────────────────────────────────────────────────────────────┘

第二种是由用户态直接读写对象标签。示例客户端对运行中的进程和线程对象挂载了整数、字符串和二进制三类标签，随后将整数从 10 改为 15、删除字符串、并将二进制内容从 DE AD BE EF 替换为 BA AD F0 0D。再次查询时，整数和二进制值均已更新，已删除的字符串则返回预期的“键不存在”状态码（0xD0000225，即 STATUS_ESP_CONTEXT_KEY_NOT_FOUND）。核心 API 调用示意如下：

// ── 1. 获取目标进程的内核对象引用 ──
ESP_EVENT_OBJECT_REF processRef;
EspCreateProcessReference(client, targetPid, &processRef);
ESP_EVENT_OBJECT processObject;
EspGetEventObjectFromReference(processRef, &processObject);
// ── 2. 写入整数标签 ContextKey(1) = 10，并动态修改为 15 ──
ESP_CONTEXT_KEY_UPDATE update = {
    .ContextKey    = 1,
    .Lifetime      = ESP_CONTEXT_KEY_LIFETIME_CLIENT_SESSION,
    .UpdateType    = ESP_CONTEXT_KEY_UPDATE_TYPE_CREATE,
    .ValueType     = ESP_CONTEXT_KEY_VALUE_TYPE_INTEGER,
    .Value.Integer = 10
};
EspSetEventObjectContextKey(processObject, &update);
update.UpdateType    = ESP_CONTEXT_KEY_UPDATE_TYPE_MODIFY;
update.TransformType = ESP_NUMERICAL_TRANSFORM_TYPE_ADD;
update.Value.Integer = 5;
// 动态累加：10 + 5 = 15
EspSetEventObjectContextKey(processObject, &update);
// ── 3. 删除字符串标签 ContextKey(2) 并验证查询结果 ──
ESP_CONTEXT_KEY_UPDATE removeUpdate = {
    .ContextKey = 2,
    .UpdateType = ESP_CONTEXT_KEY_UPDATE_TYPE_REMOVE
};
EspSetEventObjectContextKey(processObject, &removeUpdate);
auto propertyId = ESP_PROCESS_PROPERTY_ID_CONTEXT_KEY(2);
EspQueryProcessProperties(
    processObject, 1, &propertyId, &properties);
// → 返回 HRESULT = 0xD0000225
//   (STATUS_ESP_CONTEXT_KEY_NOT_FOUND)

这两组能力构成了连接数据面与策略面的桥梁：用户态引擎完成复杂关联分析后，可将风险等级写入仍持有有效引用的进程对象 ContextKey；后续触发的文件、注册表或句柄规则直接检查对象身上的标签，就能在内核路径上做出通知或阻断决策。

策略面：Block 与 EventModify 在内核路径中执行决策

有了数据面的对象建模和 ContextKey 的状态支撑，策略面的任务就是把安全决策真正落实到系统操作的执行路径中。

Block：预置规则下的内核同步阻断

WESP 的阻断完全依据预先下发到内核的规则执行。系统操作发生时，wesp.sys 直接在内核路径中完成事件、对象和条件的匹配并当场执行动作；操作被拒绝后，事件通知才通过异步队列投递给用户态客户端。

厂商下发规则
      ↓
系统操作发生
      ↓
wesp.sys 匹配事件、对象和条件
      ↓
命中 Block → 操作当场返回拒绝；通知进入异步队列

在示例客户端的进程阻断验证中，我们下发了一条同时限定发起线程与目标进程命令行的规则，动作设为 Block，拒绝原因设为 ACCESS_DENIED。当目标程序被拉起时，CreateProcess 直接在调用处返回 Win32 错误 5（拒绝访问），目标进程未能启动，用户态随后收到了对应的阻断通知。

策略驻留：控制连接与事件队列断开后的持续防护

对于用户态安全客户端而言，进程升级、服务重启或意外断连是必须面对的工程场景。为此，WESP 为规则提供了 CLIENT_SESSION、BOOT_SESSION、PERSISTED 和 PERSISTED_EARLY_BOOT 四种生命周期，并为事件队列提供了前三种生命周期。

我们在示例客户端中验证了断连期间的策略驻留表现：下发进程阻断规则并确认生效后，主动销毁控制连接与事件队列连接；在重连前的空窗期内再次尝试启动目标程序，最后按原队列标识重连并读取通知：

在 BOOT_SESSION 和 PERSISTED 下，连接断开期间的启动操作依然被内核准确拒绝；客户端按原队列标识重连后，断连期间产生的阻断事件被完整收回且携带相同的 RuleId（测试结束后注销客户端并清理规则，通过 WespCtl 核对各生命周期的规则与队列计数均归零）。一旦策略下发为非会话级生命周期，内核中的阻断执行与事件缓存就不再依赖用户态连接的实时存活。

EventModify：细粒度的权限削减

一刀切的 Block 适合边界清晰的高危行为，但在核心进程自保护等场景下，往往需要更精细的控制：允许系统诊断工具打开进程查询基础信息，但剥离其写入内存的能力。

WESP 的 EventModify 机制支持通过 AccessToSet 和 AccessToClear 按位调整权限，且句柄创建事件在当前运行时中已明确报告支持 MODIFY 动作：

OriginalDesiredAccess
        ↓
规则请求设置（AccessToSet）或清除（AccessToClear）指定访问位
        ↓
生成削减后的 DesiredAccess 交付系统执行

依托这一结构，安全策略可以在不中断正常句柄创建调用的前提下，将请求掩码中的高危权限位直接抹除。需要指出的是，操作系统在将句柄请求送入 WESP 回调之前，会先根据调用方的安全上下文对请求权限做一次基础裁剪，WESP 的 EventModify 则在此基础上做二次修剪，这正是下文“核心进程自保护”场景的底层支点。

框架串联与安全厂商的能力重组

当数据面的结构化遥测、ContextKey 的跨事件状态，以及策略面的 Block 和 EventModify 全部就位后，安全产品就可以将这些原语组装成完整的防护闭环。

两个典型闭环场景

场景一：核心进程自保护（句柄遥测 + EventModify）

依托句柄创建事件的遥测能力，内核规则可以同时识别发起请求的进程上下文、被访问的目标进程对象以及原始请求的访问掩码。自保护策略先锁定受保护的核心进程，再根据请求方身份与原始请求权限，通过 EventModify 清除 PROCESS_VM_WRITE、PROCESS_VM_OPERATION 等高风险访问位，同时保留基础查询权限，在防篡改与系统兼容性之间取得平衡。

具体实现上，该场景由两条规则配合工作——Rule A 执行权限削减并继续匹配，Rule B 投递通知以观测削减后的结果：

// ── Rule A: EventModify —— 削减 VM 权限，不阻断句柄创建 ──
ESP_ACCESS_MASK_MODIFICATION accessMod = {
    // 清除 VM_OPERATION | VM_READ | VM_WRITE (0x0038)
    .AccessToClear = 0x0008 | 0x0010 | 0x0020,
    .AccessToSet   = 0
};
ESP_OB_CREATE_HANDLE_MODIFY handleModify = {
    .DesiredAccess.ModificationsCount = 1,
    .DesiredAccess.Modifications      = &accessMod
};
ESP_EVENT_MODIFY eventModify = {
    .Type     = ESP_EVENT_MODIFY_TYPE_OB_CREATE_HANDLE,
    .Data     = &handleModify,
    .DataSize = sizeof(handleModify)
};
ESP_RULE_DESCRIPTOR ruleA = {
    .EventType   = ESP_EVENT_TYPE_OB_CREATE_HANDLE,
    // 不阻断，继续向下匹配 Rule B
    .Action      = ESP_RULE_ACTION_CONTINUE_MATCHING_NEXT_RULE,
    .EventModify = eventModify
};
// 过滤条件：目标进程 ContextKey(300) > 0 + 排除自身 + 仅限用户态句柄
ruleA.RuleConfig.EventConfig.EventTypeConfig
    ->TargetObject.ProcessConfig.Filter = ContextKeyGtZero(300);
ruleA.RuleConfig.CurrentProcessConfig.Filter = NotSelfClient();
ruleA.RuleConfig.EventConfig.EventTypeConfig
    ->KernelHandleConfig.Filter = KernelHandleFalse();
// ── Rule B: Notify —— 相同过滤条件，观测削减后的 DesiredAccess ──
ESP_RULE_DESCRIPTOR ruleB = {
    .EventType = ESP_EVENT_TYPE_OB_CREATE_HANDLE,
    .Action    = ESP_RULE_ACTION_NOTIFY
};
// 向 wesp.sys 内核注册规则组
EspUpdateRules(client, {ruleA, ruleB});

我们对受保护的 cmd.exe 进程标记 ContextKey(300) = 1，随后由外部进程以 PROCESS_ALL_ACCESS（0x001FFFFF）调用 OpenProcess。操作系统先根据调用方安全上下文将其缩减为 0x00001410，WESP 的 Rule A 命中后进一步将 VM_READ（0x0010）静默抹除，最终交付的句柄掩码变为 0x00001400：

外部进程 OpenProcess(PROCESS_ALL_ACCESS = 0x001FFFFF, protected_pid)
     │
     ▼
OS 内核安全检查（基于调用方安全上下文裁剪）：0x001FFFFF → 0x00001410
     │
     ▼
wesp.sys Rule A 命中（AccessToClear = 0x0038）：0x00001410 & ~0x0038 → 0x00001400
     │
     ▼
交付有效句柄（DesiredAccess = 0x00001400，VM_READ 0x0010 被静默剥离）
     ├─→ WriteProcessMemory        → ❌ error 998 (ERROR_NOACCESS)
     ├─→ ReadProcessMemory         → ❌ error 5   (ERROR_ACCESS_DENIED)
     └─→ QueryFullProcessImageName → ✅ 成功（QUERY_INFORMATION 0x0400 未受影响）

可以看到，OpenProcess 本身正常返回有效句柄，但外部进程随后的内存读写调用全部失败，而不涉及 VM 权限的基础映像路径查询依然正常工作，完整验证了“操作系统权限裁剪 + WESP 策略裁剪”叠加下的自保护效果。

场景二：可疑进程访问敏感文件（遥测 + ContextKey + Match Subrules + Block）

面对需要多步关联的复杂威胁，高成本的行为分析继续留在用户态完成。一旦用户态引擎判定某个进程存在可疑行为，便通过接口向该进程对象的 ContextKey 写入风险标签；预先下发在内核中的文件访问规则先检查发起进程的 ContextKey 标签，命中后再通过 Match Subrules（子规则匹配）结合目标文件路径或文件类型，在内核路径上直接决定执行 Block 还是 Notify。

具体实现上，该场景由一条父规则（门控条件为当前进程 ContextKey(500) > 0）嵌套两条子规则构成：

// ── 子规则 1: 命中敏感目录 WespDemoSensitive\* → 直接 Block ──
ESP_RULE_DESCRIPTOR subrule1 = {
    .EventType      = ESP_EVENT_TYPE_FO_CREATE,
    .Action         = ESP_RULE_ACTION_BLOCK,
    .u.Block.Reason = ESP_BLOCK_REASON_ACCESS_DENIED
};
subrule1.RuleConfig.EventConfig.EventTypeConfig
    ->TargetFileObjectConfig.Filter =
        PathPattern("*\\WespDemoSensitive\\*");
// ── 子规则 2: 命中普通目录 WespDemoNormal\* → 仅 Notify ──
ESP_RULE_DESCRIPTOR subrule2 = {
    .EventType = ESP_EVENT_TYPE_FO_CREATE,
    .Action    = ESP_RULE_ACTION_NOTIFY
};
subrule2.RuleConfig.EventConfig.EventTypeConfig
    ->TargetFileObjectConfig.Filter =
        PathPattern("*\\WespDemoNormal\\*");
// ── 父规则: 检查当前进程 ContextKey(500) > 0，进入子规则分流 ──
ESP_RULE subrules[] = { subrule1, subrule2 };
ESP_RULE_DESCRIPTOR parent = {
    .EventType       = ESP_EVENT_TYPE_FO_CREATE,
    .Action          = ESP_RULE_ACTION_MATCH_SUBRULES,
    .u.MatchSubrules = {
        .SubrulesCount = 2,
        .Subrules      = subrules
    }
};
parent.RuleConfig.CurrentProcessConfig.Filter =
    ContextKeyGtZero(500);
// 仅提交父规则，子规则随父规则一并生效
EspUpdateRules(client, {parent});

我们通过三阶段测试验证了 ContextKey 作为动态状态门控的效果：

可以看到，同一个进程在标签写入前可以正常访问所有文件；标签激活后，内核规则立即对敏感路径执行阻断、对普通路径产生告警通知；标签移除后，阻断随即解除。整个过程中用户态无需销毁或重建内核规则，仅通过一次 ContextKey 读写就能实时改变内核路径上的执行决策。

安全厂商需要重组的四项能力

WESP 提供了标准化的事件采集与执行原语，但不负责判断攻击意图。进程创建、注册表修改和句柄访问只是客观的系统事实，真正的威胁检测仍要结合攻击链上下文、威胁情报与历史行为。围绕这套新框架，安全厂商需要重组四部分能力：

第一，建立稳定的内部事件语义。 接入的第一步是明确区分事件中的发起方（actor）、作用主体（subject）和目标对象（target），再将 WESP 的角色槽位映射到现有检测模型中。缺少这层统一映射，即使底层字段齐全，跨后端规则依然会出现对象含义错位。

第二，构建策略编译与转换层。 策略引擎需要一层“编译器”，将适合平台执行的确定性条件转换为 WESP 的事件订阅、过滤器、通知属性、ContextKey、子规则和动作，将复杂关联或模型推理留在用户态。同时还需识别不同事件的能力边界，避免生成运行时不支持的 Block、Allow 或 Modify 配置。

第三，现阶段采用多后端并行架构。 在 Preview 阶段，WESP 与现有内核框架更适合并行存在：由 WESP 承担已标准化的遥测采集与确定性阻断，由传统驱动补足平台尚未覆盖的能力。这是现阶段稳妥的工程演进方式，不代表正式版本的最终形态。

第四，将验证标准从“规则创建成功”升级为“安全效果成立”。 接口返回成功、收到事件通知只是第一步，工程验证必须覆盖目标操作是否真正被内核拒绝、控制连接或客户端异常后驻留规则如何表现，以及不同 Windows 版本下同一套规则能否保持一致的语义。

结语

WESP 把 46 类系统事件组织成一致的对象模型，并在系统内核中提供了标准化的规则执行位置。在这个框架下，数据面交付结构化的对象与关系，ContextKey 让状态跟随内核对象跨事件流动，Match Subrules 支持同一事件内的递进判断，Block 与策略驻留保障了内核路径上的可靠阻断，而 EventModify 则补上了细粒度权限削减的表达能力。

当通用的内核采集与执行代码逐渐由操作系统承接后，安全厂商依然负责理解攻击行为、定义防护策略并完成运营闭环。基于当前的实践可以作出一个清晰的产品判断：未来终端安全产品的能力差异，将越来越少体现在“谁能在内核里挂更多钩子”，而更多体现在事件语义建模、策略编译转换以及多后端协同的工程能力上。