RustDuck: 双阶段僵尸网络深度剖析
原创 奇安信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建立严格的身份确认：
login (0xa0): 客户端生成 16 字节随机密文，并上报当前架构、CPU 核心数、内存大小。
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 SHA18315f650e9e4f67c00277b076ab304eed23db47d6aa791c76b3107fca9d57b7ecea8f46d97d837384d11bd496da82d15b3ed13050f414e44f5a892d4d39a3ee96be6b8f5238cb1253514ab55c88f714c
C2 Domaingayporn.twilightparadox[.combigniggadick.ignorelist[.comilovefemboy.mooo[.comigmc.duckdns[.orgqewqewqewqtq.duckdns[.orgqewqewqewqtqthree.duckdns[.orgqewqewqewqtqtwo.duckdns[.orgdisciplinenahidwin[.stcriminalcloudflare[.onlinedhdsjsdjxc.duckdns[.orgfcfrfxrfrsfs5f.duckdns[.org