Deepveindrilling: de loader in Magento CMS-blokken die scanners niet zien

Een schone scan, een volledig gepatchte Magento 2.4.7-p10, en een uur later toch weer een kwaadaardig script in de winkel. Dat beschrijft Sansec in een rapport van 24 oktober 2026 over een campagne die sinds juli 2025 953 winkels heeft geraakt, voor het grootste deel Magento.

Het script zit niet in een bestand. Het zit in de database, in je CMS-blokken. Het laat zich alleen zien aan echte bezoekers. Een scanner of crawler krijgt een lege pagina terug.

Wat is er aan de hand?

Sansec volgt deze groep sinds juli 2025. De aanvallers plaatsen een JavaScript-loader in de tabel cms_block, de statische blokken die Magento in je storefront rendert. Ze wisselen af en toe van domein. deepveindrilling.com is het vijfde loader-domein:

De aantallen overlappen. Veel winkels hebben meerdere generaties van de loader gehad. Van de 83 winkels met het nieuwe domein draaiden er 60 al een eerdere versie, 34 daarvan sinds oktober 2025. Wie eenmaal geraakt is en het niet opmerkt, krijgt gewoon de volgende versie.

deepveindrilling.com werd op 6 oktober geregistreerd. Een dag later laadden de eerste winkels het. Op 23 oktober herschreef de aanvaller de blokken met een nieuwe versie.

Wat de loader doet

De eerste versie bestond uit twee scripts:

• Een inline script leest een waarde fpCode uit de localStorage van de bezoeker. Staat die er, dan plakt het die waarde in het onclick-attribuut van een verborgen div, klikt erop en verwijdert de div. Zo draait de code zonder eval().
• Een <script>-tag laadt https://deepveindrilling.com/?s=d35c5031. Dat externe script zet fpCode.

Omdat de payload in localStorage blijft staan, draait hij bij elke volgende paginaweergave opnieuw. Ook als het domein offline is of geblokkeerd wordt.

De versie van 23 oktober vervangt de script-tag door een inline fingerprint-script. Dat kijkt of de browser geautomatiseerd is: navigator.webdriver, Selenium-variabelen en ChromeDriver-kenmerken. Het verzamelt ook de GPU-naam, het aantal CPU-cores, het geheugen, de schermgrootte, de tijdzone en de taalinstellingen. Op basis daarvan bepaalt de server of er een payload terugkomt.

Wat die payload is, weet nog niemand. Eerdere varianten van deze groep laadden crypto-gerelateerde scripts, onder meer van leqdger.click, een verbastering van de cryptowallet-merknaam Ledger. Of het nu om een betaalskimmer gaat, is niet bevestigd.

Wie loopt risico?

Iedere Magento-shop waar een aanvaller ooit schrijfrechten op de database of de admin heeft gekregen. Sansec noemt geen enkel lek als dé ingang, maar wel duidelijke patronen:

• In maart kregen 471 winkels in één uur de loader, nadat er webshells waren geplaatst via PolyShell (CVE-2026-48356). Meer daarover in ons artikel over PolyShell en de CISA KEV-lijst.
• Van 169 besmette Magento 2-installaties die minstens één core-patch misten, had 60% ook bestanden die via PolyShell of SessionReaper (CVE-2025-54236) waren geüpload.
• Eén winkel op 2.4.7-p1 had PolyShell-webshells als PNG vermomd in pub/media/custom_options/quote/, naast de loader in een CMS-blok.

En dan de 2.4.7-p10-winkel. Die miste geen enkele core-patch. Toch verscheen deepveindrilling.com op 23 oktober om 16:46 UTC, een uur na een schone scan. Die winkel had sinds 16 september een vreemd admin-account en sinds 24 september een GSocket-backdoor. Sansec zegt niet met zekerheid hoe de herbesmetting verliep, maar die twee liggen voor de hand.

Waarom patchen alleen niet genoeg is

Een patch sluit het lek waardoor de aanvaller binnenkwam. Hij doet niets met wat de aanvaller daarna heeft neergezet:

• een admin-account waarmee hij gewoon inlogt;
• een API-integratie met een geldig token;
• een backdoor of webshell op de server;
• inloggegevens die hij uit app/etc/env.php heeft gelezen, waaronder de database en de encryption key.

Met elk van die vier kan hij CMS-blokken herschrijven, zonder één lek te gebruiken. Dat is precies wat de 2.4.7-p10-winkel overkwam.

Waarom een scanner dit kan missen

Drie redenen:

1. Het zit in de database, niet in bestanden. Een scanner die alleen het bestandssysteem doorzoekt, ziet niets. Je code is schoon. Je content niet.
2. Externe scanners krijgen niets. Toen urlscan.io een besmette winkel laadde in een geautomatiseerde Chrome, kwam er een normale pagina terug zonder extra inhoud. De fingerprint herkent bots en scanners.
3. Het timing-gat. Een scan is een momentopname. Bij de 2.4.7-p10-winkel kwam de loader een uur na de schone scan binnen.

Wat je nu doet: de checklist

1. Zoek in de database. Dit zijn alleen SELECT-queries. Ze wijzigen niets. Draai ze bij voorkeur op een kopie of een read-only account. Gebruik je een tabelprefix, zet die er dan voor.

Op de indicatoren die Sansec publiceerde:

SELECT block_id, identifier, is_active, update_time
FROM cms_block
WHERE content LIKE '%fpCode%'
   OR content LIKE '%se_referrer%'
   OR content LIKE '%localStorage.getItem%'
   OR content LIKE '%deepveindrilling%'
   OR content LIKE '%additionalver%'
   OR content LIKE '%lanhd6549tdhse%'
   OR content LIKE '%neswnsssn%'
   OR content LIKE '%manulfie%';

Hetzelfde voor pagina's:

SELECT page_id, identifier, is_active, update_time
FROM cms_page
WHERE content LIKE '%fpCode%'
   OR content LIKE '%localStorage.getItem%'
   OR content LIKE '%deepveindrilling%'
   OR content LIKE '%additionalver%';

Breder, op elke <script>-tag. Dat geeft meer ruis, maar vangt ook de volgende domeinwissel:

SELECT block_id, identifier, update_time
FROM cms_block
WHERE content LIKE '%<script%'
ORDER BY update_time DESC;

Let op update_time. Dat is volgens Sansec het moment van de laatste schrijfactie van de aanvaller. Een blok dat je team al maanden niet heeft aangeraakt, maar wel gisteren is gewijzigd, verdient aandacht.

Sansec vond deze loader nooit in core_config_data. Andere campagnes gebruiken die tabel wel, via de velden voor extra HTML in de head of footer. Controleer ze daarom ook:

SELECT config_id, scope, scope_id, path
FROM core_config_data
WHERE value LIKE '%<script%'
   OR path IN ('design/head/includes', 'design/footer/absolute_footer');

Vraag in deze queries bewust niet de volledige content of value op als je de output deelt. Die kan het kwaadaardige script bevatten.

2. Controleer admin-accounts.

SELECT user_id, username, email, created, logdate, is_active
FROM admin_user
ORDER BY created DESC;

Elk account dat je niet kunt thuisbrengen, gaat eruit. Kijk ook naar logdate: een account van een oud-medewerker dat vorige week inlogde, klopt niet.

3. Controleer API-integraties. Kijk in de admin bij System > Extensions > Integrations. Een integratie die niemand herkent, verwijder je. Tokens van bekende koppelingen vernieuw je na de opschoning.

4. Zoek naar bestanden. Sansec noemt:

find pub/media/custom_options/ pub/media/customer_address/ -type f ! -name '.htaccess'
find . -name 'accesson.php' -type f

Controleer ook draaiende processen op iets onbekends, zoals de GSocket-backdoor uit het voorbeeld.

5. Ruim op en roteer.

• Verwijder de scripts uit de CMS-blokken en -pagina's.
• Wijzig de wachtwoorden van de database, de admin-accounts en de API-integraties.
• Vernieuw de encryption key (System > Other Settings > Manage Encryption Key). Wie env.php heeft gelezen, heeft die sleutel. Daarmee kan hij versleutelde configuratiewaarden ontsleutelen.
• Installeer APSB26-73 (PolyShell) en APSB25-88 (SessionReaper) als dat nog niet is gebeurd.

6. Zet een CSP neer. Een Content Security Policy beperkt van welke domeinen de browser scripts mag laden en waarheen hij data mag sturen. Een loader in een CMS-blok wordt daarmee niet verwijderd. Maar de call naar een onbekend domein wordt dan wel geblokkeerd. Magento heeft daarvoor de module Magento_Csp. Begin met report-only om te zien wat er breekt, en maak hem daarna strikt.

Een restrisico: localStorage

De payload staat in de localStorage van bezoekers die de besmette winkel eerder bezochten. Na het opschonen leest niets op je winkel fpCode nog uit, dus de code draait niet meer. Sansec beschrijft geen manier om die opgeslagen waarde bij bezoekers actief te wissen. Houd daar rekening mee.

Herken je dit en weet je niet waar je moet beginnen? Op /security/gehackt lees je hoe we een gehackte shop aanpakken. Voor een controle vooraf is er de security audit.