Vor einigen Wochen habe ich mich hier ausführlicher mit einem Cyberangriff auf mexikanische Regierungsorganisationen beschäftigt, bei dem ein einzelner Angreifer Claude Code und GPT-4.1 sehr tief in seinen operativen Workflow eingebaut hatte.
Wer den Hintergrund noch einmal nachlesen möchte:
und die deutlich technischere Analyse:
Eine Frage der Reihenfolge: Wie ein einzelner Spickzettel eine KI zum Komplizen machte
Seitdem sind weitere Analysen erschienen.
Und deshalb lohnt sich ein kurzes Update.
Die wichtigste Erkenntnis vorweg:
Die grundlegende Einordnung des ursprünglichen Falls hat sich nicht geändert. Aber inzwischen sehen wir sehr viel deutlicher, dass der Einsatz von LLMs im offensiven Cyberbereich kein isoliertes Experiment mehr ist.
Dabei ist allerdings eine Sache wichtig.
Nicht alles, was später in Mexiko passiert ist, gehört automatisch zum selben Angreifer.
Was sich am ursprünglichen Fall nicht geändert hat
Für den von Gambit Security untersuchten Angriff gibt es weiterhin keine belastbare Attribution zu einer bestimmten APT-, Cybercrime- oder Hacktivisten-Gruppe.
Der ursprüngliche Kern der Analyse steht damit weiterhin:
- ein einzelner Operator
- Claude Code für operative Tätigkeiten
- GPT-4.1 für Analyse und Aufbereitung größerer Datenmengen
- bekannte CVEs statt irgendwelcher magischen AI-Zero-Days
- sehr hohe Entwicklungsgeschwindigkeit
- automatisierte beziehungsweise stark beschleunigte Reconnaissance
- mehrere hundert während der Operation entstandene Skripte
- ein Feedback-Loop zwischen Kompromittierung, Datensammlung, Analyse und dem nächsten Angriffsschritt
Auch an den öffentlich bekannten Datenmengen und der grundsätzlichen technischen Rekonstruktion hat sich nichts Wesentliches geändert.
Was sich verändert hat, ist der Kontext darum herum.
Ein zweiter Fall – aber nicht automatisch derselbe Angreifer
Im September veröffentlichte Palo Alto Networks Unit 42 eine neue Analyse zu zwei laufenden Kampagnen in Lateinamerika.
Eine davon betrifft Mexiko.
Unit 42 bezeichnet diesen Cluster als:
CL-CRI-1131
Die Aktivität überschneidet sich mit einer zuvor von CloudSEK beschriebenen Kampagne namens:
Operation Escaneo
Wichtig ist aber genau diese Formulierung:
Es handelt sich um einen separaten Activity Cluster.
Unit 42 stellt zwar ausdrücklich den Bezug zur früheren Gambit-Analyse her, behauptet aber nicht, dass der ursprüngliche einzelne Operator aus dem Dezember-2025-/Februar-2026-Fall identisch mit den später beobachteten Angreifern ist.
Das sollte man sauber auseinanderhalten.
Quelle:
Unit 42 – Attackers Expose Ongoing AI Tool Use Targeting Organizations in Latin America
Was Unit 42 tatsächlich gesehen hat
Die neue Kampagne ist gerade deshalb interessant, weil Unit 42 sehr konkrete Host- und Infrastrukturartefakte beobachten konnte.
Im April 2026 kompromittierten Angreifer Systeme einer mexikanischen Transportorganisation.
Weitere Ziele umfassten nach Unit 42 unter anderem:
- mexikanische Bundesbehörden
- kommunale Wasserversorger
- Organisationen in Ecuador
Dabei wurde stark auf klassische Living-off-the-Land-Techniken gesetzt.
Also nicht unbedingt auf spektakuläre neue Malware.
Stattdessen verwendeten die Angreifer vorhandene Betriebssystemwerkzeuge, Batch-Skripte und bereits verfügbare administrative Funktionen.
Das klingt zunächst ziemlich gewöhnlich.
Interessant wird es bei der Art, wie diese Skripte entstanden.
Man kann der KI beim Debuggen fast zusehen
Unit 42 beobachtete auf kompromittierten Hosts eine Reihe nummerierter Batch-Skripte.
Die Angreifer versuchten unter anderem, sensible Windows-Daten zu sammeln.
Dabei wollten sie beispielsweise:
- die SAM Registry Hive auslesen
NTDS.ditvom Domain Controller kopieren- Shadow Copies erzeugen
- gesammelte Daten in vorbereitete Verzeichnisse schreiben
Das funktionierte offenbar nicht sofort.
Also wurde ausprobiert.
Geändert.
Noch einmal ausprobiert.
Das Skript bekam zusätzliche Permission Checks.
Weitere Versionen folgten.
Genau diese Abfolge beschreibt Unit 42 als konsistent mit der Verwendung eines LLM zur Fehleranalyse und Skriptentwicklung.
Und das erinnert ziemlich stark an das Muster aus dem ursprünglichen Gambit-Fall.
Nicht:
Schreib mir einmal den perfekten Angriff.
Sondern:
Versuch ↓ Fehler ↓ LLM ↓ neue Variante ↓ nächster Versuch
Eigentlich klassische Entwicklungsarbeit.
Nur direkt während einer laufenden Intrusion.
Diesmal findet man die KI sogar in der Infrastruktur
Noch interessanter wird es bei der Infrastruktur.
Bei der Analyse des Exfiltrationsservers:
62.171.185[.]97
stieß Unit 42 auf weitere Infrastruktur.
Unter anderem wurden dynamische DNS-Namen mit dem Muster:
m-doxa-*.duckdns[.]org
verwendet.
Die zugehörigen TLS-Zertifikate zeigen, dass die Infrastruktur über mehrere Monate weiterentwickelt und rotiert wurde.
Unit 42 dokumentiert Zertifikate beziehungsweise Hosts vom:
- Februar 2026
- April 2026
- Juni 2026
Damit lässt sich zumindest für diesen Cluster eine längerfristige operative Infrastruktur nachvollziehen.
Noch interessanter:
Auf:
178.128.87[.]160:3000
lief eine selbst gehostete Instanz von NextChat.
NextChat ist eine Weboberfläche, über die unterschiedliche Large Language Models angesprochen werden können.
Der entscheidende Punkt ist deshalb nicht, welches konkrete Modell dort zu welchem Zeitpunkt lief.
Sondern:
Die Nutzung von LLMs war diesmal Teil der operativen Angreifer-Infrastruktur.
Das ist aus meiner Sicht eine interessante Weiterentwicklung.
Im ersten Fall mussten wir aus Session-Logs und erzeugten Artefakten rekonstruieren, wie intensiv AI benutzt wurde.
Hier steht praktisch ein LLM-Frontend im Backend der Operation.
Das macht Attribution aber nicht einfacher
Die Versuchung ist natürlich groß zu sagen:
Mexiko.
Regierungsorganisationen.
Claude beziehungsweise andere kommerzielle LLMs.
Iterativ entwickelte Skripte.
Ähnliche Infrastruktur.
Also derselbe Angreifer.
Genau diesen Schluss würde ich nicht ziehen.
Unit 42 macht das ebenfalls nicht.
Der von Gambit untersuchte Angriff und CL-CRI-1131 liegen zeitlich nah beieinander und zeigen ähnliche Entwicklungen.
Das reicht aber nicht für eine belastbare Attribution.
Eigentlich zeigt uns das sogar etwas viel Interessanteres.
Die Gemeinsamkeit muss nicht der Angreifer sein. Die Gemeinsamkeit kann einfach die Arbeitsweise sein.
Mehrere voneinander unabhängige Gruppen entdecken dieselben Vorteile:
- schneller Code erzeugen
- Fehler erklären lassen
- Skripte iterieren
- Daten analysieren
- unbekannte Technologien verstehen
- offensive Infrastruktur schneller entwickeln
Damit wird aus einem bemerkenswerten Einzelfall langsam ein Muster.
Der eigentlich relevante Trend heißt nicht „AI Malware“
Ich glaube, wir schauen bei der Diskussion manchmal auf die falsche Stelle.
Wenn von AI und Cybercrime die Rede ist, landet man sehr schnell bei:
AI-generated Malware.
Natürlich wird auch Malware mit LLMs geschrieben.
Aber die interessantere Veränderung passiert meiner Meinung nach viel früher im Workflow.
Zum Beispiel hier:
Reconnaissance ↓ Fehleranalyse ↓ Scripting ↓ Tool-Anpassung ↓ Credential Analyse ↓ Datenaufbereitung ↓ Priorisierung ↓ nächster Angriffsschritt
Genau dort sind LLMs extrem nützlich.
Nicht weil sie irgendeine neue Hacker-Physik erfunden hätten.
Sondern weil sie Arbeit zwischen diesen Schritten reduzieren.
Der Angreifer bleibt derjenige, der entscheidet.
Aber er bekommt einen technischen Assistenten, der nie müde wird, Fehlermeldungen zu lesen.
Und Claude Code selbst?
Auch auf Produktseite hat sich seit dem ursprünglichen Vorfall einiges verändert.
Anthropic hat im August 2026 den Auto Mode für neue Claude-Code-Sessions auf Pro-, Max- und Team-Plänen zum Standard gemacht.
Statt jeden potenziell gefährlichen Tool-Aufruf vom Benutzer bestätigen zu lassen, analysiert ein zusätzlicher Classifier die Aktionen.
Der Hintergrund ist ziemlich nachvollziehbar.
Anthropic stellte bei eigenen Untersuchungen fest, dass Nutzer Permission-Dialoge extrem häufig einfach bestätigen.
In einer kontrollierten Studie mit 1.053 Teilnehmern erkannten Menschen bewusst eingeschleuste gefährliche Commands nur in 13,6 Prozent der Fälle.
Auto Mode blockierte 89 Prozent derselben Testbefehle.
Anthropic weist allerdings selbst ausdrücklich darauf hin:
Auto Mode reduziert Risiko. Er beseitigt es nicht.
Quelle:
Anthropic – Auto mode is now the default in Claude Code for Pro, Max, and Team plans
Das Security-Modell entwickelt sich weiterhin ziemlich schnell
Ebenfalls bemerkenswert ist die Anzahl der Security Advisories rund um Claude Code.
Zwei davon hatte ich bereits im vorherigen Artikel erwähnt.
CVE-2025-59536
Claude Code konnte in bestimmten älteren Versionen Code aus einem nicht vertrauenswürdigen Projekt ausführen, bevor der Benutzer den Trust-Dialog bestätigt hatte.
Behoben ab:
1.0.111
Original Advisory:
https://github.com/anthropics/claude-code/security/advisories/GHSA-4fgq-fpq9-mr3g
CVE-2026-21852
Eine manipulierte Projektkonfiguration konnte ANTHROPIC_BASE_URL auf einen Angreifer-Server setzen.
Dadurch konnten bereits vor Bestätigung des Trust-Dialogs API-Anfragen inklusive API-Key an diesen Server gehen.
Behoben ab:
2.0.65
Original Advisory:
https://github.com/anthropics/claude-code/security/advisories/GHSA-jh7p-qr78-84p7
Check Point hat die komplette Klasse dieser Angriffe inzwischen sehr ausführlich beschrieben.
Dabei geht es nicht nur um klassische Source-Code-Schwachstellen.
Relevant werden plötzlich:
.claude/settings.json- Hooks
- MCP-Konfigurationen
- Environment Variables
- Projekt-Metadaten
Quelle:
Check Point Research – Caught in the Hook
Das bestätigt für mich noch einmal eine Aussage aus dem vorherigen Artikel:
Agenten-Konfiguration ist ausführungsrelevanter Code.
Auch wenn die Datei nach Konfiguration aussieht.
Was sich für Defender daraus ergibt
Die technischen Grundlagen haben sich durch die neuen Erkenntnisse nicht verändert.
Sie werden eher noch einmal bestätigt.
1. Hunt nicht nur nach Malware
Wenn Angreifer viele kleine Scripts während einer laufenden Intrusion erzeugen, ist ein Hash schnell wertlos.
Interessanter werden Sequenzen wie:
Datei erstellt ↓ ausgeführt ↓ Fehler ↓ Datei verändert ↓ erneut ausgeführt
und das innerhalb weniger Minuten.
2. Geschwindigkeit ist ein Signal
Agentic Workflows können deutlich mehr technische Iterationen pro Zeiteinheit erzeugen als klassische Hands-on-Keyboard-Aktivität.
Ein Account, der innerhalb kurzer Zeit:
- viele Systeme enumeriert
- mehrere Script-Versionen erzeugt
- Credentials testet
- Daten sammelt
- Tunnel aufbaut
sollte allein durch diese Aktivitätsdichte interessant werden.
3. AI-Infrastruktur kann selbst ein Artefakt sein
Der NextChat-Fund von Unit 42 ist dafür ein schönes Beispiel.
Bei C2- und VPS-Infrastruktur sollte man zukünftig möglicherweise auch nach:
- selbst gehosteten LLM-UIs
- ungewöhnlichen API-Clients
- Model Gateways
- AI-Proxy-Services
schauen.
Nicht als Beweis.
Aber als zusätzliches Context Artefact.
4. Agent-Konfiguration gehört ins Threat Model
Wenn Entwickler Agenten verwenden, gehören heute auch Dinge wie:
.claude/ .mcp.json AGENTS.md Hooks Skills Environment Configuration
in Code Review, Monitoring und Supply-Chain-Überlegungen.
Das ist kein theoretisches Problem mehr.
Eine Sache hat sich dagegen nicht geändert
Die mexikanischen Behörden haben die von Gambit beschriebenen Einbrüche weiterhin nicht öffentlich in einer Weise bestätigt, die den veröffentlichten forensischen Erkenntnissen entspricht.
SAT, INE und auch die Regierung von Jalisco hatten nach Bekanntwerden der ursprünglichen Vorwürfe erklärt, in ihren eigenen Untersuchungen keine entsprechenden unautorisierten Zugriffe gefunden zu haben.
Eine neue umfassende öffentliche technische Aufarbeitung, die diesen Widerspruch auflöst, ist bislang nicht erschienen.
Damit bleibt diese Frage offen.
Mein Update nach einigen Monaten
Wenn ich meinen ursprünglichen Artikel heute noch einmal schreiben würde, müsste ich an der Kernaussage erstaunlich wenig ändern.
Vielleicht würde ich sie sogar etwas deutlicher formulieren.
Der interessante Wandel ist nicht, dass AI jetzt plötzlich Cyberangriffe durchführen kann.
Menschen konnten das vorher auch.
Neu ist die Produktivitätssteigerung innerhalb der Angriffskette.
Und inzwischen sehen wir diese Arbeitsweise nicht mehr nur in einer außergewöhnlichen forensischen Untersuchung.
Wir sehen weitere Kampagnen, in denen LLMs offenbar beim Debugging, bei der Skriptentwicklung und beim Betrieb offensiver Infrastruktur verwendet werden.
Das macht aus dem ersten Fall noch keine neue universelle Cyber-Kill-Chain.
Aber es macht ihn auch immer weniger zu einem kuriosen Einzelfall.
Und vielleicht ist genau das das eigentliche Update:
Die Frage ist langsam nicht mehr, ob Angreifer LLMs operativ einsetzen.
Die interessantere Frage wird:
An welcher Stelle ihrer Angriffskette tun sie es bereits – und können wir das in unserer Telemetrie erkennen?
Quellen
Unit 42 – Attackers Expose Ongoing AI Tool Use Targeting Organizations in Latin America
Analyse der Kampagnen CL-CRI-1131 und CL-CRI-1163, inklusive NextChat-Infrastruktur, iterativer Batch-Skripte und Infrastruktur-Timeline.
https://unit42.paloaltonetworks.com/ai-tool-use-targeting-latam-orgs/
Anthropic – Auto mode is now the default in Claude Code for Pro, Max, and Team plans
Details zum neuen Auto Mode, Permission Fatigue und den Safety-Evaluationen.
https://claude.com/blog/auto-mode-default-in-claude-code
Check Point Research – Caught in the Hook: RCE and API Token Exfiltration Through Claude Code Project Files
Technische Analyse von Hooks, MCP-Konfiguration, ANTHROPIC_BASE_URL, CVE-2025-59536 und CVE-2026-21852.
https://research.checkpoint.com/2026/rce-and-api-token-exfiltration-through-claude-code-project-files-cve-2025-59536/
GitHub / Anthropic – CVE-2025-59536
https://github.com/anthropics/claude-code/security/advisories/GHSA-4fgq-fpq9-mr3g
GitHub / Anthropic – CVE-2026-21852
https://github.com/anthropics/claude-code/security/advisories/GHSA-jh7p-qr78-84p7
SecurityWeek – Hackers Weaponize Claude Code in Mexican Government Cyberattack
Zusammenfassung der ursprünglichen Gambit-Erkenntnisse und Einordnung des Vorfalls.
https://www.securityweek.com/hackers-weaponize-claude-code-in-mexican-government-cyberattack/
Stand: 5. Oktober 2026