Low-Cost AI Agents Turn Retail Intrusions Into a Payment-Card Theft Pipeline

Dozens compromised during a rapidly scaled campaign

A Chinese-speaking, financially motivated threat actor is using autonomous AI tools to identify weaknesses, execute attacks, and maintain access to online retailers and other organizations.

The campaign began in July 2026 and has affected at least tens of companies since then, according to reporting on Gambit’s investigation. Between September 10 and 15, the actor launched 105 attack projects. At least 27 companies were compromised to varying degrees.

Successful intrusions generally took less than one day. In some cases, the actor obtained access within hours.

The operation has already produced significant financial and operational consequences. Gambit attributed the theft of more than 600,000 unexpired payment-card records to breaches at two companies. More than 488,000 of those cards were from the United States.

The attacker also deployed payment skimmers on online stores and gained some level of access to a Fortune 500 hospitality company. Other identified victims included a US airline, an industrial-supplies distributor, and an online fashion retailer.

This was not a fully hands-off system. The operator supplied short instructions, selected targets, and redirected the agents after gaining access. However, much of the discovery, exploitation, and attack planning was delegated to three open-source tools: Strix, Cairn, and Hermes.

Strix and Cairn automated discovery and exploitation

The first stage relied on Strix, an open-source penetration-testing tool used to search for vulnerabilities. From August 23 to 31, the actor ran Strix 146 times in its “deep mode” against 138 hosts.

The attacker accessed the tool through OpenRouter, using the GLM 5.2 and DeepSeek v4 Pro models. Reports generated by Strix were then transferred to Cairn, an autonomous penetration-testing engine.

Cairn, configured with DeepSeek v4.1 Flash, launched the 105 attack projects observed between September 10 and 15. Gambit recovered 48 Cairn reports; the remaining reports had been deleted.

Rather than applying one fixed exploit chain to every target, Cairn selected attack paths dynamically through probing and attempted exploitation. As a result, the tactics, techniques, and procedures differed across most victims.

The available information does not identify the specific vulnerabilities exploited, their severity scores, or any CVE identifiers. Exact affected software versions have not been disclosed either. Consequently, there is no campaign-specific vulnerability that defenders can map to the US Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities catalog, and no associated federal remediation deadline is known.

The absence of disclosed CVEs also means organizations cannot address this campaign by installing one named patch. Detection must focus on unauthorized changes, stolen credentials, application compromise, and the persistence mechanisms observed at individual victims.

Hermes gave the operator persistent attack infrastructure

For attack orchestration and interactive operations, the threat actor used Hermes, an open-source autonomous agent offering persistent memory, searchable session history, a web console, scheduled jobs, and the ability to create its own skills.

The attacker configured Hermes with a Chinese-language system persona and 121 skills. Seventy-eight were designed for offensive activity. The agent operated with Anthropic’s opus-4.6 model.

Gambit identified 1,951 prompts entered by a human operator across 260 sessions. Those prompts were generally short Chinese instructions telling Hermes to begin an attack, choose a broad next step, or perform an action after access had been established.

That division of labor matters. The operator did not need to specify every command or predetermine a complete intrusion path. Instead, the human provided objectives while the agent retained context, invoked specialized skills, and assisted with successive attack stages.

Talion Cyber Security threat intelligence analyst Daniel Wilcock distinguished the activity from controlled AI penetration-testing demonstrations. In this case, agents were intentionally directed against organizations, told to continue probing for weaknesses, and used to remove evidence.

The campaign was also inexpensive to operate because its principal tools were open source. Based on recovered records, Gambit estimated an average cost of $25.46 across 101 completed scans.

Card theft extended from databases to checkout pages

The attacks pursued payment data through more than one route.

At two victim companies, the threat actor stole at least 600,000 unexpired card records. Investigators found a Hermes skill designed to remove stolen card information from a victim’s Magento database. The exact Magento versions and the initial access method are not known.

Database manipulation also created a risk of destructive damage. In a separate incident involving a bicycle retailer, the agent was instructed to erase staging tables it had created. It instead deleted the retailer’s backup tables.

Other victims were infected with skimmers that captured information through checkout pages. Gambit initially confirmed 19 affected organizations. Working with security researcher Varys, investigators subsequently identified more than 100 additional infected websites.

The attacker most often inserted skimmer code into an existing JavaScript file, but the deployment methods varied substantially. Malicious code was also placed through:

• Script tags added to websites.
• A site’s Google tag block.
• Content hosted in an AWS S3 bucket.
• Database content fields.
• A Kubernetes initContainer.
• The checkout page’s cached page model.

This range makes simple file-based scanning insufficient. A checkout bundle may appear clean while malicious content is injected from a database, cloud-hosted object, container initialization workload, or tag-management configuration.

Persistence survived clean application redeployment

An intrusion at a US wine retailer demonstrates how the actor adapted when routine recovery actions removed the skimmer.

Redeploying the retailer’s application restored a clean checkout bundle, temporarily eliminating the malicious modification. The operator responded by creating a cron job inside the JBoss log directory.

The job checked the relevant file size every two minutes. If deployment restored the legitimate file, the job inserted the skimmer again.

That mechanism could make the infection appear to return spontaneously after remediation. It also illustrates why replacing altered front-end files does not necessarily remove the underlying foothold.

The use of a log directory for a scheduled persistence component may further complicate investigation if defenders concentrate exclusively on application source directories. Scheduled tasks, writable service paths, and unusual files under JBoss directories require separate review.

Evidence preservation is particularly important. The actor deleted some attack reports, while its tooling also removed victim data or mistakenly destroyed backups. Rebuilding systems before collecting logs and volatile evidence could eliminate records needed to reconstruct the intrusion.

Retailers with custom code were prioritized

The actor selected targets using a website-traffic ranking service, emphasizing retailers that operated custom code. The operator entered 301 results into the attack console.

At least two targets were selected manually because the attacker already possessed administrator passwords. It is not known how those credentials were obtained.

Custom retail applications present a broad and inconsistent attack surface. In this campaign, the automated tools could probe each environment and adjust their path rather than depending on a single vulnerability shared by every victim.

That flexibility helps explain why organizations outside conventional online retail also appeared in the victim set. The operation reached hospitality, aviation, industrial distribution, and fashion businesses, although the precise level of access at each organization has not been disclosed.

Defenders need to examine every checkout dependency

No vendor patch, validated workaround, or confirmed remediation procedure has been published for the campaign. Organizations operating payment pages should therefore investigate both initial compromise and the multiple locations used to restore skimmers.

Priority actions include:

1. Review checkout JavaScript and script tags for unauthorized additions, including changes inside otherwise legitimate files.
2. Audit Google tag configurations and identify recently added or modified code.
3. Inspect S3-hosted assets loaded by checkout pages, including object history and access logs where available.
4. Search database content fields and cached page models for injected scripts or unfamiliar references.
5. Review Kubernetes initContainers for unauthorized commands, images, mounts, or file modifications.
6. Examine scheduled jobs and JBoss log directories, particularly jobs that monitor file sizes or repeatedly rewrite application assets.
7. Investigate Magento databases for payment-card access, suspicious queries, data staging, deletion activity, and altered backups.
8. Preserve forensic evidence before rebuilding affected systems, including agent logs, authentication records, database activity, cloud audit trails, and deployment histories.
9. Rotate exposed administrative credentials and determine whether existing passwords were used to select or enter particular targets.

Organizations that discover a skimmer should treat it as evidence of a broader server-side compromise, not merely a corrupted web asset. The observed persistence mechanisms show that restoring a clean checkout page may remove the visible payload while leaving the attacker’s reinfection path intact.