恶意代码分析实战 Lab19

lab19-01

1IDApro打开看到解码代码如下

恶意代码分析实战 Lab19_第1张图片

od调试的时候显示说无法作为及时调试器调试,所以只能用windbg,虽然麻烦了点

解码后程序先跳到003a0464


接着在464处,马上调用003a03bf函数


步入查看程序又调用003a039e函数

恶意代码分析实战 Lab19_第2张图片

步入查看函数,这段函数很短,可以很容易看出来是在得到kernel32的base地址,看30h是的搭配peb结构地址,1ch是得到InInitializationOrderLinks链表项,并且得到第二个链表项的偏移8的dllbase,这里认为kernel是第二个被初始化的,win7下就不一定是这样了.

恶意代码分析实战 Lab19_第3张图片

接着返回函数,注意到接下来调用了很多的003a0352函数,可以知道这个函数是得到一些kernelAPI地址的函数

恶意代码分析实战 Lab19_第4张图片

进入003a0352函数查看,注意到函数003a0331函数调用,推测这是得到散列值的函数,注意到后面的比较就知道不难推测这个函数作用,这里的24h是kernel的base也就是第一个参数,kernelbase+3ch为了得到PE头地址,然后78h得到的是导出表的rva

恶意代码分析实战 Lab19_第5张图片

所以edx现在是导出表地址,他的18h偏移是numberofnames,1ch偏移是addressoffunctions,20h是addressofnames,24h是addressofnameordinals

所以不难看出来上面函数在偏移20h的addressofnames

看一下散列算法,可以看到是跟课本一样

恶意代码分析实战 Lab19_第6张图片

为了知道6次调用都得到那些API地址可以在函数003a0352内部jne后面一个mov指令设置断点然后db esi查看函数名,如第二次是得到GetSystemDirectoryAPI地址


通过这种方法知道分别得到loadlibrary GetSystemDirectory Terminateprocess getcurrentProcess winExec这五个API地址

得到这几个API之后首先调用ebp-4也就是loadlibrary参数是eax里面的URLMON.dll



接着得到urldownloadtofileAPI地址放在ebp-18h


接着调用ebp-8的GetSystemDirectory


接着调用ebp-18h就是urldownloadtofileAPI我们看一下参数url和filename就好

恶意代码分析实战 Lab19_第7张图片

接着调用ebp-14h运行那个1.exe程序


然后调用ebp-10h得到当前进程句柄,然后调用ebp-ch结束当前进程


分析结束


lab19-02

函数先提权

然后调用sub_401000函数,这个函数得到如下字符串,得到的是系统默认浏览器的绝对路径名

恶意代码分析实战 Lab19_第8张图片

函数sub_401180函数是运行这个浏览器

恶意代码分析实战 Lab19_第9张图片

接着sub_401230实现shellcode注入,shellcode在asc_407030

恶意代码分析实战 Lab19_第10张图片

跳到asc_407030处按c使得IDApro将他识别为代码

恶意代码分析实战 Lab19_第11张图片

看到解码很简单异或E7就好,我用winhex将这段shellcode拷贝出来保存在shellcoade19-02.bin然后在和E7异或,最后用IDApro打开就可以静态分析shellcode的源代码了

会发现程序的几个函数调用和流程和我们之前分析的lab19-01很像,同样的到kernel32,dll的base

然后得到loadlibrary的地址

接着调用loadlibrary得到ws2_32.dll

恶意代码分析实战 Lab19_第12张图片

为了动态分析,使用lab19-01同样的分析方法可以得到








得到两个dll所需要的API后,调用如下函数


然后是建立套接字


建立连接


看下参数sockaddr其中02c8a8c0指的是ip192.168.200.2(c0:a8:c8:02) 1234 0002指的13330(0x3412)端口和2(AF_INET)


连接成功会创建cmd进程,建立反向shell

注意建立进程之前的参数设置,下图这里的esp为startupinfo结构体,他的48h开始是进程的标准输入标准输出和标准错误,都被赋值为eax(来自esi来自之前建立套接口的返回值)

恶意代码分析实战 Lab19_第13张图片    



最后会调用getcurrentprocess和terminateprocess结束进程



运行结果反向shell成功

恶意代码分析实战 Lab19_第14张图片


lab19-03

用推荐工具检测是否存在脚本

恶意代码分析实战 Lab19_第15张图片

然后winhex打开pdf,搜索JavaScript

将那一段拷贝出来得到找到攻击负载


恶意代码分析实战 Lab19_第16张图片

找到负载就可以用课本提供脚本提取处shellcode,然后用课本提供那个.exe运行恶意代码,动态分析了

要知道都得到那些API的地址的方法之前两个代码分析已经讲过不再赘述,直接给出结论,导入如下函数

恶意代码分析实战 Lab19_第17张图片


直接看代码

分配堆


设置文件指针,然后读取信息到之前创建的堆中(sub_13D内部会调用readfile)


得到临时文件目录


再sub_EB内部会创建文件foo.exe,然后会把之前堆里面的数据写到文件

恶意代码分析实战 Lab19_第18张图片

然后创建foo.exe进程


后面是基本一样的操作,又写了一个bar.pdf文件再临时文件目录下

最后调用shellExecute启动这个pdf文件,文件名在第三个参数向上追溯就知道对那个文件操作

恶意代码分析实战 Lab19_第19张图片


这个程序没有动态分析验证,是因为觉得前面两个分析的够多了,这个代码也不难看出,只要知道了每个call都是在调用那个API(像我上面那样注释)就不难理解代码主要在做什么,当然很多细节没有分析道,毕竟只是静态分析,比如每个函数的参数具体是什么如果没有动态分析是很难确定的,但是不妨碍我们静态分析推测,比如上面的一些对文件的操作,我们不难推测都是对原来的.pdf文件的读写操作,显然后面写的两个exe和.pdf文件之前都存在最开始的.pdf文件,这是很显然的,即使不用动态分析我们也应该有这样的自觉

分析结束


你可能感兴趣的:(恶意代码分析实战 Lab19)