Thousands of e-commerce websites are bleeding customer payment data right now, and most of them don’t even know it.
A newly identified digital skimming campaign, dubbed “Mongolian Skimmer” by researchers at Jscrambler, is targeting online stores with obfuscated JavaScript code designed to harvest credit card numbers, names, addresses, and login credentials directly from checkout pages. The malware is notable for its unusual use of Unicode characters to disguise its payload — a technique that makes it harder for security tools and human analysts alike to detect the threat lurking in a site’s source code. According to TechRadar, the campaign has compromised a significant number of web stores, and the infection vector appears to be expanding.
This isn’t a new category of attack. Digital skimming — often called Magecart-style attacks after the original criminal syndicate that popularized the method — has plagued online retail for nearly a decade. But the Mongolian Skimmer represents a meaningful evolution in how these attacks evade detection. And the timing couldn’t be worse for retailers already stretched thin on cybersecurity resources heading into the second half of 2025.
The mechanics are deceptively simple. An attacker injects a small piece of JavaScript into a vulnerable e-commerce site, typically by exploiting weaknesses in third-party plugins, content management systems, or supply chain dependencies. When a customer visits the compromised checkout page, the malicious script silently captures every keystroke entered into payment forms. That data — card numbers, CVVs, expiration dates, billing addresses — is then exfiltrated to attacker-controlled servers. The customer completes the purchase normally. The merchant processes the order normally. Nobody notices anything wrong until fraudulent charges start appearing on bank statements weeks or months later.
What distinguishes the Mongolian Skimmer is its obfuscation layer. Jscrambler’s research team found that the malware uses Mongolian Unicode characters — specifically characters from the Cyrillic Mongolian script block — as variable and function names within the JavaScript code. This is a clever trick. Most automated security scanners are tuned to flag suspicious patterns in Latin-character code. By substituting recognizable variable names with Unicode characters that render as unfamiliar glyphs, the attackers make static analysis significantly more difficult. A security analyst manually reviewing the code would see what appears to be garbled nonsense rather than the structured logic of a skimming operation.
It’s an approach that exploits a blind spot. JavaScript is a permissive language — it allows Unicode identifiers by specification. So the code executes perfectly in any modern browser regardless of what character set the variable names use. The browser doesn’t care if a function is called “stealCardData” or “ᠮᠣᠩᠭᠣᠯ.” It runs the same way.
Pedro Fortuna, CTO of Jscrambler, has been vocal about the growing sophistication of client-side attacks on e-commerce platforms. His firm, which specializes in JavaScript security, has tracked a steady increase in skimming campaigns that use novel obfuscation methods to bypass both automated scanning tools and manual code reviews. The Mongolian Skimmer, according to Jscrambler’s analysis, also employs anti-debugging techniques — code that detects when a developer tools console is open and alters its behavior accordingly, making forensic investigation harder in real time.
The scale of the problem is difficult to pin down precisely, but the numbers are sobering. Sansec, a Dutch cybersecurity firm that specializes in tracking digital skimming attacks, has previously estimated that tens of thousands of online stores are actively compromised by Magecart-style malware at any given time. Many of these are small and mid-sized retailers running on platforms like Magento, WooCommerce, and PrestaShop — platforms that depend heavily on third-party extensions, each of which represents a potential entry point for attackers.
And the financial damage is enormous. The FBI’s Internet Crime Complaint Center reported that e-commerce fraud losses in the United States exceeded $10 billion in 2023, a figure that has almost certainly grown since. A significant portion of that total traces back to payment card theft via digital skimming. For individual merchants, a breach can mean PCI DSS compliance fines, forensic investigation costs, customer notification expenses, and the reputational damage that comes with being the company that leaked your customers’ credit card numbers.
The Mongolian Skimmer campaign also highlights a structural weakness in how e-commerce security is typically handled. Most merchants focus their security investments on server-side protections — firewalls, intrusion detection systems, encrypted databases. These are necessary. But digital skimming attacks operate on the client side, in the browser, where traditional server-side defenses have no visibility. The malicious JavaScript runs in the customer’s browser, not on the merchant’s server. So a merchant can have a perfectly hardened backend infrastructure and still be hemorrhaging payment data because of a compromised JavaScript file loaded from a third-party CDN or plugin.
This gap has drawn regulatory attention. The Payment Card Industry Security Standards Council updated its PCI DSS requirements in version 4.0, which took effect in March 2025, to include specific mandates around client-side script monitoring. Requirements 6.4.3 and 11.6.1 now obligate merchants to maintain an inventory of all JavaScript loaded on payment pages, ensure each script is authorized and integrity-checked, and implement mechanisms to detect unauthorized modifications. These are significant new obligations, and many merchants — particularly smaller ones — are scrambling to comply.
The enforcement reality is uneven. Large retailers with dedicated security teams and substantial budgets can implement content security policies, subresource integrity checks, and real-time JavaScript monitoring solutions. A small boutique running a WooCommerce store on shared hosting? That’s a different story entirely. These merchants often lack the technical expertise to even understand the threat, let alone defend against it. They rely on their platform provider and plugin developers to keep things secure — a trust model that has been repeatedly broken.
Third-party risk is the crux of the issue. Modern e-commerce sites routinely load JavaScript from dozens of external sources: analytics providers, advertising networks, chat widgets, social media integrations, A/B testing tools, payment processors. Each external script is a potential attack surface. If any one of those third-party providers is compromised — or if an attacker manages to inject code through a vulnerable plugin — the merchant’s checkout page becomes a data collection point for criminals. Supply chain attacks on JavaScript dependencies have become one of the most productive vectors for digital skimming groups.
The Mongolian Skimmer’s operators appear to be well-organized. TechRadar reports that the campaign uses multiple exfiltration endpoints and rotates its command-and-control infrastructure regularly, making takedown efforts more difficult. The malware also includes a loader component that can dynamically fetch updated skimming code from remote servers, meaning the attackers can modify their payload without needing to re-compromise the target site. Once they have a foothold, they can adapt.
This persistence mechanism is particularly troubling. Even if a merchant detects and removes the initial injection, the underlying vulnerability that allowed the compromise often remains unpatched. Reinfection rates for Magecart-style attacks are notoriously high. Sansec has documented cases where merchants were reinfected within hours of cleaning a compromised site, because the attackers had planted backdoors or were exploiting a vulnerability the merchant hadn’t identified.
So what should merchants actually do? The first step is visibility. You can’t protect what you can’t see. Implementing a content security policy that restricts which scripts can execute on payment pages is a baseline measure. Subresource integrity attributes can ensure that externally loaded scripts haven’t been tampered with. Real-time monitoring solutions — offered by firms like Jscrambler, Sansec, Akamai, and others — can detect unauthorized script modifications as they happen and alert security teams before significant data loss occurs.
But technology alone isn’t sufficient. Merchants need to treat their JavaScript supply chain with the same rigor they apply to their server-side dependencies. That means auditing third-party scripts, minimizing the number of external resources loaded on payment pages, and maintaining a clear inventory of every piece of code that touches customer data. The new PCI DSS 4.0 requirements provide a framework for this, but compliance is the floor, not the ceiling.
For consumers, the threat is largely invisible. There’s no way for a shopper to tell whether a checkout page has been compromised by looking at it. The site looks normal. The SSL certificate is valid. The payment goes through. The only defense on the consumer side is vigilance — monitoring bank statements, using virtual card numbers where available, and enabling transaction alerts. Some security researchers recommend using browser extensions that block unknown scripts, though this can break site functionality and isn’t practical for most people.
The broader pattern here is unmistakable. Attackers are getting better at hiding in plain sight. The use of Unicode obfuscation in the Mongolian Skimmer is just one example of a relentless innovation cycle on the offensive side. Previous campaigns have hidden skimming code inside image files, CSS stylesheets, favicon files, and even 404 error pages. Each new technique is designed to evade the specific detection methods that security vendors deployed against the last one. It’s an arms race, and the defenders are perpetually one step behind.
The e-commerce industry’s response has been fragmented. Platform providers like Adobe (which owns Magento) and Automattic (which maintains WooCommerce) have improved their security guidance and patching cadences, but they can’t control what third-party plugins do. Payment processors have implemented tokenization and hosted payment fields that reduce the amount of sensitive data that touches a merchant’s site, but adoption is inconsistent. Industry groups have published best practices. None of it has stopped the bleeding.
Part of the problem is economic. For many small merchants, the cost of implementing comprehensive client-side security monitoring exceeds their entire IT budget. They’re making rational calculations based on incomplete information — betting that they’re too small to be targeted, or that their platform provider has it covered. The attackers know this. Automated scanning tools allow criminal groups to identify and compromise thousands of vulnerable stores with minimal effort. Being small doesn’t make you safe. It makes you easy.
The Mongolian Skimmer is not the last word in digital skimming innovation. It won’t be the most sophisticated campaign we see this year. But it’s a useful case study in how the threat continues to evolve — and in how the structural incentives of e-commerce make this a problem that resists easy solutions. As long as online stores load third-party JavaScript on pages where customers enter payment data, attackers will find ways to exploit that trust. The question isn’t whether the next campaign will emerge. It’s whether the industry will be any more prepared when it does.
from WebProNews https://ift.tt/23udeYW
No comments:
Post a Comment