Open-Source-KI-Agenten stehlen 600.000 Kreditkarten

Was Gambit dokumentiert hat

Eine Kampagne zum Diebstahl von Kreditkartendaten läuft seit Juli 2026 auf Open-Source-Frameworks für KI-Agenten und war am 22. September noch aktiv. Entdeckt hat sie Gambit, ein Security-Start-up, das direkten Zugriff auf einen Staging-Server des Angreifers erlangte.

Die am 23. September 2026 von BleepingComputer^[1] veröffentlichten Zahlen: über 600.000 gültige Kartendatensätze bei zwei Unternehmen abgegriffen, aktive Skimmer auf mindestens 119 Websites, 27 kompromittierte Unternehmen in fünf Tagen.

Zu den Opfern zählen eine Hotelkette aus den Fortune 500, eine große US-Fluggesellschaft, ein amerikanischer Industriegroßhändler und ein Online-Modehändler. Die Primärforschung bleibt die im Blog von Gambit Security^[2] veröffentlichte. Das schwerwiegendste Detail ist jedoch ein anderes.

Ein einziger menschlicher Operator, von den Forschern als chinesisch eingeordnet, gab den Agenten knappe Anweisungen zu den Zielen der Operation. Alles Weitere führten die Modelle aus.

Drei Agenten, drei getrennte Rollen

Die Angriffskette stützt sich auf drei Werkzeuge, jedes mit einer eigenen Aufgabe.

• Strix: Penetration-Testing-Framework, eingesetzt für Scanning und Schwachstellensuche
• Cairn: autonome Exploitation-Engine, gesteuert über Zielvorgaben wie „verschaffe dir eine Shell" oder „verschaffe dir Admin-Zugriff"
• Hermes: Orchestrierung der Kampagne, taktische Entscheidungen und Post-Exploitation-Arbeit, aufsetzend auf dem Modell claude-opus-4.6

Hermes trug intern eine Persona namens „SOUL – Red Team Operator" und 121 geladene Skills, davon 78 mit Angriffsbezug. Das ist ein Red-Team-Operator-Profil, verpackt als Softwarepaket.

Diese Rollentrennung wiegt schwer. Aufklärung, Ausnutzung und Orchestrierung bleiben austauschbare Module: Wer die Kampagne führt, kann die Exploit-Engine wechseln und den Rest des Stacks behalten. Die Architektur ahmt eine CI-Pipeline nach, mit denselben Wartungsvorteilen.

Das Cairn dieser Kampagne ist vom gleichnamigen Malware-Analyse-Tool zu unterscheiden, das Cisco Talos am 22. September 2026 veröffentlicht hat. Gleicher Name, entgegengesetzter Zweck.

Der technisch interessante Punkt: Alle drei laufen auf öffentlichem Code. Der Vorteil des Angreifers entsteht aus der Integration der Teile, weniger aus der Leistungsfähigkeit der einzelnen Komponente.

Die Taktung: 105 Wellen in fünf Tagen

Zwischen dem 23. und 31. August 2026 wurde Strix 146 Mal gegen 138 Hosts gestartet, insgesamt 633 Stunden Scan-Zeit. Zwischen dem 10. und 15. September startete der Angreifer 105 separate Wellen, mit Erfolg bei mindestens 27 Zielen.

Dieses Volumen beschreibt eine Fabrik, nicht einen Eindringling.

Ein gleichwertiges menschliches Team bräuchte Schichten, Koordination und ein sechsstelliges Monatsbudget. Hier nähern sich die Grenzkosten des achtundzwanzigsten Opfers denen eines API-Aufrufs an. Die Ökonomie des Angriffs kippt: Der Engpass verlagert sich von Personenstunden zu Tokens.

Für die Verteidigung betrifft die praktische Folge das Zeitfenster. Der Abstand zwischen Scan und Ausnutzung schrumpft von Wochen auf Stunden, und ein monatlicher Patch-Zyklus wird rein rechnerisch unzureichend.

Sechs Wege, den Skimmer zu setzen

Die Injektion des Skimming-Codes variierte je nach erlangter Zugriffsebene, gefundenen Lücken und Architektur des Ziels. Die von den Forschern beobachteten Methoden decken den gesamten Technologie-Stack ab.

• Code, der an legitime JavaScript-Dateien angehängt wird
• Script-Tags, eingefügt in Checkout-Seiten oder in Google-Tag-Blöcke
• Vergiftung von Inhalten auf S3 und CDN sowie von serverseitigen Caches
• Änderung von Feldern in der Datenbank
• Manipulation von Kubernetes-Deployments
• Cronjobs, die den Skimmer nach der Entfernung wiederherstellen

Der letzte Punkt verdient Aufmerksamkeit. Ein Wiederherstellungs-Cronjob verwandelt die Bereinigung in eine Schleife: Das Team entfernt die Payload, die Zeitplanung schreibt sie zurück, das Monitoring meldet im falschen Zeitfenster „sauber".

Die Liste beschreibt einen Gegner, der moderne Deployment-Pipelines kennt. Kubernetes und CDN wurden als Persistenzflächen behandelt, gleichrangig mit dem Dateisystem. Dieses Maß an operativer Kompetenz, parallel auf Hunderte Ziele angewandt, war zuvor strukturierten Gruppen vorbehalten.

Die Zielauswahl lief über einen Dienst zur Einstufung von Web-Traffic, angewandt auf die von Strix erzeugte Liste, mit Priorität für Websites auf Custom-Plattformen. Die ökonomische Logik ist geradlinig: hoher Traffic bedeutet mehr Karten pro Arbeitsstunde des Agenten.

Die Grundbedingung: Die Runtime ist öffentlich

Die Bedingung, die die drei Komponenten verbindet, ist einfach: Es sind offene Projekte, in wenigen Minuten installierbar. Die Freigabe einer Open-Source-Runtime für KI-Agenten verteilt offensive und defensive Fähigkeiten unter derselben Lizenz.

Das ist eine strukturelle Eigenschaft und muss in Risikobewertungen auch so behandelt werden.

Die Security-Community hat den Fall Cobalt Strike und den von Metasploit bereits erlebt. Der Unterschied liegt heute auf der Steuerungsebene: Die früheren Werkzeuge verlangten einen Operator pro Sitzung, während diese hier ein Ziel in natürlicher Sprache entgegennehmen und taktische Entscheidungen eigenständig treffen.

Wer die Orchestrierung kontrolliert, kontrolliert die Architektur – und hier kostet die Orchestrierung nichts. Die Verteidigung verliert den Vorteil, der sich aus der Knappheit fähiger Operatoren ergab.

Das Korollar für Technologieeinkäufer: Die Risikoeinschätzung nach dem Muster „wie schwer ist es, gute Leute zu finden" ist abgelaufen. Sie muss durch eine Einschätzung ersetzt werden, die sich am Durchsatz orientiert, den ein Gegner für ein paar hundert Dollar Inferenz einkaufen kann.

Wie viel davon ist wirklich neu

Hier braucht es intellektuelle Fairness. Die Agenten haben klassische Web-Schwachstellen ausgenutzt: falsch konfigurierte Zugänge, exponierte Komponenten, permissive Deployment-Ketten. Die Untersuchung beschreibt Volumen und Geschwindigkeit, nicht eine neuartige Exploit-Klasse.

Dieser Befund ist zugleich beruhigend und unbequem.

Beruhigend, weil grundlegende Hygiene weiterhin wirkt: Patch-Management, Segmentierung, Integrität der ausgelieferten Dateien, Kontrolle über Drittanbieter-Tags auf Zahlungsseiten. Unbequem, weil dieselbe Hygiene, angewandt mit den typischen Verzögerungen eines durchschnittlichen Unternehmens, ein Fenster offenlässt, das ein Agent in wenigen Stunden nutzt.

Das muss klar gesagt werden: Der Bericht dokumentiert die Kampagne und ihre Kennzahlen und lässt die Details zur Fehlerquote der Agenten aus. Wie viele der 105 Wellen an Halluzinationen des Modells scheiterten und wie viele an wirksamen Abwehrmaßnahmen, bleibt offen. Eine ehrliche Lesart berücksichtigt diesen Spielraum.

Drei Fragen für das Enterprise-KI-Team

Diese Fragen gehören in die nächste Sitzung zur Anwendungssicherheit, mit einer schriftlich protokollierten Antwort.

1. In wie vielen Minuten erkennt das Team die Änderung einer in Produktion ausgelieferten JavaScript-Datei, und mit welcher Integritätsprüfung?
2. Welcher Prozess prüft die auf Checkout-Seiten geladenen Drittanbieter-Tags, und in welcher Taktung?
3. Wie viel Zeit vergeht zwischen der Veröffentlichung einer CVE zu exponierten Komponenten und dem tatsächlichen Patch am öffentlichen Perimeter?

Die erste Frage misst die Fähigkeit, den Skimmer überhaupt zu sehen. Die zweite misst die Kontrolle über die Zahlungsoberfläche, die das wirtschaftliche Ziel der gesamten Kampagne bleibt.

Die dritte misst den Abstand zwischen internem Patch-Zyklus und der Taktung des Gegners. Ein in Wochen ausgedrückter Wert bedeutet ein implizit akzeptiertes Risiko und gehört als solches in den Aufsichtsrat.

Wer antwortet „das Monitoring deckt den Perimeter ab", hat die falsche Antwort bereits gegeben: Die beschriebenen Skimmer lebten in legitimen Assets, ausgeliefert vom unternehmenseigenen CDN.

Ein vierter Punkt verdient Platz im Protokoll: die Liste der Domains, die JavaScript an die Zahlungsseiten ausliefern. In den meisten Unternehmen ist diese Liste länger, als das Team erwartet, und sie sollte vor der nächsten Traffic-Spitze gekürzt werden.

Entscheidungen für den nächsten Planungszyklus

Für den CTO betrifft die Überprüfung die Auslieferungskette des Frontends. Bundle-Integrität, Signierung von Artefakten und Subresource Integrity auf Zahlungsseiten werden von der Good Practice zur Anforderung.

Für den Head of Engineering geht es um die Erkennungsgeschwindigkeit, weniger um die Breite des Werkzeugkastens. Eine Hash-Prüfung der ausgelieferten Dateien, alle paar Minuten ausgeführt, fängt einen guten Teil der von den Forschern aufgeführten Injektionsmethoden ab.

Für den CFO ändert sich das Risikoprofil der Ausgaben für Anwendungssicherheit. Die erwarteten Kosten eines E-Commerce-Vorfalls steigen, weil die Wahrscheinlichkeit, getroffen zu werden, mit dem Durchsatz des Angreifers wächst. Die Budgetposten für WAF, Bot-Management und Integrity Monitoring sind in diesem Licht neu zu lesen.

Für das Technologie-Einkaufsgremium lautet die vertragliche Frage nur eine: Welcher Anbieter von CDN, Tag-Manager und E-Commerce-Plattform garantiert schriftlich die Erkennung von Änderungen an ausgelieferten Inhalten, und in welcher Zeit? Allgemeine Klauseln zu „Security Best Practices" gehören durch messbare SLAs mit daran gekoppelten Vertragsstrafen ersetzt.