Ein Docker-Host mit einer nicht authentifizierten API im Internet bietet nicht bloß eine bequeme Funktion zur Fernverwaltung an. Er stellt einen entfernten Zugang zu der Maschine bereit, auf der die Container laufen. Die am 30. September gemeldete CARBONATO-Kampagne macht diesen Unterschied schwer zu ignorieren: Angreifer nutzen offengelegte Docker-Remote-APIs, um privilegierte Container zu erstellen, Persistenz einzurichten, Zugangsdaten zu stehlen und nach weiteren Docker-Hosts zu suchen.

Redaktionelle Illustration eines exponierten Docker-Hosts mit einem Zugriffsweg aus dem Internet zum Server und zur Container-Steuerung.

Der Vorfall ist bemerkenswert, weil es im Kern nicht um eine neue Schwachstelle in Docker geht. Es geht darum, dass eine administrative Schnittstelle ohne Authentifizierungsgrenze in ein nicht vertrauenswürdiges Netz gestellt wurde. Die Schadsoftware bringt zwar eine moderne Nutzlast mit, darunter ein zweckentfremdetes Open-Source-Framework für KI-Agenten. Die auslösende Bedingung ist jedoch älter und einfacher: Wer den Daemon erreichen kann, darf ihn auffordern, Operationen mit den Rechten des Hosts auszuführen.

Für Teams, die Docker auf Cloud-Servern, Build-Rechnern, Entwicklungs-Hosts, selbst betriebenen Diensten oder Edge-Systemen einsetzen, ist eine Prüfung auf Exposition und Kompromittierung angezeigt. Den nicht authentifizierten Zugang schließen, die Nutzung des Hosts ermitteln, alles rotieren, was dort gelesen werden konnte, und anschließend benachbarte Systeme prüfen. Einen Container neu zu installieren oder ein Image-Tag zu ändern reicht nicht, wenn der zugrunde liegende Host oder seine Zugangsdaten möglicherweise bereits unter fremder Kontrolle stehen.

Was die CARBONATO-Berichte tatsächlich aussagen

Die am 30. September veröffentlichte Warnung der Cyber Security Agency of Singapore besagt, dass Forscher eine Botnet-Kampagne gegen Docker-Hosts identifiziert haben, deren nicht authentifizierte Remote-APIs im Internet erreichbar waren, typischerweise über TCP-Port 2375. Die Warnung beschreibt, wie die Kampagne legitime Docker-Funktionen nutzt, um einen privilegierten Container mit Zugriff auf Dateisystem, Prozesse und Netzwerk des Hosts zu erstellen.

Diese Abfolge ist entscheidend. Der Angreifer muss keinen Memory-Safety-Fehler in Docker Engine ausnutzen, wenn der Daemon administrative Anfragen von einer nicht vertrauenswürdigen Partei akzeptiert. Eine Anfrage, die für einen Administrator normal ist – einen Container erstellen, einen Pfad einbinden, einen Prozess starten oder ein Netzwerk verbinden –, kann zu Kontrolle auf Host-Ebene werden, wenn der Absender nicht authentifiziert ist und der Daemon mit hohen Rechten läuft.

Die singapurische Warnung sagt, dass die Kampagne dauerhaften Fernzugriff einrichten, Zugangsdaten und andere sensible Informationen stehlen und verbundene Netze nach weiteren offengelegten Docker-Hosts durchsuchen kann. Sie behauptet nicht, dass jeder exponierte Host kompromittiert wurde, und liefert auch keinen universellen Indikator, der einen Vorfall allein beweisen oder ausschließen könnte. Diese Grenzen sind wichtig. Die Warnung ist ein Anlass, Exposition und Protokolle zu untersuchen – keine Erlaubnis, jede Docker-Installation als infiziert zu bezeichnen.

Eine separate Forschungsnotiz der Cloud Security Alliance liefert Kontext zur Nutzlast. Sie beschreibt CARBONATO als sich selbst verbreitendes Botnet, das ein unverändertes Open-Source-Framework für KI-Agenten, Hermes Agent, installiert und dessen Persona-Konfiguration so verändert, dass das Framework den Zielen der Betreiber dient. Laut der Forschungsnotiz scannen infizierte Hosts benachbarte Netzwerkbereiche nach weiteren Docker-Daemons.

Ungewöhnlich ist die Wahl der Nutzlast. Für Verteidiger bleibt der Zugangsweg der entscheidende Punkt. Die Präsenz eines KI-Frameworks kann Aufmerksamkeit auf sich ziehen, aber ein Angreifer braucht keinen KI-Agenten, um einen offengelegten Docker-Daemon in einen schwerwiegenden Vorfall zu verwandeln. Dieselbe administrative Exposition könnte den Diebstahl von Zugangsdaten, Cryptomining, destruktive Aktionen, Proxying, laterale Bewegungen oder die Bereitstellung einer herkömmlichen Backdoor ermöglichen.

Warum Port 2375 eine präzise Reaktion verdient

Die Docker-Dokumentation unterscheidet zwischen dem normalen lokalen Socket und entfernten Netzwerkverbindungen. Standardmäßig verwendet Docker unter Linux und macOS einen nicht über das Netzwerk erreichbaren Unix-Socket. Für die Fernverwaltung können stattdessen SSH oder ein TCP-Socket mit TLS und Client-Authentifizierung eingesetzt werden.

Die Docker-Dokumentation nennt außerdem die übliche Aufteilung der Ports: TCP 2375 wird normalerweise für eine unsichere Verbindung ohne TLS verwendet, während TCP 2376 konventionell mit TLS verbunden ist. Die Portnummer allein beweist keine Kompromittierung, und ein anderer Port macht eine nicht authentifizierte API nicht sicher. Port 2375 ist lediglich ein nützliches Erkennungssignal, weil er häufig darauf hinweist, dass ein Docker-Daemon für einfachen Fernzugriff konfiguriert wurde.

Die entscheidende Frage lautet nicht isoliert: „Ist Port 2375 offen?“ Sie lautet:

  • Welcher Prozess lauscht dort?
  • Ist der Listener aus dem öffentlichen Internet, einem weitreichenden Unternehmensnetz oder nur aus einem eingeschränkten Management-Segment erreichbar?
  • Verlangt er Authentifizierung und autorisiert er den Client angemessen?
  • Welcher Docker-Daemon, welches Konto, welcher Host und welcher Workload stehen dahinter?
  • Gibt es Protokolleinträge für Anfragen, die der Betreiber nicht gestellt hat?

Ein internetseitig erreichbarer Dienst kann gefährlich sein, auch wenn er nicht global zugänglich ist. Ein Daemon in einem flachen internen Netz kann weiterhin von einer kompromittierten Workstation, einem Gerät eines Auftragnehmers, einem Entwicklungskonto oder einem anderen Workload erreicht werden, der niemals administrative Kontrolle über den Host haben sollte. „Er ist nur innerhalb der VPC offen“ beschreibt das Netzwerk, nicht das Autorisierungsmodell.

Das Kernproblem: Docker-Zugriff bedeutet Host-Zugriff

Container sind nützliche Isolationsgrenzen, aber der Zugriff auf den Docker-Daemon ist ein Verwaltungsprivileg. Docker warnt davor, die Bindung des Daemons an einen TCP-Socket zu ändern oder über die docker-Gruppe Zugriff auf den Unix-Socket zu gewähren, weil ein Benutzer dadurch Zugriff auf den Host mit Root-Rechten erlangen kann. Diese Warnung wird leicht übersehen, wenn ein Team ein Build-System repariert oder die Remote-Entwicklung bequemer machen möchte.

Ein Container, der mit erweiterten Rechten erstellt wurde, kann möglicherweise Host-Ressourcen sehen oder verändern. Auch ohne eine Angriffskette nachzustellen, ist die defensive Schlussfolgerung eindeutig: Docker-Daemon-Zugangsdaten und Socket-Zugriff sind wie Root-Zugangsdaten zu behandeln. Sie gehören in dieselbe Risikokategorie wie Cloud-Administratorschlüssel, Management-Schnittstellen von Hypervisoren und der Zugriff auf Kubernetes-Control-Planes.

Darum ist das Löschen eines verdächtigen Containers allein eine schwache Eindämmungsmaßnahme. Wenn ein Angreifer Zugriff auf den Daemon hatte, konnte er möglicherweise Umgebungsvariablen lesen, Host-Verzeichnisse einbinden, andere Container untersuchen, Konfigurationsdateien kopieren, Startmechanismen verändern, zusätzliche Konten anlegen oder Zugangsdaten vom Host sammeln. Der sichtbare Container kann nur ein Artefakt einer umfassenderen Kompromittierung sein.

Dasselbe Prinzip gilt für CI-Runner. Ein Build-Runner mit Zugriff auf einen privilegierten Docker-Socket kann Quellcode, Signiermaterial, Paket-Zugangsdaten, Cloud-Tokens und Berechtigungen für Deployments offenlegen. Ein Entwickler-Laptop mit eingebundenem Docker-Socket kann lokale Dateien und die Host-Umgebung preisgeben. Eine aus Bequemlichkeit eingerichtete Remote-API kann deshalb von einem Container-Workflow in die Identitäten und die Infrastruktur rundherum führen.

Was Administratoren zuerst tun sollten

Die erste Reaktion sollte die Reichweite eines Angreifers verringern, ohne Beweise zu zerstören.

1. Jeden Docker-Daemon mit Netzwerkexposition identifizieren

Beginnen Sie mit einem belastbaren Inventar statt mit Erinnerungen. Prüfen Sie Cloud-Sicherheitsgruppen, Host-Firewalls, Load-Balancer, VPN-Routen, Service-Discovery-Einträge, die Konfiguration der Container-Hosts, systemd-Unit-Dateien, Daemon-Konfigurationsdateien, Orchestrierungs-Templates und Repositories für Infrastructure as Code.

Suchen Sie nach Docker-Daemon-Listenern auf TCP-Ports 2375 und 2376, aber auch nach benutzerdefinierten Ports und Bindings, etwa einem Daemon, der auf allen Schnittstellen lauscht. Prüfen Sie Produktions- und Nicht-Produktionsumgebungen. Entwicklungs-Hosts sind häufig stärker exponiert, schlechter überwacht und mit Netzen verbunden, in denen wertvolle Zugangsdaten liegen.

Die CISA-Leitlinie zur Reduzierung der Internet-Exposition empfiehlt, Sichtbarkeit für internetseitig erreichbare Assets aufzubauen und unnötige Exposition zu reduzieren. Derselbe Ansatz gilt für interne Exposition: Ermitteln Sie, was von wo aus erreichbar ist und aus welchem geschäftlichen Grund. Ein Asset, das im Inventar fehlt, kann nicht zuverlässig gepatcht, überwacht oder untersucht werden.

Wenn ein nicht authentifizierter Daemon exponiert ist, beschränken Sie den Zugriff sofort auf Netzwerkebene und bewahren Sie dabei Protokolle und Änderungsaufzeichnungen. Das unmittelbare Ziel besteht darin, neue nicht authentifizierte Verbindungen zu stoppen. Gehen Sie nicht davon aus, dass eine Firewall-Änderung die Sauberkeit des Hosts beweist; sie verändert nur, wer ihn erreichen kann.

2. Einfachen Fernzugriff entfernen

Dockers offizielle Anleitung zum Schutz des Daemon-Sockets empfiehlt, den Fernzugriff mit SSH oder TLS abzusichern. SSH kann für Betreiber-Workflows praktisch sein, weil es Anfragen an den entfernten Unix-Socket weiterleitet und dabei auf das bestehende Authentifizierungs- und Autorisierungsmodell des Hosts setzt.

Wenn TCP-Zugriff tatsächlich erforderlich ist, verwenden Sie gegenseitig authentifiziertes TLS mit einer kontrollierten Zertifizierungsstelle, schützen Sie private Schlüssel, beschränken Sie Quellnetze und protokollieren Sie administrative Aktivitäten. Ein TLS-verschlüsselter, nicht authentifizierter Dienst bleibt ein Autorisierungsproblem. Verschlüsselung schützt den Datenverkehr vor Beobachtung und Manipulation; sie entscheidet nicht, ob ein Client privilegierte Container erstellen darf.

Bevorzugen Sie einen privaten Managementpfad gegenüber einem öffentlichen Listener. Wenden Sie das Prinzip der geringsten Rechte auf Identitäten an, die den Daemon verwalten dürfen, trennen Sie menschliche Administration von Automatisierung und verteilen Sie kein breit wiederverwendbares Client-Zertifikat an Build-Jobs oder mehrere Teams. Ein Client-Zertifikat mit uneingeschränktem Docker-Zugriff ist wie ein Host-Root-Zugang zu behandeln.

Lösen Sie eine Exposition nicht allein durch das Ändern der Portnummer. Sicherheitsgruppen, Host-Firewalls, Routing, Authentifizierung und Autorisierung müssen gemeinsam die beabsichtigte Managementgrenze durchsetzen.

3. Beweise sichern und prüfen

Bei einem möglicherweise exponierten Host sollten Sie relevante System-, Firewall-, Cloud-, Docker-, Orchestrierungs- und Identitätsprotokolle sichern, bevor Sie ihn neu aufsetzen oder Zugangsdaten rotieren. Ermitteln Sie den Zeitraum, in dem der Daemon erreichbar war, und vergleichen Sie ihn mit der Kampagnenberichterstattung und Ihrer eigenen Telemetrie.

Nützliche Prüf Fragen sind:

  • Gab es unerwartete Anfragen an Docker-API-Endpunkte?
  • Wurden außerhalb normaler Deployment-Zeitfenster Container erstellt, gestartet, angehalten oder entfernt?
  • Sind neue Images, Registries, Netzwerke, Volumes oder Secrets aufgetaucht?
  • Wurden unerwartet Host-Pfade in Container eingebunden?
  • Lief ein Container mit erweiterten Privilegien, Host-Netzwerk oder Zugriff auf sensible Verzeichnisse?
  • Wurden auf dem Host neue Prozesse, Benutzer, geplante Aufgaben, Dienste, SSH-Schlüssel oder Starteinträge angelegt?
  • Hat der Host ungewöhnliche ausgehende Verbindungen aufgebaut, insbesondere zu Command-and-Control-Infrastruktur oder unbekannten Registries?
  • Zeigten andere Hosts im selben Netz kurz danach Verbindungsversuche mit Docker-Bezug?

Das Ziel ist nicht, nach einem magischen Dateinamen zu suchen. Angreifer können Container entfernen, Prozesse umbenennen, legitime Werkzeuge verwenden oder eine andere Nutzlast einsetzen. Korrelieren Sie API-Aktivitäten mit Prozessausführung, Netzwerkflüssen, Registry-Zugriff, Cloud-Audit-Ereignissen und Protokollen des Identitätsanbieters.

Wenn der Host sensible Workloads enthält oder die Protokolle nicht klären können, was geschehen ist, isolieren Sie ihn und folgen Sie dem Incident-Response-Prozess Ihrer Organisation. Bauen Sie ihn aus einem vertrauenswürdigen Image neu auf, wenn die Integrität des Hosts zweifelhaft ist. Ein Neuaufbau ist belastbarer, wenn auch Zugangsdaten, Konfiguration und Deployment-Artefakte geprüft und nicht einfach vollständig vom möglicherweise kompromittierten System übernommen wurden.

4. Exponierte Secrets nach ihrer Berechtigung rotieren

Gehen Sie davon aus, dass Secrets, die für den Docker-Daemon, den Host, eingebundene Volumes, Umgebungsvariablen, Image-Layer oder laufende Prozesse lesbar waren, offengelegt worden sein können. Priorisieren Sie Zugangsdaten danach, was sie ermöglichen, nicht danach, wo sie gespeichert waren.

Dazu können Cloud-Zugriffsschlüssel, CI-Tokens, Quellcodeverwaltungs-Tokens, Registry-Zugangsdaten, Datenbankpasswörter, SSH-Schlüssel, Signierschlüssel, Webhook-Secrets, Service-Account-Tokens und in Deployment-Dateien eingebettete Zugangsdaten gehören. Widerrufen oder rotieren Sie sie über einen vertrauenswürdigen administrativen Zugang. Prüfen Sie, ob die neuen Zugangsdaten nach ihrer Ausstellung unerwartet verwendet wurden.

Rotation ohne Widerruf ist unvollständig, wenn die alte Zugangsdaten weiterhin gültig bleiben. Rotation ohne Protokollprüfung übersieht, dass ein Angreifer das Secret möglicherweise bereits zum Zugriff auf einen anderen Dienst verwendet hat. Rotation ohne Abhängigkeitsübersicht kann die Produktion stören und muss daher koordiniert werden. Betriebliche Unannehmlichkeiten sind jedoch kein Grund, hochwertige Zugangsdaten nach einer glaubhaften Exposition aktiv zu lassen.

Prüfen Sie außerdem Secrets, die nicht direkt auf dem Host gespeichert waren, aber über dessen Identität erreichbar waren. Eine kompromittierte Cloud-Instance-Rolle, Workload-Identität oder ein CI-Servicekonto kann den Vorfall weit über einen einzelnen Docker-Server hinaus ausweiten.

Wie eine sichere Architektur aussieht

Eine belastbare Docker-Umgebung hat normalerweise einen schmalen administrativen Zugang und einen ausdrücklichen Grund für jede Ausnahme.

Für die lokale Administration sollte der standardmäßige Unix-Socket durch die Zugriffskontrollen des Hosts geschützt bleiben. Beschränken Sie die Mitgliedschaft in der docker-Gruppe. Diese Mitgliedschaft ist keine harmlose Bequemlichkeit; sie kann weitreichende Kontrolle über den Daemon und damit über den Host geben.

Für die Fernverwaltung verwenden Sie SSH oder gegenseitig authentifiziertes TLS, begrenzen Quelladressen und stellen den Dienst gegebenenfalls hinter ein Managementnetz oder ein VPN. Bewahren Sie Protokolle außerhalb des Hosts auf, damit ein Angreifer nicht die einzige Kopie löschen kann. Überwachen Sie die Ausstellung von Zertifikaten, die Nutzung von Schlüsseln und Änderungen an der Daemon-Konfiguration.

Für CI sollten Sie einem nicht vertrauenswürdigen Build-Job keinen privilegierten Host-Socket überlassen. Rootless-Modi, isolierte Runner, kurzlebige Worker, getrennte Build- und Deployment-Identitäten sowie eng begrenzte APIs können helfen. Wenn ein Build tatsächlich privilegierte Operationen benötigt, behandeln Sie den Runner als risikoreiches Administrationssystem und isolieren Sie ihn entsprechend.

In Cloud-Umgebungen sollten Docker-Listener in das Management der Angriffsfläche und in die Erkennung von Konfigurationsabweichungen aufgenommen werden. Eine sichere Vorlage kann später durch ein Startskript, eine in ein Image eingebaute Daemon-Konfiguration, einen Fehlerbehebungsbefehl oder eine vorübergehende Firewall-Ausnahme ausgehebelt werden, die dauerhaft bestehen bleibt.

Für Entwickler sollte der genehmigte Remote-Workflow dokumentiert sein. Teams richten unsichere Listener oft ein, weil der sichere Weg unklar oder unbequem ist. Ein unterstützter SSH-Kontext, eine verwaltete Entwicklungsumgebung oder ein gut konzipierter Build-Dienst nimmt den Druck, einen Daemon direkt zu exponieren.

Exposition und bestätigte Kompromittierung unterscheiden

Ein öffentlicher oder intern weitreichend erreichbarer Docker-Listener ist ein schwerwiegender Befund, aber noch kein automatischer Beweis dafür, dass ein Angreifer ihn genutzt hat. Halten Sie in Incident-Aufzeichnungen drei Zustände auseinander:

  1. Exposition bestätigt: Der Daemon akzeptierte Verbindungen aus einem nicht vertrauenswürdigen Netz oder hätte sie akzeptieren können.
  2. Verdächtige Aktivität festgestellt: Protokolle oder Host-Telemetrie zeigen Anfragen, Prozesse, Netzwerkaktivitäten oder Konfigurationsänderungen, die sich nicht durch autorisierte Arbeit erklären lassen.
  3. Kompromittierung bestätigt: Die Ermittler verfügen über ausreichende Beweise, dass eine unbefugte Partei Kontrolle erlangt oder auf Daten zugegriffen hat.

Diese Unterscheidung verbessert Entscheidungen. Eine bestätigte Exposition sollte sofortige Abschottung und eine risikobasierte Prüfung auslösen. Bei festgestellter verdächtiger Aktivität sind Eindämmung und Incident Response erforderlich. Eine bestätigte Kompromittierung verlangt vollständige Eingrenzung, Widerruf von Zugangsdaten, Wiederherstellung, eine Bewertung möglicher Benachrichtigungen und die Aufarbeitung der Erkenntnisse.

Sie verhindert auch zwei häufige Fehler. Der erste ist Selbstzufriedenheit: „Wir haben keinen bösartigen Container gesehen, also war die Exposition harmlos.“ Der zweite ist Übertreibung: „Port 2375 war offen, also war die gesamte Umgebung definitiv kompromittiert.“ Gute Sicherheitsberichte können dringlich sein, ohne mehr zu behaupten, als die Beweise hergeben.

Der KI-Aspekt ist zweitrangig, aber trotzdem nützlich

CARBONATOs Einsatz eines Frameworks für KI-Agenten ist ein Hinweis darauf, wie Angreifer Automatisierung verpacken können, kein Grund, jede KI-Komponente grundsätzlich als bösartig einzustufen. Das von der Cloud Security Alliance beschriebene Framework ist Open Source und kann legitime Verwendungszwecke haben. Seine Zweckentfremdung in einem Botnet zeigt ein bekanntes Sicherheitsmuster: Legitime Software wird Teil eines Angriffs, wenn ein Gegner die umgebende Ausführungsumgebung und Konfiguration kontrolliert.

Verteidiger sollten deshalb die installierte Software, Konfigurationsdateien, geplante Aktivitäten, ausgehende Ziele und verwendeten Zugangsdaten in die Untersuchung aufnehmen. Wer nur nach einem Produktnamen sucht, kann eine veränderte Bereitstellung oder eine vollständig andere Nutzlast übersehen. Umgekehrt lässt das Sperren eines legitimen Framework-Namens den ursprünglichen Zugangsweg offen, wenn die Docker-Exposition nicht behoben wird.

Die größere Lehre betrifft Grenzen der Automatisierung. Ein KI-Framework auf einem kompromittierten Host kann die flexible Ausführung von Aufgaben erleichtern, erzeugt aber nicht die anfängliche Berechtigung. Diese Berechtigung kam vom Docker-Daemon. Starke Authentifizierung, Netzsegmentierung, Host-Integrität, sauberes Geheimnismanagement und brauchbare Protokolle bleiben die entscheidenden Kontrollen.

Praktische Checkliste für die nächste Prüfung

Teams können diesen Vorfall in eine wiederholbare Kontrollprüfung überführen:

  • Alle Docker-Daemons und die Netze, die sie erreichen können, inventarisieren.
  • Bestätigen, dass keine nicht authentifizierte Docker-API im Internet oder in einem nicht vertrauenswürdigen internen Netz exponiert ist.
  • Nach TCP 2375 und benutzerdefinierten Daemon-Listenern suchen, nicht nur nach erwarteten Dienstnamen.
  • Ad-hoc-TCP-Administration durch SSH oder korrekt konfiguriertes, gegenseitig authentifiziertes TLS ersetzen.
  • Docker-Socket-Zugriff beschränken und die Mitgliedschaft in der docker-Gruppe prüfen.
  • CI-Runner von sensiblen Produktionsnetzen und Zugangsdaten trennen.
  • Docker-, Host-, Firewall-, Cloud-, Identitäts- und Registry-Protokolle zentralisieren.
  • Unerwartete Container-Erstellungen, privilegierte Einstellungen, Host-Mounts, neue Images und ausgehende Verbindungen prüfen.
  • Zugangsdaten rotieren, die von betroffenen Hosts oder Workloads lesbar gewesen sein könnten.
  • Hosts aus vertrauenswürdigen Medien neu aufbauen, wenn ihre Integrität nicht festgestellt werden kann.
  • Daemon-Exposition und Konfigurationsabweichungen in regelmäßige Sicherheitsprüfungen aufnehmen.
  • Einen genehmigten Workflow für die Fernverwaltung dokumentieren, damit Entwickler keine Notfall-Listener anlegen.

CARBONATO erinnert zeitnah daran, dass die Control Plane einer Containerplattform selbst ein kritisches Asset ist. Die entscheidende Abwehrmaßnahme besteht nicht darin, über die Neuartigkeit der Nutzlast zu spekulieren. Es geht darum zu prüfen, wer den Daemon erreichen kann, was der Daemon tun darf, was er kürzlich getan hat und welche Identitäten offengelegt wären, wenn der Host kompromittiert worden wäre. Werden diese Fragen zur Routine, lässt sich das Risiko ohne Panik und ohne Wunschdenken besser beherrschen.

Quellen