恶意代码分析实战14-1_恶意代码分析实战lab14-01-CSDN博客

本文链接：https://blog.csdn.net/yalecaltech/article/details/117399661

本次实验我们将会分析lab14-01.exe文件。先来看看要求解答的问题
Q1.恶意代码使用了哪些网络库?它们的优势是什么?
Q2.用于构建网络信令的信息来源是什么，什么样的条件会引起信令的改变?
Q3.为什么攻击者可能对嵌入在网络信令中的信息感兴趣?
Q4.恶意代码是否使用了标准的Base64编码?如果不是，编码哪里不一样?
Q5.恶意代码的主要目的是什么?
Q6.使用网络特征可能有效探测到恶意代码通信中的什么元素?
Q7.分析者尝试为这个恶意代码开发一个特征时，可能会犯什么错误?
Q8.哪些特征集可能检测到这个恶意代码(以及新的变种) ?

通过wireshark进行监控，双击运行lab14-01.exe
在这里插入图片描述

从抓到的流量中可以看到会通过dns查询www.practicalmalwareanalysis.com
继续分析，看到一个get请求
在这里插入图片描述

get的内容似乎是随机的字符串
我们在另一台主机同样的操作是会发现，user-agent在不同的机器上是不同的，在这台机器上是
在这里插入图片描述

我们使用这台电脑自带的ie浏览器访问网页，从下图可以看到
在这里插入图片描述

正常的浏览器行为和我们运行程序产生的流量中看到的user-agent是相同的
说明恶意代码很可能使用了COM API接口

接着通过IDA分析
在imports窗口看到
在这里插入图片描述

这个函数就是用于下载文件到缓存中，那么就知道了程序使用COM API接口，而使用COM API接口时，http请求的大部分内容都来自windows内部，这也就解释了为什么我们在发现在不同主机中运行抓到的是不同的user-agent字符串，而每一个user-agent都与在相同主机上使用浏览器手动访问时抓到的是一样的。
Q1.恶意代码使用了哪些网络库?它们的优势是什么?
A1.该程序中包含了URLDownloadToCacheFile 函数，而这个函数使用了COM接口。当恶意代码使用COM接口时，HTTP请求中的大部分内容都来自Windows内部，因此无法有效地使用网络特征来进行针对性的检测

这个函数似乎是唯一使用的网络函数，所以可以对其查看交叉引用
在这里插入图片描述

跟入第一个，继续交叉引用
在这里插入图片描述

此时来到了sub_4011a3
该函数不仅调用了URLDownloadToCacheFileA，还调用了CrateProcessA,推测是为下载的文件创建一个进程
这里给sub_4011a3重命名为downloadRun
接着分析URLDownloadToCacheFileA附近的情况
在这里插入图片描述

在调用处上方看到了一个字符串，跟入如下所示
在这里插入图片描述

就是我们看到的get请求的那个形式
其作为sprintf函数的输入，而其输出作为URLDownloadToCacheFileA函数调用的参数
在格式化的字符串中我们看到URI的中间部分是被%s定义，而png文件内容是被%c定义，我们向前回溯，看看参数的输入点
在这里插入图片描述

004011db处push的就是%s的内容，而ecx来自arg_0,而arg_0是dwonloadRun函数的唯一参数
004011d7处push的就是%c的内容
在004011b0通过strlen获取arg_0字符串的长度，保存在var_218
在这里插入图片描述

然后%s的最后一个字符被复制到作为%c的局部变量的var_214中
这就可以解释在wireshark中看到的：文件名%c与字符串%s的最后一个字符相同
接着我们分析该函数的参数是什么
查看交叉引用，来到main
在这里插入图片描述

在下图所示处被调用
在这里插入图片描述

可以看到是处在一个循环结构里,里面还有对sleep的调用
downloadRun的参数往上可见是来自sub_4010bb
跟入sub_4010bb，分析
在这里插入图片描述

一开始是调用strlen计算字符串长度
还有一个call是sub_401000
在这里插入图片描述

跟入
在这里插入图片描述

看到byte_4050c0.跟入后可以看到
在这里插入图片描述

这其实是标准base64编码字符串
回到原函数
继续往下
在这里插入图片描述

往左是选择编码字符，往右是选择填充字符
右边的61h其实是‘a’，而不是’=‘
说明sub_401000并不是一个标准的base64编码函数。因为标准的base64是用‘=‘来填充的
回到main函数
在其前面有

在这里插入图片描述

有GetCurrrentHwProfileA函数，GetUserNameA函数，sprintf的调用
以及两个字符串
GetCurrrentHwProfileA函数返回GUID中的6个字节以MAC地址的形式被打印，然后成为%s%s中的第一个字符串，而第二个字符串则是用户名
Q2.用于构建网络信令的信息来源，什么样的条件会引起信令的改变?
A2.信息来源是主机GUID与用户名的一部分。GUID对于任何主机操作系统都是唯一-的，信令中使用了GUID中的6个字节，应该也是相对唯一的。用户名则会根据登录系统的用户而改变。
Q3.为什么攻击者可能对嵌入在网络信令中的信息感兴趣?
A3.攻击者可能想跟踪运行下载器的特定主机，以及针对特定的用户。

我们尝试使用base64工具进行解码wireshark捕获到的get的字符串
在这里插入图片描述

可以看到这个格式和我们从IDA中分析的是一样的
这里有两点需要注意：
1.对于解码而言，主机名后面的-其实是错误的解析，因为在编码时恶意代码不是使用a填充的base64，而解码时使用的是=填充的标准base64，所以在解密时会将最后的aa解释为标准字符，而不是将其识别为可以替换的填充字符
2.对于编码而言，我们知道如果是标准的base64，则最后的aa其实应该是==
所以如果是标准base64的话解码后是这样的
在这里插入图片描述

Q4.恶意代码是否使用了标准的Base64编码?如果不是，编码哪里不一样?
A4.不是标准的Base64编码，因为它在填充时，使用a代替等号(=)作为填充符号。

知道字符串的来源后，我们看看收到某些内容后会发生什么
可以看到URLDownloadToCacheFileA成功后会走右边
在这里插入图片描述

这里调用了CreateProcessA
在这里插入图片描述

它会将URLDownloadToCacheFileA返回的路劲名作为参数，一旦恶意代码下载了一个文件，就简单的执行该文件然后退出
Q5.恶意代码的主要目的是什么?
A5.这个恶意代码下载并运行其他代码。

分析生成网络特征时，我们回到解码后的结果
在这里插入图片描述

可以看到
这里的关键是用于填充的:和在硬件配置文件字节和用户名之间的-
而我们知道，在将这些内容发到网络上之前，恶意代码进行了base64编码
我们三个一组看看有什么管理
在这里插入图片描述

在这里插入图片描述

我们可以看到一些规律：
使用base64编码时，因为原始字符串中的冒号是三字符组中的第三个字符，所以编码后的每个四字符组的第四个字符比特都来自于第三个字符，从上面的图片也可以看得出，冒号之后每四个字符为6；因为破折号-的存在，所以第六个四字符组以t结尾。
我们由此已经知道，URI至少有24个字符，并且指定了6和t的具体位置。
我们还知道下载的名称是单个字符，这个字符就是路径的最后一个字符
那么就可以编写两个正则表达式，一个用于匹配字符串，一个用于匹配下载的文件
[A-Z0-9a-z+/] 是用于匹配base64编码中的所有字符，为了简洁的表示，使用A来代替
那么第一个正则可以这么写
//A{3}6 A{3}6 A{3}6 A{3}6 A{3}6 A{3}t(A{4}){1,}//
这样就可以匹配以字符6和t结尾的四字符组的模式

第二个正则用于匹配下载文件
/\A{24,}(A)/\1.png/
上面的\1是指括号之间捕获的第一个元素，它是/之前的base64编码字符串中的第一个字符。
这样就可以匹配单字符后跟一个.png

此外，还可以通过域名、恶意代码下载可执行文件等特征来联合进行检测
Q6.使用网络特征可能有效探测到恶意代码通信中的什么元素?
A6.恶意代码通信中可以作为检测目标的元素包括域名、冒号以及Base64解码后出现的破折号，以及URI的Base64编码最后一个字符是作为PNG文件名单字符
Q7.分析者尝试为这个恶意代码开发一个特征时，可能会犯什么错误?
A7.防御者如果没有意识到操作系统决定着这些元素，则他们可能会尝试将URI以为的元素作为目标。多数情况下，Base64 编码字符串以a结尾，它通常使文件名显示为a,png。然而，如果用户名长度是3的倍数，那么最后一个字符和文件名都取决于编码用户名的最后一个字符。这种情况下，文件名是不可预测的
Q8.哪些特征集可能检测到这个恶意代码(以及新的变种) ?
A8.推荐的特征集请参考上述详细分析过程，此处不再赘述。

参考：
1.《恶意代码分析实战》