Ein wachsendes Praxisproblem in Unternehmen lautet nicht mehr nur, ob KI-Agenten brauchbare Antworten liefern. Entscheidend wird, welche Anweisungen sie mit welchen Rechten ausführen dürfen. Genau an dieser Stelle setzt eine Kampagne an, die Zscaler ThreatLabz am 5. Mai beschrieben hat und über die SecurityBrief am 7. Mai berichtete. Angreifer platzierten einen vermeintlichen OpenClaw-Skill namens „DeepSeek-Claw“. Er wirkte wie eine nützliche Erweiterung für agentische Workflows, enthielt aber Installationsanweisungen, die Remcos RAT und GhostLoader nachladen konnten.
Der Fall ist relevant, weil er einen blinden Fleck vieler Agentenprogramme offenlegt. Skills, Plugins und MCP-ähnliche Erweiterungen werden häufig wie Konfigurationsdateien behandelt. Tatsächlich gehören sie zur Software-Lieferkette. Wenn ein Agent eine README, ein SKILL.md oder eine Installationsroutine nicht nur liest, sondern daraus Shell-Befehle ableitet, wird Dokumentation zur Ausführungsfläche.
Technische Details: vom Skill zur Ausführung
OpenClaw ist laut Zscaler ein Open-Source-Framework für autonome KI-Agenten, früher auch unter Namen wie Clawdbot, Moltbot oder Molty bekannt. Solche Frameworks automatisieren lokale Aufgaben mit teils weitreichenden Rechten. Das ist für Entwickler und interne Automatisierung nützlich, erhöht aber die Wirkung manipulierter Erweiterungen.
Die Kampagne nutzte einen „DeepSeek-Claw“-Skill als Köder. Darin standen Anweisungen, die entweder ein Agent automatisch parsen oder ein Entwickler manuell übernehmen konnte. Unter Windows führte der Pfad über eine PowerShell-Zeile, die per msiexec ein entferntes MSI-Paket lud. Zscaler nennt als Infrastruktur unter anderem cloudcraftshub[.]com und dropras[.]xyz; solche Domains gehören in Unternehmensumgebungen als Indikatoren behandelt, nicht als anklickbare Links.
Das geladene MSI enthielt zwei zentrale Dateien: eine legitime, digital signierte GoToMeeting-Datei G2M.exe von LogMeIn und eine bösartige g2m.dll. Der Angriff nutzte DLL Search Order Hijacking. Startet die vertrauenswürdig wirkende Anwendung, lädt sie die im selben Verzeichnis platzierte DLL statt der erwarteten legitimen Bibliothek. Die DLL fungiert anschließend als In-Memory-Shellcode-Loader für Remcos RAT.
Zscaler beschreibt mehrere Evasion-Techniken. Der Loader löst APIs dynamisch auf, verschlüsselt Strings per XOR und nutzt den Tiny Encryption Algorithm im CBC-Modus, um den finalen Payload im Speicher zu entschlüsseln. Zusätzlich patcht er Windows-Sicherheitsfunktionen: EtwEventWrite wird verändert, um Telemetrie über Event Tracing for Windows zu unterdrücken; AmsiScanBuffer wird manipuliert, damit der Payload als sauber erscheint. Hinzu kommen Anti-Debugging- und Sandbox-Prüfungen, darunter Zeitmessungen rund um Sleep-Aufrufe und API-Calls.
Für macOS und Linux beschreibt Zscaler einen zweiten Pfad über ein stark obfuskiertes Node.js-Payload, das GhostLoader installiert. Der Fall lässt sich damit nicht auf klassische Windows-Endpoint-Sicherheit reduzieren. Entwicklerrechner, Build-Umgebungen und Automationshosts rücken gleichermaßen in den Fokus.
Faktenlage und Quellen
Primärquelle ist der ThreatLabz-Bericht „Malicious OpenClaw Skill Distributes Remcos RAT and GhostLoader“ von Zscaler vom 5. Mai 2026. Zscaler ordnet die Kampagne zeitlich in den März 2026 ein und beschreibt die Angriffskette inklusive Windows-MSI, GoToMeeting-Sideloading, Remcos RAT, GhostLoader, Indicators of Compromise und MITRE-ATT&CK-Techniken. SecurityBrief UK fasste den Fall am 7. Mai 2026 zusammen und bestätigte die Kernaussagen: manipulierte OpenClaw-Skill-Instruktionen, Verteilung von Remcos/GhostLoader sowie Entwickler- und Agenten-Workflows als Zielumgebung.
Wichtig ist die Einordnung. Der Vorfall belegt nicht, dass jedes Agentenframework grundsätzlich unsicher ist. Er zeigt aber, dass Erweiterungsökosysteme für Agenten denselben Supply-Chain-Risiken unterliegen wie npm-Pakete, VS-Code-Extensions oder CI/CD-Actions — mit einem zusätzlichen Faktor: Ein Agent kann eine schädliche Anweisung selbst interpretieren und ausführen.
Branchenkontext: Agenten verschieben die Vertrauensgrenze
Viele Unternehmen testen KI-Agenten derzeit für DevOps, Security Operations, Datenanalyse oder interne Automatisierung. Damit entsteht eine neue Vertrauensgrenze. Früher musste ein Angreifer häufig einen Menschen dazu bringen, einen Befehl auszuführen. In agentischen Workflows kann es reichen, eine plausibel formulierte Installationsanweisung dort zu platzieren, wo der Agent sie als Arbeitskontext akzeptiert.
Dadurch verschwimmt die Grenze zwischen Prompt Injection, Software Supply Chain und Endpoint-Angriff. Ein manipulierter Skill ist nicht nur „Text“. Er kann eine Policy-Umgehung sein, wenn der Agent Shell-Zugriff besitzt. Er kann zum Credential-Risiko werden, wenn im selben Kontext Cloud-Tokens, Git-Zugänge oder API-Schlüssel liegen. Und er kann Persistenz schaffen, wenn Build- oder Entwicklerrechner dauerhaft kompromittiert werden.
Konkrete Implikationen für Unternehmen
Erstens sollten Unternehmen Agenten-Skills und Plugins wie Code behandeln. Dazu gehören Review, Signierung, Herkunftsprüfung, Versionspinning und Freigabeprozesse. Ein GitHub-Link oder ein bekannter Name reichen nicht aus.
Zweitens brauchen Agenten eine restriktive Ausführungsumgebung. Shell-Zugriff sollte nicht der Standard sein. Wo Befehle nötig sind, gehören Allow-Lists, dry-run-Modi, Benutzerfreigaben für riskante Aktionen und getrennte Servicekonten dazu. Besonders kritisch sind Befehle, die Installer starten, Remote-Skripte laden, PowerShell nutzen oder in CI/CD-Kontexte eingreifen.
Drittens sollten Security-Teams ihre Telemetrie um agentenspezifische Muster erweitern. Dazu zählen unerwartete msiexec-Aufrufe aus Entwicklungsverzeichnissen, PowerShell-Prozesse aus Dokumentations- oder Skill-Parsing heraus, DLL-Sideloading neben legitimen Tools sowie neue Netzwerkverbindungen zu bislang unbekannten Download-Domains. Die von Zscaler genannten IOCs sollten in EDR, Proxy, DNS-Filter und SIEM geprüft werden.
Viertens bleibt Secret-Isolation zentral. Agenten, die Code auschecken, Tests starten oder Tickets bearbeiten, sollten nicht automatisch Zugriff auf Produktions-Credentials erhalten. Kurzlebige Tokens, scoped permissions und getrennte Workspaces begrenzen den Schaden, wenn ein Skill kompromittiert wird.
Risiken und Limitierungen
Die öffentliche Berichterstattung beschreibt eine konkrete Kampagne, keine flächendeckende Ausnutzung aller OpenClaw-Installationen. Auch ist nicht jede automatische Skill-Ausführung gleich gefährlich. Das Risiko hängt stark von Berechtigungen, Betriebssystem, Netzwerkzugriff und Agentenpolicy ab. Unternehmen sollten den Fall daher nicht als Argument für pauschale Agentenverbote verstehen, sondern als Designsignal: Agenten benötigen dieselbe Governance wie andere produktionsnahe Automatisierung.
Fazit
Die OpenClaw-Kampagne ist ein früher, aber konkreter Hinweis darauf, wie sich Angriffe auf agentische Systeme entwickeln. Der schädliche Teil liegt nicht im Modell, sondern in der Verbindung aus Text, Tool-Zugriff und Vertrauen in Drittanbieter-Skills. Wer KI-Agenten produktiv einsetzt, muss Skills als ausführbaren Bestandteil der Lieferkette behandeln. Ohne Review, Isolation und Monitoring kann aus einer harmlos wirkenden Installationsanweisung ein vollwertiger Endpoint- und Supply-Chain-Angriff werden.
Quellen: Zscaler ThreatLabz, „Malicious OpenClaw Skill Distributes Remcos RAT and GhostLoader“; SecurityBrief UK, „Malicious OpenClaw skill spreads Remcos RAT & GhostLoader“.
