上篇中，通过对恶意样本的TAC告警分析，以及借助第三方平台进行扩展分析，给大家展示了一个恶意样本有可能的行为，有可能的来源等。下篇，我们来看一下通过手工分析的部分。 恶意样本分析的上篇，我们通过对恶意样本的TAC告警分析，以及借助第三方平台进行扩展分析，让大家了解，一个恶意样本有可能的行为，并尝试找到样本来源。下篇，我们来看一下通过手工分析恶意样本的行为。
该样本漏洞为CVE-2015-5119，而不是病毒引擎所报告的5221。该漏洞主要是利用了valueOf导致的漏洞，支持多个平台环境，采用vector exploit技术去实现信息泄露，从而绕过ASLR，再调用virtualProtect去赋予shellcode可执行权限，以此绕过DEP保护。可以导致感染主机安装木马。
1. 首先创建loc4 Array数组并填充
从代码中可以看到，声明了变量loc1=90,数组loc4,并将数组的各元素赋值，数组的90个元素是MyClass2对象和ByteArray类型数组交替出现，并且每分配两个MyClass2元素才会分配一次BtyeArray类型数组，当循环结束后，数组的赋值完成。
2. 代码执行
在第一次循环时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：
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 ，重新使用已经释放的内存。
并且valueOf的返回值0x40被写入：
也就是vector对象的长度以及被修改成0x400003f0。
由于其长度值被更改，允许读取到更大内存空间的数据，从而获取需要调用的函数地址，绕过ASLR保护。根据不同的系统平台，选择不同的shellcode代码执行。
内存搜索的方式也是暴力搜索“MZ”PE头，再去解析PE文件格式，从导入表中的找到kernel32.dll，再从其函数名列表里找到VirtualProtect函数，进而找到对应的函数地址进行调用。
3. Shellcode漏洞利用代码执行
最后执行ShellWin32.Exec函数，通过内存搜索找到VirtualProtect函数地址，将包含执行恶意软件代码的shellcode设置为可执行权限，以此绕过DEP保护，并用指向shellcode的指针替换payload对应的JIT函数指针，当调用Payload.call 时则执行的正是shellcode。
如果执行shellcode成功，也就意味着恶意样本完成了入侵，在目标主机上安装了木马程序，为攻击者下一步攻击做准备。
以上就是对恶意样本的人工分析，非常感谢研究院大拿刘业欣，此处有个大写加粗的赞！
特别提醒
随TAC产品的销售，我们提供恶意样本的分析和清除服务，分析恶意样本的行为，评估造成的危害等。为用户提供扩展的应急响应服务。
如果您需要了解更多内容，可以
加入QQ群：486207500、570982169
直接询问：010-68438880-8669