Carbonato: Botnetz kapert offene Docker-APIs und installiert einen KI-Agenten

Wer auf einem Linux-Server den Docker-Daemon per TCP ohne TLS ins Netz gehängt hat, typischerweise als tcp://0.0.0.0:2375, sollte das heute prüfen. Das Botnetz Carbonato sucht genau solche Hosts, startet über die offene Docker-API einen privilegierten Container mit eingehängtem Host-Dateisystem und übernimmt damit den ganzen Server. Anschließend installiert es den Open-Source-Agenten Hermes Agent mit einer manipulierten Persona namens GH0ST, der über Telegram Befehle entgegennimmt und gezielt KI-API-Schlüssel und Zugangsdaten sammelt.

Nicht betroffen sind Docker-Installationen im Auslieferungszustand, denn dort lauscht der Daemon nur auf dem lokalen Unix-Socket /var/run/docker.sock. Ebenfalls nicht betroffen ist, wer den Fernzugriff ausschließlich per SSH oder per TLS mit Client-Zertifikaten auf Port 2376 betreibt. Es handelt sich nicht um eine Sicherheitslücke in Docker oder in Hermes Agent, sondern um den Missbrauch einer Fehlkonfiguration. Die Prüfung dauert wenige Minuten, bei einem Treffer ist sie ein Notfall.

Was ist passiert?

Forscher von ThreatDown, dem Unternehmensbereich von Malwarebytes, haben am 22. September 2026 eine Analyse zu Carbonato veröffentlicht. BleepingComputer hat am 24. September 2026 darüber berichtet. Ausgangspunkt war laut ThreatDown eine ungeschützte Docker-Registry auf Port 5000 eines Servers in den USA, die seit Mai 2026 öffentlich erreichbar war und im August 2026 bei einer routinemäßigen Suche nach offenen Docker-Diensten auffiel. An einem Tag passiver, rein lesender Sammlung holten die Forscher 59 Repositories, 234 Image-Tags, 605 verifizierte Blobs und 4,3 GB Image-Daten. Die Zeitstempel reichen von Oktober 2024 bis August 2026.

Das Archiv dokumentiert zwei Geschäftszweige derselben Gruppe: gefälschte Kryptowallet-Apps und das Botnetz. Die Infektionskette beschreibt ThreatDown in fünf Schritten:

• Host übernehmen: Das Botnetz verbindet sich mit Docker-Daemons, die auf Port 2375 unauthentifizierte Verbindungen annehmen, und legt einen Container mit Privileged: true, dem Bind-Mount /:/host sowie PidMode und NetworkMode auf host an. Über nsenter laufen die Befehle dann direkt auf dem Host.
• Host halten: Ein Skript baut einen Reverse-SSH-Tunnel zu einem Relay in Costa Rica auf, installiert einen SSH-Server mit dem Schlüssel der Angreifer und meldet die Übernahme per Telegram. Der Tunnel-Port wird aus dem MD5-Hash der Opfer-IP abgeleitet.
• Tarnung und Persistenz: Der Container heißt systemd-resolved, Prozessargumente imitieren den Kernel-Thread [kworker/u2:0]. Persistenz entsteht über cron, systemd-Timer, rc.local und OpenRC, die Dateien werden als unveränderlich markiert. Watchdogs ziehen das Implantat aus der Registry nach, wenn es entfernt wird.
• Agent installieren: Hermes Agent von Nous Research wird unverändert installiert, nur die Persona-Datei SOUL.md wird durch einen 39-zeiligen Prompt ersetzt. Oberste Priorität haben KI-API-Schlüssel von 14 genannten Anbietern, danach SSH-Zugänge, Tokens und Datenbanken.
• Verbreiten: Alle fünf Minuten scannt ein Skript jedes angeschlossene /24-Netz, auch die Docker-Bridges, nach weiteren offenen Daemons auf Port 2375 und wiederholt dort die Übernahme.

Der Agent selbst ist für die Verbreitung nicht zuständig. Laut ThreatDown übernehmen das klassische Skripte. Die KI kommt erst nach der Übernahme ins Spiel: Der Operator schickt eine Aufgabe per Telegram, das Modell schreibt Terminal-Befehle, liest die Ausgabe und entscheidet über den nächsten Schritt. Zusätzlich fand ThreatDown einen Krypto-Miner, der sich als /usr/sbin/systemd-logind tarnt. Am 3. September 2026 waren laut Bericht sechs von sieben bekannten Registries sowie das LLM-Gateway der Gruppe noch online.

Wer ist betroffen?

Betroffen ist jeder Linux-Host, dessen Docker-Daemon unverschlüsselt und ohne Authentifizierung über TCP erreichbar ist. Entscheidend ist nicht nur das Internet: Weil sich Carbonato innerhalb erreichbarer /24-Netze ausbreitet, reicht ein einziger infizierter Host, um weitere Server im selben internen Netz zu übernehmen, deren Docker-API nur „intern“ offen ist. Typische Kandidaten sind Build-Server, Testsysteme, nach älteren Anleitungen eingerichtete Homelab-Umgebungen und Hosts, auf denen einmal ein Management-Tool per -H tcp://0.0.0.0:2375 angebunden wurde.

Nicht betroffen sind Standardinstallationen mit reinem Unix-Socket, Fernzugriff über ssh:// und Daemons, die mit tlsverify und Client-Zertifikaten auf Port 2376 laufen. Wer Hermes Agent legitim betreibt, ist dadurch nicht gefährdet. ThreatDown rät ausdrücklich davon ab, das Paket pauschal zu sperren, und empfiehlt stattdessen die Suche nach den konkreten Missbrauchsspuren.

Wie kritisch ist das?

Für betroffene Hosts ist die Lage kritisch. Ein privilegierter Container mit eingehängtem Wurzeldateisystem und Host-Namespaces entspricht vollem Root-Zugriff. Die offizielle Docker-Dokumentation warnt selbst, dass Fernzugriff ohne Absicherung dazu führen kann, dass entfernte Nutzer Root-Rechte auf dem Host erlangen, und stuft Fernzugriff ohne TLS als nicht empfohlen ein. Ein Patch, der das Problem behebt, existiert deshalb nicht. Die Abhilfe ist eine Konfigurationsänderung.

Besonders heikel sind drei Punkte: die wurmartige Ausbreitung im internen Netz, die auf Wiederherstellung ausgelegte Persistenz mit unveränderlichen Dateien und Watchdogs sowie der gezielte Diebstahl von KI-API-Schlüsseln, die sich direkt in Kosten beim Anbieter übersetzen. Ein bloßes Entfernen des verdächtigen Containers reicht nach den Befunden von ThreatDown nicht aus. Belastbare Zahlen zur Anzahl infizierter Hosts nennt ThreatDown nicht. Diese Größe ist unbestätigt.

Was sollten Admins jetzt tun?

• Inventar prüfen: Auf jedem Docker-Host feststellen, ob dockerd auf einem TCP-Port lauscht und mit welchen -H-Optionen er gestartet wurde. Die Befehle stehen unten.
• Offenen TCP-Socket schließen: Den Eintrag tcp://...:2375 aus /etc/docker/daemon.json (Schlüssel hosts) oder aus dem systemd-Override von docker.service entfernen, danach systemctl daemon-reload und systemctl restart docker. Laut Docker darf die Einstellung nur an einer der beiden Stellen stehen, sonst startet der Daemon nicht.
• Fernzugriff richtig lösen: Wenn Tools den Daemon remote brauchen, SSH per docker context create --docker host=ssh://user@host nutzen oder TLS mit tlsverify und Client-Zertifikaten auf Port 2376 einrichten, wie in der Docker-Dokumentation beschrieben.
• Firewall ergänzen: Port 2375 an Perimeter und zwischen internen Segmenten sperren, damit ein einzelner Fehler nicht netzweit ausnutzbar wird.
• Fremde privilegierte Container suchen: Alle laufenden Container auf Privileged, PidMode host und den Bind-Mount /:/host prüfen. Verdächtig sind Namen wie systemd-resolved, netns-probe oder net-setup und Images aus unbekannten Registries.
• Host-Indikatoren prüfen: /usr/local/bin/.docker-network-monitor, eine /root/.hermes/SOUL.md mit dem String GH0ST, eine .env mit CARBONATO_API_KEY, Prozesse mit dem Argument [kworker/u2:0] außerhalb echter Kernel-Threads und unerwartete Immutable-Bits auf cron- und systemd-Dateien.
• Netzwerk beobachten: Unerklärlicher Telegram-Verkehr von Servern und ausgehende SSH-Verbindungen nach AS262145 sind laut ThreatDown typische Spuren. Die vollständige IOC-Liste mit IP-Adressen steht im ThreatDown-Bericht.
• Bei Treffer neu aufsetzen: Einen kompromittierten Host vom Netz trennen und neu installieren statt zu bereinigen, danach alle Nachbarsysteme im selben Netz prüfen.
• Schlüssel rotieren: Alle KI-API-Schlüssel, SSH-Schlüssel und Tokens rotieren, die auf betroffenen Hosts lagen, und die Nutzung beim KI-Anbieter auf ungewöhnliche Abrufe kontrollieren.
• Registries absichern: Eigene Docker-Registries nur mit Authentifizierung betreiben. Eine offene Registry war laut ThreatDown sowohl Datenleck als auch Verteilstelle des Implantats.

Erster Check auf dem Host, ob der Daemon auf TCP lauscht und wie er gestartet wurde:

# Lauscht dockerd auf einem TCP-Port?
sudo ss -tlnp | grep dockerd
# Startoptionen aus systemd inklusive Overrides
systemctl cat docker.service | grep -n 'ExecStart'
# hosts-Eintrag in der Daemon-Konfiguration
sudo grep -n 'hosts' /etc/docker/daemon.json

Privilegierte oder mit dem Host verflochtene Container auflisten:

# Name, Image, Privileged, PidMode und Bind-Mounts je Container
docker ps -q | xargs -r docker inspect --format '{{.Name}} {{.Config.Image}} priv={{.HostConfig.Privileged}} pid={{.HostConfig.PidMode}} binds={{.HostConfig.Binds}}'

Host-Indikatoren aus dem ThreatDown-Bericht prüfen:

# Watchdog-Datei und manipulierte Agent-Persona
ls -la /usr/local/bin/.docker-network-monitor
sudo grep -l 'GH0ST' /root/.hermes/SOUL.md
# Unveränderlich markierte Persistenz-Dateien
sudo lsattr /etc/rc.local /etc/crontab /etc/cron.d/* /etc/systemd/system/*.timer 2>/dev/null | grep -- '-i-'

Einordnung für Unternehmen

Carbonato nutzt keine neue Technik, um hineinzukommen. Offene Docker-APIs auf Port 2375 werden seit Jahren für Krypto-Miner missbraucht. Neu ist, was danach passiert: Statt eines festen Skripts sitzt ein KI-Agent auf dem Host, der Aufgaben in Alltagssprache annimmt und sich die nötigen Befehle selbst zusammensetzt. Damit sinkt der Aufwand für die Angreifer, jeden übernommenen Server individuell auszuwerten. Die Fixierung auf KI-API-Schlüssel zeigt zudem, dass diese Schlüssel inzwischen als eigene Beute gelten. Laut ThreatDown betrieb die Gruppe ein eigenes LLM-Gateway, das 27 Modelle über seine API ausgab.

Für kleine und mittlere Unternehmen ist die Konsequenz überschaubar und konkret: Docker-Hosts inventarisieren, TCP-Sockets ohne TLS abschaffen, Port 2375 intern wie extern sperren und KI-Schlüssel wie Bankzugangsdaten behandeln, also getrennt ablegen, mit Budgetgrenzen versehen und regelmäßig rotieren. Wer Dienstleister mit Serverbetreuung beauftragt, sollte die Frage nach offenen Docker-Sockets gezielt stellen. Wer legitim Agent-Frameworks wie Hermes Agent betreibt, sollte deren Persona- und Konfigurationsdateien in die Integritätsüberwachung aufnehmen, denn genau dort setzt Carbonato an.

Passende Anleitungen auf S-EDV

• Docker Rootless Mode auf Debian und Ubuntu einrichten: Wie der Daemon ohne Root-Rechte läuft und eine Übernahme weniger Schaden anrichtet.
• Docker Compose absichern mit Secrets, Healthchecks und Non-Root: Zugangsdaten und Schlüssel aus Umgebungsvariablen herausholen.
• Falco für Docker einrichten: Laufzeitüberwachung, die privilegierte Container und verdächtige Prozesse meldet.

Quellen

• ThreatDown (Malwarebytes): CARBONATO: a botnet built around an AI agent, 22.09.2026
• BleepingComputer: New Carbonato malware uses AI agents to hijack exposed Docker hosts, 24.09.2026
• Docker Docs: Protect the Docker daemon socket
• Docker Docs: Configure remote access for Docker daemon