Er duikt opnieuw een campagne op waarbij aanvallers niet alleen kwetsbaarheden benutten, maar ook het detectierisico voor onderzoekers actief verkleinen. Volgens de Nederlandse e-commerce security-onderzoeker Sansec zijn 953 online winkels geïnfecteerd. Het overgrote deel draait op Magento, en de besmetting verloopt via een mechanisme in de webshop: Magento besmet via cms_block.
Wat het extra zorgwekkend maakt: de kwaadaardige code is ontworpen om pas echt “iets te doen” wanneer het om een echte bezoeker gaat. Beveiligingsscanners krijgen doorgaans niets, waardoor de infectie buiten beeld blijft tijdens automatische tests.
Hoe de aanval werkt: loader via cms_block
De kern van de campagne is het toevoegen van een klein stukje code aan pagina’s van de winkel. Die code gebruikt Magento CMS-functionaliteit om een JavaScript loader te serveren zodra een bezoeker de getroffen pagina opent.
Sansec beschrijft dat de browser bij het bezoeken van de pagina een verzoek doet naar de infrastructuur van de aanvallers. Vervolgens vindt er een controle plaats: de server probeert te bepalen of de bezoeker een echte shopper is of een security scanner. Bij scanners wordt de keten doorgaans afgebroken.
De loader wordt “gestaged” in Magento’s cms_block-tabel. Magento gebruikt die tabel om statische content in storefrontpagina’s te renderen. Door de loader daar op te slaan, kan de aanvaller de code laten meeliften met normale paginaweergave.
Verschillende domeinen en een actief veranderende keten
In de tijd zijn meerdere domeinen waargenomen die gekoppeld zijn aan deze campagne. Sansec noemt onder andere: manulfie[.]click, neswnsssn[.]click, lanhd6549tdhse[.]top, additionalver[.]com en deepveindrilling[.]com. Het patroon laat zien dat de aanvallers hun infrastructuur laten rouleren, waardoor blokkeren op basis van één domein minder effectief is.
Daarnaast meldt Sansec dat deepveindrilling[.]com sinds de domeinregistratie op 6 oktober 2026 is teruggevonden in CMS-blocks van 83 winkels. Ook hier geldt dat de JavaScript loader alleen reageert op scriptverzoeken van echte bezoekers.
Twee varianten van de loader: localStorage en fingerprinting
Sansec ziet minstens twee versies van de loader. In de eerste variant laadt de browser externe JavaScript vanaf het aanvallersdomein. Vervolgens slaat de code de payload op in localStorage. Het gevolg is dat de kwaadaardige code bij een volgend bezoek opnieuw kan worden uitgevoerd, ook wanneer de oorspronkelijke externe bron later niet meer beschikbaar is.
De tweede variant gaat verder met browser fingerprinting. Daarmee probeert de loader bots en scanners te weren. Alleen bezoekers die als “echt” worden beoordeeld, krijgen de schadelijke uitvoering. Zo blijven uitingen van compromis bij geautomatiseerde scanning vaak uit, terwijl echte bezoekers wél geraakt worden.
Traffic distribution met Keitaro in eerdere iteraties
In eerdere stappen van de campagne werd Keitaro gezien als traffic distribution system (TDS). Een TDS stuurt verkeer naar verschillende reacties op basis van kenmerken van de bezoeker: bijvoorbeeld een payload, een redirect of “niets doen”.
Sansec beschrijft een voorbeeld waarbij het aanvragen van additionalver[.]com als Windows-desktopbezoeker leidde tot een respons als “QWE=123;”. Die respons doet op zichzelf niets schadelijks, maar zet een cookie die de bezoeker 24 uur markeert. In de praktijk wordt hiermee een tijdvenster gecreëerd waarin de aanvaller opnieuw verkeer kan herkennen.
Bij deepveindrilling[.]com is die logica niet enkel extern terug te vinden: Sansec stelt dat het Keitaro-component vervalt en dat bot-filtering in de loader zelf is geïntegreerd.
Waar komt de initial access vandaan?
Sansec schat dat 471 Magento-winkels de loader kregen doordat ze waren geïnfecteerd via PolyShell (ook bekend als CVE-2026-48356). Daarnaast zouden 102 winkels zijn geraakt via uploadmethodes bij PolyShell of via SessionReaper (ook bekend als CVE-2025-54236).
In een concreet voorbeeld noemt Sansec een winkel op Magento 2.4.7-p1 waar PolyShell-webshells waren vermomd als PNG-afbeeldingen in de map pub/media/custom_options/quote/. Tegelijk stond de loader in een CMS-block naast een verwijzing naar additionalver[.]com. Later schakelde het CMS-block op deepveindrilling[.]com (op 7 oktober), terwijl de winkel nog altijd niet de fix APSB26-73 had toegepast voor ondersteunde releases.
Ook ziet Sansec gevallen waar een winkel op Magento 2.4.7-p10 werd gecompromitteerd zonder dat core-patches ontbraken. In dat scenario werd volgens de observaties eerst een rogue administrator-account toegevoegd, waarna de aanvaller de CMS-code kon injecteren.
Waarom dit vaak moeilijk te detecteren is
Een belangrijke reden dat incidenten niet sneller zichtbaar worden, is de combinatie van twee technieken: de loader die alleen “werkt” voor echte bezoekers en de verplaatsing van de schadelijke logica naar CMS-blocks. Daardoor kan een standaard security scan een schone respons teruggeven, terwijl een normale shopper in dezelfde periode wél wordt blootgesteld.
Daarbovenop komen de aanwijzingen dat payloads kunnen worden “opgeslagen” via localStorage. Zelfs wanneer externe domeinen later worden uitgeschakeld, kan de besmetting effect blijven hebben bij volgende bezoeken.
Wat webshops nu kunnen doen
Sansec geeft eigenaren van getroffen sites een duidelijke set adviezen. Het start met controle op de plek waar de aanvaller zich verstopt: Magento CMS-blocks en -pagina’s.
- Audit accounts: kijk naar verdachte gebruikers, onverwachte admin-accounts en accounts die niet passen bij het bedrijfsproces.
- Controleer CMS-inhoud: beoordeel of er ongebruikelijke CMS-blocks of CMS-pagina’s zijn aangetroffen, specifiek in de tabellen cms_block en cms_page.
- Houd Magento up-to-date: installeer relevante patches voor ondersteunde release-lijnen en verifieer dat ze daadwerkelijk zijn doorgevoerd.
- Gebruik sterke authenticatie: zorg dat wachtwoorden niet te gemakkelijk te raden of te hergebruiken zijn.
Omdat de keten vaak begint bij een kwetsbaarheid of misbruik van toegang, is het bovendien verstandig om te kijken of er sporen zijn van webshells of ongebruikelijke uploads in webmap-structuren.
Relatie met andere PHP2Shell-activiteiten
Deze disclosure komt tegelijk met bredere aandacht rond PHP2Shell, een set van twee kritieke PHP-kwetsbaarheden (CVE-2026-109618 en CVE-2026-109619). Er zijn volgens rapportage ook veel exploitatiepogingen gezien na publicatie.
Daarnaast werd er door onderzoeker Adel Karimi een eerste succesvolle exploitation in het wild gerapporteerd waarmee commando’s op honeypotservers werden uitgevoerd. Die commando’s gebruikten tools zoals wget en curl om vervolgcomponenten op te halen van een externe server. De details over de exacte tweede fase bleven daarbij nog onduidelijk.
Als je omgeving te maken kan hebben met PHP-toepassingen of vergelijkbare exploitpaden, is het extra belangrijk om niet alleen Magento te controleren, maar ook de onderliggende PHP- en applicatiestack te beoordelen.
Praktische checklist voor Security & IT
Wil je gericht handelen? Gebruik deze praktische volgorde:
- Inventariseer alle Magento-webshops en hun versies (incl. patchniveau).
- Zoek afwijkingen in cms_block en cms_page op HTML/JavaScript-fragmenten die niet passen bij normale content.
- Controleer sessies en admin-toegang: kijk naar nieuwe gebruikers, rechtenwijzigingen en onbekende inlogmomenten.
- Registreer indicatoren: noteer domeinen die in gekoppelde requests of scripts voorkomen en zet ze om in detectieregels (bijv. voor webproxy/WAF).
- Herhaal testbezoeken: doe een gecontroleerde test vanuit verschillende “profielen” om te zien of een bot-filter effect heeft op jouw detectie.
Voor extra context over hoe aanvallen zich kunnen vastzetten bij kwetsbaarheden en waarom snelle patching essentieel is, is het relevant om ook te kijken naar eerdere analyses van vergelijkbare exploitketens en mitigaties. Bijvoorbeeld: PHP2Shell en andere RCE-risico’s: patch snel.
Heb je daarnaast te maken met misbruik van messaging of supportkanalen, dan kan ook fraudepreventie helpen om besmetting via sociale routes te beperken, zie bijvoorbeeld Microsoft Teams IT-support scams: malware & ransomware.
Conclusie
De campagne van Sansec laat zien dat aanvallers niet alleen kwetsbare Magento-installaties targeten, maar ook de detectie ontwijken. Magento besmet via cms_block betekent in de praktijk dat kwaadaardige JavaScript loaders via CMS-blocks in de storefront meekomen, terwijl bot-filtering scanners afsnijdt. Daardoor kan de besmetting langer onopgemerkt blijven.
Voor webshops is de boodschap helder: controleer CMS-blocks en accounts grondig, installeer patches en leg verdachte patronen vast. Alleen zo maak je de keten zichtbaar en voorkom je dat echte bezoekers alsnog worden blootgesteld aan de volgende stage van de aanval.
Bron: https://thehackernews.com/2026/10/hackers-infect-953-online-stores-with.html
