Neuigkeiten zu Sicherheit und KI

Sicherheit von KI-Agenten · Von FireAI Security & Research Team · Veröffentlicht

Carbonato-Botnetz installiert Hermes Agent auf offenen Docker-Hosts und nimmt Befehle über Telegram entgegen

ThreatDown berichtet von einem Botnetz, das den Open-Source-Agenten Hermes Agent auf Docker-Hosts mit offenem Port 2375 installiert. Was die Quellen sagen und welche Härtung Hermes dokumentiert.

An AI agent icon on a server stack with an open port, illustrating the Carbonato botnet deploying Hermes Agent on Docker hosts exposed without authentication.

Forscher von ThreatDown beschreiben ein Botnetz namens Carbonato, das ohne Authentifizierung im Internet erreichbare Docker-Daemons übernimmt und darauf Hermes Agent installiert, ein quelloffenes Framework für KI-Agenten; BleepingComputer berichtete am 24. September 2026 über die Ergebnisse [1] [2]. Hermes Agent ist das Werkzeug, das die Angreifer gewählt haben, und nicht Gegenstand einer gemeldeten Schwachstelle: Der Artikel von BleepingComputer bezeichnet den Missbrauch nicht als Schwäche des Frameworks [1].

Hintergrund

Hermes Agent ist ein quelloffenes Agenten-Framework von Nous Research, das Befehle in einem Terminal des Betriebssystems ausführen und auf Anweisungen aus Messaging-Kanälen reagieren kann. Die eigene Dokumentation beschreibt ein Freigabesystem mit drei Modi (smart, manual und off), einen optionalen YOLO-Modus, der Freigabeabfragen überspringt, und eine Reihe von Befehlen, die in jeder Konfiguration blockiert sind [5].

Berichte aus dem Jahr 2026 hatten bereits gezeigt, dass Angreifer Hermes Agent in diesem unbeaufsichtigten Modus betreiben. Hunt.io beschrieb einen Fall vom Juli 2026, in dem ein Agent im YOLO-Modus, der Abfragen zur menschlichen Freigabe entfernt, Prüfungen zur Rechteausweitung gegen Hosts des thailändischen Finanzministeriums durchführte [4]. Unit 42 berichtete am 31. Juli 2026, ein chinesischsprachiger Angreifer habe Hermes im YOLO-Modus so konfiguriert, dass es Anweisungen aus einem Telegram-Kanal entgegennahm, während DeepSeek als Schlussfolgerungsmaschine diente [3].

Ergebnisse

Laut BleepingComputer nimmt Carbonato Docker-Hosts ins Visier, deren API ohne Authentifizierung auf Port 2375 erreichbar ist. Die Forscher fanden eine nicht authentifizierte Docker-Registry mit knapp 60 Repositories und 4,3 GB an Image-Daten, und laut dem Artikel durchsucht das Botnetz alle fünf Minuten die an einen infizierten Host angeschlossenen Netzwerke nach weiteren offenen Daemons [1].

The Hacker News berichtet, das Botnetz starte einen privilegierten Container, um Befehle auf dem darunterliegenden System auszuführen, installiere dann Hermes Agent und überschreibe die Standarddatei SOUL.md mit der Persona, sodass der Agent als „GH0ST“ auftritt, beschrieben als erfahrener Hacker, Pentester und Exploit-Entwickler. Die Persona nennt API-Schlüssel für KI-Dienste und andere Zugangsdaten als Priorität [2].

BleepingComputer zufolge deutet der Agent eine Aufgabe, schreibt Terminalbefehle, liest die Ausgabe und entscheidet über den nächsten Schritt; seinen Bericht schickt er dann in einen Telegram-Chat. Zu den Daten, die er sammeln soll, gehören API-Schlüssel für KI-Dienste, SSH-Zugangsdaten und Zugriffstokens [1]. Die Forscher konnten Carbonato keinem bekannten Bedrohungscluster zuordnen und nennen Costa Rica als möglichen Standort des Betreibers [1].

Folgen für Menschen, die Agenten lokal betreiben

Der Einstiegspunkt von Carbonato ist ein offener Docker-Daemon, keine Schwäche von Hermes Agent; gefährdet sind in diesem Bericht also Personen, die eine Docker-API ohne Authentifizierung veröffentlichen. Die abgerufenen Quellen sagen nicht, ob ein Opfer ein privater Mac war, und die berichteten Persistenzmethoden (Cron-Jobs und Watchdog-Skripte) sind Linux-Mechanismen [1] [2].

Die Berichte zeigen, was ein Agent mit Terminalzugriff tun kann, sobald jemand seine Anweisungen kontrolliert: Er sammelt Zugangsdaten und meldet sie über einen gewöhnlichen Messaging-Dienst zurück. Dieselbe Fähigkeit steht auch seinem rechtmäßigen Besitzer zur Verfügung; deshalb behandelt die Dokumentation des Frameworks Freigaben, Container-Isolation und Schlüsselablage als Konfigurationsentscheidungen, die der Betreiber treffen muss [5].

Empfehlungen

  1. Eine Docker-API niemals ohne Authentifizierung auf Port 2375 veröffentlichen. Die Forscher raten, die Authentifizierung des Docker-Daemons zu erzwingen, den Remote-API-Zugriff zu deaktivieren, wenn er nicht gebraucht wird, und Netzwerke zu segmentieren, um seitliche Bewegungen zu begrenzen [2].
  2. Die Freigaben von Hermes Agent eingeschaltet lassen. Die Dokumentation nennt smart als Standardmodus und manual als den Modus, der bei gefährlichen Befehlen stets nachfragt; off schaltet alle Freigabeprüfungen ab [5].
  3. Den Agenten in einem Container-Backend mit den dokumentierten Ressourcenlimits und als Nutzer ohne Root-Rechte betreiben [5].
  4. Für das Messaging-Gateway ausdrückliche Allowlists verwenden und die Einstellung „alle erlauben“ vermeiden [5].
  5. API-Schlüssel, wie in der Dokumentation empfohlen, in der .env-Datei des Agenten ablegen, mit auf den Besitzer beschränkten Rechten (chmod 600), und jeden Schlüssel erneuern, den ein Agenten-Host preisgegeben haben könnte [5].
  6. Hermes Agent aktuell halten und seine Logs im Verzeichnis ~/.hermes/logs prüfen [5].

Bezug zu FireAI

FireAI ist eine Firewall für einen einzelnen Mac. Es erkennt eine App an ihrer Codesignatur oder ihrem Pfad, zeigt die Verbindungen, die diese App öffnet, und wendet darauf Regeln pro App an. Ein Mac, auf dem Hermes Agent läuft, erscheint in FireAI als der Interpreter, der ihn startet, meist Python; eine Regel gilt also für alles, was dieser Interpreter ausführt. Eine Regel, die nur die Domain des Modellanbieters erlaubt und jedes andere Ziel blockiert, ist die Kontrolle, die begrenzt, wohin ein solcher Agent Daten senden darf; die Seite Aktivität zeigt die Ziele, die er kontaktiert hat.

FireAI schützt keine Server, sucht keine offenen Docker-Ports und schließt sie nicht, verwaltet weder Docker noch irgendeinen Container und prüft weder die Anweisungen an einen Agenten noch den Inhalt verschlüsselter Verbindungen. Es kann einen Agenten nicht daran hindern, lokale Dateien zu lesen oder zu löschen. Eine Telegram-Verbindung, die der Nutzer erlaubt hat, würde nicht hinterfragt.

Einschränkungen

Die Carbonato-Ergebnisse stammen von ThreatDown, wie sie BleepingComputer und The Hacker News weitergeben; keiner der beiden Artikel nennt in der abgerufenen Fassung, wie viele Hosts kompromittiert wurden. Die beiden Artikel setzen leicht unterschiedliche Schwerpunkte, und die Zeitangaben zur Offenlegung der Systeme wurden hier nicht abgeglichen. Die Fälle von Hunt.io und Unit 42 sind getrennte Operationen verschiedener Akteure und werden nur angeführt, um zu zeigen, dass die unbeaufsichtigte Nutzung von Hermes Agent durch Angreifer schon früher im Jahr 2026 berichtet wurde [3] [4].

Die Härtungsschritte stammen aus der Dokumentation von Hermes Agent selbst, nicht aus einem unabhängigen Audit, und dieser Beitrag prüft nicht, ob sie das in den Botnetz-Berichten beschriebene Verhalten verhindern. Die Dokumentation hält außerdem fest, dass die Freigabe gefährlicher Befehle in Sandbox-Backends übersprungen wird, weil die Container-Grenze die Isolation liefert [5].

FireAI von HisnLabs 17 Tage kostenlos testen.

Quellen

  1. BleepingComputer, 24 September 2026: New Carbonato malware uses AI agents to hijack exposed Docker hosts
  2. The Hacker News, September 2026: Carbonato botnet compromises Docker hosts to deploy Telegram-controlled Hermes AI agent
  3. BleepingComputer, 31 July 2026: Hacker uses DeepSeek AI to autonomously attack vulnerable servers
  4. Hunt.io, 23 July 2026: Thailand Ministry of Finance targeted with Hermes AI agent running unattended
  5. Hermes Agent documentation: Security