As reported by SecurityAffairs, the CARBONATO botnet—active since at least October 2024—exemplifies a shift we at Shield53 have been tracking: threat actors aren't just deploying malware anymore, they're building self-sustaining AI-powered attack platforms. The discovery by ThreatDown of an unauthenticated container registry exposing the attackers' entire toolchain offers a rare glimpse into how modern botnet operators think, build, and unfortunately for them, make mistakes.

Threat Alert: As reported by SecurityAffairs, the CARBONATO botnet—active since at least October 2024—exemplifies a shift we at Shield53 have been tracking: threat actors aren't just deploying malware anymore, they're building self-sustaining AI-powered attack platforms.

The Self-Funding Model Changes the Economics

What makes CARBONATO genuinely novel isn't the initial access vector—exposed Docker daemons on port 2375 are a well-known and embarrassing problem that persists despite years of warnings. The innovation is the business model. By stealing API keys and credentials from compromised hosts, the operators fund their own LLM gateway. This creates a feedback loop: compromise begets AI capability, which begets more effective compromise.

This matters because it removes a key constraint on AI-augmented attacks. Traditionally, threat actors needed either deep pockets or stolen cloud credits to run large-scale AI inference. CARBONATO demonstrates that the stolen credentials themselves can power the AI agent that orchestrates further operations—autonomous command execution, lateral movement decisions, and likely credential exfiltration triage. The botnet becomes its own funding engine.

Docker Daemons: The Gift That Keeps Giving to Attackers

The initial infection method is textbook but effective. The bot scans for Docker daemons accepting unauthenticated TCP connections on port 2375—a configuration that should never be internet-facing. When found, the attacker uses the Docker API to launch a privileged container with the host filesystem mounted, effectively granting full host compromise through legitimate container orchestration mechanisms.

The host's own daemon does most of the work. No exploit needed—just misconfiguration and exposed management interfaces.

The post-exploitation tradecraft shows reasonable sophistication: reverse SSH tunnels with deterministic port selection (derived from MD5 hashing the victim's IP), Telegram-based deployment reporting, and SSH key persistence. The use of voseo Spanish in deployment reports and Costa Rican relay infrastructure provides attribution breadcrumbs but doesn't necessarily confirm operator location.

Operational Security Failures Cut Both Ways

The discovery was made possible by the attackers' own opsec failure—an exposed unauthenticated container registry containing 4.3 GB of image data, 59 repositories, and configuration history revealing C2 addresses, bot tokens, and even the shared password for their AI gateway. This is the kind of self-incrimination that makes threat intelligence valuable, but it also reveals that even capable operators make the same fundamental mistakes they exploit in victims: exposed services with no authentication.

For defenders, this is instructive. The same scanning techniques that CARBONATO uses to find vulnerable Docker daemons can be applied defensively—continuously enumerate your own attack surface for exposed management interfaces before attackers find them.

Who Is Most at Risk

Operational Security Failures Cut Both Ways
Cloud-hosted environments with Docker daemon exposed to the internet (AWS, GCP, Azure, bare-metal hosting providers)
Development and CI/CD environments where Docker TCP is often left unauthenticated for convenience
Small-to-midsize organizations with containerized workloads but limited dedicated security teams
Any organization storing API keys, cloud credentials, or LLM API tokens on containerized hosts

Shield53 Recommendations

Immediate Actions

  • Audit Docker daemon exposure: Scan your external IP ranges for port 2375/2376. Any hit is a critical finding requiring immediate remediation. Use shodan search port:2375 product:Docker or equivalent to find your exposed hosts.
  • Disable TCP socket or enforce TLS with client certificates: Docker daemon should bind to a Unix socket only. If remote access is required, use mutual TLS authentication via dockerd --tlsverify --tlscacert --tlscert --tlskey and restrict to specific client certificates.
  • Apply network-level controls: Place Docker daemons behind firewalls, VPNs, or zero-trust network access. Port 2375 should never appear in any public-facing security group or firewall rule.

Hardening and Detection

  • Hunt for indicators of compromise: Look for unexpected privileged containers, unauthorized SSH keys in authorized_keys files, reverse SSH tunnels, and outbound connections to Telegram API endpoints or Costa Rican IP ranges
  • Implement container runtime security: Deploy tools like Falco, Sysdig, or Aqua to detect containers running with --privileged flag or mounting host paths
  • Audit and rotate API keys: Assume any credential stored on a host with an exposed Docker daemon is compromised. Rotate all API keys, cloud credentials, and LLM gateway tokens immediately
  • Monitor for anomalous LLM API usage: If you operate your own AI gateway, watch for unexpected spikes in inference calls or authentication from unknown client identifiers
  • Implement least-privilege container policies: Use Docker's built-in security profiles, disable capabilities, and enforce read-only filesystems where possible

Strategic Considerations

CARBONATO foreshadows a broader trend: AI-augmented malware that can adapt, make decisions, and operate with greater autonomy. Organizations should treat credential hygiene on containerized hosts with the same rigor as endpoint security. The era of AI-powered botnets is here—and unlike traditional cryptominers, these operations have a built-in economic engine that makes them harder to shut down through infrastructure takedowns alone.