GTIG AI Threat Tracker: von einem Prompt zu Tausenden von Zugangsdaten in sechs Stunden

Die Google Threat Intelligence Group hat die Q2-2026-Ausgabe ihres AI Threat Tracker am 8. September 2026 veröffentlicht. Der Fall, um den es in dem Bericht geht, lässt sich kurz und klar darstellen: Ein mutmaßlich finanziell motivierter Akteur griff auf eine Cloud-Ressource eines Opfers zu, gab einen Prompt und eine Reihe vorab verfasster Agent-Anweisungen in einen KI-Coding-Chatbot ein und hatte Tausende Zugangsdaten Dritter in weniger als sechs Stunden geerntet, wobei der Agent Schwachstellen-Scans, Fehlerbehebung und IP-Rotation selbstständig übernahm. Derselbe Bericht beschreibt trojanisierte MCP-Server auf PyPI, einen Credential Stealer, der die eigene Identität eines Build-Systems stiehlt, sodass seine mit Backdoor versehenen Pakete mit gültigen, kryptografisch signierten SLSA-Build-3-Attestierungen eintreffen, sowie adversarialen Text, der darauf abzielt, LLM-basierte Sicherheitsscanner dazu zu bringen, sich zu weigern, den darunterliegenden Code zu lesen. All das ist Googles Darstellung seiner eigenen Telemetrie. Dieser Bericht ist mit seiner Konfidenzstufe und seinen zitierten Quellen in dem AI-Incident-Archiv katalogisiert, das daneben jeden anderen dokumentierten Vorfall dieser Reihe enthält.

Keine der substanziellen Behauptungen wurde von einer Partei überprüft, die nicht Google wiedergibt. Help Net Security berichtete am Tag der Veröffentlichung über den Tracker, die Cloud Security Alliance veröffentlichte am folgenden Tag eine Forschungsnotiz, und Lineaje veröffentlichte am 17. September eine DUSTMAKER-Analyse; jede davon ist eine Zusammenfassung oder eine analytische Einordnung von Googles Offenlegung, und Lineaje sagt das selbst und merkt an, dass GTIG „mehrere verwandte DUSTMAKER-Fähigkeiten beschreibt statt einer einzigen beobachteten durchgängigen End-to-End-Ausführungsspur“. Die zweite zusammen mit diesem Datensatz zitierte Quelle, ein „Threat Pulse“-Eintrag von threatops.tech vom 11. September 2026, ist eine Wiederholung statt eines zweiten Zeugen: Sie fügt keine Berichterstattung hinzu, bestreitet keine Zahl und hebt die Schweregradbezeichnung an, ohne zu erklären, woran sie gemessen wird. Die Berichterstattung stimmt nicht einmal vollständig beim Namen der Ausgabe überein – Help Net Security nennt sie den Q3-2026-Tracker, datiert ihren Hauptfall aber auf Q2 2026 –, was ein Unterschied in der Nummerierung und kein faktischer Konflikt ist.

Das Archiv führt dies als Bericht statt als Vorfall: Vertrauensgrad A, nicht bestritten, keine quantifizierte Angabe zum tatsächlichen Schaden dazu verzeichnet. Diese Einstufung beschreibt die Qualität der Dokumentation, nicht das Ausmaß des Schadens. Google zählt Zugangsdaten, nicht Opfer. Der Tracker sagt nicht, wie viele Organisationen von der sechsstündigen Kampagne betroffen waren, wer sie waren, welcher Chatbot verwendet wurde oder ob einige der gestohlenen Zugangsdaten später verkauft oder verwendet wurden.

Die sechs Stunden, die GTIG beschreibt, und die drei Aufgaben, die der Agent allein erledigt hat

Die im Bericht beschriebene Abfolge reicht von der Zugangsbeschaffung bis zum Ergebnis, wobei dazwischen nur sehr wenig menschliche Beteiligung stattfindet. Der Akteur kompromittierte eine Cloud-Ressource und nutzte dann einen kommerziellen KI-Coding-Chatbot zusammen mit dem, was GTIG als „einen Prompt“ und „eine Reihe von Agentenanweisungen“ bezeichnet – die Markdown-Playbooks, die heute als AGENTS.md-Dateien in Repositories liegen –, um die Operation zu planen, aufzubauen und durchzuführen. Googles eigene Bezeichnung für das Ergebnis ist eine „agentengestützte Massenkampagne zum Erbeuten von Zugangsdaten“, die „in weniger als sechs Stunden“ abgeschlossen wurde.

Drei Aufgaben werden als autonom beschrieben, und es sind die drei, die andernfalls die Aufmerksamkeit eines Bedieners in Anspruch genommen hätten:

• Die Pipeline für die Schwachstellenüberprüfung, die die Agentenanweisungen die KI „autonom verwalten“ lassen – in der Formulierung, die Help Net Security von GTIG zitiert.

• Echtzeit-Fehlerbehebung für alles, was der Scan zutage förderte, damit ein Fehler den Lauf nicht blockierte, während auf eine Entscheidung gewartet wurde.

• IP-Rotation, sodass aufeinanderfolgende Versuche von unterschiedlichen Adressen ausgingen, ohne dass jemand den Befehl erteilte.

Wo die Operation lief, ist ebenso wichtig wie ihre Geschwindigkeit. Indem der Akteur aus der eigenen Cloud-Infrastruktur des Opfers heraus agierte, leitete er den Datenverkehr über die legitimen IP-Adressbereiche des Opfers. Anfragen, die so aussehen, als kämen sie aus dem Inneren einer Organisation, sind genau diejenigen, die reputationsbasierte Abwehrsysteme am wenigsten hinterfragen können, und der Bericht vermerkt dies als Folge des Agierens aus der eigenen Umgebung des Opfers.

Was der Bericht nicht enthält, ist ebenso aussagekräftig wie das, was er enthält. Es gibt keine Zeitmessung pro Schritt, daher ist „unter sechs Stunden“ eine einzige Messung des gesamten Ablaufs und lässt sich nicht in ein Diagramm zerlegen. Es gibt keinen Namen für den Akteur außer „vermutlich finanziell motiviert“, kein Opfer und keine Angabe, welches Modell oder der Chatbot welches Anbieters beteiligt war. Der Tracker behandelt den Fall als durchgearbeitetes Beispiel eines Trends, und er ist auf einer Flughöhe geschrieben, die diesem Zweck dient, statt auf der Flughöhe, die sich ein Incident-Responder wünschen würde.

Ein exponierter Server, der sich zu einem Dashboard mit 23.800 Geheimnissen entwickelte

Ein zweiter Befund im selben Abschnitt ist konkreter und ein separater Fall. GTIG fand einen offen zugänglichen Command-and-Control-Server, auf dem ein automatisiertes Framework für Aufklärung und Credential-Management lief, das sie Recon nennen. Das Verzeichnislisting war lesbar und gab sein Design preis: AGENTS.md, KNOWLEDGE.md, agentic_vuln_research.md, dazu ein modulares Verzeichnis .openclaw/ und ein Verzeichnis memory/. Diese Dateinamen sind der Fingerabdruck eines Agent-Stacks und nicht eines maßgeschneiderten Implantats – Anweisungen, angesammeltes Wissen und ein Forschungsplan, alles auf der Festplatte, wo die Tools des Betreibers sie lesen können.

Dasselbe Verzeichnis diente später als Live-Frontend-Dashboard zum Organisieren und Validieren von mehr als 23.800 erbeuteten Secrets, darunter API-Schlüssel für Cloud- und KI-Dienste. GTIG charakterisiert die damit verbundene Verschiebung als einen Wandel „von passiven, endpoint-fokussierten Infostealern zu offensivem agentischem Harvesting“ – das heißt von Malware, die von einem einzelnen Laptop abgreift, was sie kann, hin zu Tools, die die bereits erreichten Ziele weiter bearbeiten.

Zu dieser Zahl gehören zwei Einschränkungen. 23.800 ist eine Zahl von Secrets, nicht von Personen oder Unternehmen, und der Bericht rechnet das eine nicht in das andere um. Und GTIG gibt nicht an, ob es sich beim Recon-Server und der sechsstündigen Kampagne um dieselbe Operation handelt; sie werden im selben Abschnitt als getrennte Beobachtungen dargestellt, sodass es eine Schlussfolgerung wäre, sie als einen einzigen Handlungsstrang zu behandeln, die der Bericht nicht zieht.

DUSTMAKER und die Bescheinigung, die korrekt besagt, dass das Paket echt ist

Die Lieferketten-Hälfte des Trackers betrifft UNC6780, das Google ebenfalls als TeamPCPführt – eine finanziell motivierte Gruppe, die seit März 2026 Open-Source-Infrastruktur bei PyPI, npm und Docker Hub kompromittiert. Ihre Vorgehensweise beim KI-Tooling ist direkt: Kompromittierte Entwicklerkonten wurden genutzt, um trojanisierte Forks legitimer MCP-Server zu veröffentlichen, wobei tiktoken_mcp als Beispiel auf PyPI genannt wird, und bösartiger Code wurde in offizielle Organisations-Repositories eingeschleust, darunter azure-functions-mcp-extension. GTIG merkt an, dass Payloads und bösartige Workspace-Hooks dann automatisch aufgenommen wurden, sobald die Assets heruntergeladen oder geklont wurden – kein separates Ködern, kein zweiter Schritt.

Der dazugehörige Credential-Stealer, DUSTMAKER, ist die Stelle, an der der nützlichste technische Punkt des Berichts steckt. Die Kette ist kurz. Der Stealer erkennt, dass er in einer CI/CD-Umgebung läuft; GTIG schreibt, dass er „falls bestätigt“ OIDC-Tokens aus dem Prozessspeicher eines GitHub-Actions-Runners extrahiert. Er nutzt diese Tokens, um sich selbst als vertrauenswürdigen Publisher zu autorisieren. Anschließend veröffentlicht er kompromittierte Paketversionen mit gültigen, kryptografisch signierten SLSA-Build-3-Attestierungen. Nichts an dieser Kette ist gefälscht. Die Attestierung ist echt, ausgestellt auf eine echte Identität, für einen Build, der wirklich stattgefunden hat – von Code, den der Angreifer geschrieben hat. GTIGs Fazit ist der Satz, der für alle relevant ist, die sich auf Provenienz verlassen: „Mit gültigen Tokens veröffentlichte Pakete bestehen die automatisierten Vertrauensprüfungen durch KI-Coding-Agenten.“

Der Rest von DUSTMAKERs Verhalten zielt auf Orte, die Verteidiger nicht beobachten. Es legt Dateien in Arbeitsbereichsverzeichnissen von KI-Codierungsassistenten und IDEs ab und verändert sie — .claude/, .vscode/, .cursor/ — wo es im Entwicklerrauschen untergeht und Orte meidet, die Endpoint Detection tatsächlich überwacht, etwa Windows-Registrierungsschlüssel oder /etc/cron.*. Es schreibt Konfigurationen, die die IDE oder KI-Erweiterung dazu bringen, beim Öffnen des Arbeitsbereichs ein Skript wie setup.mjs auszuführen, wodurch das Öffnen eines Ordners zur Codeausführung wird. Es erstellt Pipeline-Aufgaben mit KI-bezogenen Namen wie "Copilot Setup", um nach Tokens zu suchen, und sendet API-Aufrufe, um Ausführungsprotokolle von Workflows zu löschen, damit der Lauf nicht in der GitHub-Oberfläche erscheint.

Die Malware, die den Scanner bittet, wegzusehen.

Der letzte Mechanismus ist der am wenigsten verifizierte der drei. DUSTMAKERs JavaScript-Loader-Skripte beginnen mit adversarialem Prompt-Text, eingebettet als Kommentare – in _index.js unter anderem –, der biologische und nukleare Waffen erwähnt und eine Anfrage nach einer Spezifikation für eine 20-Kilotonnen-Spaltungsvorrichtung vom Implosionstyp enthält. Die Einschätzung von GTIG lautet, dass dies „wahrscheinlich dazu gedacht war, dass LLM-Sicherheitsscanner aufgrund von Sicherheits- oder Richtlinienverweigerungen scheitern oder die Analyse des darunterliegenden bösartigen JavaScript-Codes überspringen“.

Das Label an diesem Satz ist entscheidend. Es ist eine Aussage über die Absicht, abgeleitet aus dem Text, den der Loader mitführt, nicht der Nachweis, dass irgendein Scanner die Datei tatsächlich abgelehnt hat. Der Bericht nennt keinen Scanner, der die Datei übersprungen hat, berichtet nicht über eine Umgehungsrate und sagt nicht, dass die Technik funktioniert hat. Belegt ist, dass jemand den Köder geschrieben und in einem Credential Stealer ausgeliefert hat – was selbst ein Beweis dafür ist, dass die Angreifer erwarten, dass LLM-basierte Triage im Pfad liegt.

UNC6508, MIDNIGHT NEPTUNE und CALANQUE ION stehen im selben Bericht.

Das staatlich verknüpfte Material des Trackers ist umfangreicher als sein kriminelles Material und größtenteils weniger automatisiert. UNC6508, eine Gruppe mit Verbindungen zur VR China, führt seit mehreren Jahren eine Spionagekampagne gegen nordamerikanische akademische, medizinische und militärische Forschung durch und zielt nun gezielt auf proprietäre KI-Forschung ab; GTIG vermutet, dass die Gruppe Cloud-Umgebungen kompromittiert, um lokale Open-Weight-Modelle einzusetzen, was die Überwachung kommerzieller APIs umgeht und die Rechenleistung des Opfers nutzbar macht.

Andernorts ist das Muster: Standardmodelle, die gewöhnliche Arbeit im großen Maßstab erledigen. Nordkoreas MIDNIGHT NEPTUNE, früher UNC1069, nutzte DeepSeek-Coder, um Python-Remote-Access-Trojaner mit plattformübergreifender Persistenz und Prozessinjektion zu schreiben, nutzte LLMs für Bash-Skripte zur lateralen Bewegung, betrieb Social-Engineering-Personas und technische Lures, vergiftete interne Repository-Konfigurationen, veränderte Claude CLI-Hooks und installierte die SOMBERMEME-Backdoor, als ein Entwickler mit dem Repository interagierte. Irans CALANQUE ION, früher APT42, nutzte Modelle, um Ziel-E-Mail-Adressen zu identifizieren, OSINT zu betreiben, Lures zu lokalisieren, exfiltrierte Daten zusammenzufassen und Reverse Engineering von Lizenzierungscode zu versuchen. PRC-nexus BASIN CASTLE nutzte Gemini für Zielprofiling, die Übersetzung chinesischen Materials in formelle englischsprachige politische Berichterstattung und PowerShell-Fehlerbehebung; RAVINE CASTLE untersuchte damit VMware vCenter SAML-Bypasses und Active-Directory-Post-Exploitation; die russische Gruppierung SANDWORM RELIC ließ Gemini ihren Code für Password-Spraying schreiben. Die finanziell motivierte Gruppierung UNC6240, auch als ShinyHunters geführt, nutzte Claude Code Prompts, um obfuskierten Code zu schreiben, Cloudflare zu umgehen und exfiltrierte Verzeichnisse über benutzerdefinierte MCP-Tools zu parsen.

Ein Fall in diesem Abschnitt geht einen Schritt weiter als die übrigen. Eine Gruppe mit Verbindungen zur VR China nutzte Gemini, um ein dynamisches automatisiertes Penetrationstest-Framework zu entwerfen, das den Zustand eines Ziels beobachten, darüber nachdenken sollte, was als Nächstes zu tun ist, und Portscans sowie Service-Parsing durchführen sollte. Google gibt an, es habe umfassendere Maßnahmen gegen die identifizierten Kampagnen ergriffen und dabei zugehörige Assets, Projekte und Konten deaktiviert. Unabhängig davon hat Google im Juni 2026 „Outsider Enterprise“ gestört, einen in China ansässigen Cybercrime-Dienst, der Phishing-Kits lieferte, und dies als das erste Mal beschrieben, dass das Unternehmen wegen Missbrauchs von Gemini rechtliche Schritte eingeleitet habe. Das sind zwei getrennte Aussagen, und eine Zusammenfassung, die sie zusammenführt, würde mehr aussagen, als der Bericht tut: Das Pentest-Framework gehört zur Formulierung der Deaktivierung von Assets, die rechtlichen Schritte gehören zu Outsider Enterprise.

LLMJacking – und was ein gestohlenes KI-Konto heute kostet

Der Tracker bepreist außerdem den Markt für gestohlenen KI-Zugang. Die Nachfrage im Untergrund konzentrierte sich auf Claude- und Gemini-Zugangsdaten sowie auf die autonomen Coding-IDEs Cursor Pro und Devin – Letzteres von Cognition –, und die durchschnittlichen Marktplatzpreise pro Konto haben sich im Laufe des Jahres 2026 mehr als verdoppelt. Die Infostealer, die die Sammlung übernehmen – LUMMAC.V2, STEALC.V2, VIDAR und ACRSTEALER –, wurden aktualisiert, um auf KI-Entwicklerkonfigurationen abzuzielen. Im Mai 2026 verteilten die Betreiber von ACRSTEALER File-Grabber-Regeln für Clines secrets.json und Continue AIs config.yaml, die beide Klartext-API-Schlüssel und benutzerdefinierte Endpunkte für das Modell-Routing enthalten können.

Ein von GTIG beschriebener Eindringfall zeigt, was ein KI-Konto wert ist, sobald es übernommen wurde. Im April 2026 genügte ein offengelegtes persönliches GitHub-Zugriffstoken (Personal Access Token), um Gemini Enterprise zu aktivieren, Hochleistungs-Rechenkapazität bereitzustellen, Docker-Repositories für ein LiteLLM-API-Deployment und das Manus-Agenten-Framework zu erstellen und Cloud-Run-Dienste aufzusetzen, die allUsers über eine IAM-Invoker-Bindung ausgesetzt waren. Dieselbe Sitzung erstellte ein unbefugtes Dienstkonto mit Editor-Rechten und exportierte dessen Schlüssel, fragte BigQuery nach Umgebungsvariablen und Zugangsdaten ab, versuchte, die Projektinhaberschaft an eine externe Adresse zu übertragen, und nutzte die Cloud Quotas API, um NVIDIA RTX 6000-Kapazität und zusätzliche 48-vCPU-Instanzen anzufordern.

Das Bild der Modell-Extraktion zeigt dieselbe Ökonomie in größerem Maßstab. GTIG sagt, Destillationskampagnen fänden inzwischen regelmäßig statt, „manche mit mehr als 100 Millionen Prompts“, wobei Abfragen über Tausende kompromittierte und betrügerische Konten rotiert und über Proxy-Infrastruktur geleitet würden, und dass Google Gegenmaßnahmen eingesetzt habe, die die Leistung eines Studentenmodells beeinträchtigen können, sowie Methoden zur Identifizierung Gemini-destillierter Modelle anhand ihrer Provenienz.

Was feststeht, was Einschätzung ist und was GTIG nach eigenen Angaben nicht gesehen hat

Belegt ist dies insofern, als Google seine eigene First-Party-Telemetrie und seine eigenen Kontoaktionen beschreibt: den Bericht und sein Datum; die Artefakte, die es nach eigenen Angaben beobachtet hat, einschließlich der Paketnamen, der Dateinamen des Loaders, der Verzeichnisnamen und des Dashboards mit 23.800 Secrets; und die Maßnahmen zur Unterbrechung, die Google nach eigenen Angaben ergriffen hat und die es bezeugen kann, weil das Deaktivieren eines Kontos etwas ist, das es tut, und nicht etwas, das es lediglich ableitet. Help Net Security, die Cloud Security Alliance und Lineaje berichten alle über diese Punkte ohne Widerspruch, obwohl keines von ihnen eigene unabhängige Belege beibringt.

Bewertung, in dem Sinne, dass es ein Urteil ist, das Google fällt: jede Zuordnung zu einem Nationalstaat im Bericht; die Deutung des Ablehnungsköders als absichtlich; und die Behauptung, dass gestohlene Token „automatisierte Vertrauensprüfungen von KI-Coding-Agenten“ bestehen würden, was eine Aussage darüber ist, wie diese Prüfungen üblicherweise aufgebaut sind, statt eine Messung, bei der ein bestimmtes Produkt an einer solchen scheitert.

Nicht geklärt: die Identität des sechs Stunden lang aktiven Akteurs, die Opfer und ihre Anzahl, der beteiligte Chatbot und das Modell sowie ob der Recon-Server überhaupt mit dieser Kampagne verbunden ist.

Und die Obergrenze des Berichts selbst liegt niedriger, als sein Titel nahelegt. GTIG erklärt, dass es bisherkeine vollständig autonomen Exploit-Pipelines in freier Wildbahn beobachtethat, und bewertet, dass die gegnerische Nutzung „sich auf diesen Anwendungsfall zubewegen könnte“. Die Trennung verläuft innerhalb des Angriffs und nicht um ihn herum: Menschen liefern das Ziel, den Prompt und die Instruktionsdatei; der Agent liefert das Scannen, die Fehlerbehebung und die Rotation und hält nicht an, um eine Erlaubnis einzuholen. Bei sorgfältiger Lektüre ist die sechsstündige Kampagne kein Beleg dafür, dass die Autonomie angekommen ist. Sie ist ein Beleg dafür, dass der menschliche Anteil der Arbeit auf den Teil zusammenschrumpfte, der einen Menschen erfordert – die Entscheidung, was zu tun ist –, während alles zwischen Entscheidung und Ergebnis von selbst ablief.

Was Google eigenen Angaben zufolge geändert hat – und auf welche Kontrolle der Bericht tatsächlich verweist

Die von Google dargelegte Reaktion verläuft auf zwei Gleisen. Zum Missbrauch heißt es, die Aktivitäten hätten „die Sicherheitsreaktionen von Gemini ausgelöst“, Google habe „zusätzliche, breitere Maßnahmen“ gegen die Kampagnen ergriffen, aufgrund der operativen Sicherheitslücken der Akteure, zugehörige Assets, Projekte und Konten deaktiviert, und Google DeepMind habe die Erkenntnisse genutzt, um seine Klassifikatoren und das Modell selbst zu stärken, sodass es diese Anfragen ablehnt. Auf Verteidigungsseite hat das Unternehmen Google AI Threat Defense, das Gemini- und Frontier-Modelle mit Wiz-Risikopriorisierung, Gemini- und CodeMender-Behebung sowie Mandiant-Intelligence kombiniert, wobei leichtere Modelle für kontinuierliches Scannen und Frontier-Modelle für Hochrisikofunde eingesetzt werden; außerdem lancierte es Gemini 3.8 Flash Cyber für Schwachstellenerkennung und automatisierte Patch-Erstellung und veröffentlichte Open-Source-Leitlinien zur Härtung der Lieferkette.

Die konkrete Korrektur, die der DUSTMAKER-Fall erfordert, ist enger gefasst als dieser Stack, und externe Analysen kommen darin überein. Eine SLSA-Attestierung beantwortet, ob ein Paket von der Identität gebaut wurde, die es angibt. Sie beantwortet nicht, ob diese Identität noch zu der Partei gehört, der Sie vertrauen wollten, und die gesamte Methode von DUSTMAKER besteht darin, eine Identität zu leihen statt sie zu fälschen. Lineajes Zusammenfassung des zugrunde liegenden Wandels ist die klarste Formulierung dafür: „Repository-Inhalte werden zur Ausführungsautorität.“ Paketnamen, MCP-Servernamen, Attestierungs-Badges und Anweisungsdateien in einem Repository treten nun alle mit einem gewissen Anspruch auf, befolgt zu werden, und das gestohlene OIDC-Token ist das, was den Anspruch verifiziert erscheinen lässt.