Magento malware scan: Security Scan Tool, eComscan en handmatig

Een malware-scan vindt niet alles. Skimmers die in je database zitten, glippen door de meeste scanners heen. Dit is wat elke tool wel en niet ziet.

Veel shopeigenaren draaien één keer een scan, zien groen en gaan door. Dat voelt veilig. Het is het niet altijd. Een scanner is een filter met gaten, en aanvallers kennen die gaten.

In dit artikel zetten we de gangbare opties naast elkaar: de gratis Adobe Security Scan Tool, de commerciële Sansec eComscan en de handmatige controles die wij zelf gebruiken. Daarna volgt een scanritme dat past bij een gewone webshop.

Wat wil je eigenlijk vinden?

Malware in Magento komt in een paar vormen voor. Elke vorm vraagt een andere zoekmethode.

• Webshells en backdoors. PHP-bestanden die een aanvaller later weer binnenlaat. Vaak verstopt in pub/media, in een extensiemap of vermomd als een bestaand bestand.
• Gewijzigde core- of vendorbestanden. Een paar regels extra in een bestaand PHP-bestand, bijvoorbeeld in een betaalmodule.
• Skimmers (Magecart). JavaScript dat kaartgegevens onderschept op de betaalpagina en doorstuurt naar een server van de aanvaller. Meer over de werking lees je in ons artikel over Magecart-skimmers.
• Database-malware. Scriptcode opgeslagen in configuratie, CMS-blocks of e-mailtemplates. Zie het artikel over skimmers in je database.
• Rogue admin-gebruikers en cronjobs. Geen bestand, maar wel een blijvende toegang.

Een goede scan dekt de eerste drie af. De laatste twee vraag je er zelden mee uit.

Adobe Security Scan Tool

Adobe biedt een gratis Security Scan Tool aan via je Adobe Commerce-account. Je voert je domein in en krijgt een rapport.

• Het is gratis en je hebt geen toegang tot de server nodig.
• Het controleert van buiten, zoals een aanvaller dat ook zou doen.
• Het geeft een snelle indicatie van bekende kwetsbaarheden en verdachte configuratie.
• Het is een prima eerste stap als je nog nooit hebt gescand.

• Het kijkt niet in je bestandssysteem of database. Een webshell in een map die niet publiek bereikbaar is, ziet het niet.
• Het ziet geen skimmer die alleen reageert op bepaalde bezoekers of alleen op de betaalpagina.
• Het vervangt geen patchbeleid. Een groen rapport zegt niets over wat er morgen uitkomt.

Gebruik het als eerste check, niet als eindoordeel.

Sansec eComscan

Sansec is een bekende naam in Magento-security. Hun eComscan is een commerciële scanner die op de server draait. Dat is het grote verschil met een externe scan.

• Het draait lokaal en kan dus bestanden doorzoeken, niet alleen wat zichtbaar is voor bezoekers.
• Het werkt met een database van bekende malware-signatures voor Magento, die regelmatig wordt bijgewerkt.
• Het is gebouwd voor e-commerce en kent de typische plekken waar Magento-malware zich verstopt.
• Het is bedoeld om periodiek of continu te draaien.

• Het is betaald. Kijk op hun site voor de actuele prijzen en licentievoorwaarden.
• Signature-gebaseerd betekent: bekend is vindbaar, nieuw of aangepast kan ontsnappen.
• Je hebt servertoegang nodig om het te installeren. Op sommige hostingpakketten lukt dat niet.

Wij zien eComscan als een goede aanvulling op onderhoud, zeker voor shops die kaartgegevens via hun eigen checkout laten lopen. Het is geen vervanging van een audit.

Vergelijking in een oogopslag

De tabel laat een patroon zien. Hoe automatischer, hoe meer je op bekende patronen vertrouwt. Hoe handmatiger, hoe beter je afwijkingen vindt, maar hoe duurder het is.

Wat signature-scans missen

Een signature is een vingerafdruk van bekende malware. Aanvallers weten dat en passen zich aan.

• Obfuscatie. Dezelfde skimmer wordt anders gecodeerd, zodat de vingerafdruk niet meer klopt.
• Eigen varianten. Een aanvaller schrijft iets nieuws voor één shop.
• Legitiem uitziende plekken. Code in een template, een CMS-block of een configuratiewaarde ziet er voor een bestandsscanner uit als gewone data.
• Gerichte activatie. Een skimmer die alleen start op /checkout, voor bezoekers zonder admin-sessie, of alleen buiten kantooruren. Een scan van buiten ziet de aanval dan niet.

De les: een scan zonder context vindt de makkelijke gevallen. De moeilijke vind je door te vergelijken met hoe het hoort te zijn.

Zelf zoeken: de handmatige checks

Dit is wat wij gebruiken, vaak naast een scanner. Draai dit op een kopie of staging als dat kan, en lees altijd eerst voordat je iets verwijdert.

1. Vergelijk code met je repository

Als je code in git staat en je deployt vanuit git, is dit de krachtigste check. Alles op de server dat niet in git staat, is verdacht.

cd /pad/naar/magento
git status --short
git diff --stat

Op een productieserver horen geen wijzigingen te staan. Zie je die wel, dan wil je weten waarom. Let ook op nieuwe, niet-gevolgde bestanden in pub/, app/code/ en vendor/.

2. Zoek PHP waar het niet hoort

In pub/media hoort geen PHP. Afbeeldingen, PDF's, uploads, geen scripts.

find pub/media -type f -name "*.php*" -o -name "*.phtml" -o -name "*.phar"

Elke hit daar is een alarm, tenzij je precies weet waarom het er staat. Blokkeer uitvoering van PHP in die map ook in je webserverconfig. Dat staat in ons artikel over server hardening.

3. Zoek verdachte functies

grep -rEl "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" app/code pub --include=*.php

Dit geeft ruis. Legitieme code gebruikt base64_decode ook. Het gaat erom dat je de lijst kort genoeg krijgt om per bestand te beoordelen. Combineer het met de vraag: hoort dit bestand hier?

4. Kijk naar recent gewijzigde bestanden

find app pub lib -type f -mtime -14 -not -path "pub/static/*" -not -path "pub/media/catalog/*"

Pas het aantal dagen aan. Na een deploy zie je veel, daarom werkt dit het best naast een lijst van je eigen deploymomenten.

5. Controleer de database

Hier zit het gat van de meeste scanners. Controleer in elk geval:

• core_config_data, vooral de paden onder design/head/ en design/footer/
• cms_block en cms_page
• e-mailtemplates in email_template
• de lijst met admin-gebruikers in admin_user

SELECT config_id, scope, path, LEFT(value, 120)
FROM core_config_data
WHERE value LIKE '%<script%' OR value LIKE '%eval(%';

Hoe je dit systematisch doet, met meer queries en opruimstappen, staat in het artikel over skimmers in de database.

6. Controleer admin-gebruikers en cron

Een nieuwe admin die niemand kent is een van de duidelijkste signalen. Controleer admin_user op accounts en aanmaakdata. Kijk ook in cron_schedule en je systeem-crontab op taken die je niet herkent.

Hoe vaak scannen?

Er is geen magisch getal, maar er zijn wel redelijke uitgangspunten.

• Elke dag of continu: een geautomatiseerde scan en monitoring van wijzigingen op de betaalpagina, als je zelf kaartgegevens in je checkout verwerkt.
• Na elke deploy en elke patch: een snelle check op onverwachte bestandswijzigingen. Dit kost minuten als je het automatiseert met git.
• Elk kwartaal: een handmatige controle van admin-gebruikers, database-plekken en cronjobs.
• Direct bij twijfel, na een groot lek of na een incident: een volledige scan en een handmatige review.

Heb je een PCI DSS-verplichting, dan helpt een vast ritme ook als bewijs dat je detectie hebt ingericht. Voor wijzigingsdetectie op de betaalpagina speelt eis 11.6.1 een rol. Overleg met je QSA of betaalprovider wat voor jouw situatie vereist is, dit is geen juridisch advies.

Wanneer is dit overkill?

Eerlijk is eerlijk: niet elke shop heeft een betaald scanpakket nodig.

• Gebruik je een volledig gehoste betaalpagina van je PSP, dan loopt er geen kaartdata door je eigen code. Het risico verschuift dan naar accountovername en phishing, maar het skimmerrisico is kleiner.
• Draait je shop vanuit git met een strakke deployflow, dan vang je veel af met git diff alleen.
• Een kleine shop zonder custom code en met een bijgewerkte installatie heeft vaak meer aan goede patches en 2FA dan aan een extra scanner.

Een scanner helpt wel als je weinig controle hebt over wat er op de server staat, bijvoorbeeld bij een overgenomen shop of bij veel losse beheerders.

Wat doe je bij een hit?

Een gevonden bestand is een symptoom, geen oorzaak. Alleen het bestand verwijderen is meestal niet genoeg. De aanvaller is er via een kwetsbaarheid of gelekt wachtwoord ingekomen en kan terugkomen.

1. Maak eerst een kopie voor onderzoek, verwijder daarna.
2. Zoek de ingang: gepatcht? Admin-wachtwoord gelekt? Kwetsbare extensie?
3. Roteer wachtwoorden en sleutels waar nodig.
4. Controleer database en cronjobs, niet alleen de bestanden.
5. Weeg af of je een datalek moet melden. Bij risico voor betrokkenen geldt een meldplicht bij de Autoriteit Persoonsgegevens binnen 72 uur.

De volledige route staat in Magento 2 gehackt: wat nu? en op onze pagina Security voor gehackte shops.

Veelgestelde vragen

Is de gratis Adobe Security Scan Tool genoeg?

Voor een eerste indruk wel, als enige maatregel niet. De tool kijkt van buiten en ziet geen bestanden of database-inhoud. Combineer het met patchbeleid, 2FA en minimaal periodieke controles op de server.

Vindt Sansec eComscan alle malware?

Geen enkele scanner doet dat. Signature-scans vinden bekende malware goed en onbekende of sterk aangepaste varianten slechter. Vergelijking met je git-repository en controle van de database vullen dat gat.

Kan malware in mijn database zitten terwijl de bestandsscan schoon is?

Ja. Skimmers worden vaak opgeslagen in core_config_data, CMS-blocks of e-mailtemplates. Een bestandsscan komt daar niet, dus controleer de database apart.

Hoe vaak moet ik mijn Magento-shop scannen?

Verwerkt je checkout zelf kaartgegevens, dan liefst dagelijks of continu geautomatiseerd. Anders minimaal na elke deploy op wijzigingen en elk kwartaal met een handmatige controle. Na een incident of groot lek direct.

Moet ik na een schone scan nog een security audit laten doen?

Een scan beantwoordt de vraag of er bekende malware zit. Een audit beantwoordt of je shop veilig is ingericht. Dat zijn twee verschillende vragen. Zie wat er bij een Magento security audit wordt gecontroleerd.

Twijfel je of je shop schoon is, of wil je een vast scanritme laten inrichten? Neem contact op en je praat direct met degene die de controle uitvoert. Meer over onze aanpak vind je op /security/magento.