恶意软件分析实战01-分析3个恶意程序
Lab1-2: 分析Lab01-02.exe文件:
首先拖入PEID发现该软件加过UPX壳
脱壳, 在拖入PEID后, 发现是VC++写的:
将其拖到VirusTotal上分析。发现有恶意行为:
其导入了如下dll:
推测其可能会与网络相关，并且可能会有修改注册表或者注册服务等行为。
观察其导入的函数, 主要可以归纳:
1. 其创建了线程。并可能创建多个因为有互斥量存在。
2. 其创建了系统服务，可能是要以系统服务方式启动。
3. 打开了一个url资源，但没有进行进一步操作
使用strings工具查看一下恶意代码内部的字符串。发现如下:
还有就是:
一个可能的服务名称:
果然在服务内发现了对应的服务:
总结:
1. 如果使用了IE8的用户可能会被其影响。
2. 如果主机访问过malwareanalysisbook.com资源可能受到影响
3. 出现MalService服务的机器代表已被感染
Lab1-3: 分析Lab01-03.exe文件
拖入PEID:
其加上了一个FSG 1.0的壳。没有碰到过这个壳。尝试手脱, 先查看下各个表:
进入OD查看:
接下去就是对IAT修复
最后我们回到了OEP处:
脱完壳后查看一下PEID发现同样是VC++6.0编写的:
导入表恢复正常, 脱壳成功
接下去分析程序行为, 首先杀毒检查一下，果然满满的恶意行为:
但是看一下它的导入表，倒是非常干净，没有任何恶意行为使用了com组件:
但是仔细看看totalvirus 的报告:
说明了肯定存在动态加载的行为。来搜索一下可执行文件内的字符串:
果然如此。但是令我最好奇的还是一点。分明导入表没有对应的dll被导入。为了会最终动态加载了那么多的库?
怎么想都感觉问题出在那个com组件上。由于我对com组件并不了解。在我逆向时非常小心翼翼，我发现当其在调用下面这个call前，模块间调用还是正常的:
模块间调用:
但当进入了这个call时就出现了问题:
此时的模块间调用。出现了非常多的新动态库以及对应的函数。这时正好与totalvirus上报告相符
于是去查看了下COM组件的资料结合MSDN的信息:
了解到一些基本新消息:
1. CoCreateInstance被调用时，其通过注册表来获取一些信息(简单说就是有注册表行为)
2. CoCreateInstance参数CLSID代表着是一串编码，注册表中会指出该编码对应哪个程序
3. CoCreateInstance参数IID代表IWebBrowser2接口
最关键的是首先先找到CLSID和IID:
拖入IDA后获取具体位置, 获取对应数值:
解析出来:
找到CLSID对应的注册表项:
发现其与IE浏览器相关。 在继续分析, 它下面分配一个字符串是一个网页:
可以初步断定其会访问该网页，并且感觉像是个广告网页。最后就是传入了这个url字符串后调用了一个函数。这个函数是主要功能函数。后面就是字符串释放以及返回的代码
进入这个call后就发现是系统库的代码了。之后就再也没有人写的代码了。
可以猜想其功能就是调用IE浏览器并打开广告页面, 果然如此:
Lab1-4: 分析Lab01-04.exe文件:
拖入PEID，发现没有加壳, 是用VC++编写:
初步检查发现是恶意软件:
看一下详细分析情况:
该程序的编写时间可能是:
资源节太了。可能有寄宿在母体的程序。这种情况是很可能是编程者把其他文件以资源形式存在了母体内。等适当的时候调用FindResource, LoadResource, LockResource, FreeResource等一系列API释放出来。查看导入表，找到了这些API基本上可以确定了:
现在需要把藏在资源节的文件拿出来分析, 这里用Resource Hacker打开, 发现PE文件是一个exe可执行文件:
将其保存为a.exe然后用PEID打开, 没有加壳是一个VC++写的程序:
现在先把母体程序放一边，先分析一下释放出来的程序。
其存在恶意行为，在看看其他信息, 可以初步猜测主要的还是进行广告行为:
看一些导入表内容, 其中最精彩的就是URLDownloadToFileA函数，代表其从远程服务器上下载了东西下来, 很可能就是从上面的url上下载:
再看看，其调用了获取Windows目录以及临时目录的API。然后调用了WinExec执行了某个程序。
初步猜测其从远程服务器下载可执行文件下来到Windows目录以及临时目录后执行下载下来的内容。
这个程序就初步分析到这里。接下来继续分析母体程序:
母体进行了提权操作，很可能是为了获取DEBUG权限:
猜想一下母体程序的行为:
接下来进行逆向分析:
首先从psapi.dll中获取函数:
首先调用了EnumProcesses函数:
来看看其函数功能, 其能够获取当前系统中存活的进程PID的数组:
进入循环遍历PID数组，对每个进程调用FindModuleInProcess函数
下面来仔细分析一下FindModuleInProcess函数:
毫不奇怪, EnumProcesses第一个枚举到的PID肯定是System进程的PID为4
接下去对局部变量进行赋值操作:
赋值完后就打开目标进程后调用了EnumProcessModules
查看一下该函数， 该函数可以获取进程内所有的模块句柄的数组。首先第一个获取的是自身模块的句柄
对这个功能函数进行进一步分析:
现在完全确认了该函数的功能是遍历当前所有进程后寻找winlogon.exe是否存在。将其改名为CheckWinlogonExists
进入sub_401174函数, 看到了以SeDebugPrivilege为参数调用的sub_4010FC。猜测这是获取DEBUG权限的提权功能函数
进入后发现果然是这样，于是修改名称为GetDebugPrivilege
返回之前后继续往下分析, 调用GetDebugPrivilege后获取DEBUG权限。通过动态调用方式获取sfc_os.dll库内的某个函数作为远线程函数。并远线程注入winlogon.exe
进行注入后把系统目录下的wupdmgr.exe移动到临时目录并改名为winup.exe后就进入了另一个新函数
首先拼搭一个路径。并将资源节内的PE文件以该路径释放出来
释放资源后调用WinExec来执行生成的wupdmgr.exe
到此，母体的程序已经完全分析完毕。下面是衍生下的子程序的分析过程, 子程序比较简单。运行winup.exe后从远程服务器上下载wupdmgrd.exe后执行(该程序可能是一个daemon服务进程)
(完)
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！