CARBONATO macht aus ungeschützten Docker-Hosts ein KI-gestütztes Netzwerk zum Diebstahl von Zugangsdaten

Offene Docker-APIs verschaffen den Angreifern ersten Zugriff

CARBONATO ist ein Docker-basiertes Botnetz, das herkömmliche Methoden zur Kompromittierung von Servern mit einem Open-Source-KI-Agenten kombiniert. Die seit mindestens Oktober 2024 aktive Kampagne zielt auf Zugangsdaten ab – insbesondere auf API-Schlüssel für KI-Plattformen. Mit ihnen können die Betreiber ihr eigenes Gateway für große Sprachmodelle finanzieren.

Das Botnetz nimmt Docker-Daemons ins Visier, die ungeschützte Verbindungen über TCP-Port 2375 akzeptieren. CARBONATO nutzt keine bekannte Software-Schwachstelle aus, sondern missbraucht eine unsichere Konfiguration, die entfernten Clients Zugriff auf die Docker-API gewährt.

Konkrete betroffene Docker-Versionen wurden nicht genannt. Auch wurde die Kampagne weder einer CVE noch einem Eintrag im CISA-Katalog der bekannten, aktiv ausgenutzten Schwachstellen zugeordnet.

Sobald die Angreifer einen erreichbaren Daemon gefunden haben, verwenden sie die API, um einen privilegierten Container zu erstellen und das Host-Dateisystem darin einzubinden. So können aus dem Container heraus gestartete Befehle auch den zugrunde liegenden Server beeinflussen. Die Kontrolle über Docker wird damit zur Kontrolle über den Host.

Bei der Untersuchung von CARBONATO stießen Forschende auf die Kampagne, als sie eine über das Internet erreichbare Container-Registry ohne Authentifizierung fanden. Im Lauf eines Tages passiver Erhebungen im Nur-Lese-Modus sammelten sie 4,3 GB Image-Daten aus 59 Repositories mit 234 Tags und 605 verifizierten Datei-Blobs.

Die Registry gab mehr als nur Malware-Images preis. Aus den Konfigurationshistorien der Docker-Images gingen Command-and-Control-Adressen, Bot-Tokens und ein von den Betreibern gemeinsam genutztes Passwort für den Zugang zu ihrem KI-Gateway hervor.

Privilegierte Container sichern dauerhaften Zugriff auf den Host

CARBONATOs Komponente für die Erstinstallation ist entry.sh in Version 5.3, die als Skript der ersten Stufe beschrieben wird. Nach dem Start richtet sie einen umgekehrten SSH-Tunnel vom Opfer zur Relay-Infrastruktur in Costa Rica ein.

Der entfernte Tunnel-Port wird nicht zufällig ausgewählt. CARBONATO leitet ihn aus dem MD5-Hash der IP-Adresse des Opfers ab. Kennt ein Betreiber diese Adresse, kann er den erwarteten Port für die erneute Verbindung berechnen.

Das Skript installiert außerdem einen SSH-Server und hinterlegt einen öffentlichen Schlüssel, der von den Betreibern kontrolliert wird. Über Telegram meldet es die erfolgreiche Kompromittierung und übermittelt Container-ID, Hostname, IP-Adresse und Land. Die Einsatzmeldungen sind in spanischer Sprache mit Voseo verfasst, also mit der regionalen Anredeform „vos“.

Mehrere Mechanismen helfen der Malware, Neustarts und Bereinigungsversuche zu überstehen:

• Cron-Jobs;
• systemd-Timer;
• rc.local;
• OpenRC;
• unveränderliche Dateiattribute, die das Löschen oder Ändern erschweren sollen.

Eine Watchdog-Komponente überwacht die Installation. Verschwindet der schädliche Container, lädt der Watchdog das Implantat aus der öffentlich erreichbaren Registry herunter und installiert es erneut.

CARBONATO versucht auch, seine Prozesse unauffällig wirken zu lassen. Der Container trägt den Namen systemd-resolved, während ein gefälschtes Banner den Resolver von systemd-networkd nachahmt. Die Prozessargumente werden so manipuliert, dass sie wie der Kernel-Worker-Thread [kworker/u2:0] aussehen.

Diese Tarnung kann oberflächliche Prozessprüfungen erschweren. Sie macht die Aktivitäten jedoch nicht ununterscheidbar von legitimen Systemdiensten. Ein privilegierter Container, der das Host-Dateisystem einbindet, eine umgekehrte SSH-Verbindung herstellt und Telegram kontaktiert, ist weiterhin ein wichtiger Ermittlungsansatz.

Die Netzwerkausbreitung kommt ohne KI-Modell aus

Obwohl KI das interaktive Befehlssystem von CARBONATO maßgeblich unterstützt, ist sie nicht für die selbstständige Ausbreitung des Botnetzes verantwortlich.

Alle fünf Minuten untersucht ein Skript die Netzwerke, mit denen der infizierte Host verbunden ist, darunter Docker-Bridge-Netzwerke. Anschließend scannt es benachbarte /24-Adressbereiche nach Systemen, auf denen ein Docker-Daemon über Port 2375 erreichbar ist.

Findet CARBONATO einen erreichbaren Daemon, prüft die Malware, ob das Ziel bereits infiziert ist. Ist das nicht der Fall, installiert sie über die Docker-API dieselbe schädliche Umgebung. Der neu kompromittierte Rechner beginnt daraufhin ebenfalls mit dem Scannen.

So kann sich die Malware wiederholt ausbreiten, ohne dass dafür ein neuer Telegram-Befehl oder ein vom Modell generierter Befehl nötig ist. Eine Kompromittierung, die auf einem einzelnen ungeschützten Server beginnt, kann dadurch auch auf benachbarte Netzwerksegmente übergreifen, die von diesem Host aus erreichbar sind.

Unmittelbar betroffen sind Administratoren und Unternehmen, die ungeschützte Docker-APIs betreiben. Die Folgen gehen jedoch über Container-Workloads hinaus: Durch das privilegierte Einbinden des Host-Dateisystems erhält die Malware Zugriff auf lokal gespeicherte Dateien und Geheimnisse.

Hermes Agent wird über seine Persona-Datei umfunktioniert

Das Implantat installiert Hermes Agent, ein Open-Source-Framework unter MIT-Lizenz, das von Nous Research entwickelt wurde. CARBONATO verändert nicht den zugrunde liegenden Framework-Code, sondern die Anweisungen, die das Verhalten des Agenten festlegen.

Die Betreiber ersetzen den Inhalt der Persona-Datei SOUL.md durch einen 39-zeiligen Prompt und benennen den Agenten in „GH0ST“ um. Darin wird er angewiesen, als Post-Exploitation-Werkzeug zu agieren, über Telegram übermittelte Aufgaben auszuführen, den Zugriff aufrechtzuerhalten und Zugangsdaten zu sammeln.

Dieser Ansatz erschwert eine Erkennung, die allein auf dem Softwarebestand beruht. Die Installation von hermes-agent beweist nicht, dass ein Server infiziert ist, denn das Framework wird auch für legitime Zwecke eingesetzt. Verteidiger sollten daher die Konfiguration, die Persona-Anweisungen, die zugehörigen Persistenzmechanismen und die Kommunikation prüfen.

Die schädliche Persona priorisiert Zugangsdaten für KI-Dienste vor SSH-Zugangsdaten, allgemeinen Zugriffstokens und Datenbankgeheimnissen. Sie nennt ausdrücklich 14 Anbieter und Technologien:

• OpenAI
• Anthropic
• Google
• Gemini
• OpenRouter
• Together
• Groq
• Mistral
• Cohere
• LocalAI
• Ollama
• vLLM
• LiteLLM
• One API

Das LLM-Gateway der Betreiber war Berichten zufolge am 3. September online und wurde in einem kostenlosen Tarif betrieben. Es bot zwölf Modelle an, von denen sich 27 über die API nutzen ließen.

Im Betriebsablauf von CARBONATO sendet ein Angreifer eine Aufgabe über Telegram. Hermes leitet die Anfrage zusammen mit der schädlichen Persona aus SOUL.md an das Gateway weiter. Ein ausgewähltes Modell generiert Terminalbefehle, wertet deren Ausgabe aus und entscheidet über die nächsten Schritte. Die Ergebnisse landen wieder in demselben Telegram-Chat, über den auch die Installationsmeldungen versendet werden.

Das Modell stellt somit eine adaptive Schnittstelle zur Befehlsausführung bereit. Es kann auf Unterschiede zwischen kompromittierten Systemen reagieren, ohne dass die Betreiber für jeden Host eigene Skripte erstellen müssen. Der menschliche Betreiber stößt die Aufgaben weiterhin an; das LLM setzt diese Ziele in Befehle und Folgeaktionen um.

Gestohlene KI-Schlüssel finanzieren weitere Aktivitäten

Der Fokus von CARBONATO auf KI-Zugangsdaten verleiht der Kampagne eine selbstfinanzierende Komponente. Gestohlene API-Schlüssel können die Kosten für die Modellnutzung auf die Opfer abwälzen und dem Botnetz zugleich den weiteren Zugriff auf externe Inferenzdienste ermöglichen.

Je nach Dienst und Berechtigungen können kompromittierte Schlüssel außerdem Einblick in die kontospezifische Nutzung, Kontingente oder verbundene Anwendungen geben. Wie viele Schlüssel gestohlen wurden und wie viele Unternehmen betroffen sind, ist nicht bekannt.

Die Kampagne birgt mehrere miteinander verbundene Risiken: dauerhafter Fernzugriff, privilegierte Befehlsausführung, Diebstahl verschiedener Arten von Zugangsdaten, automatisierte Ausbreitung im Netzwerk und KI-gestützte Post-Exploitation. Eine formale Schweregradeinstufung wurde nicht vergeben.

Die öffentlich erreichbare Registry erfüllt zwei Zwecke: Sie verteilt das Implantat an infizierte Hosts, und ihre schwachen Zugriffskontrollen gaben zugleich interne Betriebsdaten preis, die zur Aufdeckung der Kampagne beitrugen.

Es gibt Hinweise auf eine mögliche Verbindung zu Costa Rica, doch sie belegen nicht den tatsächlichen Aufenthaltsort der Betreiber. Vierzehn von 162 untersuchten Image-Konfigurationen enthielten Zeitstempel in UTC-06:00, die mit der Zeitzone Costa Ricas übereinstimmen. Der Telegram-Handle Carbo506 enthält die Ländervorwahl +506, und die umgekehrten SSH-Verbindungen endeten bei AS262145, einem costa-ricanischen Netzwerk.

Auch das Voseo im Spanischen liefert einen sprachlichen Hinweis. Keines dieser Indizien ist jedoch eindeutig, und die Infrastruktur in Costa Rica könnte von einem anderen Land aus gesteuert werden.

Was Administratoren prüfen und absichern sollten

Die wichtigste Schutzmaßnahme besteht darin, ungeschützte Netzwerkzugriffe auf die Docker-Daemon-API zu verhindern. Port 2375 sollte nicht für nicht vertrauenswürdige Netzwerke erreichbar sein. Zugriffe müssen auf autorisierte Systeme beschränkt werden.

Auch Container-Registries benötigen Authentifizierung und sollten nur eingeschränkt über das Netzwerk erreichbar sein. Eine offene Registry kann eingebettete Geheimnisse, Image-Verläufe, interne Werkzeuge und einsatzbereite Malware-Komponenten preisgeben.

Bei der Suche nach möglichen CARBONATO-Infektionen sollten Verteidiger auf folgende Hinweise achten:

• /root/.hermes/SOUL.md mit dem Namen GH0ST;
• .env-Dateien mit CARBONATO_API_KEY;
• unerklärlicher ausgehender Telegram-Datenverkehr von Servern;
• privilegierte Container mit dem Namen systemd-resolved;
• umgekehrte SSH-Verbindungen ohne genehmigten administrativen Zweck;
• unerwartete SSH-Schlüssel, Cron-Einträge, systemd-Timer, Änderungen an rc.local oder Persistenzmechanismen von OpenRC;
• ohne dokumentierten betrieblichen Grund als unveränderlich markierte Dateien;
• wiederkehrende Scans nach TCP-Port 2375 in lokalen /24-Netzen.

Administratoren sollten Hermes Agent nicht allein deshalb blockieren, weil die Software installiert ist. Die Untersuchung sollte sich auf schädliche Persona-Inhalte und das Verhalten im Umfeld konzentrieren.

Unternehmen sollten außerdem die in ihrer Infrastruktur gespeicherten KI-API-Schlüssel erfassen, offengelegte oder nicht erklärbare Zugangsdaten austauschen und die anschließende Nutzung überwachen. Bei dieser Kampagne sind solche Schlüssel kein beiläufiger Fund, sondern ein Hauptziel und eine Ressource, mit der die KI-gestützten Aktivitäten des Botnetzes aufrechterhalten werden sollen.