AI Agents Skimmed 600K Credit Cards for $25 a Target

The economics of a payment-card breach just changed. For most of the Magecart decade, standing up a skimming campaign against a real retailer meant a skilled operator spending days on manual reconnaissance, building or buying a working exploit, and staying hands-on-keyboard for each victim. On 23 September 2026 the threat-intel startup Gambit published the reconstruction of a campaign that removed almost all of that human labour. Three off-the-shelf AI agents — one to find the way in, one to break in, one to run the operation — breached at least 27 companies and stole more than 600,000 unexpired payment-card records, at a marginal cost of around $25 per target, per BleepingComputer's report on the Gambit findings.

This is not a story about a clever new exploit. Every technique in it is a decade old. It is a story about what happens to the threat model when the cost of executing those techniques against a real business falls to the price of a restaurant dinner, and the operator no longer has to be awake to run them.

What Gambit reconstructed

Gambit recovered the operator's staging infrastructure and rebuilt the operation from it. The work was split across three autonomous agents, each an existing open-source project, chained by a human who supplied only the targets and the objectives:

Agent	Role	What it did unattended
Strix	Reconnaissance	Scanned targets, enumerated attack surface, found candidate vulnerabilities
Cairn	Exploitation	Turned a candidate into a shell or admin access — "obtain access" as an objective, not a script
Hermes	Orchestration	Persistent memory, self-written skills, scheduled jobs, a searchable session archive and a web console to run the campaign

The measured output over one five-day window (10–15 September) was 105 attack waves and at least 27 companies compromised to varying degrees, according to The Register's account of the campaign. Skimmers were confirmed on 19 targets with more than 100 additional related sites identified, and over 600,000 valid card records were pulled from just two of the victims. Named victim sectors include a Fortune 500 hospitality company, a major US airline, a large US industrial supplies distributor, and an online fashion retailer. The campaign has run since July and was still active on 22 September. Attribution, on the recovered evidence, points to a Chinese operator.

$25 a target: the cost curve broke, not the technique

The number that should worry a CISO is not 600,000. It is $25. Gambit found an OpenRouter account showing $7,005.71 spent over roughly four weeks as of 25 August, with the full campaign estimated at $12,000–$18,000 in model-access fees. Spread across the targets, that is a few tens of dollars each, and the agents were hitting about ten companies a day. Where access was achieved it usually took less than a day — in many cases a few hours — as SecurityWeek noted in its coverage.

Manual Magecart economics force triage: an operator picks a handful of high-value carts because their time is the scarce resource. Autonomous economics remove the triage. When a target costs $25 and no human attention, the rational strategy is not to pick — it is to spray. Every mid-sized store with a checkout page becomes worth attacking, because the marginal attempt is nearly free and the agent that fails simply moves to the next name on the list.

"We're too small to be a target" was always a bet that a human attacker would spend their limited time on someone bigger. That bet is now against a scheduled job that will get to you this week because getting to you costs it twenty-five dollars and none of its attention.

The skimmer payload itself is unremarkable — appended code in JavaScript files, injected script tags on checkout pages, poisoned CDN content, modified database fields, altered Kubernetes deployments. What is new is that a single operator produced that payload across 119 sites without touching most of them by hand.

The skimmer is quiet. The exfiltration is not.

Client-side skimming is built to be invisible on the box. The injected script is small, often obfuscated, and loads inside legitimate checkout logic. Endpoint tooling on the web server does not flag a few lines added to a JavaScript asset. A weekly page scan can miss a payload that only activates for a fraction of sessions, or that lives in a CDN edge the scanner never fetches. This is exactly why PCI DSS moved to mandate client-side script controls — and it is also why so many merchants still discover skimmers only when their acquirer calls.

But a skimmer that harvests card data has to do one thing it cannot hide: send the data somewhere. The harvested fields leave the checkout tier as outbound traffic, usually as periodic small POSTs to a collection endpoint the environment has never talked to before. That egress is anomalous on the wire regardless of what the compromised host's own logs say:

• A web/checkout host that historically only serves traffic suddenly makes sustained outbound connections.
• The destination is a domain and ASN with no prior baseline in the environment — freshly registered, or a look-alike of a real analytics or CDN provider.
• The traffic is encrypted (the skimmer uses HTTPS) so signature-based inspection sees nothing, but the behavioural pattern — regular beacons, small uniform payloads, off-hours consistency — is legible to a model that has learned what normal looks like for that host.
• CDN-hosted skimmers add a second signal: the checkout page now pulls script from an origin outside the merchant's declared inventory.

The point that separates a caught campaign from a 90-day dwell time is when you see the egress. In next morning's SIEM digest, the cards are already gone. While the beacon is establishing, you still have the session.

Why your logs won't save you

The agents did not just steal — they cleaned up. Gambit's reconstruction found the operation configured to, after extracting and downloading all card data, wipe the source fields in batches, and to use cron jobs to restore the skimmer if it was removed. On a rooted host, that behaviour is decisive: the database rows that would prove theft are deleted, the application logs are attacker-writable, and any skimmer you strip out reappears on the next cron tick.

This is the recurring lesson of every appliance and server compromise we cover, and it applies exactly here. On-box telemetry is an adversary statement, not evidence. The one record the attacker cannot retroactively edit is the traffic that already crossed the network — the outbound card exfiltration, the callback to a never-seen ASN, the CDN fetch from an unauthorised origin. If your only visibility is on the compromised host, an autonomous operator with a cleanup routine will hand you a clean-looking box over a stolen card database.

Remediation

There is no single CVE to patch here — the entry vectors were ordinary web vulnerabilities the agents found on demand. The defensible posture is script control, egress visibility, and hunting for persistence.

1. Am I affected? — exposure check.

• Inventory every script that loads on a payment page, including third-party and CDN-hosted ones. If you cannot produce that inventory, you are already out of compliance with PCI DSS.
• Diff the JavaScript actually served to a browser at checkout against a known-good baseline. Skimmers append; a byte-level or hash comparison catches the addition.
• Check your CDN and object storage for modified assets, and compare deployed Kubernetes manifests against source control — the campaign altered both.
• List cron jobs and scheduled tasks on web and checkout hosts; look for anything that rewrites web content or re-fetches remote script.

2. Patch the control gap — PCI DSS 4.0.1. Requirements 6.4.3 (script management — every payment-page script inventoried, justified, authorised, integrity-verified) and 11.6.1 (a change-and-tamper-detection mechanism on payment pages, run at least weekly) have been mandatory since 31 March 2025, and QSAs now fail assessments without evidence for both. The PCI Security Standards Council's payment-page security and e-skimming guidance is the reference implementation. Enforce a Content-Security-Policy with nonces or hashes so an injected inline script does not execute, and use Subresource Integrity on externally hosted scripts.

3. Can't re-architect now? — compensating controls. Allowlist egress from the checkout tier so a web host can only reach the destinations it legitimately needs; a skimmer beaconing to a new domain then fails outbound. Move client-side tamper detection to real-time rather than weekly. Reissue is the acquirer's call, but flag the exposure early.

4. Hunt for compromise — signals mapped to MITRE ATT&CK.

• Outbound POSTs from a checkout host to a newly seen domain/ASN — Exfiltration Over Web Service (T1567) / over C2 (T1041).
• Injected inline <script> or appended JS on payment pages — Input Capture / web portal capture (T1056.003) via JavaScript (T1059.007).
• Checkout page loading script from a CDN origin outside inventory — Compromise Software Supply Chain (T1195.002).
• Web shell or admin-access artefacts from the initial break-in — Exploit Public-Facing Application (T1190), Server Software Component: Web Shell (T1505.003).
• Cron jobs that restore removed content (T1053.003); batch deletion of card fields (Data Destruction, T1485).

5. Eradicate + verify. Remove the skimmer and its persistence — the cron job and any altered deployment manifest — in the same window, or it returns on the next tick. Rotate credentials and API keys reachable from the compromised host. Coordinate card reissue with your acquirer. Then confirm clean after remediation with continuous script-integrity checks, not a one-time scan, because the whole design of this campaign assumes you will remove the payload once and stop looking.

Where this leaves defenders

The campaign is a preview of the attacker Zero Hunt is built to answer, and it lands on two of our three pillars at once.

The card data leaving the checkout tier is the part the attacker could not hide, and catching it while it happens is the job of Zero Hunt's AI Traffic Analysis: a proprietary deep-learning model with four inference heads — suspicious traffic, malware classification, attack-type identification, application fingerprinting — trained on billions of PCAP sequences and running locally on the appliance GPU at 2.7+ Gbit/s. The application-fingerprinting head knows what normal traffic for a given host looks like, so the moment a checkout server that only ever serves begins beaconing small encrypted POSTs to a never-seen ASN, that is anomalous the instant it appears — not in tomorrow's SIEM digest, and independent of on-box logs the attacker has already wiped.

The other half is symmetric. This operation worked because three cheap autonomous agents could find and exploit an entry path faster and more cheaply than any defender could manually check for one. Zero Hunt runs the same class of engine on the defender's side: a 10-agent generative pentest swarm with change-triggered campaigns that launch within the hour a new asset appears on the perimeter, writing per-target exploits with a local LLM rather than replaying public proof-of-concept. It answers the question a vulnerability scanner cannot — is this checkout stack actually reachable and exploitable the way Cairn would exploit it — and every finding is ECDSA-signed at write time. When the loss is regulated payment-card data, that signed evidence trail maps directly across the PCI DSS, GDPR and NIS2 controls the breach puts in scope — one finding, evidenced once, verifiable later.

The operator who ran this campaign automated the attack. The only durable answer is to automate the validation and the watching to match — and to place the watching where the attacker cannot edit the record.