2025 年至 2026 年，端点检测与响应（EDR）领域发生了一件看似矛盾的事：一方面，Elastic、CrowdStrike 等厂商将**调用栈（call stack）**视为 Windows 端点遥测的"win-win-win"——同时降低误报、减少漏报、增强告警可解释性；另一方面，开源社区连续发布 Moonwalk++、LACUNA Chain / Ghost Frames 等 PoC，证明调用栈不仅可以被伪造，而且伪造成本正在快速下降。这意味着，EDR 依赖的"调用链信任"假设正在经历结构性挑战。
本文的核心问题是：当攻击者能够系统性地伪造 Windows 调用栈时，以栈指纹为核心的行为检测规则是否正在从"高置信度信号"退化为"可操纵的上下文"？ 我们将从检测原理出发，拆解 Moonwalk++ 与 LACUNA Chain 的攻击机制，分析调用栈作为"信任锚"为何存在单点失效风险，并讨论蓝队在无法完全阻止欺骗的情况下，应如何通过多层遥测交叉验证与行为相关性分析重建检测韧性。
调用栈检测为何成为 EDR 的新宠
在 Windows 端点上，EDR 的传统检测逻辑主要依赖三类遥测：API Hooking（用户态函数拦截）、ETW（Event Tracing for Windows）（内核态事件订阅）以及内核回调（如 PsSetCreateProcessNotifyRoutineEx、ObRegisterCallbacks）。这三类机制各有所长，但共同面临一个难题：当攻击者使用**直接系统调用（direct syscall）或间接系统调用（indirect syscall）**绕过用户态 hook 时，EDR 会失去对敏感 API 调用发起者的上下文感知。
调用栈检测试图解决这个问题。其基本逻辑是：无论攻击者通过何种路径进入内核，CPU 在执行敏感操作前的某个时刻，其线程栈上必然留存着返回地址链（return address chain）。EDR 通过内核回调或 ETW 会话，在关键事件触发点（如进程创建、远程线程注入、内存分配权限变更）捕获当前线程的完整调用栈，并将其与已知良性模式进行比对。
Elastic 在 2024–2025 年的工程实践中将这一机制称为内核调用栈增强（kernel call stack enrichment）。根据 Elastic Security Labs 的公开技术博客，Elastic Defend 的 550 余条行为规则中，大量规则利用调用栈信息判断敏感操作是否来自可信路径。例如，NtCreateThreadEx 的调用栈若显示调用者来自 kernel32.dll → legitimate_service.exe，与调用者来自 unknown_mapped_memory → suspicious_loader.dll，其检测置信度完全不同。
调用栈的价值可以概括为三点：
- 降低误报：通过排除已知良性调用路径，减少高权限进程正常行为触发的噪音。
- 降低漏报：即使攻击者绕过 API hook，只要其代码最终需要调用系统服务，调用栈仍可能暴露异常入口点（如从堆内存直接调用
NtAllocateVirtualMemory）。 - 增强可解释性：分析师可以直接看到"谁调用了谁"，缩短事件调查中的上下文重建时间。
然而，这一检测模型隐含了一个关键假设：调用栈是不可伪造的，或至少伪造成本极高。 Moonwalk++ 与 LACUNA Chain 的出现，正在动摇这一假设的根基。
Moonwalk++：ROP + 内存加密下的调用链伪造
Moonwalk++ 并非凭空出现。它的技术谱系可以追溯至 Stack Moonwalking 与 SilentMoonwalk：前者首次系统性地展示了如何通过操纵栈帧隐藏原始调用者；后者则进一步使用 ROP（Return-Oriented Programming） 使控制流与**栈展开（stack unwinding）**解耦，从而令操作系统和调试器的 unwinder 重建出一条与真实执行路径完全不同的虚假调用链。
技术实现的三重机制
根据 klezVirus 在 GitHub 发布的 Moonwalk++ PoC 代码与技术博客，该技术的核心由三个相互增强的模块组成：
1. ROP 驱动的控制流/栈展开解耦
在正常的程序执行中，CPU 的指令指针（RIP）与栈指针（RSP）是协同推进的：函数调用时 call 指令将返回地址压栈，ret 指令从栈顶弹出地址并跳转。Windows 的 SEH（Structured Exception Handling） unwinder 以及现代 EDR 的内核栈回溯逻辑，都假设栈上的返回地址链与实际控制流一致。
Moonwalk++ 使用 ROP gadget 打破这一假设。它不在栈上留下传统的 call → ret 痕迹，而是通过预先布置的 gadget 链，让 CPU 跳转至目标系统调用 stub，同时栈上的返回地址指向一个伪造的合法函数帧（例如 OneDrive.exe 的某个导出函数）。当 EDR 的内核回调触发并捕获调用栈时，unwinder 从 RSP 开始回溯，看到的将是一条完全合法的调用链，而真实的恶意代码执行路径已被 ROP 链抹除。
2. 内存自加密（In-Memory Self-Encryption）
Moonwalk++ 的第二个模块在执行期间对 shellcode 进行实时加密/解密。具体而言，恶意代码被分割为多个小块，每执行完一块即重新加密，仅在下一块执行前短暂解密。这一设计的直接目的是对抗 EDR 的内存扫描（memory scanning）和YARA 规则匹配。即使 EDR 用户态代理周期性扫描进程内存，也很难在加密状态下捕获到特征码。
值得注意的是，内存自加密与调用栈欺骗之间存在协同效应：EDR 的检测引擎通常会将"异常调用栈"与"内存中的可疑代码"进行关联打分。Moonwalk++ 同时消除了这两个信号——调用栈看起来合法，且内存中没有持续暴露的恶意代码。
3. 针对调用栈签名的精准绕过
Elastic 等厂商的检测规则并非只检查单个返回地址，而是构建调用栈签名（call stack signatures）——即一条完整的模块路径序列。Moonwalk++ 的伪造精度达到了模块级别：它可以将整个调用链伪装成来自 C:\Program Files\Microsoft OneDrive\OneDrive.exe → ntdll.dll → kernelbase.dll → NtCreateThreadEx 的合法路径。
2026 年初公开的研究证实，Moonwalk++ 能够成功绕过 Elastic EDR 的多个基于调用栈的行为规则。其根本原因不是规则逻辑有误，而是规则的信任锚（trust anchor）本身被伪造了。
LACUNA Chain / Ghost Frames：DLL 间隙中的"幽灵帧"
如果说 Moonwalk++ 是通过主动伪造调用链来欺骗 EDR，那么 LACUNA Chain 及其核心技术 Ghost Frames 则揭示了 Windows 调用栈机制中一个更为隐蔽的结构性盲区：即使攻击者什么都不做，Windows 自身的 DLL 加载与栈展开逻辑也可能留下"看不见的间隙"，而这些间隙足以让 EDR 的 unwinder 产生误判。
Ghost Frames 的技术原理
Windows 的 64 位栈展开依赖存储在 PE 文件中的 UNWIND_INFO 结构。当异常发生或 EDR 触发栈回溯时，操作系统使用这些元数据从 RIP 反向计算每个栈帧的大小和返回地址位置。这一机制的前提是：所有参与调用链的模块都必须提供完整、准确的 unwind 信息。
Ghost Frames 攻击利用了两个现实问题：
- 部分 Windows 系统 DLL 的 unwind 信息不完整或存在歧义。某些经过优化或手动汇编的导出函数没有标准的
UWOP_PUSH_NONVOL/UWOP_SET_FPREG记录，导致 unwinder 在回溯时"跳过"或"错误解释"某些帧。 - 攻击者可以构造人工栈帧，使其恰好落入 unwinder 无法解析的区域。通过精心控制 RSP 和伪造的返回地址，攻击者让 unwinder 在早期就"迷失"，从而将真实的恶意调用帧完全排除在回溯结果之外。
Netcrook 的安全研究将这一效果称为**"幽灵帧"（Ghost Frames）**：它们在物理内存中真实存在，但在 EDR 捕获的调用栈中完全不可见。其后果是，EDR 看到的调用链比实际执行的调用链更短、更"干净"，甚至完全缺失了关键的恶意入口点。
与 HookChain 研究的关联
Ghost Frames 并非孤例。它与早期的 HookChain 研究共享同一个底层洞察：EDR 的检测逻辑严重依赖执行上下文的完整性，而上下文完整性又依赖栈展开的正确性。一旦栈展开本身成为攻击面，所有建立在调用栈之上的检测规则都会面临基础假设崩溃的风险。
LACUNA Chain 将 Ghost Frames 与其他规避技术（如 IAT unhooking、syscall proxying）组合成一个完整的攻击框架。其攻击流可以概括为：
- 初始访问：通过钓鱼或供应链漏洞植入 loader。
- 权限维持：使用 Ghost Frames 隐藏主模块的调用痕迹，使 EDR 无法将异常行为归因于恶意进程。
- 防御规避：在需要执行敏感操作（如 LSASS 内存读取、远程线程注入）时，确保调用栈仅显示良性系统模块路径。
- 横向移动：利用被隐藏的调用上下文，在多个端点间复用同一套规避模板而不触发行为关联告警。
| 技术维度 | Moonwalk++ | LACUNA Chain / Ghost Frames |
|---|---|---|
| 核心机制 | ROP + 内存自加密 + 主动伪造调用链 | 利用 Windows DLL unwind 间隙制造"幽灵帧" |
| 攻击视角 | 主动欺骗：构造虚假但完整的良性调用栈 | 被动隐匿：让真实恶意帧从回溯中"消失" |
| 针对目标 | 调用栈签名规则（如 Elastic 行为检测） | 栈回溯机制本身（unwinder 可靠性） |
| 实现复杂度 | 高（需 ROP gadget 搜索、内存加密引擎） | 中高（需深入理解 PE unwind 元数据） |
| 检测残留 | 无直接残留，但 ROP 链可能在内存中留下痕迹 | 栈回溯结果"过于干净"本身可能是异常信号 |
| 关联研究 | Stack Moonwalking, SilentMoonwalk | HookChain, ARM64 Call Stack Spoofing |
上表展示了两种技术虽然路径不同，但最终都指向同一个结论：调用栈作为信任锚的可信度正在下降。
调用栈为何从"信任锚"变成"单点失效"
Moonwalk++ 与 LACUNA Chain 的成功并非偶然。它们揭示了调用栈检测模型中一个深层的结构性矛盾：EDR 试图从一个攻击者拥有写权限的内存区域中，读取不可篡改的证据。
栈内存的可写性
在 Windows 用户态进程中，线程栈默认位于进程虚拟地址空间内，且对进程自身代码是可读写的。这意味着，任何能够在目标进程中执行代码的攻击者，理论上都可以修改栈上的返回地址、帧指针（RBP）以及 SEH 链。ROP 之所以能够工作，正是因为栈是可写的；Ghost Frames 之所以能够隐匿，也是因为攻击者可以操纵 RSP 使其指向 unwinder 无法解析的区域。
相比之下，基于**硬件的性能监控单元（PMU）或Intel PT（Processor Trace）**的检测机制，其证据来源不在攻击者的直接写权限范围内，因此具有更高的防篡改性。调用栈检测缺乏这种硬件级隔离。
Unwinder 的依赖链问题
Windows 的栈展开是一个多层委托过程：
- EDR 内核回调触发，请求当前线程的调用栈。
- 操作系统使用 RtlWalkFrameChain 或类似机制进行回溯。
- 回溯依赖每个模块的 PE unwind info、异常目录和运行时寄存器状态。
- 若其中任一环节被操纵，最终输出的调用栈就是不可信的。
问题在于，EDR 作为调用栈的消费者，并不验证 unwind info 的完整性，也不验证返回地址是否指向合法的代码段。这种"消费者盲目信任生产者"的模式，正是 LACUNA Chain 能够利用的盲区。
从"参考信号"到"信任锚"的错位
调用栈最初被引入 EDR 检测体系时，其定位是辅助上下文（context enrichment）——帮助分析师理解告警背后的调用路径。但在实际工程落地中，由于调用栈对检测准确率的提升效果显著，它逐渐被部分检测引擎提升为决策级信号（decision-level signal），甚至成为某些规则的唯一否决条件（veto condition）。
这种定位的升级带来了风险：一旦调用栈可被伪造，依赖它的规则就会从"高置信度"瞬间跌落为"高误信度"（high confidence in false data）。Moonwalk++ 对 Elastic 规则的绕过，本质上不是规则写得不好，而是规则赋予了一个可变信号过高的决策权重。
上图展示了两种技术如何 converges 到同一个结果：EDR 基于一个被篡改或截断的调用栈做出错误的放行决策。这个流程的核心脆弱点在于 EDR 没有独立的验证层来交叉核对调用栈的真实性。
蓝队重建：从"信任栈"到"验证栈"
调用栈检测不会消失。在大多数日常场景中，它仍然是一个高性价比的上下文增强手段。但安全团队需要将其从信任锚降级为参考信号，并在架构上构建不依赖调用栈真实性的多层验证体系。以下是基于当前攻防现状的检测工程建议。
1. 行为相关性优先于栈指纹
Elastic 官方在其技术博客中已明确承认调用栈存在架构局限性。面对 Moonwalk++ 和 Ghost Frames，检测逻辑应减少对"调用链模式匹配"的依赖，增加对行为序列相关性的分析。
具体而言，不应再因为"NtCreateThreadEx 的调用栈看起来来自 OneDrive"就自动降低告警优先级，而应结合以下信号进行交叉验证：
- 线程创建目标：新线程的入口点是否指向已加载模块的合法导出函数？还是指向
RWX内存区域？ - 时间序列异常：OneDrive.exe 在正常情况下是否会在此时刻创建远程线程？其历史行为基线如何？
- 内存区域属性：即使调用栈合法，目标进程的内存映射中是否出现了无文件（fileless）代码区域？
这种**"栈上下文 + 行为基线 + 内存状态"**的三维关联，比单一栈指纹更难被一次性绕过。
2. 内核 ETW 与用户态 Hook 的交叉验证
Moonwalk++ 的 ROP 链主要影响用户态可见的调用栈，但内核 ETW 提供者（如 Microsoft-Windows-Kernel-Process、Microsoft-Windows-Threat-Intelligence）在系统调用进入内核门时捕获的上下文，与用户态 hook 看到的可能存在差异。
检测工程应设计遥测源不一致告警：当用户态 EDR agent 报告某操作的调用栈为"良性"，但内核 ETW 显示该操作来自异常内存区域或异常进程上下文时，应触发高优先级审查，而非自动调和差异。
3. 异常线程起点检测
无论调用栈如何伪造，攻击者的最终载荷通常需要在某个线程中执行。一个有效的补偿控制是：监控线程起点（Thread Start Address）的合法性。具体检测点包括：
- 线程起点是否指向磁盘上已知模块的
.text段？ - 线程起点是否经过代码签名验证？
- 对于动态生成的线程（如通过
NtCreateThreadEx创建的线程），其起点与父进程的代码段是否在同一模块内？
Moonwalk++ 可以伪造调用栈，但如果其最终执行体的线程起点位于 0x000001FF... 这样的动态分配内存区域，这本身就是一个独立于调用栈的强信号。
4. 内存完整性持续验证
内存自加密虽然能躲避周期性扫描，但无法躲避执行时的完整性验证。蓝队可以考虑以下技术路径：
- VBS（Virtualization-Based Security）/ HVCI（Hypervisor-Protected Code Integrity）：在支持硬件虚拟化的终端上启用 HVCI，确保只有签名的代码才能执行。Moonwalk++ 的 ROP 链和自加密 shellcode 在 HVCI 环境下会面临更高的执行门槛（需要利用签名的脆弱驱动或内核漏洞才能加载未签名代码）。
- 运行时代码完整性（Runtime Code Integrity, CI）检查：通过内核驱动或受信任的代理，对关键进程（如 LSASS、浏览器、Office 进程）的代码段进行哈希白名单校验。任何未在白名单中的代码执行，即使调用栈完美，也应触发告警。
5. 遥测覆盖差距的持续度量
EDR Telemetry 项目提出的透明基准测试理念值得蓝队借鉴。安全团队应定期在自己的环境中执行以下动作：
- 使用开源 PoC（如 EDRBypassZoo 中的 call stack spoofing 模块）测试当前 EDR 对已知规避技术的可见性。
- 记录"EDR 是否捕获了异常调用栈？是否捕获了真实执行路径？是否生成了告警？"
- 将测试结果映射到具体的检测规则缺口，形成可量化的遥测覆盖差距报告（Telemetry Coverage Gap Report）。
| 补偿控制层 | 检测目标 | 针对 Moonwalk++ | 针对 Ghost Frames | 实施复杂度 |
|---|---|---|---|---|
| 行为序列相关性 | 操作上下文 + 时间基线 + 进程历史 | 高（伪造栈需配合正常行为基线才不被触发） | 高（幽灵帧无法隐藏异常行为序列） | 中（需行为基线建设） |
| 内核/用户态遥测交叉验证 | 用户态栈 vs 内核上下文不一致 | 高（ROP 链在内核门处可能暴露真实来源） | 中（Ghost Frames 主要影响用户态回溯） | 中高（需多源日志关联平台） |
| 异常线程起点检测 | 线程入口点是否在合法代码段 | 高（shellcode 通常位于动态内存） | 高（即使帧消失，线程起点仍可能异常） | 低（多数 EDR 已支持） |
| VBS/HVCI 内存完整性 | 未签名代码执行限制 | 高（ROP + 自加密 shellcode 执行门槛提升） | 中（不直接阻止 Ghost Frames，但提高整体门槛） | 中（需硬件支持 + 兼容性测试） |
| 遥测覆盖差距度量 | 已知规避技术是否被检测 | 中（需持续更新测试用例） | 中（需深入 unwind 机制测试） | 高（需专业红队/紫队能力） |
上表的核心信息是：没有任何单一补偿控制能够完全抵消调用栈伪造的风险，但多层控制的叠加可以显著提高攻击者的规避成本，使其从"一次性绕过"退化为"需要多次精准配合的高复杂度攻击"。
上图展示了多层检测如何覆盖同一攻击向量的不同侧面。即使攻击者突破了其中一层（如伪造了调用栈骗过行为基线引擎），其他层（如线程起点校验、HVCI）仍可能暴露其痕迹。
结论：调用栈检测的降级与重建
Moonwalk++ 与 LACUNA Chain 并非宣告了 EDR 的终结，而是宣告了调用栈作为单一信任锚时代的终结。这两项研究的共同启示是：任何建立在"攻击者无法篡改证据"假设之上的检测机制，都会随着攻击者能力的提升而逐渐失效。调用栈检测从"辅助上下文"被提升为"决策信号"的过程，本质上是安全产品对检测效率的追求与攻击面扩大之间的张力体现。
对于蓝队而言，务实的路径不是放弃调用栈，而是降低其决策权重，增加交叉验证层。具体而言：
- 短期：在当前 EDR 规则中审查所有将调用栈作为"放行条件"（allow-list condition）的逻辑，将其降级为"评分因子"（scoring factor）。
- 中期：建立行为基线引擎与异常线程起点监控，使攻击者即使伪造了调用栈，仍需在行为序列和内存布局上保持完美正常才能避免告警——这显著提高了攻击成本。
- 长期：在硬件支持的终端上推动 VBS/HVCI 的普及，将"代码执行权限"的证明从"栈上的返回地址"转移到"硬件强制签名的代码页"，从根本上改变攻防博弈的边界。
一个尚未闭合的技术边界是：当前的开源 PoC 主要针对 x64 架构的用户态 EDR 代理。ARM64 Windows 设备的调用栈欺骗（如 xaitax/ARM64-CallStackSpoofing 所示）是否会导致移动端/ARM 设备上的 EDR 面临更严重的盲区？ 随着 Windows on ARM 在企业环境中的渗透率上升，这一架构差异可能成为下一代检测工程的关键变量。
另一个待验证的假设是：当 EDR 厂商开始在内核中直接验证 unwind info 的完整性（例如通过 PE 签名验证 unwind metadata）时，Ghost Frames 是否会被系统性消除？ 这一假设的可行性取决于 Windows 内核是否愿意承担额外的 PE 解析开销，以及厂商是否愿意共享 unwind info 的签名标准。在这些问题得到工程层面的回答之前，调用栈检测的降级策略仍是蓝队最稳妥的应对。
