On July 10, the operator’s own dashboard for the NadMesh botnet claimed to have harvested 3,811 unique AWS keys from exposed AI services. That single figure alone shows how lucrative unsecured AI endpoints have become for cyber‑crime.
Key Takeaways
- The botnet scans for AI tools like ComfyUI, Ollama, and Gradio, then pulls cloud credentials from environment variables.
- Operator‑reported metrics differ sharply from independent observations, hinting at inflated success claims.
- Docker API sockets and Jenkins consoles still account for the bulk of exploit traffic.
- Over 21,000 MCP services were reachable by early May, many exposing an
execute_commandRPC call. - Removal is intentionally hard; each agent is packed, obfuscated, and padded uniquely.
Historical Context
The shift toward AI‑driven workloads on cloud infrastructure accelerated in the past two years. Early adopters often spun up containers for image generation or language modeling without a hardened perimeter. Those deployments mirrored the earlier explosion of IoT devices that fed the Mirai botnet. When the first wave of AI services went public, many teams treated them like internal tools, leaving ports open and credentials in plain text. That mindset created a fertile ground for actors who could now harvest cloud keys directly from the runtime environment. The NadMesh campaign is the latest manifestation of a pattern that started with unsecured Docker sockets and has now migrated into the AI layer.
In parallel, security research communities began publishing scans of exposed AI endpoints. Those reports highlighted the same ports that NadMesh now prioritizes. The timeline shows a clear progression: from generic container exploits in 2022 to targeted AI endpoint harvesting in 2024. This evolution underscores how attackers adapt their playbooks to whatever services become popular in the development community.
NadMesh Botnet Targets Exposed AI Services for Cloud Keys
What’s ironic is that the botnet isn’t after the host itself – it’s after the cloud credentials that sit inside the host’s environment. The Shodan‑based harvester feeds the queue with services such as ComfyUI, Ollama, n8n, Open WebUI, Langflow, and Gradio. Those are the image generators and workflow builders that teams spin up quickly and then forget to lock down.
How the Scan Works
Every five minutes, subnets that produce hits get resampled more densely. IPs flagged as dangerous in the last 24 hours are rescanned as /32s with the AI ports first, and any target that absorbs ten deployment attempts without a result is auto‑blacklisted as a suspected honeypot. The botnet even generates random /24 blocks when the queue runs dry.
Rescanning at that cadence lets the botnet stay ahead of temporary defenses. When a host briefly opens a port for testing, the next sweep will likely capture it before the window closes. This aggressive timing explains why even short‑lived deployments can become sources of stolen credentials.
Operator Metrics vs. Independent Sensors
The dashboard shows a counter reading 17,700 total deploys and a funnel claiming 95,700 deployments in the past 24 hours. One tile says there are 16 active bots; the next says 12. The only number that repeats reliably is the credential count – the 3,811 AWS keys.
Qi An Xin’s XLab sensors paint a different picture. Distinct source IPs pushing NadMesh were near zero through late June, then spiked to around 139 a day in the first week of July. That suggests the botnet’s scale grew rapidly, but the internal counters likely overstate actual activity.
What’s Being Stolen
When a bot lands, it pulls cloud keys from environment variables, Kubernetes service account tokens, and the contents of ~/.aws/config, .env, and ~/.docker/config.json. The researchers summed it up: “the operator is after not the host itself, but the cloud credentials, Kubernetes cluster privileges on it.” Model access and callable MCP tools round out the loot.
MCP as a Prime Target
MCP heads the controller’s priority order for exploitation, above Kubernetes, Docker API, and Redis. The vector XLab recorded beside it is a JSON‑RPC execute_command call. No CVE is attached, and the report doesn’t claim one. Censys counted 12,520 reachable MCP services across 8,758 IP addresses as of April 28, more than 21,000 by May 6, and roughly 90 advertising a tool that runs commands. On 39 of those, the tool was named execute_command, matching the botnet’s table.
Even though the operator’s own counters list 12,100 MCP services as exploitable, XLab’s intel records show no MCP vulnerabilities among the 100 intel records on screen. The discrepancy underscores how the botnet’s self‑reported data can be misleading.
Exploit Traffic Landscape
XLab charted the exploit traffic it observed. Docker containers API RCE accounts for 30.31 % of the traffic, followed by Jenkins script console RCE at 22.28 %. Telnet weak passwords make up 10.36 %, and Redis is at 8.29 %. The mcp_cmd_execute vector sits in the unlabeled tail, representing 0.78 % of traffic.
That means the AI targeting is real at the intake and in the loot, but most of the exploit traffic still goes to Docker sockets and Jenkins consoles. The chart’s labels don’t match the controller’s status strings, so they reflect XLab’s sensor view, not the operator’s success ledger.
Botnet Architecture and Persistence
Five build versions run concurrently. Eleven bots operate on a 33.8‑GO‑TITAN platform, while the stragglers run on 30.0. A canary endpoint stages new builds to a slice of the fleet, serving 5,448 responses and 84,024 null replies. The panel’s footnote reveals that success is scored on an outcome allowlist that explicitly excludes the Ollama and AWS harvest – the operator’s scoreboard doesn’t count the thing the operator is taking.
Removal is built to fail. The agent persists in three ways at once, so pulling one leaves the others to bring it back. Every build goes through Garble obfuscation, UPX ‑9 packing, and random padding, which means no two agents share a hash. The published sample hash will catch that one build and miss the rest.
Competitive Landscape
While NadMesh focuses on AI endpoints, other malicious groups continue to chase classic attack surfaces. Some actors specialize in Docker‑API exploits; others have built dedicated Jenkins‑targeting kits. The overlap in tooling means a single compromised host can serve multiple campaigns at once. That reality makes it harder for defenders to attribute activity to a single botnet. In practice, a host that runs an exposed ComfyUI instance may also be running a vulnerable Jenkins script console, giving attackers two footholds from the same IP address.
Because the botnet’s architecture supports multiple builds, it can swap modules on the fly. One build may prioritize Docker exposure, while another switches to MCP exploitation depending on what the scanner discovers. This modularity mirrors what security analysts have seen in other malware families that adapt to the environment they encounter. The result is a flexible threat that can pivot between old‑school container attacks and the newer AI‑focused loot.
Defenders therefore need to think beyond a single vector. Hardening Docker sockets, securing Jenkins consoles, and locking down AI ports all contribute to a broader reduction in the botnet’s attack surface. When each layer is reinforced, the botnet loses its ability to chain the steps that lead from a simple port scan to a full cloud credential harvest.
Practical Recommendations for Defenders
Most of what NadMesh throws is aimed at exposed services and admin functionality left callable: an open Docker API on port 2375, a Jenkins script console, unauthenticated Redis, weak Telnet, and SSH passwords. No patch closes any of those. Get them behind auth or off the public internet, starting with the four ports the rescan job puts first: 8188 (ComfyUI), 11434 (Ollama), 7860 (Gradio), and 567.
What This Means For You
If you’re running any of the listed AI services, you need to treat the exposed ports as high‑risk entry points. Enforce strong authentication, restrict inbound access to trusted IP ranges, and rotate any cloud credentials stored in environment variables on a regular basis. Because the botnet pulls directly from ~/.aws/config and Docker configs, even a single leaked file can hand over full cloud control.
Developers should also audit their MCP deployments. Since roughly 90 services were advertising a command‑execution tool and 39 of those used the exact execute_command call seen in the botnet’s table, any unsecured MCP endpoint is a prime target. Tightening optional authentication – which many deployments still skip – could cut down the botnet’s success rate dramatically.
Consider three concrete scenarios. First, a startup that spins up an Ollama container for internal testing may expose port 11434 to the internet for convenience. A single misconfigured firewall rule lets the botnet reach the service, harvest the environment’s AWS token, and then use that token to spin up additional cloud resources. Second, a CI/CD pipeline that runs Jenkins with the script console enabled can be hijacked by a simple HTTP request that executes arbitrary code. The attacker can then drop a payload that scans for AI endpoints and repeats the credential theft loop. Third, an enterprise that relies on Kubernetes for scaling AI workloads often stores service‑account tokens in the pod’s filesystem. If a compromised container gains access to that token, it can impersonate the entire cluster and read secrets from other namespaces, including the same AI services the botnet is hunting. In each case, the root cause is an open, unauthenticated entry point that should have been locked down from day one.
Future botnets will likely mimic this playbook, focusing on the “intake” of AI services while continuing to exploit classic containers and CI/CD pipelines. The question is whether the industry will finally prioritize securing the “first‑line” AI ports before they become a routine hunting ground.
Key Questions Remaining
Several uncertainties linger. One is whether cloud providers will introduce native protections for the environment variables that many AI containers expose. Another is how quickly the community can adopt automated scanning tools that flag open AI ports before they go live. A third question concerns the economics of credential theft: will attackers keep harvesting AWS keys, or will they shift toward other cloud assets as defenses improve? Finally, there is the open issue of attribution. Because the botnet mixes multiple exploit vectors, teasing apart which group is responsible for a given compromise remains a challenge for investigators.
Answering these questions will shape the next wave of defensive strategies. If providers roll out tighter defaults, the incentive to target
