AI-Agent-Driven Magecart Campaign: 600K Credit Cards Stolen From 100+ Online Retailers — Detection and Hardening Guide

Security researchers have disclosed a financially motivated campaign in which a threat actor is using open-source AI agent frameworks to attack hundreds of online retailers at scale — infecting more than 100 sites with payment card skimmers and exfiltrating over 600,000 credit card records. This is not a proof of concept. It is a production criminal operation, and it represents a meaningful shift in the economics of web skimming: the reconnaissance, vulnerability discovery, exploitation, and skimmer deployment phases are being executed autonomously by AI agents, allowing a single operator to run what previously required an entire crew.

If you operate or defend any e-commerce property — Magento/Adobe Commerce, WooCommerce, Shopify-adjacent custom builds, or bespoke checkout stacks — you are in scope for this campaign. The attackers are not targeting one platform; they are targeting the entire class of internet-facing retail infrastructure, and the automation layer means the dwell time between initial compromise and live skimming is collapsing from weeks to hours.

This post breaks down the attack chain, gives your SOC concrete detection logic (Sigma, KQL, and VQL), and provides a hardening and verification script you can run today.

Technical Analysis

What Makes This Campaign Different

Classic Magecart operations were manual: scan for vulnerable stores, exploit, plant a webshell, inject a skimmer into checkout JavaScript, stand up exfiltration infrastructure, monetize. Each phase was rate-limited by human operator time. The actor behind this campaign has wired those phases together using open-source AI agent frameworks — the same class of tooling defenders see legitimately used for task orchestration and code generation. The agent handles target enumeration, vulnerability triage, payload adaptation per-platform, and even skimmer obfuscation, while the human operator supervises and handles monetization.

The practical consequences for defenders:

• Volume: 100+ confirmed infected sites, hundreds targeted. Signature-based blocklists of "known Magecart domains" will not keep pace — the agent can spin up fresh exfil domains per victim or per wave.
• Speed: The gap between initial access and live skimming is compressed. Detection windows measured in days are now measured in hours.
• Polymorphism: AI-generated skimmers vary per deployment — different variable names, encoding schemes, and injection points — which degrades YARA-style static matching and makes behavioral detection the priority.

Attack Chain (Defender's View)

Based on the reported tradecraft, the campaign follows a consistent, observable sequence:

1. Reconnaissance: Automated scanning of internet-facing retail sites to fingerprint the e-commerce platform, version, and exposed admin panels. Expect probing of paths like /admin, /wp-admin, /downloader, /rest/V1, and version-disclosure files.
2. Initial Access: Exploitation of known, unpatched e-commerce platform vulnerabilities and exposed management interfaces, or abuse of stolen credentials for admin panels. No CVE identifier has been published for this campaign — the common denominator is unpatched, internet-reachable retail infrastructure, not a single novel bug.
3. Persistence: Deployment of PHP webshells or malicious admin accounts, plus modification of core platform files so the skimmer survives cache flushes and casual cleanup.
4. Skimmer Injection: Malicious JavaScript is injected into checkout flows — appended to legitimate JS bundles, inserted into database-stored template/header blocks (a classic Magento pattern via miscellaneous scripts config), or loaded from attacker-controlled domains designed to mimic legitimate analytics/Tag Manager infrastructure.
5. Exfiltration: Harvested card data (PAN, CVV, expiry, billing address) is POSTed — often base64- or XOR-encoded — from the victim's browser to attacker infrastructure. Note this critical detail: exfiltration happens client-side, so your server's egress firewall sees nothing. Your customers' browsers are the exfil channel.

Exploitation Status

• Active, confirmed in-the-wild exploitation across 100+ sites with 600,000+ stolen card records.
• No CVE is associated with this disclosure; do not wait for a CVE-centric patch cycle. This is an operational threat requiring configuration hardening, integrity monitoring, and behavioral detection.
• Skimming attacks of this class are the primary driver of PCI-DSS 4.0 requirements 6.4.3 and 11.6.1 (payment page script inventory/authorization and tamper detection) — if you are PCI-scoped, you already have a compliance mandate to detect exactly this.

Detection & Response

The following detections target the server-side observable behaviors of this campaign: webshell deployment by web server processes, unauthorized modification of checkout assets, and anomalous execution chains under the web service account. Client-side controls (CSP, SRI, script inventory) are covered in Remediation and are equally critical.

Sigma Rules

---
title: Web Server Process Spawning Shell or Download Utility
id: 3f9a1b72-6c4e-4d81-9a27-8e5c2f401ab6
status: experimental
description: Detects nginx, Apache, or PHP-FPM worker processes spawning shells, downloaders, or scripting interpreters — a hallmark of webshell activity following e-commerce platform compromise, as seen in AI-agent-driven skimmer campaigns.
references:
  - https://www.bleepingcomputer.com/news/security/malicious-ai-agents-steal-600k-credit-cards-infect-100-plus-sites-with-skimmers/
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1505.003
  - attack.execution
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/nginx'
      - '/apache2'
      - '/httpd'
      - '/php-fpm'
      - '/php-fpm8.1'
      - '/php-fpm8.2'
      - '/php-fpm8.3'
  selection_child:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/dash'
      - '/curl'
      - '/wget'
      - '/perl'
      - '/python'
      - '/python3'
      - '/base64'
      - '/nc'
      - '/ncat'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate application deployment pipelines executing under the web user (scope these by CI/CD host or time window)
  - Monitoring/backup agents invoking curl from PHP-FPM cron contexts
level: high
---
title: Webshell-Like PHP File Created in Web-Accessible Directory
id: 8c2e5d14-4b7a-4f39-b1c6-2d9a7e305812
status: experimental
description: Detects creation of PHP files in upload, media, cache, or temporary web directories — a common persistence and post-exploitation step in Magecart-style e-commerce compromises where attackers stage webshells before injecting skimmers.
references:
  - https://www.bleepingcomputer.com/news/security/malicious-ai-agents-steal-600k-credit-cards-infect-100-plus-sites-with-skimmers/
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection_paths:
    TargetFilename|contains:
      - '/uploads/'
      - '/upload/'
      - '/media/'
      - '/pub/media/'
      - '/var/cache/'
      - '/var/tmp/'
      - '/tmp/'
      - '/images/'
      - '/static/'
  selection_ext:
    TargetFilename|endswith:
      - '.php'
      - '.phtml'
      - '.phar'
      - '.php5'
      - '.php7'
  filter_legit_upload_paths:
    TargetFilename|contains:
      - '/var/www/'
      - '/srv/www/'
  condition: selection_paths and selection_ext and filter_legit_upload_paths
falsepositives:
  - Legitimate plugin/theme installations writing PHP into media trees (rare — investigate all hits)
  - Developer deployments outside change windows
level: high
---
title: Checkout or Payment JavaScript Modified on Web Server
id: 5a7d3f91-2e6c-48b4-a932-1f4b8c607d3a
status: experimental
description: Detects modification or creation of JavaScript files with checkout/payment-related names in web root directories — the direct injection point for payment card skimmers. Any unsanctioned change to checkout JS on a production retail host is a high-fidelity signal.
references:
  - https://www.bleepingcomputer.com/news/security/malicious-ai-agents-steal-600k-credit-cards-infect-100-plus-sites-with-skimmers/
  - https://attack.mitre.org/techniques/T1189/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.impact
  - attack.t1657
  - attack.t1189
logsource:
  category: file_event
  product: linux
detection:
  selection:
    TargetFilename|contains:
      - '/var/www/'
      - '/srv/www/'
      - '/usr/share/nginx/'
      - '/htdocs/'
    TargetFilename|endswith: '.js'
    TargetFilename|contains:
      - 'checkout'
      - 'payment'
      - 'cart'
      - 'billing'
      - 'onepage'
      - 'opc'
      - 'order'
      - 'cc'
  filter_static_pipeline:
    User|contains:
      - 'deploy'
      - 'jenkins'
      - 'github'
  condition: selection and not filter_static_pipeline
falsepositives:
  - Deployment pipelines modifying checkout assets — scope filter_static_pipeline to your actual deploy accounts/hosts
  - Cache-busting regeneration by the platform (correlate with known maintenance windows)
level: critical

KQL — Microsoft Sentinel / Defender

This hunt looks for web server or PHP processes initiating outbound network connections — server-side processes like php-fpm and nginx serve requests; they should almost never originate connections to arbitrary internet hosts. This catches webshell-driven exfil staging, payload retrieval, and C2. It assumes Linux web host telemetry via Defender for Endpoint or Syslog/CEF ingestion.

// Hunt: Web server / PHP processes originating outbound connections (webshell behavior)
let WebProcs = dynamic(["nginx", "apache2", "httpd", "php-fpm", "php", "php8.1-fpm", "php8.2-fpm", "php8.3-fpm", "www-data"]);
let AllowedDestinations = dynamic(["api.stripe.com", "api.braintreegateway.com", "fonts.googleapis.com", "cdn.jsdelivr.net"]);
DeviceNetworkEvents
| where TimeGenerated > ago(24h)
| where InitiatingProcessFileName in~ (WebProcs) or InitiatingProcessAccountName =~ "www-data"
| where RemotePort in (443, 80, 8443)
| where RemoteUrl !in~ (AllowedDestinations)
| where not(ipv4_is_private(RemoteIP))
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            ConnectionCount = count(), DistinctDestinations = dcount(RemoteIP),
            RemoteUrls = make_set(RemoteUrl, 20)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteIP, RemotePort
| order by ConnectionCount desc;

For environments ingesting Syslog from web hosts, correlate file-modification telemetry against checkout assets:

// Hunt: Modifications to checkout/payment assets reported via Syslog file integrity monitoring (e.g., auditd, AIDE, Wazuh)
Syslog
| where TimeGenerated > ago(48h)
| where Facility =~ "auditd" or ProcessName has_any ("aide", "wazuh", "ossec", "fim")
| where SyslogMessage has_any ("checkout", "payment", "onepage", "billing", "cart")
| where SyslogMessage has_any (".js", ".phtml", ".php")
| where SyslogMessage has_any ("modify", "write", "create", "changed")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc;

Velociraptor VQL

Use this hunt artifact across your Linux web fleet to surface recently modified executable and script content in web roots — the footprint of webshells and skimmer injection. Pair it with the network check below to catch PHP-FPM holding unexpected established connections.

-- Hunt: Recently modified PHP/JS files in web roots (potential webshells and skimmer injection points)
LET lookback = 7 * 24 * 3600  // 7 days in seconds

SELECT FullPath,
       Mtime AS ModifiedTime,
       Size,
       Mode
FROM glob(globs=['/var/www/**/*.php', '/var/www/**/*.phtml', '/var/www/**/js/**/*.js',
                 '/srv/www/**/*.php', '/usr/share/nginx/**/*.js', '/home/*/public_html/**/*.php'])
WHERE Mtime > (now() - lookback)
ORDER BY ModifiedTime DESC

-- Hunt: Web service processes with established outbound connections (webshell/exfil channel)
SELECT Pid,
       Name,
       CommandLine,
       Username,
       netstat().LocalIP AS LocalIP,
       netstat().LocalPort AS LocalPort,
       netstat().RemoteIP AS RemoteIP,
       netstat().RemotePort AS RemotePort,
       netstat().State AS ConnState
FROM pslist()
WHERE (Name =~ 'php|nginx|apache|httpd' OR Username =~ 'www-data|nginx|apache')
  AND netstat().State =~ 'ESTABLISHED'
  AND netstat().RemotePort IN (80, 443, 8443)

Note on fidelity: the outbound-connection rules will fire on legitimate payment gateway API calls (Stripe, Braintree, Adyen) and CDN fetches. Tune the allowlist to your stack once, and the residual is a genuinely high-signal detection — in most mature environments, php-fpm talking to an unknown host on 443 is worth paging on.

Remediation / Verification Script

Run this on suspected or in-scope Linux web hosts. It performs non-destructive checks: recently modified web content, suspicious script tags and obfuscation patterns in checkout assets, PHP execution in upload directories, rogue admin users (Magento/WooCommerce), and unexpected outbound connections from web processes. Review output before taking containment action.

#!/bin/bash
# Security Arsenal — E-commerce skimmer triage script (non-destructive)
# Run as root or with sudo on the web host.

WEBROOTS="/var/www /srv/www /usr/share/nginx /home"
DAYS=14
echo "===== [1] Recently modified PHP/JS in web roots (last ${DAYS} days) ====="
find $WEBROOTS -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.js" \) -mtime -${DAYS} -ls 2>/dev/null | head -200

echo "===== [2] PHP files in upload/media/cache directories ====="
find $WEBROOTS -type d \( -name "uploads" -o -name "media" -o -name "cache" -o -name "tmp" \) 2>/dev/null | while read d; do
  find "$d" -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) -ls 2>/dev/null
done

echo "===== [3] Suspicious script injections & obfuscation in checkout JS ====="
grep -rIl --include="*.js" -E "(atob\(|fromCharCode|\\x[0-9a-f]{2}\\x[0-9a-f]{2}|eval\(|new Function)" $WEBROOTS 2>/dev/null | head -50
echo "--- External script tags referencing non-whitelisted domains ---"
grep -rIho --include="*.html" --include="*.phtml" --include="*.php" -E '<script[^>]+src=["'"'"']https?://[^"'"'"' >]+' $WEBROOTS 2>/dev/null | sort -u | head -100

echo "===== [4] Magento: injected scripts in core_config_data ====="
if command -v mysql >/dev/null 2>&1; then
  echo "Run manually against your Magento DB:"
  echo "  SELECT path, value FROM core_config_data WHERE value LIKE '%<script%' OR value LIKE '%atob%' OR value LIKE '%fromCharCode%';"
fi

echo "===== [5] Rogue admin users ====="
echo "Magento: SELECT user_id, username, email, created FROM admin_user ORDER BY created DESC LIMIT 10;"
echo "WordPress: SELECT ID, user_login, user_email, user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 15;"
echo "WordPress admins: SELECT u.user_login FROM wp_users u JOIN wp_usermeta m ON u.ID=m.user_id WHERE m.meta_key='wp_capabilities' AND m.meta_value LIKE '%administrator%';"

echo "===== [6] Outbound connections from web service processes ====="
ss -tnp 2>/dev/null | grep -E "ESTAB" | grep -E "php|nginx|apache|httpd|www-data" | head -50

echo "===== [7] Unexpected cron / systemd persistence for web user ====="
crontab -l -u www-data 2>/dev/null; crontab -l -u nginx 2>/dev/null; crontab -l -u apache 2>/dev/null
ls -la /etc/cron.d/ 2>/dev/null

echo "===== Triage complete. Preserve disk image and web/access logs before remediation. ====="

If checks 1–4 return unexpected hits on a production store: treat it as a confirmed incident. Preserve evidence first (disk snapshot, access logs, database dump of config tables), then rebuild from known-good code rather than cleaning in place — skimmer operators consistently leave secondary persistence that survives surface cleanup.

Remediation & Hardening

There is no single patch for this campaign — remediation is architectural. Prioritize in this order:

Immediate (24–72 hours):

1. Run the triage script above against every internet-facing retail host. Any unauthorized change to checkout assets is a reportable incident — engage your IR retainer and assess PCI breach-notification obligations (card brands and, depending on jurisdiction, state attorneys general and GDPR authorities; 600K-record campaigns mean regulators are watching this threat class closely).
2. Rotate everything: e-commerce admin credentials, API keys, database passwords, SSH keys, and payment gateway secrets. Enforce phishing-resistant MFA on all admin panels — credential abuse is a primary initial-access vector here.
3. Deploy a strict Content Security Policy on checkout pages with script-src limited to an explicit allowlist of your payment processor and tag manager domains, plus report-uri/report-to so violations alert you in near-real time. CSP is the single highest-leverage client-side control against skimmer exfiltration because it breaks the browser-to-attacker channel even if injection succeeds.
4. Subresource Integrity (SRI) on all third-party scripts, and pin/remove any third-party tag on checkout pages that isn't strictly required for payment processing.

Short term (1–2 weeks):

5. File integrity monitoring (FIM) on web roots with alerting on any modification to checkout/payment assets — this satisfies PCI-DSS 4.0 requirement 11.6.1, which is now a hard requirement (the March 2025 future-dated deadline has passed; assessors are testing it).
6. Payment page script inventory and authorization per PCI-DSS 6.4.3: maintain a written justification for every script executing on payment pages, and block anything not on the list.
7. Patch the platform: apply all outstanding security updates for Magento/Adobe Commerce, WooCommerce and its plugin ecosystem, and any third-party checkout modules. Disable or remove unused extensions — they are the highest-risk attack surface. Restrict admin panels by IP allowlist or place them behind SSO/VPN.
8. Block PHP execution in upload/media directories at the web server layer (location blocks in nginx, php_flag engine off in Apache), and ensure the web user cannot write to code directories in production.

Structural:

9. Rebuild don't clean any confirmed-compromised host from known-good artifacts and IaC. Diff the database config tables against a pre-incident backup — Magento skimmers frequently live in core_config_data, not on disk.
10. Assume AI-agent-speed adversaries in your monitoring design: detection logic must alert within minutes of a checkout-asset change, not in a nightly batch. The operator-side automation in this campaign means your dwell-time budget is hours.
11. Threat-hunt retroactively: pull 90 days of access logs and look for the reconnaissance pattern — automated platform fingerprinting, admin-panel probing, and bursts of POSTs to webshell paths — to determine whether you've already been visited.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub