样本速览
哈希：MD5 05C137D8E79CE59ED6E4B7CD78E5B8A2
SHA256：5A31C77293AF2920D7020D5D0236691ADCEA2C57C2716658CE118A5CBA9D4913
一眼看去就是一个普通的doc文档，很容易掉以轻心。
文件头分析
拿到样本第一步，永远不看拓展名。
使用010编辑器打开发现开头明显的rtf字段
正常doc文档
正常docx文档
RTF文件格式
我们新建一个文档，然后写入RTF代码，然后windows自动识别可以使用word打开，图标也变了样子，查看属性可以看到是RTF格式，双机可以正常解析。它和 Markdown 是同一个思路(比 Markdown 早了 17 年)：纯文本描述格式，只在“富文本”这个赛道——比 .txt 多了字体、颜色、表格、图片，所以叫“富”文本。
此时我们把后缀换成docy依旧可以正常解析。
OLE技术
我对OLE的理解是比如word里面的插入对象，可以插入一个文档，一个公式，可以是任何数据类型，然后“OLE服务器”承担对这些对象的打开或者解析，比如我们本次分析的样本，就是文档中插入一个公式，然后打开文档就会使用公式编辑器（OLE服务器）进行打开。
为什么偏偏是RTF
在我们的例子中，写一个rtf文件，很快就完成了，想改哪里改哪里，真的构造doc的话，需要正确构造好多东西，所以rtf成本极低，改一个字节就是不同的哈希，靠特征码匹配每次都要重新认识。其次就是我们在上面做的rtf文件的实验，看到有好多/b类似等等的指令，熟悉html或者md文档的朋友们很容易看出来这是一个加粗，其实还有很多的指令，如下图，这些都是给word程序看的，word看到自动解析执行。比如这个\objupdate，是RTF文件格式特有的指令，打开文档时自动更新此对象，也就是如果插入一个公式的话，打开文档，就会自动更新对象，也就是直接打开（公式编辑器）OLE服务器进行执行命令。
| 控制字 作用 类别 \b \i \par \fs24 加粗/斜体/换段/字号 排版开关 \object “此处开始一个 OLE 对象” 对象家族的总开关 \objemb / \objlink / \objautlink 嵌入 / 链接 / 自动更新链接 对象类型 \objocx 这是 ActiveX 控件型对象 对象类型 \objclass 对象类名(如 Equation.3) 身份登记 \objdata 对象数据(十六进制)从此开始 数据体 \objupdate 打开文档时自动更新此对象 装载指令 {\result {\pict…}} 对象的缓存预览图 显示缓存 |
|---|
从这个地方我们也可以了解到RTF这种格式的文档可以面临两个攻击面，一个就是解析文档的程序在解析的时候有没有安全问题，第二个就是OLE服务器有没有安全问题。
动态样本分析
双击，process monitor监控，并且开启SystemInformer看有无可疑进程，发现毫无东西，怀疑样本过老，环境不适配，放弃这一波，根据md5去vs或者any run可以拿到分析报告获取ioc等一些详细进程链信息。结合rtf文档格式翻到了cve漏洞，直接分析cve漏洞。
POC漏洞点分析
我们使用https://github.com/Ridter/CVE-2017-11882的poc，是会弹出一个计算器，运行使用process monitor进行监控，查看进程树，发现计算器是由EQNEDT32.EXE运行的，那么漏洞点就出现在这个地方。
使用x32dbg进行调试该程序，在x32dbg下方输入下方命令
1 | init "C:\Program Files\Common Files\Microsoft Shared\EQUATION\EQNEDT32.EXE", "-Embedding" |
第 1 次停在 System Breakpoint(系统断点)
第 2 次停在 Entry Breakpoint
第 3 次 F9 之后程序自由运行，安静待命——左下角状态栏显示“运行中”就对了
我们下断点
1 | bp kernel32.WinExec |
双击rtf-POC文件。
查看上一级返回地址找寻是谁进行的调用。
1 | 0019ED84 004218E4 返回到 eqnedt32.FMDFontListEnum+650 自 eqnedt32.EqnFrameWinProc+2AC7 |
可以发现是这个函数的返回地址
那我们去ida看一下这个函数的定义,看到这个函数里面也调用了其他的函数，我们对这个4115A7进行下断点，然后跟着走一步一步调试，看看是哪一步的问题
重新运行poc，我们观察栈的情况，当我们摁F7的时候，18E4会被压入栈，就是这个call 15A7的返回地址，并且此时看到了160F的调用，不出意外的话，我们调用160F的时候，也要把他下一行压入栈，也就是15D8
结合ida来看这个函数的话，发现是我们可以控制的Substr参数也就是自定义长度和内容的字符串没做限制可以写入string[36]这个数组。
在x32dbg断点，我们拿到edi就是目标数组地址，拿到当前ebp地址，esi就是源地址
然后拿到ecx为0c，就是12轮，一轮4字节，要复制48个字节，也就是源地址的那三行，实时观察内存和栈的情况
1 | 高地址 |
可以看到返回地址已经被覆盖，一路运行到返回，注意到esp+4其实就是cmd这些命令，天然的参数，然后ret跳转到call winexec，即可执行命令
调试样本分析
我们直接断在15A7，然后直接跳转到跳转160F。
直接断到漏洞触发点，相同触发点，相同地址，但是源数据也就是恶意数据是加密的，我们依旧
直接运行栈溢出覆盖返回地址，然后直接运行到函数返回
接下来就是shellcode的一些骚操作了，环境不适配一直报错，分析戛然而止，其实跳转过去就是一级shellcode，只是做一个跳转，跳转到二级shellcode，这个二级shellcode是写入到文档里面的一个地址。找了一个平替，大家可以观看看雪的一篇文章，有下文。https://bbs.kanxue.com/thread-281592-1.htm
总结
好久不输出分析文章手生了，分析过程中一点一点找回记忆。在htb中随便找了一个钓鱼分析的靶场，下载下来浅浅分析了一下，没有涉及怎么主动挖掘类似栈溢出漏洞，仅涉及更改文档后缀钓鱼手法，word历史栈溢出漏洞，ole相关知识，rtf相关知识。
参考链接
https://app.hackthebox.com/sherlocks/Malicious_Doc