TAC检测恶意样本扩展分析实例(下篇)

上篇中,通过对恶意样本的TAC告警分析,以及借助第三方平台进行扩展分析,给大家展示了一个恶意样本有可能的行为,有可能的来源等。下篇,我们来看一下通过手工分析的部分。 恶意样本分析的上篇,我们通过对恶意样本的TAC告警分析,以及借助第三方平台进行扩展分析,让大家了解,一个恶意样本有可能的行为,并尝试找到样本来源。下篇,我们来看一下通过手工分析恶意样本的行为。

该样本漏洞为CVE-2015-5119,而不是病毒引擎所报告的5221。该漏洞主要是利用了valueOf导致的漏洞,支持多个平台环境,采用vector exploit技术去实现信息泄露,从而绕过ASLR,再调用virtualProtect去赋予shellcode可执行权限,以此绕过DEP保护。可以导致感染主机安装木马。

1. 首先创建loc4 Array数组并填充

loc4_ Array

从代码中可以看到,声明了变量loc1=90,数组loc4,并将数组的各元素赋值,数组的90个元素是MyClass2对象和ByteArray类型数组交替出现,并且每分配两个MyClass2元素才会分配一次BtyeArray类型数组,当循环结束后,数组的赋值完成。

2. 代码执行

代码1

在第一次循环时i_loc7_=85,通过调试结果可知loc4 [85]元素的类型是ByteArray类型,其大小是0xfa0,那么ba=_loc4 [i]也就是将loc4 [85]赋给_ba,_ba:ByteArray就是原始的ByteArray。同时将一个新的Myclass类赋给_ba的第四个字节_ba3。由于ByteArray的元素类型是Byte,当把Class类赋值给ByteArray3时,AVM会试图将其转化为Byte,此时Class的valueOf函数将被调用,也就是说赋值引发调用valueOf:

代码2

ValueOf函数首先对gc数组赋值,该数组在TryExp1函数中通过_gc.push(a)加入a数组元素,又在valueof函数中通过_gc.push(_va)加入了_va数组,_va数组又包含了5个Vector对象,_gc[0]= _loc4, _gc1=_va。

在valueOf函数中,最关键的是_ba.length = 4352(0x1100);它更改了ByteArray的长度,将其设置成为0x1100,这个操作将会触发_ba.ByteArray内部buffer的重新分配,生成一个大小为0x1100的新的ByteArray对象,旧的buffer(大小为0xfa0)将会被释放。

紧接着使用相同大小的vector在重分配的过程中占位原始的_ba.ByteArray ,重新使用已经释放的内存。

代码3

并且valueOf的返回值0x40被写入:

代码4

也就是vector对象的长度以及被修改成0x400003f0。

由于其长度值被更改,允许读取到更大内存空间的数据,从而获取需要调用的函数地址,绕过ASLR保护。根据不同的系统平台,选择不同的shellcode代码执行。

代码5

内存搜索的方式也是暴力搜索“MZ”PE头,再去解析PE文件格式,从导入表中的找到kernel32.dll,再从其函数名列表里找到VirtualProtect函数,进而找到对应的函数地址进行调用。

代码6

3. Shellcode漏洞利用代码执行

最后执行ShellWin32.Exec函数,通过内存搜索找到VirtualProtect函数地址,将包含执行恶意软件代码的shellcode设置为可执行权限,以此绕过DEP保护,并用指向shellcode的指针替换payload对应的JIT函数指针,当调用Payload.call 时则执行的正是shellcode。

代码7

如果执行shellcode成功,也就意味着恶意样本完成了入侵,在目标主机上安装了木马程序,为攻击者下一步攻击做准备。

以上就是对恶意样本的人工分析,非常感谢研究院大拿刘业欣,此处有个大写加粗的赞!

特别提醒

随TAC产品的销售,我们提供恶意样本的分析和清除服务,分析恶意样本的行为,评估造成的危害等。为用户提供扩展的应急响应服务。

TAC

如果您需要了解更多内容,可以
加入QQ群:486207500、570982169
直接询问:010-68438880-8669

发表评论