NadMesh僵尸网络分析：AI服务时代的产品级威胁

Xlab

2026年7月17日 • 13 min read

概述

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 的威胁本质不是脚本小子的拼凑，而是有明确商业意图、注重投入产出比的产业级恶意软件，呈现出明显区别于传统蠕虫的「长期演进型」形态。

截屏2026-07-10 12.35.21.png

NadMesh 目前仍处于起步阶段，感染趋势如下：

截屏2026-07-10 12.17.24.png

我们观察到的 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 联动，形成横向自扩散能力。

┌──────────────────────────────────────────────────────────────────┐
│                   Attacker VPS (/opt/scanner/)                   │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ① 情报采集 (ai_harvest.py)                                      │
│     ├─ Shodan API查询 AI服务IP                                   │
│     ├─ 目标：ComfyUI/Ollama/n8n/Open WebUI/Langflow/Gradio      │
│     └─ 注入为高优先级 (priority=20) 扫描任务                      │
│                                                                  │
│  ② 主控制端 (controller_go.go :80/:8443)                          │
│     ├─ 接收bot注册/beacon回连                                    │
│     ├─ 下发扫描任务 (CIDR+ports)                                 │
│     ├─ 收集部署结果/凭证情报                                     │
│     └─ 可视化管理面板 (/panel)                                   │
│                                                                  │
│  ③ 任务自治补给                                                  │
│     ├─ yield_generator.py：根据扫描成果放大高产网段              │
│     ├─ auto_inject.sh：周期性注入危险IP重扫                      │
│     ├─ reinject.sh：全量高优先级重扫                             │
│     └─ auto_blacklist.sh：蜜罐IP自动黑名单                      │
│                                                                  │
│  ④ Agent多态构建 (build_agent.sh)                                │
│     ├─ Garble 符号/字面量混淆                                    │
│     ├─ UPX -9 压缩 + 特征抹除                                    │
│     └─ 随机填充多态，每份哈希不同                                │
│                                                                  │
│  ⑤ 主动投递部署                                                  │
│     ├─ vps_deployer.py (Docker/MCP/Redis三向量)                  │
│     └─ push_deployer.py (二进制+watchdog推送)                    │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘
                            ▼ HTTP /api/*
┌──────────────────────────────────────────────────────────────────┐
│                  Target Network (Internet)                        │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  受害机A (Victim Host)          受害机B (Victim Host)            │
│  ┌──────────────────┐          ┌──────────────────┐             │
│  │ Beacon投递       │          │ 扫描 + 利用      │             │
│  │ ├─ SSH后门写入   │          │ ├─ 30端口探测    │             │
│  │ ├─ Loader下载    │          │ ├─ 服务识别      │             │
│  │ └─ Agent执行     │          │ ├─ RCE投递       │             │
│  │                  │          │ └─ 凭证回传      │             │
│  │ Bot Agent v31+   │          │                  │             │
│  │ ├─ 内网扫描      │◄────────►│ NadMesh P2P扩散    │             │
│  │ ├─ 凭证抓取      │ beacon   │                  │             │
│  │ ├─ 持久化维护    │          │ Docker/Redis等   │             │
│  │ └─ C2回连        │          │ 未授权服务       │             │
│  └──────────────────┘          └──────────────────┘             │
│                                                                  │
│  → 持久化文件                  → Cron任务                        │
│    /dev/shm/.a                   /etc/cron.d/.sys_monitor       │
│    /var/tmp/.a                   /etc/cron.d/.s                 │
│    /tmp/.a                                                       │
│    .ssh/authorized_keys                                          │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

NadMesh 控制端功能分析

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

整体架构

                ┌─────────────────────────────────────────────┐
   运营者 ────► │  Operator Web Panel  (/panel,  cookie 鉴权)   │
                │  Overview/Bots/Profiles/Intel/Deploys/...     │
                └─────────────────────┬───────────────────────┘
                                      │  X-Operator-Key / cookie
   ╔══════════════════════════════════╪══════════════════════════╗
   ║  controller_go.go  (HTTP :80/:8443, 伪 nginx 头)            ║
   ║                                                              ║
   ║  ┌─ Auth 层 ─────────────────────────────────────────────┐ ║
   ║  │ Bot: HMAC-SHA256(meshKey, nid:ts)  ±60s 窗口          │ ║
   ║  │ Operator: X-Operator-Key == opKey                     │ ║
   ║  │ Panel: cookie = sha256(opKey+小时) 每小时轮换          │ ║
   ║  └───────────────────────────────────────────────────────┘ ║
   ║                                                              ║
   ║  热路径(纯内存)         │   冷路径(异步批量写)               ║
   ║  sync.Map nodeRegistry  │   backgroundWriter → PostgreSQL   ║
   ║  taskCh chan(100k)      │   flushNodesLoop (30s)            ║
   ║  findings/deploys/intel │   refillLoop (30s)                ║
   ║  环形缓冲 + 速率桶       │                                   ║
   ╚══════════════════════════╪══════════════════════════════════╝
                             │  HTTP API
        ┌────────────────────┼────────────────────┐
        ▼                    ▼                    ▼
   受控 Bot (Go agent)   扫描目标 (全网 /8)     第三方: Shodan / ip-api
   - 注册/beacon         - 30+ 端口探测          - ai_harvest.py 喂养
   - 拉任务/交结果        - 20+ RCE 向量利用      - geoLookup 地理
   - 上报情报/画像        - beacon 回连扩张

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

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 需操作员鉴权
其余 /api/ 路径强制 Bot HMAC 鉴权
/api/result/ 故意开放，供 Bot 提交扫描结果

HTTP 端点功能清单

路径	方法/鉴权	功能
`/api/status`	开放	心跳，返回 `binaryToken`（版本指纹）
`/api/register`	开放	Bot 注册/上线，upsert 节点，异步地理定位
`/api/beacon`	开放	投递初始感染 shell 脚本（SSH 后门 + 下载 loader）
`/api/agent/binary(.gz)`	开放	下发 agent 二进制（按 arch）
`/api/agent/loader`	开放	下发 722KB 轻量 loader（后台再拉 full）
`/api/agent/full` / `/minimal`	开放	下发完整 agent
`/api/agent/download`	token(`?k=`)	带 token 校验的下载
`/cdn/<binaryToken>/assets/img.bin`	开放	伪装成静态资源的二进制分发
`/api/bot_update.py`	开放	下发 Python 更新脚本
`/api/update/check`	token	检查稳定版更新
`/api/update/canary`	token/bot	金丝雀更新（A/B 灰度）
`/api/update/health` `/promote`	—	更新健康检查/晋升（占位）
`/api/client/update`	开放	直返 latest_update.json
`/api/endpoints`	开放	返回 C2 端点列表（含 CDN fallback）
`/api/peers`	bot	返回 P2P 对等节点列表
`/api/task/<nid>`	bot	Bot 拉取扫描任务（CIDR+端口）
`/api/result/<nid>`	开放	Bot 上报扫描发现
`/api/deployed`	bot	Bot 上报漏洞利用部署结果
`/api/intel`	GET 操作员 / POST bot或操作员	情报上报与查询（凭证/AI/MCP）
`/api/chains` `/chains/refresh` `/chains/result/`	bot/操作员	多步利用链
`/api/conversion`	操作员	24h 部署转化漏斗
`/api/tasks/add`	bot（实为操作员用）	手动注入扫描任务
`/api/seeds`	bot	批量 `ip:port` 种子注入
`/api/health`	开放	运行时指标（goroutine/内存/DB）
`/panel/login` `/logout`	—	面板登录/登出
`/panel/api/*`	cookie	面板后端 API（overview/bots/profiles/intel/deploys/findings/blacklist）
`/panel/`	cookie	面板 SPA

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

覆盖的服务面：

Web：80/443/3000/5000/8000/8080
Kubernetes：6443（API）/10250（kubelet）/2379（etcd）
数据库：5432（PostgreSQL）/3306（MySQL）/6379（Redis）
容器：2375/2376（Docker API）
监控：9200（Elasticsearch）
AI 服务：8188（ComfyUI）/11434（Ollama）/5678（n8n）/7860（Gradio）← 优先攻击目标
管理：10000（Webmin）/8090 等

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

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

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

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

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

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

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

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

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

优先级	含义
50（最高）	确认危险的 IP 全量重扫
20（高）	24h 内的危险发现、Shodan 收割的 AI 服务
10（中）	高产网段放大
5（低）	随机新增网段
0（最低）	Bot 拉不到任务时即时生成的 /24

蜜罐自动黑名单

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

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

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

扫描与识别（Bot 侧）

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

Bot ──GET /api/task/<nid>──→ Controller
            ↑
            │
        获取任务：CIDR + ports
        └─ 若无任务，即时生成随机/24 (兜底机制)
        
Bot ──扫描 CIDR/ports──→ 发现目标
    ├─ 端口开放检查
    ├─ 服务识别 (banner grab)
    ├─ 漏洞检测 (版本指纹)
    └─ 危险标记 (dangerous=true)

Bot ──POST /api/result──→ Controller (回传发现)

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

20+ RCE 向量清单

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

服务	攻击向量	风险等级	备注
MCP	JSON-RPC tools/call → execute_command	高	AI时代核心威胁
Kubernetes	API创建Pod + 挂载hostPath	高	集群逃逸
Docker API	/containers/create + host网络 + always重启	高	容器逃逸
Redis	CONFIG SET dir + dbfilename + SAVE	高	无认证常见
Elasticsearch	脚本RCE (_search)	高	未授权普遍
SSH/Telnet	弱口令爆破	中	部署后门
Jenkins	Script Console RCE	中	管理员弱口令
Spring Cloud Gateway	表达式注入	中	版本限制
code-server	API执行命令	中	无认证暴露
Airflow/Superset/XXL-Job	DAG/Admin API RCE	中	弱鉴权/默认凭证
WebLogic	反序列化RCE	中	CVE-2016-0638等

部署结果分类

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

status: "docker_push"   → 分类: "success"   (Docker RCE成功)
status: "mcp_sql_rce"   → 分类: "success"   (MCP SQL执行)
status: "redis_save"    → 分类: "success"   (Redis cron持久化)
status: "ssh_deploy"    → 分类: "success"   (SSH后门部署)
status: "beacon_start"  → 分类: "exploit_sent"  (Beacon已下发)
status: "timeout"       → 分类: "failed"    (无反应)
status: "hw_suspect"    → 分类: "intel"     (蜜罐嫌疑，不入库)
status: "os_profile"    → 分类: "intel"     (画像情报)

NadMesh 凭证与 AI 情报收割

情报字段（Agent 上报）

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

{
  "node_id": "bot_id_hash",
  "metadata": {
    "profile": {
      "hostname": "prod-server-01",
      "os": "linux",
      "arch": "x86_64",
      "kernel": "5.10.0",
      "env_creds": ["AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE"],
      "services": ["redis", "docker", "k8s"],
      "internal_ranges": ["10.0.0.0/8", "172.16.0.0/12"],
      "k8s_sa": "ServiceAccount token with cluster-admin...",
      "docker_host": true,
      "in_container": false
    },
    "aws_creds": ["AKIA..."],
    "bedrock_creds": [...],
    "ssh_sessions": [...]
  },
  "files": {
    "aws_config": "~/.aws/config",
    "env_file": ".env",
    "docker_config": "~/.docker/config.json"
  },
  "docker": true,
  "ai_models": [
    "ollama://llama2",
    "ollama://mistral",
    "openai://gpt-4"
  ],
  "mcp_services": [
    { "name": "mcp-sql", "tool": "execute_sql", "exploitable": true },
    { "name": "mcp-shell", "tool": "execute_shell", "exploitable": true }
  ]
}

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

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

# Shodan API查询目标清单
TARGETS = {
    'comfyui': 'port:8188',
    'ollama': 'port:11434',
    'n8n': 'port:5678',
    'openwebui': 'http.title:"Open WebUI"',
    'langflow': 'http.title:"Langflow"',
    'sdwebui': 'port:7860',
    'gradio': 'port:7861'
}

# 每次查询结果注入为高优先级(priority=20) /32任务
# Shodan API key: ****

情报面板展示

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

凭证数：唯一 AWS AccessKeyId 数量
MCP 漏洞：可利用的 execute_sql / execute_shell 服务数量
AI 模型：Ollama（llama2/mistral）+ ComfyUI + Open WebUI
K8s ServiceAccount：集群权限 token
环境变量凭证：可跨主机复用的凭证
Docker 主机：可逃逸的容器宿主

IoC

C2

209.99.186[.]235
cdnorigin[.]net

Sample SHA1

31c69b3e12936abca770d430066f379ec1d997ec