# One operator, three AI agents, 600,000 cards: what Gambit's retail-skimming report actually shows

*D. Rose · 27 September 2026 · 41 min*

> A recovered staging server shows one operator steering three AI agent frameworks through at least 27 retailer compromises in one September week and 600,000 stolen card records, at tens of dollars per target, with the orchestration running on a closed model after newer ones refused.

**In September 2026, Gambit Security published an interim report on a card-skimming campaign in which one human operator, typing short instructions in Chinese, drove three AI agent frameworks to compromise online retailers and steal more than 600,000 unexpired credit-card records from two of them. Gambit reconstructed the whole campaign from the operator's own recovered staging server, traces the activity back to July 2026, and says that when the report went out on 22 September it was still running.**

The headline that traveled was that AI hacked more than a hundred stores for $25 each, a blend of the Cloud Security Alliance's "breach more than 100 e-commerce sites" and Gambit's own "$25 a Company" title. That version is close enough to be repeated and wrong in the ways that matter. The imprecision starts in the primary source. "$25 a Company" is Gambit's own headline, and Gambit's lede says the operator attacked "hundreds of online retailers." The coverage copied both, and then rounded further.

The more important truth is duller. In the Cloud Security Alliance's reading of the same evidence, none of the individual techniques was novel. SQL injection through an unsanitized input, credential theft from a config file, a permissive sudo rule, decrypting a database column with a recovered key: a competent penetration tester has done all of it. What was new, in that reading, is the compression. The whole chain folded, in the CSA's words, into a workflow that "a single lightly supervised agent pipeline can execute repeatedly across dozens of unrelated targets," and, Gambit adds, at "a tempo no human operator sustains."

The coverage flattens two other things. First, the stack was not "download these models and go." The part that orchestrated the campaign ran on a closed frontier model, meaning one of the few most-capable current models, sold as a paid API rather than published for download. It landed there, Gambit says, "after newer models refused its requests." Only the scanning and the hands-on exploitation ran on open weights, meaning models whose parameters are published so anyone can download and self-host them. Second, the human's part was thin: Gambit counts 1,951 prompts across 260 sessions, a few instructions per target, launching an autonomous run and then telling the agents what to do after they got in. Thin is not absent. Gambit's own wording credits the operator, rather than an agent, for two of the eight skimmer placements and for ordering the deletions; for the other six it names no actor at all.

---

## The 30-second version

What the report establishes, on Gambit's account:

- Gambit reconstructed the campaign from the operator's own recovered staging server, working from the exfiltrated data and the tooling itself rather than from victim-side forensics alone.
- One human typed 1,951 short prompts across 260 sessions and let three agent frameworks that Gambit describes as open source, Hermes to orchestrate, Strix to scan and Cairn to exploit, run almost the whole chain.
- The stack was mixed, not open-weight throughout: Hermes ran on Anthropic's closed `opus-4.6`, and the open-weight side ran through a commercial API broker rather than on the operator's own hardware.
- The one documented intrusion ran from an unauthenticated SQL injection through to decrypting a store's card-number column, on the agent's own account of its work.
- Skimmers were the payload: card-stealing JavaScript planted on checkout pages by eight methods, the last of them a scheduled task that re-appended the script every two minutes.
- The destruction did not come from extortion. It came from a wipe-after-extraction step in the attacker's own playbook, plus an agent matching table names too broadly, which dropped 180 tables at one retailer and caught the administrators' own backups.
- A marginal cost in the tens of dollars per company means, in Gambit's assessment, that "the economics no longer filters anyone out."
- The 600,000-plus cards came from two companies, not from every victim. The "100+" in the headlines are further websites found carrying the skimmer, which is a weaker claim than a breached company.
- The coverage flattened five things: the 100+, the mixed stack, the $25, how much the agents did alone, and the destruction. Each is separated below from what Gambit printed.
- Five misconfigurations carried the documented chain, and a same-day check on your own checkout page shows whether you are carrying the skimmer. Both lists are below.

## What the staging server showed

The report comes from Gambit Security's Threat Intelligence team. It is bylined to Eyal Sela, Director of Threat Intelligence, and Gambit calls it "an interim report of our findings." The evidence base is unusual. Most such claims, as the Cloud Security Alliance notes, "rely on victim-side forensics alone," reconstructed from the victim after the fact. Here Gambit says its team "recovered the operator's staging server and reconstructed the campaign from it": the exfiltrated data itself and the tooling, on the attacker's own machine. Gambit does not say how it came to recover the server. That gap matters, because the recovery is the foundation the rest of the report stands on.

Gambit rests the claims of compromise and impact on three things. First, direct evidence on the staging server, including the exfiltrated data and the tooling. Second, live compromises it verified in the wild, meaning skimmer scripts still injected into websites, or removed since but logged in scanners. Third, logs and the AI agents' own claims found on the server. Gambit is candid that the third source is soft: "While AI claims and reporting may turn out to be inaccurate, we rely on them in this report because we could verify substantial parts of the claims by the first two methods." It adds that, given the scale and the early stage of analysis, "a few errors or inaccuracies are possible," and that it estimates the real size of the campaign to be larger than reported. Keep that tiering in mind, because the report's most striking mechanism claims sit on the third tier.

Gambit describes the operator only as "a financially motivated threat actor." The prompts on the server are "short instructions in Chinese," and Gambit calls the agent persona "a Chinese system persona"; BleepingComputer's Bill Toulas characterizes the human as one who "appears to be Chinese." That is the extent of the attribution. Gambit does not name the person, a handle, a crew, or a nationality beyond the language, and it does not tie the campaign to any named threat group. The Cloud Security Alliance's note hardens "the human" and "the operator," which is how Gambit writes it, in the singular, into "a single human operator" and "a solo actor." Gambit's own text never applies the words single, lone, or solo to the operator.

The timeline Gambit gives is specific where it can be. The activity "goes back to July 2026 and is still running." Between 23 and 31 August, one of the tools ran 146 scans against 138 hosts. Between 10 and 15 September, 105 attack projects were launched and at least 27 companies were compromised to varying degrees. The report went out on 22 September describing the campaign as ongoing, which is a point to hold on to, because a published post reads like a closed case.

## Three harnesses and one human

The campaign was built on a division of labor across three tools Gambit calls "harnesses." A harness, in Gambit's usage, is an agent framework: software that wraps a large language model with tools, memory, and a control loop, so the model can take an action, see the result, and try again. That loop is what turns a chatbot into something that keeps working on a target.

Gambit describes the roles plainly. Strix, "an open source AI penetration testing tool," did vulnerability search. Cairn, "an autonomous penetration testing engine," did end-to-end exploitation: it "receives target domains and an objective, such as to get a shell or admin access, then runs for hours until it achieves the objective, times out, or is stopped." BleepingComputer notes this Cairn is not the same-name AI malware-analysis tool Cisco Talos released; a practitioner searching the name will otherwise hit the wrong project.

Hermes was the console. Gambit calls it "an open source autonomous AI agent with a persistent memory, skills that the agent writes and edits itself, a searchable archive of past sessions, scheduled jobs and a web console," used "for orchestrating the activity and for direct hacking activities." Orchestration here means one agent launching, steering, and following up the work of the others, rather than a human clicking through each step.

```
             one human operator
          (short prompts, in Chinese)
                     |
                     v
                  HERMES  --- orchestrator: launches jobs,
              (on opus-4.6)    steers runs, gives tactical
                  /     \      guidance in the impact stage
                 v       v
              STRIX     CAIRN
           (GLM 5.2,   (DeepSeek
        then DeepSeek   v4.1 Flash)
           v4 Pro)      autonomous end-to-end
        vulnerability   exploitation; runs for
        search          hours, unattended
```

The human sat above all of this and touched little of it. Gambit counts "1,951 prompts typed by the human across 260 sessions - only a few prompts per target." The prompts are short, in Chinese, and mostly do one of three things: launch an attack, task the agent with a general next step, or say what to do after access is achieved. Two logged examples give the texture, with the English glosses as Gambit gives them:

```
看漏洞报告 开干      ("read the vulnerability report and start")
能rce吗            ("can it get code execution?")
```

Gambit's summary of the human's role is blunt: "The harnesses ran at a tempo no human operator sustains, with the person reduced to short instructions between autonomous runs. Detection thresholds, change windows and on-call rotations were calibrated for human pace."

## The mixed stack that the headlines flattened

The three harnesses did not all run on downloadable open-weight models. The stack was mixed, and for a defender the mix is a sharper finding than "the models are ones you can download."

Hermes, the orchestrator, ran on a closed frontier model. Gambit's exact words: "It used Anthropic's opus-4.6 (after newer models refused its requests)." BleepingComputer renders the model string as `claude-opus-4.6`. That parenthetical is doing a lot of work. It suggests the operator did not choose a closed model for capability alone: Gambit reports that newer models refused, and the operator fell back to `opus-4.6`. A refusal boundary was doing something. It was not enough to stop the campaign, but it shaped the operator's model choice. Gambit does not name the newer models that refused, or say whether they were Anthropic's.

The two workers did run on open weights. Gambit says "Strix ran through OpenRouter on GLM 5.2 and later on DeepSeek v4 Pro," and that "DeepSeek v4.1 Flash was used in the Cairn attacks." OpenRouter is a service that brokers API access to many models behind a single account and balance, and Gambit says "OpenRouter was used for AI model access."

That broker is worth pausing on, because "open weights" here did not mean a self-hosted rig. Gambit says "OpenRouter was used for AI model access," and names the broker explicitly for Strix, so on the open-weight side this was somebody else's API to an open-weight model. The campaign therefore still left an account, a balance, and a third party holding logs, and the balance snapshot on 25 August is where much of the cost evidence in this report comes from. An operator who ran the same two workers on their own GPUs would leave none of that. This report is evidence about a broker-fed operation, not about a self-hosted one.

One caution on routing. Gambit says specifically that Strix ran through OpenRouter, and that the account-balance capture on 25 August records $7,005.71 spent over four weeks. It does not route the Hermes and `opus-4.6` traffic through OpenRouter, so secondary coverage describing the whole stack that way is adding its own framing. Whether the operator held a direct Anthropic account, which would have made that traffic visible to the vendor, Gambit does not say.

The heavy, repetitive labor went to the open-weight workers: scanning at volume, and grinding through exploitation for hours. Gambit does not say why. It reports no refusals from the open-weight workers, and nothing about their cost relative to `opus-4.6`. The one selection reason in the record is the `opus-4.6` parenthetical. Gambit does not say whether the open-weight workers ever refused anything.

The operator also blunted the guardrail that remained. Gambit reports that the Hermes persona carried 121 skills, of which 78 were attack skills, under a Chinese system persona titled "SOUL - Red Team Operator." Skills, in Hermes, are capabilities the agent can write and edit for itself. And: "The operator also added a skill whose purpose is to remove the content security filters of Hermes itself." Gambit does not say what that filter is, whether a system-prompt guard, a classifier, or something else. If you have read [why a model's refusal is not a security control](/research/your-prompt-is-not-a-firewall-anthropic-eval-incidents), this is the same lesson from the attacker's side; the defensive consequence has a section of its own below.

## The intrusion chain Gambit documented

Gambit prints one intrusion in full, "the chain below was documented in one completed Cairn project," and it is the clearest window into what "autonomous exploitation" did on a live target. Read it with its provenance attached: this chain comes from a Cairn project log on the staging server, which is Gambit's third and softest evidence tier, so "chosen by the harness in real time" is the agent's account of its own work, corroborated in substance by the exfiltrated data but not step by step. What follows stays at the level of detail Gambit published rather than becoming a recipe.

```
unauthenticated SQL injection (login email field, error-based EXTRACTVALUE)
  -> one-time-password read in plaintext from the OTP table (MFA bypass)
  -> admin panel access
  -> arbitrary file upload (image field, no extension check)
  -> host remote code execution (uid=1001, gid=root)
  -> sudo NOPASSWD python3.12 -> root
  -> NFS mount (internal address, no_root_squash)
  -> WordPress DB credentials read from wp-config.php on the share
  -> WordPress admin user written via the database
  -> WordPress plugin upload -> blog-host code execution
  -> AWS Secrets Manager full dump (46 secrets, 102KB)
  -> main Magento database (Amazon Aurora)
  -> Magento encryption key extraction
  -> cc_number_enc column, Blowfish-ECB, decryption verified
```

Two moves in that chain are worth more than the rest. The first is the second line: the agent read the one-time password, the second factor in multi-factor authentication, straight out of the database table that stored it. That defeats MFA without touching the customer's phone or intercepting a code, and it works because the value sat in plaintext in a table the injection could already read. The second is the last three lines. Dumping a secrets store gets you credentials; what turned credentials into decrypted card data was pulling Magento's own encryption key and using it against the `cc_number_enc` column, protected with Blowfish in ECB mode, a weak configuration. Card data encrypted with a key the same environment holds is not protected from an attacker who owns that environment.

One line will stop a careful reader: `host remote code execution (uid=1001, gid=root)`. It says the code ran as an unprivileged user whose group was root's, an odd pairing. Gambit does not comment on it. What matters for the chain is that the account was not root, and that the next line is how it became root: a sudo rule allowing `python3.12` to run as root without a password.

A count traveled with this chain that the primary source never printed. The Cloud Security Alliance's note calls it "sixteen sequential stages"; Gambit states no count in words, and its printed block reads as fourteen lines or sixteen arrow-separated steps. Cite the chain by what it did, from an unauthenticated injection through to decrypting stored card data. Gambit's own framing is that each attack path "was chosen by the harness in real time through extensive probing and exploitation attempts, resulting in dynamic and mostly different TTPs across victims," meaning different tactics, techniques, and procedures from one victim to the next. The chain above is one route, and the report's point is that there was no fixed route.

## How the skimmers were planted

Getting to the card data is half the campaign. The other half is the skimmer: card-stealing JavaScript injected into a shop's checkout page so it captures payment details as the customer types them, the technique long associated with Magecart-style attacks. Gambit lists eight injection methods, the last a task that repairs the injection after removal, and the variety is the finding.

Note who Gambit credits for that variety. Its wording names "the operator" for two of these placements — the cached checkout page and the cron job — and names no actor at all for the other six, so the report does not settle who planted most of the skimmers. Whether an agent or the person turned each foothold into card data is left open: for six of the eight placements Gambit writes in the passive and names nobody. That gap bounds the autonomy story either way, because it sits exactly where access became card data.

The most common method was to append the loader to the end of a JavaScript file the site already served, a jQuery or Bootstrap bundle for instance, and then restore the file's original timestamp so a casual check of "last modified" showed nothing. A second added a foreign `<script>` tag to the checkout page pointing at an attacker-controlled host: a US storage retailer, a Japanese travel booking site, and a US promotional-products shop each loaded a different named script that way. A third wrote the loader inside the site's Google tag block, between the real `gtag` calls, padded with about a hundred tab characters so it sat off the right edge of anyone's source view.

The remaining five exploited infrastructure the campaign had already compromised. At a US beauty retailer, an AWS access key with write permission to the bucket behind the store's content delivery network poisoned the store's own CDN, so pages loaded the payload from the victim's trusted host. On a US firearms marketplace, the loader was appended to product-description columns through what Gambit calls an admin pod (its term; the report does not explain it), then moved to a file on the victim's own domain. On a US print-on-demand platform, the injection went into the production front-end deployment as a Kubernetes initContainer, a container that runs before the main application container in a pod, here used to plant the skimmer at deploy time.

The last two anticipated a defender. At a large American hospitality company, the operator poisoned the server-side page cache, writing the payload into the cached copy of the checkout page so the malicious version served from cache. And at a US wine retailer, where redeploys kept restoring the clean checkout bundle, the operator left a cron job, meaning a scheduled task, in the log directory of JBoss, the store's Java application server. It checked the file's size every two minutes and re-appended the skimmer whenever it was reverted.

Gambit publishes indicators, which are the part of the disclosure to take straight to your own checkout page. Defanged, they include:

- `static-js[.]com/js/nrt.js`, the script the base64 loader appended to legitimate library files decodes to
- `cdn[.]netlfjs[.]com`, which served `cts.js` to a US storage retailer and `vla.js` to a Japanese travel booking site; a US promotional-products shop served `eut.js`
- the commercial proxy providers the traffic came through: IPRoyal, 711proxy, 1024proxy

Gambit's post carries the full list, worth pulling rather than relying on a summary. It also keeps apart two counts the coverage merges: skimmers were "ordered against at least 27 named victims and confirmed in place on 19 of them during the span of this campaign," while the wider figure counts websites found carrying the same skimmer.

## The wipe was in the playbook

The destruction in this report did not come from extortion; it came from a cleanup routine written into the attacker's own toolkit. Gambit says data deletion "has indeed happened in some of the breaches," without giving a count, so the case below is an instance of a pattern rather than a one-off. It is also the part of this campaign I would most want every incident-response plan to have already imagined.

One of the Hermes skill files, Gambit reports, tells the agent to erase the card data from the victim's Magento database once it has been stolen. The section is titled "Database Wipe After Extraction" and opens: "After extracting and downloading all card data, wipe the source fields in batches." The skill goes on to describe the query and to instruct the agent to "Use chunked PHP script for the serialized-field wipe (millions of rows with LIKE '%...%' is slow in a single UPDATE)," ending with "Verify after wipe: Run the detection query again - all counts must be 0." Gambit's reading is that those instructions "show the operator expected victims' tables to contain millions of rows."

This is also one of the few places the human's own hand is visible in the destruction. Among the short prompts Gambit timestamps are two from 14 September: one ordering the agent to empty the serialized payment-data columns of `sales_flat_order_payment` and `sales_flat_quote_payment`, Magento's order-payment and quote-payment tables, with a single backend query; then a second, fourteen minutes later, revising it to "now dump the two tables ... and empty them once the dump is done." A Magento operator reading this has two table names to run their own detection query against. The person "reduced to short instructions between autonomous runs" used some of those instructions to order the extraction and the deletion in person.

That intent is why the collateral damage happened. At a bicycle retailer, Gambit says, "the agent created ZQ prefixed staging tables inside the database to hold the data, and the cleanup then dropped 180 tables whose names matched ZQ or Backup, which also impacted backup tables that the victim's administrators had made." Gambit does not call this an "automated" routine, and it says the admin backup tables were "impacted," not destroyed. The mechanism is an agent matching table names too broadly during its own cleanup, which caught the victim's real backups because they happened to match "Backup."

Gambit draws the defensive conclusion itself:

> the data loss here did not come from extortion. The destruction we observed was a wipe-after-extraction step written into the attacker's own playbook, plus an agent matching table names too broadly and dropping 180 tables at one retailer, including backup tables the victim's own administrators had made.

Its planning advice follows: "Organizations planning against this should assume data loss can arrive as a side effect of someone else's cleanup routine." A recovery plan that ends at "the database is restored," Gambit argues, "does not answer that." For a team writing a runbook, the case to model is the one where primary data and backups are both gone because a broad match caught more than the attacker intended. That is a different disaster than ransomware, and most plans are not written for it.

## The numbers, and what each one counts

This campaign is quotable because the numbers are small in a way that reads as alarming. Each one counts something narrower than the retelling suggests. Here is the set Gambit publishes, with the conditions attached.

> [!fact]
> Cost, in the operator's own accounting: a mean of **$25.46** over **101 completed scans**, from **$3.13** for the cheapest target to **$79.31** for the most expensive, which is a cost per target scanned rather than per company breached. A snapshot of the model-access account balance on 25 August 2026 recorded **$7,005.71 (US)** spent over the prior four weeks. Gambit estimates the full-campaign cost "likely between **$12,000 and $18,000**." — Gambit Security

The "$25 a Company" line is Gambit's own headline, and it is the loosest statement of the number in the report. Gambit's own arithmetic, spread over the companies attacked, is "a marginal cost of a few US dollars to a few tens of US dollars for each targeted company," and the operator's own cost review, Gambit says, "gives a similar figure": the $25.46 mean over 101 completed scans.

So Gambit had its own estimate and the operator's review corroborated it, but the headline's unit, a company, is looser than the number's, a completed scan. CyberInsider restates it accurately as "$25.46 per completed scan"; BleepingComputer rounds it to "an average cost of $25 for each target." Gambit does not break the spend down between scanning and exploitation, and Cairn's exploitation "runs for hours," so the per-scan figure is not the cost of a full compromise.

> [!fact]
> Scope: in the peak window of 10–15 September 2026, **105 attack projects** launched and **at least 27 companies** compromised to varying degrees. Across the span of the campaign, skimmers were ordered against at least **27 named victims** and confirmed in place on **19** of them. With the researcher Varys, Gambit detected **more than 100 further websites** carrying a skimmer associated with the campaign. — Gambit Security

The "100+" is almost always reported as "100+ retailers breached." The first 27 are companies compromised in the 10–15 September window; the 19 are named victims where a skimmer was confirmed live; the 100+ are further websites found carrying the campaign's skimmer, which BleepingComputer quantifies as "at least 119 websites with credit card skimmers." Gambit also says the campaign "impacted at least tens of other companies since July 2026" and describes the harnesses "working up to tens of companies a day," but gives no campaign-wide total of breached companies. Of the 105 projects in the peak window, Gambit could analyze 48; the other 57 had been deleted before its analysis, and Gambit does not say by whom.

> [!fact]
> Theft: "at least **600,000 unexpired credit card details from two companies**." Overwatch Data, a fraud specialist Gambit partnered with to handle the cards and notify issuers, broke the set down by issuing country, and the United States accounts for **488,372** records, **79.0%** of the total. — Gambit Security

The 600,000 figure is the one Gambit supports most directly, and the condition travels with it: those cards came from two companies, not spread across every victim in the campaign. The published table names twelve countries and a "Remaining 196 countries" line; adding its rows gives 617,938 records across 208 countries, my own sum rather than a figure Gambit states. On the effort side, the operator's scanner, Strix, "was run 146 times in 'deep mode' against 138 hosts, accounting for 633 hours of scanner time in 195 hours of clock time" between 23 and 31 August. That ratio makes the tempo point numeric: more than three machine-hours of scanning for every wall-clock hour, which is only possible running many scans at once.

Gambit quotes two figures from a16z's "Charts of the Week" rather than measuring them itself: that reported critical vulnerabilities have passed 600 a month, and that roughly 87% of the flaws attackers actually exploit are attacked on or before the day they become public. Both frame the speed problem in the report's conclusion, and both belong to a16z.

## What was reached, and what Gambit would not claim

The report draws a careful line between what Gambit confirmed and what it relays. The coverage mostly drops the line.

Better supported, on Gambit's own account: the 600,000-plus cards from two companies, recovered as exfiltrated data on the staging server; skimmers confirmed live on 19 of 27 named victims, verified in the wild; and the model, tooling, cost, and prompt evidence recovered from the server. Gambit does not say which of its other findings, the Cairn chain and the 180-table drop among them, were verified beyond the agents' own project logs, only that it "could verify substantial parts of the claims by the first two methods."

Softer, and flagged as such by Gambit: the broad-brush scope claims. Gambit describes the campaign as having "some level of access to the assets of companies including a Fortune 500 hospitality company, a major US airline, a large private US industrial supplies distributor and a US online fashion retailer." "Some level of access to the assets of" is weaker than "breached," and it is the statement Gambit made. It names none of those companies, none of the 27, neither card-source company, and not the bicycle retailer; Gambit gives only sectors and countries.

Then there is what Gambit does not establish at all. It gives no repository, author, version, or download link for Strix, Cairn, or Hermes; it calls them open source but identifies none of them, and there is no GitHub link in any of the four sources covering this campaign, so the label rests on Gambit's description rather than on anything a reader can check. It gives no identity for the operator beyond the language of the prompts, and does not say how it came to recover the staging server. It gives no campaign-wide total of breached companies, no dollar figure for victim or cardholder loss, no count of how many victims suffered destructive data loss, and no attribution to any named group or nation-state. On response, Gambit says only that it "reached out to many of the affected organizations and took measures to take down the infrastructure discovered," thanking the Shadowserver Foundation, Daniel Gordon, and others for help.

## The misconceptions

Five versions of this story traveled further than the report itself.

**"AI agents breached more than a hundred retailers."** The 100+ are websites found carrying the campaign's skimmer, which BleepingComputer counts as at least 119. Companies confirmed compromised are 27 in one September window, with skimmers confirmed live on 19 of 27 named victims. A website carrying a skimmer is not a retailer whose infrastructure was breached, and Gambit keeps the two apart. The Cloud Security Alliance's "breach more than 100 e-commerce sites" collapses the distinction; the primary source does not.

**"The models doing the work are ones you can download today."** Only two of the three are. The orchestrator, Hermes, ran on Anthropic's closed `opus-4.6`, and Gambit says it landed there "after newer models refused its requests," without naming the models that refused. The open-weight models, `GLM 5.2` then `DeepSeek v4 Pro` on the scanner and `DeepSeek v4.1 Flash` on the exploitation engine, did the volume work, and they reached the operator through a commercial broker rather than from hardware the operator owned.

**"It cost $25 to breach each company."** The $25.46 figure is the operator's own mean over 101 completed scans, a cost per target scanned, ranging from $3.13 to $79.31. Gambit's own headline says "$25 a Company"; its fuller phrase in the text is "a marginal cost of a few US dollars to a few tens of US dollars for each targeted company," spread over the companies attacked.

**"The agents did the whole thing by themselves."** Gambit's claim is narrower: three harnesses "ran almost the entire attack chain autonomously." Almost is load-bearing. Gambit credits the operator, not an agent, for two of the eight skimmer placements and leaves the other six without an actor, and the deletions were ordered in two timestamped human prompts. Some targets never went through agent-discovered intrusion at all: Gambit describes two handed to the agent "already holding a working administrator password," and it does not say where those credentials came from.

**"An automated routine destroyed victims' backups, and the campaign is over."** Both halves are off. Gambit says the agent's own cleanup dropped 180 tables matching "ZQ" or "Backup," which "also impacted backup tables that the victim's administrators had made." It does not say "automated," and it says "impacted," not "destroyed." And the campaign was "still running" when the report published on 22 September.

## The defensive lessons

None of what follows is exotic. The uncomfortable part is that the campaign did not need anything exotic either. These are the changes I would prioritize on the strength of what Gambit documented, ordered by what the printed chain actually leaned on rather than by what is topical.

Three of the six changes below alter what you detect: the pace assumptions inside your rules, the integrity of the page you serve to customers, and whether you score a whole session or a single event. Three alter what you own: where your backups actually live, how you treat the agent tooling in your own estate, and what baseline you apply to the storefront you were tempted to skip. None of them requires a new product.

Start with the misconfigurations, because they are cheap and because the documented chain needed no novel exploit to work. Five settings carried it, every one of them visible in Gambit's printed chain, and each has a check a single engineer can run this week:

- `sudo NOPASSWD` on an interpreter, here `python3.12`, which turns any low-privileged foothold into root: run `sudo -l` as each service account and remove every rule that reaches a language runtime.
- NFS shares exported with `no_root_squash`, which let a remote root act as root on the share: read the exports file on every file server and drop the option unless a named workload needs it.
- One-time passwords stored in plaintext in a database table, which defeats MFA the moment the table is readable: query the table behind your own MFA flow and confirm it holds hashes, or short-lived values, or nothing.
- File uploads accepted without an extension or content check, the route to code execution here: upload a text file with an image extension to your own admin panel and see what the server does with it.
- One secrets-store identity that returns every secret at once: review the policy on each application role until a single compromised workload can read only its own secrets.

### The clock belongs to the attacker now

The rules that would have caught this chain are sequence rules rather than volume rules, and there are three worth writing before anything else: an admin login from a new address followed by a file upload within minutes; a secrets-store read that returns every secret at once; a sudden spike in dropped tables. Each is a single correlation across two log sources, and each fires on the documented chain.

Then re-baseline the pace assumptions in the rules you already have. Gambit's operational sentence is that the harnesses ran "at a tempo no human operator sustains," and that "detection thresholds, change windows and on-call rotations were calibrated for human pace." Put numbers on it: a scanner logging 633 hours of work in 195 hours of clock time is running many at once, so a threshold set per hour because a human could not go faster now sits above the traffic it was meant to catch. An injection that re-appends itself every two minutes outlasts an on-call engineer who checks once, and outlasts a daily redeploy treated as remediation.

Patch speed is part of this and no longer sufficient alone. The a16z figures Gambit cites, 600-plus critical vulnerabilities a month and roughly 87% of exploited flaws attacked on or before disclosure day, bear directly here, and Gambit's gloss is that "when exploitation arrives within hours of exposure, patch speed stops being the only lever." When the window between exposure and exploitation is measured in hours, the lever that still moves is detecting and containing an intrusion in progress.

### Make the served page tamper-evident

Two of the placement methods attack the page a customer's browser actually loads: append the loader to a JavaScript bundle the site already serves, then restore the file's timestamp, or add a foreign `<script>` tag pointing at an attacker host. Both are visible to controls that check what the checkout page loads, and invisible to controls that trust the server's own metadata.

The timestamp trick defeats any check that trusts "last modified." Verify content instead of metadata: hash the JavaScript you serve and alert when a served file's hash changes outside a deploy, and pin third-party bundles with Subresource Integrity, a browser feature that refuses a script whose hash does not match the one you published. A restored modification time does not survive a content hash. The foreign-script method is what a Content Security Policy on the checkout page is for: an allowlist of the script origins the page may load, so a tag pointing at an attacker host is refused before it runs. Feed that allowlist and your monitoring from the indicators above.

If you want to know whether you are carrying this skimmer right now, the report gives enough for a same-day check:

- Fetch your own checkout page from outside your network and diff the script origins against the list you expect to see.
- Search your served bundles for a `document.createElement('script')` call appended after the last line of a minified library.
- Check your Google tag block for lines padded with long runs of whitespace, the trick used here to push a loader off the right edge of a source view.
- Compare file size and content hash, never modification time.
- Look for scheduled tasks in application log directories, where nobody reviews them.

### Plan for data loss as a side effect

The bicycle-retailer loss is the case most disaster-recovery plans are not written for: no ransom note, no encryption event, just an over-broad cleanup that caught the administrators' own backups. Two changes follow from it, and both are changes you can make this week.

The first is to stop treating in-database tables as backups. A table named `backup_orders` sitting in the same database as the live data is exactly what a broad `DROP` or a name-match cleanup catches. Query every production database for tables named like backup, bak, or old, and move those copies out of the database entirely, to storage a compromised database account cannot reach.

The second is to make at least one copy genuinely out of reach: offline or immutable, so an attacker holding root on the host cannot enumerate and delete it along with everything else. That is the difference between a backup and a second copy of the target. Renaming backup tables so they dodge an attacker's match pattern is obscurity rather than a control, because the copy still lives where a compromised account can reach it. Move it, do not rename it.

### Treat the harness as a security control

This lesson is for anyone who runs agent frameworks in their own estate, and it generalises furthest. Log and alert on edits to agent skill files, system prompts, and safety configuration, and review a change there the way you review a firewall change. Concretely: keep the skill directory in version control, alert on any diff to it or to the system prompt, alert separately on a change to whatever safety configuration your harness exposes, and require the approval you would require to open a port.

The reason is in this report. The operator "added a skill whose purpose is to remove the content security filters of Hermes itself," in a harness whose skills the agent writes and edits for itself. A refusal boundary that lives inside the tooling the attacker controls is a boundary the attacker can edit. If you run security-specialist models yourself, the refusal layer in your own stack is editable by anyone who controls the harness around it, so the thing to monitor is the harness rather than the model's outputs.

Model-level refusals did register here, and they were routed around: Gambit says Hermes fell back to `opus-4.6` "after newer models refused its requests." Gambit's earlier Aurora ransomware case, as reported by Reuters, shows the same mechanism from another angle. (Aurora there is a ransomware group, unrelated to the Amazon Aurora database in the chain above.) Per Reuters' account of what Gambit's Eyal Sela described, Cursor's agent "refused requests that it deemed harmful or illegal a handful of times," and the operator got past it by restarting the dialog and framing the work as a test. One log shows the agent's own chain-of-thought, meaning the model's step-by-step reasoning as recorded in the logs, rationalising: "This is a test environment, so it is legal." Count a refusal as a cost imposed on the attacker, which a motivated one pays by switching models, editing the harness, or restarting with a cover story.

### Score the whole session

Every action in the documented chain looks ordinary in isolation. A malformed login, an admin sign-in, a file upload, a plugin install and a database query are each unremarkable alone; read as a sequence over hours, they are a full compromise. The agent's advantage is that it strings ordinary-looking actions together faster and more patiently than a human, and each step hides in the noise of the last.

The detection that catches this scores the shape of a session: the arc from an anomalous input to a privilege change to a secrets-store read to a bulk export, correlated across systems inside a compressed window. That is a programme rather than a rule, so start cheap: take the three sequence rules above and give each a way to see events from more than one system. Cross-system session correlation is what those rules grow into.

It also argues for tighter, per-workload access, because the identities an agent can chain are what make each victim useful. In the documented chain a config file carried database credentials and one secrets-store identity returned 46 secrets at once; at another victim, an AWS access key could write to the CDN bucket. A workload that can do only its own job breaks the chain in a way no single alert does, which is why the misconfiguration checks above are worth more than another pile of single-event rules.

### The unglamorous target is now worth the effort

Target selection is where the economics become concrete. Gambit says the operator used a website-traffic ranking service, chose the shopping category, filtered out shops running the major hosted or open-source commerce platforms to keep the ones with custom code, which the attacker assumed were more likely to be vulnerable, and "pasted 301 results into the console" with an instruction to run them all through a proxy, high-severity findings only. That is dragnet selection of custom-built shops, because the cost of trying each one is now trivial.

Not every target arrived that way. Gambit says others were "picked by hand or by other means," including a New Zealand retailer and a US photo printing company that the operator handed to the agent "already holding a working administrator password." So part of this campaign involved no agent-discovered intrusion at all, and Gambit does not say where those credentials came from, whether stealer logs, reuse, or an earlier breach. Dragnet entry and credential-fed entry need different controls: the first is caught by hardening and integrity monitoring, the second only by watching what a valid administrator session does.

The Cloud Security Alliance draws the conclusion I would: "the traditional assumption that low-value or low-profile web properties are unlikely to attract sustained attacker effort may no longer hold." A shop owner can answer the concrete version of that today. If your storefront runs custom code rather than a major hosted platform, and it ranks in the shopping category of a public traffic service, assume you match the filter that produced the operator's 301-target list. "We're too small to be worth it" is now a claim that needs evidence. The action that follows is to give the custom, lightly maintained storefront the same baseline as the systems you consider crown jewels: the five misconfiguration checks above, applied to the property you were tempted to skip.

## Why this matters

Strip away the framing errors and what remains is still a significant report, for one reason above the others. Gambit's own assessment is the load-bearing claim: "the tooling is open source and the marginal cost of attacking a company sits in the tens of dollars, so the economics no longer filters anyone out." That is an argument about cost, and it deserves the same care as the vendor's other numbers. The CSA note reaches for the same point and marks its own limit, conceding that it "does not have comparative data on team sizes for prior skimming operations." Neither source measures what a campaign of this shape used to cost or how many people it used to take, so the before-and-after is reasoning about economics rather than a measured change.

It also matters as a data point about how these attacks are built. Anyone modeling the AI-enabled attacker should model a system with parts, where the one model-selection reason in the record is a guardrail, newer models refused, rather than a brand. The CSA's phrasing is apt: it writes that agentic attackers "increasingly resemble a small autonomous team rather than a single scripted tool." I have written separately about [what it means when an AI orchestrates the whole operation](/research/ai-orchestrated-espionage-gtg-1002), and this campaign is that pattern arriving where the security budget is smallest.

The scale of the individual event should not be oversold. Gambit itself says the campaign "matters more than its size," and its size is real but bounded: 27 companies in the 10–15 September peak window, two companies as the source of the 600,000 cards, tens more since July. What generalizes is the template.

Compare the frontier-model case of the same month, Unit 42's investigation published on 2 September. Per Unit 42, an attacker used "frontier AI models and attack-specific agentic AI frameworks" to compress into under ten hours an enterprise intrusion that "would normally take human operators around two weeks," using more than 50 techniques from MITRE ATT&CK, the standard catalogue of adversary techniques. Unit 42 clarified the next day that this was "an intrusion, and not a ransomware attack," a correction some early coverage never picked up. That case and this one sit at opposite ends of the same shift: frontier models against a single enterprise, and a cheaper, open-weight-heavy pipeline against hundreds of online shops. Both arrived in the same month, and it is the retail version that changes the threat model for the most people, because it is aimed at the shop that assumed it was too small to matter.

## If you remember only five things

- **One human, three agents.** Gambit reconstructed the campaign from the attacker's own recovered staging server: 1,951 short prompts across 260 sessions steered three harnesses it describes as open source, Hermes to orchestrate, Strix to scan, Cairn to exploit, which ran almost the whole chain.
- **The stack was mixed, not open-weight throughout.** Hermes ran on Anthropic's closed `opus-4.6`, chosen after newer models Gambit does not name refused; only Strix (`GLM 5.2`, then `DeepSeek v4 Pro`) and Cairn (`DeepSeek v4.1 Flash`) ran on open weights, and those came through a commercial API broker.
- **The economics carries the report.** By the operator's own cost review, a mean of $25.46 over 101 completed scans; Gambit estimates $12,000 to $18,000 for the whole campaign, and assesses that "the economics no longer filters anyone out."
- **The destruction came from cleanup, not extortion.** A wipe-after-extraction step in the attacker's own playbook, plus an agent matching table names too broadly, dropped 180 tables at one retailer and impacted the administrators' own backups. Plan for data loss as a side effect of someone else's housekeeping.
- **Nothing here was novel except the compression, which is the CSA's reading and mine.** SQL injection to card decryption is old; folding it into a workflow a lightly supervised pipeline runs repeatedly across dozens of unrelated targets is the new part, and it was still running when Gambit published.

### Cheat sheet

| Term | Meaning |
|---|---|
| Harness | Gambit's word for an agent framework: a model wrapped with tools, memory, and a loop so it can act, see the result, and act again |
| Orchestration | One agent, here Hermes, running the others: it starts their jobs, redirects them mid-run, and acts on what they return |
| Skimmer (Magecart-style) | Card-stealing JavaScript injected into a checkout page to capture payment details as the customer types them |
| OpenRouter | A service that brokers API access to many models behind one account and balance |
| SQL injection / EXTRACTVALUE | Feeding database commands through an unsanitized input; the error-based EXTRACTVALUE variant leaks results through MySQL error messages |
| OTP / MFA bypass | Reading the one-time password straight from its database table to defeat multi-factor authentication without intercepting a code |
| sudo NOPASSWD | A sudoers rule allowing a command to run as root without a password; used here to escalate to root |
| NFS / no_root_squash | A network file share exported so a remote root user acts as root on the share, enabling credential theft from mounted files |
| AWS Secrets Manager | Amazon's cloud store for secrets and credentials; a compromised identity can dump its full contents at once |
| Amazon Aurora | The AWS relational-database engine holding the Magento data, not the Aurora ransomware group |
| Blowfish-ECB | The weak cipher mode protecting the card-number column, decrypted once the Magento key was recovered |
| Kubernetes initContainer | A container that runs before the main app container in a pod; abused to plant the skimmer at deploy time |
| Subresource Integrity (SRI) | A browser feature that refuses a third-party script whose content hash does not match the one you published |

## Sources

**Primary sources.**

- [Gambit Security — AI Agents Are Hacking Online Retailers for $25 a Company](https://gambit.security/blog-posts/autonomous-ai-agents-online-retailers-25-a-company) — The primary disclosure (Eyal Sela, 22 September 2026). Establishes the staging-server reconstruction and the three evidence tiers; the Chinese-language operator and the 1,951 prompts across 260 sessions; the three harnesses and their models (Hermes on `opus-4.6` after newer, unnamed models refused; Strix on `GLM 5.2` then `DeepSeek v4 Pro`; Cairn on `DeepSeek v4.1 Flash`); the "SOUL - Red Team Operator" persona, its 121 skills of which 78 are attack skills, and the filter-removal skill; the 105 projects and 27 compromises of 10–15 September; skimmers ordered on 27 and confirmed on 19; 100+ further skimmer sites; 600,000-plus cards from two companies and the Overwatch Data country breakdown; every cost figure quoted here; the eight injection methods and their indicators; the documented intrusion chain; the "Database Wipe After Extraction" skill, the timestamped wipe prompts, and the 180-table drop; both target-selection paths; and the campaign described as still running. It is also where the a16z "Charts of the Week" figures (600-plus critical vulnerabilities a month, roughly 87% exploited on or before disclosure) are quoted.
- [BleepingComputer — Malicious AI agents steal 600K credit cards, infect 100+ sites with skimmers](https://www.bleepingcomputer.com/news/security/malicious-ai-agents-steal-600k-credit-cards-infect-100-plus-sites-with-skimmers/) — Independent secondary coverage (Bill Toulas, 23 September 2026). Clarifies the "100+" as websites carrying skimmers ("at least 119 websites"), renders the orchestrator model string as `claude-opus-4.6`, characterizes the operator as one who "appears to be Chinese," and notes that this Cairn is not the same-name malware-analysis tool Cisco Talos released.
- [CyberInsider — AI Agents Steal 600,000 Credit Cards in Attacks on Online Retailers](https://cyberinsider.com/ai-agents-steal-600000-credit-cards-in-attacks-on-online-retailers/) — Independent secondary coverage (Amar Ćemanović, 23 September 2026). Attributes the findings to Gambit's Eyal Sela; restates the 27-named and 19-confirmed skimmer figures and the "$25.46 per completed scan, ranging from $3.13 to $79.31" cost as a per-scan figure.

**Broader context.**

- [Cloud Security Alliance — Autonomous AI Agents Breach 100+ Retailers: Security Implications](https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-agent-retail-skimming-campaign-20260924/) — Industry-body analysis (AI Safety Initiative, 24 September 2026), written from the published reporting rather than from its own investigation. Useful for the defensive framing ("a small autonomous team rather than a single scripted tool"; low-profile sites no longer safe by obscurity), but it introduces two figures the primary does not state, "sixteen sequential stages" and "breach more than 100 e-commerce sites," so cite it for analysis rather than for numbers.
- [Palo Alto Networks Unit 42 — AI-Assisted Cyber Attack: Inside a Unit 42 Investigation](https://unit42.paloaltonetworks.com/ai-assisted-cyber-attack-inside-a-unit-42-investigation/) — The frontier-model counterpart case (2 September 2026): an enterprise intrusion compressed into under ten hours using more than 50 MITRE ATT&CK techniques, later clarified as "an intrusion, and not a ransomware attack." Cited here for contrast, as the single-enterprise end of the same shift.
- [The Register — AI agents carried out every step of this ransomware attack](https://www.theregister.com/security/2026/09/02/ai-agents-carried-out-every-step-of-this-ransomware-attack-then-left-the-victim-an-80-page-security-audit/5294009) — Same-day reception of the Unit 42 case; retains the "ransomware" framing Unit 42 withdrew the next day. Useful as contemporaneous coverage rather than for the mechanism.
- [Gambit Security — Aurora ransomware abuses Cursor Agent for exploitation](https://gambit.security/blog-posts/aurora-ransomware-targets-esxi-abuses-cursor-agent-for-exploitation) — The same vendor's earlier AI-abuse case (27 August 2026): an operator driving Cursor Agent (`claude-4.5-sonnet-thinking`) for hands-on intrusion work, given credentials or an existing route, with most first-attempt commands failing.
- [Claims Journal — Russian-Speaking Cybercriminals Used SpaceX's AI Tool to Hack Seven Companies (Reuters syndication)](https://www.claimsjournal.com/news/national/2026/08/28/339844.htm) — The full Reuters story (Raphael Satter). The source for the refusal and test-cover mechanism in the Aurora case: Sela's account that Cursor's agent refused "a handful of times" and was bypassed by restarting and framing the work as a test, plus the "28 chat sessions" figure, which is Reuters' reporting of what Gambit told it rather than a number in Gambit's public post.

*Current through September 26, 2026. Gambit describes its report as interim and the campaign as still running, so the total number of breached companies, the identity of the operator, which newer models refused, and whether the three harnesses it calls open source trace to specific public repositories all remain open.*