Mijn WordPress-site is gehackt: wat nu?

Als je WordPress gehackt bent, is het eerste wat je doet: niets aanraken. Niet inloggen, niet opschonen, niet zelf proberen te repareren. Dat klinkt misschien contra-intuïtief. Maar het is geen voorzichtigheid, het is een technische realiteit: wat je zelf doet op dit moment maakt het onderzoek daarna onmogelijk.

Je bent hier waarschijnlijk met een leeg gevoel in je maag. De site is weg, verminkt, of stuurt bezoekers door naar een plek waar ze nooit mogen komen. Heb je al ingelogd of al iets geprobeerd, dan is dat geen ramp: vanaf nu zo min mogelijk veranderen is wat telt. Dit artikel legt uit wat er nu gebeurt en wat er daarna moet gebeuren.

Waarom zelf ingrijpen het probleem verergert

Hier zit de kern. Wanneer een aanvaller binnenkwam via een kwetsbaarheid, laat hij sporen achter in de logging. Die sporen zijn nodig om vast te stellen hoe de toegangsweg eruitzag. Opschonen wist precies die sporen.

Wat je daarna overhoudt is een schone site met een open deur. Je hebt het symptoom opgeruimd en de oorzaak laten staan. Dat verklaart waarom herinfectie zo snel kan volgen na een zelfherstelpoging.

In onze praktijk is een verouderde plugin in ongeveer 75 procent van de gevallen de toegangsweg geweest. Maar “verouderd” vertelt niet welke plugin, welk lek en welke versie. Die precisie haal je uit de sporen, niet uit een gok achteraf.

Wat mensen doorgaans als eerste proberen en waarom het niet werkt

Inloggen in WordPress. Op het moment van een actieve besmetting is de backend vaak al niet meer bereikbaar. Het lukt dan eenvoudigweg niet.

De hostingpartij bellen. Hosting kan je serveromgeving beheren, maar de besmetting zit in de bestanden en de database van jouw site. Dat valt buiten hun bereik. Ze zijn niet nalatig als ze zeggen dat ze het niet kunnen oplossen. Het is een kwestie van waar hun verantwoordelijkheid ophoudt.

Plugins updaten. Begrijpelijk, want een verouderde plugin is vaak de toegangsweg. Maar updaten verwijdert de besmetting niet. De code die al is geïnjecteerd blijft staan. Bovendien wist het updaten de sporen die nodig zijn om te achterhalen wat er is misbruikt. Te laat voor preventie, te vroeg voor herstel.

Meer over wat er mis kan gaan bij pogingen tot zelf verwijderen, staat uitgewerkt in het artikel over WordPress malware verwijderen.

Wat herstel inhoudt: het proces stap voor stap

Ook zonder toegang tot de WordPress-backend is herstel in vrijwel alle gevallen mogelijk. Via de hostingomgeving of op serverniveau is er vrijwel altijd een weg naar binnen. Dat is geen geruststelling om je te kalmeren, maar een feit over hoe herstel technisch werkt.

Dit zijn de stappen, en wat elke stap moet opleveren:

Toegang verkrijgen. Tot de site en de hostingomgeving, ongeacht of de WordPress-backend bereikbaar is.

Vaststellen waar de besmetting zit. Vaak gaat het om geïnjecteerde code in bestanden of om wijzigingen in de database. Dit geeft een beeld van de omvang.

Vaststellen hoe de aanvaller binnenkwam. Hiervoor wordt onder meer naar de serverlogging gekeken. Die laat zien wat er is gebeurd, wanneer en langs welke route. Als de oorzaak niet eenduidig is te herleiden uit de logs, of als een interne oorzaak niet is uit te sluiten, kan aanvullende logging worden opgezet. Zo wordt ook zichtbaar of het probleem aan gebruikerszijde ligt, bijvoorbeeld een besmette computer van iemand met beheerderstoegang.

De oorzaak dichten. Pas nadat de toegangsweg is vastgesteld. Dit is de reden waarom stap 3 vóór het opschonen komt. Wie eerst opschoont en daarna pas onderzoekt, sluit een deur die misschien niet de enige was.

Opschonen. Waaronder herinstallatie van de WordPress-core en het schoonmaken van de database en bestanden.

Oplevering. De site is schoon en weer bereikbaar.

Structureel onderhoud. Zodat de site bijgewerkt blijft en de kwetsbaarheid niet opnieuw ontstaat.

Herstel is een afweging, geen automatisme

Niet bij elke besmetting is doorrechercheren de snelste of verstandigste weg. Bij een kleinere site kan het exporteren van de content en opnieuw publiceren op een schone installatie de betere keuze zijn. We hebben dat gedaan bij een site waar de besmetting zich bleef verspreiden: content geëxporteerd, opnieuw opgebouwd op een schone basis, klant snel weer online. Doorrechercheren was in dat geval de duurdere en tragere route geweest.

De afweging hangt af van de omvang van de site, de complexiteit, wat er aan koppelingen actief is en wat de site moet kunnen blijven doen. Precies daar zit de ervaring.

Doorlooptijd en wat die bepaalt

De meeste sites zijn binnen een dag weer live. Dat is ervaring, geen toezegging. Wat de doorlooptijd bepaalt: of er een SLA-overeenkomst is, welke capaciteit op dat moment beschikbaar is, de omvang van de site, het aantal pagina’s of producten, en of koppelingen zijn geraakt. Bij een SLA-overeenkomst wordt binnen vier uur gehandeld bij een calamiteit.

Na herstel: wat je mag verwachten

Bij oplevering is de site schoon. Herhaling is nooit volledig uit te sluiten.

In de praktijk komt herinfectie weinig voor na professioneel herstel, omdat oorzaak en preventieve maatregelen met de klant worden doorgesproken en er daarna structureel onderhoud volgt. Preventie is een apart hoofdstuk, maar het begint direct na herstel. Wat dat inhoudt staat uitgelegd in Hoe beveilig je WordPress preventief?

Als er klantgegevens zijn buitgemaakt

Blijkt bij het onderzoek dat persoonsgegevens zijn ingezien of buitgemaakt, dan hoort daar juridische opvolging bij. De Autoriteit Persoonsgegevens is de bevoegde instantie in Nederland. Termijnen, melddrempels en precieze verplichtingen hangen af van de situatie en wijzigen met de regelgeving. Raadpleeg hiervoor een jurist.

Het volledige kader rondom beveiliging en herstel staat beschreven in WordPress beveiligen en een gehackte site herstellen, inclusief de stappen die aan herstel voorafgaan.

De beslissing is nu aan jou: hoe lang kan jouw site uit de lucht zijn, wat zijn de gevolgen van een dag zonder bereikbaarheid, en wie zorgt er na herstel voor dat updates worden bijgehouden en het onderhoud structureel is geborgd? Wie die vragen scherp heeft, weet ook welke vorm van ondersteuning daarbij past.

Frequently asked questions

Wat moet ik als eerste doen als mijn site gehackt is? Niets aanraken. Niet inloggen, niet opschonen, geen plugins updaten. Elke handeling in de site op dit moment kan sporen wissen die nodig zijn om de toegangsweg te achterhalen. Schakel zo snel mogelijk iemand in die het onderzoek kan uitvoeren voordat die sporen verdwenen zijn.

Mag ik zelf proberen de besmetting te verwijderen? Dat is af te raden, en niet alleen omdat het technisch ingewikkeld is. Zelf opschonen wist de logging die laat zien hoe de aanvaller binnenkwam. Zonder die kennis kun je het lek niet dichten, en dan keert de besmetting terug.

Kan mijn site hersteld worden als ik niet meer kan inloggen? Ja. Herstel hoeft niet via de WordPress-backend. Via de hostingomgeving of op serverniveau is er vrijwel altijd toegang mogelijk om het herstelproces te starten.

Hoe lang duurt het voordat mijn site weer online is? De meeste sites zijn binnen een dag weer live, maar dat is ervaring en geen toezegging. Bepalende factoren zijn de omvang van de site, de ernst van de besmetting, of er koppelingen zijn geraakt, en of er een SLA-overeenkomst van kracht is. Met een SLA wordt binnen vier uur gehandeld.

Is mijn site na herstel definitief schoon? Bij oplevering is de site schoon. Herhaling is nooit volledig uit te sluiten. Omdat de oorzaak tijdens het herstelproces wordt vastgesteld en gedicht, en er daarna structureel onderhoud volgt, komt herinfectie in de praktijk weinig voor.

Wat gebeurt er als er klantgegevens zijn buitgemaakt? Dan hoort daar juridische opvolging bij. De Autoriteit Persoonsgegevens is de bevoegde instantie in Nederland. Termijnen en meldverplichtingen hangen af van de specifieke situatie en de geldende regelgeving. Raadpleeg een jurist voor het eigenlijke advies.

Kan mijn hostingpartij dit oplossen? Doorgaans niet. De besmetting zit in de bestanden en database van jouw site zelf, en dat valt buiten het bereik van een hostingpartij.