Malware News SuperPixel: The Card Skimmer Hiding Inside Your Own jQuery

[Sampei.Nihira]

Content source

https://blog.report-uri.com/superpixel-the-card-skimmer-hiding-inside-your-own-jquery/

We've uncovered a new card-skimming campaign affecting more than 100 online shops so far, and the attackers are hiding their malware somewhere you might never think to look: inside the website's own copy of jQuery.

There are no suspicious third-party scripts to spot, no unfamiliar script domains to investigate, and nothing obviously new being loaded by the page. Instead, the attackers have modified JavaScript files the shops already host and trust, appending roughly a megabyte of obfuscated malware.

The malware, which calls itself SuperPixel, replaces genuine payment forms with convincing fakes, steals shoppers' card details, and retrieves its exfiltration destination from an Ethereum smart contract.

We've confirmed infections across WordPress, PrestaShop and OpenCart stores, with research ongoing. As far as we can tell, this campaign hasn't been publicly documented before.........

 

[Sampei.Nihira]

It's interesting to note that NextDNS (AI-powered threat detection) is currently blocking:

The current exfiltration endpoint is set to hxxps://metrics-onclick.com.

 

[Bot]

Hi Sampei. This is a nasty Magecart-style campaign, and it neatly demonstrates why “we host jQuery ourselves” is not a security boundary.

One important distinction: jQuery is the hiding place, not the initial vulnerability. The Report URI researchers believe the attackers already have write access to each shop and then append the skimmer to an existing first-party JavaScript file. There is no evidence that official jQuery releases or its CDN were compromised. Simply replacing jquery.min.js would therefore be cleanup theatre if the original access remains open.

The Ethereum angle is also easy to misunderstand. The stolen card data is not being stored on-chain; the smart contract acts as a resilient configuration pointer that tells every implant where its current collection server is. One transaction can redirect the whole campaign, while the listed RPC providers are legitimate services being abused—not malicious infrastructure by themselves. The original research documents the mechanism and indicators.

For shop operators, the sensible response is:

• Compare core, theme and plugin files with trusted packages and deployment records. On WordPress, wp core verify-checksums covers official core files, but not all theme and plugin assets.
• Look for unexpected file growth, particularly the roughly 1 MB addition, and the reported __SuperPixelRunning and superpixel_rendered markers.
• Test checkout using a clean browser profile because the skimmer uses browser storage to avoid repeatedly showing the fake form.
• Preserve logs and establish how write access was gained before rebuilding from known-good files. Review administrative accounts, hosting/SFTP access, vulnerable extensions and persistence.
• Do not rely on script-src 'self': the altered script comes from the permitted first-party origin. SRI or equivalent integrity monitoring can detect changed static scripts, while a tightly allowlisted connect-src can block or report the outbound RPC and exfiltration requests.
• Treat a confirmed infection as a possible payment-card breach and follow the processor/acquirer’s incident procedure.

This is exactly the class of attack addressed by PCI DSS payment-page script authorization, integrity and tamper monitoring guidance for Requirements 6.4.3 and 11.6.1. Browsers trust origins; attackers rather rudely exploit the fact that origins can serve poisoned files too.

Sources

• SuperPixel: The Card Skimmer Hiding Inside Your Own jQuery
• developer.wordpress.org

 

[Sampei.Nihira]

@Bot

I think forum members are more interested in users who make purchases on websites compromised by SuperPixel.

Have you noticed that the “Genuine” and “Skimmer” screenshots are written in the language of my country (Italy)?

 

[Bot]

@Bot I think forum members are more interested in users who make purchases on websites compromised by SuperPixel. Have you noticed that the “Genuine” and “Skimmer” screenshots are written in the language of my country (Italy)?

Fair point—my earlier reply leaned too heavily toward shop operators.

And yes, the “Genuine” and “Skimmer” comparison is an Italian-language checkout. The researchers describe it as a currently infected store. That makes the example especially relevant to Italian shoppers, although the language alone does not establish that the campaign primarily targets Italy; the published research identifies affected platforms, not a geographical concentration.

For customers, the important distinction is:

• Merely visiting the shop does not mean your card was stolen. The documented theft occurs when the malicious checkout replaces the legitimate form and the shopper enters card and billing details.
• If you entered the full card number, expiry date and CVC on a shop subsequently confirmed or strongly suspected to be infected, lock the card, contact its issuer and request replacement. Do this even if the payment failed—the fake form may already have transmitted the information.
• Monitor transactions and enable instant alerts. The captured billing details may also make subsequent phishing messages more convincing. Never provide an OTP or banking-app approval code in response to an unexpected call.
• If payment was completed entirely through an external wallet such as Apple Pay, Google Pay or PayPal, without entering card details into the shop’s page, exposure to this particular card-form skimmer is substantially lower.
• SuperPixel is not presently documented as a password stealer, so changing unrelated passwords solely because of this campaign would be unnecessary.
• There is normally no customer-device malware to remove: the hostile JavaScript runs from the compromised shop. Reopening the checkout to “check” is not a useful test.

The NextDNS block is useful telemetry. If metrics-onclick.com was blocked at the exact time card details were submitted, it may have prevented that particular transmission—but it is not strong enough to bet the card on, because the collection address can be changed through the smart contract. Conversely, receiving no DNS alert proves nothing.

The awkward customer-facing lesson is that HTTPS, a familiar shop and a convincing Italian payment form can all be present while the checkout is compromised. A virtual or disposable card number is one of the few practical ways for shoppers to limit the damage.

Sources

• SuperPixel: The Card Skimmer Hiding Inside Your Own jQuery

 

[Sampei.Nihira]

@Bot

you're letting me down.

Explain to users why those who use dynamic filtering Hard Mode,for example, in uBlock Origin,experience greater mitigation with SuperPixel than those who use Medium Mode.

 

[Bot]

@Bot you're letting me down. Explain to users why those who use dynamic filtering Hard Mode,for example, in uBlock Origin,experience greater mitigation with SuperPixel than those who use Medium Mode.

Yes—that is the practical user-side point I missed. Hard Mode does not stop SuperPixel’s poisoned jQuery from executing, but it places a much stronger barrier around its outbound communications.

The difference is in uBO’s dynamic rules:

• Medium Mode blocks third-party scripts and frames:
  

  * * 3p-script block
  * * 3p-frame block

• Hard Mode blocks all third-party network requests:
  

  * * 3p block

That distinction fits SuperPixel unusually well:

SuperPixel stage	Medium Mode	Hard Mode
Compromised jquery.min.js loaded from the shop	Allowed because it is first-party	Also allowed
fetch() to an Ethereum RPC service	Not generically blocked—it is an XHR/fetch request, not a script or frame	Blocked as third-party
fetch() to metrics-onclick.com with stolen data	Depends on static lists, DNS filtering or a specific rule	Blocked as third-party
Attacker changes to a previously unknown collection domain	May initially pass	Still blocked by the generic third-party rule

The SuperPixel research identifies three external Ethereum RPC domains and a separate external collection domain. All are third-party relative to the compromised shop. Therefore, Hard Mode can obstruct both retrieving the current destination and sending the captured card data, without needing to recognise any of those domains as malicious first.

That is where your NextDNS observation fits. In Medium Mode, NextDNS or uBO’s static lists may catch the known metrics-onclick.com indicator. Hard Mode does not have to wait for that indicator: unknown third party is blocked until the user decides otherwise. The official uBO documentation describes Medium Mode as blocking third-party scripts and frames, while Hard Mode blocks all third-party requests.

There are two important qualifications:

1. The hostile first-party code still executes. It may alter the checkout and collect what is typed; Hard Mode mitigates the documented escape route rather than disinfecting the shop.
2. Users should unblock only the necessary payment-provider domains. Broadly applying a local noop to the entire third-party cell effectively relaxes that site back toward Medium Mode and throws away this advantage.

So the precise conclusion is: Hard Mode offers materially greater mitigation against the documented SuperPixel implementation because its network firewall covers third-party fetch/XHR traffic, whereas Medium Mode’s generic rules do not. It is not proof that a compromised checkout is safe—but it gives the skimmer a rather awkward problem: stolen card data with nowhere to go.

Sources

• Blocking mode: medium mode · gorhill/uBlock Wiki · GitHub
• Blocking mode: hard mode · gorhill/uBlock Wiki
• SuperPixel: The Card Skimmer Hiding Inside Your Own jQuery

 

[aidunno]

thank you @Sampei.Nihira

I used to buy on online pharmacies, so this is an important point

so, @Bot , we can block third parts totally, or use nextdns, or? Do we have others options?

 

[Bot]

thank you @Sampei.Nihira I used to buy on online pharmacies, so this is an important point so, @Bot , we can block third parts totally, or use nextdns, or? Do we have others options?

Use both if possible. uBO Hard Mode and NextDNS are complementary, not equivalent:

Layer	What it can do against SuperPixel	Limitation
uBO Hard Mode	Blocks the unknown third-party RPC and collection requests by default	The poisoned first-party jQuery still executes and may display the fake form
NextDNS/security DNS	Blocks a collection domain once it is identified or detected	The attacker can rotate the domain, and DNS cannot detect the modified first-party script
Virtual/tokenized payment	Reduces the usefulness of stolen card data	Does not prevent theft of billing details
Transaction alerts/card controls	Provides quick detection and lets you freeze the card	Reactive rather than preventive

Practical setup​

1. Keep uBO in Hard Mode on checkout pages.
   If a pharmacy needs an external payment processor, create a local noop only for that processor’s hostname. Do not relax the entire third-party cell, because that also removes Hard Mode’s advantage against the skimmer. uBO’s dynamic-filtering guide explains the difference.
2. Keep NextDNS enabled as a second layer.
   It can still protect another browser or an accidentally relaxed uBO configuration. For this particular implant, advanced users could also denylist the three documented Ethereum RPC hosts:
   • ethereum-rpc.publicnode.com
   • 1rpc.io
   • eth.drpc.org

That obstructs the documented method of retrieving the current collection address, while blocking metrics-onclick.com targets the present collector directly. The RPC services are legitimate and blocking them may break cryptocurrency applications, so this is a campaign-specific choice—not evidence that those providers are malicious. The implant or its infrastructure can also be changed later; the research describes only the currently analysed version.

3. Prefer a single-use, merchant-locked or low-limit virtual card, if your bank offers one. A normal reusable “virtual” number is still stealable; the useful properties are limited reuse and easy replacement. Google’s description confirms that supported virtual cards substitute a generated number for the actual card number, but availability and behaviour depend on the issuer.

4. Prefer a genuine tokenized payment sheet where available.
For example, Apple states that Apple Pay does not send the actual card number to the app or website. Still verify the merchant and amount displayed in the trusted payment sheet—a compromised shop can cause mischief without learning the underlying card number.

5. Enable immediate transaction notifications and app-based card freezing. These do not stop the skimmer, but they substantially shorten the response time.

Disabling JavaScript would prevent this implementation from running, but most modern checkouts would also stop functioning. Blocking only third-party scripts, disabling third-party cookies, using private browsing, a VPN, or relying on the HTTPS padlock does not solve this case. The hostile code is already first-party; the padlock merely delivers it securely, which is not the victory it sounds like.

For your previous pharmacy purchases, purchasing there does not by itself establish exposure. The relevant questions are whether that particular shop was infected at that time and whether you entered the card number, expiry and CVC into its page. If both are confirmed or strongly suspected, freeze the card and contact the issuer even if the payment failed. The published analysis confirms theft of card and billing details; it does not currently establish theft of prescription records.