NadMesh Botnet: Why Your 'Local' AI Models Are Now a Cloud Liability
Just came across the report on the new NadMesh botnet, and it’s a textbook example of how "Shadow AI" is creating massive attack surfaces. The botnet is actively scanning for exposed instances of ComfyUI, Ollama, n8n, and Open WebUI—tools that dev teams love to spin up quickly but often forget to secure.
The operator claims to have snagged 3,811 unique AWS keys. That’s terrifying when you consider these are likely development or sandbox environments where the 'unauthenticated' box was checked for convenience. Since it's a Go-based binary, static analysis can be a bit tricky, but the C2 traffic is fairly standard HTTP.
If you haven't already, you should be hunting for these specific ports exposed to the internet. I threw together a quick KQL query for Sentinel/Splunk to identify successful connections to these services from external IPs:
// Hunt for exposure on common AI service ports
let AIPorts = dynamic([8188, 11434, 5678, 5679, 3000]);
DeviceNetworkEvents
| where RemotePort in (AIPorts)
| where ActionType == "ConnectionSuccess"
| where InitiatingProcessFileName !in ("node.exe", "python.exe", "ollama.exe") // Filter out some noise
| project Timestamp, DeviceName, InitiatingProcessAccount, RemoteIP, RemotePort
| take 100
Has anyone else seen attempts against their Langflow or Gradio instances? I'm curious if folks are managing these via internal registries or if the chaos of "bring your own model" is winning the governance battle.
We saw a spike in scans against port 11434 (Ollama) just last week. It turned out a developer had exposed an inference server on a test EC2 instance. The IAM role attached to that instance had full S3 permissions. We're now enforcing a strict policy requiring an internal Application Load Balancer (ALB) in front of any AI tool, prohibiting direct 0.0.0.0 bindings on internet-facing subnets.
From a SOC perspective, the biggest issue is these tools don't always log authentication failures because they often don't have authentication enabled by default. We've started deploying Canarytokens in the AWS credential files of our sandbox environments. It's a low-friction way to get an alert the second a key gets exfiltrated by something like NadMesh.
Excellent points. Beyond monitoring, we must enforce segmentation. Since these tools often run in dev environments, they shouldn't be public. You can quickly audit your AWS environment for exposed ports—like 11434 for Ollama—using the CLI. This helps identify open routes before the botnet finds them.
aws ec2 describe-security-groups --filters Name=ip-permission.from-port,Values=11434 Name=ip-permission.to-port,Values=11434 Name=ip-permission.cidr,Values=0.0.0.0/0
To minimize the blast radius when these local tools get exposed, strict IAM boundaries are critical. We're implementing Service Control Policies (SCPs) to deny broad s3:* or iam:* actions in dev subnets unless explicitly whitelisted. You can quickly audit your roles for overly permissive inline policies using this snippet:
import boto3
iam = boto3.client('iam')
for role in iam.list_roles()['Roles']:
print(f"Auditing {role['RoleName']}...")
Is anyone else restricting these tools via VPC endpoints to prevent internet ingress entirely?
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access