首先我们通过静态分析发现该程序的导入表中有很多文件操作类函数。
又在StringView中发现了Lab07-03.dll字符串,我们推断程序有可能调用了该动态库,但却没有发现任何loadlibrary或者getprocaddress函数。所以我们的推测可能是错的,他有可能并没有加载这个动态库。
其中也出现了Kernel32.dll的完整路径。但还出现了一个Kerne132.dll的完整路径,很明显,这个程序可能恶意的冒充Kernel32.dll,从而达到一些目的。
接下来,我们用IDA分析该动态库。
相同的我们先查看它的导出表,导入表以及StringView。
很奇怪的是,这个动态库并没有导出任何函数,他不能被一个程序所导入。
我们在导入表中发现了一些网络通信的函数。而且看到了CreateProcessA函数,这意味着它很可能创建了另外一个进程。
在StringView中,我们看到了一个IP地址127.26.152.13,这个恶意代码可能会连接它。
分析DLL:
首先由于代码冗杂,我们开启FunctionsCallView,通过查看函数调用来阅读代码。
首先,是调用通过库函数__alloca_probe来在空间中分配栈。接下来调用了OpenMutexA和CreateMutexA函数是为了保证程序单开。(只有一个实例在运行)
接下来的函数通过一个socket来建立连接(127.26.152.13),并且传输和接收数据。这个函数以对Sleep和CreateProcessA的调用结束。我们并不知道发送的内容是什么。但是我们可以猜测这个DLL在做什么。对于一个发送和接收数据并创建进程的函数,对于它最好的解释是被设计来从一个远程机器接受命令。
我们发现了参数127.26.152.13(远程主机IP),80端口(常被web流量使用)。
通过对send函数传参的分析,它向远程机发送了一个“Hello”,这似乎是受害机发送的一个问候,来使服务器知道他已经准备好执行下一个命令。
我们发现,这个程序期望在回复中接受到一些数据,并将其会保存在esp+120ch+buf(栈上的缓冲区)
接下来我们判断这个程序会在回复中做什么。我们发现这个缓冲区值(esp+120ch+buf)在后面几行被检查。
虽然到Esp的偏移发生了变化,但是同一个缓冲区(站的大小发生了变化),IDA同时标记了buf来告诉我们是同一个值。
并且在代码中,调用strncmp函数,判断它前五个字符是不是字符串“Sleep”,如果是,它将调用sleep函数来睡眠60秒。这告诉我们如果远程服务器发送的是sleep命令,这个程序将会调用sleep函数。
同样的,代码检查这个缓冲区是不是以“exec”开始,如果是,strncmp函数将会返回0,并顺序执行调用CreateProcessA函数。我们发现这个函数有很多参数,最有价值的是它的CommandLine参数,他告诉我们要被创建的进程。而且代码显示CommandLine中的字符串被保存在栈的某处。但是我们却没有发现该指针在别处被调用。
我们去查看CommandLine的定义
我们发现recv函数的接受缓冲区是从1000h开始的,并且这个值使用lea指令来设置的,这告诉我们这个数据本身是保存在栈上的,并且不仅仅是一个指向数据的指针。同样我们发现了CommandLine的定义是0FFBh,这说明它会接收缓冲区中保存的任意5字节的东西。所以从远程服务器中接受到的字符串是exec FullPathOfProgramToRun。它会用FullPathOfProgramToRun来调用CreateProcessA。
现在我们知道了该Dll实现了后门功能,这允许攻击者通过发送回复给80端口上的一个数据包,来启动一个系统上的可执行文件。
分析EXE:
首先我们查看这个可执行文件的main函数,首先我们看见了一个对命令行参数的检查。
首先,它比较检查参数个数是否为2.如果参数不是2,代码跳转是程序提前退出。(这是我们试图执行动态分析,程序快速终止的原因)
接着程序将argv[1]移动到EAX,以及将WARNING_THIS_WILL_DESTROY_YOUR_MACHINE字符串移动到ESI寄存器。然后循环比较,如果他们不一样,这个程序将会跳转到一个位置,并从这个函数返回,不执行任何其他事情。
[培训]内核驱动高级班,冲击BAT一流互联网大厂工作,每周日13:00-18:00直播授课