0x01 开源情报收集
https://app.any.run/tasks/ffc1ecff-e461-4474-8352-551db7e7b06f/
可以看到用GET请求访问C&C服务器下载了一个二进制binary文件。点开binary文件查看详情：
dump下来wireshark数据包，过滤http请求同样可以发现该二进制文件
查询C&C服务器ip：
现在对该恶意软件已经有了初步了解，下面进行数据包分析，看看能不能找到有用的信息。最直观的看到就是使用了非常见的端口连接，还有发现一个有趣的现象：
竟然是肉鸡主动连接的C&C服务器，让我联想到了CS马。这种手法类似于反弹shell，好处就是可以绕过防火墙限制，如果对方是内网ip，你无法直接发起连接请求，方便持久化控制等等。
0x02 样本基本信息
用exeinfo查壳，标准的32位VC编译的程序
用Process Monitor监控行为
具体每一项的图略了，大概看了一下读取了注册表的某些键值，设置了某些键值对的值，很多对IE浏览器的设置，代理，Cache等等。用createfile()函数读取了本地一些文件，但是没有在磁盘创建文件的行为，也没有删除文件的行为。
网络行为监控可以看到send,receive动作，应该是从C&C服务器接收了下一阶段的恶意负载。重点看了一下注册表里面没有找到用于持久性控制的键值修改。
0x03 binary分析
IDA静态分析
原则：先静后动
反调试：
我采取的办法是直接对照着IDA，在OD中把第二个函数完整的执行了一遍，花费了大概三个半小时，这估计是最笨的方法了吧。但是至少搞清楚了程序流程。
关键函数是sub_4534B0()，在它来到关键函数之前，恶意软件还设置了某几个文件夹的属性，如
C:UsersAdministratorAppDataRoamingMicrosoftWindowsCookies
难道要窃取cookie？调试后定位到关键函数，其实这个应该就是主函数，ida没有识别出来：
从00515000—0051531F，更有意思的是在payload尾部发现了C&C服务器的ip地址。而且之后调试发现，整个程序都是使用的这种手法来执行自己的payload。payload分析：
OD动态分析
第一步：关闭样本的aslr，方便进行分析和调试。载入peview
00020068处是进行网络通信时用到的API函数的ASCII码
LPVOID VirtualAlloc{LPVOID lpAddress, // 要分配的内存区域的地址DWORD dwSize, // 分配的大小DWORD flAllocationType, // 分配的类型DWORD flProtect // 该内存的初始保护属性};
这个位置是随机的，之后会调用InternetReadFile()，将第二段负载读到此处。
第二段payload已经被读入
把PE文件dump出来
查壳
本例中是直接在内存中进行执行。说一下要点：因为之前有CTF经验，在静态分析时快速识别出来base64算法和AES算法。Base64码表：
‘=’补齐：
标准的HttpSendRequestA系列API进行网络请求：
0x04攻击流程
通过xor操作达到免杀的目的，这个binary的作用相当于一个downloader，用于下载下一阶段的恶意负载。通过对请求的url的判断，提高了自己的隐蔽性，在合适的时机被攻击者唤醒。
样本还有一个亮点是全程没有落地，通过VirtualAlloc()分配内存，将payload复制进内存进行执行，给我逆向分析的过程中带来了不少的麻烦。样本检测通过社区的yara规则即可检测为恶意样本。
0x05 IOC
“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 关联分析
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论