AI Agents Turn Retail Skimming Into a Low-Cost Cybercrime Operation
AI Agents Turn Retail Skimming Into a Low-Cost Cybercrime Operation
Executive Summary
Gambit Security has documented an active campaign in which a financially motivated operator used open-source AI harnesses to attack online retailers at scale. The reported impact is not theoretical: researchers say the campaign compromised more than 100 e-commerce sites, stole more than 600,000 unexpired payment card records from two companies, and deployed card-skimming code across live checkout environments.
The important shift is speed and economics. Gambit says one operator launched 105 attack projects between September 10 and September 15, 2026, while relying on a chain of AI-assisted tools for reconnaissance, exploitation, orchestration, and cleanup. Cloud Security Alliance’s analysis frames the case as a practical example of agentic attacker infrastructure compressing web exploitation, post-exploitation, and persistence into a workflow that can run faster than many teams can investigate.
For defenders, this belongs in the cybercrime queue, not the AI-hype queue. The campaign’s goals were payment theft, skimmer deployment, credential access, and operational persistence. Retailers, payment processors, and any organization running revenue-critical web applications should treat this as a warning about attacker tempo: exposed web flaws, weak admin paths, and fragile checkout integrity can now be tested and abused at machine pace.
What Happened
Gambit’s threat intelligence team says it recovered and analyzed the operator’s staging server, giving researchers visibility into the attacker’s tooling, prompts, logs, target lists, and exfiltrated data. According to the report, the activity began in July 2026 and was still running when the research was published on September 22.
The operator used three open-source AI harnesses:
- Strix for vulnerability discovery and reconnaissance.
- Cairn for autonomous exploitation and initial access.
- Hermes for campaign orchestration, tactical guidance, persistence, cleanup, and scheduled jobs.
SecurityWeek’s coverage notes that the operator used the tools to automate vulnerability research, exploitation, and attack orchestration. Gambit’s own numbers show how much of the campaign was delegated: 1,951 human prompts across 260 sessions, often short instructions in Chinese, with the agents handling much of the probing and exploitation between prompts.
The campaign focused on online retailers and e-commerce operators. Confirmed or suspected victim categories included a Fortune 500 hospitality company, a major U.S. airline, an industrial supplies distributor, and an online fashion retailer. Gambit says access, when successful, often happened in less than a day and sometimes within only a few hours.
Why This Is a Cybercrime Story
The campaign’s business model was direct monetization. The operator stole card data, placed skimmers on checkout pages, and maintained access where useful. That makes the dominant risk data breach, payment fraud, and card-not-present abuse rather than a single product vulnerability or espionage objective.
Gambit reports more than 600,000 payment card records stolen from two companies. Roughly 488,000 of those cards were issued in the United States. The same campaign also used skimmers against live checkout flows, with Gambit initially confirming 19 victim sites and later detecting more than 100 additional infected websites with help from security researcher Varys.
The cost model is equally important. Gambit estimated a mean cost of $25.46 across 101 completed scans, with some targets costing only a few dollars. CSA highlighted this as a strategic change: if large-scale probing and exploitation can be economically justified against minor or mid-market web properties, defenders cannot rely on obscurity, low profile, or attacker labor cost as a meaningful filter.
The Intrusion Pattern
The techniques were familiar; the automation changed the pace. In one documented path, the attack moved from unauthenticated SQL injection to MFA bypass, administrator access, arbitrary file upload, host-level remote code execution, privilege escalation, exposed NFS shares, WordPress database credentials, AWS Secrets Manager access, Magento database access, and payment data decryption.
None of those steps is exotic by itself. SQL injection, file upload abuse, exposed secrets, weak administrative paths, and brittle checkout deployment practices have been incident-response staples for years. What changed is that the tools could chain those opportunities across many targets with limited human steering.
The skimmer deployment methods also varied by environment. Gambit observed malicious code appended to legitimate JavaScript files, injected script tags, payloads hidden in Google tag blocks, S3 bucket poisoning, database content modification, Kubernetes initContainer changes, cached checkout-page poisoning, and cron jobs designed to reinsert skimmers after cleanup.
That variety matters for defenders. A checkout compromise is no longer always a single malicious script in a template file. It may live in a CDN object, a deployment manifest, a database field, a cache layer, or a scheduled task that quietly puts the malicious code back after an application redeploy.
The Cleanup Step Became a Destructive Step
One of the most useful lessons is not just that the attackers stole data. It is that the agent-driven cleanup logic created additional damage.
Gambit says a Hermes skill instructed the agent to wipe payment-card fields after extraction. In another case, a bicycle retailer lost data when cleanup logic dropped 180 database tables whose names matched staging or backup patterns. CSA called this a distinct risk category: autonomous attacker housekeeping can destroy evidence or production data even when destruction is not the primary monetization goal.
This is where incident response needs to move faster than a normal ticket queue. If a retailer suspects checkout compromise, preserving database snapshots, logs, object-store versions, deployment manifests, and checkout bundles should happen immediately and out of band. Waiting for a full investigation before preserving evidence gives automated cleanup routines too much time to erase the scene.
What Defenders Should Do Now
Retail and payment teams should start with checkout integrity. Compare production checkout JavaScript, tag-manager content, CDN assets, S3 objects, database-rendered content, Kubernetes manifests, and cache-generated pages against known-good versions. Look for new script tags, appended JavaScript, base64 loaders, unexpected external domains, and code that reappears after removal.
Application teams should review exposed e-commerce paths for the weaknesses this campaign chained repeatedly: SQL injection, unsafe file upload, weak admin panels, plugin-level remote code execution, overexposed NFS mounts, leaked WordPress credentials, broad cloud secret access, and Magento database paths. Patch management still matters, but in this case the larger lesson is attack-chain interruption.
Security operations teams should hunt for persistence around web infrastructure. Pay special attention to newly created cron jobs, unusual jobs under application or log directories, modified deployment manifests, changed object-store assets, unexpected writes to checkout bundles, and repeated modifications to the same JavaScript file shortly after remediation.
Incident response teams should assume evidence and backups may be targeted by automation. Take immediate out-of-band snapshots when compromise is suspected. Preserve payment databases, webroots, CDN versions, object-store versions, container manifests, and server-side cache artifacts before beginning normal cleanup.
Leadership should also revisit resilience planning. The question is not only whether a database can be restored. It is whether the minimum viable revenue path can be rebuilt quickly when checkout code, secrets, content stores, deployment automation, and backup tables may all be touched during the same intrusion.
Detection Priorities
Useful detection ideas include:
- Alert on checkout pages loading new third-party JavaScript domains.
- Monitor production JavaScript bundles for unexpected appended code or timestamp anomalies.
- Diff tag-manager blocks and CMS-rendered checkout content against approved versions.
- Watch for new cron jobs on web, application, and commerce hosts.
- Alert when object-store assets behind a checkout CDN are modified outside the deployment process.
- Monitor Kubernetes deployment changes that add initContainers or alter front-end workloads.
- Hunt for database writes to product descriptions, payment fields, checkout templates, and cached page models.
- Treat skimmer reappearance after cleanup as a sign of persistence, not a failed removal.
Invaders Take
This campaign is not proof that every attacker now has a magical autonomous intrusion team. It is proof that financially motivated operators can already stitch together open-source agents, commodity model access, and ordinary web weaknesses into a scalable cybercrime workflow.
The response should be practical. Retailers need tighter checkout integrity, faster evidence preservation, stronger secret boundaries, and a recovery plan that assumes attacker automation can move faster than human review. Security teams should focus less on whether a specific AI tool is novel and more on whether their web estate can withstand repeated, cheap, parallel probing.
The uncomfortable lesson is simple: when the cost of trying another target falls to a few dollars, attackers do not need to choose carefully. They can let the agents keep looking until a weak checkout path answers.
References
FAQ
Gambit Security has documented an active campaign in which a financially motivated operator used open-source AI harnesses to attack online retailers at scale. The reported impact is not theoretical: researchers say the campaign compromised more than 100 e-commerce sites, stole more than 600,000 unexpired payment card records from two companies, and deployed card-skimming code across live checkout environments.
Retail and payment teams should start with checkout integrity. Compare production checkout JavaScript, tag-manager content, CDN assets, S3 objects, database-rendered content, Kubernetes manifests, and cache-generated pages against known-good versions. Look for new script tags, appended JavaScript, base64 loaders, unexpected external domains, and code that reappears after removal.