Von Clawdbot zu OpenClaw: Wenn Automatisierung zur digitalen Hintertür wird

Nach der ersten Veröffentlichung dieses Artikels wurde das zuvor als Clawdbot und Moltbot bekannte Projekt erneut umbenannt und heißt nun OpenClaw. Die hier besprochenen grundlegenden agentenbasierten Architektur- und Sicherheitsaspekte behalten auch unter dem neuen Namen ihre Gültigkeit.

---

Clawdbot entwickelte sich Anfang 2026 zu einem der meistdiskutierten Open-Source-KI-Agenten , nicht weil es sich um einen weiteren Chatbot handelte, sondern weil es eine Grenze überschritt, die viele Tools nicht überschritten hatten. Es kombinierte große Sprachmodelle mit direktem, autonomem Zugriff auf Betriebssysteme, Dateien, Anmeldedaten und Messaging-Plattformen.

Was die Nutzer jedoch an Produktivität gewannen, gewannen die Angreifer als neue Angriffsfläche.

Als Clawdbot aufgrund von Markenrechtsproblemen in Moltbot umbenannt wurde, veränderte sich das Risikoprofil erneut. Nicht weil sich der zugrunde liegende Agent geändert hatte, sondern weil die rasante Popularität mit einer mangelnden operativen Vorbereitung kollidierte. In der Eile, Repositorys, Domains und Social-Media-Konten umzubenennen, entstanden Lücken in den Eigentumsverhältnissen. Angreifer handelten schneller als die Betreiber, kapern innerhalb von Sekunden aufgegebene Identitäten und nutzten das Vertrauen der Community aus.

Die Umstellung des Projekts auf OpenClaw ging einher mit einer erneuten Fokussierung auf ein sicherheitsorientiertes Design und klareren Warnungen vor den Risiken des autonomen Systemzugriffs. Dies signalisiert , dass die Entwickler nun die Sicherheitslücke erkennen, die durch die frühen Anwender aufgedeckt wurde.

Nun wirkt sich die explosionsartige Verbreitung des Tools zugunsten der Angreifer aus. Eine schnell wachsende Zahl von Nutzern ist begierig darauf, es auszuprobieren, zu klonen, zu integrieren und mit weitreichenden Berechtigungen zu betreiben, bevor die Sicherheitsfragen vollständig geklärt sind. Diese Kombination aus hohen Berechtigungen, viraler Verbreitung und vorübergehender Identitätsverwirrung macht ein ohnehin schon sensibles Automatisierungstool zu einem äußerst attraktiven Ziel.

Clawdbot ist standardmäßig nicht für die öffentliche Nutzung vorgesehen. Wenn Sie sich nicht mit der Absicherung eines Servers, dem Verständnis der Vertrauensgrenzen von Reverse-Proxys und der Ausführung von Diensten mit hohen Berechtigungen und geringsten Zugriffsrechten auskennen, sollten Sie dieses Programm nicht auf einem öffentlichen VPS einsetzen.

Das Projekt setzt ein Maß an operativer Reife voraus, das viele Nutzer unterschätzen, und die meisten der bisher beobachteten Ausfälle in der Praxis sind auf Konfigurationsfehler zurückzuführen, nicht auf Exploits.

Dies ist keine Geschichte über ein gescheitertes KI-Projekt. Es ist eine Geschichte darüber, wie moderne Angriffe entstehen , wenn Vertrauen, Automatisierung und Identität schneller voranschreiten als Sicherheitskontrollen.

Um zu verstehen, warum Clawdbot so schnell Angreifer anzieht, ist es hilfreich, sich anzusehen, wie der Agent nach seiner Bereitstellung tatsächlich funktioniert.

TL;DR

• Moltbot verwandelt Automatisierung in eine Angriffsfläche mit hohen Privilegien, wenn es offengelegt oder falsch konfiguriert ist.
• Die meisten Kompromittierungen in der Praxis sind auf Konfigurationsfehler und Vertrauensmissbrauch zurückzuführen, nicht auf Zero-Day-Exploits.
• Sobald die Sicherheit kompromittiert ist, ermöglicht der Agent den Diebstahl von Anmeldedaten, laterale Bewegungen und ransomware.
• Autonome KI-Agenten müssen als privilegierte Infrastruktur behandelt werden, nicht als Produktivitätswerkzeuge.
• Wenn Sie es nicht absichern und überwachen können , setzen Sie es nicht der Gefahr aus.

Der Rest dieses Artikels erklärt, wie Moltbot so schnell zu einem attraktiven Ziel wurde, wie Angreifer es in der Praxis missbrauchen und was dies für die Zukunft der agentenbasierten KI-Sicherheit bedeutet. Leser, die nach praktischen Anleitungen suchen, können zum Abschnitt „Hardening“ am Ende des Artikels springen.

Der KI-Agent als ständiger Schatten-Superuser

Clawdbot wurde für den Betrieb auf benutzergesteuerten Infrastrukturen, Laptops, Heimservern, cloud und sogar Einplatinencomputern entwickelt. Es kann Shell-Befehle ausführen, Dateien lesen und schreiben, im Internet surfen, E-Mails oder Chat-Nachrichten versenden und den persistenten Speicher über mehrere Sitzungen hinweg aufrechterhalten. In der Praxis fungiert er als Automatisierungsschicht mit hohen Privilegien, die oft API-Schlüssel, OAuth-Token, Chat-Anmeldedaten und manchmal auch Root-Zugriff enthält. Dieses Design vereint mehrere Vertrauensgrenzen in einem einzigen System. Messaging-Plattformen, lokale Betriebssysteme, cloud und Tools von Drittanbietern laufen alle über einen einzigen autonomen Agenten zusammen. Nach der Bereitstellung ist Clawdbot nicht mehr nur eine Anwendung, sondern wird Teil der Sicherheitsstruktur der Umgebung.

Aus Sicht eines Angreifers ist dies ideal. Kompromittieren Sie den Agenten einmal und übernehmen Sie alles, worauf er Zugriff hat, über alle Umgebungen hinweg.

Sobald dieser Zugriff besteht, benötigen Angreifer keine neuen Techniken mehr, sondern verwenden einfach bekannte Techniken über einen weitaus leistungsfähigeren Vermittler.

Wie Angreifer Clawdbot in der Praxis missbrauchen

Sobald Clawdbot – jetzt Moltbot – eingesetzt wird, stellt sich nicht mehr die Frage, ob es missbraucht werden kann, sondern wie. Einige Techniken sind bereits bekannt (Fehlkonfigurationen und Tricks in der Lieferkette), während andere – wie die Prompt-Injektion– in der Forschung gut dokumentiert sind und realistisch werden, wenn Agenten nicht vertrauenswürdige Inhalte lesen und Tools ausführen können.

Erster Zugriff: Wo der Agent zum Einstiegspunkt wird

Die häufigste Art, wie Clawdbot kompromittiert wird, ist nicht durch einen cleveren Exploit, sondern durch einfache Offenlegung. Die Control UI ist eine Verwaltungsschnittstelle, auf die lokal zugegriffen werden soll. In der Praxis machen einige Benutzer sie jedoch versehentlich durch Fehlkonfigurationen, offene Ports oder unsichere Proxy-Einstellungen über das öffentliche Internet erreichbar.

In diesem Fall kann sich ein lokales Admin-Dashboard wie ein Fernbedienungsfeld verhalten.

Ein Teil der Verwirrung rührt daher, wie das Wort exposed verwendet wird. In der Praxis gibt es jedoch bedeutende Unterschiede:

• Internet-zugänglich: über eine öffentliche IP-Adresse und einen öffentlichen Port erreichbar.
• Fingerabdruck: Durch Shodan oder Censys erkennbar, da die HTTP-Antwort mit den Signaturen von Moltbot oder Clawdbot übereinstimmt, selbst wenn die Authentifizierung aktiviert ist.
• Nicht authentifiziert oder umgangen: Auf die Steuerungs-Benutzeroberfläche kann ohne gültige Kopplung oder Anmeldedaten zugegriffen werden, häufig aufgrund einer Fehlkonfiguration. Dies ist ein gefährlicher Fall.

Dieser Unterschied ist wichtig. Sobald eine Verwaltungsschnittstelle über das öffentliche Internet erreichbar ist, wird sie leicht auffindbar. Suchmaschinen wie Shodan können diese Systeme schnell aufspüren, wodurch ein einziger Konfigurationsfehler zu einem weitreichenden Problem werden kann.

‍

Öffentliche Screenshots, die eine große Anzahl von Clawdbot-Ergebnissen zeigen, können irreführend sein. Viele davon beziehen sich auf Systeme, die zwar sichtbar, aber dennoch geschützt sind. Das tatsächliche Risiko liegt in der geringeren Anzahl von Fällen, in denen die Authentifizierung fehlt oder unwirksam ist.

In solchen Situationen ist die Benutzeroberfläche der Steuerung über das öffentliche Internet erreichbar, und Angreifer können möglicherweise Konfigurationsdaten einsehen, auf den Gesprächsverlauf zugreifen oder Befehle ausführen, je nachdem, wie der Agent konfiguriert wurde.

‍

‍

Selbst wenn Benutzer glauben, dass die Authentifizierung aktiviert ist, können Angreifer diese durch unsichere Standardeinstellungen und Fehlkonfigurationen des Proxys vollständig umgehen. zero-day kein zero-day erforderlich. Eine einzige Header-Neuschreibung oder Weiterleitungsregel kann die Grenze zwischen vertrauenswürdigem und nicht vertrauenswürdigem Zugriff aufheben. Sobald sie sich im System befinden, können Angreifer alle Funktionen des Agenten nutzen.

Nicht jeder erste Zugriff erfordert eine Netzwerk-Exposition oder Fehlkonfiguration.

Social Engineering und Prompt-Injection

Die Fähigkeit von Clawdbot, E-Mails, Chat-Nachrichten und Dokumente zu lesen, schafft eine neue Angriffsfläche, bei der die Nutzlast Sprache und nicht malware ist.

Die Prompt-Injektion wurde in der Forschung und in praktischen Agentenkonfigurationen nachgewiesen: Eine manipulierte Nachricht kann einen Agenten manchmal dazu veranlassen, sensible Daten preiszugeben oder unbeabsichtigte Aktionen auszuführen, selbst wenn der Angreifer den Host nie direkt berührt.

‍

Bei der Verteidigung geht es weniger darum, „einen Fehler zu beheben“, sondern vielmehr darum, die Möglichkeiten des Agenten einzuschränken, zu bestimmen, wer mit ihm kommunizieren darf, und festzulegen, wie er mit nicht vertrauenswürdigen Inhalten umgeht.

Wenn Angreifer tatsächlich auf dem Host Fuß fassen, schafft das lokale Design von Clawdbot einen zweiten, unauffälligeren Weg zur Übernahme.

Malware Clawdbot-Daten Malware

malware Infostealer benötigen keinen Clawdbot-spezifischen Exploit, um von Agent-Bereitstellungen zu profitieren. Wenn Tokens, OAuth-Artefakte oder der Agent-Status lokal gespeichert sind – insbesondere wenn sie im Klartextgespeichert sind –, kann eine routinemäßige endpoint zu einer Übernahme des Agenten und aller verbundenen Dienste, auf die er zugreifen kann, eskalieren.

‍

In anderen Fällen greifen Angreifer den Host nie direkt an, sondern gelangen über vertrauenswürdige Erweiterungen und Integrationen dorthin.

Missbrauch der Lieferkette, Plugins und bösartige Erweiterungen

Das Plugin-Modell von Clawdbot führt einen weiteren initialen Zugriffsvektor ein. Erweiterungen werden als Code auf demselben Rechner wie der Agent ausgeführt und übernehmen dessen Berechtigungen. Ein bösartiges Plugin oder ein kompromittiertes legitimes Plugin fungiert als sofortige Remote-Codeausführung. Der Agent wird zum Übertragungsmechanismus.

Über die Kernsoftware hinaus haben Angreifer auch das umgebende Ökosystem missbraucht. Kürzlich wurde eine gefälschte Clawdbot VS Code-Erweiterung verwendet, um den Fernzugriffstrojaner ScreenConnect zu installieren, wobei das Vertrauen der Entwickler in den Projektnamen ausgenutzt wurde, um vollständige Fernsteuerung zu ermöglichen. Die Erweiterung sah legitim aus, trug das richtige Branding und stützte sich eher auf das richtige Timing und den Bekanntheitsgrad als auf eine Software-Sicherheitslücke.

‍

Diese Art von Angriffen wird bei Rebrandings noch effektiver. Wenn sich Projektnamen, Repositorys und Domains schnell ändern, nutzen Angreifer die Verwirrung aus, indem sie ähnliche Repositorys oder Erweiterungen veröffentlichen, die legitim erscheinen. Die Kompromittierung erfolgt oft, bevor der Code überprüft wird, da aufgrund des Namens und des Zeitpunkts Vertrauen vorausgesetzt wird.

Bei der Verteidigung geht es hier weniger um das Patchen als vielmehr um die Identitätsprüfung. Nach einem Rebranding sollten Installationen auf die offizielle GitHub-Organisation und Projektdomain beschränkt sein . Neu erstellte oder gesponserte Repositorys verdienen eine besonders genaue Prüfung, und Plugins oder Skills sollten auf kuratierte Zulassungslisten beschränkt werden.

Das Gleiche gilt für Entwicklertools. Bei Editor-Erweiterungen sollten Sie den Herausgeber überprüfen, den Verlauf und die Aktualisierungshäufigkeit überprüfen und, sofern verfügbar, Hashes oder Signaturen kontrollieren. In diesem Ökosystem ist das Vertrauen in die Lieferkette Teil der Sicherheitsgrenze.

Sobald eine bösartige Erweiterung installiert ist, ist kein weiterer Exploit erforderlich und die Kontrolle erfolgt sofort.

Befehl und Kontrolle: Den Agenten zum C2-Kanal machen

Wenn ein Angreifer Zugriff auf die Control-Benutzeroberfläche oder einen Kanal erhält, über den Tools ausgeführt werden können, wird Clawdbot selbst zum Command-and-Control-Framework. Über die Control-Schnittstelle oder API können sie Shell-Befehle ausgeben, Ausgaben sammeln und interaktiv arbeiten. Das Risiko besteht nicht darin, dass Moltbot auf magische Weise die Sicherheit selbst unterbricht, sondern darin, dass ein kompromittierter Agent bereits über integrierte Ausführungs-, Persistenz- und Kommunikationspfade verfügt.

‍

‍

Missbrauch legitimer Integrationen

Clawdbot kann mithilfe legitimer Anmeldedaten Nachrichten über Slack, Telegram, E-Mail und andere Plattformen versenden. Angreifer können diese Integrationen missbrauchen, um Daten zu exfiltrieren oder Anweisungen zu empfangen, wobei sie sich nahtlos in den normalen Datenverkehr einfügen. Aus Sicht der Erkennung sieht dies wie erwartetes Automatisierungsverhalten aus, nicht wie C2-Datenverkehr.

Man-in-the-Middle auf der kognitiven Ebene

Wenn ein Angreifer die Konfiguration, Eingabeaufforderungen oder den gespeicherten Speicher des Agenten ändern kann (z. B. nachdem er Zugriff auf das Dateisystem erhalten hat), kann er versuchen, das zu beeinflussen, was der Benutzer sieht und was der Agent tut.

In der Praxis könnte dies bedeuten, dass Zusammenfassungen verschoben, Warnmeldungen unterdrückt oder versteckte Anweisungen eingefügt werden, die später ausgelöst werden. Dies sollte am besten als potenzielles Ergebnis eines Kompromisses betrachtet werden und nicht als garantierte Funktion in einer ordnungsgemäß isolierten Umgebung.

Die Kontrolle über den Agenten hebt auch traditionelle Privilegiengrenzen auf.

Privilegienerweiterung und Missbrauch von Anmeldedaten

Wenn Clawdbot als Standardbenutzer ausgeführt wird, können Angreifer es nutzen, um herkömmliche Techniken zur Rechteausweitung durchzuführen. In vielen Bereitstellungen ist eine Rechteausweitung nicht erforderlich, da der Agent bereits mit erhöhten Berechtigungen ausgeführt wird, insbesondere in containerisierten oder Einzelbenutzer-Setups.

‍

Clawdbot zentralisiert Anmeldedaten von Grund auf. API-Schlüssel, OAuth-Token, Chat-Anmeldedaten, cloud und manchmal auch VPN-Zugänge befinden sich alle an einem Ort. Sobald diese Anmeldedaten gesammelt sind, können Angreifer sich als Benutzer ausgeben, auf cloud zugreifen und sich lateral bewegen, ohne das ursprüngliche System erneut zu berühren.

In hybriden Umgebungen vervielfacht sich diese Auswirkung. Ein kompromittierter Agent, der auf einem Laptop ausgeführt wird, kann den SaaS-Zugriff des Unternehmens gefährden. Ein Agent, der in der cloud ausgeführt wird, verfügt cloud über IAM-Berechtigungen, mit denen Angreifer Infrastrukturen erstellen, auf Datenspeicher zugreifen oder CI/CD-Pipelines manipulieren können. Der Agent wird zu einer Brücke zwischen Umgebungen, die niemals direkt miteinander verbunden werden sollten.

Nachdem sie sich Zugang verschafft haben, konzentrieren sich Angreifer darauf, unbemerkt zu bleiben.

Beharrlichkeit: Wenn sich der Agent an den Angreifer erinnert

Da Agenten häufig langfristige Zustände auf der Festplatte speichern, kann ein kompromittierter Host diesen Zustand in Persistenz umwandeln. Wenn ein Angreifer in den Speicher oder die Konfiguration des Agenten schreiben kann, kann er Anweisungen oder Artefakte hinterlassen, die einen Neustart überstehen und weiterhin schädliche Aktionen ausführen, bis das System neu aufgebaut und die Geheimnisse rotiert werden.

Da Clawdbot für den kontinuierlichen Betrieb und die Ausführung von Aufgaben nach einem Zeitplan ausgelegt ist, können Angreifer wiederkehrende Aktionen einbetten. Datenexfiltration, Systemaufzählung oder ausgehende Kommunikation können automatisch und ohne weitere Interaktion ausgelöst werden.

Mit Shell-Zugriff können Angreifer auch auf klassische Persistenzmethoden, geplante Aufgaben, Startskripte oder zusätzliche Hintertüren zurückgreifen. Der Unterschied besteht darin, dass Clawdbot diese Aktionen oft hinter legitimer Automatisierung versteckt, was die forensische Analyse erschwert.

Der eigentliche Schaden entsteht, wenn der kompromittierte Agent als Brücke zu allem anderen genutzt wird.

Seitliche Bewegung und breitere Wirkung

Von einem einzigen kompromittierten Agenten aus können Angreifer interne Netzwerke scannen, Anmeldedaten wiederverwenden und sich lateral bewegen. Und da Clawdbot häufig persönliche, Unternehmens- und cloud umfasst, führt eine Kompromittierung in einem Bereich oft zu einer Kompromittierung in allen drei Bereichen.

Gestohlene Tokens ermöglichen es Angreifern, sich Zugang zu SaaS-Plattformen , internen Collaboration-Tools und cloud zu verschaffen. Sie können sich als Benutzer ausgeben, vertrauenswürdige Nachrichten versenden und über soziale Kanäle, die von Verteidigern selten als Angriffspfade überwacht werden, weiteren Zugriff verbreiten.

Im Extremfall können Angreifer Clawdbot nutzen, um ransomware einzusetzen, Daten zu vernichten oder Vorgänge zu sabotieren. Der Agent verfügt bereits über Dateizugriff, Ausführungsrechte und Kommunikationskanäle. Jede zerstörerische Aktion ist für den Assistenten lediglich eine weitere „Aufgabe“, die es zu erledigen gilt.

Zusammengenommen zeigen diese Verhaltensweisen eine umfassendere Veränderung in der Art und Weise, wie moderne Angriffe ablaufen.

Wenn Automatisierung zur Angriffsfläche wird

Clawdbot verkörpert sowohl das Versprechen als auch das Risiko autonomer KI. Es bietet leistungsstarke Automatisierung, aber genau diese Autonomie schafft eine hochwertige Angriffsfläche. Offene Schnittstellen, böswillige Eingaben und angepasste malware Angreifern, den Agenten für Befehls- und Kontrollzwecke, den Missbrauch von Berechtigungen, Persistenz und laterale Bewegungen zu missbrauchen. Diese Techniken verwischen die Grenze zwischen traditionellen Eindringungswegen und KI-gesteuertem Missbrauch, wobei die Auswirkungen persönliche Systeme, cloud und Unternehmensnetzwerke umfassen. Ein kompromittierter Agent kann je nach seiner Verbindung alles ermöglichen, von gezielten Datendiebstählen bis hin zu groß angelegten ransomware.

Clawdbot/Moltbot sollte wie eine Infrastruktur mit hohen Privilegien behandelt werden – und nicht wie ein gelegentliches Wochenend-Experiment –, da es Anmeldedaten zentralisiert und Aktionen über Konten und Geräte hinweg ausführen kann. Starke Authentifizierung, eingeschränkte Netzwerkexposition und sorgfältiger Umgang mit Geheimnissen sind unverzichtbar. Unternehmen müssen Einblick darin haben, wo diese Agenten ausgeführt werden, Segmentierungen vornehmen und auf anomales Verhalten wie unerwünschte Aktionen oder unerwartete Kommunikationen achten. Prompt-Injection fügt eine weitere Risikoschicht hinzu, bei der Missbrauch unsichtbar bleiben kann, wenn das Verhalten des Agenten selbst nicht überwacht wird.

Clawdbot verhält sich wie ein Schatten-Superuser innerhalb der Umgebung. Da autonome Agenten immer häufiger zum Einsatz kommen, ist die Lehre daraus klar: Fähigkeiten ohne Kontrolle bedeuten Gefährdung. Es liegt nun in der Verantwortung der Benutzer und Sicherheitsteams, diese Agenten zu schützen, bevor Angreifer dies für sie tun.

Dieses Umdenken zu verstehen, ist nur der erste Schritt. Um Risiken zu reduzieren, muss Moltbot wie jedes andere privilegierte System behandelt werden, und es müssen gezielte Kontrollen in Bezug auf Exposition, Identität, Ausführung und Überwachung angewendet werden .

So reduzieren Sie Risiken beim Ausführen von Moltbot

Autonome Agenten versagen nicht auf elegante Weise. Sobald sie mit umfassendem Zugriff eingesetzt werden, können kleine Konfigurationsfehler überproportionale Auswirkungen haben. Das Ziel der Absicherung besteht nicht darin, Moltbot „sicher” zu machen, sondern den Explosionsradius zu begrenzen, die Gefährdung zu verringern und Missbrauch erkennbar zu machen.

1. Checkliste zur Baseline-Härtung

2. Isolierung von Host und Infrastruktur

• Setzen Sie die Benutzeroberfläche der Steuerung nicht dem öffentlichen Internet aus. Verwenden Sie vorzugsweise ein VPN wie Tailscale oder WireGuard oder SSH-Tunneling zum lokalen Host. Isolieren Sie den Agenten von Produktions-Workloads.
• Führen Sie Moltbot nicht auf demselben VPS aus, auf dem Backend-Dienste, Datenbanken oder persönliche Dateien gehostet werden.
• Härten Sie SSH auf jedem VPS. Deaktivieren Sie die Passwortauthentifizierung und die Root-Anmeldung, verwenden Sie nur Schlüssel und aktivieren Sie Firewall-Regeln sowie Ratenbegrenzung oder fail2ban.
• Führen Sie den Agenten als Nicht-Root-Benutzer aus. Vermeiden Sie privilegierte Container und mounten Sie niemals das Host-Dateisystem oder den Docker-Socket.
• Führen Sie regelmäßig Patches durch. Installieren Sie Betriebssystem-Updates, aktualisieren Sie Container-Images und rotieren Sie langlebige Schlüssel.

3. Steuerung der Benutzeroberfläche und Gateway-Konfiguration

• Binden Sie das Gateway und die Steuerungs-Benutzeroberfläche an 127.0.0.1, es sei denn, ein Fernzugriff ist unbedingt erforderlich.
• Aktivieren Sie die Control-UI-Authentifizierung und überprüfen Sie die Reverse-Proxy-Einstellungen, damit Remote-Clients nicht als Localhost behandelt werden.
• Protokollieren und benachrichtigen Sie über neue Gerätepaarungen, Konfigurationsänderungen und Tool-Ausführungsereignisse.

4. Kanäle und Integrationen

• Verwenden Sie strenge Zulassungslisten für diejenigen, die dem Bot Nachrichten senden dürfen. Die Standardeinstellung sollte „standardmäßig ablehnen” sein.
• Deaktivieren oder beschränken Sie risikoreiche Tools wie Shell-Zugriff, Dateischreiben und Browser-Automatisierung, sofern dies nicht unbedingt erforderlich ist.
• Verwenden Sie separate Konten mit minimalen Berechtigungen für Integrationen, wie z. B. dedizierte Gmail-Konten, eingeschränkte Slack-Bot-Berechtigungen und begrenzte GitHub-Token.
• Behandeln Sie QR-Codes und URIs, die Geräte verbinden, wie Passwörter. Lassen Sie keine Pairing-Artefakte an öffentlich zugänglichen Orten liegen und wechseln Sie sie aus oder verbinden Sie sie neu, wenn sie offengelegt wurden.
• Bevorzugen Sie Bot-Konten pro Dienst und beschränken Sie die Sichtbarkeit. Vermeiden Sie öffentliche Discord-Server und sperren Sie Direktnachrichten für alle außer einer Whitelist.

5. Geheimnisse und Umgang mit Daten

Dies sind gängige Standardorte, die auf Ihrem Host überprüft werden sollten. Behandeln Sie sie als sensibel und sperren Sie die Zugriffsrechte:

Zusätzliche Kontrollen:

• Behandeln Sie den Agenten wie einen Geheimnisverwalter. Sperren Sie Dateiberechtigungen und verschlüsseln Sie Speicher, wo immer dies möglich ist.
• Drehen und widerrufen Sie Tokens nach jedem Verdacht auf eine Gefährdung aggressiv. Bevorzugen Sie kurzlebige OAuth-Tokens gegenüber langlebigen API-Schlüsseln.
• Begrenzen Sie die Aufbewahrung von Konversationsverläufen und Anhängen. Eine einfache Standardeinstellung ist 7 bis 14 Tage für Sitzungsprotokolle, die wöchentlich rotiert oder gelöscht werden, mit Verschlüsselung im Ruhezustand, wenn eine längere Aufbewahrung erforderlich ist.

6. Prompte Injektion und nicht vertrauenswürdige Inhalte

• Gehen Sie davon aus, dass jede E-Mail, jedes Dokument, jede Webseite oder jede Chat-Nachricht feindliche Anweisungen enthalten kann.
• Verhindern Sie, dass nicht vertrauenswürdiger Text direkt Shell-Befehle oder den Export von Anmeldedaten auslöst.
• Verwenden Sie kanalbezogene Tool-Richtlinien. Erlauben Sie beispielsweise Zusammenfassungen in E-Mails oder Slack, aber verweigern Sie Shell- oder Dateischreibaktionen von Telegram oder Discord.
• Erfordern Sie eine menschliche Bestätigung für risikoreiche Aktionen wie das Ausführen von Befehlen, das Exportieren von Dateien, das Ändern von Einstellungen oder das Initiieren von Anmeldungen.
• Behandeln Sie die Browser-Automatisierung als hohes Risiko. Verwenden Sie für den Agenten ein separates, abgemeldetes Browserprofil und verwenden Sie niemals eine persönliche Sitzung wieder.
• Ein nützliches Muster ist die Kennzeichnung der Herkunft von Inhalten in Kombination mit einer Richtlinie für Tools pro Herkunft und einer obligatorischen Bestätigung für risikoreiche Tools.

7. Überwachung und Erkennung, minimal erforderliche Abdeckung

ATT&CK-Kurzform für Verteidiger

• Erster Zugriff: exponierte Steuerungs-Benutzeroberfläche oder Missbrauch der Lieferkette
• Ausführung: Shell- und Tool-Aufrufe
• Zugriff auf Anmeldedaten: lokale Tokens und Konfigurationsdateien
• Persistenz: geänderte Konfigurationen, Speicher oder Plugins
• Befehl und Kontrolle: Chat-Kanäle
• Exfiltration: Uploads und Webhooks

Mindestanforderungen, die zu beachten sind

• Kontrolle von Authentifizierungsfehlern in der Benutzeroberfläche, neuen Gerätepaarungen und Konfigurationsänderungen
• Toolaufrufe wie Shell-Ausführungen, Datei-Lese- und Schreibvorgänge, Browser-Automatisierung und ausgehende Uploads
• Unerwartete Änderungen am Dateisystem unter ~/.clawdbot/* und im Arbeitsbereich des Agenten
• Netzwerkaktivitäten wie neue ausgehende Domänen, Spitzen im Nachrichtenverkehr oder ungewöhnlicher Webhook-Verkehr
• Host-Signale wie Firewall-Protokolle auf Moltbot-Ports, SSH-Anmeldeereignisse und ungewöhnliche untergeordnete Prozesse

8. Bei Verdacht auf Exposition: schnelle Reaktion

• Beenden Sie den Dienst und sichern Sie die Beweise. Erstellen Sie einen Snapshot der VM oder des Containers und sammeln Sie die Systemprotokolle sowie ~/.clawdbot/*.
• Rotieren und widerrufen Sie Anmeldedaten. Ersetzen Sie Tokens, widerrufen Sie OAuth-Sitzungen, rotieren Sie SSH-Schlüssel und stellen Sie langlebige API-Schlüssel neu aus.
• Zugriffspfade ungültig machen. Offene Kanäle deaktivieren, Zulassungslisten zurücksetzen und die Kopplung oder Passwörter der Steuerungs-Benutzeroberfläche rotieren.
• Löschen Sie sensible Verlaufsdaten, wo dies angemessen ist. Löschen Sie Sitzungsprotokolle, wenn sie vertrauliche Informationen enthalten, und setzen Sie dann eine kurze Aufbewahrungsfrist durch.
• Im Zweifelsfall neu aufbauen. Wenn der Host ohne starke Authentifizierung erreichbar war oder der Verdacht auf Befehlsausführung besteht, bauen Sie ihn aus einem sauberen Image neu auf und verknüpfen Sie die Kanäle sorgfältig neu.
• Überprüfen Sie nach der Überprüfung die Persistenzpunkte wie systemd-Dienste, crontab, autorisierte SSH-Schlüssel und installierte Plugins oder Erweiterungen.

Was man mitnehmen sollte

1. Behandeln Sie Moltbot wie eine privilegierte Infrastruktur. Es verwahrt Geheimnisse, führt Befehle aus und kommuniziert über vertrauenswürdige Kanäle.
2. Die meisten Fehler sind Konfigurationsprobleme, keine Exploits. Öffentliche Steuerungs-Benutzeroberflächen, schwache Proxy-Einstellungen, offene Kanäle und übermächtige Tools sind für die meisten Vorfälle verantwortlich.
3. Identität ist Teil der Angriffsfläche. Vertrauen Sie nur offiziellen Organisationen, Domänen und Erweiterungen, insbesondere bei Rebrandings.
4. Wenn Sie es nicht absichern können, setzen Sie es keiner Gefahr aus. Behalten Sie die Benutzeroberfläche auf localhost oder VPN, beschränken Sie die Kanäle und verlangen Sie eine Bestätigung für riskante Aktionen.

Um sich gegen dieses Modell zu verteidigen, muss man nicht nur die Vermögenswerte, sondern auch das Verhalten im Blick haben. Hier kommt die Vectra AI entscheidend, da sie Sicherheitsteams die Möglichkeit gibt, Angreifer-Verhaltensweisen zu erkennen, die auftreten, wenn vertrauenswürdige Automatisierung in Identitäts-, Netzwerk-, cloud und Hybridumgebungen missbraucht wird, bevor diese Verhaltensweisen zu einer vollständigen Kompromittierung eskalieren.

‍

---

Quellen:

• Offizielle Sicherheitsrichtlinien für Moltbot/Clawdbot (Hardening, Reverse Proxy, Authentifizierung): https://docs.clawd.bot/gateway/security
• Offizielle Projektseite: https://molt.bot (auch https://clawd.bot)
• Offizielles GitHub-Repository/Organisation: https://github.com/moltbot/clawdbot (Organisationsseite: https://github.com/clawdbot/)
• Chirag (@mrnacknack) hat einen informativen Artikel über häufige Fehlkonfigurationen und Prompt-Injection-Pfade geschrieben (als sekundärer Kontext verwenden): https://x.com/mrnacknack/article/2016134416897360212 (siehe auch die Threads von @theonejvo).
• Berichterstattung von Cointelegraph über aufgedeckte Fälle und das Risiko von Datenlecks (über TradingView Mirror): https://www.tradingview.com/news/cointelegraph:99cbc6b7d094b:0-viral-ai-assistant-clawdbot-risks-leaking-private-messages-credentials/
• Zusammenfassung der Binance-Nachrichten zum GitHub/X-Hijack + Verwirrung um Token-Betrug: https://www.binance.com/en/square/post/01-27-2026-clawdbot-founder-faces-github-account-hijack-by-crypto-scammers-35643613762385
• DEV Community-Zeitleiste zur Umbenennung und zur Welle von Betrugsversuchen durch Identitätsdiebstahl: https://dev.to/sivarampg/from-clawdbot-to-moltbot-how-a-cd-crypto-scammers-and-10-seconds-of-chaos-took-down-the-internets-hottest-ai-project-4eck
• Aikido-Sicherheitsanalyse einer gefälschten Clawdbot VS Code-Erweiterung:malware
• Projekt-Änderungsprotokoll (zur Verfolgung sicherheitsrelevanter Änderungen): https://github.com/clawdbot/clawdbot/blob/main/CHANGELOG.md
• Sekundäre Berichterstattung über das Interesse von Infostealern an Clawdbot/Moltbot-Ökosystemen (indikativ, nicht endgültig): https://www.infostealers.com/article/clawdbot-the-new-primary-target-for-infostealers-in-the-ai-era/