Webshop gehackt? Wij helpen je vandaag nog
Een skimmer op je checkout, een onbekende admin-user of een melding van je betaalprovider: elk uur telt. Wij stoppen de schade, zoeken uit hoe de aanvaller binnenkwam en zetten je webshop schoon terug. Je praat direct met de developer die het werk doet.
- Direct contact, geen ticketwachtrij
- Ingang vinden, niet alleen opruimen
- Schoon herstel met nieuwe sleutels
Opruimen is niet hetzelfde als herstellen
De meeste gehackte webshops zijn niet één keer gehackt. Ze zijn twee of drie keer gehackt, omdat de eerste schoonmaak alleen het zichtbare bestand verwijderde. De ingang bleef open, een backdoor bleef staan, en een week later zat de skimmer er weer.
Echt herstel betekent drie dingen. Je stopt de actieve schade. Je vindt hoe de aanvaller binnenkwam en wat hij heeft achtergelaten. En je bouwt de shop terug op een basis waarvan je weet dat die schoon is, met nieuwe wachtwoorden, keys en tokens.
Dat doen wij met een vast senior team dat Magento, Shopify en Laravel dagelijks onder handen heeft. Geen accountmanager die je doorverbindt. Je belt of mailt, en de persoon die antwoordt kijkt mee in je logs.
Signalen dat je webshop gehackt is
Niet elke hack is zichtbaar. Skimmers zijn juist gebouwd om onopgemerkt te blijven. Dit zijn de signalen die we het vaakst zien.
Melding van je betaalprovider of bank
Je PSP of acquirer meldt dat kaarten die bij jou gebruikt zijn later misbruikt worden. Dat is vaak het eerste harde signaal van een Magecart-skimmer.
Lees verder →Onbekende scripts op de checkout
Een extern JavaScript-bestand dat je niet kent, of inline code in je head die er gisteren nog niet stond. Kijk ook in de database, niet alleen in bestanden.
Lees verder →Nieuwe admin-users of rare logins
Een admin-account dat niemand heeft aangemaakt, logins op vreemde tijden of vanaf onbekende IP's. Ook een gewijzigd e-mailadres op een bestaand account is verdacht.
Lees verder →Gewijzigde bestanden of onbekende PHP
Bestanden in pub/media of var die PHP bevatten, gewijzigde core-bestanden, of een git status die niet schoon is terwijl er niet gedeployed is.
Een server die plots zwaar draait
Hoge CPU zonder extra bezoekers wijst vaak op een cryptominer. Die komt zelden alleen: wie een miner kan plaatsen, kan ook je data lezen.
Spam, redirects of blacklist-meldingen
Google Search Console meldt malware, bezoekers worden doorgestuurd naar andere sites, of er verschijnen spampagina's in de zoekresultaten van je domein.
Wat je in het eerste uur doet (en wat niet)
Paniek leidt tot overhaaste stappen die bewijs vernietigen. Dit is de volgorde die we aanhouden.
Wel doen
- Bel of mail ons, en je hostingpartij, zodat er direct iemand meekijkt
- Maak een snapshot of volledige back-up van de huidige staat, inclusief logs, vóór je iets verwijdert
- Zet de checkout of de hele shop in maintenance-mode als er een actieve skimmer draait
- Noteer wat je zag, wanneer, en wie toegang had: tijdlijn is goud waard
- Waarschuw je betaalprovider als er kaartgegevens in het geding kunnen zijn
Niet doen
- Niet alleen het verdachte bestand verwijderen en verder gaan
- Niet de server herinstalleren voordat logs en bestanden veiliggesteld zijn
- Niet zomaar een oude back-up terugzetten: die kan de backdoor al bevatten
- Niet wachtwoorden wijzigen vanaf een machine die mogelijk zelf besmet is
- Niet publiek communiceren voordat je weet wat er gebeurd is
Hoe aanvallers binnenkomen
We zoeken altijd de ingang. Zonder die te dichten is elke schoonmaak tijdelijk.
| Ingang | Hoe het werkt | Wat wij controleren |
|---|---|---|
| Ongepatchte Magento-lekken | Bekende lekken zoals TrojanOrders (CVE-2022-24086), CosmicSting (CVE-2024-34102) en SessionReaper (CVE-2025-54236) zijn massaal misbruikt bij shops die te laat patchten. | Versie en patchniveau, welke bulletins ontbreken, sporen van bekende exploits in access logs. |
| Kwetsbare extensie of plugin | Een module van derden met een lek of een niet-onderhouden plugin geeft een aanvaller een ingang naast de core. | Inventaris van alle extensies, versies en bekende lekken, plus code die niet uit een bekende bron komt. |
| Gestolen of zwakke admin-login | Hergebruikt wachtwoord, geen 2FA, of een oud account van een vertrokken medewerker of bureau. | Alle admin-accounts, laatste logins, 2FA-status, IP-herkomst van sessies. |
| Lek in PHP of de server | Kritieke lekken in PHP zelf, zoals PHP2Shell, of een open Redis, database of SSH met wachtwoord. | PHP-versie, publiek bereikbare services, SSH-config, cronjobs en onbekende processen. |
| Livewire- of Filament-lek in Laravel | Een kwetsbare Livewire v3-versie (CVE-2025-54068) maakte remote code execution mogelijk, ook in Filament-panels. | Composer lockfile, composer audit, bereikbaarheid van admin-panels. |
| Gecompromitteerde third-party scripts | Een extern script (chat, analytics, review-widget) wordt aangepast bij de bron en laadt zo code op jouw checkout. | Alle externe scripts op betaalpagina's, CSP-rapporten, SRI-hashes. |
Forensisch onderzoek: wat we uitzoeken
Forensisch klinkt zwaar, maar het komt neer op vier vragen. Wanneer kwam de aanvaller binnen? Via welke route? Wat heeft hij gedaan of achtergelaten? En welke data kan hij hebben gezien?
Daarvoor leggen we de huidige code naast een schone referentie: je git-repository of een verse installatie van dezelfde Magento-, Laravel- of extensieversie. Elk verschil wordt verklaard of verwijderd. In de database zoeken we in plekken waar skimmers graag zitten, zoals core_config_data, cms_block en cms_page.
We lezen access logs en applicatielogs terug naar het moment van eerste misbruik. Requests naar ongebruikelijke endpoints, POST-requests naar bestanden die niet horen te bestaan, en logins die niet passen bij je team. Bij Magento gebruiken we waar zinvol ook scanners zoals de Adobe Security Scan Tool of Sansec eComscan, maar we vertrouwen niet blind op een scan: database-malware en maatwerk-backdoors vallen er soms doorheen.
Het resultaat is een tijdlijn in gewone taal. Die heb je nodig voor je eigen afweging over melden, voor je betaalprovider, en om te bewijzen dat het lek dicht is.
Melden: AP, betaalprovider en klanten
Wij geven geen juridisch advies. Wel leveren we de technische feiten die je nodig hebt om goed te beslissen.
Autoriteit Persoonsgegevens: binnen 72 uur
Een datalek met risico voor betrokkenen meld je binnen 72 uur nadat je het ontdekt (AVG art. 33). Wij leveren de tijdlijn en wat er mogelijk gelekt is. De afweging maak jij, eventueel met je jurist.
Lees verder →Betaalprovider en acquirer
Bij een skimmer op de checkout wil je PSP het weten. Zij kunnen vragen om een onderzoeksrapport. Wij beschrijven technisch wat er gebeurd is en wat er hersteld is.
Lees verder →Klanten informeren
Als er een hoog risico is voor klanten, moet je hen ook informeren. Wij helpen met een feitelijke, technisch correcte uitleg zonder te overdrijven of te bagatelliseren.
NIS2 en sectorregels
Valt je organisatie onder de Cyberbeveiligingswet, dan gelden mogelijk extra meldplichten. Check of het voor jou geldt.
Lees verder →Na het herstel: zorgen dat het niet terugkomt
Een schone shop zonder aanpassingen in beheer is over een paar maanden weer een doelwit. De aanvaller weet dat je bestaat, en de geautomatiseerde scans die je vonden draaien nog steeds.
Daarom sluiten we elk herstel af met een korte lijst maatregelen, geordend op impact. Denk aan een vast patchritme, 2FA en IP-beperking op de admin, file integrity monitoring, CSP en SRI op de checkout, en alerts op nieuwe admin-users of gewijzigde betaalinstellingen.
Wil je dat structureel geregeld hebben, dan kan dat via ons Magento-supportcontract of als losse security audit. Niet verplicht: je krijgt de lijst sowieso, en je kunt hem ook zelf of met je eigen partij uitvoeren.
Zo werken we
Bij een hack werken we in vaste stappen. De eerste twee lopen vaak parallel, omdat schade stoppen voor alles gaat.
- 1
1. Contact en containment
Je spreekt direct een senior developer. We bepalen samen of de checkout of de hele shop dicht moet en blokkeren actieve skimmers of backdoors.
- 2
2. Bewijs veiligstellen
We maken een kopie van code, database en logs voordat we iets wijzigen. Zo kan het onderzoek achteraf nog alles terugzien.
- 3
3. Ingang en impact bepalen
We vergelijken code met een schone bron, doorzoeken de database en lezen logs terug. Uitkomst: hoe kwam de aanvaller binnen, wat deed hij, welke data is geraakt.
- 4
4. Schoon herstel
We bouwen terug vanaf een betrouwbare bron, patchen het lek, verwijderen alle backdoors en zetten de shop gecontroleerd weer live.
- 5
5. Sleutels en toegang roteren
Alle wachtwoorden, API-keys, integratietokens, SSH-keys en waar nodig de Magento-encryptiesleutel worden vervangen. Oude accounts gaan eruit.
- 6
6. Rapport en nazorg
Je krijgt een tijdlijn, de oorzaak, wat we gedaan hebben en een geprioriteerde lijst vervolgstappen. In de weken erna houden we extra toezicht.
Wat je krijgt
- Direct een senior aanspreekpunt, geen ticketwachtrij
- Stopzetten van actieve skimmers, redirects of miners
- Vastgestelde ingang en een tijdlijn van het incident
- Schone codebase en database, vergeleken met een betrouwbare bron
- Rotatie van wachtwoorden, API-keys, tokens en waar nodig de encryptiesleutel
- Technisch rapport in gewone taal, bruikbaar voor AP, PSP en verzekeraar
- Geprioriteerde lijst maatregelen om herhaling te voorkomen
- Extra monitoring in de periode na herstel
Waarom Coding.nl
Direct de juiste persoon
Geen projectmanager, geen sales, geen doorverbinden. Bij een hack praat je meteen met iemand die je server en code kan lezen.
15+ jaar e-commerce
We hebben de grote Magento-lekken van dichtbij meegemaakt en weten waar aanvallers hun code verstoppen, in bestanden én in de database.
Magento, Shopify en Laravel
Hyvä Silver Partner en Hypernode Silver Partner. Ook voor Laravel-portals en Filament-panels, dus ook als de ingang naast je webshop zit.
Eerlijk over wat nodig is
Niet elke verdachte melding is een hack. Is het loos alarm, dan zeggen we dat, en hoef je geen herstelproject te betalen dat je niet nodig hebt.
Verder lezen
- ›Magento 2 gehackt: dit doe je de eerste 24 uur
- ›Magecart skimmer: detecteren en verwijderen in je webshop
- ›Skimmer in de database: verborgen code in Magento CMS-blocks
- ›Incident response plan webshop: monitoring en draaiboek
- ›Datalek webshop: wanneer melden bij de AP en hoe binnen 72 uur?
- ›Magento malware scan: Security Scan Tool, eComscan en handmatig
- ›Magento encryptiesleutel en env.php: secrets beheren
- ›Back-ups tegen ransomware: een herstelplan voor je webshop
Veelgestelde vragen
Nu een hack of verdachte melding?
Bel of mail ons direct met je URL, wat je zag en wie je hosting beheert. Je krijgt een senior developer aan de lijn, geen wachtrij. We kijken eerst of het echt een hack is en stoppen de schade waar nodig dezelfde dag.