EDR检测逻辑的本地仿真：heavener项目的六层架构逆向与检测工程边界

核心问题

2026年6月，安全研究者otterpwn发布了名为 heavener 的项目：一套面向Windows的模块化EDR仿真引擎，能够将SentinelOne、Cortex XDR、CrowdStrike、Sophos四款主流商业EDR的检测逻辑从代理二进制中逆向提取，并在本地针对实时或回放遥测运行判定，输出与生产环境EDR"完全一致的检测结果"。

这个项目揭示了一个被长期回避的检测工程矛盾：蓝队对自身EDR的检测边界往往缺乏可验证的认知。企业部署了昂贵的EDR产品，却难以回答以下问题：

• 某类攻击行为是否确实会被当前EDR捕获？
• 检测规则的具体触发条件是什么？
• 绕过已知检测的代价和可行性如何量化？
• 多厂商EDR之间的检测覆盖差异在哪里？

heavener的价值不在于"绕过EDR"——它的检测逻辑是只读的——而在于将EDR从黑箱转化为可审计、可验证的检测工程对象。本文基于公开技术资料，解析其六层架构、关键设计决策、各厂商模块的技术差异，以及这一方法论对蓝队检测工程的边界意义。

为什么需要本地EDR仿真

真实EDR测试的两难

传统的payload验证方式面临结构性困境：

heavener走的是第四条路径：在不运行真实代理的前提下，加载厂商原生的检测资源（ML模型、规则脚本、行为引擎），对本地采集的系统遥测执行判定。这样既保留了检测逻辑的原始语义，又避免了payload提前暴露的风险。

检测工程的可复现性诉求

从蓝队视角看，heavener解决了检测工程中的三个核心痛点：

1. 规则验证的可复现性：某条检测规则声称能捕获"进程注入"，但在真实环境中触发条件是什么？是必须有远程线程创建（CreateRemoteThread），还是仅凭VirtualAllocEx+WriteProcessMemory的组合即可？heavener允许研究者精确控制输入事件序列，观察规则触发边界。

2. 多厂商覆盖差异的量化：不同EDR对同一攻击技术的检测能力差异显著。例如，heavener的CrowdStrike模块目前仅支持静态ML检测，行为检测仍在逆向中；而Cortex XDR模块已完整还原了7967条CLIPS生产规则。这种差异为企业选择或叠加EDR提供了数据支撑。

3. 检测漂移的监控：厂商频繁更新检测规则。heavener支持将事件序列保存为JSON并回放，使得"同一攻击场景在不同版本EDR中的表现"成为可对比的实验。

heavener的六层架构

heavener的架构设计遵循一条清晰的数据流：采集 → 归一化 → 富化 → 检测 → 输出。以下是六层核心组件的解析。

第一层：内核驱动 heavendrv

heavendrv是项目的基石，一个Windows内核微筛选器驱动，通过四类回调机制捕获系统行为：

关键设计细节：

• 无锁队列 + 统计丢弃：驱动使用无锁队列传递事件到用户态，消费滞后时统计丢弃数而不阻塞内核线程。这保证了驱动不会因用户态处理慢而影响系统稳定性——代价是可能丢失事件。
• 真实创建者记录：驱动同时上报进程的父PID和真实创建者PID，直接识别父PID欺骗（Parent PID Spoofing）。这是近年攻击者常用的规避手段。
• 通信协议：FilterSendMessage协议带版本握手，单条记录最大64KB，变长数据（字符串、调用栈）以长度前缀二进制块传输。

第二层：ETW提供者订阅

内核驱动无法覆盖全部遥测，heavener补充订阅了七类ETW提供者：

ETWTI的特殊性：微软将ETWTI的消费权限限制为PPL（Protected Process Light）进程。heavener为此实现了heaventi-svc——一个PPL-AM采集服务，通过ELAM（Early Launch Anti-Malware）驱动建立信任锚点，获得PPL权限后通过命名管道转发原始事件。这是项目中技术门槛最高的组件之一。

第三层：进程模型 ProcessModel

原始离散事件的检测价值有限，必须结合进程上下文。ProcessModel在内存中维护一棵实时更新的进程树：

• 每个进程节点保存的字段：唯一ID、PID、父PID、真实创建者PID、进程名、命令行、镜像路径、创建时间、完整性级别、会话ID、用户SID、文件版本信息、证书发布者、登录会话ID。
• 行为标记：是否属于远程组、是否存在注入线程、是否被跨进程打开、是否被申请虚拟内存读写权限等。
• 双索引结构：按PID查询当前运行进程，按唯一ID查询历史进程信息。整棵树用读写锁保护，支持多读者单写者并发。
• 扩展值字典：厂商规则可在不同事件间读写字典，累积跨事件行为状态。例如，某条规则需要追踪"进程A在过去5分钟内是否创建过计划任务"。

第四层：修饰引擎 ModifierEngine

ModifierEngine计算跨事件的聚合行为特征，核心功能包括：

• 文件创建滑动窗口：为每个进程维护最近32个创建文件的滑动窗口，支撑勒索软件检测（短时间内多目录同名勒索信）。
• 调用栈富集：对ETWTI事件的调用栈进行分类——合法模块承载、无后备帧（shellcode/反射加载器）、系统调用溯源（正常路径 vs 间接/直接系统调用）、调用栈伪造检测（检查返回地址前字节是否符合合法CALL指令编码）。
• 字节补丁检测：当检测到进程将敏感DLL的.text段改为可写可执行时，读取内存与磁盘原始文件逐字节对比，在字节级别检测EDR unhooking行为。

第五层：遥测关联器 TelemetryCorrelator

从原始底层事件合成更高层级事件，使厂商原生规则直接运行：

LogonSessionMap组件将登录会话LUID解析为登录类型（交互式/RDP），为横向移动检测提供关键上下文。

第六层：厂商检测模块

所有厂商模块实现统一C++接口，支持运行时热切换。引擎只调用标准接口，完全不关心内部实现。

SentinelOne模块

双层检测架构：

1. 静态扫描层：8个XGBoost模型 + YARA规则，返回良性/可疑/恶意三级判定。
2. 行为引擎层：嵌入LuaJIT运行时，加载203个Lua行为脚本。两套分发机制并行：
   • 事件类系统：脚本按S1内部事件类层级注册处理函数，事件到来时转换为S1 Lua事件格式分发。
   • registerOSEventFilter管道：137个OS过滤回调，引擎维护静态路由表，附带守卫函数做前置判断（修饰标记、注册表路径、文件名模式匹配），避免不必要性能开销。

Lua脚本可回调C++层查询进程模型、文件富集信息、代理配置、读写进程扩展字典。

Cortex XDR模块

三层检测体系，架构最复杂：

1. YARA静态扫描：36套按文件类型分类的规则集（PE、脚本、宏、文档等），先识别文件类型再运行对应规则集。
2. ML检测：本地XGBoost模型，YARA与ML结果支持四种融合策略（取最高严重等级、YARA优先、ML优先、加权组合）。
3. CLIPS行为引擎：核心层，运行完整的CLIPS（C Language Integrated Production System）专家系统，加载约7967条从真实代理提取的生产规则。

CLIPS引擎将每个BehavioralEvent转换为事实字符串断言到工作内存。进程启动类事实包含27个字段（镜像路径、命令行、父进程信息、SID、完整性级别、代码签名、哈希、PE版本信息、熵值等）。

ETW-TI路径的特殊处理：远程内存操作事件到来时，栈富集器处理调用栈后，对目标分配内存、调用站点内存、页基址、分配基址四块区域执行YARA扫描，再通过地址解析器将基地址解析为镜像路径。所有信息打包送入CLIPS工作内存，规则既能知道操作内容，也能知道操作发生时内存中的内容。

项目还从零重写了66个CLIPS规则调用的外部函数，包括一套完整的ECMAScript兼容正则引擎（因规则使用的正则语法C++标准库不支持）。CLIPS支持进程外隔离模式，子进程崩溃自动重启，反复崩溃事件跳过以保证流程继续。

CrowdStrike模块

目前仅支持静态ML检测。行为检测逻辑封装在channel文件中，作者正在逆向分析解析与导入逻辑。静态扫描器运行CrowdStrike的XGBoost模型，返回恶意概率，判定阈值取自真实组件逻辑。

Sophos模块

两套ML模型（PE文件、PDF/Office文档）+ 传统特征码扫描引擎。三类检测结果取最严重项作为最终判定。

事件处理管道的设计哲学

为什么单线程？

heavener的事件处理管道刻意设计为单线程。检测逻辑对事件顺序高度敏感："进程创建→写入文件→加载镜像"与这三个事件打乱顺序，代表完全不同的行为。单线程保证厂商模块看到的事件顺序与真实EDR代理采集顺序完全一致。

事件通过无锁提交接口送入队列，成批取出处理，避免逐个事件加锁的性能损耗。

三阶段流水线

每个事件处理严格遵循三阶段：

1. 更新进程模型：让所有下游组件拿到最新进程状态。
2. 运行修饰引擎：为事件附加聚合行为特征。
3. 送入厂商模块：执行检测逻辑。

遥测关联器合成的更高层级事件同样走完整流水线。

回放系统：检测工程的实验基础设施

heavener的回放能力是其对检测工程最大的贡献之一。

捕获与回放机制

• 捕获模式：将内核驱动或ETW采集的实时事件序列保存为JSON文件。
• 回放模式：加载JSON文件，将所有事件完整送入处理流水线，得到与实时运行完全一致的检测结果。
• 确定性告警ID：采用FNV-1a哈希算法，同一条事件流无论回放多少次，产生完全一致的告警ID。

典型开发工作流

靶机运行攻击场景 → 捕获事件序列(JSON)
    ↓
开发主机回放验证规则触发情况
    ↓
调整富集逻辑或路由规则
    ↓
再次回放验证效果

这套机制将测试工作与内核驱动/ETW环境解耦。研究者只需在虚拟机中运行一次攻击场景，即可在开发主机上反复迭代，不需要每次测试都以管理员权限加载内核驱动。

配套运营控制台

heavener附带完整的Docker化Web控制台，技术栈：

• ClickHouse：告警数据存储，支持追加写入和物化视图秒级统计。
• Postgres：可变应用状态（资产清单、处置工作流、保存视图、规则图谱）。
• Redis：幂等校验和服务端事件推送。
• 后端：Go语言REST API。
• 前端：React单页应用，Caddy提供服务。

四大核心视图：

边界与局限

heavener并非EDR的完美复制品，其局限性需要清晰认知：

云端检测能力不可复刻

所有EDR厂商将相当一部分检测能力部署在云端：文件信誉查询、云端ML模型、威胁情报关联、动态沙箱分析。这些层级运行在厂商基础设施上，代理与云端通信经过身份认证，协议不公开。heavener只能复现本地检测逻辑，无法覆盖云端判定。

行为检测覆盖不均

内核稳定性风险

heavendrv作为第三方内核驱动，在高负载场景下可能出现事件丢弃。虽然驱动设计上不阻塞内核线程，但丢弃事件意味着检测盲区。生产环境使用需要充分的压力测试。

法律与合规边界

逆向工程商业EDR检测逻辑涉及法律灰色地带。heavener仅用于本地安全研究和payload验证，不得用于：

• 生产环境替代真实EDR
• 生成绕过EDR的武器化方案
• 公开发布提取的厂商规则或模型

对蓝队检测工程的启示

从"信任厂商"到"验证厂商"

heavener代表了一种检测工程范式的转变：蓝队不应被动接受EDR厂商的检测能力声明，而应建立可验证的检测覆盖矩阵。

自建检测能力的参考架构

即使不直接使用heavener，其架构设计对自建检测系统也有参考价值：

1. 分层采集策略：内核回调为主，ETW补充，PPL-AM获取特权遥测。
2. 进程为中心的上下文模型：所有检测最终都依赖进程树和跨事件状态累积。
3. 规则引擎的隔离性：CLIPS的进程外隔离模式值得借鉴，避免规则崩溃拖垮整个系统。
4. 确定性回放：检测系统的可测试性依赖于捕获-回放机制，这是CI/CD pipeline集成的基础。

与Sysmon原生集成的关系

2026年2月，微软将Sysmon原生集成至Windows 11（Build 26300.7733）。这一举措与heavener形成有趣的对照：

• Sysmon：官方、稳定、只记录不告警，依赖下游SIEM分析。
• heavener：非官方、实验性、完整复刻EDR检测流水线，自带判定输出。

微软的WESP（Windows Endpoint Security Platform）战略明确推动EDR向用户模式转型。未来，Sysmon提供标准化遥测，heavener类项目提供检测逻辑验证，两者可能形成互补的检测工程生态。

风险矩阵：heavener的双刃剑效应

核心判断：heavener本身是中性工具，其价值取决于使用者的目的。对蓝队而言，它填补了"EDR检测能力可验证性"的空白；对攻击者而言，它降低了绕过EDR的实验成本。这种双刃剑效应是所有检测透明度工具的共同命运。

结论

heavener项目将EDR从黑箱推向了可审计的检测工程对象。其六层架构——内核驱动采集、ETW补充、进程模型上下文、修饰引擎富化、遥测关联器合成、厂商模块判定——完整复刻了商业EDR的检测流水线。SentinelOne的Lua行为引擎、Cortex XDR的CLIPS专家系统、CrowdStrike的静态ML模型、Sophos的多层检测，展示了不同厂商在检测架构上的显著差异。

对蓝队而言，heavener的价值不在于绕过，而在于建立检测能力的可验证基准。当企业能够回答"我们的EDR对某类攻击的检测边界在哪里"时，防御决策就从"信任厂商"升级为"工程化验证"。

未闭合边界：

1. CrowdStrike行为检测逻辑的逆向仍在进行中，完整覆盖需要时间。
2. 云端检测能力（信誉查询、云端ML、威胁情报）本质上是不可本地复刻的，这部分盲区需要通过多源情报和主动狩猎来弥补。
3. 内核驱动的稳定性在高负载生产环境中的长期表现尚未有大规模验证数据。
4. 微软WESP战略推进后，用户态EDR架构可能改变当前内核驱动的采集模式，heavener类项目需要适配新的Windows安全平台接口。