AI retail skimming campaign points to modular attack pipelines

What is known about the tooling

The reported toolchain had three distinct roles.

Strix, an open-source AI penetration-testing tool, was used for vulnerability hunting. SecurityWeek reported that it ran 146 times in “deep mode” against 138 hosts between August 23 and August 31, using OpenRouter with GLM 5.2 and DeepSeek v4 Pro.¹ CSA characterized Strix as the reconnaissance and vulnerability discovery component.²

Cairn, described as an autonomous penetration-testing engine, received target domains and objectives, then attempted exploitation. SecurityWeek reported that Cairn was used to launch 105 attack projects between September 10 and September 15 on DeepSeek v4.1 Flash, and that Gambit retrieved 48 attack reports because others had been deleted.¹ CSA said Cairn could operate independently for hours, attempting exploitation until it succeeded, timed out, or was stopped.²

Hermes appears to have been the orchestration and post-exploitation layer. SecurityWeek reported that Hermes had persistent memory, self-written skills, a searchable session archive, scheduled jobs, and a web console; the operator loaded a Chinese system persona and 121 skills, including 78 attack skills.¹ TechRadar reported that Hermes ran on Anthropic’s opus-4.6 after newer models refused the requested actions, and that Gambit counted 1,951 human-typed prompts across 260 sessions — only a few prompts per target.³

That division of labor is the key development. Traditional automation can scan, exploit known flaws, or deploy malware at scale. This campaign illustrates a more flexible, pipeline-like use of AI systems to make decisions across heterogeneous environments, including custom e-commerce stacks. CSA noted that the individual techniques were familiar, but that the significant change was compressing a multi-stage intrusion chain into a workflow a lightly supervised agent pipeline could repeat across unrelated targets.²

How the pipeline changes speed and labor

The reported workflow changes the attacker labor model in three ways.

First, reconnaissance becomes continuous and cheap. Target selection reportedly drew from a website traffic ranking service, with the operator pasting hundreds of results into the console and focusing on shops running custom code.¹ That matters because bespoke retail applications have historically required more manual review than commodity platform exploitation. P.K. Sharma’s practitioner analysis argued that the campaign did not out-scale older mass skimming campaigns; instead, it made bespoke intrusion newly affordable, expanding the set of retailers worth attacking individually.⁵

Second, exploitation becomes parallelized and less dependent on one operator’s moment-to-moment judgment. Pivot News reported that where access was achieved, it usually took less than a day and often only a few hours.⁴ CSA noted that a single operator issued fewer than 2,000 short prompts across 260 sessions while sustaining 105 distinct attack waves in less than a week.² That ratio suggests the human role was closer to tasking, supervising, and redirecting than manually executing each step.

Third, post-exploitation and persistence become part of the automated workflow. SecurityWeek reported skimmer placement in existing JavaScript files, script tags, Google tag blocks, AWS S3 buckets, database content fields, a Kubernetes initContainer, and cached checkout page models.¹ Pivot News reported one persistence method in which a cron job in a JBoss log directory checked a file size every two minutes and reappended the skimmer after redeployments restored a clean checkout bundle.⁴

For defenders, repeated reappearance of malicious code should not be treated only as a cleanup failure. It may indicate orchestration logic that is monitoring the victim environment and automatically undoing remediation.

What the card-theft numbers do and do not prove

The largest reported figure — more than 600,000 payment card records — needs careful interpretation. SecurityWeek reported that the attackers stole information from more than 600,000 unexpired credit cards from two compromised companies and injected skimmer scripts into five online stores, while later identifying many additional infected websites with researcher Varys.¹

Sharma’s analysis cautioned that the 617,938-card figure came from two databases, not from 100 skimmed sites, and argued that defenders should separate database exfiltration counts from confirmed skimmer installations and associated skimmer sites.⁵ That distinction matters for incident response and risk communication. A large card count does not necessarily mean every infected storefront produced the same volume of stolen payment data, or that all reported sites were compromised in the same way.

The more defensible conclusion is narrower but still serious: the campaign combined database theft, skimmer deployment, and agent-assisted post-exploitation across multiple e-commerce environments, with enough automation to reduce the cost and time required per target.

What defenders can verify now

Security teams do not need to wait for perfect attribution or complete victim lists to act. The reported injection methods leave observable changes in merchant-controlled assets.

Start with checkout JavaScript. Compare current checkout bundles, first-party libraries, tag-manager snippets, and inline scripts against known-good builds. File modification times are not enough; Sharma’s analysis noted that appended JavaScript can evade simple timestamp checks, while content hashing would catch the change.⁵

Review CDN and S3-backed content. SecurityWeek reported skimmer placement in an AWS S3 bucket, and CSA recommends auditing CDN and S3 contents along with checkout-page JavaScript and Content Security Policy settings.¹² Where possible, check object version history, CloudTrail events, bucket policy changes, and recent access-key use.

Inspect database-backed content and templates. Skimmer code may live in product descriptions, CMS fields, checkout page templates, cached page models, or tag-manager blocks rather than only in source files.¹⁵ This should push teams beyond host-based file integrity monitoring and into database diffing, template review, and cache validation.

Check persistence mechanisms. CSA specifically recommends looking for newly created or modified cron jobs, unexpected Kubernetes deployment manifest changes, and unauthorized modifications to NFS-mounted shares.² Pivot’s account of the JBoss-directory cron job shows why: a skimmer that returns after redeployment may be maintained by a local persistence mechanism rather than by a second manual intrusion.⁴

Validate e-commerce stack exposure. CSA recommends confirming that Magento, WordPress-based storefronts, plugins, and extensions are patched against known SQL injection and file-upload vulnerabilities, because these were among the documented entry points in the campaign’s intrusion chains.²

Protect backups before deep cleanup. CSA reported that automated cleanup logic destroyed database tables at one victim, including backup tables, after being instructed to erase staging tables.² Incident responders should snapshot affected systems out of band before broad cleanup, rebuild, or restore operations.

Reassess browser-side controls, but do not rely on them alone. Content Security Policy can help, especially with restrictive connect-src controls, but Sharma’s analysis notes that scripts appended to first-party bundles or served from a merchant’s own CDN may still satisfy common allowlists.⁵ Subresource Integrity and synthetic checkout monitoring can add coverage, but the campaign’s methods show that estate-change detection — files, buckets, database rows, manifests, caches, and cron — remains central.

Strategic takeaway

The campaign’s significance is less about a breakthrough exploit than about operational architecture. AI-enabled attacks are beginning to look like modular engineering systems, with reconnaissance, exploitation, orchestration, persistence, and cleanup assigned to specialized components that can be reused across targets.

For security leaders, the defensive response should mirror that modularity. Asset inventory, code integrity, cloud object monitoring, Kubernetes drift detection, database change review, checkout-page telemetry, and incident-response backup handling need to be treated as one control chain around the e-commerce path. If attackers can turn web exploitation into a low-cost pipeline, defenders need comparable continuity across the places where that pipeline leaves traces.