一个CS马伪装下的loader样本分析

admin 2021年4月13日00:57:56一个CS马伪装下的loader样本分析已关闭评论32 views字数 4341阅读14分28秒阅读模式

0x01 开源情报收集

样本下载链接:https://app.any.run/tasks/ffc1ecff-e461-4474-8352-551db7e7b06f/

常用平台:VT,微步,哈勃 app.any.run, joesandbox
::: hljs-center

一个CS马伪装下的loader样本分析
图一:VT检测

:::

木马实锤

沙箱跑一下看一下行为:
::: hljs-center

一个CS马伪装下的loader样本分析
图二:沙箱行为分析

:::

可以看到用GET请求访问C&C服务器下载了一个二进制binary文件。

点开binary文件查看详情:
::: hljs-center

一个CS马伪装下的loader样本分析
图三:恶意binary

:::

dump下来wireshark数据包,过滤http请求同样可以发现该二进制文件
::: hljs-center

一个CS马伪装下的loader样本分析
图四:抓包分析

:::

查询C&C服务器ip:
::: hljs-center

一个CS马伪装下的loader样本分析
图五:ip检测

:::

现在对该恶意软件已经有了初步了了解,下面进行数据包分析,看看能不能找到有用的信息。最直观的看到就是使用了非常见的端口连接,还有发现一个有趣的现象:
::: hljs-center

一个CS马伪装下的loader样本分析
图六:数据包分析

:::

竟然是肉鸡主动连接的C&C服务器,让我联想到了CS马。这种手法类似于反弹shell,好处就是可以绕过防火墙限制,如果对方是内网ip,你无法直接发起连接请求,方便持久化控制等等。

0x02 样本基本信息

用exeinfo查壳,标准的32位VC编译的程序
::: hljs-center

一个CS马伪装下的loader样本分析
图七:样本信息

:::

用Process Monitor监控行为
::: hljs-center

一个CS马伪装下的loader样本分析

图八:软件行为

:::

具体每一项的图略了,大概看了一下读取了注册表的某些键值,设置了某些键值对的值,很多对IE浏览器的设置,代理,Cache等等。用createfile()函数读取了本地一些文件,但是没有在磁盘创建文件的行为,也没有删除文件的行为。网络行为监控可以看到send,receive动作,应该是从C&C服务器接收了下一阶段的恶意负载。重点看了一下注册表里面没有找到用于持久性控制的键值修改。

0x03 binary分析

IDA静态分析

原则:先静后动
载入IDA看一下导入表,看到了很多标志性的API
反调试:
::: hljs-center

一个CS马伪装下的loader样本分析

:::

查询用户默认区域,呦呵,还是有针对性的呀
::: hljs-center

一个CS马伪装下的loader样本分析

:::

反调试:
::: hljs-center

一个CS马伪装下的loader样本分析

:::

分配内存,因为恶意样本会从C&C接受binary文件,但是没有写入磁盘,猜测就是用来这个API开辟了一段内存空间,在内存中执行payload。

一个CS马伪装下的loader样本分析

但是有一点很疑惑,没有看到与网络操作有关的API函数和库。

看静态字符串
::: hljs-center

一个CS马伪装下的loader样本分析

:::

静态分析程序流程
::: hljs-center

一个CS马伪装下的loader样本分析

:::

就两个函数,我重点分析了第二个函数sub_453960(),因为第一个函数点进去看没有什么实质性的操作,在初始化处理,创建互斥体等等。

我采取的办法是直接对照着IDA,在OD中把第二个函数完整的执行了一遍,花费了大概三个半小时,这估计是最笨的方法了吧。但是至少搞清楚了程序流程。关键函数是sub_4534B0(),在它来到关键函数之前,恶意软件还设置了某几个文件夹的属性,如C:UsersAdministratorAppDataRoamingMicrosoftWindowsCookies,难道要窃取cookie?

调试后定位到关键函数,其实这个应该就是主函数,ida没有识别出来:
::: hljs-center

一个CS马伪装下的loader样本分析

:::

程序用VirtualAlloc()开辟了一段内存,&unk_515000里面存的是程序硬编码的payload,sub_44F3DC()的作用相当于strcpy(),将payload复制到v1,然后把v1当函数执行。其实payload就是一段机器码。从00515000—0051531F,更有意思的是在payload尾部发现了C&C服务器的ip地址。而且之后调试发现,整个程序都是使用的这种手法来执行自己的payload。

payload分析:
::: hljs-center

一个CS马伪装下的loader样本分析

:::

OD动态分析

第一步:关闭样本的aslr,方便进行分析和调试。
载入peview
::: hljs-center

一个CS马伪装下的loader样本分析

:::

偏移是15E,放入hex编辑器,我看很多大佬都用010editor
::: hljs-center

一个CS马伪装下的loader样本分析

:::

修改完成后,载入OD即可
反调试是用hideod过的,手工也可以,直接修改PEB块中的值。
直接从关键函数处开始展示:
::: hljs-center

一个CS马伪装下的loader样本分析

:::

因为是32位系统,默认是eax寄存器存放函数返回值,调用完VirtualAlloc()后返回值存放的是分配内存的首地址,0002000,也就是说payload会被复制到这里,并执行。
::: hljs-center

一个CS马伪装下的loader样本分析

:::

并且该内存页属性,RWE,符合条件。
::: hljs-center

一个CS马伪装下的loader样本分析

:::

数据窗口跟随,在执行完sub_44F3DC()后payload被复制于此。
::: hljs-center

一个CS马伪装下的loader样本分析

:::

程序开始执行payload,经过对payload的调试,作用是通过loadlibrary()函数加载wininet库,这也解释了为什么在导入表里面没有找到与网络操作相关的API函数信息。找到所需API函数地址后,开始与C&C服务器通信。
::: hljs-center

一个CS马伪装下的loader样本分析

:::

::: hljs-center

一个CS马伪装下的loader样本分析

:::

我们直接对00020068和0020086处下断点即可。调试的时候可以很明显的感觉到有时钟机制在阻碍动态分析,直接在关键点下段,绕过即可。
::: hljs-center

一个CS马伪装下的loader样本分析

:::

00020068处是进行网络通信时用到的API函数的ASCII码
::: hljs-center

一个CS马伪装下的loader样本分析

:::

00020086处用了一条jmp eax指令来执行API函数
::: hljs-center

一个CS马伪装下的loader样本分析

:::

因为之前通过沙箱分析和流量分析知道,第一个样本会连接C&C服务器下载第二段payload,大体思路就是通过VirtualAlloc()函数分配一块内存,然后通过InternetReadFile()指令读取payload到内存。

查了一下VirtualAlloc()传参次序:
LPVOID VirtualAlloc{
LPVOID lpAddress, // 要分配的内存区域的地址
DWORD dwSize, // 分配的大小
DWORD flAllocationType, // 分配的类型
DWORD flProtect // 该内存的初始保护属性
};

::: hljs-center

一个CS马伪装下的loader样本分析

:::

从右向左进行传参,网上查了一下,当Address参数为null时,系统将会决定分配内存区域的位置,并且按64-KB向上取整(roundup)。

这个位置是随机的,之后会调用InternetReadFile(),将第二段负载读到此处。
::: hljs-center

一个CS马伪装下的loader样本分析

:::

此处下一个硬件执行断点
::: hljs-center

一个CS马伪装下的loader样本分析

:::

第二段payload已经被读入
::: hljs-center

一个CS马伪装下的loader样本分析

:::

程序开始执行第二段payload
::: hljs-center

一个CS马伪装下的loader样本分析

:::

循环解密payload
::: hljs-center

一个CS马伪装下的loader样本分析

:::

解密出来就是一个PE文件
::: hljs-center

一个CS马伪装下的loader样本分析

:::

把PE文件dump出来
查壳
::: hljs-center

一个CS马伪装下的loader样本分析

:::

一个dll文件

VT分析
::: hljs-center

一个CS马伪装下的loader样本分析

:::

之前分析复现过APT28的一个样本,手法和这个程序差不多,最终也会释放一个恶意的dll。Dll文件有的是用rundll32执行,有的是直接在内存里加载dll,执行里面函数,这样dll就不用落地了,就算exe程序被捕获了,dll核心功能也不会被获取到。本例中是直接在内存中进行执行。

说一下要点:因为之前有CTF经验,在静态分析时快速识别出来base64算法和AES算法。
Base64码表:
::: hljs-center

一个CS马伪装下的loader样本分析

:::

Base64算法实现:

::: hljs-center

一个CS马伪装下的loader样本分析

:::

‘=’补齐:
::: hljs-center

一个CS马伪装下的loader样本分析

:::

发现了用于AES加密的S盒:
::: hljs-center

一个CS马伪装下的loader样本分析

:::

标准的HttpSendRequestA系列API进行网络请求:
::: hljs-center

一个CS马伪装下的loader样本分析

:::

动态调试时,发现了url。
::: hljs-center

一个CS马伪装下的loader样本分析

:::

通过分析数据包,原本以为像普通马一样,收集本机敏感信息,压缩上传至C&C服务器,结果这个马更加狡猾。这个恶意的dll相当于还是一个downloader,它通过去连接这个url,类似于心跳包检测的机制,根据页面回显或提前设置好的标志位,来决定执行的操作。是执行恶意功能还是sleep。执行恶意功能应该就是去下载真正的恶意负载。
::: hljs-center

一个CS马伪装下的loader样本分析

:::

0x04攻击流程

这个样本的适用场景应该是APT组织攻击或红队攻击中,通过渗透测试成功向目标上传了CS马,但是由于CS的易检测的特制,不适于现代实现持久化控制的目的。所以在cs马中硬编码了一段payload,与C&C服务器进行通信下载了一个binary。通过xor操作达到免杀的目的,这个binary的作用相当于一个downloader,用于下载下一阶段的恶意负载。通过对请求的url的判断,提高了自己的隐蔽性,在合适的时机被攻击者唤醒。样本还有一个亮点是全程没有落地,通过VirtualAlloc()分配内存,将payload复制进内存进行执行,给我逆向分析的过程中带来了不少的麻烦。样本检测通过社区的yara规则即可检测为恶意样本。

0x05 IOC

Main object :"3F37FC95AA5C8F7C304AA0DFC3FFBF2E"
SHA256: F6E04B3710044F76666468559FD2B6688CCAC091284D138E461C2257C387D7D3
SHA1: 4BB7B4AE2CC8C5D6C8EF1704A9B027878190D028
MD5: 3F37FC95AA5C8F7C304AA0DFC3FFBF2E
Connections
IP 8.210.181.149
HTTP/HTTPS requests
URL http://8.210.181.149:16678/activity
URL http://8.210.181.149:16678/9jhQ

0x06 关联分析

关联分析用的是奇安信的平台
::: hljs-center

一个CS马伪装下的loader样本分析

一个CS马伪装下的loader样本分析

:::

相关推荐: 浅析CVE-2020-5405

漏洞信息 Spring Cloud Config 程序内部在处理客户端传入的资源时存在自动将 (_) 转换为 / 的隐藏转换,当 profile 设置为 native时,则会导致服务端路径穿越,因此攻击者可以利用此机制来穿越到其它路径,读取任意文件。 影响范围…

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2021年4月13日00:57:56
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   一个CS马伪装下的loader样本分析http://cn-sec.com/archives/246721.html