If you run checkout for an online store, here’s the uncomfortable truth: card skimming isn’t “a sophisticated one-off” anymore. It’s turning into a repeatable workflow. A financially motivated actor is chaining open-source AI agents to scan targets (Strix), exploit them (Cairn), and coordinate the whole operation (Hermes) at speed and scale . The campaign has been active since at least July, hit 100+ waves, infected 119+ retail sites, and led to 600,000+ valid card records stolen . The scary part isn’t just the theft—it’s how cheaply and quietly it can happen.
What Changed: Skimming Became a “Workflow,” Not a Hack
For a long time, web skimming (aka Magecart-style credit card skimmers) was treated like a “someone hand-crafted malware and got lucky” problem. The shift now is ugly and simple: it’s becoming an assembly line.
Researchers tracking a financially motivated actor found a repeatable chain powered by open-source AI agents—each one doing a specific job, fast, and with minimal human steering.
Here’s the plain-English breakdown of the AI-powered web skimming workflow:
- Strix = the finder
It scans and performs vulnerability discovery like a penetration testing framework—basically, it keeps knocking on doors until it finds one that’s unlocked. In one observed window, Strix ran 146 times against 138 hosts, racking up 633 scanning hours.
- Cairn = the breaker-in
Once Strix flags an opening, Cairn works the exploit with a clear goal (get a shell, get admin access). This is where “AI” stops being a buzzword and starts being a production tool.
- Hermes = the manager
Hermes coordinates the campaign and post-exploit steps—using claude-opus-4.6 to direct activity, pick next actions, and run playbooks. It even had a built-out operator persona (“SOUL - Red Team Operator”) and a library of skills.
The scale is the headline. This campaign has been active since at least July and was still running as of September 22. In a five-day stretch (Sep 10–15), the actor launched 105 distinct attack waves and hit at least 27 companies to varying degrees. Researchers tied the activity to 119+ compromised websites running credit card skimmers, with 600,000+ valid card records stolen (confirmed from two companies alone).
That’s the change you should care about: AI makes client-side card skimming repeatable. When compromise becomes a workflow, “we’ve never been targeted” stops being comforting—and starts being a countdown.
How Skimmers Get In: The 6 Quiet Entry Points Most Teams Miss
Once attackers can run this kind of operation at scale, they don’t need a fancy, exotic path into your checkout. They just need one quiet place to inject malicious JavaScript or tamper with the systems that feed JavaScript to customers.
Gambit’s research calls out six injection paths seen in real-world AI-powered web skimming runs.
1) Malicious code appended to legitimate JavaScript files
This is the classic “looks normal at a glance” move: take a real .js file your store already serves and append a few lines that capture form fields and exfiltrate payment data.
Why teams miss it:
- The file name, URL, and most of the code still look right.
- Quick diff checks can miss it if nobody’s pinning hashes or doing integrity monitoring.
2) Script tags added directly to checkout pages
Instead of editing existing scripts, attackers can inject a new <script> tag into the checkout flow—sometimes pointing to an external skimmer loader.
What it looks like operationally:
- “Nothing changed in our app code” (because the edit happened in a template, CMS, or injected content path).
- Customers report fraud weeks later, so the timing doesn’t line up in people’s heads.
3) Script tags slipped into Google tag blocks / tag management
This one hurts because it blends into “marketing tooling.” Attackers add script tags into Google tag blocks, where extra JavaScript doesn’t automatically trigger panic.
Common failure mode:
- Tag changes have a looser approval process than checkout code.
- Too many people have publish rights.
4) “Invisible” S3/CDN content poisoning and server-side cache poisoning
This is the sneakiest category: poisoned S3/CDN content or server-side caches can serve customers malicious code without touching your repo.
Why it’s maddening:
- Devs keep redeploying “clean” builds, but the edge/cache keeps serving the bad version.
- Your internal tests may hit a different cache path than real users.
5) Database field modifications (signals a deeper foothold)
Not every skimmer lives in a .js file. If an attacker can modify database fields, they can inject payloads into stored page content, configuration tables, or template fragments that render at checkout.
Read this as: “This isn’t just a web bug.” It’s access.
6) Kubernetes deployment changes (supply chain inside your infra)
If you run modern ecomm on containers, attackers may alter Kubernetes deployments to inject skimmer logic at build, startup, or via sidecars/config.
What makes it dangerous:
- A deployment change can spread fast across replicas.
- Rollbacks aren’t always clean if the attacker also changed images, secrets, or config.
The one that makes teams feel like they’re losing it: cron persistence
Even if you remove the skimmer, attackers can use cron jobs to restore it after cleanup—so it “mysteriously” comes back.
If you’ve ever had that experience where a removed script reappears a day later, it’s often not an accident. It’s persistence.
The Hidden Damage: They Don’t Just Steal Cards—They Break Your Operations
If you think the worst-case outcome is “we’ll deal with fraud reports later,” you’re missing the part that can knock your team sideways this week: attackers can sabotage your data after they’ve already taken what they want.
In this campaign, Gambit found direct evidence of a cleanup routine that doesn’t just cover tracks—it creates real damage. The attacker instructed the AI agent to remove payment data from Magento databases after exfiltration, with a specific instruction embedded in a Hermes skill file: “After extracting and downloading all card data, wipe the source fields in batches.”
That one line changes the incident from “security issue” to “operational incident.”
What “wipe the source fields” actually does to a retailer
When card-related fields or related payment records disappear in batches, you’re left with half-a-transaction trail. Orders exist. Customer emails exist. Shipping might already be moving. But the payment details you rely on for support and reconciliation? Gone. Gambit noted this led to operational disruptions at several retailers due to data losses.
How it shows up inside the business (and why it’s easy to misread)
This is where teams waste days, because it doesn’t look like a skimmer problem at first. It looks like random breakage.
Here’s the pattern you’ll feel:
- Support tickets spike
- “My card was charged but my order failed.”
- “I was asked to re-enter payment.”
- “My receipt doesn’t match what I paid.”
- Chargebacks get messy
- Your chargeback responses depend on clean order + payment evidence.
- Missing fields turn a winnable dispute into a forced loss.
- Finance can’t reconcile cleanly
- Daily settlement matching becomes a manual job.
- Small gaps spread into larger reporting headaches.
- Engineering hunts ‘bugs’ that aren’t bugs
- People roll back releases, blame plugins, blame the gateway.
- Meanwhile, the real issue is deliberate: the attacker’s post-exfiltration cleanup.
A lot of security write-ups focus on the credit card skimmer itself. This campaign is a reminder that attackers also optimize for friction: if your team is busy restoring data and calming customers, you’re slower to find the original compromise.
Why This Campaign Scales: The Economics Are Brutal (and That’s the Point)
When attackers can steal cards and break your ops, the natural question is: why aren’t they doing this to everyone?
Answer: because now they can afford to.
Gambit’s reporting included a rare look at the spend behind the operation: an OpenRouter account showing $7,005.71 spent over roughly four weeks as of August 25. That’s not a nation-state budget. That’s a line item.
Based on subsequent usage, Gambit estimated total costs of $12,000–$18,000, averaging about $25 per target. The operator’s own review lined up: a mean of $25.46 over 101 completed scans, ranging from $3.13 (cheapest) to $79.31 (most expensive).
The cost math changes the attacker’s behavior
At ~$25 a shot, the playbook becomes simple:
- Spray attempts widely
- Hit lots of online retailers and ecommerce stacks.
- Learn fast, adjust, repeat
- Every failed exploit still teaches the agent what to try next.
- Prioritize winners
- Double down on the targets where access is easiest and checkout traffic is valuable.
This is why “we’re too small to be targeted” is basically a feel-good story now. Low per-target costs mean attackers don’t need a perfect list. They can make the list by scanning.
Speed makes it worse (because humans can’t keep up)
Gambit also noted that access was obtained in just a few hours in many cases, with AI tools doing the work based on short instructions the operator provided between autonomous runs.
That’s the scary economics: cheap attempts, fast feedback loops, and barely any hands-on time. Once AI-powered web skimming is priced like ad spend, attackers can keep testing checkout pages until something sticks.
Defense That Actually Helps: Catch Skimmers Fast, Contain Blast Radius, Expect Data Loss
If the economics are cheap and the attempts are constant, defense has to be built for speed and repeatability, too. Gambit explicitly warned defenders to plan for potential data loss as a side effect of the attacker’s cleanup routine.
Here’s what actually moves the needle against web skimming / Magecart-style attacks.
1) Catch it at the browser: client-side skimmer monitoring
Server logs won’t reliably tell you what scripts a customer’s browser executed.
Prioritize client-side payment page integrity checks that can answer:
- What scripts loaded on checkout (and in what order)?
- Did a new domain start receiving form data?
- Did a “known” script change without a matching release?
2) Lock down scripts and tags like it’s production code (because it is)
This campaign used multiple injection routes, including script tags added to checkout pages or Google tag blocks.
Tighten governance:
- One owner for checkout scripts and tag containers
- Two-person review for any change that can execute JavaScript on checkout
- Time-bounded access (temporary publish rights, not permanent keys)
3) Watch for “repo-clean” infections: CDN/S3 and cache integrity checks
Attackers were seen poisoning S3/CDN content and server-side caches.
That means your Git history can be spotless while customers get served a skimmer.
Controls that help:
- Publish immutable, versioned assets (fingerprinted filenames)
- Add Subresource Integrity (SRI) where feasible for third-party scripts
- Alert on unexpected asset hash changes at the edge (not just in CI)
4) Alert on unauthorized web asset changes (and treat them like incidents)
Don’t wait for fraud reports. Set alerts for:
- New or modified
.jsfiles in web roots - Template edits affecting checkout
- New
<script>tags or new external script sources on payment pages
5) Harden the “deeper access” paths: database and Kubernetes
Gambit observed attackers modifying database fields and altering Kubernetes deployments to inject skimmers.
That’s a broader compromise signal.
Minimum hardening:
- Separate roles: app deploy ≠ DB admin ≠ cluster admin
- Audit logs on: DB writes to content/config tables, Kubernetes deployment changes
- Restrict who can edit ingress, configmaps, secrets, and image tags
6) Assume persistence and plan restores (seriously)
They also used cron jobs to restore the skimmer after removal.
So build response playbooks that include:
- Cron and scheduled task review (not optional)
- Known-good backups + restore drills for web assets and databases
- A quick re-compromise checklist (edge cache, tag manager, DB, k8s)
If you’re looking for one mindset shift: treat checkout like a critical system with integrity monitoring, not a web page with “some scripts on it.”
