Als der Angreifer keinen Menschen mehr brauchte
Am 1. Juli 2026 veröffentlichte das Sysdig Threat Research Team seine Analyse einer Ransomware-Operation, die es JADEPUFFER nannte. Nach Sysdigs eigenen Worten handelt es sich um "what we assess to be the first documented case of agentic ransomware: a complete extortion operation driven end-to-end by a large language model (LLM)." (nach Sysdigs Einschätzung der erste dokumentierte Fall agentischer Ransomware: eine vollständige Erpressungsoperation, die von Anfang bis Ende von einem Large Language Model gesteuert wurde).
Dies ist keine weitere Geschichte über KI-geschriebene Phishing-Mails oder Deepfake-Anrufe. In den Payloads, die Sysdig mitgeschnitten hat, nutzte der Agent eine aus dem Internet erreichbare Anwendung aus, sammelte Zugangsdaten, wechselte auf einen zweiten Server, übernahm dessen Konfigurationsdienst, verschlüsselte und löschte Daten und hinterließ eine Lösegeldforderung. Schlug ein Schritt fehl, diagnostizierte er den Fehler und versuchte es erneut, ohne auf Anweisungen zu warten.
Bei BackupSec halten wir JADEPUFFER weniger als Einzelvorfall für bedeutsam denn als Vorschau. Es ist ein früher Datenpunkt zu einer Frage, die jede Backup- und Recovery-Architektur irgendwann beantworten muss: Was passiert, wenn die Entscheidungsschleife auf der Gegenseite von Stunden auf Sekunden schrumpft?
Die Angriffskette von JADEPUFFER im Detail
In groben Zügen ist dies eine Kill Chain, gegen die sich Sicherheitsteams seit Jahren verteidigen. Sysdig sagt das selbst: "None of the individual techniques were novel or sophisticated." (Keine der einzelnen Techniken war neu oder raffiniert.) Neu war, was sie ausführte. Der folgende Ablauf folgt Sysdigs Bericht:
- Erstzugriff. Der Agent nutzte CVE-2025-3248 in Langflow aus, einem Open-Source-Framework zum Bau von LLM-Anwendungen. Die NVD beschreibt die Schwachstelle als Code-Injection im Endpunkt
/api/v1/validate/code, über die "a remote and unauthenticated attacker" (ein entfernter, nicht authentifizierter Angreifer) beliebigen Code ausführen kann, und bewertet sie mit CVSS 9,8. Die Korrektur erschien mit Langflow 1.3.0 am 31. März 2025, und die CISA nahm die Schwachstelle am 5. Mai 2025 in ihren Katalog der Known Exploited Vulnerabilities auf. Der Patch existierte, war aber nicht eingespielt. - Sammeln von Zugangsdaten. Auf dem Langflow-Host enumerierte der Agent das System, durchsuchte die Umgebung nach API-Schlüsseln von LLM-Anbietern, Cloud-Zugangsdaten, Kryptowährungs-Wallets und Datenbank-Zugangsdaten und erstellte anschließend einen Dump der Postgres-Datenbank von Langflow selbst. Er fand einen vom Host aus erreichbaren MinIO-Objektspeicher, meldete sich mit den Standard-Zugangsdaten von MinIO (
minioadmin:minioadmin) an und listete Buckets auf, zu denen laut Sysdig "application data, backups, ML artifacts, and a terraform-state bucket" gehörten (Anwendungsdaten, Backups, ML-Artefakte und ein Bucket mit Terraform-State). Aus einem davon holte er eine Dateicredentials.jsonmit einem Paar aus Access Key und Secret. - Persistenz. Er richtete auf dem Langflow-Host einen Crontab-Eintrag ein, der alle 30 Minuten die Infrastruktur des Angreifers kontaktiert.
- Wechsel zum eigentlichen Ziel. Laut Sysdig war das eigentliche Ziel der Operation ein separater, aus dem Internet erreichbarer Produktivserver mit MySQL und einem Alibaba-Nacos-Konfigurationsdienst. Der Agent verband sich als root mit dem offen erreichbaren MySQL-Port. Woher diese Root-Zugangsdaten stammten, hat Sysdig nicht beobachtet: "Their origin is unknown." (Ihre Herkunft ist unbekannt.)
- Übernahme von Nacos. Der Agent griff Nacos auf mehreren Wegen gleichzeitig an: über die Familie der Authentifizierungsumgehungen von CVE-2021-29441 (laut NVD lässt sich in Nacos vor Version 1.4.1 der Authentifizierungsfilter mit einem gefälschten User-Agent-Header umgehen), über ein JSON Web Token, das mit dem öffentlich dokumentierten Standard-Signaturschlüssel von Nacos gefälscht wurde, und über ein Hintertür-Administratorkonto, das er mit seinem Root-Zugriff direkt in die Nacos-Datenbank schrieb. Der JWT-Weg scheiterte ("custom secret in use", also mit dem Hinweis, dass ein eigenes Secret konfiguriert war) und wurde aufgegeben. Das Hintertürkonto funktionierte, nach der unten beschriebenen Korrektur innerhalb von 31 Sekunden.
- Auswirkung. Der Agent verschlüsselte alle 1.342 Nacos-Konfigurationseinträge mit MySQLs
AES_ENCRYPT(), löschte die ursprünglichen Konfigurations- und Verlaufstabellen und ging dann dazu über, ganze Datenbankschemata zu löschen. Die Lösegeldnotiz behauptet AES-256; Sysdig weist darauf hin, dassAES_ENCRYPT()standardmäßig AES-128-ECB verwendet, sofern der Server nicht umkonfiguriert wurde. Für die Wiederherstellung wichtiger ist ein anderes Detail: Der Schlüssel wurde einmal ausgegeben und weder gespeichert noch übermittelt, sodass, in Sysdigs Worten, "The victim cannot recover the encrypted configurations even with payment." (Das Opfer kann die verschlüsselten Konfigurationen selbst gegen Zahlung nicht wiederherstellen.) Nur eine Kopie, die vor dem Angriff erstellt und außerhalb der Reichweite des Angreifers aufbewahrt wurde, konnte diese Daten zurückbringen. - Erpressung. Er legte eine Tabelle
README_RANSOMmit der Forderung, einer Bitcoin-Adresse und einem Proton-Mail-Kontakt an.
Der ehrliche Vorbehalt
Wir wollen genau sagen, was „autonom" hier bedeutet, denn eine Übertreibung würde das Argument untergraben, das wir gleich vorbringen.
Sysdig benennt zwei Dinge, die es nicht sehen kann. Es hat nicht beobachtet, wie der Agent an die MySQL-Root-Zugangsdaten kam, die er in Schritt vier verwendete. Und es hat "no visibility into JADEPUFFER's system prompt or agent configuration" (keinen Einblick in den System-Prompt oder die Agentenkonfiguration von JADEPUFFER), kann also nicht sagen, welches Ziel oder welche Ressourcen ein Mensch dem Agenten vor dem Start mitgegeben hat. Jemand hat ihn gebaut, konfiguriert und gestartet.
Was Sysdig dokumentiert, ist das Verhalten innerhalb der mitgeschnittenen Sitzungen: mehr als 600 unterschiedliche Payloads, Code, der seine eigenen Überlegungen kommentiert, und Fehler, die binnen Sekunden diagnostiziert und korrigiert wurden. Auf dieser Grundlage kommt Sysdig zu dem Schluss, dass "the evidence points to an autonomous agent driving the operation rather than a human operator or a fixed toolkit." (die Belege auf einen autonomen Agenten als treibende Kraft der Operation hindeuten und nicht auf einen menschlichen Operator oder ein festes Toolkit).
Diese Unterscheidung ist wichtig, und wir meinen, dass sie das Argument eher stärkt als schwächt. Selbst eine Kette, in der ein Mensch das Ziel vorgibt und der Agent die Ausführung übernimmt, beseitigt die größte Latenzquelle einer klassischen Ransomware-Operation: die Zeit, die ein menschlicher Operator mit Nachdenken, Rückfragen bei einem Handler und der Entscheidung über den nächsten Versuch verbringt.
Warum 31 Sekunden mehr bedeuten, als es klingt
Die 31 Sekunden sind keine Gesamtdauer des Angriffs. Sysdig veröffentlicht keine Gesamtdauer der Kette, und wir werden bewusst keine erfinden. Veröffentlicht wird eine Sequenz mit Zeitstempeln aus der Nacos-Übernahme. Der Agent legte sein Hintertür-Adminkonto an, versuchte sich um 19:34:36 UTC anzumelden und scheiterte. Er prüfte zwei mögliche Ursachen parallel und setzte dann um 19:35:07 eine 15-zeilige Korrektur-Payload ab, die das Konto korrekt neu aufbaute. Die Anmeldung gelang um 19:35:18. In Sysdigs Worten: "The window between the failed login and the correct multi-step fix is 31 seconds." (Zwischen dem fehlgeschlagenen Login und der korrekten mehrstufigen Korrektur liegen 31 Sekunden.) Sysdig berichtet dasselbe Muster an anderen Stellen der Sitzung. Als eine Anfrage XML statt JSON zurückgab, parste die nächste Payload XML. Als ein DROP DATABASE an einer Fremdschlüssel-Constraint scheiterte, schaltete die nächste die Prüfung zuerst ab.
Vergleichen Sie das damit, wie sich ein menschlicher Operator verhält, wenn ein Schritt fehlschlägt. Er hält inne. Er bewertet die Lage neu. In einer strukturierten Ransomware-as-a-Service-Operation schreibt er vielleicht einem Handler und wartet auf Anweisungen. Er versucht es erneut, in einem Zeitrahmen von Minuten oder Stunden, manchmal über einen Schichtwechsel hinweg. Diese Latenz, die Lücke zwischen einem Fehlschlag und dem nächsten Versuch, war immer einer der wenigen Faktoren, die zugunsten der Verteidiger wirkten. Sie ist der Grund, warum ein Alarm um 2 Uhr nachts noch um 8 Uhr morgens von einem Menschen triagiert werden kann, ohne dass sich der Vorfall in der Zwischenzeit zwangsläufig dramatisch verschlimmert hat.
Ein Agent, der diese Lücke auf 31 Sekunden schließt, ist nicht einfach nur schneller. Er beseitigt die Annahme, die in fast jedem Incident-Response-Runbook steckt: dass zwischen dem ersten fehlgeschlagenen Versuch eines Angreifers und seinem nächsten ein Zeitfenster in menschlichem Maßstab liegt und dass ein Detection-and-Response-Prozess, der in einem ähnlich menschlichen Zeitmaß arbeitet, vernünftigerweise erwarten kann, darin einzugreifen.
Die Zahlen, die schon vor der KI galten
Backup-Infrastruktur ist nicht wegen agentischer KI zum Ziel geworden. Sie war es bereits, und die Daten dazu sind zwei Jahre älter als JADEPUFFER.
- Veeams 2024 Ransomware Trends Report, eine Umfrage unter 1.200 Befragten aus Organisationen, die 2023 mindestens einen Ransomware-Angriff erlitten hatten, stellte fest: "backup repositories are targeted in 96% of attacks, with bad actors successfully affecting the backup repositories in 76% of cases." (Backup-Repositories werden bei 96 % der Angriffe ins Visier genommen, und in 76 % der Fälle gelingt es den Angreifern, sie zu beeinträchtigen.) Veeam wiederholt die Zahl von 96 % im eigenen Blog.
- Sophos' Studie von 2024 zu kompromittierten Backups, basierend auf 2.974 IT- und Cybersecurity-Fachleuten, deren Organisationen im Vorjahr von Ransomware getroffen worden waren, kam zu dem Ergebnis: "The median overall ransomware recovery costs for organizations whose backups were compromised ($3M) came in eight times higher than that of organizations whose backups were not impacted ($375K)." (Die medianen Gesamtkosten der Wiederherstellung lagen bei Organisationen mit kompromittierten Backups mit 3 Mio. US-Dollar achtmal höher als bei Organisationen, deren Backups nicht betroffen waren, mit 375.000 US-Dollar.)
Diese Zahlen beschreiben eine Welt menschlicher Angreifer, die bereits verstanden hatten, dass das Zerstören oder Verschlüsseln der Backup-Ebene der wirkungsvollste einzelne Schritt ist, sobald eine Ransomware-Operation Fuß gefasst hat. Agentische KI ändert an dieser Rechnung nichts. Sie ändert, wer oder was sie umsetzen kann: im großen Maßstab, rund um die Uhr, ohne Schlaf, ohne Schichtpause und ohne auf die Freigabe eines Handlers zu warten, bevor die nächsten Zugangsdaten ausprobiert werden.
IBMs 2026 X-Force Threat Intelligence Index liefert die Trendlinie. IBM X-Force beobachtete einen Anstieg von 44 % bei Angriffen, die mit der Ausnutzung öffentlich erreichbarer Anwendungen begannen, also genau über den Einstiegsvektor, den JADEPUFFER nutzte, und die Zahl aktiver Ransomware- und Erpressergruppen stieg im Jahresvergleich um 49 %. Die Angriffsfläche wuchs bereits, bevor irgendetwas davon einen autonomen Operator brauchte.
Von Erkennungsfenstern zu Wiederherstellungssicherheit
Die Ausnutzung einer bekannten Schwachstelle ist bereits der häufigste Weg hinein. Derselbe IBM-Bericht sagt, die Ausnutzung von Schwachstellen "became the leading cause of attacks, accounting for 40% of incidents observed by X-Force in 2025." (wurde zur häufigsten Angriffsursache und machte 40 % der von X-Force im Jahr 2025 beobachteten Vorfälle aus). Die Lücke zwischen bekannten und geschlossenen Schwachstellen ist zu groß und füllt sich zu stetig wieder auf, als dass perfekte Prävention realistisch wäre. JADEPUFFER passt ins Muster: Sysdig merkt an, dass der Angriff auf das eigentliche Ziel "leaned on years-old issues, a 2021 Nacos auth-bypass and an unchanged default signing key." (sich auf jahrealte Probleme stützte, eine Nacos-Authentifizierungsumgehung von 2021 und einen nie geänderten Standard-Signaturschlüssel). JADEPUFFER ändert dieses Argument nicht. Es verschärft es.
Wenn die Arbeitsannahme der Branche lautete, ein Detection-and-Response-Prozess im menschlichen Tempo könne vernünftigerweise erwarten, einen Einbruch irgendwo zwischen Erstzugriff und irreversibler Auswirkung abzufangen, dann stellt ein Agent, der sich in 31 Sekunden selbst korrigiert, diese Annahme direkt infrage. Die Antwort kann nicht „schneller erkennen und reagieren als eine Maschine" lauten, denn das ist kein Wettlauf, bei dem Verteidiger erwarten können, ihn auf unbestimmte Zeit weiter zu gewinnen. Die Antwort muss architektonisch sein: Das Ergebnis eines schnellen, anpassungsfähigen Einbruchs muss überlebbar sein, ganz gleich, wie viel schneller der Angreifer wird.
Konkret ändern sich die Eigenschaften, auf die es bei Backup- und Recovery-Infrastruktur ankommt, nicht dadurch, dass der Angreifer ein KI-Agent statt eines Menschen ist. Sie werden von erstrebenswert zu unverzichtbar:
- Trennung von Zugangsdaten und Identitäten, die nicht davon abhängt, dass ein Mensch ungewöhnliche Aktivitäten rechtzeitig bemerkt. Wenn die Zugangsdaten, die in Ihre Backup-Umgebung führen, dieselben sind, die ein Agent in Sekunden von einem kompromittierten Host abgreifen kann, muss die Isolation strukturell sein, nicht prozedural.
- Immutability, die validiert und nicht nur konfiguriert ist. Eine Aufbewahrungssperre, die sich mit ausreichend privilegierten Zugangsdaten stillschweigend deaktivieren lässt, ist eine Kontrolle, die davon ausgeht, dass ein menschlicher Angreifer zögert. Ein Agent zögert nicht.
- Recovery-Tests, die davon ausgehen, dass der Angreifer Ihre Umgebung bereits kennt. Der Agent von JADEPUFFER passte sich in Echtzeit an fehlgeschlagene Schritte an. Ein Wiederherstellungsplan, der immer nur gegen ein einziges, erwartetes Fehlerszenario getestet wurde, ist für einen langsameren, berechenbareren Gegner gebaut als den, der nun nachweislich möglich ist.
Was das für Verantwortliche im Enterprise-Risikomanagement bedeutet
JADEPUFFER ist eine dokumentierte Kampagne, kein Beleg dafür, dass jede Ransomware-Operation jetzt autonom abläuft. Doch wenn Sysdigs Einschätzung zutrifft, wurde etwas beobachtet, das bisher theoretisch war: ein LLM-Agent, der eine echte Angriffskette gegen ein echtes Ziel ausführt, mit einer Selbstkorrekturschleife im Sekundenbereich.
Für Risikoverantwortliche lautet die praktische Frage nicht mehr, ob agentische Ransomware häufiger wird. Sysdig sagt, Verteidiger "should expect the volume and breadth of such campaigns to rise as agentic tooling matures" (sollten damit rechnen, dass Umfang und Breite solcher Kampagnen zunehmen, je ausgereifter agentische Werkzeuge werden), und IBM X-Force "expects adversaries to automate complex tasks like reconnaissance and advanced ransomware attacks." (erwartet, dass Angreifer komplexe Aufgaben wie Aufklärung und fortgeschrittene Ransomware-Angriffe automatisieren). Die praktische Frage ist, ob die Annahmen Ihrer Wiederherstellungsarchitektur für einen Gegner im menschlichen Tempo gemacht wurden oder für einen, der das nicht mehr sein muss.
Wo BackupSec ins Spiel kommt
Bei BackupSec haben wir unseren Ansatz um eine Prämisse herum aufgebaut, die JADEPUFFER dringlicher macht: Prävention wird versagen, und über den Ausgang entscheidet die Ebene, die darauf ausgelegt ist, dieses Versagen zu überstehen, ganz gleich, wie schnell sich das bewegt hat, was es verursacht hat.
- ZeroMON überwacht Veeam Backup & Replication. Es wird on-premises als OVA bereitgestellt, verbindet sich mit einem Read-only-Konto und sendet nichts an BackupSec oder Dritte. Es verfolgt den Zustand der Backup-Jobs, protokolliert Konfigurationsänderungen in Veeam (wer was wann geändert hat), zeigt den Immutability-Status so an, wie ihn Veeams eigene Repository-Einstellungen melden, und behält die Checkliste des Veeam Security Analyzer im Blick. Seine Alarmregeln decken die Schritte ab, die ein Eindringling auf Veeam-Seite gegen Backups unternimmt, etwa Änderungen an Zugangsdaten, Änderungen an Aufbewahrung und Zeitplänen, deaktivierte Jobs und Löschsitzungen. Alarme werden per E-Mail und als In-App-Benachrichtigung versendet. ZeroMON überwacht Veeam: Es sieht kein Abgreifen von Zugangsdaten auf anderen Hosts, und es liest Veeams Immutability-Einstellungen aus, statt die Sperren auf dem Speicher selbst zu prüfen.
- ZeroTAM stellt Ihrem Team einen dedizierten Backup-Security-Berater zur Seite: Architekturprüfung, Planung der Ransomware-Wiederherstellung, Kapazität und priorisierter Support in der Krise. Hier lässt sich auf den Prüfstand stellen, ob Ihre Identitätstrennung, Immutability und Isolation für einen Angreifer im menschlichen Tempo ausgelegt wurden.
- ZeroPEN ist ein bedrohungsorientierter Penetrationstest von Veeam Backup & Replication, Veeam ONE und Enterprise Manager. Er simuliert eine Ransomware-Kill-Chain in acht Phasen, die auf MITRE ATT&CK abgebildet sind, vom Erstzugriff und Missbrauch von Zugangsdaten über den Zugriff auf Repositories und die Neutralisierung von Backups bis zum Nachweis der Verschlüsselungsfähigkeit. Das Engagement umfasst die Verifizierung der Restore-Integrität und der Immutability und liefert auditfähige Nachweise sowie einen Retest für kritische Befunde. Es ist nicht destruktiv: ZeroPEN "never deletes real backups, performs real encryption, or stops production or backup services." (löscht niemals echte Backups, führt keine echte Verschlüsselung durch und stoppt weder Produktions- noch Backup-Dienste).
Die Frage, die JADEPUFFER aufwirft, ist nicht, ob Ihre Abwehr schnell ist. Sie lautet, ob Ihre Wiederherstellungsarchitektur so gebaut wurde, dass sie nicht davon abhängt, dass die Abwehr schnell ist.
Sprechen Sie mit BackupSec über die Validierung Ihrer Wiederherstellungsarchitektur →
Diese Analyse stützt sich auf Sysdigs Forschung zu JADEPUFFER vom Juli 2026, IBMs 2026 X-Force Threat Intelligence Index, Veeams 2024 Ransomware Trends Report und Sophos' Studie von 2024 zu kompromittierten Backups, mit Schwachstellendetails von NVD und CISA. Die hier vorgestellte Interpretation und das Framework stammen von BackupSec. Wenn Sie besprechen möchten, wie sich diese Analyse auf Ihre konkrete Umgebung übertragen lässt, nehmen Sie Kontakt mit unserem Team auf →
