SystemBC僵尸网络劫持了全球1万台设备用于DDoS攻击
SystemBC 恶意软件家族是一种持续性威胁，最早于 2019 年被发现，如今已发展成为一个庞大的僵尸网络基础设施，控制着全球超过 10,000 台被劫持的设备。 该恶意软件主要用作 SOCKS5 代理和后门，使威胁行为者能够掩盖其恶意流量并长期访问受感染的网络。
SystemBC 恶意软件家族是一种持续性威胁，最早于 2019 年被发现，如今已发展成为一个庞大的僵尸网络基础设施，控制着全球超过 10,000 台被劫持的设备。
该恶意软件主要用作 SOCKS5 代理和后门，使威胁行为者能够掩盖其恶意流量并长期访问受感染的网络。
通过将受感染的系统转换为中继，僵尸网络允许攻击者通过受害者的机器路由命令和控制通信，有效地向防御者隐藏其真实位置，并使归因工作变得复杂。
这种“反向连接”架构创建了一个具有弹性的网络，该网络经受住了重大的执法干扰，包括欧洲刑警组织在 2024 年 5 月发起的“终局行动”。
基础设施并没有消失，而是进行了调整，将重点从住宅网络转移到了损害托管服务提供商。
这种战略转变使得感染持续时间比典型的恶意软件活动要长得多，平均系统被感染的时间长达 38 天，有些感染甚至持续超过 100 天。
僵尸网络是勒索软件部署的关键先导，它通过隧道传输流量以窃取数据并进行进一步利用。
Silent Push 的分析师指出，僵尸网络的复苏涉及对全球受感染 IP 地址的复杂追踪。
他们的研究发现，美国是主要目标，拥有超过 4300 台受感染的设备，其次是德国、法国和新加坡。
调查还揭露了敏感政府环境中令人震惊的漏洞，包括越南和布基纳法索境内托管官方网站的高密度服务器。
这些被入侵的资产经常被用来发动其他攻击或支持其他犯罪活动。
未检测到的 Perl 变体分析
此次行动的关键在于发现了一种此前未被记录的、用 Perl 编写的SystemBC变体，该变体专门用于规避传统的安全控制。
与僵尸网络命令基础设施通信的文件中包含这个不寻常的脚本，该脚本最初在主要防病毒引擎中均未被检测到。
这种变种通常由 ELF 二进制文件投放器部署，这些投放器被识别为“SafeObject”和“StringHash”，它们使用 UPX 打包来隐藏其恶意代码，使其无法通过静态分析工具进行分析。
一旦解压，这些投放器就会积极地在主机系统上搜索可写目录，然后执行数百个嵌入式有效载荷。
对投放器代码的调查显示，它异常“嘈杂”，并且充满了俄语字符串，这可能为威胁行为者的来源提供了线索。
由于 SystemBC 基础设施通常会发出入侵链早期阶段的信号，因此建议安全团队优先主动监控这些指标，以防止升级为勒索软件攻击。
关于作者
评论2次
### 结论 SystemBC僵尸网络通过动态基础设施调整（如转向托管服务商）、隐蔽通信协议（Perl变体）及模块化投放机制（如UPX打包的ELF payload）实现长期驻留与抗干扰。核心威胁在于其利用合法隧道流量进行横向移动，且隐蔽性极强，需从代码特征、网络行为和xi统异常三个维度切入排查。 --- ### 分析路径（按T00ls方法论） **L1 攻击面识别** - **Source-Sink链路**： - **Source**：被感染设备（尤其是托管服务商服务器）的开放服务（SSH/FTP/RDP）、弱口令、未修复的远程代码执行漏洞（如CVE-2023-20863）。 - **Sink**：SystemBC通过ELF投放器（如"SafeObject"）在xi统中投放Perl后门，劫持SOCKS5代理流量，最终连接C2（需关注DNS请求异常和隐蔽C2通信模式）。 - **关键攻击路径**： 1. 投放器通过漏洞或弱口令植入xi统（ELF二进制文件）。 2. 运行时解压UPX，搜索可写目录（如`/tmp`）部署Perl后门。 3. Perl后门与C2通信，建立反向隧道，成为DDoS中继或勒索软件跳板。 **L2 假设与验证** - **假设1**：托管服务商服务器因权限高且日志审计不足，成为主要感染目标。 - 验证：检查服务器日志（`/var/log/auth.log`）中异常SSH登录时间，或未授权进程（如`perl -e eval`）。 - **假设2**：Perl变体通过动态代码混淆规避AV检测。 - 验证：静态分析ELF文件（`strings <binary> | grep 'upx'`），检查UPX打包痕迹；解包后用`grep -r 'eval{'; perl`定位动态执行代码。 - **假设3**：C2通信使用DNS隧道或加密混淆协议。 - 验证：抓包分析（`tcpdump port 53 or port 443 -w test.pcap`），用Wireshark检查DNS请求中非标准子域名或TLS证书指纹异常。 **L3 边界/异常场景** - **边界场景1**：托管服务商环境因多租户特性导致横向感染。 - 验证：检查跨主机的异常SSH连接（如`last`命令查看非业务时段登录）、共享存储目录权限异常（如`ls -la /mnt`）。 - **边界场景2**：Perl后门利用xi统服务（如Cron）持久化。 - 验证：审计Cron任务（`crontab -l; ls /etc/cron*`），检查是否包含`/tmp/`路径的定时任务或隐藏的PID（如`ps aux | grep perl`）。 **L4 防御反推与修复** - **防御缺口**： - 防火墙未阻断异常出站流量（如SOCKS5端口1080）。 - Perl解释器未限制执行权限，允许任意脚本运行。 - 日志未集中分析，无法检测长期驻留的隐蔽进程。 - **修复方向**： 1. **网络层**： - 阻断非业务必要端口（如SOCKS5的1080、SSH的22），仅开放最小化服务端口。 - 配置防火墙规则（`iptables -A OUTPUT -p tcp --dport 1080 -j LOG/DROP`）。 2. **主机层**： - 关闭不必要的Perl执行权限（如`chmod -x /usr/bin/perl`），或使用AppArmor/SELinux限制脚本执行范围。 - 安装YARA规则检测UPX打包的ELF文件： ``` rule UpxElf投放器 { strings: $a = {46 4C 45 7F 00 00 00 01} $b = "UPX" condition: $a and $b } ``` 3. **监控层**： - 部署ELK/Splunk分析长期登录尝试（如连续失败SSH登录超过3次触发告警）。 - 监控进程行为：若发现`perl`调用`system()`或`socket()`函数，立即隔离主机。 --- ### 验证步骤（最小可执行方案） 1. **日志溯源**： ``` # 检查异常SSH登录（假设攻击时间在最近30天内） grep 'sshd\[.*Failed password' /var/log/auth.log | \ awk '{print $11}' | sort | uniq -c | sort -nr # 搜索/tmp目录下可疑Perl脚本 find /tmp/ -type f -mtime -30 -exec file {} \; | grep 'Perl script' ``` 2. **流量检测**： ``` # 抓取SOCKS5相关流量 tcpdump 'port 1080 and tcp[tcpflags] & (tcp-syn) != 0' -i eth0 -c 100 # 解析DNS请求中的异常子域 tshark -r test.pcap -Y 'dns.flags.response == 0' -T fields -e dns.qry.name ``` 3. **代码分析**： ``` # 解压UPX打包的ELF文件 upx -d suspicious_binary # 查找Perl后门关键行为（如C2连接） strings suspicious_binary | grep -E 'eval|system|socket|inet_aton' ``` --- ### 修复建议 1. **紧急响应**： - 立即隔离感染主机，阻止其与其他设备通信。 - 清理残留文件：`rm -rf /tmp/可疑目录`，重启服务清除内存驻留进程。 2. **长期防御**： - 部署EDR工具（如CrowdStrike）监控进程树异常（如`init -> bash -> perl`的非正常继承）。 - 对托管服务商环境实施最小权限原则，禁用弱口令并启用多因素认证（MFA）。 3. **情报联动**： - 将C2域名/IP提交至Cloudflare防火墙或本地IDS（如Suricata），更新规则库以覆盖SystemBC的YARA特征。 --- 注：若环境为Linuxxi统，重点检查`/dev/shm`、`/tmp`临时目录及Cron任务；Windows环境则需排查`%TEMP%`及计划任务中的隐藏服务。
僵尸网络的基础设施载体的变化，监控指标值得所有公司重视啊。