Carbonato: Ein offener Docker-Port, ein gekaperter Agent — und Ihre KI-Schlüssel sind weg

/01Was ThreatDown am 22. September gemeldet hat

Am 22. September 2026 hat ThreatDown, die Unternehmenssparte von Malwarebytes, eine Analyse mit dem Titel „CARBONATO: a botnet built around an AI agent" veröffentlicht. BleepingComputer griff den Fall am 24. September auf, The Hacker News am 28. September. Der Zugang der Forscher war ungewöhnlich: eine seit Mai 2026 ohne Authentifizierung erreichbare Docker-Registry der Angreifer, aus der sie an einem Tag passiver, lesender Sammlung knapp 60 Repositories mit 4,3 GB Image-Daten zogen. Die Images decken laut BleepingComputer einen Betriebszeitraum von Oktober 2024 bis August 2026 ab. Eine Zahl kompromittierter Hosts nennt ThreatDown nicht.

Was Carbonato von den Krypto-Minern unterscheidet, die seit Jahren offene Docker-Daemons abgrasen: Nach der Übernahme installiert es keinen Miner als Hauptnutzlast, sondern einen KI-Agenten — agentische KI im Wortsinn —, der auf dem Host Befehle entgegennimmt, ausführt, die Ausgabe liest und entscheidet, was als Nächstes zu tun ist. Der Operator schreibt in Telegram „sammle alle API-Schlüssel ein", und ein Sprachmodell übersetzt das in Shell-Befehle für genau dieses System. ThreatDown fasst es so zusammen: „Das Modell interpretiert die Aufgabe, schreibt Terminalbefehle, liest die Ausgabe und entscheidet, was als Nächstes zu tun ist."

Für den Betreiber eines KI-Hosts ist das zweite Detail wichtiger als das erste: Ganz oben auf der Einkaufsliste der Angreifer stehen KI-API-Schlüssel. Wer Ollama, vLLM, Open WebUI oder n8n in Docker betreibt, betreibt genau die Art von Host, die hier gesucht wird — und hat auf dem Host genau die Art von Schlüsseln liegen, die hier gesammelt werden.

/02Die Angriffskette: vom offenen Port zum ferngesteuerten Host

ThreatDown beschreibt fünf Schritte. Keiner davon nutzt eine Software-Schwachstelle; alle nutzen Konfiguration.

1. Einstieg. Der Wurm sucht Docker-Daemons, die auf TCP-Port 2375 ohne Authentifizierung antworten. Die Docker-Dokumentation sagt zu diesem Zustand: Über einen TCP-Socket bietet der Daemon standardmäßig „unverschlüsselten und nicht authentifizierten direkten Zugriff". Wer den Port so öffnet, hat jedem, der ihn erreicht, Root auf dem Host gegeben. Carbonato lässt den Daemon einen privilegierten Container starten — mit dem Dateisystem des Hosts eingehängt und mit Zugriff auf dessen Prozess- und Netzwerk-Namensräume.
2. Festsetzen. Aus dem Container heraus öffnet das Skript einen Reverse-SSH-Tunnel zu einem Relais in Costa Rica (AS262145); der Port auf der Gegenseite wird aus dem MD5-Hash der Opfer-IP abgeleitet. Es installiert einen SSH-Server, hinterlegt den Schlüssel des Operators und meldet den neuen Host per Telegram. Persistenz entsteht über Cron, systemd-Timer, rc.local und OpenRC-Hooks; die Dateien werden mit dem Immutable-Attribut versehen, und paarweise laufende Wächterprozesse holen das Implantat aus der Registry nach, falls es fehlt.
3. Agent installieren. Das Skript installiert Hermes Agent, ein MIT-lizenziertes Open-Source-Framework von Nous Research — unverändert. Nur die Persona-Datei SOUL.md wird überschrieben: ein 39-zeiliger Prompt, der den Agenten „GH0ST" nennt, ihn als Pentester und Exploit-Entwickler ausgibt und anweist, Persistenz zu halten, über Telegram zu antworten und jede Operation auszuführen.
4. Fernsteuern. Der Operator schickt Aufgaben per Telegram. Hermes Agent reicht sie zusammen mit SOUL.md an das LLM-Gateway der Operation weiter (213.136.83.197, Contabo). Das Modell erzeugt Befehle, der Agent führt sie auf dem Opfer aus, die Ergebnisse gehen zurück nach Telegram.
5. Ausbreiten. Alle fünf Minuten ermittelt der Wurm die am Host angeschlossenen Netze und Docker-Bridges und scannt jedes /24 nach Daemons auf Port 2375. Ein einziger offener GPU-Host im Serverraum reicht, um die Nachbarn abzusuchen — auch die, die nur aus dem LAN erreichbar wären.

/03Hermes Agent: ein legitimes Framework als Werkzeug — und als Produkt

An dieser Stelle ist Sorgfalt nötig, weil Hermes Agent in diesem Haus kein Fremdwort ist: ki·spezial bietet mit OpenClaw / Hermes einen On-Premise-Assistenten an, der auf genau diesem Framework aufsetzt. Carbonato ändert daran nichts, und zwar aus einem einfachen Grund: Das Framework hat nichts falsch gemacht. Hermes Agent ist ein Agenten-Laufzeitsystem mit Gateways für Telegram, Discord, Slack, WhatsApp, Signal und E-Mail, mit austauschbaren Modellanbietern und einer Persona-Datei, die das Verhalten beschreibt. Das ist die Funktion. Carbonato nutzt sie wie ein Einbrecher einen Lieferwagen nutzt — der Wagen ist nicht das Problem.

Der Unterschied zwischen legitimem Betrieb und Missbrauch liegt in drei Dingen, die ein Betreiber kontrolliert:

• Wer die Persona schreibt. In einem eigenen Betrieb schreiben Sie SOUL.md, legen sie unter Versionskontrolle und überwachen Änderungen. Carbonato überschreibt die Datei — ein Dateiänderungs-Alarm auf /root/.hermes/SOUL.md hätte den Vorfall gemeldet, bevor der erste Befehl lief.
• Wer das Modell stellt. Ein On-Premise-Assistent spricht mit einem Modellendpunkt im eigenen Netz. Carbonato spricht mit einem LLM-Gateway der Angreifer im Internet. Ein Egress-Filter, der dem Agenten-Host nur den internen Endpunkt erlaubt, hätte den Agenten stumm gemacht.
• Wer die Befehle gibt. Ein Telegram-Gateway ist für einen Assistenten, der dem Geschäftsführer unterwegs antwortet, eine sinnvolle Funktion. Auf einem GPU-Host im Serverraum, dessen Aufgabe Inferenz ist, hat ausgehender Telegram-Verkehr nichts verloren. Die Frage ist nicht „Telegram ja oder nein", sondern „auf welchem Host und zu welchem Zweck".

In der Praxis: Dass Angreifer ein Agenten-Framework als Fernsteuerung benutzen, ist das erwartbare nächste Kapitel nach Cobalt Strike und Metasploit — Werkzeuge, die ebenfalls für legitime Zwecke gebaut wurden. Für die Bewertung eines Frameworks ist entscheidend, ob es sich kontrolliert betreiben lässt: eigene Persona, eigener Endpunkt, eigene Gateways, Protokollierung. Hermes Agent lässt das zu. Es verlangt es nur nicht — das ist Ihre Aufgabe. Wie ein solcher Assistent im eigenen Haus aufgesetzt wird, steht in OpenClaw / Hermes: Ihr eigener On-Premise-KI-Assistent.

/04Was gestohlen wird — und warum lokale Endpunkte auf der Liste stehen

Die Persona gibt eine Prioritätenliste vor. An erster Stelle stehen „AI API keys" von 14 Anbietern: OpenAI, Anthropic, Google, Gemini, OpenRouter, Together, Groq, Mistral, Cohere, LocalAI, Ollama, vLLM, LiteLLM und One API. Danach SSH-Zugänge, Zugriffstokens und Datenbanken. Alles landet im Klartext unter /root/.hermes/loot/ mit sprechenden Dateinamen. BleepingComputer berichtet zudem, dass die Operation gestohlene Schlüssel nutzt, um ihr eigenes LLM-Gateway zu betreiben — die Angreifer rechnen ihre Modellkosten über die Konten der Opfer ab.

Lesen Sie die Liste noch einmal: Ollama, vLLM, LiteLLM, LocalAI. Das sind keine Cloud-Dienste, das sind die Werkzeuge des On-Premise-Betriebs. Warum interessieren sich Angreifer für den API-Schlüssel eines lokalen vLLM-Servers?

• Weil er oft nicht lokal bleibt. Ein vLLM-Server mit --api-key und einem Reverse-Proxy davor ist aus dem Internet erreichbar, sobald jemand ihn für das Homeoffice freigibt. Der Schlüssel macht aus einer GPU im Rack einen kostenlosen Inferenzdienst für Fremde — das Muster, das als LLMjacking bekannt ist und das wir in LLMjacking stoppen: Ollama und vLLM richtig absichern beschrieben haben.
• Weil er Zugang zu Daten ist. Ein LiteLLM-Gateway oder ein Open-WebUI-Konto führt zu Chatverläufen, hochgeladenen Dokumenten und RAG-Beständen. Der Schlüssel öffnet nicht nur Rechenzeit, sondern den Wissensspeicher.
• Weil er auf demselben Host liegt wie alles andere. Wer OPENAI_API_KEY, ANTHROPIC_API_KEY und den vLLM-Schlüssel in derselben .env-Datei neben dem n8n-Container führt, hat dem Agenten eine Einkaufsliste mit Adressen hinterlegt.

ThreatDown rät, KI-API-Schlüssel „wie Bankzugangsdaten" zu behandeln: inventarisieren, rotieren, Nutzung überwachen. Für Cloud-Schlüssel heißt das Ausgabenlimits und Nutzungsalarme beim Anbieter. Für lokale Schlüssel heißt es: Sie müssen selbst messen, wer Ihren Endpunkt wie stark nutzt — Durchsatz pro Schlüssel ist der Indikator, den ein gekaperter Schlüssel nicht verbergen kann.

/05Warum KI-Hosts im Mittelstand besonders exponiert sind

Ein GPU-Server für Inferenz ist in der Regel kein Projekt der IT-Abteilung, sondern eines Fachbereichs, der schnell Ergebnisse wollte. Das hat Folgen für die Konfiguration, die sich in fast jedem Haus wiederholen:

• Docker wurde für die GPU eingerichtet, nicht für den Betrieb. Das NVIDIA Container Toolkit, --gpus all, ein Compose-File aus einem Tutorial. Dass der Daemon dabei auf tcp://0.0.0.0:2375 hört, weil ein Werkzeug wie Portainer oder eine Remote-IDE das verlangte, fällt niemandem auf — es funktioniert ja.
• Der Host steht im falschen Netz. Ein GPU-Server, der ins Büro-LAN gestellt wurde, weil dort der Switch-Port frei war, ist von jedem Arbeitsplatz aus erreichbar — und scannt im Fall einer Kompromittierung jeden Arbeitsplatz zurück. Carbonato sucht in jedem angeschlossenen /24.
• Privilegierte Container sind Alltag. Open WebUI mit Zugriff auf den Docker-Socket für Pipelines, n8n mit privileged: true, weil ein Node es brauchte, ein Monitoring-Container mit /:/host. Die Docker-Dokumentation sagt zu --privileged: Es gibt dem Container „Zugriff auf alle Geräte des Hosts" und „nahezu denselben Zugriff auf den Host wie Prozesse außerhalb von Containern". Mit anderen Worten: Der Container ist keine Grenze mehr.
• Schlüssel liegen in Umgebungsvariablen. docker inspect zeigt sie jedem, der den Socket erreicht. Eine .env-Datei neben docker-compose.yml ist für einen Agenten mit Root-Rechten der erste Fundort.
• Egress ist unbegrenzt. Der Host darf ins Internet, weil er Modelle von Hugging Face und Images von Docker Hub laden soll. Dass er damit auch Telegram, einen SSH-Tunnel nach Costa Rica und ein fremdes LLM-Gateway erreichen darf, ist dieselbe Regel.

Keiner dieser Punkte ist eine Lücke in Ollama, vLLM, Open WebUI oder n8n. Es sind Betriebsentscheidungen, die niemand bewusst getroffen hat. Carbonato ist der Beleg, dass sie trotzdem Folgen haben. Die CVE-Welle in den KI-Werkzeugen selbst — Langflow, Open WebUI, Dify — kommt obendrauf; sie steht in KI-Stack-CVEs 2026.

/06Checkliste: Docker auf GPU-Hosts härten

Sechs Punkte, in der Reihenfolge ihrer Wirkung. Der erste schließt den Carbonato-Einstieg vollständig; die anderen begrenzen den Schaden, wenn ein anderer Weg gefunden wird.

1. Docker-Socket nie auf 0.0.0.0 — und prüfen, ob er es ist

# Hört irgendetwas auf 2375/2376? Und was sonst noch nach außen?
ss -ltnp | grep -E ':(2375|2376|11434|8000|3000|5678)\b'

# Wie ist der Daemon konfiguriert?
cat /etc/docker/daemon.json 2>/dev/null
systemctl cat docker.service | grep -E '^ExecStart'
grep -rn 'DOCKER_OPTS\|-H tcp\|hosts' /etc/default/docker /etc/systemd/system/docker.service.d/ 2>/dev/null

Sauber ist: kein Eintrag für 2375 in der ss-Ausgabe, kein -H tcp:// in ExecStart, kein "hosts" mit tcp://0.0.0.0 in daemon.json. Der Standard ist der Unix-Socket unix:///var/run/docker.sock, und für die meisten GPU-Hosts gibt es keinen Grund, davon abzuweichen. Wer Fernzugriff braucht, nimmt SSH: DOCKER_HOST=ssh://admin@gpu01 funktioniert mit jedem Docker-Client und nutzt die vorhandene Schlüsselverwaltung.

2. Wenn TCP sein muss: Port 2376 mit TLS-Verifikation

{
  "hosts": ["unix:///var/run/docker.sock", "tcp://10.20.40.11:2376"],
  "tlsverify": true,
  "tlscacert": "/etc/docker/pki/ca.pem",
  "tlscert":   "/etc/docker/pki/server-cert.pem",
  "tlskey":    "/etc/docker/pki/server-key.pem",
  "no-new-privileges": true,
  "icc": false,
  "live-restore": true
}

tlsverify erzwingt Client-Zertifikate — ohne gültiges Zertifikat von Ihrer CA kommt keine Verbindung zustande, das ist der Unterschied zu bloßer Verschlüsselung. Die Bindung an die konkrete Management-Adresse statt 0.0.0.0 hält den Port aus dem Büro-LAN heraus. Die Docker-Dokumentation ist deutlich: Wer die Zertifikate hat, „kann dem Docker-Daemon beliebige Anweisungen geben, was Root-Zugriff auf den Host bedeutet. Schützen Sie diese Schlüssel wie ein Root-Passwort."

3. Keine privilegierten Container, kein Docker-Socket im Container

# Bestandsaufnahme: welche Container laufen privilegiert oder mit dem Socket?
docker ps -q | xargs -r docker inspect --format \
  '{{.Name}} privileged={{.HostConfig.Privileged}} caps={{.HostConfig.CapAdd}} mounts={{range .Mounts}}{{.Source}} {{end}}' \
  | grep -E 'privileged=true|docker.sock|CAP_SYS_ADMIN| / '

Jeder Treffer braucht eine Begründung, die in der Compose-Datei als Kommentar steht. Für GPU-Zugriff genügt --gpus über das Container Toolkit; --privileged ist dafür nicht nötig. Container, die den Docker-Socket brauchen (Portainer, Watchtower, manche n8n-Nodes), bekommen ihn über einen Socket-Proxy mit Positivliste erlaubter API-Pfade — oder sie laufen nicht auf dem GPU-Host.

4. Egress-Filter für den GPU-Host

# nftables: GPU-Host darf Modelle laden und den internen Proxy erreichen — sonst nichts
table inet gpu_egress {
  chain output {
    type filter hook output priority 0; policy drop;
    ct state established,related accept
    oif lo accept
    ip daddr 10.20.0.53 udp dport 53 accept           # interner Resolver
    ip daddr 10.20.0.0/16 accept                       # internes Netz (Clients, Proxy, Registry)
    ip daddr 10.20.0.80 tcp dport 3128 accept          # HTTP-Proxy mit Allowlist (huggingface.co, registry-1.docker.io)
    log prefix "gpu-egress-drop " limit rate 10/minute
    counter drop
  }
}

Modell-Downloads laufen über den Proxy, dessen Positivliste Sie pflegen. Ein Reverse-SSH-Tunnel nach AS262145, ein Telegram-API-Aufruf oder eine Verbindung zu 213.136.83.197 scheitern an der Standardregel — und erscheinen im Journal. Container erben die Regel nicht automatisch; mit "icc": false und einem eigenen Docker-Netz je Dienst begrenzen Sie auch den Verkehr zwischen Containern. Wie das für Inferenz-Endpunkte im Detail aussieht, steht in LLMjacking stoppen.

5. Schlüssel nicht in ENV

Umgebungsvariablen sind für jeden lesbar, der docker inspect ausführen oder /proc/<pid>/environ lesen darf — also für jeden mit Zugriff auf den Socket oder Root auf dem Host. Besser: Docker Secrets (auch ohne Swarm über secrets: mit Dateiquelle in Compose), Dateien mit Rechten 0400 in einem Volume, das nur der Dienstbenutzer liest, oder ein Secret-Store, aus dem der Dienst beim Start liest. Und: ein Schlüssel je Dienst. Der vLLM-Schlüssel von Open WebUI ist nicht der von n8n; wird einer gestohlen, rotieren Sie einen, nicht alle.

6. Dateiänderungen und Immutable-Attribute überwachen

Carbonato setzt das Immutable-Attribut auf seine Persistenzdateien. lsattr -R /etc/cron.d /etc/systemd/system /usr/local/bin 2>/dev/null | grep -- '-i-' findet sie — auf einem Host, auf dem Sie selbst nie chattr +i gesetzt haben, ist jeder Treffer ein Vorfall. Eine Dateiintegritätsprüfung (AIDE, Wazuh FIM) auf /etc, /usr/local/bin und /root meldet das automatisch.

/07Erkennung: Prozess- und Netzwerkindikatoren

ThreatDown nennt Indikatoren, die sich ohne Spezialwerkzeug prüfen lassen. Die folgende Tabelle ordnet sie dem Prüfbefehl zu; die Adressen stammen aus dem Bericht und können sich ändern — der Mechanismus dahinter nicht.

Echte Kernel-Threads wie kworker haben die Eltern-PID 2 (kthreadd) und keine Datei auf der Platte; ein Prozess mit diesem Namen und einer anderen Eltern-PID ist eine Tarnung. Das ist der zuverlässigste der Prozessindikatoren, weil er nicht von Pfaden abhängt, die der Angreifer im nächsten Image ändert.

Ein Fund bedeutet: Host vom Netz nehmen, nicht aufräumen. Carbonato hält paarweise Wächter vor, die das Implantat nachladen; ein gelöschtes Skript ist nach Minuten wieder da. Die Schlüssel, die auf dem Host lagen, gelten als kompromittiert — alle, nicht nur die in loot/ gefundenen — und werden rotiert. Welche Schlüssel das waren, wissen Sie nur, wenn Sie ein Inventar haben.

/08Grenzen: Was die Checkliste nicht leistet

Sie schützt nicht vor Lücken in den KI-Werkzeugen selbst. Ein geschlossener Docker-Port hilft nichts, wenn Open WebUI, Langflow oder Ollama eine Schwachstelle haben, die über den regulären Dienstport erreichbar ist. Patch-Stand bleibt die zweite Säule; die erste Hälfte des Jahres hat gezeigt, wie kurz die Fenster sind.

Sie schützt nicht vor dem, was im Container passiert. Ein n8n-Workflow mit einem Code-Node führt beliebigen JavaScript-Code aus — innerhalb des Containers, mit dessen Rechten und Netz. Ist der Container nicht privilegiert und das Netz gefiltert, bleibt der Schaden im Container. Ist er es doch, ist die Checkliste an Punkt 3 gescheitert, nicht an Punkt 1.

Ein Egress-Filter bremst den Betrieb. Modell-Downloads über einen Proxy mit Positivliste sind langsamer einzurichten als „darf alles". Ein neuer Modellanbieter, ein neues PyPI-Paket, ein neues Image — jedes braucht einen Eintrag. Das ist Arbeit, und sie fällt an, wenn jemand schnell etwas testen will. Wer sie nicht leisten will, sollte wenigstens die bekannten Kanäle sperren: Telegram-APIs, ausgehendes SSH, ausgehende Verbindungen zu Ports 4444 und 8080 außerhalb des eigenen Netzes.

Die Indikatoren veralten. Pfade, Adressen und das Passwort „carbonato125" stehen im nächsten Image anders. Was bleibt, ist das Verhalten: privilegierte Container, die niemand angelegt hat, Prozesse mit Kernel-Namen und falscher Eltern-PID, ausgehender Verkehr zu Zielen, die kein Dienst braucht. Darauf sollte die Erkennung bauen, nicht auf eine IP-Liste.

Und: Diese Checkliste ist kein Argument gegen Docker auf GPU-Hosts. Container sind der sinnvolle Weg, Inferenz-Stacks reproduzierbar zu betreiben. Carbonato nutzt eine Fehlkonfiguration des Daemons, keine Eigenschaft von Containern. Die Alternative — alles direkt auf dem Host, ohne Isolation — wäre schlechter, nicht besser.

/09Entscheidung: Wer heute den Port prüfen muss

Heute, vor Feierabend: jeder, der einen Docker-Host mit GPU betreibt und nicht aus dem Kopf sagen kann, ob der Daemon auf TCP hört. ss -ltnp | grep 2375 dauert zehn Sekunden. Ist das Ergebnis leer, haben Sie Zeit für den Rest. Ist es nicht leer, ist der Rest heute dran — und zwar mit der Annahme, dass der Port bereits gefunden wurde. Ein Daemon auf 0.0.0.0:2375, der aus dem Internet erreichbar ist, wird nach Erfahrung der letzten Jahre innerhalb von Stunden gescannt; Carbonato ist nur das Botnetz mit dem auffälligsten Werkzeug.

Diese Woche: jeder Betrieb mit mehr als einem KI-Dienst in Docker — Modellserver, Chat-Oberfläche, Automatisierung, Vektordatenbank. Punkte 3 bis 5 der Checkliste: privilegierte Container inventarisieren, Egress filtern, Schlüssel aus den Umgebungsvariablen holen. Das ist ein Tag Arbeit für einen Administrator, der Docker kennt, und es ist dieselbe Arbeit, die jedes andere System auch bekommt.

Nicht betroffen ist, wer Inferenz ohne Docker direkt auf dem Host betreibt — dann fehlt der Einstieg, aber die Fragen nach Egress, Schlüsseln und Segmentierung bleiben dieselben. Und nicht betroffen ist, wer einen Betreiber hat, der diese Liste als Routine abarbeitet; dann ist die Frage an den Betreiber nicht „Habt ihr Carbonato?", sondern „Zeigt mir die Egress-Regel des GPU-Hosts und das Datum der letzten Schlüsselrotation".

Für ein Haus, das KI auf eigener Hardware betreibt, ist Carbonato kein Grund zur Umkehr. Es ist der Beleg, dass On-Premise Verantwortung heißt: Die Schlüssel, die hier gestohlen werden, liegen auf Hardware, die Sie kontrollieren — und das ist nur dann ein Vorteil, wenn jemand die Kontrolle ausübt. Ein GPU-Server im Kubernetes-Cluster oder auf einem einzelnen Docker-Host ist ein privilegiertes System mit GPU und Internetzugang. Behandeln Sie ihn so.