If someone at your company quickly spun up n8n, Ollama, or ComfyUI on a VPS to test AI automation — and forgot to close the port to the outside world — this could already be a problem. A new botnet called NadMesh, written in Go, systematically scans the internet via Shodan looking for exactly such unprotected instances, then steals AWS keys, Kubernetes tokens, and other credentials.

This is not a theoretical threat. According to researchers, the botnet operator's dashboard has already accumulated over 3,800 unique AWS keys — and that's just what has been recorded. For Ukrainian companies rapidly adopting n8n, local LLMs, and no-code AI tools, the risk is especially relevant: implementation speed often outpaces basic security hygiene.

How It Works

NadMesh: Bots Scan for Exposed AI Services and Steal AWS Keys

According to The Hacker News, NadMesh automates the entire attack cycle:

  • Through Shodan/Censys-like search indexes, the bot finds IP addresses with open ports of popular AI services: ComfyUI, Ollama, n8n, Open WebUI, Langflow, Gradio.

  • If these services lack authentication (which many lack by default), the bot gains access to the management interface or API.

  • It then searches configuration files, environment variables, and container logs for AWS Access Key/Secret Key pairs, Kubernetes ServiceAccount tokens, and sometimes credentials for other cloud providers.

  • Discovered secrets are sent to the operator's server and end up in the dashboard, which already holds thousands of valid AWS keys.

The key reason for the botnet's success is mundane: services get deployed "for testing" without a password, with a port open on all interfaces (0.0.0.0), and then people forget to close access or never think about it because the server is "temporary."

Why This Matters for Ukrainian Businesses

Ukrainian companies — from small e-commerce shops to product IT teams — are actively experimenting with AI automation: n8n for integrations and workflows, Ollama for local LLMs without sending data to the cloud, ComfyUI for image generation. This is a logical and correct trend — control over data, savings on API calls, speed.

The problem is that these tools are often deployed on VPS or in-house servers by developers or marketers, not network engineers. The port gets opened for a "quick check from home or client's office," authentication is postponed for "later." Meanwhile, AWS keys or S3-compatible storage credentials needed for n8n integrations sit right in the workflow or container environment variables.

If such a server falls within NadMesh's scanning range, a company can incur a bill for thousands of dollars from compromised AWS resources (crypto mining, spam via SES) or suffer a leak of customer data within minutes.

Practical Checklist: Audit Your Infrastructure Today

NadMesh: Bots Scan for Exposed AI Services and Steal AWS Keys

1. Check if you're already exposed on Shodan/Censys

  • Go to shodan.io and search your IP or range: net:YOUR.IP.RANGE/24.

  • Look for typical banners: port:5678 (n8n), port:11434 (Ollama), port:7860 (Gradio/ComfyUI default), port:3000 (Open WebUI, may vary).

  • Also check via Censys.io — indexes sometimes differ.

2. Block external access to AI ports via firewall

The fastest fix is blocking inbound connections on these ports at the router or server firewall level. Example for MikroTik RouterOS:

/ip firewall filter add chain=input protocol=tcp dst-port=5678 action=drop comment="Block n8n from WAN"
/ip firewall filter add chain=input protocol=tcp dst-port=11434 action=drop comment="Block Ollama from WAN"
/ip firewall filter add chain=input protocol=tcp dst-port=7860 action=drop comment="Block Gradio/ComfyUI from WAN"
/ip firewall filter move [find comment="Block n8n from WAN"] destination=0

If remote access is needed, use a VPN (WireGuard/IPsec on the same MikroTik) instead of an open port, or at minimum restrict access by IP address list:

/ip firewall address-list add list=trusted_office address=203.0.113.10
/ip firewall filter add chain=input protocol=tcp dst-port=5678 src-address-list=!trusted_office action=drop

3. Enable authentication in the services themselves

  • n8n — enable basic authentication via environment variables N8N_BASIC_AUTH_ACTIVE=true, N8N_BASIC_AUTH_USER, N8N_BASIC_AUTH_PASSWORD, or connect SSO/OAuth in the paid tier.

  • Ollama — by default listens only on localhost; if you explicitly set OLLAMA_HOST=0.0.0.0, revert this and proxy access through nginx with basic auth or a VPN.

  • Open WebUI — enable mandatory registration/login (WEBUI_AUTH=True), disable anonymous access.

  • ComfyUI/Gradio — use the --auth parameter (Gradio supports built-in auth=("user","pass") in the launch code) or keep the service behind a reverse proxy with authentication.

4. Get rid of static AWS keys

  • Where possible, replace static Access Key/Secret Key pairs with IAM roles (for EC2, ECS, Lambda) — then keys aren't stored in files and can't leak along with the n8n config.

  • If static keys are unavoidable (e.g., for external n8n workflow integrations), restrict them to minimal permissions via IAM policies (principle of least privilege).

  • Rotate all AWS keys that may have been hardcoded somewhere in configs, git repositories, or Docker images.

  • Enable AWS CloudTrail and alerts for anomalous activity (unusual regions, unusual API calls).

5. Monitoring and logging

  • Keep access logs for AI services and analyze for requests from unusual IPs or User-Agents (Go-based bots often have distinctive headers).

  • Set up fail2ban or a similar mechanism on the server to block IPs after several failed authentication attempts.

  • Repeat the Shodan/Censys check regularly (weekly-monthly) — a new service can get indexed within hours of deployment.

FAQ

Does this only apply to cloud servers, or on-premises too?

It applies to any server with a public IP address or accessible via port forwarding on a router — even if it's an office server rather than AWS/VPS.

Our n8n is only accessible via VPN — are we safe?

Much safer than an openly exposed port. But verify that VPN is really the only path in — sometimes parallel public IP access remains "just in case."

How long does a Shodan check take?

5–10 minutes per IP range. It's the fastest action on the whole checklist and should be done first.

Source: The Hacker News — New NadMesh Botnet Hunts Exposed AI Services