PrestaShop gehackt: een bankskimmer opsporen en verwijderen

De ergste hack is de hack die niets stukmaakt

Als een gehackte PrestaShop-webshop met een 500-fout plat gaat, merkt de eigenaar dat binnen het uur. Zit er een skimmer in, dan blijft alles gewoon werken: bestellingen komen binnen, klanten betalen, en een script dat in de betaalpagina is geïnjecteerd kopieert ondertussen kaartnummers naar een server van derden.

De golf die begin 2026 op PrestaShop is waargenomen, volgt precies dit patroon. Het startpunt is bijna nooit de core, maar een niet-bijgewerkte externe module, soms jaren eerder geïnstalleerd en daarna vergeten.

Twee gevolgen die meteen spelen: u verliest uw PCI DSS-conformiteit bij uw betaaldienstverlener, en u moet het datalek binnen 72 uur melden bij de bevoegde toezichthouder voor gegevensbescherming, op grond van artikel 33 van de AVG.

Signalen die u serieus moet nemen

Geen van deze signalen is op zichzelf een bewijs, maar elk ervan verdient onderzoek:

• klanten melden frauduleuze afschrijvingen kort na een bestelling bij u;
• uw betaaldienstverlener neemt contact op over een afwijkend fraudepercentage;
• een JavaScript-bestand van het thema heeft een recente wijzigingsdatum terwijl u niets hebt gepubliceerd;
• in de broncode van de bestelpagina staat een <script>-tag die naar een onbekend domein verwijst;
• Google Search Console meldt misleidende inhoud of geïndexeerde spampagina's.

De domeinen waarnaar de gegevens weglekken, imiteren bewust legitieme diensten: namen met cdn, analytics, jquery of tag-manager erin, op ongebruikelijke extensies. Een domein dat op Google lijkt zonder google.com te zijn, is het betrouwbaarste signaal.

De diagnose via SSH, in vijf commando's

Bestanden die in de afgelopen zeven dagen zijn gewijzigd:

find . -type f -name "*.php" -mtime -7 -not -path "./var/cache/*"
find . -type f -name "*.js" -mtime -7 -not -path "./var/cache/*"

Verhulde code in thema's en modules:

grep -rl "eval(atob\|eval(String.fromCharCode\|_0x" themes/ modules/

Klassieke achterdeuren:

grep -rl "eval(\$_POST\|assert(\$_REQUEST\|base64_decode(\$_" . --include="*.php"

Aan de databasekant bestaat er een goed gedocumenteerde injectie waarbij JavaScript in de winkelnaam wordt gezet en vervolgens op elke pagina opnieuw wordt getoond:

SELECT name, value FROM ps_configuration WHERE value LIKE '%<script%';
SELECT id_employee, email, active FROM ps_employee;

Een medewerkersaccount dat u niet herkent, of een configuratiewaarde met HTML erin, geldt als bevestiging.

De opschoonprocedure

Een gehackte site in willekeurige volgorde opschonen leidt gegarandeerd tot herbesmetting. De volgorde telt.

1. Bevries de situatie. Maak een volledige kopie van de bestanden en de database voordat u iets aanraakt. Dat is uw enige bewijsmateriaal en uw enige kans om de toegangsroute te achterhalen.

2. Stop de bloeding. Zet de webshop in onderhoudsmodus. Zolang de betaalpagina online staat, blijven er kaartnummers weglekken.

3. Herstel de code vanuit een schone bron. Download de PrestaShop-core opnieuw in exact de geïnstalleerde versie en overschrijf de bestanden, met behoud van img/, upload/, download/, uw eigen modules en config/settings.inc.php. Installeer elke externe module opnieuw via de leverancier, nooit vanuit een archief dat u op de server aantreft.

4. Ruim de database op. Herstel de aangetaste waarden in ps_configuration, verwijder onbekende medewerkersaccounts en controleer de CMS-blokken en productbeschrijvingen op <script>.

5. Vernieuw alles. Wachtwoorden van medewerkers, het databasewachtwoord, FTP/SSH-toegang, API-sleutels van de betaalmodules en de cryptografische sleutels in config/settings.inc.php (_COOKIE_KEY_, _RIJNDAEL_KEY_). Het opnieuw genereren van die sleutels verbreekt alle sessies, ook die van de aanvaller.

6. Sluit de voordeur. Zonder deze stap volgt binnen enkele dagen een herbesmetting. Werk alle modules bij, raadpleeg per module de advisories van Friends-of-Presta en installeer de beveiligingspatches van de core.

De webshop daarna weerbaar maken

• Hernoem de beheermap en beveilig die met een extra HTTP-authenticatie.
• Verbied de uitvoering van PHP in img/, upload/ en download/ via de serverconfiguratie.
• Zet tweefactorauthenticatie aan voor alle medewerkersaccounts.
• Zet een web application firewall in en bewaak de integriteit van de bestanden: een nieuw PHP-bestand in modules/ hoort een melding op te leveren.
• Maak dagelijks een back-up, met een bewaartermijn van minimaal 30 dagen. Aan zeven dagen bewaartermijn hebt u niets als een inbraak pas na drie weken aan het licht komt.

Is uw webshop gecompromitteerd via een niet-gepatchte facetzoekmodule, lees dan ook onze analyse van het ps_facetedsearch-lek.

Hulp bij een noodgeval

Elke dag dat een skimmer blijft zitten, kost geld. Wij onderzoeken, schonen op en beveiligen, met een schriftelijke rapportage van de toegangsroute. Gratis diagnose, reactie binnen 1 uur — neem contact op.