The Magento loader campaign has changed infrastructure repeatedly. Sansec tracked the first domain, manulfie.click, from July 2025, then neswnsssn.click, lanhd6549tdhse.top, additionalver.com, and the current deepveindrilling.com. The report associates the domains with 863, 494, 355, 246, and 83 stores, respectively, and says the group has hit 953 stores overall. The difference between the per-domain totals and the campaign total reflects overlapping victims.
Domain rotation creates a common monitoring problem. A block on the newest domain may stop a fresh request, but the store can still contain an older script, and a visitor who previously received a payload may retain it in localStorage. An indicator list is necessary, but it is not the same as an inventory of loaded scripts or a clean store.
What the domains tell an investigator
Sansec says the first four domains were used as Keitaro traffic-distribution endpoints. The current domain drops Keitaro and performs the fingerprint check in the loader itself. It was registered on October 6, 2026 and first appeared on stores the next evening. Its front page returns a 404, while script paths respond selectively.
Two older domains, manulfie.click and neswnsssn.click, expired and were registered again in May 2026. Sansec observed their nameservers pointing to a parking service. In August through October, it still found the old manulfie.click loader on nine stores and the neswnsssn.click loader on six. This is a useful reminder that a domain's current status does not erase the code embedded in a storefront.
ZoomEye can add a limited infrastructure view. On November 12, a query for domain="deepveindrilling.com" returned two matches and domain="additionalver.com" returned zero. For scale, app="Magento" returned 134,331 product matches. None of those numbers identifies an infected store. Domain matches describe indexed domain relationships, and product matches describe a broad application population.
Monitor the chain, not only the last hop
A defensive program should keep a versioned list of loader domains and paths, then record how each item is observed. CSP reports can show a browser attempt to load a blocked domain. Web server logs can show requests for script paths. Page-source monitoring can find a script tag or inline loader. Application database reviews can find the CMS block that generated the request. Each source answers a different question.
The list should include the named loader domains, the Keitaro campaign paths, and the payload domains from Sansec's indicators of compromise. It should also record the first and last observation time, the owning store, the response status, and the evidence source. A block should remain in place until the store has been cleaned and the relevant access path has been closed.
Parked and expired domains complicate ownership
An expired domain can be re-registered, parked, or repurposed. A current nameserver record does not prove that the original actor still controls it, and a current parking page does not prove the old loader is harmless. The safer question is what the store's page and database still reference. If a stale script remains, the browser may continue to request the domain even when the domain owner has changed.
The same caution applies to attribution. Sansec describes a criminal group and a multi-year campaign. It does not establish a legal identity for each domain or a complete list of current operators. Infrastructure overlap can support investigation, but it should not be turned into a claim about a person or organization without stronger evidence.
A useful review cadence
Review the domain list whenever a new loader is reported and whenever a domain changes ownership. Check stores for the current and historical names. Compare the public page with the CMS block, then check the server for uploaded backdoors. Use ZoomEye as a discovery layer for public domains and assets, not as a substitute for database access.
The operational lesson is simple: a domain block is a temporary control, while a storefront review is evidence work. Rotation makes the first task frequent. Persistence inside the application makes the second task necessary.