Spartan Exploit Kit分析

之前都是调试flash的漏洞，相关的样本接触较少，碰巧看到一篇不错的分析，尝试了一下，留个记录。

调试flasher样本一般建议使用调试版的flash player，在调试版本下可以输出swf文件运行时的相关日志，便于进行相关的分析，安装之后会在家目录（C:User<your name>mm.cfg）生成该文件（早期的flash调试版本不会生成该文件，需要手动生成）。

文件中包含以下配置选项，手动生成的话红色框中的选项为必选项，用于告诉flash生成错误日志及trace日志（对应的日志文件保存在C:Users<your name>AppDataRoamingMacromediaFlash PlayerLogs目录下）。

 

该样本在运行之后含有多层解密（以下以此分析）。

Sample1

通过JPEXS反编译之后，该样本只有两个主要的类

1. Base64 传统的base64算法
2. MainTimeline 样本的功能类

MainTimeline的入口函数frame1中首先对组合出第一个请求地址，当请求结束，调用TteNDbdn函数。

 

通过trace可以获取该请求的地址

请求之后会报错，因为该cc已经失效，好处是该样本通信的过程记录在fiddler的包中，我们将这次请求的页面保存到本地，在fiddler中设置对这两个地址的自动回复，回复的文件使用本地保存好的两个页面。

http://zaleimneviskivgorlo.website/crossdomain.xml

http://zaleimneviskivgorlo.website/XVsiAHhqXHV1TT8nPEB_Tgc.xml

 

此时再运行该样本，trace记录如下，输出的地址如下：

 

现在回到样本的分析，对应请求完成后启用函数TteNDbdn，该函数会解析其中返回的xml文件，获取两个参数，并完成解密，之后解密的内容通过addChlid函数加载起来，这个地方很容易就明白该解密的内容应该就是接下来的运行样本。

 

该xml及对应的两个变量如下：

这个地方可能会想到通过trace的方式直接打印出该解密内容，通过上面给出的代码是不行的，因为此处的_loc4_并不是一个普通的变量或常量，其类型为一个对象。

 

为了获取第二层的样本，可以通过python脚本手动解密该xml文件中包含的sample2，这个地方注意读取的时候不要使用python中的ET.ElmentTree的方式去读取，至少我在通过该方式读取的数值解密之后，JPEXS无法反编译。

可以使用以下代码：

解密之后为标准的swf文件格式。

 

Sample2

反编译之后的主方法如下所示：其中比较重要的有yYJREHXgUy，和TPbsJhbquQh

 

首先是函数yYJREHXgUy，运行之后实际上是将字符串”G5GH……..”直接附加到exec之后，并以LoaderContext的类型返回，这时很容易想到该返回的结果有可能是作为一个参数。

 

然后是函数TPbsJhbquQh，该函数会调用dMbRyCRIPq进行实际的解密，这个地方的param1，_loc3_值得关注。

 

通过trace直接获取这两个参数的数值。

 

对应的值如下，可以看到这两个参数分别为一个长的加密序列content，和一个秘钥key:4d07059cb79e3545dcf7f0cf5bc33baa。

可以发现加密序列content实际就是sample2中的二进制数据文件。

 

使用之前的脚本即可解密出sample3。

Sample3

通过JPEXS对该样本进行反编译，如下图所示，可以看到相比于前两个样本该样本中有多个类。

 

加载运行该swf文件，程序报错，错误出现在class_7中。

 

直接查看class_7,其代码会检测exec之后的参数是否为空，而之前直接加载sample3并不是通过样本直接运行的，所以没有传送参数，因此报错。

此时直接修改函数，把相关的校验部分去掉之后，替换成右侧的代码，可以看到最后会调用到class_1.init()函数

 

函数class_1.init中首先会检测当前版本是否小于19.207，只有小于该版本才往后执行，函数之后值得关注的有asfsgrggvxyb，_loc_4,及extLoaded函数

 

从以上的代码可以得知，_loc4_应该是一个json文件，如下图所示通过trace函数直接获取该参数。

 

不出所料，此处为一个json文件，在json中的vari42即为对应漏洞利用代码（此处为了便于显示将vari42的值简略了）

之后解析好的json内容会被赋值给变量§_-q§，然后获取其中的vari42域，即json中的加密字符串，作为class_11.method72的参数，实际上，该函数只是简单的base64解码操作，同样通过trace获取该解密的结果。

 

运行样本，可以看到输出的结果如下，一个标准的swf文件，这个就是漏洞利用的swf文件了。

 

由于之前已经获取了对应的json文件，这里直接通过pyton脚本做一下处理就能获取对应的漏洞利用代码。

 

如下图所示，CVE-2015-7645漏洞的利用代码，该漏洞为一个writeExternal对象的类型混淆漏洞。

 

回到之前的init函数，漏洞利用函数解密加载之后，会调用exloaded函数，如下图所示：

 

此时该类下的EXP_try通过JPEXS反编译的效果并不好，可以尝试换AS3 Sorcerer（as3有多个反编译工具，可以交替使用，JPEXS的好处在于打trace很方便）。

 

进入class_4.EXP_try函数，在该函数中会调用到Load函数。

 

在load中完成shellcode的解码，最后通过_safe_Str_10类的函数exec执行shellcode，此处的shellcode除了解密出来的部分外还包括asfsgrggvxvb中返回的数值（该值来之于sample2中作为sample3的启动参数）。

 

进入exec函数可以看到flash中经典的获取virtualprotect函数地址，分配可以执行内存，并执行shellcode的操作。

 

在以下两图中通过修改jit字节码，将对应的shellcode替换成一系列的CC中断指令。

  

运行之后可以看到，flash player在windgb中确实中断下来了。

 

编写loader

此时可以通过修改sample3的部分代码，实现仅仅通过一个html页面加载该样本的功能，这个地方主要需要注意的是shellcode的问题，通过上面的分析可以发现，最终sample3漏洞触发之后使用到的shellcode来自两部分。

1. 来自sample2启动sample3时传入的参数exec
2. load中硬编码的shellcode2

传入的exec参数会在asfsgrggvavb中进行处理，通过分析我们知道该函数仅仅是将传入的数值附加到”exec”之后，该功能可以在html页面中直接实现，因此通过修改字节码直接将该函数的功能去掉，以方便在html中增加我们的shellcode接口。

 

我们的shellcode通过html传入，因此直接把sample3中load中硬编码的shellcode2删除。

 

通过一个html加载运行。

 

之后点击之后直接运行。

 

总流程

整个kit的运行过程如下所示:

 

 参考

http://vulnerablespace.blogspot.co.uk/2016/04/malware-analysing-and-repurposing.html