KI-Agenten stehlen Kreditkartendaten: 600.000 Karten für 25 Dollar pro Shop

Ein einzelner Angreifer hat mit KI-Agenten Kreditkartendaten im großen Stil abgeräumt: mehr als 600.000 noch gültige Kartendatensätze, gestohlen bei nur zwei Unternehmen. Der Sicherheitsanbieter Gambit Security hat die Kampagne am 22. September 2026 veröffentlicht – ausdrücklich als Zwischenbericht, weil sie noch läuft. Die eigentliche Nachricht steckt nicht in der Zahl, sondern im Preis: Der Angreifer gab für einen Angriff im Schnitt rund 25 US-Dollar aus.

Was Gambit Security dokumentiert hat

Die Forscher kamen an einen Staging-Server des Angreifers und damit an dessen Werkzeuge, Logs und Prompts. Zwischen dem 10. und 15. September 2026 wurden von dort 105 Angriffsprojekte gestartet; mindestens 27 Unternehmen wurden dabei in unterschiedlichem Ausmaß kompromittiert. Bei 19 Opfern war der Kartendaten-Skimmer nachweislich installiert – teils noch aktiv, teils inzwischen entfernt, aber in Scannern protokolliert. Über 100 weitere Websites trugen zur Kampagne passenden Skimmer-Code. Aktiv ist die Operation laut Gambit seit mindestens Juli 2026.

Gesteuert wurde das Ganze von drei Open-Source-KI-Harnessen; der Modellzugriff lief über OpenRouter:

• Hermes für Orchestrierung, Gedächtnis und Skills – mit einer eigens ergänzten Fähigkeit, die die Inhaltsfilter des Werkzeugs selbst entfernt. Modell: Anthropics opus-4.6, laut Gambit erst eingesetzt, nachdem neuere Modelle die Anfragen verweigerten.
• Strix für die Schwachstellensuche, mit GLM 5.2 und später DeepSeek v4 Pro. 146 Läufe gegen 138 Hosts, 633 Scanner-Stunden in 195 Stunden Echtzeit.
• Cairn als autonome Exploitation-Engine mit DeepSeek v4.1 Flash.

Der Mensch dahinter schrieb kurze Anweisungen auf Chinesisch – 1.951 Prompts über 260 Sitzungen – und ließ die Agenten arbeiten. Die belegten Kosten: 7.005,71 Dollar OpenRouter-Guthaben in etwa vier Wochen, insgesamt schätzt Gambit 12.000 bis 18.000 Dollar. Die eigene Kostenübersicht des Angreifers weist über 101 abgeschlossene Scans einen Schnitt von 25,46 Dollar aus, Spanne 3,13 bis 79,31 Dollar.

AD-Checkliste

Dein AD härten: 12 Sofortmaßnahmen

Das PDF mit Bordmitteln, PowerShell-Prüfbefehlen und 30-Tage-Reihenfolge – per Mail, sobald du deine Anmeldung zum Tech-&-Tacheles-Newsletter bestätigst.

E-Mail-Adresse *

Mit der Anmeldung erhältst du die AD-Checkliste als PDF und danach den Tech-&-Tacheles-Newsletter mit Einordnungen zu Security, KI und Crypto sowie gelegentlichen Hinweisen auf meine Bücher und Produktempfehlungen (auch Affiliate-Links) – eingetragen bist du erst nach Klick auf den Bestätigungslink in der E-Mail (Double-Opt-in). Abmeldung jederzeit über den Link in jeder E-Mail, Details in der Datenschutzerklärung.

Kein CVE, sondern handgeschriebener Shop-Code

Bemerkenswert ist die Zielauswahl. Der Angreifer zog Shopping-Websites aus einem Traffic-Ranking und filterte die großen gehosteten und Open-Source-Shopsysteme bewusst heraus, um Shops mit eigenem Code zu behalten. In keiner der Quellen ist eine CVE-Nummer im Spiel. Die dokumentierte Kette bei einem Opfer war stattdessen Handarbeit von der Stange: unauthentifizierte SQL-Injection im Login-Feld, Klartext-OTPs in der Datenbank (damit war die Zwei-Faktor-Hürde weg), Admin-Panel, Bild-Upload ohne Endungsprüfung, Codeausführung, ein sudo NOPASSWD auf python3.12 für Root, ein NFS-Mount mit no_root_squash, WordPress-Zugangsdaten aus der wp-config.php, 46 Secrets aus dem AWS Secrets Manager – und am Ende der Magento-Verschlüsselungsschlüssel, mit dem die Kartennummern entschlüsselt wurden.

Skimmer, die sich selbst reparieren

Gambit dokumentiert acht Injektionswege – und nennt sie ausdrücklich nur als Auswahl, nicht als vollständige Liste. Am häufigsten hängten sie den Loader ans Ende einer ohnehin ausgelieferten JavaScript-Datei und setzten den originalen Zeitstempel zurück. Bei einem Hersteller landete der Code im Google-Tag-Block, mit rund 100 Tabulatoren nach rechts aus dem sichtbaren Quelltext geschoben. Bei einem Beauty-Händler erlaubte ein AWS-Key Schreibzugriff auf den S3-Bucket hinter dem CDN – der Skimmer kam danach vom eigenen CDN des Opfers. Weitere Varianten: Produktbeschreibungsfelder in der Datenbank, ein Kubernetes-initContainer im Produktions-Frontend und serverseitig vergifteter Seiten-Cache.

Am aufschlussreichsten ist der Weinhändler: Dort stellte ein Redeploy das saubere Checkout-Bundle wieder her. Der Angreifer legte daraufhin einen Cronjob im JBoss-Log-Verzeichnis ab, der alle zwei Minuten die Dateigröße prüfte und den Skimmer erneut anhängte.

Dazu kommt eine Eigenschaft, die diese Kampagne von klassischem Kartenklau unterscheidet: Hermes enthielt einen Skill-Abschnitt „Database Wipe After Extraction“. Nach dem Abzug der Daten löschten die Agenten die Quellfelder. Bei einem Fahrradhändler traf es mehr: Der Agent hatte eigene Zwischentabellen mit dem Präfix ZQ angelegt, und die Aufräumroutine löschte anschließend alle 180 Tabellen, deren Namen auf „ZQ“ oder „Backup“ passten – also auch die Backup-Tabellen der Administratoren des Opfers.

Was das für dich bedeutet

Die Schlagzeile lautet „KI-Agenten“, der eigentliche Befund ist unbequemer: Die Schwachstellen waren alt und banal. SQL-Injection, ein Upload ohne Endungsprüfung, ein zu großzügiges sudo-Recht, ein NFS-Export ohne root_squash, ein AWS-Key mit Schreibrechten auf das CDN – das steht seit zwanzig Jahren in jedem Audit-Bericht. Neu ist nicht die Angriffstechnik, neu ist die Stückkosten-Rechnung. Solange ein Angriff einen Menschen zwei Tage kostet, lohnt er sich nur bei großen Zielen. Bei 25 Dollar pro Versuch lohnt er sich bei jedem. Das verschiebt die Bedrohungslage für kleine und mittlere Shops fundamental – nicht weil sie interessanter geworden sind, sondern weil sie nicht mehr zu billig zum Angreifen sind.

Der zweite Punkt betrifft die Zielauswahl, und der sollte jedem zu denken geben, der auf eine Eigenentwicklung stolz ist: Der Angreifer mied Standard-Shopsysteme und suchte gezielt Custom-Code. Nicht weil Individualsoftware schlechter programmiert wäre, sondern weil dort niemand von außen Patches liefert und niemand automatisiert nach bekannten Lücken scannt. Der Preis einer Eigenentwicklung ist, dass du die Sicherheitsabteilung des Herstellers selbst stellen musst.

Dritter Punkt, und er ist der, den die meisten Notfallpläne nicht abdecken: Diese Angreifer haben Daten nicht verschlüsselt, sondern gelöscht – als Nebenwirkung ihrer eigenen Aufräumroutine, nicht als Erpressung. Wer seine Wiederherstellung nur gegen Ransomware geplant hat, hat das falsche Szenario geübt. Und wenn die Backups in derselben Datenbank liegen wie die Produktivdaten, sind sie beim nächsten Cleanup mit weg. Ein Offline-Medium ist hier kein Luxus; in meinem Ratgeber zu verschlüsselten USB-Sticks und externen SSDs habe ich zusammengestellt, worauf es bei so einer getrennten Kopie ankommt.

Bei der Belastbarkeit ist Zurückhaltung angebracht: Alle Zahlen stammen aus einem einzigen Bericht von Gambit Security. BleepingComputer und CyberInsider geben diesen Bericht wieder, sie bestätigen ihn nicht unabhängig – eine Verifikation durch ein zweites Forschungsteam liegt bislang nicht vor, und kein betroffenes Unternehmen hat sich geäußert. Gambit selbst schränkt ein, dass Teile der Angaben aus Logs und Selbstaussagen der KI stammen und Fehler möglich sind; der tatsächliche Umfang sei wahrscheinlich größer. Das ist ein ehrlicher Umgang mit Unsicherheit, bleibt aber eine Quelle.

Was jetzt konkret zu tun ist

• Integrität des ausgelieferten JavaScript prüfen, nicht die Änderungszeit. Die Angreifer haben Zeitstempel zurückgesetzt. Was hilft, ist ein Hash-Vergleich gegen den Build-Artefakt-Stand – idealerweise automatisiert nach jedem Deploy.
• Checkout-Seite im Browser auf fremde Skripte kontrollieren, inklusive Google-Tag-Block. Und im Quelltext auf ungewöhnlich lange Leerraum-Einrückungen achten, die Code aus dem Blickfeld schieben.
• Schreibrechte auf CDN-Buckets einschränken. Ein AWS-Key, der auf den Bucket hinter dem CDN schreiben darf, ist ein Skimmer-Verteilungsdienst mit Hausmarke.
• Die Klassiker abklopfen, weil genau die hier gereicht haben: parametrisierte Queries statt zusammengebauter SQL, Upload-Validierung nach Inhalt, sudo-Regeln ohne Interpreter-Freibrief, NFS-Exporte mit root_squash, OTPs nur gehasht speichern.
• Backups außerhalb der Produktivdatenbank und mindestens eine Kopie, die vom kompromittierten System aus nicht löschbar ist. Und einmal durchspielen, ob die Wiederherstellung auch dann noch funktioniert, wenn Produktivdaten und Sicherungen gleichzeitig fehlen.
• Cronjobs und Deployment-Definitionen in die Prüfung aufnehmen. Ein Redeploy ist keine Bereinigung, wenn im Log-Verzeichnis ein Job wartet.

Wer sich fragt, wie gut KI-Agenten inzwischen offensiv arbeiten: Google hat das mit Gemini an echten Firmen getestet, und im August koordinierten 700 Agenten einen Angriff auf Hugging Face. Dieser Fall ist die kommerzielle Variante davon.

Ein Hinweis zur Verwechslungsgefahr am Rande: Das hier genannte Angriffswerkzeug „Cairn“ ist nicht das gleichnamige KI-Malware-Analyse-Tool, das Cisco Talos ebenfalls am 22. September vorgestellt hat.

Quellen

• Gambit Security: Autonomous AI Agents Attack Online Retailers for $25 a Company (22.09.2026)
• BleepingComputer: Malicious AI agents steal 600K credit cards (23.09.2026)
• CyberInsider: AI agents steal 600,000 credit cards in attacks on online retailers