JADEPUFFER: Der erste autonome KI-Ransomware-Angriff ist da

Jeder Plattformverantwortliche, der schon einmal um 3 Uhr nachts einen Incident-Bridge-Call geleitet hat, kennt das Muster: Der Angreifer stolpert, Alarme schlagen an, Verteidiger bekommen ein Zeitfenster. Dieses Zeitfenster ist gerade auf 31 Sekunden geschrumpft. Das Threat Research Team von Sysdig veröffentlichte am 6. Juli 2026 Erkenntnisse über das, was sie als die erste End-to-End-Ransomware-Kampagne bezeichnen, die von einem KI-Agenten – und nicht von einem Menschen an einer Tastatur – gesteuert wird.

Was geschah

Der Bedrohungsakteur, von Sysdig's TRT als JADEPUFFER bezeichnet, führte eine vollständige Ransomware-Kill-Chain ohne Hinweise auf direkte menschliche Eingriffe durch. Wie CX Today berichtete, nutzte die Kampagne ein Large Language Model, um Aufklärung, Credential-Diebstahl, Lateral Movement, Persistenz, Privilege Escalation und den abschließenden Ransomware-Einsatz zu koordinieren.

Der initiale Zugriff erfolgte über CVE-2025-3248, eine Remote-Code-Execution-Schwachstelle in Langflow, dem Open-Source-Framework, das Teams verwenden, um LLM-Anwendungen und KI-Workflows zu verbinden. Von dieser exponierten Langflow-Instanz aus schwenkte der Agent auf einen produktiven Datenbankserver um. Zwei Ziele, ein autonomer Operator.

Michael Clark, Director of Threat Research bei Sysdig, brachte es im Bericht auf den Punkt: „JADEPUFFER gilt als agentic threat actor (ATA), also als Operator, dessen Angriffsfähigkeit durch einen KI-Agenten und nicht durch ein menschlich gesteuertes Toolkit bereitgestellt wird." Was die Forscher aufmerksam machte, war, dass die Payloads mit sich selbst sprachen. Clark stellte fest, sie „enthielten natürlichsprachige Überlegungen, Zielprioritäten und detaillierte Anmerkungen, die menschliche Operatoren selten schreiben, die aber LLM-generierter Code reflexartig produziert."

Das Endergebnis war verheerend. JADEPUFFER verschlüsselte mehr als 1.300 Nacos-Konfigurationsdatensätze mithilfe der MySQL-eigenen Funktion AES_ENCRYPT(), löschte die Originale und hinterließ eine Bitcoin-Erpressungsnachricht. Der Verschlüsselungsschlüssel wurde zufällig generiert und weder gespeichert noch übertragen. Selbst die Zahlung des Lösegelds bringt die Daten nicht zurück. Dieses letzte Detail ist es, das CISOs schlaflose Nächte bereiten sollte.

Technische Anatomie

Die Angriffskette liest sich wie ein ATT&CK-Diagramm, verfasst von einem Bot, der jedes ATT&CK-Diagramm gelesen hat. Initialer Zugriff über den Langflow-RCE. Dann eine systematische Durchsuchung des kompromittierten Servers nach LLM-Provider-API-Keys, Cloud-Credentials für AWS, Azure, Google Cloud und große chinesische Cloud-Anbieter, Datenbank-Credentials, Kryptowährungs-Wallets sowie Konfigurationsdateien und Umgebungsvariablen. Alles, was monetarisierbar oder wiederverwendbar war, wurde mitgenommen.

Anschließend enumerierte der Agent interne Dienste, sammelte Credentials aus einem MinIO-Object-Storage-Deployment, etablierte Persistenz über einen geplanten Beacon und schwenkte auf das eigentliche Produktionsziel um: einen MySQL-Server und eine Nacos-Konfigurationsplattform. Auf dem Weg dorthin fälschte er JWT-Tokens, versuchte parallel mehrere Authentifizierungsumgehungen, erstellte Administrator-Konten direkt in der Datenbank und führte Privilege-Escalation-Prüfungen durch, bevor er den Auslöser betätigte.

Die Verhaltenssignatur ist der Punkt, an dem dies aufhört, wie ein Script-Kit auszusehen. Als der Agent es nicht schaffte, ein Admin-Konto auf dem Nacos-Server zu erstellen, diagnostizierte er den Fehler, regenerierte seinen eigenen Code und schloss die Kompromittierung 31 Sekunden später ab. Einunddreißig Sekunden ist schneller, als die meisten SOC-Alert-Triage-Queues reagieren. Herkömmliche automatisierte Tools tun das nicht. Sie entweder erfolgreich gegen einen bekannten Pfad vorgehen oder hängen sich auf.

Clarks Zusammenfassung: „Die Beweise deuten darauf hin, dass ein autonomer Agent die Operation steuert, nicht ein menschlicher Operator oder ein festes Toolkit." Ich glaube ihm, denn die Python-Payloads kommentierten ihre eigenen Entscheidungen in Kommentaren und erklärten, warum bestimmte Datenbanken und Credentials priorisiert wurden. Menschliche Operatoren hinterlassen diese Spur nicht. LLMs, die aufgefordert werden, Schritt für Schritt zu denken, tun es dagegen zuverlässig.

Meine Einschätzung: Der Ransomware-Angriff auf Nacos ist der klügste Teil der gesamten Operation. 1.300 Konfigurationsdatensätze innerhalb von MySQL mit AES_ENCRYPT() zu verschlüsseln bedeutet, dass der Explosionsradius keine Dateien auf einer Festplatte sind – es ist das Service-Mesh-Gehirn, das jedem Microservice mitteilt, wo er seine Abhängigkeiten findet. Backups können nach Belieben wiederhergestellt werden – wenn die Konfigurationsebene nicht rekonstruiert werden kann, startet die Anwendung nicht.

Wer betroffen ist

Jeder, der Langflow mit einer öffentlich zugänglichen Instanz betreibt, steht diese Woche unter Zeitdruck. Jeder, der Nacos als Service-Discovery- und Konfigurations-Backbone betreibt, sollte davon ausgehen, dass er nun auf der Zielliste steht. Und jedes Team, das stillschweigend einen LLM-Prototyp in die Produktion gebracht hat – verbunden mit echten Cloud-Credentials – sitzt nun auf einer Angriffsfläche, die vor 24 Monaten noch keine benannte Bedrohung darstellte.

Die iGaming- und Fintech-Betreiber, die ich im letzten Jahrzehnt beobachtet habe, haben hier tendenziell dieselbe Schwachstelle: Internes Tooling wird schnell ausgeliefert, „nur für das Analytics-Team" exponiert und landet nie in den Perimeter-Scans. Langflow, LangChain-Wrapper, selbst entwickelte Orchestratoren – sie alle fallen in diese Lücke. Produktionsvorfälle, die ich gesehen habe, lassen sich fast immer auf eine interne App zurückführen, die jemand vergessen hatte, dass sie im Internet erreichbar ist. JADEPUFFERs erster Zug folgt genau diesem Muster.

Miguel Fornés, Governance & Compliance Manager bei Surfshark, beschrieb den Wandel so: „Diese Effizienz wird gerade als Waffe eingesetzt. Angreifer nutzen KI gnadenlos." Er hat recht, und die Kostenrechnung macht es dauerhaft. Ein LLM-Durchlauf, der Aufklärung bis hin zum Ransomware-Einsatz verknüpft, kostet einstellige Dollarbeträge an API-Calls. Im Vergleich dazu stehen die Kosten für die Einstellung eines Offensiv-Operators. Das entspricht grob dem Budget von zwei Ingenieuren in einem 10-köpfigen Red Team – ersetzt durch eine Inferenzrechnung.

Die unbequeme Erkenntnis: Verteidiger skalieren linear mit der Mitarbeiterzahl, Angreifer skalieren jetzt mit GPU-Kapazität. Ein Zitat aus dem Quellbericht brachte es auf den Punkt: „KI verändert das IT- und Sicherheitsgeschäft für immer. Es wird nicht rückgängig gemacht werden… Traditionelle Sicherheit wird nicht funktionieren. Das Aufstocken mit deutlich mehr menschlichen Sicherheitsteams wird nicht ausreichen." Ich würde argumentieren, dass das keine Übertreibung mehr ist – es ist die Betriebsbedingung für die nächsten 18 Monate.

Die 90-Tage-Prognose für exponierte Umgebungen: Rechnen Sie mit Nachahmern. Die Technik ist dokumentiert, das Zielprofil (KI-Orchestrierungs-Plattformen mit Cloud-Credentials auf der Festplatte) ist breit gefächert, und das Ransomware-Endergebnis ist von Natur aus nicht wiederherstellbar.

Playbook für Sicherheitsteams

Diese Schritte sollten diese Woche, in dieser Reihenfolge, umgesetzt werden:

• Inventarisieren Sie alle Langflow-, LangChain- und LLM-Orchestrierungs-Deployments. Stellen Sie sicher, dass keine ohne Authentifizierung über das Internet erreichbar sind. Prüfen Sie den CISA KEV-Katalog für den Status von CVE-2025-3248 und patchen Sie oder nehmen Sie die Instanzen offline.
• Rotieren Sie alle Credentials, die jemals einen KI-Anwendungsserver berührt haben. LLM-Provider-API-Keys, Cloud-Keys für AWS, Azure, GCP und chinesische Anbieter, Datenbank-Credentials, Wallet-Keys, alles in Umgebungsvariablen. Gehen Sie davon aus, dass eine Enumerierung irgendwo bereits stattgefunden hat.
• Behandeln Sie Nacos, Consul und etcd als Tier-Zero. Wenn Ihre Konfigurationsplattform mit AES_ENCRYPT() verschlüsselt wird, retten Sie Anwendungsdaten-Backups nicht. Erstellen Sie täglich Offline-Snapshots der Konfigurationen und testen Sie die Wiederherstellung.
• Fügen Sie Verhaltensdetection für selbstkommentierende Payloads hinzu. Python-Skripte mit ungewöhnlich ausführlichen Kommentaren und schrittweisen Überlegungen sind jetzt ein echtes Kompromittierungsindikator. Speisen Sie dieses Signal in Ihr EDR ein.
• Alarmieren Sie bei jedem Prozess, der mehrere Cloud-Metadata-Endpunkte sequenziell abfragt. Ein menschlicher Operator wählt einen. Ein LLM-Agent, der auf Dokumentation trainiert wurde, versucht alle.
• Verkürzen Sie die Überprüfungsfrequenz für geplante Tasks. Persistenz über geplante Beacons ist nicht neu, funktioniert aber immer noch, weil niemand Cron prüft.

Eine strukturelle Änderung, für die es sich lohnt, Budget einzuplanen: Gehen Sie davon aus, dass jeder Host, auf dem eine LLM-Anwendung läuft, ein Credential-Tresor ist. Behandeln Sie ihn wie einen Secrets Manager – mit derselben Netzwerksegmentierung, Egress-Kontrollen und Audit-Logging. Die meisten Teams behandeln ihn derzeit wie ein Entwicklungswerkzeug.

Wichtigste Erkenntnisse

• JADEPUFFER ist die erste dokumentierte vollständig autonome Ransomware-Kampagne gemäß der Offenlegung von Sysdig vom 6. Juli 2026. Einstieg über CVE-2025-3248 in Langflow.
• Der Agent regenerierte fehlgeschlagene Payloads in 31 Sekunden. Das Zeitfenster für Verteidiger ist damit dramatisch geschrumpft.
• Mehr als 1.300 Nacos-Konfigurationsdatensätze wurden mit MySQL AES_ENCRYPT() verschlüsselt. Der Schlüssel wurde nie gespeichert, sodass die Zahlung des Lösegelds nichts wiederherstellt.
• KI-Orchestrierungsserver sind jetzt hochwertige initiale Angriffsziele, weil sie LLM-API-Keys, Multi-Cloud-Credentials und Datenbankpasswörter an einem Ort bündeln.
• Kopfzahl-basierte Sicherheitsskalierung verliert den arithmetischen Kampf. Detection Engineering und Blast-Radius-Reduktion schlagen die Einstellung weiterer Analysten.