Introduction
HUMAN’s Satori Threat Intelligence and Research Team has uncovered an active Magecart (digital skimming) campaign collecting personally identifying information (PII) and payment card information from the checkout pages of more than 15 digital storefronts, served from a network of 102 threat actor-owned domains. The threat is identified as TI-74 in the Human Defense Platform.
The threat actors injected code on these checkout pages to mimic the payment form, and after unsuspecting users filled out the form, the code relayed the information both to the threat actors and to the storefront owner. This resulted in the transaction going through as expected, so neither the shopper nor the storefront owner notices that something is wrong.
Compounding the threat, HUMAN found that many of the targeted organizations were actively running digital ads pointing toward the infected storefront. These ads were legitimate and completely unrelated to the skimming attack; it’s merely unfortunate that they directed users to a checkout page that stole their information.
Researchers have shared information about this threat with the targeted organizations.
HUMAN’s Client-Side Defense identifies unauthorized scripts running in user browsers, protecting customers from Magecart-style attacks, and HUMAN’s Malvertising Defense identifies when malicious scripts have been injected into the landing page of an ad and blocks the ad from rendering, protecting users from being exposed to the threat.
Executive Summary
Satori threat researchers found an active Magecart-style campaign that planted a heavily obfuscated credit-card skimmer on checkout pages of more than 15 digital storefronts, served from a rotating network of more than 70 attacker-controlled domains. The skimmer overlays a convincing fake payment form, harvests shoppers’ card numbers, expiration dates, CVVs, and full billing details, and quietly exfiltrates them to attacker infrastructure, all while the real transaction still completes, so neither the shopper nor the store notices.
The evidence indicates these stores were compromised by an external attacker through existing vulnerabilities; the site owners were victims, not participants. (In fact, on one site the skimmer was even injected incorrectly and rendered as visible plain text instead of executing, a clear sign of an unwanted intrusion.)
What makes this campaign matter beyond the merchants themselves: legitimate, brand-owned digital ads were driving shoppers straight to these compromised checkouts, turning a single store compromise into an advertising-ecosystem problem.
Threat Overview
Magecart is the umbrella term for “digital skimming” attacks, in which criminals inject malicious JavaScript into an online store’s pages to copy customers’ payment and personal data as they type it at checkout. The legitimate purchase still goes through, which is what makes these attacks so hard to spot and so long-lived.
At a high level, this campaign works like this:
The TI-74 behavioral chain, in which a compromised landing page loads a malicious third-party library, which builds a fake checkout mirroring the real one, captures the card and billing data, and exfiltrates it to the attacker’s server.
The skimmer is delivered as a remote script that always follows the same URL shape:
https://<attacker-owned-rotating-domain>.top/<store-identifier>/metrics.js
Disguising the payload as a “metrics” file helps it blend in with the analytics and tracking scripts every site already loads.
Injection Methods / Infection Vectors
Researchers haven’t yet pinpointed what vulnerability led to the script injection, as there are no obvious shared platforms or plugins among the targeted organizations and storefronts. What the researchers can say with confidence:
- The skimmer arrived after the stores were compromised, and more than one delivery method was used. Sometimes threat actors used an inline loader that dynamically creates a <script> element, sometimes they used a script injected directly into the server’s HTML response.
- Threat actors assigned each target its own payload path (the store’s name as a subdirectory) and rotated through a collection of lookalike .top domains, which complicates simple domain-based blocklisting and takedowns.
- Researchers observed cases where, even after an organization removed the injected script from their site, the attacker’s per-target payload endpoint kept serving the skimmer. Removing the script does not automatically retire the attacker’s endpoint or close the original entry vector, leaving the door open to rapid re-infection.
As noted above, researchers have shared information about this attack with impacted organizations.
Inside the Skimmer
The threat actors behind this attack relied on multiple obfuscation techniques. Most of the live payloads researchers observed included a common hex-based JavaScript obfuscator, but many also employed js-confuser, a more advanced open-source obfuscator that abuses techniques like the deprecated with statement to defeat automated control-flow recovery. Satori researchers built dedicated deobfuscation tooling to peel back that obfuscator to uncover the original purpose-built card skimmer. The key steps:
- Targets the checkout. The script first checks whether the current page is a checkout page and whether it has already exfiltrated on this session, so it only activates where payment data will be entered.
- Builds a convincing fake payment form. It locates the real payment container and injects its own form with fields for Card Number, Expiration Date, and CVC, complete with embedded logos for major card providers so the form looks native to the store’s checkout.
The fields in the injected form are built to capture every keystroke with
document.getElementById("cardNum").addEventListener("input", (e) => {
localStorage.setItem("cardNum", e.target.value);
});
3. Skims and stages the data. As the shopper types, the card number, expiry, CVV, and the full set of billing fields (name, address, email, phone, etc.) are continuously copied into the browser’s localStorage.
4. Exfiltrates on “Place Order.” When the shopper submits, the collected data is packaged as JSON, Base64-encoded, and sent to the attacker’s endpoint dressed up as an analytics “metric.” Across samples, researchers saw the data shipped via more than one mechanism (a background fetch() call or a WebSocket), but always to the same kind of analytics-looking endpoint:
https://<attacker-domain>.top/api/accept-metrics?metrics=<base64-encoded-JSON>
Because the legitimate order still completes normally, there’s no visible symptom for the shopper or the merchant.
Advertising Inadvertently Feeding the Fire
As noted above, many of the targeted organizations were, through legitimate ad campaigns, pointing unsuspecting customers toward the infected checkouts. In one example, an off-road parts retailer had search ads that led directly to the storefront.
The ad was entirely legitimate; the landing page was infected. Researchers notified the organization of the issue and the injected script was promptly removed. There is no evidence the organization was aware of the infection before our outreach.
The advertising ecosystem can become part of the attack surface:
- Publishers and platforms can unknowingly serve or carry ads whose landing pages are compromised.
- Users who trust an ad from a recognizable brand are delivered straight to a skimmer.
- Domain rotation means yesterday’s “clean” landing page can be today’s infected one.
HUMAN detected the compromise at both the ad and landing-page level by rendering and analyzing where ads actually take users and blocked the ads that led to infected checkouts, so users in our customers’ environments were not delivered to the skimmer. We also reported the offending ads to the platforms distributing them.
How HUMAN Protects Against Threats Like TI-74
This campaign is a good illustration of why client-side and advertising defenses are complementary:
- HUMAN’s Malvertising Defense protects publishers, platforms, SSPs/DSPs, and other ad-tech participants by continuously evaluating the creatives and the landing-page destinations flowing through their inventory. When an ad leads to a compromised or malicious destination—like a checkout running this skimmer—HUMAN identifies it, blocks it, and reports it. This protects the ad-tech organization and shields end-users from being routed into the attack, even though the threat lives on a third party’s e-commerce site, rather than in the ad itself.
- HUMAN’s Client-Side Defense protects e-commerce and any site collecting sensitive data by monitoring the actual behavior of first-, third-, and nth-party scripts running in the browser. It detects unauthorized access to payment/PII fields, anomalous script behavior, and data-exfiltration attempts, even when the malicious code is dynamically loaded and heavily obfuscated.
Together, they cover both ends of this campaign: the merchant whose checkout was compromised, and the advertising supply chain that was unwittingly sending shoppers there.
What Defenders Should Do
- Storefront owners: Audit checkout (and site-wide) source for unexpected remote scripts, especially “metrics”/analytics-looking files on unfamiliar domains. Removing the injected tag is necessary but not sufficient, as the attacker’s payload endpoint stays live and your original entry vector remains, so close the root cause (unpatched CMS/plugins, weak admin credentials, server-side injection), hunt for backdoors/persistence, monitor for re-injection, and notify potentially affected customers.
- Advertisers/agencies: Don’t assume your own landing pages are safe just because the ad is yours. Monitor the live destination, not just the creative.
- Publishers/platforms: Evaluate ads by where they actually take users, continuously, because attacker infrastructure rotates.
The Bigger Picture
Magecart-style attacks remain a significant concern. As long as skimming stolen cards remains cheap to operate and profitable to monetize, attackers will keep compromising stores, rotating infrastructure, and layering on obfuscation to stay ahead of static detection. What’s evolving is the distribution side: campaigns increasingly lean on the advertising ecosystem—legitimate ads, recognizable brands, rotating domains—to deliver victims at scale. Defending the modern web means watching behavior, not signatures, on both the checkout page and the path the user took to get there.
Indicators of Compromise (IOCs)
Valid as of 2026-08-06. The operators rotate domains frequently, so this is a point-in-time snapshot, not exhaustive. At snapshot time, ~70 of the hosts below still resolved; the remainder had already rotated out but are retained as historical IOCs. Victim identities are intentionally excluded.
Payload URL pattern
https://<attacker-rotating-domain>.top/<redacted-store-id>/metrics.js[?v=N]Exfiltration pattern
https://<attacker-domain>.top/api/accept-metrics?metrics=<base64-encoded-JSON>Attacker payload-hosting domains (102)
| Domain | Domain | Domain | Domain |
|---|---|---|---|
| brightsnow.top | chainsupdated.top | darkdreams.top | emberpixel.top |
| errormeriks.top | fishpixelnow.top | frontshadows.top | grapemeriks.top |
| histonmeriks.top | hornypixel.top | lightflowers.top | manymeriks.top |
| meriksbarierz.top | meriksbiken.top | meriksbmw.top | merikschecked.top |
| merikscomebackpls.top | merikseldrix.top | meriksfeyron.top | meriksgailen.top |
| meriksgigantes.top | meriksglobalelite.top | meriksgoblinsquad.top | merikshailaiterr.top |
| merikshasky.top | merikshigger.top | meriksjangi.top | meriksjasiiik.top |
| meriksjasik.top | meriksjustens.top | merikskaimen.top | meriksla.top |
| merikslayers.top | merikslunex.top | meriksnewplayer.top | meriksnexara.top |
| meriksnyvera.top | meriksradian.top | meriksscally.top | meriksshadowfiend.top |
| meriksskaterr.top | meriksslaikibnaiky.top | meriksslayerr.top | merikssnoiwer.top |
| meriksstantion.top | meriksstayhuman.top | meriksstaylife.top | meriksstormes.top |
| meriksstounheree.top | merikstenki.top | merikstoppalace.top | meriksvarion.top |
| meriksvortexa.top | meriksxenonlight.top | pixel-kings.co | pixelcrocodile.top |
| pixelelephant.top | pixelforloveme.top | pixelgaidensom.top | pixelgrandthetun.top |
| pixelhaimensoms.top | pixelharrycloud.top | pixelhinensoom.top | pixelkaleren.top |
| pixelkanion.top | pixelkorvix.top | pixellunex.top | pixellowersoon.top |
| pixellowerseon.top | pixelneversleep.top | pixelnexara.top | pixelnothingrich.top |
| pixelobserv.top | pixeloutcandy.top | pixeloutputtt.top | pixelolvex.top |
| pixelpraicenotgood.top | pixelpulsema.com | pixelqiwiwallet.top | pixelradian.top |
| pixelslowermode.top | pixelstarline.top | pixelthalix.top | pixelunionsoft.top |
| pixelvarion.top | pixelyllion.top | pixelzentor.top | presession.top |
| shadowflowers.top | shadowmoon.top | sharklpixelwhite.top | stylegamers.top |
| styleinfinity.top | stylemercedes.top | styleolivert.top | styleolivvs.top |
| styleoutspring.top | stylepackman.top | styleyary.top | taisorbanned.top |
| utilitymeriks.top | yorumerikschannel.top |
Exfiltration/C2 domains (4)
pixelostin.top merikshaimanern.top teampixelspeak.top merikscanuseeme.top
Sample hashes (victim-neutral domains)
| ID | Size | Obfuscation | SHA-256 |
|---|---|---|---|
| Sample-01 | 199 KB | js-confuser | 7ab48e622e29e61babbdec3fb331ec1d649ea3a70a6d4794432dd7a2902fda0d |
| Sample-02 | 201 KB | obfuscator.io-style hex | c0f52abc8c8558bf758b4887c3561716ea395ddac2b0a72862305760a5fdf410 |
| Sample-03 | 11 KB | obfuscator.io-style hex | 7511a6ed47c5f8d40c0bc8e6a31814e88269431ad2112b250ac62dba85815952 |
| Sample-04 | 216 KB | js-confuser | b3f899f904790c98fb56d6dfc64b14bbf7a3624c8ba377472ea4fdaa754ef327 |
| Sample-05 | 11 KB | obfuscator.io-style hex | aa8b48eea839acc0710063b74c6ed6facebc3be6ce974354356350958db788f5 |
| Sample-06 | 207 KB | obfuscator.io-style hex | bd073f902c2bf1f8cdcf30d0ecab634053caafd493368c20738bffa53377140d |
| Sample-07 | 207 KB | obfuscator.io-style hex | f940af3cae8483354714385a38ef3a4b201257ed927ca90263dbc2f43e54cc77 |
| Sample-08 | 188 KB | obfuscator.io-style hex | 774ba996ff0ec7e3954f190affdcd44ee71fcc762222d2a4b71e29b7b447ce2d |
| Sample-09 | 209 KB | obfuscator.io-style hex | f74d06c9dd53fc3c06b3549c4c0f6f02480c0bfda2261615482afe456b85faa5 |
Host-based detection strings
/api/accept-metrics?metrics=
.top/<store>/metrics.js (remote script on an unfamiliar .top domain)
localStorage keys: cardNum, exp, cvv, already_checked
