EU-Aktionsplan für KI und Cybersicherheit: Was deutsche KMU jetzt konkret tun sollten

Der Sicherheitsanbieter Sysdig hat eine Erpressungsoperation dokumentiert, die nach Einschätzung seines Threat Research Teams durch einen KI-Agenten von Anfang bis Ende gesteuert wurde. JADEPUFFER zeigt vor allem eines: Bekannte Schwachstellen, offen erreichbare KI-Werkzeuge und schlecht geschützte Zugangsdaten können heute in Maschinengeschwindigkeit zu einer vollständigen Angriffskette verbunden werden.

Für deutsche KMU ist das kein Anlass für KI-Panik. Die eingesetzten Techniken waren überwiegend bekannt, und der Einstieg erfolgte über eine bereits seit 2025 bekannte, aktiv ausgenutzte Langflow-Lücke. Genau deshalb ist der Vorfall relevant: Solide Basismaßnahmen wie Patchen, Netzsegmentierung, Secret Management, unveränderliche Backups und schnelle Erkennung werden nicht überholt, sondern dringlicher.

TL;DR

• Sysdig bewertet JADEPUFFER als ersten dokumentierten Fall einer durch ein großes Sprachmodell Ende-zu-Ende gesteuerten Ransomware-Operation.
• Der Einstieg erfolgte über CVE-2025-3248 in einer internetseitig erreichbaren Langflow-Instanz; betroffen sind Langflow-Versionen vor 1.3.0.
• Der Agent suchte Zugangsdaten, bewegte sich zu weiteren Systemen, richtete Persistenz ein und zerstörte Datenbankinhalte.
• Die auffällige Neuerung ist nicht eine neue Exploit-Technik, sondern adaptive Automatisierung: Ein fehlgeschlagener Login wurde laut Sysdig binnen 31 Sekunden diagnostiziert und korrigiert.
• KMU sollten zuerst exponierte KI- und Automatisierungsdienste inventarisieren, bekannte Lücken priorisiert schließen, Secrets trennen, ausgehenden Verkehr begrenzen und Wiederherstellungen testen.

Was Sysdig beobachtet hat

Sysdig veröffentlichte seine Analyse am 1. Juli 2026. Nach Einschätzung der Forschenden erlangte JADEPUFFER über CVE-2025-3248 Zugriff auf eine öffentlich erreichbare Langflow-Instanz. Von dort aus wurden Systeminformationen und Zugangsdaten gesucht, weitere Dienste angesprochen und schließlich eine Produktionsdatenbank angegriffen. Sysdig spricht ausdrücklich von einer eigenen Bewertung auf Basis der beobachteten Artefakte; ein unabhängiger Einblick in den System-Prompt oder die Konfiguration des Angreifer-Agenten lag nicht vor.

Von Langflow bis zur Datenbank

CVE-2025-3248 betrifft Langflow-Versionen vor 1.3.0. Die Schwachstelle erlaubt einem nicht authentifizierten Angreifer über einen Code-Validierungs-Endpunkt die Ausführung beliebigen Codes. NVD führt sie mit CVSS 9,8; CISA nahm sie bereits am 5. Mai 2025 wegen nachgewiesener aktiver Ausnutzung in den Known Exploited Vulnerabilities Catalog auf.

Nach dem Einstieg suchte der Angreifer laut Sysdig unter anderem nach API-Schlüsseln von Modellanbietern, Cloud-Zugangsdaten und Datenbank-Credentials. Die kompromittierte Langflow-Instanz diente anschließend als Ausgangspunkt für den Zugriff auf weitere Systeme. Am Ende verschlüsselte der Agent 1.342 Konfigurationseinträge eines Nacos-Systems, löschte Ursprungstabellen und legte eine Lösegeldnotiz an. Der generierte Schlüssel wurde nach Analyse von Sysdig weder gespeichert noch übertragen; eine Wiederherstellung durch Zahlung wäre daher nicht möglich gewesen.

Was daran tatsächlich neu ist

Keine einzelne Technik des Angriffs war außergewöhnlich. Entscheidend war die Verkettung: Aufklärung, Credential-Suche, laterale Bewegung, Persistenz, Fehlerkorrektur und Zerstörung wurden in einer kohärenten Folge ausgeführt. Sysdig stützt die Einordnung als LLM-gesteuert auf vier Indizien: stark kommentierte, sich selbst erklärende Payloads, spezifische Korrekturen bei Fehlern, das Verarbeiten natürlichsprachlicher Hinweise und mehr als 600 zielgerichtete Payloads in kurzer Zeit.

Anpassung statt starrem Skript

Ein Login mit einem neu angelegten Administratorkonto schlug fehl. Der nächste erfolgreiche Korrekturablauf folgte laut Zeitstempeln 31 Sekunden später und änderte gezielt die Art der Passwort-Hash-Erzeugung. In einem anderen Schritt wechselte der Code nach einer unerwarteten XML-Antwort unmittelbar vom JSON- zum XML-Parsing. Dieses situationsabhängige Verhalten unterscheidet einen Agenten von einem klassischen, starr ablaufenden Skript.

Die Formulierung „erste agentische Ransomware“ sollte dennoch sauber eingeordnet werden: Sie ist die Bewertung des veröffentlichenden Forschungsteams, kein allgemein zertifizierter Status. Die Forschenden konnten zwei Details nicht abschließend klären, darunter, ob eine in der Lösegeldnotiz verwendete Beispiel-Bitcoin-Adresse vom Modell halluziniert oder bewusst vorgegeben wurde. Für Verteidiger ändert diese Unsicherheit wenig, sie verhindert aber überzogene Schlussfolgerungen.

Warum der Vorfall für KMU relevant ist

KMU haben häufig weniger Personal für Patch-Management und Security Monitoring. Gleichzeitig entstehen mit internen KI-Piloten neue Dienste: Flow-Builder, Notebook-Umgebungen, Vektordatenbanken, Modell-Gateways und selbst betriebene Agenten. Werden solche Systeme kurzfristig veröffentlicht und tragen sie zugleich Provider-Schlüssel oder Cloud-Credentials in ihrer Prozessumgebung, verbinden sie eine große Angriffsfläche mit wertvollen Zugängen.

Agentische Angriffe verkürzen zudem die Zeit zwischen Erstzugriff und Schaden. Ein Alarm, der erst am nächsten Arbeitstag bearbeitet wird, kann bei automatisierter lateraler Bewegung zu spät kommen. Das bedeutet nicht, dass jedes KMU ein rund um die Uhr besetztes SOC aufbauen muss. Es bedeutet, dass kritische Alarme automatisch eskalieren, gefährliche Verbindungen technisch blockiert und besonders exponierte Systeme außerhalb der Geschäftszeiten notfalls isoliert werden sollten.

Prioritäten im Sicherheitsprogramm

1. KI- und Automatisierungsdienste inventarisieren

Erfassen Sie Langflow, n8n, Notebook-Server, Modell-Proxys, lokale Web-UIs, Vektordatenbanken und experimentelle Container genauso wie klassische Produktionssoftware. Dokumentieren Sie Version, Verantwortliche, Erreichbarkeit, Daten, hinterlegte Secrets und Patch-Weg. Suchen Sie zusätzlich über Cloud-Inventar, Container-Registries, DNS und externe Exposure-Scans nach vergessenen Instanzen.

2. Exponierung und Schwachstellen zuerst reduzieren

Ist Langflow im Einsatz, müssen Versionen vor 1.3.0 aktualisiert werden. Unabhängig vom Produkt sollten Code-Ausführungs- und Validierungs-Endpunkte nicht offen im Internet stehen. Schützen Sie Verwaltungsoberflächen durch VPN oder Zero-Trust-Zugänge, starke Authentifizierung, Netzwerkfilter und möglichst kurze erlaubte Quelllisten. Der CISA-KEV-Katalog ist ein sinnvoller Priorisierungsfaktor, weil er Schwachstellen mit belegter Ausnutzung hervorhebt.

3. Secrets aus Web-Prozessen herauslösen

Ein KI-Orchestrator benötigt selten dauerhaft weitreichende Cloud-Rechte. Nutzen Sie einen Secret Manager, kurzlebige Identitäten und getrennte Service Accounts pro Anwendung und Umgebung. Vergeben Sie nur die Berechtigungen, die für den konkreten Workflow nötig sind. Schlüsselrotation muss vorbereitet sein: Wenn ein Webdienst kompromittiert wurde, sollten alle erreichbaren Secrets zügig gesperrt und ersetzt werden können.

4. Laterale Bewegung erschweren

Produktionsdatenbanken, Konfigurationsdienste und administrative Ports gehören nicht ins öffentliche Netz. Segmentieren Sie Entwicklungs-, KI- und Produktionsumgebungen. Beschränken Sie nicht nur eingehenden, sondern auch ausgehenden Verkehr: Ein kompromittierter Dienst sollte nicht beliebige externe Server, Datenbanken oder Command-and-Control-Ziele erreichen können.

5. Verhalten erkennen und Wiederherstellung testen

Überwachen Sie ungewöhnliche Kindprozesse von Web- oder Datenbankdiensten, massenhafte Secret-Zugriffe, neue Cronjobs, unbekannte Admin-Konten, große Datenbankänderungen und Verbindungen zu neuen Zielen. Klassische Signaturen bleiben nützlich, reichen gegen variable Agenten-Payloads aber nicht allein. Ergänzen Sie sie um Laufzeit- und Identitätsdaten. Backups müssen getrennt, möglichst unveränderlich und regelmäßig durch echte Restore-Tests geprüft sein.

Kompakte 72-Stunden-Checkliste

• Prüfen, ob Langflow oder vergleichbare KI-Orchestratoren intern oder extern betrieben werden.
• Internetseitig erreichbare Instanzen und administrative Datenbankports schließen oder stark einschränken.
• Langflow vor Version 1.3.0 sofort aktualisieren und Logs auf frühere Ausnutzung untersuchen.
• In KI-Diensten hinterlegte API-Schlüssel, Cloud-Credentials und Datenbankkonten erfassen und überprivilegierte Rechte reduzieren.
• Egress-Regeln für KI-, Entwicklungs- und Datenbanksegmente überprüfen.
• Alarme für Secret-Zugriff, neue Persistenzmechanismen und destruktive Datenbankaktionen aktivieren.
• Letzten Wiederherstellungstest und die tatsächliche Trennung der Backups kontrollieren.

Was im Verdachtsfall zu tun ist

Wenn eine exponierte KI-Anwendung verwundbar war oder ungewöhnliches Verhalten zeigt, reicht ein schnelles Update allein nicht aus. Ein Patch schließt den Einstieg, entfernt aber weder angelegte Konten noch gestohlene Schlüssel oder Persistenz. Behandeln Sie das System deshalb bis zum Gegenbeweis als kompromittiert: vom Netz isolieren, flüchtige Daten und Logs sichern, den zeitlichen Ablauf dokumentieren und erst danach bereinigen. Die forensische Sicherung sollte mit dem internen Notfallplan, dem IT-Dienstleister oder einem Incident-Response-Spezialisten abgestimmt werden.

Rotieren Sie alle Zugangsdaten, die der betroffene Prozess lesen konnte – nicht nur das Passwort der Anwendung. Dazu können Modell-API-Schlüssel, Cloud-Tokens, Datenbankkonten, SSH-Schlüssel und Zugangsdaten in Konfigurationsdateien gehören. Prüfen Sie außerdem die Zielsysteme, auf die diese Identitäten zugreifen durften. Eine reine Neuinstallation des Einstiegsservers ist unzureichend, wenn der Angreifer bereits neue Konten, geplante Tasks oder Datenbankänderungen auf Folgesystemen hinterlassen hat.

Entscheidungen nach Geschäftsauswirkung priorisieren

Nicht jeder KI-Pilot braucht dasselbe Schutzniveau. Ein isolierter Test ohne echte Daten hat ein anderes Risiko als ein Orchestrator mit Zugriff auf CRM, ERP und Produktionsdatenbanken. Entscheidend sind erreichbare Daten und Systeme, nicht das Label „KI“. Geschäftsführung und IT sollten für jeden Dienst festlegen, welcher Ausfall tolerierbar ist, welche Daten betroffen sein können, wie schnell isoliert werden muss und wer die Entscheidung trifft.

• Niedrige Kritikalität: Testdaten, keine produktiven Identitäten, keine Verbindung zu internen Systemen. Standard-Patching und Basis-Monitoring können genügen.
• Mittlere Kritikalität: Interne Daten oder einzelne SaaS-Schnittstellen. Zusätzliche Segmentierung, zentrale Secrets und konkrete Alarmwege sind erforderlich.
• Hohe Kritikalität: Personenbezogene Daten, Produktionszugriffe, administrative Rechte oder Kundenprozesse. Hier sind enges Least Privilege, Laufzeiterkennung, unveränderliche Backups und ein geübter Incident-Response-Ablauf notwendig.

Bei einem möglichen Abfluss personenbezogener Daten müssen Unternehmen zudem ihre datenschutzrechtlichen Bewertungs- und Meldeprozesse aktivieren. Ob eine Meldung erforderlich ist, hängt vom konkreten Vorfall ab und sollte mit Datenschutzbeauftragten beziehungsweise Rechtsberatung geklärt werden. Technische Eindämmung und belastbare Dokumentation helfen dabei, die Lage schnell und nachvollziehbar zu bewerten.

Fazit

JADEPUFFER ist weniger eine Geschichte über eine magische neue Ransomware als über die Industrialisierung bekannter Angriffstechniken. Ein KI-Agent kann alte Schwachstellen, schwache Konfigurationen und offen liegende Zugangsdaten schnell kombinieren. Das senkt die Hürde für Angreifer und verkürzt die Reaktionszeit für Verteidiger.

Die wirksamste Antwort für KMU bleibt pragmatisch: Angriffsfläche kennen, aktiv ausgenutzte Lücken priorisieren, Identitäten klein halten, Netze segmentieren, Verhalten überwachen und Wiederherstellung beweisen. Wer diese Grundlagen konsequent umsetzt, nimmt auch einem adaptiven Agenten die Bausteine für eine erfolgreiche Angriffskette.

Quellen und Hinweis

• Sysdig Threat Research: JADEPUFFER – Agentic ransomware for automated database extortion
• NIST National Vulnerability Database: CVE-2025-3248
• CISA: Aufnahme von CVE-2025-3248 in den Known Exploited Vulnerabilities Catalog
• Langflow: Release 1.3.0

Die Einstufung als erster dokumentierter agentischer Ransomware-Fall ist die Bewertung von Sysdig. Der Beitrag gibt den öffentlich dokumentierten Stand wieder und ersetzt keine individuelle Incident-Response- oder Rechtsberatung.