Unit 42: Die autonome Angriffsschleife ist machbar, und jeder bestätigte Erfolg war manuell.

Am 30. Juli 2026 veröffentlichte Unit 42 von Palo Alto Networks eine Untersuchung zu einem chinesischsprachigen Operator, der ein Sprachmodell direkt in die Angriffsschleife einband: DeepSeek, das in Hermes Agent lief, einem Open-Source-Terminal-Agenten von Nous Research, und Anweisungen über Telegram entgegennahm. Der Operator unternahm Angriffe auf mehr als 460 Ziele und hielt Exploit-Tooling für sieben Schwachstellenbereiche vor, die sich über acht CVE-Kennungen erstreckten. Fast nichts, was die Maschine ohne menschliche Hilfe tat, führte zu einer Kompromittierung — beide autonomen Exploit-Versuche scheiterten an Voraussetzungen, die die Ziele bereits abgeschaltet hatten. Was ein Mensch steuerte, erzeugte dagegen Wirkung: Speicherdaten wurden aus drei Citrix-NetScaler-Bereitstellungen exfiltriert, Befehlsausführung auf elf Marimo-Notebook-Instanzen bestätigt und ein System der malaysischen Regierung über mehrere aufeinanderfolgende Tage hinweg angegriffen. In keinem der beiden zitierten Berichte wird ein Opfer genannt, und der gesamte Bericht wurde aus den eigenen exponierten Servern der Operatoren rekonstruiert.Der vollständige Datensatz mit der Schweregradbewertung des Archivs und den zitierten Quellen ist im Orca AI Incident Archive verzeichnet, zusammen mit den benachbarten Einträgen aus derselben Woche.

Wie die Operation in den Blick kam

Unit 42 hat diese Kampagne nicht erkannt. Der eigene Agent des Betreibers lieferte sie aus. Auf einen Telegram-Befehl hin startete Hermes Agent einen HTTP-Dateiserver — python3 -m http.server 8888 — aus dem Home-Verzeichnis des Akteurs unter /home/worker statt aus einem isolierten Staging-Verzeichnis. Ein Standardverhalten legte den Arbeitsbereich offen: KI-Tool-Konfigurationen, API-Schlüssel, Exploit-Skripte, Zielisten, Bash-Verlauf und die Protokolle der autonomen Hermes-Sitzungen, die Unit 42 später nutzen würde, um den Angriffszyklus Schritt für Schritt zu rekonstruieren.

Unit 42 beschreibt die Exponierung als unbeabsichtigt und hält fest, dass der Akteur an anderer Stelle nicht nachlässig war: Exploit-Verzeichnisse wurden nach der Nutzung geleert, und die Konversationsprotokollierung in Codex wurde deaktiviert, um die lokale Speicherung von Antworten zu begrenzen. Die AI Safety Initiative der Cloud Security Alliance, die dieselbe Offenlegung am 4. August 2026 analysierte, brachte den prägnanteren Punkt auf den Punkt: Der Betreiber praktizierte konventionelle Tradecraft, doch die Bequemlichkeits-Standardvoreinstellungen des Agenten-Frameworks machten dies in einem einzigen Schritt zunichte – und Angreifer, die Agenten-Frameworks übernehmen, erben deren Standardvoreinstellungen zusammen mit ihren Fähigkeiten.

Wer der Betreiber ist, nach den verfügbaren Beweisen

Unit 42 nennt den Akteur nur anhand seiner Handles: knaithe und KnYuan. Die Bewertung zu Zhuhai stützt sich auf GitHub-Aktivitäten, insbesondere auf die Wartung von 1DayNews durch den Akteur – einer automatisierten Pipeline für Schwachstellen-Intelligence, die Offenlegungen zu Remote-Code-Execution aus 17 Quellen zusammenführt, überwiegend von Herstellern von Netzwerkperimeter-Lösungen, DeepSeek nutzt, um sie nach Ausnutzbarkeit zu filtern, und Warnmeldungen über Telegram verbreitet. In einem Interview mit Infosecurity Magazine am 31. Juli 2026 beschrieb Andy Piazza, Senior Director of Threat Intelligence bei Unit 42, dieselbe Person als „einen opportunistischen Exploit-Operator und selbsternannten Binärsicherheitsforscher“.

Keiner der beiden zitierten Berichte behauptet eine staatliche Steuerung. Die Anmerkung von CSA stellt fest, dass die Offenlegung keine Hinweise auf staatliche Steuerung enthält, und bewertet Ressourcenausstattung und Umfang als vereinbar damit, dass eine einzelne Person einen offensiven Workflow aus einem handelsüblichen Reasoning-Modell und einem frei verfügbaren Agent-Framework zusammengestellt hat. Infosecurity Magazine berichtet, dass die Ziele der Kampagne sich über drei Länder erstreckten, darunter China und Malaysia.

Die autonome Hälfte: zwei Produkte, zwei Fehlschläge

Unit 42 konnte eine vollständige Hermes Agent-Sitzung vom Mai 2026 wiederherstellen und außer der Eröffnungsaufgabe keine Operator-Eingaben wiederherstellen. Was die Protokolle zeigen, ist ein Agent, der seine eigenen Ziele wählt und sie ohne Anweisung aufgibt.

Es begann mit Langflow und CVE-2026-33017, CVSS 9.8. Er lud den öffentlichen Proof of Concept von GitHub herunter, enumerierte über die chinesische Asset-Suchmaschine FOFA mit der Abfrage title="Langflow" 84 Langflow-Instanzen und fand eine, die einen anfälligen Build ausführte, 1.3.4. Der Versuch scheiterte, weil die Schwachstelle entweder aktiviertes auto_login oder eine öffentliche Flow-ID erfordert und das Ziel weder das eine noch das andere hatte. Das eigene Urteil des Agenten, zitiert im Bericht: „Alle drei Langflow benötigen eine öffentliche Flow-ID, aber kein auto_login – festgefahren. Deployments klein (84 aktiv), ausnutzbar wahrscheinlich 0. Suche nach Schwachstellen in größerem Maßstab.“

Dann tat es, worum sein Auftrag nicht gebeten hatte. Es erfasste auf FOFA die Deployment-Zahlen über zehn Produktfamilien hinweg, durchsuchte GitHub nach angesagten, nach Stars sortierten 2026-CVE-Proof-of-Concept-Repositories und bewertete Kandidaten nach Schweregrad, Footprint und Ausnutzbarkeit, bevor es sich auf n8n festlegte — im Log gerechtfertigt durch die 258 Stars und CVSS 10.0 des Proof of Concept. FOFA verortete n8n bei 647.017 Instanzen weltweit, davon 25.209 in China.

Die n8n-Kette bestand aus CVE-2026-21858, beliebigem Dateilesen mit CVSS 10,0, gepatcht in 1.121.0, sowie CVE-2025-68613, einer Sandbox-Umgehung zur Remote-Code-Ausführung mit CVSS 9,9, gepatcht in 1.120.4. Der Agent prüfte die Versionsbereiche selbst – „Laut CVE ist AFR in 1.121.0 und RCE in 1.120.4+ behoben. v1.117.3 ist also für beide anfällig!“ – und nahm dann eine Stichprobe von etwa 100 der 25.209 Adressen, prüfte etwa 40 davon und fand drei, auf denen anfällige Versionen liefen: 1.18.0, 1.117.3 und 1.108.2.

Alle drei scheiterten aus demselben Grund. Der Exploit benötigt ein nicht authentifiziertes Formular mit Datei-Upload, und die Formulare, die erreicht wurden, erforderten Authentifizierung. Der Agent sagte das im Log – „Diese Formulare haben Authentifizierung aktiviert. Ich prüfe andere Ziele“ – scannte über 50 weitere chinesische Ziele, fand keine öffentlich zugänglichen Formulare und hörte auf. Die wiederhergestellte Sitzung endet dort. Unit 42 verzeichnet überhaupt keine Ausnutzung aus dem autonomen Track.

Wo der Schaden tatsächlich angekommen ist

Jeder bestätigte Impact im Datensatz stammte aus dem manuellen Track, der mit konventionellen Workflows durchgeführt wurde: FOFA-Enumeration, eigene Python-Scanner und direkte Exploitation.

• Citrix NetScaler ADC and Gateway, CVE-2026-3055, CVSS 9.8 – aus drei Organisationen wurden Daten exfiltriert. Laut Unit 42 wurden bei den drei erfolgreichen Vorfällen Speicherdaten über den Out-of-Bounds-Read abgezogen, und der Akteur durchsuchte anschließend den gestohlenen Inhalt nach NetScaler-Authentifizierungscookies (NSC_AAAC=), was auf Session-Hijacking statt auf Diebstahl um seiner selbst willen hindeutet.

• Eine Regierungsstelle in Malaysia – über mehrere Tage hinweg beharrlich ins Visier genommen und ausgenutzt, mit dem, was Unit 42 als Memory-Grooming-Parameter und maximale Leseversuche bezeichnet, und bei späteren Besuchen zusätzlich mit Proxy-Anonymisierung. Dies ist das einzige Ziel, bei dem der Bericht eine Absicht über Opportunismus hinaus sieht.

• Marimo-Notebooks, CVE-2026-39987, CVSS 9,8 — Befehlsausführung auf 11 Instanzen bestätigt.

• Apache Tomcat, CVE-2026-34486, CVSS 7.5 — Reverse-Shell-Versuche gegen neun Server.

Windows-IKE-VPN, CVE-2026-33824, CVSS 9,8 — Reverse-Shell-Callbacks, die auf drei Endpunkte abzielen.

• PAN-OS User-ID Authentication Portal, CVE-2026-0300, CVSS 9.8 — ein öffentlich zugängliches Forschungs-Proof-of-Concept, das geklont, aber nie ausgeführt wurde. Unit 42 stellte fest, dass der Code nicht funktionsfähig ist und Platzhalterwerte enthält, die keine Ausführung ermöglichen.

Zwei Einschränkungen sind von Bedeutung. Die Opfer werden nicht genannt, daher sind die Identität der drei NetScaler-Betreiber und der malaysischen Behörde nicht öffentlich. Und Unit 42 gibt an, Beweise für die Massenausnutzung einer unbekannten Anzahl von Hosts geprüft zu haben, die in einer Datei aufgetaucht seien, die der Angreifer vor der Analyse gelöscht habe – wodurch die bestätigte Zahl eine Untergrenze und keine Gesamtzahl darstelle.

Was ist gesichert, und was wird behauptet?

Für einen Vorfall dieser Art ist die Funktionsweise ungewöhnlich gut belegt. Unit 42 liest die eigenen Konfigurationsdateien, Sitzungsprotokolle, Zielisten und die Bash-Historie des Operators; die CVE-Liste, die Anzahl der Ziele und die Fehlermodi stammen aus diesem Material und nicht aus Rückschlüssen auf den Netzwerkverkehr.

Die Zuschreibung ist vager. „Chinesischsprachig“, „mit Sitz in Zhuhai“ und die Handles knaithe und KnYuan sind Analysteneinschätzungen, die auf GitHub-Aktivitäten, einem älteren persönlichen Blog und der 1DayNews-Pipeline beruhen. Es liegen keine Anklagen, Sanktionen oder Regierungserklärungen dazu vor, und keiner der zitierten Berichte nennt eine betroffene Organisation.

Eine Behauptung über eine Durchsetzungsmaßnahme stammt innerhalb des Berichts selbst aus zweiter Hand. Unit 42 gibt weiter, dass OpenAI-Mitarbeiter bestätigt hätten, dass ihre anbieterseitigen Schutzmaßnahmen Anfragen abgelehnt hätten, die gegen die Richtlinien verstießen, und dass fortgesetzte Versuche dazu geführt hätten, dass ihre Sicherheitssysteme ein Konto markierten und deaktivierten, von dem sie glauben, dass es mit dieser Kampagne in Verbindung steht, bevor Unit 42 ihre Erkenntnisse mit ihnen teilte. Das ist ein Anbieter, der seine eigene Durchsetzung beschreibt; Unit 42 hat dies nicht unabhängig überprüft.

Eine Lücke sollte man klar benennen: Bis zum 30. Oktober 2026 sind bei den Recherchen für diesen Artikel keine Stellungnahme der malaysischen Regierung, von MyCERT oder anderen nationalen CERTs zu dieser Kampagne aufgetaucht. Hunt.io, die zweite für diesen Eintrag zitierte Quelle, gibt an, am 6. Juli 2026 die betroffenen Organisationen und die zuständigen nationalen CERTs benachrichtigt und die Veröffentlichung für ein siebentägiges Disclosure-Fenster zurückgehalten zu haben – doch eine Benachrichtigung ist keine öffentliche Darstellung.

Die beiden zitierten Berichte sind sich über Claude Code nicht einig.

Dieser Bericht zitiert zwei Herstelleruntersuchungen, die im Abstand von zwei Wochen veröffentlicht wurden, und sie beschreiben unterschiedliche Aufteilungen der eingesetzten Tools. Unit 42 ordnet in seinem Bericht vom 30. Juli die Ausführung Hermes Agent zu, mit DeepSeek als Reasoning-Engine, und behandelt Claude Code als Testlauf. Der rekonstruierte Verlauf umfasst zehn Einträge über drei Sitzungen mit /model-Prüfungen, Konnektivitätstests und einer npm-install-Anfrage, die zur Prüfung der Konnektivität und zur Proxy-Validierung dienten. Bei Codex gibt es Hinweise auf eine Nutzung in Exploit-Entwicklungsverzeichnissen, aber seine Chat-Protokolle wurden nicht aufbewahrt; Qwen Code erhielt zwei Sitzungen. Unit 42 deutet diese Streuung als einen Operator, der sich im gesamten KI-Markt umsieht, die westlichen Tools über einen Proxy unter code.newcli[.]com leitet, während er DeepSeek und Qwen direkt über deren native API-Endpunkte anspricht.

Hunt.io beschreibt in einem am 14. Juli aus einem offenen Verzeichnis, das es unter 112.213.124[.]132 auf Port 8888 fand, veröffentlichten Bericht die umgekehrte Anordnung: Claude Code 2.1.165 als Ausführungs-Engine über persistente Sitzungen zwischen dem 8. und 12. Juni 2026, wobei DeepSeek-v4-pro darunter die Denkarbeit übernahm, und eine wiederhergestellte CLAUDE.md-Datei, die Claude Code anwies, geklonte Phishing-Seiten zu erstellen, zu testen und iterativ zu verfeinern.

Beide Berichte beschreiben ein zurückgelassenes Agenten-Framework, das ein Verzeichnis auf Port 8888 bereitstellte. Sie beschreiben unterschiedliche Opfergruppen: Die von Hunt.io bestätigten Intrusionen fanden in Afghanistan, Thailand und Taiwan statt, wobei Phishing gegen zwei US-Regierungsbehörden vorbereitet wurde; die von Unit 42 bestätigten Opfer sind drei namentlich nicht genannte Citrix-Betreiber und eine malaysische Regierungseinrichtung, wobei sich die autonomen Sondierungen größtenteils gegen die inländische Infrastruktur Chinas richteten. Keiner der Berichte verweist auf den anderen, und weder das Archiv noch einer der Anbieter hat eine Abgleichung veröffentlicht. Zusammengenommen stützen sie eine Schlussfolgerung, nicht zwei: LLM-gesteuerte Intrusionsarbeit lief im Juni und Juli 2026 in der Umgebung dieses Betreibers. Welches Modell wo im Stack saß – und ob die beiden Berichte einen Betreiber oder zwei beschreiben – ist durch die veröffentlichte Aktenlage nicht geklärt.

Was hat sich danach geändert

Da die Offenlegung die Beweise zutage förderte, betrifft die konkreteste Veränderung den Akteur und nicht die Opfer. Unit 42 gibt an, die Ergebnisse mit Mitgliedern der Cyber Threat Alliance geteilt zu haben, und die entsprechende Seite trägt einen Aktualisierungsstempel vom 11. August 2026, zwölf Tage nach der Veröffentlichung. Für Palo-Alto-Kunden listet sie Cortex-Xpanse-Regeln zur Angriffsfläche für exponierte Langflow-, n8n- und Citrix-ADC-Appliances sowie eine Reihe von Threat-Prevention-Signaturen auf.

Bei den verwundbaren Produkten liegen die Korrekturen zeitlich vor der Kampagne. n8n lieferte 1.120.4 und 1.121.0 für die beiden Schwachstellen vor der rekonstruierten Sitzung aus, und der Agent las diese Versionsgrenzen selbst aus den Advisories ab. Die Mitteilung von CSA vom 4. August empfiehlt, dass NetScaler-Betreiber, die CVE-2026-3055 ausgesetzt sind, die Session-Authentifizierungs-Cookies NSC_AAAC rotieren und authentifizierte Sitzungen auf Anomalien überprüfen sollten, da der Akteur ausdrücklich auf dieses Cookie Jagd machte, und dass jeder mit vermuteter Exposition gegenüber der Marimo-Schwachstelle davon ausgehen sollte, dass eine Befehlsausführung bereits stattgefunden haben könnte.

Der Katalog der bekannten ausgenutzten Schwachstellen von CISA, direkt am 30. Oktober 2026 eingesehen, zeigt, wie öffentlich dieses Material war, bevor irgendetwas davon gemeldet wurde: CVE-2025-68613 wurde am 11. März 2026 aufgenommen, CVE-2026-33017 am 25. März, CVE-2026-3055 am 30. März, CVE-2026-39987 am 23. April und CVE-2026-0300 am 6. Mai — alle vor der Veröffentlichung durch Unit 42. CVE-2026-34486 folgte am 4. August und CVE-2026-33824 am 18. August. CVE-2026-21858, die n8n-Dateilesen-Hälfte der gescheiterten autonomen Kette, erscheint im Katalog überhaupt nicht.

Warum die Marge der entscheidende Befund ist

Die Schlussfolgerung von Unit 42 lautet nicht, dass die Kampagne erfolgreich war, sondern dass sie es beinahe gewesen wäre. Die Ausnutzung wurde durch die Konfiguration auf der Zielseite gestoppt – das fehlende auto_login, die authentifizierten Formulare – und der Bericht stellt fest, dass „Ziele mit schwächeren Standardkonfigurationen anfällig gewesen wären“. Seine Gesamtbewertung ist, dass autonome Angriffszyklen operativ machbar sind und dass die Fehlermarge gering war.

Die unabhängige Lesart von CSA weist aus einem anderen Blickwinkel auf dieselbe Asymmetrie hin: Autonome Aufklärung und Triage ließen sich weit leichter skalieren als autonome Ausnutzung, und die bestätigten, waffenfähig nutzbaren Ergebnisse hingen von menschlich gesteuerter Arbeit ab, die auf der Aufklärung des Agenten aufsetzte. Beide Lesarten betreffen eine Kampagne eines Betreibers. Die Aufzeichnung enthält keine Behauptung, dass eine autonome Schleife bereits ein System eigenständig kompromittiert habe.