A Go-based botnet named NadMesh has been actively scanning for exposed AI services and harvesting cloud credentials. Research from QiAnXin's XLab reveals that the botnet's operator claims to have collected 3,811 unique AWS keys and Kubernetes tokens from misconfigured services. This isn't just a theoretical risk; it's an active exploitation of a specific attack surface many teams overlook.
What Happened
NadMesh targets exposed Model Context Protocol (MCP) services and related AI infrastructure. It uses a Shodan harvester to find vulnerable targets, then exploits known vulnerabilities and misconfigurations to extract cloud credentials. Censys identified 12,520 reachable MCP services across 8,758 IP addresses as of April 28, creating a vast attack surface.
The botnet doesn't use zero-day exploits. It targets services that should never be internet-accessible, exploiting default credentials and unpatched vulnerabilities.
Timeline
Early July 2025: XLab observes 139 distinct source IPs pushing NadMesh daily. The botnet operates at scale, with automated scanning and credential extraction.
April 28, 2025: Censys identifies over 12,000 reachable MCP services, many lacking authentication. This represents a large pool of potential targets.
Ongoing: The operator's dashboard continues to accumulate credentials. Each harvested AWS key or Kubernetes token is a potential entry point into cloud infrastructure.
NadMesh moves faster than most teams' detection-to-response cycles, making speed a critical factor.
Which Controls Failed
Network Segmentation: MCP services and AI tools were exposed to the public internet. These services handle sensitive data and often run with elevated privileges, yet they were accessible from any IP address.
Authentication and Authorization: Services ran with default credentials or no authentication. Even when authentication existed, it wasn't enforced at the network layer.
Secrets Management: Cloud keys and Kubernetes tokens were accessible through service interfaces instead of being properly scoped and rotated. Once NadMesh accessed a service, it could extract credentials granting broader access.
Vulnerability Management: The botnet exploited known vulnerabilities. Patches existed but weren't applied to internet-facing services.
Logging and Monitoring: The 139 daily source IPs scanning and extracting credentials should have triggered alerts. Most affected organizations likely didn't notice the activity until credentials were used elsewhere.
What Standards Require
PCI DSS v4.0.1 Requirement 1.3.1 mandates that inbound traffic to the cardholder data environment be restricted to only what's necessary. Exposing AI services that can access cloud credentials violates this principle. If those credentials can reach payment systems, you've failed the requirement.
NIST 800-53 Rev 5 AC-3 (Access Enforcement) requires systems to enforce approved authorizations for logical access. Running services without authentication or with default credentials is a direct violation. AC-17 (Remote Access) adds that remote access must be authorized and monitored.
ISO/IEC 27001:2022 Annex A.9.1.2 covers access to networks and network services. Internet-accessible services need documented business justification and appropriate controls. "We deployed it for testing" doesn't meet the standard.
SOC 2 Type II CC6.1 requires logical and physical access controls. If your MCP service can hand out AWS keys to anyone who connects, you're failing the common criteria for access restrictions.
The gap isn't in the standards; it's in the assumption that development and AI tooling don't need the same controls as production systems. NadMesh proves that assumption wrong.
Lessons and Action Items
Audit your internet-facing services today. Run shodan search "your-domain.com" to see what's exposed. If you find MCP services, AI APIs, or development tools, ask why they need public IPs. Most don't.
Implement network-layer authentication. Even if your service has application-level authentication, put it behind a VPN or IP allowlist. Defense in depth means an attacker needs to bypass multiple controls, not just guess a password.
Rotate cloud credentials on a schedule. Your AWS keys should have maximum lifetimes measured in days, not months. Use IAM roles for EC2 instances instead of long-lived keys. For Kubernetes, implement short-lived tokens with RBAC scopes that match actual job requirements.
Enable logging on credential usage. AWS CloudTrail and Kubernetes audit logs should alert you when credentials are used from unexpected locations or for unusual API calls. If a key that normally creates S3 buckets suddenly starts listing EC2 instances, you need to know immediately.
Patch internet-facing services first. Your vulnerability management process should prioritize anything with a public IP. If you can't patch it, take it offline until you can.
Review your AI service deployments. MCP and similar protocols are useful, but they're not designed for internet exposure. If you're running them, document the business justification and implement compensating controls. If you can't justify the exposure, move them to private networks.
The 3,811 AWS keys sitting in NadMesh's dashboard represent 3,811 failures of basic controls. Your team's job is to make sure your keys aren't in the next batch. Start with the audit, then work through the network segmentation. The botnet operators are already scanning; the question is whether they'll find anything when they hit your IP ranges.
