1.背景
2024年4月11日，某影视公司的服务器遭受了勒索软件攻击，随后向我司寻求帮助进行恢复。经过我司溯源排查，勒索组织通过一处用友NC资产进行入侵，攻击者利用国产工具横移了数小时后实施勒索。其中一台超融合（vcenter）成了攻击者重要跳板，但也因为这台重要跳板的“端点挂全部挂”的特性，勒索攻击得到了有效地“自动”遏制，最后排查得出30多台服务器被勒索，重要系统被锁定无法使用,溯源过程中还发现了多个挖矿木马，目前尚不清楚该挖矿木马是否与此次勒索病毒组织有关联，但这也揭示了客户网络安全防护的薄弱之处。
经分析，确认该病毒家族为Babuk，加密之后的文件后缀为.babyk。我司解密专家通过多种数据恢复手段成功将加密文件全部恢复，经负责人确认恢复文件内容无误。
在2024年4月11日至2024年4月20日期间，我司组织了6人次的应急响应团队，为客户受害服务器提供数据备份、溯源分析、漏洞修复、网络排查、渗透测试、安全加固等多项工作。同时，公司网络安全实验室的多位安全专家参与了病毒的逆向分析、日志溯源分析和数据恢复工作，运维专家根据目前现场运维环境及网络架构提出了针对性的安全建设意见。整体圆满完成各项任务，达到客户要求指标。
2.溯源分析
2.1 受灾情况统计
2024年4月12日，Solar应急响应团队到达该集团现场，对受灾服务器进行断网并排查，最终排查情况如下：
| 被加密服务器数量 | 33台 |
|---|---|
| 被加密文件总数 | 287938个 |
| 被加密数据大小 | 12.45TB |
| 后门木马 | 62个 |
| 黑客利用工具 | 7个 |
| 数据恢复时长 | 1天 |
| 数据恢复率 | 99％ |
统计出的被加密服务器情况：
| 顺序 | IP | 服务器名称 | 加密时间 | 文件总数 | 加密文件总数 |
|---|---|---|---|---|---|
| 1 | 192.168.0.1 | 1 | 2024.04.07 | 165604 | 14938 |
| 2 | 192.168.0.2 | 2 | 2024.04.07 | 3415114 | 32435 |
| 3 | 192.168.0.3 | 3 | 2024.04.07 | 1723965 | 57963 |
| ...省略数行 |
表中数据已脱敏，仅作示例参考
2.2 最初攻击时间
1.在2024-04-06 21:21:58攻击者（104.234.240.225）探测到一处用友NC6.5资产存在saveXmlToFileServlet任意文件上传漏洞，利用该漏洞成功突破边界拿到了第一个shell。后续用友官方人员利用工具确认了此漏洞存在。
图1 用友自测工具扫描结果图
图2 中间件日志
木马存在一定的混淆特征，将常规的\u给混了，用替换将不合规的全换回来就能看见明文。明文下的webshell也不难理解，参数zxc，传入A83In中，构造ProcessBuilder对象，调用cmd /C 执行A83In，中间符号并无意义。
图3 混淆的jsp木马
图4 解开混淆后的明文
2.3 其他工具利用
2.在2024.04.06-22:37攻击者就上传了s6.exe，经过确认是内防渗透工具fscan.exe。对内网进行扫描，命中了数台主机，其中就有那台“重要的跳板机”vcenter（超融合）。
fscan.exe:一款内网综合扫描工具，该工具支持主机存活探测、端口扫描、常见服务的爆破、ms17010、redis 批量写公钥、计划任务反弹 shell、读取 win 网卡信息、web 指纹识别、web 漏洞扫描、netbios 探测、域控识别等功能。
s6.exe通过命令可进行查看版本信息，为V1.8.3，对比github上的fscan发现hash一致未做编译操作。
SHA1:5a341a41bb909bf577465491420e3fce6001c5cf
版本：V1.8.3
工具链接：https://github.com/shadow1ng/fscan/releases
图5 fscan落地
图6 fscan扫描结果
2.4 日志排查
3.攻击者于2024/4/7 01:32:09使用vck.exe（VcenterKiller利用工具）对vcenter平台进行攻击，分别使用了CVE-2021-21972和CVE-2021-21985。
VcenterKiller：一款针对Vcenter的综合验证工具，包含目前最主流的CVE-2021-21972、CVE-2021-21985以及CVE-2021-22005，提供一键上传webshell，命令执行或者上传公钥并使用SSH连接的功能，以及针对Apache Log4j CVE-2021-44228漏洞在Vcenter上的检测以及利用。
vck.exe通过命令可进行查看版本信息，为V1.3.6，对比github上的VcenterKiller发现hash一致未做编译操作。SHA1:804858fc2546fc9cd60eb075082b118ffaeb18a8
版本：V1.3.6
工具链接：https://github.com/Schira4396/VcenterKiller/releases/tag/v1.3.7
图7 首次开始攻击vcenter平台
4.攻击者在2024/4/7 02:27成功对vcenter上传shell，并在2024/4/7 02:28:53访问webshell进行操作。攻击期间攻击者于2024/4/7 1:46上传了另一个木马，里面有一个IP185.196.11.210，在日志里并没有成功触发。
图8 vcenter上webshell落地时间
图9 访问webshell开始进行攻击
图10 offline_bundle木马
5.在2024/4/7 3:06，攻击者翻到了vcenter的凭证，因此在2024/4/7 3:57:05登陆了vcenter平台直接对其他主机的攻击。此刻的攻击者还没意识到“问题”所在。
图11 打包凭证xxs.zip
图12 成功登陆vcenter平台
6.攻击者利用vcenter平台于2024/04/07 4:29:3登陆第六台服务器和第七台服务器，在上面直接对服务器进行攻击操作。
图13 成功登陆第六台服务器
图14 成功登陆第七台服务器
7.在2024/04/07 4:35:48，攻击者在第七台服务器上使用rdp连接第五台服务器，并发现该数据主机的rdp密码。
图15 利用rdp登陆第五台服务器
图16 第七台服务器上记录了第五台服务器的密码
8.后续我们通过恢复手段发现，攻击者在2024/04/07 04:46左右返回了vcenter利用上面获得的密码登陆第五台服务器，并做了frp代理（工具已删除）。
图17 攻击者利用vcenter登陆第五台服务器
图18 frp执行证明贴图
9.攻击者在第五台服务器上翻找，打开了运维常用的secureCRT，里面恰好记录两台主机的密码，这样第五台服务器成为了下一个跳板。
图19 SecureCRT登陆缓存
10.由于加密的工具均被删除，利用everything可以得知加密开始时间为2024.04.07 05:09。
图20 加密开始时间
11.攻击者在于2024.04.07 06:34:50将操作日志全部清除。但是攻击者想不到的是，加密完一部分主机后，其他横不过去了宕掉了。原因在于，这款超融合的特性，只要下面的节点（端点）挂掉，其他的就不能登上去了，而vcenter在超融合里自然就过不去了，勒索攻击至此被“自动”遏制了。
图21 日志被清除
12.攻击者104.234.240.225属于加拿大 多伦多，同段多为代理和木马主机。
图22 攻击者IP溯源
13.对用友NC6.5系统进行渗透测试，同时厂家用友对该系统进行全面扫描，发现确实存在文件上传漏洞，与上述吻合。
图23 我方人员渗透测试贴图
图24 厂家用友扫描贴图
2.5 后门排查
img
图1 黑客使用的工具
图2 黑客上传的木马
图3 黑客地址
图4 勒索信内容
图5 加密后缀
2.6 详细攻击路径
2024年3月24日，根据对日志的调研分析，安全专家已梳理出入侵路线如下（已脱敏）：
攻击者在2024/04/07针对集团主机实施勒索攻击，在2024/04/06通过对用友NC6.5系统漏洞进行利用成功获取webshelll，随后对内网进行扫描获取vcenter平台的登陆权限。攻击者在2024/04/07通过vcenter平台登陆其中一台受害主机拿到第五台服务器的RDP密码，之后在第五台服务器主机的运维工具上获得其他受害主机的密码。最后攻击者在2024/04/07 5:09实施勒索攻击。期间攻击者利用IP185.196.11.210、104.234.240.225均被判定为恶意IP，由于攻击者将windows日志和其他重要日志清除，无法捕获加密器。
3.恶意文件分析
溯源过程中我们提取到了加密器并且还提取到了疑似黑客留下的其他攻击工具、挖矿木马，下文一一进行了列举分析，因受篇幅影响，针对加密器的分析会在下篇文章进行推送。
3.1 gykauy.exe文件信息
| 大小 | gykauy.exe(221277 bytes) |
|---|---|
| 操作系统 | Windows |
| 架构 | i386 |
| 类型 | exe |
| 字节序 | Little Endian |
| SHA256 | 2f10ce62e3fcf5c0b2db110211503bc0b857226b65e826300d14af0c040dd7d8 |
| 大小 | gykauy.exe(221277 bytes) |
| 操作系统 | Windows |
| 架构 | i386 |
3.1.1 混淆去除
两种混淆模式:
1.利用异常,抛出异常后接收,干扰控制流分析。
2.类似vmp的垃圾指令,执行但不影响程序环境.这张图中,混淆指令从0x401189开始,到达0x4011f1结束。
ida的解析：
3.1.2 第一层外壳文件逆向分析
以下分许全部基于去除混淆之后的idb文件。
3.1.2.1 主函数
简单地输出调试信息,再检测命令行是否为字符串”Win7”.然后跳入对应的函数,这些函数的区别在第二层壳中显示出。
解密pe文件,并加载,后跳至导出表的不同函数。
3.1.2.2 解密函数
简单的异或加密,中间加了Sleep对抗沙箱.
3.1.2.3 加载pe文件
常规加载方式,分配内存,解析重定位,填充iat,恢复页面属性,调用入口函数.
加载主函数:
int *__cdecl load_pe(_DWORD *a1)
{
int *result; // eax
char *v2; // edi
int *v3; // esi
HANDLE ProcessHeap; // eax
int *v5; // ebx
char *v6; // eax
char *v7; // eax
int *v8; // ecx
int v9; // eax
int *v10; // eax
int *v11; // [esp+10h] [ebp-4h]
if ( *(_WORD *)a1 != 'ZM' )
return 0;
v2 = (char *)a1 + a1[15];
if ( *(_DWORD *)v2 != 'EP' )
return 0;
v3 = (int *)VirtualAlloc(*((LPVOID *)v2 + 13), *((_DWORD *)v2 + 20), 0x2000u, 4u);
v11 = v3;
if ( !v3 )
{
result = (int *)VirtualAlloc(0, *((_DWORD *)v2 + 20), 0x2000u, 4u);
v11 = result;
if ( !result )
return result;
v3 = result;
}
ProcessHeap = GetProcessHeap();
v5 = (int *)HeapAlloc(ProcessHeap, 0, 0x14u);
v5[1] = (int)v3;
v5[3] = 0;
v5[2] = 0;
v5[4] = 0;
VirtualAlloc(v3, *((_DWORD *)v2 + 20), 0x1000u, 4u);
v6 = (char *)VirtualAlloc(v3, *((_DWORD *)v2 + 21), 0x1000u, 4u);
qmemcpy(v6, a1, *((_DWORD *)v2 + 21) + a1[15]);
v7 = &v6[a1[15]];
*v5 = (int)v7;
*((_DWORD *)v7 + 13) = v11;
alloc_segs((int)a1, (int)v2, v5);
v8 = (in
扫一扫
1234
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
