文章总结: 该报告详细分析了2026年7月发现的nadmesh僵尸网络,它是一款针对AI基础设施的产业级恶意软件。其核心特点包括自治扫描引擎、20余种漏洞利用向量、定向收割AI服务凭证、产品化运营及多态构建。攻击链涵盖情报收集、控制、补给、构建与投递五个环节,并具备持久化双保险机制。报告揭示了攻击者明确的商业意图和长期演进形态,建议加强AI服务安全防护。 综合评分: 85 文章分类: 恶意软件,漏洞分析,威胁情报,红队,安全工具
NadMesh僵尸网络分析:人工智能服务时代的产品级威胁
原创
奇安信X实验室 奇安信X实验室
奇安信XLab
2026年7月17日 16:02 北京
在小说阅读器读本章
去阅读
概述 2026 年 7 月初,我们注意到一个用 Go 语言编写的僵尸网络正在向互联网大规模投递 Bot 样本。它把扫描、漏洞利用、凭证与 AI 服务情报收割整合在同一套自治平台里。由于其控制端在代码中自称 n4d mesh controller,我们将其命名为 NadMesh。 NadMesh 并非一次性的蠕虫爆发,而是一个长期迭代、目标明确指向 AI 基础设施与 MCP 生态的自治型僵尸网络。它区别于传统蠕虫的地方在于: * 自治扫描引擎:内置 90+ 个云服务商地址段,无人值守持续扩散 * 20+ 漏洞利用向量:覆盖 Redis、Docker、MCP、K8s 等多种服务的 RCE * AI 服务定向收割:通过 Shodan 搜集 ComfyUI、Ollama 等 AI 服务 IP,并赋予最高扫描优先级 * 产品化运营:内置 Web 面板、转化漏斗统计、金丝雀更新,运营全程可观测 * 持久化双保险:SSH 公钥后门 + Agent 进程 + Cron 看门狗,单点清除难以根除 * 多态构建:Garble 混淆 + UPX 压缩 + 随机填充,每份 Agent 哈希互异 综合来看,NadMesh 的威胁本质不是脚本小子的拼凑,而是有明确商业意图、注重投入产出比的产业级恶意软件,呈现出明显区别于传统蠕虫的「长期演进型」形态。
NadMesh 目前仍处于起步阶段,感染趋势如下:
我们观察到的 NadMesh 漏洞利用分布: 
#
#
NadMesh 完整攻击杀伤链
通过对样本文件的详细分析,我们发现 NadMesh 整体是一套以攻击者 VPS 为中枢、目标网络为执行面的自治化闭环攻击平台,运营模式高度产品化。整条杀伤链可以拆成「情报 → 控制 → 补给 → 构建 → 投递」五个协同环节。
情报侧由 ai_harvest.py 承担,它借助 Shodan API 定向搜集 ComfyUI、Ollama、n8n、Open WebUI、Langflow、Gradio 等 AI/MCP 服务资产,并以最高优先级(priority=20)注入扫描队列——这是其攻击意图明确指向 AI 基础设施的最直接证据。
控制侧是 controller_go.go,监听 80/8443 端口,负责 Bot 注册与 beacon 回连、下发 CIDR + 端口扫描任务、回收部署结果与凭证情报,并通过 /panel 可视化面板实现对整个僵尸网络的可观测运营。
补给侧由四个脚本构成任务自治供给回路:yield_generator.py 放大高产网段、auto_inject.sh 周期重扫危险 IP、reinject.sh 做全量高优先级重扫、auto_blacklist.sh 自动规避蜜罐 IP。这套回路让「扫描—利用—再扩散」无需人工干预即可持续放大。
构建与投递侧,build_agent.sh 采用 Garble 符号/字面量混淆 + UPX-9 压缩 + 随机填充的多态构建策略,保证每份 Agent 哈希互异以对抗特征检测;随后由 vps_deployer.py(Docker/MCP/Redis 三向量)与 push_deployer.py(二进制 + watchdog 推送)负责主动投递部署。
在受害端,Bot Agent 落地后通过三条路径完成持久化:
-
写入 SSH 公钥后门:
-
.ssh/authorized_keys
-
落多路径持久化文件:
-
/dev/shm/.a
-
/var/tmp/.a -
/tmp/.a -
植入隐蔽 Cron 看门狗:
-
/etc/cron.d/.sys_monitor -
/etc/cron.d/.s
任何单点清除都会被其余路径拉起。同时它承担 30 端口探测、服务识别、20+ 向量 RCE 投递、内网扫描与凭证抓取,并以 beacon 形式与主控及同网段节点保持 P2P 联动,形成横向自扩散能力。
NadMesh 控制端功能分析
NadMesh 控制端有 Golang 和 Python 两个版本,功能基本一致。本文主要分析 Golang 版本,文件名 controller_go.go,代码中作者自称 “n4d mesh controller”。
整体架构
作者在注释里写下了自己的设计哲学:
In-memory hot path: sync.Map + channels + ring buffers. DB only for background persistence.
也就是读路径全走内存、零 DB 查询,写路径异步批量落库。这个取舍让单机就能扛住高并发的 Bot 流量。
认证机制
#
控制端有三套彼此独立的认证。
Bot 鉴权(verifyBotAuth)走 HMAC:
-
请求头
X-Mesh-Auth: <node_id>:<hex_hmac> -
算法为
HMAC-SHA256(meshKey, "<node_id>:<unix_ts>")。 -
服务端以当前时间 ±60 秒为窗口共迭代 121 次,并用
hmac.Equal做常量时间比较以防时序侧信道。
操作员鉴权(verifyOperatorAuth)最为简陋:
- 仅检查
X-Operator-Key头与opKey明文等值。
面板 Cookie 鉴权则相对完整:
- 登录密码即
opKey,用subtle.ConstantTimeCompare比较; - 登录成功后下发 cookie
n4d_panel = sha256(opKey + "YYYY-MM-DD-HH") - 每小时轮换,校验时同时接受当前小时与上一小时窗口以防边界失效
- Cookie 带 HttpOnly、SameSite=Lax,HTTPS 下附加 Secure,MaxAge 86400。登录还有限速:每 IP 10 分钟 5 次,超限返回 429。
此外,Bot 上报的主机画像(profile)经 xorDecrypt 解密——base64 解码后与 meshKey 循环 XOR,强度聊胜于无。
鉴权由中间件分层落实:
- openEndpoints:注册、beacon、二进制下载、更新检查等无需鉴权(beacon 回连用
?k=token 或干脆无认证) operatorEndpoints:intel/chains/stats/conversion 的 GET 需操作员鉴权``3其余/api/路径强制 Bot HMAC 鉴权/api/result/故意开放,供 Bot 提交扫描结果
HTTP 端点功能清单
NadMesh 自治扫描与任务调度
扫描端口集(30 个)
80,443,3000,5000,8000,8080,8443,8888,9000,9999,6443,10250,9200,22,23,8088,2718,8090,10000,2379,8848,8265,8188,5678,11434,7860,5432,3306,2375,2376,6379
覆盖的服务面:
任务补给机制(自适应反馈)
#
yield_generator.py —— 高产网段放大扫描
# 每5分钟执行一轮:# 1. 查询24h内dangerous != '[]' 的results# 2. 按/16前缀聚合,取top50高产网段# 3. 从这些网段随机生成2000个/24任务# 4. priority=10注入 (高于随机但低于危险IP)
效果很直接:扫描越出成果的网段,越会被密集再扫,形成正反馈循环。
auto_inject.sh —— 危险 IP 周期重扫
# 每15分钟执行:# 1. 24h内 dangerous != '[]' 的IP作为/32高优先级(priority=20)重扫# 2. AI服务端口优先: 8188/11434/7860/5678# 3. 同时从130个精细化云服务商/16前缀随机生成500个/24 (priority=5)
reinject.sh —— 全量高优先级重扫
INSERT INTO tasks (cidr, ports, priority=50)SELECT DISTINCT ip||'/32' FROM resultsWHERE dangerous != '[]' AND created_at > now()-604800 -- 7天 AND ip NOT IN honeypot_blacklist;
三个脚本叠加,形成清晰的优先级梯队: 
蜜罐自动黑名单
-- auto_blacklist.sh 每小时执行INSERT INTO honeypot_blacklist (ip, reason='auto: 10+ deploys')SELECT target_ip FROM deploysWHERE status NOT LIKE 'fail_%'GROUP BY target_ip HAVING count(*) >= 10;
判定逻辑是:对同一 IP 部署 ≥10 次仍拿不到结果,即认定为蜜罐并自动拉黑。这说明作者已经意识到安全研究人员的存在,并主动做了规避。
#
NadMesh Agent 远控能力与漏洞利用向量
扫描与识别(Bot 侧)
Bot Agent 的扫描任务流程如下:
值得注意的是兜底机制:即便控制端任务队列耗尽,Bot 也会自行生成随机 /24 继续扫描,不会闲置。
20+ RCE 向量清单
控制端支持的利用方式,按优先级排列:
部署结果分类
Agent 上报的 status 在控制端被归为四类,这套分类直接支撑了面板上的转化漏斗统计:
NadMesh 凭证与 AI 情报收割
情报字段(Agent 上报)
Agent 在入侵成功后立即采集的情报类型:
这份结构透露出攻击者真正在意的东西:不是主机本身,而是主机上的云凭证、K8s 集群权限、AI 模型访问权和可利用的 MCP 工具。
Shodan AI 服务定向收割(ai_harvest.py)
#
情报面板展示
控制端面板会统计并展示以下几类收割成果:
-
凭证数: 唯一 AWS AccessKeyId 数量
-
MCP 漏洞: 可利用的 execute_sql / execute_shell 服务数量
-
AI 模型: Ollama(llama2/mistral)+ ComfyUI + Open WebUI
-
K8s ServiceAccount: 集群权限 token
-
环境变量凭证: 可跨主机复用的凭证
-
Docker 主机: 可逃逸的容器宿主
#
IoC
C2209.99.186[.]235cdnorigin[.]net Sample SHA131c69b3e12936abca770d430066f379ec1d997ec
免责声明:
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。
任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我。
本文转载自:奇安信XLab 奇安信X实验室 奇安信X实验室《NadMesh僵尸网络分析:人工智能服务时代的产品级威胁》
版权声明
本站仅做备份收录,仅供研究与教学参考之用。
读者将信息用于其他用途的,全部法律及连带责任由读者自行承担,本站不承担任何责任。








评论