DeepSeek und ein quelloffenes Agentengerüst: der selbsttätige Angriff scheitert, der manuelle gelingt

Was geschehen ist

Nach dem Bericht von Unit 42 verband ein einzelner Akteur das Modell DeepSeek mit dem quelloffenen Agentengerüst Hermes Agent. Angebunden war zusätzlich ein öffentlich verfügbarer MCP-Server (FofaMap-Platinum-Full-Expert), der dem Modell drei Dinge zugänglich machte: die Suche nach erreichbaren Systemen über den Dienst FOFA, die Erzeugung von Prüfläufen mit dem Werkzeug Nuclei und die Übersetzung natürlicher Sprache in Suchabfragen. Der Akteur hat diese Software nicht selbst geschrieben; der Bericht verweist auf das zugehörige öffentliche Verzeichnis.

Insgesamt versuchte der Akteur nach dem Bericht, über 460 Ziele anzugreifen — und zwar „mit einer Mischung aus selbsttätigen und von Hand ausgeführten Verfahren”. Die beiden Teile sind im Bericht getrennt dargestellt, und sie gingen unterschiedlich aus.

Der selbsttätige Teil

Unit 42 konnte einen selbsttätigen Durchlauf vollständig wiederherstellen, vom 7. Mai 2026. Er begann mit einem Befehl über den Nachrichtendienst Telegram. Weitere Eingaben des Menschen ließen sich nicht nachweisen: „Wir konnten über die ursprüngliche Aufgabenstellung hinaus keine weitere Eingabe des Betreibers wiederherstellen.”

Der Ablauf:

1. Erster Angriffsweg. Das Modell ermittelte über FOFA 84 erreichbare Instanzen der Software Langflow und prüfte sie mit einem selbst beschafften Prüfprogramm auf die Schwachstelle CVE-2026-33017. Ein Ziel war angreifbar.

2. Eigenständiger Abbruch. Die Angriffe scheiterten, weil die Schwachstelle eine bestimmte Einstellung oder eine öffentlich bekannte Kennung voraussetzt. Das Modell hielt das selbst fest — der Bericht gibt seine Überlegung wörtlich wiedergegeben: „Alle drei Langflow brauchen eine öffentliche Flow-ID, aber kein auto_login — festgefahren […] Suche nach Schwachstellen größeren Umfangs.” Und: „ausnutzbar wahrscheinlich 0.”

3. Eigenständige Zielwahl. Das Modell verglich daraufhin die Verbreitung von zehn Produktfamilien über FOFA und durchsuchte das Verzeichnis GitHub nach Angriffscode zu aktuellen Schwachstellen. Es entschied sich für die Software n8n — nach der Beliebtheit des gefundenen Angriffscodes (258 Sterne) und nach dem Schweregrad der Schwachstelle (CVSS 10.0).

4. Zweiter Angriffsweg. FOFA wies 647.017 Instanzen weltweit aus, 25.209 davon in China. Das Modell wählte daraus rund 100 Adressen aus, prüfte etwa 40 davon einzeln auf die Versionsnummer und fand drei angreifbare Fassungen (CVE-2026-21858 und CVE-2025-68613).

5. Ende. Auch dieser Weg scheiterte: Keines der drei Ziele hatte die öffentlich erreichbaren Formulare, die der Angriffsablauf benötigte. Der Durchlauf endet an dieser Stelle.

Der selbsttätige Teil blieb damit ohne jeden Erfolg. Gescheitert ist er nicht an einer Abwehr, sondern an Voraussetzungen auf der Seite der Ziele, die zufällig nicht erfüllt waren. Der Bericht hält das als erste von vier Folgerungen für Verteidiger fest: Selbsttätige Angriffszyklen seien betrieblich durchführbar, und die Spanne zum Erfolg sei schmal gewesen — bei Zielen mit schwächeren Voreinstellungen wären sie gelungen.

Der von Hand ausgeführte Teil

Hier liegen die bestätigten Schäden:

• Abfluss von Daten bei drei Stellen über eine Schwachstelle in Citrix NetScaler (CVE-2026-3055). Darunter eine Regierungsstelle in Malaysia, die der Akteur nach dem Bericht beharrlich und über mehrere Tage hinweg angriff.
• Befehlsausführung auf elf Instanzen der Software Marimo (CVE-2026-39987).
• Versuche, eine Rückwärtsverbindung aufzubauen, gegen neun Apache-Tomcat-Server und drei IKE-VPN-Endpunkte; mit welchem Ergebnis, geht aus dem Bericht nicht hervor.

Bestätigt betroffen sind nach dem Bericht Stellen in drei Staaten und mehreren Branchen.

Das ist der Befund, der die Darstellung in der Berichterstattung umkehrt: Nicht der Agent war erfolgreich, sondern der Mensch. Der Agent war schnell — eine Fachdarstellung spricht davon, er habe Stunden manueller Zielauswahl in Minuten zusammengezogen — aber er traf kein Ziel.

Was die Anbieter betrifft

Der Akteur nutzte nach dem Bericht neben DeepSeek auch kommerzielle Werkzeuge, aber in geringem Umfang:

Claude Code: „Der Akteur nutzte dies nur für Erreichbarkeitsprüfungen und die Überprüfung eines Vermittlungsservers. Der Sitzungsverlauf (10 Einträge über drei Sitzungen) enthielt nur /model-Abfragen, Erreichbarkeitsprüfungen und eine Anfrage zur Installation eines Pakets.” Eine Verweigerung ist hierzu nicht dokumentiert.

Qwen Code: zwei Sitzungen, geringfügige Nutzung.

Codex: Hierzu nennt der Bericht die einzige dokumentierte Durchsetzung von Schutzmechanismen:

„Unsere Kollegen bei OpenAI konnten bestätigen, dass ihre anbieterseitigen Schutzmaßnahmen Anfragen abgewiesen haben, die gegen ihre Richtlinien verstießen. Sie bestätigten ferner, dass fortgesetzte Versuche dazu führten, dass ihre Sicherheitssysteme ein Konto, das sie dieser Kampagne zuordnen, markiert und abgeschaltet haben — und zwar vor unserem Austausch von Erkenntnissen mit ihrem Team.”

Was die Sichtbarkeit einschränkt. Der Akteur hatte bei beiden westlichen Werkzeugen Vorkehrungen gegen die Zuordnung getroffen: Er leitete sie „über einen Vermittlungsdienst eines Dritten […], um die Nachvollziehbarkeit zu verringern”, schaltete bei Claude Code über zwei Umgebungsvariablen die Zuordnungskennung und nicht zwingende Übertragungen ab und bei Codex die Speicherung der Antworten.

Hinzu kommt, dass Claude Code nach der Aufstellung im Bericht nicht für die geringe Nutzung eingerichtet war, die der Sitzungsverlauf zeigt: Die Berechtigungsabfragen waren übergangen, zwölf Werkzeuge ausdrücklich freigegeben, darunter die Kommandozeile, Dateizugriff, Netzabfragen und das Starten weiterer Agenten.

Daraus folgt für die Aussage „keine Verweigerung dokumentiert”: Sie beschreibt, was in den wiederhergestellten Unterlagen steht, nicht zwangsläufig, was geschehen ist. Wo Verkehr über einen fremden Vermittlungsdienst läuft und Kennungen abgeschaltet sind, ist die Grundlage schmaler. Der Bericht selbst liest die geringe Nutzung als Markterkundung: Sie sei „damit vereinbar, dass der KI-Markt geprüft wurde, um den bevorzugten Werkzeugsatz zu bestimmen.”

Die Folgerung zieht der Bericht selbst, als dritte seiner vier Folgerungen für Verteidiger: Angreifer wählten Modelle mit minimalen Schutzvorkehrungen, erreichbar über Gerüste ohne Beschränkungen. Zu diesem Fall heißt es: „der Akteur wählte ein Modell mit minimalen Sicherheitsvorkehrungen (DeepSeek), erreichbar über ein quelloffenes Gerüst ohne clientseitige Beschränkungen.”

Was der Bericht nicht sagt: dass der Akteur es zuerst mit den kommerziellen Werkzeugen versucht habe und nach deren Verweigerung gewechselt sei. Eine zeitliche Reihenfolge der Werkzeugnutzung ist nicht dargestellt. Mehrere Darstellungen in der Berichterstattung legen diese Reihenfolge nahe; sie ist durch den Bericht nicht belegt.

Wie die Sache aufflog

Nicht durch Erkennung, sondern durch einen Fehler des Agenten selbst — der Bericht führt das als vierte Folgerung: Selbsttätige Ausführung schaffe neue betriebliche Risiken für die Angreifer.

Hermes Agent startete auf den Telegram-Befehl hin einen einfachen Dateiserver (python3 -m http.server 8888) im Benutzerverzeichnis des Akteurs (/home/worker) statt in einem abgetrennten Arbeitsverzeichnis. Damit lagen offen im Netz:

• die Konfigurationen der verwendeten KI-Werkzeuge
• Zugangsschlüssel
• Angriffsskripte
• Ziellisten
• der Befehlsverlauf der Kommandozeile
• die Protokolle der selbsttätigen Durchläufe

Erst dadurch wurde die Kampagne von außen sichtbar und im Einzelnen auswertbar. Der wiederhergestellte Durchlauf vom 7. Mai stammt aus diesen Protokollen.

Der Unterschied zu GTG-1002

Das Verzeichnis führt mit GTG-1002 (September 2025) einen weiteren Fall weitgehend selbsttätiger Angriffe. Die beiden sind nicht vergleichbar:

	GTG-1002	Dieser Fall
Akteur	nach Einschätzung des Anbieters staatlich geförderte Gruppe	Einzelperson
Modell	kommerzielles Modell	quelloffenes Modell, über ein quelloffenes Gerüst
Schutzmechanismen	mussten umgangen werden, und dieser Aufwand war Teil der Kampagne	auf der genutzten Seite nicht vorhanden
Quelle	Bericht des beteiligten Anbieters	Untersuchung eines Dritten, mit Angaben eines Anbieters darin
Ergebnis des selbsttätigen Teils	in einer kleinen Zahl von Fällen erfolgreich	ohne Erfolg
Ergebnis insgesamt	—	erfolgreich war der von Hand ausgeführte Teil

Die Zeile zu den Schutzmechanismen ist der sachliche Kern: Bei GTG-1002 wurde der Angriff in harmlos wirkende Einzelaufgaben zerlegt und das Modell über den Zusammenhang getäuscht. Hier entfiel dieser Aufwand, weil auf der genutzten Seite nichts zu umgehen war.

Die Zeile zum Ergebnis ist der zweite: Die beiden Fälle stützen entgegengesetzte Aussagen über die Leistungsfähigkeit selbsttätiger Angriffe. Beide beruhen auf je einer Untersuchung.

Regulatorische Anknüpfungspunkte

Art. 2 Abs. 12 der KI-Verordnung nimmt KI-Systeme, die unter freien und quelloffenen Lizenzen bereitgestellt werden, vom Anwendungsbereich aus — soweit sie nicht Hochrisiko-Systeme sind oder unter die Art. 5 und 50 fallen. Für Modelle mit allgemeinem Verwendungszweck gilt das in dieser Form nicht: Art. 53 Abs. 2 nimmt quelloffene Anbieter nur von zwei der vier Pflichten aus, und für Modelle mit systemischem Risiko entfällt die Ausnahme ganz. Einzelheiten im Eintrag zu den Art. 51, 52 und 55.

Vorgelagert bleibt die Frage, wer bei einer solchen Zusammensetzung Anbieter ist. Der Akteur verband ein fremdes Modell, ein fremdes Agentengerüst und einen fremden MCP-Server zu einem Ablauf, den er nicht in Verkehr gebracht hat. Ob dabei ein KI-System im Sinne der Verordnung entstanden ist und wen dessen Pflichten treffen würden, ist in diesem Eintrag nicht beantwortet.

Festzuhalten ist der Sachverhalt: Die Schutzmechanismen, an denen die Verordnung bei den Anbietern ansetzt, haben dort gewirkt, wo sie vorhanden waren — ein Anbieter hat Anfragen abgewiesen und ein Konto abgeschaltet, aus eigenem Antrieb und vor jedem Hinweis von außen. Der Angriff fand gleichwohl statt, über einen Weg, auf dem solche Mechanismen nicht bestanden.