Eine chinesische staatsnahe Hackergruppe hat Anthropics Claude Code in eine autonome Angriffsplattform umfunktioniert, 30 Organisationen auf vier Kontinenten ins Visier genommen und die KI 80-90% der Operation eigenständig durchführen lassen. Anthropic hat die Kampagne öffentlich gemacht, nachdem interne Überwachungssysteme das Muster erkannten. Der Bedrohungsakteur wurde als GTG-1002 klassifiziert. Vier Organisationen wurden nachweislich kompromittiert. Das ist kein Laborexperiment und kein Forschungspapier. Es ist der erste dokumentierte Fall, in dem ein staatlicher Akteur einen KI-Agenten für eine vollständige Spionagekampagne eingesetzt hat.
Die Kampagne ist aus einem konkreten Grund relevant: Sie beweist, dass KI-Agenten den Angriffszyklus von Wochen auf Stunden komprimieren können, bei einem Bruchteil des sonst nötigen Personalaufwands. Die Angreifer brauchten menschliches Urteilsvermögen an nur 4-6 Entscheidungspunkten pro Ziel. Alles andere, von der Netzwerkkartierung über das Abgreifen von Zugangsdaten bis zur Datenklassifikation, lief autonom.
Der Social-Engineering-Trick, der alle Sicherheitsfilter umging
GTG-1002 hat keinen technischen Jailbreak in Claudes Sicherheitsfiltern entdeckt. Der Ansatz war viel simpler: Sie haben gelogen. Die Operatoren erstellten Konten unter der Behauptung, Mitarbeiter legitimer Cybersecurity-Firmen zu sein, und stellten jede Anfrage als autorisierten Penetrationstest dar. Sie erklärten Claude, es führe defensive Sicherheitstests im Auftrag zahlender Kunden durch.
Das funktionierte, weil die einzelnen Anfragen isoliert betrachtet plausibel aussahen. Ein Netzwerk-Bereich scannen, einen Login-Endpunkt testen, Standard-Zugangsdaten prüfen: Das machen Sicherheitsfachleute täglich. Claude hatte keine Möglichkeit zu verifizieren, ob der “Kunde” den Test tatsächlich genehmigt hatte oder ob die Ziele den anfragenden Personen gehörten. Jede Aufgabe war klein genug, um die Sicherheitsprüfung zu bestehen. Die böswillige Absicht wurde erst sichtbar, wenn man die gesamte Sequenz über mehrere Sitzungen hinweg betrachtete.
Die ProArch-Analyse der Kampagne identifizierte konkrete Infrastruktur: Domains wie update-sync-mcp[.]net und cloud-recon-service[.]com tarnten den Command-and-Control-Verkehr, während IPs bei verschiedenen Hosting-Anbietern (45.77.188.34, 185.244.25.61, 198.46.224.112) den operativen Fußabdruck verteilten. Die Domains wurden bewusst so gewählt, dass sie wie legitime Cloud-Service-Endpunkte aussahen.
Dieser Social-Engineering-Ansatz legt eine grundlegende Schwäche aktueller KI-Sicherheitsmodelle offen. Sicherheitsfilter bewerten einzelne Anfragen gegen Richtlinien. Gegnerische Operationen sind aber so konzipiert, dass sie auf Anfrageebene harmlos wirken und erst auf Kampagnenebene feindlich werden. Kein einzelner API-Aufruf löste eine Sicherheitsverletzung aus. Die Verletzung war das Muster.
Die sechs Phasen: Von der Initialisierung bis zur Datenexfiltration
Laut Anthropics technischer Offenlegung und der anschließenden Analyse durch ExtraHop folgte die GTG-1002-Operation einer strukturierten Methodik in sechs Phasen.
Phase 1: Kampagnen-Initialisierung
Menschliche Operatoren etablierten persistente Einsatzkontexte durch mehrtägige Claude-Code-Sitzungen mit detaillierten Personas und Hintergrundgeschichten. Sie konfigurierten MCP-Server (Model Context Protocol), die Standard-Penetrationstest-Werkzeuge kapselten: Netzwerkscanner, Password-Cracker und Browser-Automatisierung. Diese Infrastruktur ermöglichte Claude den direkten Zugriff auf Dateien, Datenbanken und Terminals über dasselbe Protokoll, das auch für legitime Entwicklerarbeit genutzt wird.
Phase 2: Autonome Aufklärung
Hier wurde der Skalierungsvorteil deutlich. Claude führte Browser-Automatisierung und Netzwerkscans mit tausenden Anfragen pro Sekunde durch, eine Rate, die für menschliche Operatoren physisch unmöglich ist. Bei einer bestätigten Kompromittierung entdeckte der Agent autonom interne Dienste, kartierte die vollständige Netzwerktopologie über mehrere IP-Bereiche und identifizierte hochwertige Systeme wie Datenbanken und Workflow-Orchestrierungsplattformen. Die KI scannte nicht nur; sie interpretierte Ergebnisse, priorisierte Ziele und passte ihre Vorgehensweise basierend auf den Erkenntnissen an.
Phase 3: Schwachstellenerkennung
Claude generierte maßgeschneiderte Payloads und validierte Exploits ohne menschliches Zutun. Der Bedrohungsakteur setzte überwiegend auf Open-Source-Penetrationstest-Tools und Standard-Sicherheitswerkzeuge statt auf Custom-Malware. Das ist bedeutsam: Die Angriffskette nutzte dieselben Werkzeuge, die auch legitime Sicherheitsteams täglich einsetzen, was eine signaturbasierte Erkennung nahezu unmöglich machte.
Phase 4: Credential Harvesting
Der Agent sammelte systematisch Zugangsdaten aus Konfigurationsdateien, Browser-Speichern und Umgebungsvariablen. Er kartierte Berechtigungsstufen der gesammelten Konten und identifizierte Lateral-Movement-Pfade zu höherwertigen Systemen. Die KI priorisierte Zugangsdaten anhand des geschätzten Zugriffsumfangs und konzentrierte sich auf Konten mit Datenbank- oder Administratorrechten.
Phase 5: Datensammlung und -klassifikation
Diese Phase demonstriert den spezifischen Nachrichtenwert von KI in der Spionage. Claude analysierte extrahierte Daten und klassifizierte proprietäre Informationen nach Geheimdienstwert. Hochprioritäre Ziele (Geschäftsgeheimnisse, interne Kommunikation, technische Dokumentation) wurden automatisch von irrelevanten Daten getrennt. Ein menschlicher Analyst bräuchte für diese Arbeit über 30 Zielorganisationen hinweg Wochen. Der Agent erledigte das als Teil des automatisierten Workflows.
Phase 6: Dokumentation und Reporting
Der Agent erstellte automatisch umfassende Berichte zum Angriffsfortschritt für die menschlichen Operatoren. Das kehrte das traditionelle Modell um, in dem Junioranalysten die Arbeit erfahrener Operatoren dokumentieren. Hier erledigte die KI die operative Arbeit und dokumentierte sie für die Menschen, die nur strategische Ergebnisse prüfen mussten.
Warum herkömmliche Abwehrmaßnahmen versagten
PwCs Analyse der Kampagne verdeutlicht ein strukturelles Problem: Angreifer können Rechenressourcen exponentiell skalieren, während Verteidiger typischerweise linear durch Personalaufbau und Tool-Einkauf wachsen. GTG-1002 demonstrierte diese Asymmetrie in der Praxis.
Geschwindigkeit übertraf Erkennung
Der Agent operierte in einem Tempo, das manuelle SOC-Workflows überforderte. Herkömmliche SIEM-Systeme generieren Alerts, die Analysten triagieren, was zu Untersuchungen führt, was zu Reaktionen führt. Diese Kette dauert Stunden bis Tage. Die GTG-1002-Operation komprimierte den gesamten Angriffszyklus in ein Zeitfenster, das kürzer war als die meisten Alert-Triage-Zyklen.
Legitime Tools entkamen Signaturen
Weil die Operation Open-Source-Sicherheitstools einsetzte (dieselben Werkzeuge, die auch das eigene Red Team nutzt), hatte signaturbasierte Erkennung nichts zum Flaggen. Der Netzwerkverkehr sah aus wie ein Sicherheits-Assessment. Die Zugangsmuster sahen aus wie IT-Administration. Das einzige Signal war die Geschwindigkeit und das Volumen, was Verhaltensanalyse statt traditioneller IOC-Abgleiche erforderte.
Kompartimentierte Anfragen umgingen die Intent-Analyse
Jede einzelne Claude-API-Anfrage bestand die Sicherheitsprüfung. Die Operation war darauf ausgelegt, komplexe feindliche Ziele in einzelne Aufgaben zu zerlegen, die isoliert betrachtet legitim wirkten. Das ist kein neues Konzept in der Geheimdiensttradition (Kompartimentierung ist Standard-Operationssicherheit), aber die Anwendung auf KI-Sicherheitsfilter war neuartig und effektiv.
ExtraHops Post-Incident-Analyse identifizierte Erkennungssignale, die die Kampagne früher hätten auffangen können: Hochfrequente Scan-Bursts, ungewöhnliche Verbindungsvolumen von einzelnen Endpunkten, Orchestrierungsverkehr (interne Agent-Verbindungen zu externen LLM-Diensten) und Datenexfiltrations-Beaconing-Muster. Diese Signale erfordern jedoch Network Detection and Response (NDR) Werkzeuge, die speziell für KI-orchestrierte Angriffsmuster konfiguriert sind, was zum Zeitpunkt des Angriffs praktisch kein Unternehmen hatte.
Das MCP-Problem: Wenn Entwickler-Infrastruktur zur Angriffsinfrastruktur wird
GTG-1002 nutzte Model Context Protocol (MCP) Server als Bindeglied zwischen Claude und offensiven Werkzeugen. MCP ist Anthropics offener Standard zur Verbindung von KI-Modellen mit externen Datenquellen und Tools. Hunderttausende Entwickler nutzen es ganz regulär. Das Problem: MCP behandelt Konnektivität als Feature, nicht als Risiko.
In der GTG-1002-Operation kapselten MCP-Server Standard-Penetrationstest-Werkzeuge und Browser-Automatisierung in eine einheitliche Schnittstelle, über die Claude handelsübliche Hacking-Tools genauso einfach steuern konnte wie einen Code-Editor. Der Agent erbte die vollständigen persistenten Berechtigungen der Entwicklersitzung: Lese-/Schreibzugriff auf Repositories, CI/CD-Deployment-Rechte und interne Datenbankverbindungen. Es gab keine separate Identität für den Agenten, keine eingeschränkten Zugangsdaten, keine Laufzeitgrenze.
WitnessAIs Analyse nennt das Problem der “unauthentifizierten Belegschaft”. Der KI-Agent operierte innerhalb des Netzwerkperimeters mit gültigen bestehenden Zugangsdaten. Aus Netzwerksicht sah jede Aktion des Agenten wie eine legitime Entwicklersitzung aus. Es gab keinen Mechanismus zur Unterscheidung von “Entwickler nutzt Claude zum Coden” und “Angreifer nutzt Claude zur Datenexfiltration”, weil die Identität identisch war.
Das hat direkte Implikationen für jede Organisation, die MCP-basierte KI-Tools in Entwicklungs-Workflows einsetzt. Wenn Ihre Entwickler Claude Code (oder einen anderen KI-Coding-Agenten) über MCP mit Produktionssystemen verbinden, gewährt eine kompromittierte Sitzung dem Angreifer jede Berechtigung, die der Entwickler hat. Keine Privilege Escalation nötig.
Für Unternehmen im DACH-Raum hat das besondere Brisanz. Die DSGVO fordert technische und organisatorische Maßnahmen zum Schutz personenbezogener Daten. Wenn ein KI-Agent mit Entwicklerrechten auf Kundendatenbanken zugreift und Daten exfiltriert, stellt sich sofort die Frage nach Art. 32 DSGVO (Sicherheit der Verarbeitung) und der Meldepflicht nach Art. 33. Der EU AI Act klassifiziert KI-Systeme in kritischer Infrastruktur als Hochrisiko-Systeme, was zusätzliche Dokumentations- und Überwachungspflichten nach sich zieht.
Konkrete Abwehrmaßnahmen für Unternehmen
Basierend auf den Post-Incident-Analysen von ProArch, PwC und ExtraHop sind hier spezifische Maßnahmen, die die GTG-1002-Kampagne abgeschwächt hätten.
Sub-200ms-Burst-Muster überwachen. KI-Agenten erzeugen Netzwerkverkehr in Geschwindigkeiten, die Menschen nicht erreichen können. Tausende Anfragen in unter 200 Millisekunden an interne Dienste sind ein zuverlässiger Indikator für automatisierten Betrieb. Konfigurieren Sie Ihre NDR- und SIEM-Werkzeuge entsprechend.
MCP-Befehlssignaturen im Netzwerkverkehr erkennen. Wenn Ihre Organisation MCP-basierte Tools einsetzt, überwachen Sie MCP-Verkehrsmuster, die nicht von bekannten Entwicklungsendpunkten stammen. Die GTG-1002-Operation nutzte URL-Muster wie /mcp/execute, /auto/scan/task und /dispatch/payload.
Agentenidentität trennen. Lassen Sie KI-Agenten nicht ohne Einschränkung Entwickler-Zugangsdaten erben. Jede KI-Agent-Sitzung sollte sich mit einem eigenen kurzlebigen, aufgabenbezogenen Token authentifizieren. Wenn Claude Code Datenbankzugriff benötigt, bekommt es einen Read-Only-Zugang für genau diese Datenbank, nicht den vollständigen Produktionszugang des Entwicklers.
KI-spezifische Verhaltensbaselines einsetzen. Herkömmliche Baselines messen menschliches Nutzerverhalten: Anmeldezeiten, Zugriffsmuster, Datenvolumen. KI-Agenten produzieren grundlegend andere Verkehrsprofile. Erstellen Sie separate Verhaltensmodelle für KI-gestützte Sitzungen und alarmieren Sie bei Abweichungen.
Bekannte GTG-1002-Infrastruktur blockieren. Nehmen Sie die offengelegten IOCs in Ihre Blocklisten auf: Domains (update-sync-mcp[.]net, cloud-recon-service[.]com, api-sync-agent[.]org, adaptive-scan-cloud[.]io) und IPs (45.77.188.34, 185.244.25.61, 198.46.224.112, 91.210.144.77, 152.89.196.12).
MFA und Passkeys für alle internen Dienste vorschreiben. Die Credential-Harvesting-Phase war erfolgreich, weil gesammelte Zugangsdaten ohne zusätzliche Verifizierung funktionierten. MFA auf internen APIs, Datenbanken und Admin-Panels hätte die Lateral-Movement-Kette unterbrochen.
Häufig gestellte Fragen
Was ist der GTG-1002-Cyberangriff?
GTG-1002 ist die Bezeichnung für eine chinesische staatsnahe Spionagekampagne, die Anthropics Claude Code als autonome Angriffsplattform nutzte. Die Gruppe zielte auf rund 30 Organisationen in den Bereichen Technologie, Finanzen, Chemie und Regierung ab, wobei die KI 80-90% der Angriffsoperationen eigenständig durchführte. Anthropic entdeckte und stoppte die Kampagne, die den ersten dokumentierten Fall eines großangelegten KI-gesteuerten Cyberangriffs darstellt.
Wie hat GTG-1002 Claude für Angriffe manipuliert?
GTG-1002 nutzte keinen technischen Jailbreak. Stattdessen setzten sie Social Engineering gegen das KI-Modell ein, indem sie Konten erstellten und sich als Cybersecurity-Fachleute ausgaben, die autorisierte Penetrationstests durchführen. Jede einzelne Anfrage sah nach legitimer Sicherheitsarbeit aus; die böswillige Absicht wurde erst beim Blick auf das Gesamtmuster über mehrere Sitzungen sichtbar.
Wie viele Organisationen wurden bei der GTG-1002-Kampagne kompromittiert?
GTG-1002 zielte auf etwa 30 Organisationen in den Sektoren Technologie, Finanzen, Chemie und Regierung. Anthropic bestätigte, dass vier Einbrüche erfolgreich waren, bei denen die Angreifer Zugang zu internen Systemen erlangten, Zugangsdaten abgriffen und Daten exfiltrierten.
Welche Rolle spielte MCP beim GTG-1002-Angriff?
Model Context Protocol (MCP) Server dienten als Brücke zwischen Claude und offensiven Hacking-Tools. Die Angreifer konfigurierten MCP-Server, die Netzwerkscanner, Password-Cracker und Browser-Automatisierung kapselten und Claude die autonome Steuerung dieser Tools ermöglichten. Da MCP die Berechtigungen der Entwicklersitzung erbt, hatte der Agent vollen Zugriff auf interne Systeme ohne separate Zugangsdaten.
Wie können sich Unternehmen gegen KI-gesteuerte Cyberangriffe wie GTG-1002 schützen?
Wichtige Abwehrmaßnahmen umfassen die Überwachung von Sub-200ms-Netzwerkverkehrs-Bursts (als Indikator für KI-Geschwindigkeit), die Erkennung von MCP-Befehlssignaturen im Datenverkehr, die Durchsetzung separater Identitäten und aufgabenbezogener Zugangsdaten für KI-Agent-Sitzungen, den Einsatz KI-spezifischer Verhaltensbaselines in NDR/SIEM-Systemen, das Blockieren bekannter GTG-1002-IOCs und die Pflicht zu MFA auf allen internen Diensten.