Sansec: 953 online stores infected by malware that hides from scanners

A clean scan can describe the wrong visitor

Most security checks ask one question: what does this page look like to a machine? This campaign is built around that habit. The code first decides whether the visitor is a person or a tool, and it hides from tools.

Sansec, a Magento security firm, reports that one criminal group has infected 953 online stores since July 2025. Most of them run Magento. SecurityWeek reported Sansec's findings on October 26.

The lesson here is simple. A clean scan is evidence about the scanner's experience, not about your customers' experience. A scanner and a shopper can be shown different pages.

How the loader works

The group adds a small piece of JavaScript to store pages. When a shopper visits, the browser contacts the group's server and asks what to do next. Sansec calls this a loader.

The newest version, from October 23, sends a browser fingerprint to the group's server. It checks for signs of automation, such as the navigator.webdriver flag, Selenium globals and ChromeDriver properties. It also collects the graphics card name, CPU cores, memory, screen size, time zone and languages.

The server then chooses its reply based on that fingerprint. In one test, urlscan.io's automated Chrome visited an infected store. The page came back with HTTP 200, and Sansec saw nothing extra in it. Sansec has not yet captured the final payload, so what real shoppers receive from this version is unknown.

Earlier versions hint at the intent. On December 12, 2025, a logged-in customer on an infected store received a script that loaded pages from crypto-themed domains. One, leqdger.click, is a misspelling of the Ledger wallet brand.

The loader sits in the cms_block table, where Magento keeps the static blocks it renders into pages. Sansec's eComscan scanner found it there on 148 server installs and not in core_config_data or theme files. Anyone checking only theme code would miss it.

Old domains still work for someone else

The group moves to a new domain every few months. The newest, deepveindrilling.com, was registered on October 6, 2026. Infected stores began serving it the following evening. Sansec found it on 83 stores, and 60 of those already ran an earlier loader.

Abandoned domains stay dangerous. Two retired addresses, neswnsssn.click and manulfie.click, lapsed and were bought by someone else in May 2026. Between August and October, Sansec still found their loaders on 9 and 6 stores. Visitors to those stores give a stranger the page they came from and the page title. Their browsers will also run whatever script that stranger serves.

Sansec also runs a service that collects browser reports about which outside scripts a page loads. This kind of browser rule is called CSP. The service logged visitors' browsers loading all four earlier domains. About 52,000 of those reports concerned additionalver.com.

Patching alone did not close the door

Sansec says the October rewrites used no new vulnerability. The operator reused access from earlier waves. Back in March, webshells were uploaded through the PolyShell flaw (CVE-2026-48356). Within an hour the group planted the loader on 471 stores. A webshell is a hidden file that gives an attacker remote control.

Among the loader's hosts, Sansec counts 169 Magento 2 installs that lack at least one core patch. Of those, 102 (60%) also contain files uploaded through PolyShell or SessionReaper (CVE-2025-54236). Sansec puts the rate at 32% across 3,024 comparable installs carrying a different skimmer.

Patching did not guarantee safety, either. Sansec describes a store on Magento 2.4.7-p10 that was missing no core patches. It received the new loader at 16:46 UTC on October 23, an hour after a clean scan.

That store was not a clean victim. According to Sansec, eComscan had flagged a rogue admin account on it on September 16. A GSocket backdoor followed on September 24.

So the clean scan was clean only of the loader. The earlier access was already in place.

Sansec states that deleting the script does not remove the attacker's access. If the entry point stays, the code returns.

What to ask your team

Ask who owns the check that looks at what shoppers receive, not only at what scanners receive. Ask whether the team can see which outside scripts load in real customers' browsers.

Sansec's guidance is specific. Search the cms_block and cms_page tables for the loader code, remembering that domains are often base64 encoded. The update_time column shows the attacker's latest write.

Then look for the entry point: unfamiliar accounts in admin_user, unknown processes and uploaded webshells. Change database, admin and API passwords. Sansec also tells owners to install Adobe's PolyShell fix, APSB26-73, and its SessionReaper fix, APSB25-88.

Sansec sells related products, so weigh its commercial interest. Its technical findings still give your team concrete things to check.

A scanner can only report what it is shown. Plan for an attacker who decides what that is.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Sansec.