How to Detect a Checkout Skimmer Before the Next Audit

In its September 22, 2026 report on an AI-assisted campaign against online retailers, Gambit Security describes attackers using AI agents in operations that included deploying payment skimmers. Its LinkedIn summary brought the campaign into view. These are Gambit's reported findings; CellWall has not independently verified the underlying victim data or the extent of AI autonomy.

Gambit acknowledges incomplete data and says attacker claims about AI use were corroborated where possible. That limits what we can conclude about the campaign. The workflow below is independent defensive guidance: you do not need to prove that an attacker used AI to investigate a changed script, unexpected form access, or a suspicious request from your payment page.

A skimmer can arrive through a compromised storefront or plugin, an unauthorized tag-manager publication, or a third-party script that starts delivering altered code. An approved loader can also fetch a new downstream script after the initial page load. The checkout may still complete normally while malicious code captures data or substitutes a payment form.

This is why third-party script monitoring must follow the loading chain and the user journey. Microsoft's web-skimming research documents techniques including fake forms and exfiltration through encoded image requests. That research supports the mechanisms described here; it does not independently validate Gambit's campaign. Magecart detection should focus on observable behavior as well as known indicators.

Capture the scripts actually delivered and executed during checkout: URLs, content fingerprints, inline code, loading initiators, frames, and dynamically introduced dependencies. Pair them with relevant HTTP headers and the approved deployment or tag-manager version. Payment page script integrity means investigating an unexplained difference, not automatically accepting the latest state as the baseline.

Legitimate vendor updates create changes too. Keep the approval separate from the observation: record who approved the specific change, for which checkout paths, and why. A familiar domain or matching script name does not establish that the bytes or behavior are safe. Start with the existing third-party JavaScript monitoring guide to build the inventory and ownership loop.

Look for scripts reading sensitive fields, adding input or submit listeners, replacing forms, overlaying new fields, or changing a payment frame's destination. Associate each observation with the responsible resource and its documented purpose. A payment SDK may legitimately handle fields; a marketing integration doing so deserves an explanation. Field access is a lead, not by itself proof of theft.

Correlate requests with the script, frame and interaction that initiated them. Review new recipients, unusual paths on existing hosts, request methods and timing around field entry or submission. Include fetch and XHR, image beacons and form submissions where visible. A new hostname is a useful lead, but an approved hostname can also carry an unauthorized request.

Exercise representative checkout variants with synthetic data: mobile and desktop, payment methods, consent states, and relevant regions or user states. Observe interactions through submission in an authorized test flow rather than stopping at page load. Sampling can miss conditional delivery, and encrypted or encoded content can limit interpretation. Do not collect real card values to prove a detection works.

The first malicious observation tells you when you first saw the behavior, not when the attacker installed it. A trustworthy earlier clean capture and a later malicious capture can help bracket a transition only for comparable paths and conditions. A clean desktop test does not bound a mobile-only skimmer. Missing telemetry, conditional delivery and retention gaps may leave the beginning unknown.

PCI DSS 6.4.3 addresses authorization, integrity and an inventory of payment-page scripts with written business or technical justification. PCI DSS 11.6.1 addresses detecting and alerting on unauthorized changes to security-impacting HTTP headers and payment-page contents as received by the browser. PCI SSC's payment-page security guidance explains their role in reducing e-skimming risk.

Requirement 11.6.1 permits evaluation at least weekly or at a frequency supported by a Requirement 12.3.1 targeted risk analysis. Real-time monitoring is not a universal PCI mandate. More frequent observation can reduce blind intervals, but coverage and response still matter. Confirm your applicable validation route: PCI SSC FAQ 1588 distinguishes the SAQ A script-attack eligibility criterion for embedded payment forms from ordinary redirects. Confirm obligations with the entity accepting your compliance validation.

Use the PCI DSS payment-page script checklist to organize authorization, integrity, change detection and response evidence. A product or a clean test alone does not establish compliance.