Sophisticated Magecart-Style Campaign Targets Nearly 1,000 Magento Stores with Advanced Anti-Analysis Evasion Techniques

CYBERSECURITY INVESTIGATION — E-commerce security researchers have uncovered an ongoing, highly sophisticated digital skimming and malicious injection campaign that has successfully compromised at least 953 online retail stores—predominantly running on Adobe’s Magento e-commerce platform. Active since July 2025, this operation distinguishes itself from traditional cybercrime campaigns through its calculated deployment of advanced anti-analysis mechanisms, aggressive browser fingerprinting, and persistent database-level persistence that routinely bypasses standard automated security scans.

Discovered and tracked by security firm Sansec, the campaign underscores a worrying evolution in web-based threat vectors. Rather than merely grabbing credit card details via noisy, easily detectable JavaScript injects, the threat actors behind this operation have designed a stealthy, multi-tiered loader that actively probes incoming requests to determine whether a browser is operated by a human shopper or a security researcher.

Main Facts: The Anatomy of a Stealthy E-Commerce Threat

At the core of the operation is a malicious JavaScript loader strategically concealed within the cms_block table of the targeted Magento databases. Because the malicious code resides directly within the database rather than as a physical, modified file on the web server’s filesystem, it is natively rendered as standard, legitimate CMS content whenever a customer visits the storefront.

When a user loads an infected e-commerce page, their browser executes the injected script, which immediately initiates contact with infrastructure controlled by the threat actors to fetch subsequent malicious instructions. However, the most striking innovation of this campaign is its gatekeeping logic.

Before the loader executes any secondary payloads or interacts further with the visitor, it performs rigorous client-side and server-side checks. By evaluating browser behavior, hardware specifications, screen sizes, time zones, and language configurations, the script attempts to identify automated browser instances, headless testing environments, and security auditing tools (such as urlscan.io). If the script detects the hallmarks of a scanner, it terminates its routine, returning a completely benign, clean response. Consequently, automated vulnerability scanners routinely report that the infected websites are entirely secure and free of anomalous injections.

The campaign’s infrastructure has been notably dynamic, cycling through at least five distinct domains to evade domain-level blocklists and sinkholing efforts. The most recently identified domain, registered on October 6, was subsequently deployed within the CMS blocks of 83 distinct online stores—60 of which had previously hosted an earlier iteration of the exact same loader. This high rate of recidivism demonstrates that these infections are not isolated, opportunistic drive-by compromises, but rather part of a tightly managed, repeatedly re-infected estate.

Chronology of an Evolving Campaign: From Keitaro TDS to Custom Fingerprinting

The threat actors behind this campaign have continuously refined their tactics, techniques, and procedures (TTPs) across several distinct operational phases throughout 2025 and late 2026.

Early Phase and the Keitaro TDS Dependency (Mid-2025 to September 2026)

During the early months of the campaign, the malicious operators relied heavily on established commercial infrastructure to manage their traffic. Specifically, they utilized the Keitaro Traffic Distribution System (TDS). When a victim loaded an infected page, the script routed through Keitaro to dynamically decide whether to serve a malicious payload, redirect the user elsewhere, or serve an empty response. While effective at masking the operation, this reliance on an intermediary introduced external network calls that could sometimes be intercepted or flagged by robust enterprise monitoring tools.

The October Shift: Direct-to-Domain Architecture

A pivotal shift occurred on October 7, 2026, when Sansec researchers identified a heavily rewritten loader script that completely eliminated the Keitaro intermediary. Instead of routing traffic through a third-party TDS, the new script called the threat actors’ newly provisioned domain directly. Furthermore, it introduced localized payload caching: once a visitor’s browser successfully received the payload, the code was stored locally in the browser environment. On subsequent page loads, the browser would execute the cached script locally, ensuring that the malicious routine could execute even if the command-and-control (C2) domains were temporarily taken down, blocked, or sinkholed.

The October 23 Refinement: Advanced Browser Fingerprinting

Just over two weeks later, on October 23, the attackers deployed another major code revision. This iteration introduced comprehensive browser fingerprinting capabilities. Before delivering any further instructions, the script exhaustively inventories the visitor’s hardware footprint, screen dimensions, localized time zones, and browser language settings. The server processes this multidimensional profile to differentiate between genuine consumers and automated analysis tools.

Despite capturing these extensive telemetry metrics, security researchers have not yet successfully extracted the campaign’s ultimate final-stage payload. Because the loader can successfully reach advanced operational stages without ever deploying a visible or malicious functional payload to targeted browsers, the immediate impact manifests primarily as a severe supply-chain and integrity failure for the merchant, rather than an immediately classifiable financial fraud pattern for the end consumer.

Supporting Data: Vulnerabilities, Persistence, and the Myth of Patching Alone

A common misconception in web application security is that applying core software patches immediately eradicates an existing compromise. This campaign provides a textbook, sobering case study proving why patching alone is insufficient in the face of persistent threat actors.

Initial Access Vectors: WebShells and Exploits

In March 2026, a massive wave of this campaign planted the malicious loader across 471 online stores within a single hour. Investigations revealed that the primary entry points leveraged sophisticated web shells planted via vulnerabilities such as PolyShell (tracked as CVE-2026-48356). A detailed forensic audit of 169 infected Magento 2 installations lacking at least one critical core security patch revealed definitive evidence of file uploads via PolyShell and SessionReaper (CVE-2025-54236) in 102 of those environments.

The Patch Paradox: Why Updates Fail to Clean Existing Infections

The clearest demonstration of the limits of patching is highlighted by a specific Magento 2.4.7-p10 store monitored by Sansec. This particular merchant maintained a fully patched core system and successfully passed a comprehensive security scan. Yet, exactly one hour after passing the scan on October 23, the store was found hosting the newest iteration of the loader.

Forensic analysis of the same store from the preceding September revealed the root cause: attackers had previously established a rogue, unauthorized administrator account alongside a stealthy GSocket backdoor. While subsequent patching closed the software vulnerabilities that initially permitted entry, it did nothing to revoke the persistent administrative access and database write privileges the attackers had already secured.

This operational reality offers a critical lesson for incident responders: simply purging a malicious script from a database CMS block or updating the e-commerce core leaves the attacker’s underlying database write access completely intact. Consequently, compromised stores are rapidly re-infected almost as quickly as defenders attempt to clean them.

Official Responses and Strategic Implications for the E-Commerce Sector

As digital skimmers and malicious loaders grow increasingly evasive, the cybersecurity community and enterprise risk managers are facing a paradigm shift. Traditional perimeter defenses and automated vulnerability scanners are proving fundamentally inadequate against threats that selectively alter their behavior based on client-side environment checks.

Industry analysts note that campaigns like this blur the line between traditional malware distribution and supply-chain compromise. Because the malicious code is hosted directly within the merchant’s own database, customers navigating the storefront are trusting an environment that has been weaponized from within. Payment gateway providers and digital commerce platforms are under increasing pressure to provide built-in database integrity monitoring and stricter Content Security Policies (CSP) that limit unauthorized external script execution.

Furthermore, compliance frameworks such as the Payment Card Industry Data Security Standard (PCI DSS) are expected to place heavier emphasis on runtime application self-protection (RASP) and continuous behavioral monitoring for e-commerce websites, moving beyond traditional point-in-time vulnerability assessments that can be easily manipulated by evasive JavaScript loaders.

Recommended Remediation and Instrumenting Detection

Security researchers emphasize that recovering from this campaign requires a strict, sequenced remediation methodology. A haphazard cleanup effort will invariably leave persistence mechanisms active, allowing attackers to re-establish their foothold within minutes.

The Correct Recovery Sequence

1. Isolate and Preserve: Immediately place affected environments into an isolated staging or maintenance mode to prevent further user data exposure while preserving forensic artifacts.
2. Revoke and Rotate: Terminate all active administrative sessions, invalidate API keys, rotate cryptographic secrets, and audit all administrator accounts to remove unauthorized users.
3. Eradicate Backdoors: Hunt for hidden web shells, unauthorized administrative accounts, and persistent backdoors (such as GSocket or Cron-based jobs) across both the filesystem and database layers.
4. Clean the Database: Purge malicious injections from the cms_block and related database tables, replacing them with known-good backups.
5. Patch and Harden: Apply all missing core software patches, update third-party modules, and implement strict database access controls and multi-factor authentication (MFA) for all administrative portals.

Critical Telemetry and Instrumentation Signals

To detect similar sophisticated campaigns before widespread operational damage occurs, security teams should instrument their monitoring stacks around three key telemetry signals:

• Database Content Integrity Checks: Because sophisticated loaders bypass filesystem scans by embedding themselves directly into database tables like cms_block, organizations must deploy continuous database-integrity monitoring tools that specifically flag unauthorized alterations to CMS content tables.
• Administrative Anomalies: The creation of new administrator accounts or sudden permission modifications are statistically rare events in normal merchant operations. Automated alerts should trigger immediate investigations whenever administrative changes occur outside officially scheduled maintenance windows, regardless of whether the storefront appears superficially clean.
• Outbound Traffic Analysis: Monitoring outbound HTTP/S requests from the storefront to recently registered or unverified domains can expose command-and-control callbacks. However, security architects must account for the fact that these callbacks may only fire selectively for targeted visitors, meaning traditional automated scanners will remain blind to them.

As threat actors continue to weaponize application databases and implement adaptive environmental checks, proactive threat hunting and rigorous, multi-layered integrity monitoring remain the primary defenses for securing the modern digital retail ecosystem.