Günstige KI-Agenten machen aus Angriffen auf den Einzelhandel eine Pipeline zum Diebstahl von Zahlungskartendaten

Dutzende Unternehmen bei schnell ausgeweiteter Kampagne kompromittiert

Ein chinesischsprachiger, finanziell motivierter Bedrohungsakteur nutzt autonome KI-Tools, um Schwachstellen aufzuspüren, Angriffe durchzuführen und sich dauerhaft Zugang zu Onlinehändlern und anderen Organisationen zu verschaffen.

Die Kampagne begann im Juli 2026. Seitdem waren mindestens Dutzende Unternehmen betroffen, wie aus Berichten zu Gambits Untersuchung hervorgeht. Zwischen dem 10. und 15. September startete der Akteur 105 Angriffsprojekte. Mindestens 27 Unternehmen wurden dabei in unterschiedlichem Umfang kompromittiert.

Erfolgreiche Angriffe dauerten in der Regel weniger als einen Tag. In einigen Fällen verschaffte sich der Akteur innerhalb weniger Stunden Zugang.

Die Operation hatte bereits erhebliche finanzielle und betriebliche Folgen. Gambit führte den Diebstahl von mehr als 600.000 gültigen Zahlungskartendatensätzen auf Sicherheitsverletzungen bei zwei Unternehmen zurück. Mehr als 488.000 dieser Karten stammten aus den USA.

Der Angreifer installierte außerdem Payment-Skimmer in Onlineshops und erlangte zumindest eingeschränkten Zugang zu einem Hospitality-Unternehmen aus der Fortune 500. Zu den weiteren identifizierten Opfern gehörten eine US-amerikanische Fluggesellschaft, ein Industriezulieferer und ein Online-Modehändler.

Das System lief nicht vollständig ohne menschliches Zutun. Der Operator gab kurze Anweisungen, wählte Ziele aus und lenkte die Agenten nach dem Eindringen in die Systeme um. Einen Großteil der Aufklärung, Ausnutzung von Schwachstellen und Angriffsplanung übertrug er jedoch drei Open-Source-Tools: Strix, Cairn und Hermes.

Strix und Cairn automatisierten Aufklärung und Ausnutzung

In der ersten Phase kam Strix zum Einsatz, ein Open-Source-Penetrationstest-Tool zur Suche nach Schwachstellen. Vom 23. bis 31. August startete der Akteur Strix 146-mal im „Deep Mode“ gegen 138 Hosts.

Der Angreifer griff über OpenRouter auf das Tool zu und verwendete dabei die Modelle GLM 5.2 und DeepSeek v4 Pro. Die von Strix erstellten Berichte wurden anschließend an Cairn weitergegeben, eine autonome Penetrationstest-Engine.

Cairn war mit DeepSeek v4.1 Flash konfiguriert und startete die 105 Angriffsprojekte, die zwischen dem 10. und 15. September beobachtet wurden. Gambit konnte 48 Cairn-Berichte wiederherstellen; die übrigen waren gelöscht worden.

Statt bei allen Zielen dieselbe festgelegte Exploit-Kette anzuwenden, wählte Cairn seine Angriffswege dynamisch aus, indem es Systeme sondierte und Schwachstellen auszunutzen versuchte. Deshalb unterschieden sich Taktiken, Techniken und Vorgehensweisen bei den meisten Opfern.

Aus den verfügbaren Informationen geht nicht hervor, welche konkreten Schwachstellen ausgenutzt wurden, wie schwerwiegend sie waren oder ob ihnen CVE-Kennungen zugeordnet sind. Auch die genauen betroffenen Softwareversionen wurden nicht offengelegt. Daher gibt es keine kampagnenspezifische Schwachstelle, die sich dem Katalog Known Exploited Vulnerabilities der US-amerikanischen Cybersecurity and Infrastructure Security Agency zuordnen ließe. Eine damit verbundene Frist für Bundesbehörden zur Behebung der Schwachstelle ist ebenfalls nicht bekannt.

Da keine CVEs offengelegt wurden, können Unternehmen diese Kampagne auch nicht durch die Installation eines bestimmten Patches eindämmen. Bei der Erkennung sollten sie sich auf nicht autorisierte Änderungen, gestohlene Zugangsdaten, kompromittierte Anwendungen und die bei einzelnen Opfern beobachteten Persistenzmechanismen konzentrieren.

Hermes verschaffte dem Operator eine dauerhafte Angriffsplattform

Für die Orchestrierung und interaktive Steuerung der Angriffe nutzte der Bedrohungsakteur Hermes. Der autonome Open-Source-Agent bietet ein persistentes Gedächtnis, durchsuchbare Sitzungsverläufe, eine Webkonsole, geplante Aufgaben und die Möglichkeit, eigene Skills zu erstellen.

Der Angreifer konfigurierte Hermes mit einer chinesischsprachigen Systempersönlichkeit und 121 Skills. 78 davon waren für offensive Aktivitäten ausgelegt. Der Agent arbeitete mit dem Modell opus-4.6 von Anthropic.

Gambit identifizierte 1.951 Eingaben eines menschlichen Operators aus 260 Sitzungen. Dabei handelte es sich meist um kurze Anweisungen auf Chinesisch, die Hermes aufforderten, einen Angriff zu starten, einen groben nächsten Schritt auszuwählen oder nach dem Zugriff eine bestimmte Aktion auszuführen.

Diese Arbeitsteilung ist entscheidend: Der Operator musste nicht jeden Befehl vorgeben oder den gesamten Angriffsweg im Voraus festlegen. Stattdessen gab der Mensch die Ziele vor, während der Agent den Kontext behielt, spezialisierte Skills aufrief und die einzelnen Angriffsphasen unterstützte.

Daniel Wilcock, Threat-Intelligence-Analyst bei Talion Cyber Security, grenzte die Aktivitäten von kontrollierten KI-Penetrationstests ab. In diesem Fall wurden die Agenten gezielt gegen Unternehmen eingesetzt, sollten weiter nach Schwachstellen suchen und Spuren beseitigen.

Der Betrieb der Kampagne war zudem kostengünstig, da die wichtigsten Tools Open Source waren. Auf Grundlage der wiederhergestellten Aufzeichnungen schätzte Gambit die durchschnittlichen Kosten auf 25,46 US-Dollar für 101 abgeschlossene Scans.

Kartendaten wurden aus Datenbanken und von Checkout-Seiten gestohlen

Die Angriffe zielten auf mehreren Wegen auf Zahlungsdaten ab.

Bei zwei betroffenen Unternehmen stahl der Bedrohungsakteur mindestens 600.000 gültige Zahlungskartendatensätze. Die Ermittler fanden einen Hermes-Skill, der darauf ausgelegt war, gestohlene Kartendaten aus der Magento-Datenbank eines Opfers zu entfernen. Welche Magento-Versionen betroffen waren und wie der Angreifer zunächst Zugriff erlangte, ist nicht bekannt.

Manipulationen an Datenbanken bargen außerdem das Risiko schwerwiegender Schäden. Bei einem separaten Vorfall in einem Fahrradgeschäft sollte der Agent von ihm angelegte Staging-Tabellen löschen. Stattdessen löschte er die Backup-Tabellen des Händlers.

Andere Opfer wurden mit Skimmern infiziert, die Daten über Checkout-Seiten abgriffen. Gambit bestätigte zunächst 19 betroffene Unternehmen. Gemeinsam mit dem Sicherheitsforscher Varys identifizierten die Ermittler anschließend mehr als 100 weitere infizierte Websites.

Am häufigsten fügte der Angreifer den Skimmer-Code in eine vorhandene JavaScript-Datei ein. Die Methoden zur Einschleusung unterschieden sich jedoch erheblich. Der Schadcode wurde auch über folgende Wege eingebunden:

• Über zusätzliche Script-Tags auf Websites.
• Über den Google-Tag-Block einer Website.
• Über Inhalte in einem AWS-S3-Bucket.
• Über Inhaltsfelder in Datenbanken.
• Über einen Kubernetes initContainer.
• Über das zwischengespeicherte Seitenmodell der Checkout-Seite.

Diese Vielfalt zeigt, dass eine einfache dateibasierte Suche nicht ausreicht. Ein Checkout-Bundle kann unauffällig wirken, während Schadcode über eine Datenbank, ein in der Cloud gehostetes Objekt, einen Container-Initialisierungsprozess oder eine Tag-Management-Konfiguration eingeschleust wird.

Persistenz überstand die saubere Neuinstallation der Anwendung

Ein Angriff auf einen US-amerikanischen Weinhändler zeigt, wie der Akteur reagierte, als routinemäßige Wiederherstellungsmaßnahmen den Skimmer entfernten.

Durch die erneute Bereitstellung der Anwendung erhielt der Händler ein sauberes Checkout-Bundle zurück; die schädliche Änderung war vorübergehend beseitigt. Daraufhin legte der Operator einen Cron-Job im JBoss-Logverzeichnis an.

Der Job prüfte alle zwei Minuten die Dateigröße der relevanten Datei. Wenn bei einer Bereitstellung die legitime Datei wiederhergestellt wurde, fügte der Job den Skimmer erneut ein.

Dieser Mechanismus kann den Eindruck erwecken, die Infektion kehre nach der Bereinigung von selbst zurück. Er zeigt auch, warum der Austausch veränderter Frontend-Dateien nicht zwangsläufig den ursprünglichen Zugang des Angreifers beseitigt.

Die Verwendung eines Logverzeichnisses für eine geplante Persistenzkomponente kann die Untersuchung zusätzlich erschweren, wenn sich die Verteidiger ausschließlich auf die Verzeichnisse des Anwendungscodes konzentrieren. Geplante Aufgaben, beschreibbare Dienstpfade und ungewöhnliche Dateien in JBoss-Verzeichnissen sollten separat überprüft werden.

Die Sicherung von Beweisen ist besonders wichtig. Der Akteur löschte einige Angriffsberichte. Gleichzeitig entfernten seine Tools Daten von Opfern oder zerstörten versehentlich Backups. Werden Systeme neu aufgesetzt, bevor Protokolle und flüchtige Beweise gesichert wurden, können wichtige Informationen zur Rekonstruktion des Angriffs verloren gehen.

Händler mit individuellem Code standen im Fokus

Bei der Auswahl der Ziele nutzte der Akteur einen Dienst zur Rangfolge des Website-Traffics und bevorzugte Händler mit individuell entwickeltem Code. Der Operator gab 301 Treffer in die Angriffskonsole ein.

Mindestens zwei Ziele wählte der Angreifer manuell aus, weil er bereits über Administratorpasswörter verfügte. Wie er an diese Zugangsdaten gelangte, ist nicht bekannt.

Individuell entwickelte Einzelhandelsanwendungen bieten eine breite und uneinheitliche Angriffsfläche. Bei dieser Kampagne konnten die automatisierten Tools jede Umgebung sondieren und ihren Angriffsweg anpassen, statt von einer einzelnen Schwachstelle abhängig zu sein, die bei allen Opfern vorkommt.

Diese Flexibilität erklärt möglicherweise, warum auch Unternehmen außerhalb des klassischen Onlinehandels zu den Opfern zählten. Die Operation erfasste Unternehmen aus den Bereichen Hospitality, Luftfahrt, Industriezulieferung und Mode. Wie weit der Zugriff bei den einzelnen Unternehmen reichte, wurde jedoch nicht offengelegt.

Verteidiger sollten alle Abhängigkeiten der Checkout-Seite prüfen

Für die Kampagne wurden weder ein Hersteller-Patch noch eine geprüfte Umgehungslösung oder ein bestätigtes Verfahren zur Behebung veröffentlicht. Unternehmen, die Zahlungsseiten betreiben, sollten daher sowohl den ursprünglichen Angriff als auch die verschiedenen Wege untersuchen, über die Skimmer erneut eingeschleust wurden.

Zu den vorrangigen Maßnahmen gehören:

1. Checkout-JavaScript und Script-Tags überprüfen und nach nicht autorisierten Ergänzungen suchen, auch innerhalb ansonsten legitimer Dateien.
2. Google-Tag-Konfigurationen prüfen und kürzlich hinzugefügten oder geänderten Code identifizieren.
3. Von S3 gehostete Ressourcen untersuchen, die Checkout-Seiten laden, einschließlich des Objektverlaufs und verfügbarer Zugriffsprotokolle.
4. Inhaltsfelder in Datenbanken und zwischengespeicherte Seitenmodelle durchsuchen und nach eingeschleusten Skripten oder unbekannten Verweisen suchen.
5. Kubernetes initContainers überprüfen und nach nicht autorisierten Befehlen, Images, Einbindungen oder Dateiänderungen suchen.
6. Geplante Aufgaben und JBoss-Logverzeichnisse untersuchen, insbesondere Jobs, die Dateigrößen überwachen oder Anwendungsressourcen wiederholt überschreiben.
7. Magento-Datenbanken auf Zugriffe auf Zahlungskartendaten untersuchen und nach verdächtigen Abfragen, Datenbereitstellung, Löschvorgängen und veränderten Backups suchen.
8. Forensische Beweise sichern, bevor betroffene Systeme neu aufgesetzt werden. Dazu gehören Agentenprotokolle, Authentifizierungsdaten, Datenbankaktivitäten, Cloud-Audit-Trails und Bereitstellungsverläufe.
9. Offengelegte Administratorkennwörter ändern und prüfen, ob vorhandene Passwörter dazu genutzt wurden, bestimmte Ziele auszuwählen oder sich Zugang zu ihnen zu verschaffen.

Unternehmen, die einen Skimmer entdecken, sollten ihn als Hinweis auf eine umfassendere serverseitige Kompromittierung behandeln – nicht bloß als beschädigte Webressource. Die beobachteten Persistenzmechanismen zeigen, dass die Wiederherstellung einer sauberen Checkout-Seite zwar die sichtbare Schadkomponente entfernen kann, der Angreifer aber möglicherweise weiterhin einen Weg zur erneuten Infektion hat.