七月初，一个名叫NadMesh的Go语言僵尸网络悄然上线，它的目标不是普通服务器，而是那些匆忙上线、防护薄弱的AI服务。图像生成工具ComfyUI、本地模型运行器Ollama、工作流自动化平台n8n、聊天界面Open WebUI、低代码AI工作台Langflow、机器学习应用框架Gradio——但凡团队为了快速验证想法、先跑起来再说，防火墙随手关上后就不管了的，全成了它的猎物。Shodan扫描器源源不断地把这些暴露在公网的AI服务塞进队列，24小时不停，而操作者自己的控制面板上赫然跳出一个数字：3811个唯一的AWS密钥已经落袋。
这个数字来自奇安信XLab在上周五发布的一份报告。研究团队从NadMesh源码里扒出了“n4d mesh controller”字串，顺手给它起了个名字，还截图了操作面板。面板上的数据全是操作者自己记的账，抓取时间是7月10日，但前后矛盾得让人哭笑不得。一个17,700“总部署”的计数器，下面紧挨着一条“过去24小时95,700”的漏斗，差出去将近五倍。一张小卡片写着16个活跃bot，旁边那张写着12。唯一前后对得上、说了两次的，就是那个3811个AWS密钥的数量。XLab用自己的传感器看外面的动静，给出的也不是bot数目，而是推送NadMesh的独立源IP——6月下旬还几乎为零，7月第一周直接垂直拉升到每天大约139个。
这波扫荡不是冲着挖矿或者植入后门去的。研究人员说得直白：操作者盯着的是“主机本身之外的云凭据和Kubernetes集群权限”。被劫走的包括环境变量里的云密钥、k8s服务账户令牌，还有~/.aws/config、.env、~/.docker/config.json这类配置文件里的敏感信息。模型访问权限和可调用的MCP工具也在清单上。在最近100条情报记录里，47次凭据收割和41次模型资产盘点，直接反映出对手的意图——人家要的就是登堂入室的钥匙，不是门口的花盆。
那些被盘点的模型清单里出现了DeepSeek、GLM、Kimi这些名字，后缀还挂着“:cloud”。也就是说，NadMesh扫描到的远不止盒子本身，而是顺着算力节点摸到了背后的云端资源。算力、模型、凭据，三样打包在一起，就成了一个高权限入口。一旦拿到Kubernetes服务账户令牌，就能横向移动、劫持集群、偷跑模型推理，甚至篡改工作负载。
攻击优先级列表上，排在最前面的就是MCP。在控制器的漏洞利用顺序中，MCP被放在Kubernetes、Docker API、Redis之前，对应的利用方式是JSON-RPC tools/call里的execute_command。XLab在图表中标注了这一项，但这一行并没有挂任何CVE编号，报告也没有声称这是个已知漏洞。问题出在MCP本身的协议设计上——它的第一版规范把身份验证彻底甩在了核心协议外面。2025年3月补上来的授权流程，按规范自己的说法，仍然是可选功能。大量部署直接跳过了认证这一步。截至4月28日，Censys扫描到8,758个IP地址上暴露了12,520个可访问的MCP服务；到了5月6日就突破21,000个；其中大约90个公开了能运行命令的工具。有39个工具的名字就叫execute_command，跟NadMesh优先调用表里的头号目标一字不差。
但NadMesh自己面板上的MCP统计也是一笔糊涂账：列出了12,100个“可利用”的MCP服务，总计21个MCP漏洞，然而旁边屏幕上的100条情报记录里却愣是一个都没出现。XLab索性不看操作者自报的账，直接去观测真实的攻击流量。结果发现，docker_containers_api_rce占了30.31%，jenkins_scripttext_rce占了22.28%，Telnet弱口令10.36%，Redis 8.29%。mcp_cmd_execute虽然出现在图表里，但挂在没标名字的最小份额末端，比例不到0.78%。流量分布跟控制面板上的优先级刚好掉了个个儿。
这种错位说明了两件事。一是攻击者手里已经握着大量已知的老漏洞利用工具，自动化扫一遍，谁不关门就进谁。二是MCP虽然被当成新型攻击面重点照顾，但眼下真正的突破大多数还在走Docker和Jenkins那条路。然而，MCP部署的爆炸式增长——两个月内从一万多跳升到两万多——加上认证几乎为零的现实，意味着NadMesh这类专门针对AI链条的新一代僵尸网络，迟早会把execute_command推到更靠前的位置。毕竟，一个能直接调用工具执行命令的接口，在攻击者眼里比单纯挖矿诱人得多。
XLab的报告还拆了一个战术细节：NadMesh并不是一上来就自己扫。它用Shodan收割机维持扫描队列，专挑暴露的AI服务下手。从ComfyUI到Gradio，这些框架大多在设计时优先考虑易用性和快速集成，安全配置往往被放在最后一步，或者干脆略过。团队急着看效果，模型跑通了、界面亮了，任务栏里一关，防火墙和认证忘得一干二净。而NadMesh要的就是这种“先上线，后防御”缝隙里的那些轻率。
回传的数据包里，最先被抓走的是环境变量中的云密钥和Kubernetes服务账户令牌。这些密钥一旦泄露，攻击者就能以合法身份访问AWS、Azure、GCP等云服务，启动实例、复制数据、偷跑模型推理，甚至用受害者的算力去挖矿或发起下一次攻击。k8s令牌则直接赋予集群内部权限，让攻击者在容器间横向移动，找到挂载的敏感存储卷。再加上从~/.aws/config、.env和~/.docker/config.json拿到的配置文件信息，对手等于一次性拿到了云、容器、模型三层钥匙。
更深一层的是模型访问权限和MCP工具的调用能力。有了模型凭证，攻击者可以直接调用商业API接口，消耗受害者的额度，或者窃取模型交互记录，提取训练数据、系统提示词等核心资产。MCP的可调用工具如果是execute_command这种类型，就等于在受害者环境下获得了一个远程命令执行的入口。虽然目前实际观测到的mcp_cmd_execute流量只占不到0.78%，但操作者把它放在利用优先级第一位，说明这个攻击面正在被重点盯防。
奇安信XLab用自己的传感网络确认了一件事：推送NadMesh的独立源IP数，在6月下旬几乎为零，7月第一周突然跳到每天约139个。这个曲线说明的不是感染规模，而是分发强度——攻击者正在高速扩军。不到一周时间，每日投放量就从无到有、拉出一条垂直线。面板上虽然矛盾重重，但“17,700总部署”这个数如果哪怕只有一部分真实，意味着已有上万个主机沦陷。而那3811个AWS密钥如果确有其数，背后对应的云资产规模足以让人后背一凉。
整份情报暴露出一个老问题的新变种：AI时代的快速试错，让大量服务带着默认配置和未加固端口直接暴露在公网上。NadMesh这类专门化僵尸网络就是看准了这一点，不再广撒网式地乱扫，而是聚焦AI栈的每个薄弱环节——从模型服务到工作流引擎，再到身份令牌。操作者并不关心宿主机本身，他们要的是以被入侵AI服务为跳板，拿到通向云计算和Kubernetes集群的控制权。一旦成功，就能在云上复刻更多攻击节点，形成链式扩散。
MCP协议的认证缺陷把这种风险放到了最大。标准制定者把安全问题留给实现方，而实现方在快速部署的压力下又选择了最省事的方案——跳过认证。Censys的数据已经说明，暴露在公网的MCP服务数量正在指数级爬坡。除非出现一个默认开启认证的版本，并且被广泛采纳，否则NadMesh的下一个版本很可能把mcp_cmd_execute的流量份额从0.78%推到30%以上，那会儿再补课，成本就完全不一样了。
热门跟贴