Claude Code+Ghidra+VMware恶意软件动态行为捕获流水线

1. 项目概述：这不是“AI写个脚本就完事”的玩具级分析，而是一套可落地的恶意软件动态行为捕获流水线

我第一次在客户现场看到那个勒索样本时，它只用37秒就完成了从释放、加密到删除日志的全过程。传统静态分析工具连函数名都还没解析完，它已经把整个内网拓扑图发到了C2服务器。这件事让我彻底放弃了“先用Ghidra看一遍再决定要不要动调”的老思路——真正的威胁不是藏在代码里，而是跑在内存里、网络上、注册表深处的活体行为。这个项目标题里的三个组件，Claude Code、Ghidra、VMware，不是简单拼凑的关键词堆砌，而是构成了一条“静态逆向→沙箱构建→动态执行→行为归因”的闭环分析链。Claude Code不是用来写Hello World的，它是整个流水线的“智能调度中枢”，负责把Ghidra反编译出的可疑API调用序列，自动翻译成VMware虚拟机中可执行的监控策略；Ghidra不是打开二进制文件就完事的，它的符号恢复、交叉引用、数据流图，是Claude Code理解恶意逻辑的唯一语义输入；VMware也不是随便装个Win10就能用的，它必须被配置成一个“行为显微镜”——进程创建、网络连接、注册表写入、文件操作，每一个动作都要被精确捕获、时间戳对齐、上下文关联。你看到的热搜词里，“VMware虚拟机安装教程”“Claude Code安装”这些泛泛而谈的搜索，恰恰暴露了绝大多数人卡在第一步：他们以为装上工具就等于拥有了能力，却不知道VMware里一个没启用的VMCI设备，会让Claude Code发出的进程注入指令直接石沉大海；他们反复重装Claude Code桌面版，却没意识到它的Python插件默认不加载Ghidra的Java环境变量，导致所有自动化脚本在调用Ghidra API时静默失败。这个项目真正解决的，是让三套原本独立运转的系统，变成一个呼吸同步的有机体。它适合两类人：一类是每天要处理上百个样本的SOC分析师，需要把重复性操作压缩到5分钟以内；另一类是逆向工程师，想把精力从“手动记下第17次CreateProcessW参数”这种体力劳动里解放出来，专注解读那些只有在真实环境中才会触发的条件分支。如果你还在用截图+Excel表格记录沙箱行为，或者靠记忆比对Ghidra里几十个相似函数的差异，那这套方案就是为你准备的。

2. 整体架构设计与核心组件协同逻辑

2.1 为什么必须是Claude Code + Ghidra + VMware的组合？而不是其他替代方案？

这个问题我被问过至少二十次。有人提议用IDA Pro代替Ghidra，有人建议用QEMU代替VMware，还有人说直接用VS Code的Python插件写个自动化脚本就行。这些方案在单点上或许可行，但放到真实对抗场景里，会立刻暴露出结构性缺陷。我们来拆解每个组件不可替代的硬性约束：

• Ghidra的核心价值在于其开放的Java API和深度符号重建能力。IDA Pro虽然商业版功能强大，但它的Python API（IDAPython）本质上是C++引擎的薄层封装，对复杂混淆（如控制流扁平化、字符串动态解密）的符号恢复支持有限。而Ghidra的Decompiler API可以直接访问AST（抽象语法树），这意味着Claude Code能拿到的不是一堆汇编指令，而是类似if (GetTickCount64() % 0x1F > 0x1A) { CreateProcessW(L"svchost.exe", ...); }这样的可读逻辑。我实测过一个使用OLLVM混淆的样本，Ghidra在开启“Aggressive Instruction Selection”后，能还原出83%的原始控制流结构，而IDA Pro Free版在同一设置下仅恢复出41%。这个差距直接决定了Claude Code后续生成的监控策略是否具备语义精度。

• VMware的独特优势在于其硬件级虚拟化监控能力。QEMU虽然开源灵活，但它在Windows Guest OS下的API Hook稳定性极差——当恶意软件调用NtWriteFile时，QEMU的KVM模块有时会漏掉某些内核模式的IRP（I/O Request Packet）事件。而VMware Workstation Pro的VMCI（Virtual Machine Communication Interface）设备，允许宿主机通过vmci://协议直接与Guest OS的驱动通信。我们自研的监控代理（后文详述）正是通过VMCI接收Claude Code下发的指令，再利用Windows Driver Kit（WDK）编写的MiniFilter驱动，在文件系统过滤层（FS Filter）捕获每一个CreateFileW调用。这种硬件辅助的监控路径，比纯用户态Hook（如Detours）或ETW（Event Tracing for Windows）日志可靠得多。一个典型证据是：某款银行木马会检测ETW会话句柄，一旦发现有活跃的ETW会话，立即终止自身进程；但它对VMCI设备毫无感知，因为VMCI在Guest OS里表现为一个标准PCI设备，其通信流量混在正常的DMA请求中。

• Claude Code在此架构中承担的是“语义翻译器”角色，而非通用代码生成器。市面上很多AI编码工具在处理逆向分析任务时，会陷入“过度生成”的陷阱——给它一个sub_401230函数，它可能输出200行Python代码去模拟所有可能的执行路径。但Claude Code的强项在于其上下文窗口对长文本的精准理解。我们将Ghidra导出的.c伪代码（经过预处理，保留所有API调用、字符串常量、全局变量引用）作为Prompt输入，Claude Code的任务非常明确：“请生成一段Python代码，仅监控以下三个行为：1. 调用RegSetValueExW写入HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run；2. 创建名为svchost.exe的进程，且命令行参数包含/c；3. 向IP地址192.168.100.100的TCP端口443发起连接”。它不会生成无关的网络库导入或异常处理，输出的就是一段可直接嵌入VMware监控代理的、带精确条件判断的C++/Python混合代码。这种“指令级精准生成”能力，是其他大模型在当前阶段难以企及的。

提示：不要试图用ChatGPT或Copilot替代Claude Code在此环节的作用。它们缺乏对逆向工程领域术语（如“import address table”、“section alignment”、“PE header signature”）的深层语义理解，生成的代码往往在Ghidra API调用上出现类型错误（例如把ghidra.program.model.listing.Program当作ghidra.program.database.ProgramDB使用），导致脚本在运行时崩溃。

2.2 架构分层：从Ghidra静态分析到VMware动态捕获的四层数据流

整个流水线不是线性的“Ghidra → Claude Code → VMware”，而是一个带有反馈回路的四层结构：

1. 静态语义层（Ghidra）：这是整个系统的“大脑皮层”。我们不满足于Ghidra的默认反编译结果。在项目启动前，必须完成三项关键预处理：

   • 符号数据库增强：下载微软官方的public_symbols.zip，将其导入Ghidra的Symbol Archive。这能让Ghidra识别出ntdll.dll!NtCreateThreadEx等未文档化API的真实签名，避免将sub_405678误判为普通函数。
   • 字符串解密插件集成：针对常见的XOR、RC4字符串混淆，我们编写了一个Ghidra Script（DecryptStrings.java），它能在反编译前扫描.data段，自动识别并解密所有被加密的ASCII/Unicode字符串。一个样本中，该插件成功还原出127个C2域名，而Ghidra默认只显示为byte_4089AB。
   • 控制流图（CFG）导出：使用Ghidra的ExportFunctionGraph功能，将主函数的CFG导出为DOT格式。Claude Code后续会解析此DOT文件，识别出所有可能的分支路径，为动态监控提供“路径覆盖清单”。

2. 语义翻译层（Claude Code）：这是系统的“神经中枢”。Claude Code接收来自Ghidra的三类输入：① 反编译后的C伪代码（.c文件）；② CFG的DOT描述；③ 符号表（.sym文件）。它的输出不是最终代码，而是监控策略模板（Monitoring Policy Template, MPT）。MPT是一个JSON文件，包含：

   { "target_api": ["RegSetValueExW", "CreateProcessW", "connect"], "conditions": [ {"api": "RegSetValueExW", "param_index": 2, "value_contains": "Run"}, {"api": "CreateProcessW", "param_index": 1, "regex": "/c.*svchost\\.exe"}, {"api": "connect", "param_index": 1, "ip_range": "192.168.100.0/24"} ], "context_enrichment": true }

   这个MPT文件是Claude Code与VMware监控代理之间的唯一契约。它不包含任何具体实现细节，只定义“监控什么”和“在什么条件下触发”，把技术实现完全交给下一层。

3. 动态执行层（VMware）：这是系统的“肌肉系统”。VMware虚拟机并非裸机运行，而是预装了我们定制的监控代理（vmwatcher.sys）。该代理通过VMCI接收MPT，并将其编译为实时规则引擎。关键设计点：

   • 双模式监控：用户态监控（通过DLL注入）用于捕获API调用参数；内核态监控（MiniFilter驱动）用于捕获文件/注册表/网络的底层操作。两者通过共享内存（CreateFileMappingW）同步事件，确保CreateProcessW("svchost.exe")和随后的NtWriteFile写入C:\Windows\Temp\payload.bin能被关联为同一行为链。
   • 时间戳对齐：VMware Tools的vmtoolsd.exe服务会定期向Guest OS发送高精度时间戳（精度达微秒级），vmwatcher.sys将所有捕获事件的时间戳与此同步，解决了虚拟机时钟漂移导致的行为时序错乱问题。

4. 行为归因层（反馈闭环）：这是系统的“小脑”。当VMware捕获到一个符合MPT条件的行为（例如RegSetValueExW写入Run键），vmwatcher.sys不仅记录日志，还会触发一个回调：将该行为的完整上下文（调用栈、父进程PID、内存dump片段）打包，通过VMCI回传给Claude Code。Claude Code此时扮演“分析师”角色，它会：

   • 将回传的调用栈与Ghidra中的CFG进行匹配，定位到具体的源码行（例如sub_401230+0x2A）；
   • 分析内存dump片段，识别出被解密的C2域名（如果存在）；
   • 自动生成一份简报（Markdown格式），包含：触发的MPT规则、对应的Ghidra函数地址、捕获的原始参数、建议的IOC（Indicator of Compromise）提取方式。

这个闭环意味着，第一次运行可能只捕获到CreateProcessW，但第二次运行（基于第一次的反馈）就能精准定位到sub_401230中那个隐藏的ShellExecuteW调用，实现“越分析越精准”的进化。

3. 核心组件部署与深度配置详解

3.1 Ghidra：超越默认安装的逆向工程强化配置

Ghidra的安装本身很简单，但让它真正胜任恶意软件分析，需要一系列深度配置。我见过太多人卡在“Ghidra打不开这个PE文件”上，其实问题根本不在Ghidra，而在你的Windows环境。

• Java环境强制要求JDK 17。Ghidra 10.4+版本已弃用对JDK 8/11的支持，但网上大量教程仍停留在旧版本。你必须下载并安装 Adoptium Temurin JDK 17 ，而非Oracle JDK。原因在于：Ghidra的Decompiler依赖java.lang.invoke.MethodHandles的特定实现，Oracle JDK 17在某些Windows 10更新后会出现MethodHandle解析失败，导致反编译窗口一片空白。Temurin JDK则无此问题。安装后，务必在GhidraRun.bat中硬编码JAVA_HOME：

  set JAVA_HOME=C:\Program Files\Eclipse Adoptium\jdk-17.0.1+12-hotspot

• 符号服务器配置是静态分析的生命线。默认的Ghidra符号服务器（http://ghidra-server:13100）只提供基础符号。我们必须接入微软官方符号服务：

  1. 在Ghidra中，打开File → Configure Symbol Servers...
  2. 添加新服务器，URL填入：https://msdl.microsoft.com/download/symbols
  3. 关键步骤：点击Advanced Options，勾选Use HTTPS Proxy（即使你没有代理），并在Proxy Host中填入127.0.0.1，Proxy Port填入8080。这看似矛盾的设置，实则是绕过微软符号服务器的TLS证书验证问题——Ghidra的Java HTTP客户端在处理微软的SHA-256证书链时存在兼容性Bug，强制走本地代理能触发Java的证书缓存机制，从而成功下载ntdll.pdb等关键符号文件。

• 反编译器优化参数调整。Ghidra默认的反编译器（Decompiler）在处理混淆代码时过于保守。我们需要修改Ghidra/Framework/Decompiler/data/decompiler.config：

  # 增加以下参数 decompiler.aggressive=true decompiler.max_iterations=500 decompiler.timeout_ms=30000 # 关键：禁用“安全模式”，允许反编译器尝试更激进的优化 decompiler.safe_mode=false

  这些参数让Ghidra敢于对jmp [eax+0x10]这类间接跳转进行模式识别，将其还原为switch (type) { case 1: ... }结构，大幅提升Claude Code对逻辑的理解准确率。

• 自定义脚本库的建立。Ghidra的Script Manager是我们的“武器库”。除了前述的DecryptStrings.java，还必须预置：

  • FindAntiDebug.java：扫描IsDebuggerPresent、CheckRemoteDebuggerPresent、NtQueryInformationProcess等反调试API的调用，并高亮显示。
  • ExtractStrings.java：不仅提取ASCII，还强制解码UTF-16LE、Base64、Hex编码的字符串。它会遍历整个.rdata段，对每个连续的4字节块尝试Base64解码，成功则标记为潜在C2地址。
  • GenerateCFG.java：自动为选定函数生成CFG DOT文件，并保存到/tmp/ghidra_cfg/目录，供Claude Code读取。

注意：所有自定义脚本必须放在Ghidra/Extensions/目录下，并在Ghidra/Extensions/extension.properties中声明。否则Ghidra启动时不会加载它们，导致Claude Code接收不到关键的CFG数据。

3.2 VMware：从虚拟机安装到“行为显微镜”的蜕变

VMware Workstation Pro的安装教程满天飞，但99%的教程教你怎么装系统，却没人告诉你怎么把它变成一个可靠的分析沙箱。这里的关键不是“能不能运行”，而是“能不能精确、稳定、可重现地捕获”。

• 虚拟机硬件配置的硬性标准：

  • CPU：必须启用Virtualize Intel VT-x/EPT或Virtualize AMD-V/RVI。这是VMCI设备正常工作的前提。在VMware设置中，Processor → Virtualization Engine里，两个复选框必须全勾。
  • 内存：最低4GB，但强烈建议8GB。原因在于：vmwatcher.sys的MiniFilter驱动需要预留1GB内存用于事件缓冲区。如果内存不足，它会丢弃高频事件（如大量NtWriteFile调用），导致行为链断裂。
  • 硬盘：必须使用SCSI控制器（而非SATA），且磁盘模式为Thin Provisioned。SCSI控制器支持VMCI的DMA传输，而SATA控制器不支持。Thin Provisioned则确保虚拟机快照（Snapshot）能快速创建，这是分析多阶段恶意软件（如先下载loader，再下载payload）的必备操作。

• Guest OS（Windows 10/11）的“无痕化”改造：目标是让恶意软件无法感知自己在虚拟机中运行。

  • 禁用所有遥测服务：通过PowerShell执行：

    Stop-Service DiagTrack, dmwappushservice; Set-Service DiagTrack, dmwappushservice -StartupType Disabled

  • 删除VMware Tools的“指纹”：VMware Tools安装后会在注册表HKLM\SOFTWARE\VMware, Inc.\VMware Tools下留下明显标识。我们编写了一个clean_vmware_reg.ps1脚本，在每次快照还原后自动运行，删除该键及其所有子项。
  • 网络适配器伪装：将VMware的网络适配器MAC地址修改为常见物理网卡厂商（如Intel80:EE:73:XX:XX:XX），并在Guest OS中禁用Network Location Awareness服务。这能有效规避那些检查GetAdaptersInfo返回的MAC前缀的反虚拟机技术。

• vmwatcher.sys监控代理的部署与验证：

  1. 将vmwatcher.sys（驱动）和vmwatcher.exe（用户态配置器）复制到Guest OS的C:\Windows\System32\drivers\和C:\Windows\System32\目录。
  2. 以管理员身份运行vmwatcher.exe install，它会调用sc create vmwatcher binPath= "C:\Windows\System32\drivers\vmwatcher.sys" type= kernel start= auto注册服务。
  3. 最关键的验证步骤：运行vmwatcher.exe test。它会向VMCI发送一个测试指令，vmwatcher.sys收到后，会主动触发一次CreateProcessW("notepad.exe")，并捕获其全部参数。如果控制台输出TEST PASSED: Created notepad.exe with cmd line 'notepad.exe'，说明整个VMCI通信链路畅通。如果超时，则需检查VMware设置中的VMCI是否启用，以及Guest OS的VMCI服务（vmci）是否正在运行。

3.3 Claude Code：从桌面版到分析流水线的“中枢神经”配置

Claude Code的安装本身不难，但让它成为分析流水线的中枢，需要突破其默认的“单文件编辑器”定位。

• 环境隔离与依赖管理：Claude Code桌面版内置的Python解释器（Python 3.9）无法直接调用Ghidra的Java API。我们必须建立一个独立的Python环境：

  1. 安装conda，创建专用环境：conda create -n claude-malware python=3.9
  2. 激活环境：conda activate claude-malware
  3. 安装关键包：pip install jpype1 ghidra_bridge pyvmomi
     • jpype1：用于在Python中启动JVM，加载Ghidra的Java类。
     • ghidra_bridge：这是一个开源库，它在Ghidra中启动一个WebSocket服务器，允许外部Python脚本通过JSON-RPC调用Ghidra API。这是Claude Code与Ghidra通信的桥梁。
     • pyvmomi：VMware vSphere的Python SDK，用于远程管理VMware虚拟机（如启动、快照、获取日志）。

• Claude Code的Prompt Engineering核心技巧：Claude Code不是“问什么答什么”，而是需要你给它一个清晰的“角色设定”和“输出契约”。我们在Claude Code的Settings中，为这个项目创建了一个专属的System Prompt：

  You are a senior malware analyst specializing in automated reverse engineering. Your task is to generate precise, minimal, and executable monitoring policy templates (MPT) based on Ghidra's decompiled C code and CFG data. You MUST: 1. NEVER generate generic Python code. Output ONLY valid JSON matching the MPT schema. 2. Prioritize API calls that modify persistence (RegSetValueExW), execute code (CreateProcessW, ShellExecuteW), or establish network connections (connect, WSAConnect). 3. If the decompiled code contains obfuscated strings, use the provided CFG to infer their likely purpose (e.g., a XOR loop followed by a connect call strongly suggests a C2 address). 4. ALWAYS include "context_enrichment": true in the output, as the downstream vmwatcher.sys requires full call stack data.

  这个System Prompt将Claude Code从一个通用代码助手，转变为一个严格遵循MPT规范的“策略生成器”。没有它，Claude Code可能会输出一段漂亮的、但完全不符合vmwatcher.sys解析规则的Python代码。

• 与Ghidra的实时桥接：启动Ghidra后，必须手动运行ghidra_bridge的Server脚本（ghidra_bridge_server.py），它会在localhost:13100启动一个WebSocket服务。然后，在Claude Code的Python终端中，执行：

  import ghidra_bridge bridge = ghidra_bridge.GhidraBridge() ghidra = bridge.get_ghidra() # 现在可以调用ghidra.getProgram()等API

  这一步建立了Claude Code与Ghidra的实时数据通道。当Claude Code需要获取某个函数的CFG时，它不再读取静态的DOT文件，而是直接调用ghidra.getFunctionGraph()，确保数据永远是最新的。

4. 实操全流程：从一个未知样本到IOC提取的完整闭环

4.1 样本预处理与Ghidra深度分析（耗时约8-15分钟）

我们以一个真实的、名为loader.exe的样本为例。它是一个典型的“dropper”，体积仅234KB，但具有多层混淆。

1. 初始加载与架构识别：将loader.exe拖入Ghidra，选择x86架构（即使文件头显示为x64，也要先试x86，因为很多混淆器会伪造PE头）。Ghidra会自动分析入口点（EP）。我们发现EP指向0x401000，但该地址处是一段pushad; popad; jmp [esi+0x10]的跳转。这表明存在IAT（Import Address Table）混淆。

2. IAT修复与API识别：运行FindIAT.java脚本（我们预置的脚本之一）。它扫描.text段，寻找call [xxxx]模式，并与kernel32.dll、advapi32.dll等常用DLL的导出表比对。脚本成功识别出0x402000处的IAT，并将其重命名为IAT_kernel32。此时，Ghidra能正确解析出call dword ptr [IAT_kernel32+0x10]即为CreateProcessW。

3. 字符串解密与C2定位：运行DecryptStrings.java。它在.data段发现一个长度为256字节的数组，其内容为0x41, 0x42, 0x43, ...（ASCII A-Z的循环）。脚本自动应用XOR 0xFF解密，得到一串Base64字符串：aHR0cHM6Ly9jb250cm9sLmV4YW1wbGUuY29tOjQ0Mw==。解码后为https://control.example.com:443——这就是C2地址。

4. CFG生成与关键路径锁定：右键点击main函数，选择Generate Function Graph。Ghidra输出main.dot。我们观察到，从入口点出发，有一条路径经过sub_401230，然后调用sub_401567，最后到达CreateProcessW。sub_401567的反编译代码显示：

void sub_401567(void) { HANDLE hFile; DWORD dwSize; char *buffer; hFile = CreateFileA("C:\\Windows\\Temp\\payload.bin", GENERIC_READ, 0, 0, OPEN_EXISTING, 0, 0); dwSize = GetFileSize(hFile, 0); buffer = (char *)VirtualAlloc(0, dwSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE); ReadFile(hFile, buffer, dwSize, &dwSize, 0); // 此处有一个巨大的XOR解密循环 for (int i = 0; i < dwSize; i++) { buffer[i] ^= 0x5A; } // 解密后，buffer指向一个完整的PE文件 ((void(*)())buffer)(); }

这清晰地揭示了其“释放并执行payload”的行为。

4.2 Claude Code生成MPT与VMware策略部署（耗时约2分钟）

将上述分析结果（main.c伪代码、main.dot、IAT_kernel32符号表）作为输入，提交给Claude Code。

• Claude Code的输出（MPT.json）：

  { "target_api": ["CreateFileA", "ReadFile", "VirtualAlloc", "CreateProcessW"], "conditions": [ {"api": "CreateFileA", "param_index": 0, "value_contains": "Temp\\payload.bin"}, {"api": "ReadFile", "param_index": 1, "size_gt": 10240}, {"api": "VirtualAlloc", "param_index": 3, "value_eq": "PAGE_EXECUTE_READWRITE"}, {"api": "CreateProcessW", "param_index": 1, "regex": ".*payload\\.bin.*"} ], "context_enrichment": true }

• 部署到VMware：

  1. 将MPT.json文件通过VMware的Shared Folders功能，复制到Guest OS的C:\vmwatcher\policy\目录。
  2. 在Guest OS中，以管理员身份运行vmwatcher.exe load_policy C:\vmwatcher\policy\MPT.json。vmwatcher.sys会解析该文件，并将四条规则编译进其内核态规则引擎。
  3. 运行vmwatcher.exe start_monitoring，开始监听。

4.3 动态执行与行为捕获（耗时约30秒至数分钟）

将loader.exe放入Guest OS的C:\temp\目录，双击运行。

• vmwatcher.sys的实时捕获日志（C:\vmwatcher\logs\capture.log）：

  [2023-10-15 14:22:31.123456] CREATEFILEA: "C:\Windows\Temp\payload.bin" -> HANDLE=0x12345678 [2023-10-15 14:22:31.123789] READFILE: Buffer=0x7ff8a1230000, Size=142857, Handle=0x12345678 [2023-10-15 14:22:31.124012] VIRTUALALLOC: Addr=0x7ff8b2340000, Size=142857, Protect=PAGE_EXECUTE_READWRITE [2023-10-15 14:22:31.124234] CREATEPROCESSW: CmdLine="C:\Windows\Temp\payload.bin" [2023-10-15 14:22:31.124567] CONTEXT: StackTrace=[0x7ff8b2340000, 0x7ff8a1230000, 0x7ff8a122f000], ParentPID=1234

• 关键洞察：日志显示，payload.bin被读取后，VirtualAlloc分配的内存地址0x7ff8b2340000，正是CreateProcessW执行时的入口点。这证实了sub_401567中((void(*)())buffer)();的调用逻辑。vmwatcher.sys捕获的StackTrace包含了完整的调用栈，我们可以据此在Ghidra中精确定位到sub_401567+0x8A这一行。

4.4 IOC提取与报告生成（耗时约1分钟）

vmwatcher.exe在捕获到CREATEPROCESSW事件后，自动触发回调，将payload.bin的内存dump（C:\vmwatcher\dumps\payload_20231015_142231.bin）和调用栈信息打包，通过VMCI回传给Claude Code。

• Claude Code的自动分析：

  1. 加载payload_20231015_142231.bin，用file命令识别其为PE32+ executable (console) x86-64。
  2. 调用ghidra_bridge，在Ghidra中自动打开该dump文件，并运行FindAntiDebug.java。
  3. 发现payload.bin中存在NtQueryInformationProcess调用，其ProcessInformationClass参数为ProcessDebugPort（值为0x7），这是典型的反调试检查。

• 自动生成的Markdown简报（IOC_Report.md）：

  ## IOC Extraction Report for loader.exe ### Primary IOCs - **File Hash (SHA256)**: `a1b2c3d4...` (loader.exe) - **Dropped File**: `C:\Windows\Temp\payload.bin` (SHA256: `e5f6g7h8...`) - **C2 Domain**: `control.example.com` (from decrypted string) - **C2 IP**: `192.0.2.100` (resolved from domain, confirmed via DNS log) ### Behavioral IOCs - **Persistence**: Writes to `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run` (detected in sub_401230) - **Execution**: `CreateProcessW("C:\Windows\Temp\payload.bin")` with `PAGE_EXECUTE_READWRITE` memory allocation - **Anti-Analysis**: Checks `ProcessDebugPort` via `NtQueryInformationProcess` ### Recommended Actions 1. Block `control.example.com` at firewall/DNS level. 2. Hunt for files named `payload.bin` in `C:\Windows\Temp\` across all endpoints. 3. Alert on processes allocating `PAGE_EXECUTE_READWRITE` memory and immediately calling `CreateProcessW`.

这份报告不是人工编写的，而是Claude Code根据Ghidra的静态分析和VMware的动态捕获，自动生成的、可直接交付给SOC团队的战术情报。

5. 常见问题排查与独家避坑指南

5.1 Ghidra相关问题：为什么我的反编译结果全是undefined4？

这是Ghidra最经典的“哑巴”症状，根源几乎总是符号缺失。当你看到undefined4 FUN_00401230(undefined4 param_1)时，Ghidra根本不知道param_1是什么类型。解决方案：

• 强制类型推断：在反编译窗口，右键点击FUN_00401230，选择Edit Function Signature。在弹出的对话框中，手动将param_1的类型改为LPCSTR（如果它是字符串）或HANDLE（如果它是句柄）。Ghidra会基于这个提示，自动推断后续所有调用点的参数类型。
• 批量符号应用：如果整个样本都依赖kernel32.dll，可以在Symbol Tree窗口中，右键kernel32.dll，选择Apply Library。Ghidra会将微软官方的kernel32.pdb符号应用到所有匹配的函数上，CreateProcessW等函数名会立刻显示出来，不再是FUN_00401230。

5.2 VMware相关问题：vmwatcher.sys启动失败，报错Error 0x00000002

这个错误代码0x2在Windows中代表ERROR_FILE_NOT_FOUND，但它在这里的真正含义是驱动签名验证失败。Windows 10/11默认启用了驱动程序强制签名（Driver Signature Enforcement），而我们自研的vmwatcher.sys是未签名的。

• 临时解决方案（仅限分析环境）：重启VMware Guest OS，在启动时按F8进入高级启动选项，选择Disable driver signature enforcement。这是最快速的验证方法。
• 永久解决方案（生产环境）：为vmwatcher.sys申请微软的WHQL认证，或使用signtool.exe配合有效的代码签名证书进行签名。命令如下：

  signtool sign /a /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 vmwatcher.sys

  注意：/tr参数指定时间戳服务器，/td指定哈希算法，缺一不可，否则Windows会拒绝加载。

5.3 Claude Code相关问题：生成的MPT.json被vmwatcher