CloudMeeting_Win_1.3.1.exe样本分析
基本信息
样本概述
该样本是一个钓鱼邮件中的附件程序，cobaltstrike生成的木马加了些反调试。
样本发现日期
2021.04.12
样本类型
钓鱼邮件/远控程序
样本文件大小/被感染文件变化长度
6045184 (bytes)
样本文件MD5校验值
md5,5E3B3732BD5E4D0C1254B1958E87AA53
样本文件SHA1校验值
sha1,11F7D01691FE2DE3A6BB73F5B8B99BC42B2DE3BD
样本文件SHA256校验值
sha256,D4EE34A773E901029EF165E4DD211957A79E4AB38A26D848192A8B339FFC9D62
壳信息
未加壳
可能受到的威胁的系统
64-bit
相关漏洞
未涉及
已知检测名称
CloudMeeting
被感染系统及网络症状
文件系统变化
样本运行之后会先释放_install.exe，在释放install.exe
释放路径
C:\Sandbox\mac\DefaultBox\user\current\AppData\Local\Temp
注册表变化
进行一系列注册表读取
网络症状
抓包发现install.exe发起网络请求如下：
详细分析/功能介绍
静态调试
我们将样本拖入IDA,查看字符串
从字符串上来看，这应该是cs的一个go的插件生成的
入口函数地址450A50，乱七八糟的运算就不分析了只分析有用的运算
打开之后发现，程序并不大有用的东西也没多少，填充了大量的垃圾数据以及无用的逻辑运算
看一下字符串，几乎也是一些乱七八糟看起来没多大用的东西
看到最后发现有一个kernel32.dll，双击进去
从数据段看应该是样本主要功能
跟进sub_429470函数，查看sub_429470的交叉引用
发现sub_42E300应该是刚样本的后门程序主体，而且没有其他交叉引用
我们跟进，调用了GetStdHandle
根据程序运行以及程序流程图概况，这块应该是创建install.exe
我们继续跟进数据段的53CB0D,这应该是go的数据结构地址空间存储，发现该样本应该是和go有关
继续跟进到42A414，出现了一个函数SetWaitableTimer，它的作用就是一个无界面的定时器
查看其伪代码,通过各种运算判断应该是起到一个延时作用
继续跟进，获取当前目录路径
从静态看目前只分析出这些，因为样本字符串以及汇编没有分析出相关的函数引用，所以具体还得看动态调试
动态调试
将样本用x64dbg打开,由于我们在静态分析的时候发现他有CreateFile操作，所以我们在此下断点,下了断点之后，F4运行到当前断点时程序停止调试了，应该是遇到反调试了，我们将样本丢入微步，给的是反检测行为是利用GlobalMemoryStatusEx
// GlobalMemoryStatusEx Sample output:
// There is 51 percent of memory in use.
// There are 2029968 total KB of physical memory.
// There are 987388 free KB of physical memory.
// There are 3884620 total KB of paging file.
// There are 2799776 free KB of paging file.
// There are 2097024 total KB of virtual memory.
// There are 2084876 free KB of virtual memory.
// There are 0 free KB of extended memory.
#include <windows.h>
#include <stdio.h>
#include <tchar.h>
// Use to convert bytes to KB
#define DIV 1024
// Specify the width of the field in which to print the numbers.
// The asterisk in the format specifier "%*I64d" takes an integer
// argument and uses it to pad and right justify the number.
#define WIDTH 7
void _tmain()
{
MEMORYSTATUSEX statex;
statex.dwLength = sizeof (statex);
GlobalMemoryStatusEx (&statex);
_tprintf (TEXT("There is %*ld percent of memory in use.\n"),
WIDTH, statex.dwMemoryLoad);
_tprintf (TEXT("There are %*I64d total KB of physical memory.\n"),
WIDTH, statex.ullTotalPhys/DIV);
_tprintf (TEXT("There are %*I64d free KB of physical memory.\n"),
WIDTH, statex.ullAvailPhys/DIV);
_tprintf (TEXT("There are %*I64d total KB of paging file.\n"),
WIDTH, statex.ullTotalPageFile/DIV);
_tprintf (TEXT("There are %*I64d free KB of paging file.\n"),
WIDTH, statex.ullAvailPageFile/DIV);
_tprintf (TEXT("There are %*I64d total KB of virtual memory.\n"),
WIDTH, statex.ullTotalVirtual/DIV);
_tprintf (TEXT("There are %*I64d free KB of virtual memory.\n"),
WIDTH, statex.ullAvailVirtual/DIV);
// Show the amount of extended memory available.
_tprintf (TEXT("There are %*I64d free KB of extended memory.\n"),
WIDTH, statex.ullAvailExtendedVirtual/DIV);
}
检测系统内存大小来判断是否是在虚拟机，对抗方法也很简单，增大虚拟机的CPU核数和内存
我们复制一个虚拟机，然后我们增加其中一个虚拟机配置以后样本可以跑起来
我们未增加配置的虚拟机的x64dbg上在GlobalMemoryStatusEx出下断，运行到当前断点后，由于我们ida和x64dbg的基地址是一致的，所以我们尝试在ida找到有关GlobalMemoryStatusEx的运行逻辑，谁调用的它，但是没有找到，可能是加载了kernel32.dll之后运行了某段代码，所以静态看不到，我们开启运行追踪，打开自动步过
我们发现在0x4B1807出停下
我们打开打开增加完配置的虚拟机在相同位置调试，发现是直接通过调试的
那说明，这个位置就是反调试的位置，我们回到ida，跳转到0x481803
切换到汇编，然后查看交叉引用
下边sub_42A100/sub_42160.....调用逻辑都是一致的，我们只分析sub_42A040
我们发现这里有引用sub_42A040，同时发现ida分析出来在sub_4292F0有上一级引用，我们跟进
我们发现样本获取系统环境,通过GetEnvironmentStringsW返回的值对进行各种判断,我们通过伪代码便可以看出
我们在跟进上一级，发现sub_42E5F0跳转到sub_425F0,并且stat_0入口函数call了这个
这就应该是GlobalMemoryStatusEx反调试执行流程
,我们发现该样本释放了两个文件，一个是install.exe一个是_installs.exe
我们使用火绒剑对样本进行追踪发现
install.exe是个壳子，真正对样本主体在_installs.exe中
我们对_installs.exe进行动态调试
获取系统版本
拼接字符串
加载wininet.dll
调用InternetOpenA，InternetConnectA连接C2
调用HttpOpenRequestA，HttpSendRequestA向C2发送连接请求
相关服务器信息分析
| No. |
IoC |
| 1 |
60.217.246.188:443 |
| 2 |
123.129.244.212:443 |
| 3 |
27.221.44.50:443 |
| 4 |
124.132.134.224:443 |
发表于 2021-4-29 10:50
|
发表于 2021-5-6 15:35
