WannaCry勒索软件中，利用了NSA泄露工具中的“永恒之蓝”漏洞，关于这个漏洞，之前已经有一些分析，在我看的文章中，http://blogs.360.cn/360safe/2017/04/17/nsa-eternalblue-smb/说得最详细，该文章中针对win7 32位的系统的漏洞触发过程进行了分析。
但是在整个网络上，我没有看到关于64位系统的分析，因此我在该文章的基础上，对win7 64位的触发，以及触发后的shellcode的行为进行了分析整理成此文。
其中若有疏漏，还请大家指教。最后感谢武汉科锐,感谢钱老师的悉心教学,钱老师严谨的治学作风和渊博的知识深深的影响着我，使我受益终身。
搭建测试环境
因为样本的原有行为，是随机产生IP地址，并对目标进行发包。这非常不方便我们测试。因此，需要先在特定的位置断下，将IP地址改为我们的测试目标，并拍快照记录。
具体步骤如下：
1. 在0x00407982处下断，该处为拼接IP字符串，在此处将该字符串修改为自己的测试目标值。
2. 单步（如果不单步可能会因为多线程的原因造成测试不成功，因此推荐单步）至下方的线程创建函数，并在该线程回调处下断点。
3. 在上一步的线程回调函数中，有两处关键点，一处为该样本的第一波发包攻击，攻击结果为:在远程电脑上安装一个后门；第二处为第二波发包攻击，攻击结果为：利用第一波攻击安装的后门，在远程电脑上的系统进程中注入一个dll。他们的调用位置如下图所示：
漏洞的原理
在Srv.sys中的SrvOs2FeaListToNt函数中，会有以下调用关系：
SrvOs2FeaListToNt call SrvOs2FeaListSizeToNt call SrvOs2FeaToNt
其中在SrvOs2FeaListSizeToNt中因为有一个DWORD*转WORD*并赋值的bug，造成在SrvOs2FeaListToNt的一个循环中，SrvOs2FeaToNt被调用的次数会多于预期，而造成SrvOs2FeaToNt中的一个memmove拷贝越界。
可以看到，运行到下图时，对大小为0x11000：
通过!pool指令查看：
而实际运行时：
不过，越界覆盖后，最终pool中的地址+0xa8处的数据，会作为一个指针被当作数据接受缓冲区，这是为什么，这其中的原理我没有完全搞明白，还请熟悉的朋友指教。
定位第一轮发包的shellcode触发点
尝试定位shellcode,要知道一个前提,这在其它报告中也已经提到,那就是
该样本的第一次发包，会安装一个后门，该后门的实现方式是在srv模块中，挂钩SrvTransaction2DispatchTable表中的一个表项，可以通过命令.
我之后就是利用这一点,来检验自己的测试机是否已经被触发漏洞,并一步步定位到触发点的(见下文分析).
kd> dps srv!SrvTransaction2DispatchTable查看：
挂钩前：
</pre> fffff880`0301e760 fffff880`03088780 srv!SrvSmbOpen2 fffff880`0301e768 fffff880`0304fb20 srv!SrvSmbFindFirst2 fffff880`0301e770 fffff880`03085f40 srv!SrvSmbFindNext2 fffff880`0301e778 fffff880`03051650 srv!SrvSmbQueryFsInformation fffff880`0301e780 fffff880`0307ad20 srv!SrvSmbSetFsInformation fffff880`0301e788 fffff880`0304f670 srv!SrvSmbQueryPathInformation fffff880`0301e790 fffff880`03088cb0 srv!SrvSmbSetPathInformation fffff880`0301e798 fffff880`0304d420 srv!SrvSmbQueryFileInformation fffff880`0301e7a0 fffff880`0304e080 srv!SrvSmbSetFileInformation fffff880`0301e7a8 fffff880`0306f660 srv!SrvSmbFsctl fffff880`0301e7b0 fffff880`03088ae0 srv!SrvSmbIoctl2 fffff880`0301e7b8 fffff880`0306f660 srv!SrvSmbFsctl fffff880`0301e7c0 fffff880`0306f660 srv!SrvSmbFsctl fffff880`0301e7c8 fffff880`0307b4f0 srv!SrvSmbCreateDirectory2 fffff880`0301e7d0 fffff880`0306f460 srv!SrvTransactionNotImplemented fffff880`0301e7d8 fffff880`0306f460 srv!SrvTransactionNotImplemented <pre>
挂钩后：
</pre> fffff880`0301e760 fffff880`03088780 srv!SrvSmbOpen2 fffff880`0301e768 fffff880`0304fb20 srv!SrvSmbFindFirst2 fffff880`0301e770 fffff880`03085f40 srv!SrvSmbFindNext2 fffff880`0301e778 fffff880`03051650 srv!SrvSmbQueryFsInformation fffff880`0301e780 fffff880`0307ad20 srv!SrvSmbSetFsInformation fffff880`0301e788 fffff880`0304f670 srv!SrvSmbQueryPathInformation fffff880`0301e790 fffff880`03088cb0 srv!SrvSmbSetPathInformation fffff880`0301e798 fffff880`0304d420 srv!SrvSmbQueryFileInformation fffff880`0301e7a0 fffff880`0304e080 srv!SrvSmbSetFileInformation fffff880`0301e7a8 fffff880`0306f660 srv!SrvSmbFsctl fffff880`0301e7b0 fffff880`03088ae0 srv!SrvSmbIoctl2 fffff880`0301e7b8 fffff880`0306f660 srv!SrvSmbFsctl fffff880`0301e7c0 fffff880`0306f660 srv!SrvSmbFsctl fffff880`0301e7c8 fffff880`0307b4f0 srv!SrvSmbCreateDirectory2 fffff880`0301e7d0 fffff880`053e2060 fffff880`0301e7d8 fffff880`0306f460 srv!SrvTransactionNotImplemented <pre>
可以发现第0xe项会被hook。这个表项的hook是由一段shellcode代码所完成的，具体如何定位到shellcode的入口，见以下分析。
因为已知漏洞会在srvnet! SrvNetWskReceiveComplete中完成触发，只是不确认win 7 64位的shellcode写入点是否与前辈win 7 32位地址一样（通常不一样），因此一开始通过下断点并打印内存情况摸索规律：
</pre> kd> u srvnet!SrvNetWskReceiveComplete+0x15: fffff880`02d3cdc5 488bca mov rcx,rdx fffff880`02d3cdc8 498bf8 mov rdi,r8 kd> ba e1 srvnet!SrvNetWskReceiveComplete+0x15 "dq r8 r8+0x48;gc" <pre>
得到以下结果：
fffffa80`049236b0 00000000`00000003 fffffa80`042fd800 fffffa80`049236c0 fffffa80`042fd800 000059b4`918947fc fffffa80`049236d0 fffffa80`049237f0 00000000`00000810 fffffa80`049236e0 fffffa80`04923710 fffffa80`00000000 fffffa80`049236f0 00000000`00000438 fffffa80`0568d730 …… fffffa80`04a9b010 00000000`0000ffff 00000000`0000ffff fffffa80`04a9b020 00000000`00000000 00000000`00000000 fffffa80`04a9b030 00000000`ffdff100 ffdff020`00000000 fffffa80`04a9b040 ffffffff`ffdff100 00000000`10040060 fffffa80`04a9b050 00000000`ffdfef80 ffffffff`ffd00010
经过比对，发现以上标红内容特殊，是x86报告所记录的溢出时机断点。因此重启环境，下条件断点：
kd> ba e1 srvnet!SrvNetWskReceiveComplete+0x15 ".if(poi(@r8+0x48) == 0xffffffffffd00010){}.else{gc}"
结合以上所知的，SrvTransaction2DispatchTable会被shellcode挂钩，因此在该表项处下断点：
kd> ba w8 srv!SrvTransaction2DispatchTable+0x8*0xe
经过验证，在以上第一个断点触发后，继续运行，会触发第二个断点：
但是，当步入ffffffff`ffd00b77后，栈已经被破坏，难以定位到该段shellcode的触发点。
在我所看到的其它的分析文章中，均没有提及具体是个位置转移到shellcode的，因此只有自己定位。
考虑到shellcode一般均需要间接call，因此，通过寻找SrvNetWskReceiveComplete中的间接call，并下断点排查。最终，定位到shellcode触发点srvnet!SrvNetCommonReceiveHandler+0xb7：
kd> u srvnet!SrvNetCommonReceiveHandler+0xb3 srvnet!SrvNetCommonReceiveHandler+0xb3: fffff880`028017e3 89742420 mov dword ptr [rsp+20h],esi fffff880`028017e7 41ff5208 call qword ptr [r10+8] fffff880`028017eb 8be8 mov ebp,eax fffff880`028017ed 488b0d1cc90100 mov rcx,qword ptr [fffff880`0281e110] fffff880`028017f4 493bcf cmp rcx,r15 fffff880`028017f7 740b je srvnet!SrvNetCommonReceiveHandler+0xd4 (fffff880`02801804) fffff880`028017f9 0fba612c09 bt dword ptr [rcx+2Ch],9 fffff880`028017fe 0f82be840000 jb srvnet! ?? ::FNODOBFM::`string'+0x1341 (fffff880`02809cc2)
在该处下断点验证：
kd> bp srvnet!SrvNetCommonReceiveHandler+0xb7
确实可以截取到shellcode的进入入口：
第一轮shellcode的行为分析
为了测试方便，可以下以下条件断点，这样运行win7测试机器后，断下的地点就是shellcode的入口：
ba e1 srvnet!SrvNetWskReceiveComplete+0x15 ".if(poi(@r8+0x48) == 0xffffffffffd00010){bp srvnet!SrvNetCommonReceiveHandler+0xb7;gc}.else{gc}"
进入shellcode后，该样本在进行奇怪的jne和call之后（我认为是防止静态分析以及弄乱栈），修改了第0C0000082h号MSR：
</pre> ffffffff`ffd00201 31c0 xor eax,eax ffffffff`ffd00203 4090 xchg eax,eax ffffffff`ffd00205 7408 je ffffffff`ffd0020f ffffffff`ffd0020f e8a7000000 call ffffffff`ffd002bb ffffffff`ffd002bb b9820000c0 mov ecx,0C0000082h ffffffff`ffd002c0 0f32 rdmsr ffffffff`ffd002c2 48bbf80fd0ffffffffff mov rbx,0FFFFFFFFFFD00FF8h ffffffff`ffd002cc 895304 mov dword ptr [rbx+4],edx ffffffff`ffd002cf 8903 mov dword ptr [rbx],eax ffffffff`ffd002d1 488d050a000000 lea rax,[ffffffff`ffd002e2] ffffffff`ffd002d8 4889c2 mov rdx,rax ffffffff`ffd002db 48c1ea20 shr rdx,20h ffffffff`ffd002df 0f30 wrmsr ffffffff`ffd002e1 c3 ret ffffffff`ffd00214 c3 ret srvnet!SrvNetCommonReceiveHandler+0xbb: fffff880`02cec7eb 8be8 mov ebp,eax <pre>
这样，利用系统原有的系统调用，样本有机会时系统运行到其准备好的shellcode（ffffffff`ffd002e2）处，经实测，在该处下断点会系统崩溃，但是在其后1条指令处下断点，则不会崩溃：
kd> bp ffffffff`ffd002e5
此处开始的shellcode，会寻找内存中的PE格式、定位PE文件头、定位服务表项的位置，最终将服务表项进行hook，但是代码流程的细节需要亲自调试才能看清楚。在此我就不截图了。
病毒样本的第二轮发包攻击
先在后门处下断点：
</pre> kd> dps srv!SrvTransaction2DispatchTable fffff880`03302760 fffff880`0336c780 srv!SrvSmbOpen2 fffff880`03302768 fffff880`03333b20 srv!SrvSmbFindFirst2 fffff880`03302770 fffff880`03369f40 srv!SrvSmbFindNext2 fffff880`03302778 fffff880`03335650 srv!SrvSmbQueryFsInformation fffff880`03302780 fffff880`0335ed20 srv!SrvSmbSetFsInformation fffff880`03302788 fffff880`03333670 srv!SrvSmbQueryPathInformation fffff880`03302790 fffff880`0336ccb0 srv!SrvSmbSetPathInformation fffff880`03302798 fffff880`03331420 srv!SrvSmbQueryFileInformation fffff880`033027a0 fffff880`03332080 srv!SrvSmbSetFileInformation fffff880`033027a8 fffff880`03353660 srv!SrvSmbFsctl fffff880`033027b0 fffff880`0336cae0 srv!SrvSmbIoctl2 fffff880`033027b8 fffff880`03353660 srv!SrvSmbFsctl fffff880`033027c0 fffff880`03353660 srv!SrvSmbFsctl fffff880`033027c8 fffff880`0335f4f0 srv!SrvSmbCreateDirectory2 fffff880`033027d0 fffffa80`040a3060 fffff880`033027d8 fffff880`03353460 srv!SrvTransactionNotImplemented kd> ba e1 fffffa80`040a3060 <pre>
接着，触发第二轮攻击，等待断点触发。以下是行为分析。
shellcode的行为分析
第二轮发送的包，为SMB2协议的包，其timeout项，被作为控制flag。
该域经过计算后，它只有三种值，分别对应了“检查”、“卸载”和“执行程序”，计算公式如下：
域的解析判断部分如下：
在经过ping包后，会执行exec包，执行的程序也包含在（拼接后并解码后的）SMB2包中。其行为为：
1. 找ntoskrnl的基址：
2. 通过hash，找出关键的系统调用
3. 通过遍历PID，获取EPROCESS，在通过比对进程EPROCESS中进程名的HASH值，获取指定的进程PID
最后，利用apc注入，将自带的dll注入到指定系统进程中，apc注入看雪中已有相关文章。
Apc的回调函数地址是:
也就是刚才拷贝的apc注入的shellcode,用于内存加载dll,并执行其唯一的导出函数PlayGame，该shellcode及dll我均已经dump出，大家可以从附件下载:
PlayGame运行后，会释放并执行母体，溢出攻击到此结束,但是悲剧将在新的机器上循环上演。
文章 (RSS)