Gehackte WordPress site schoonmaken en verhuizen: clean-build aanpak

Gehackte WordPress site schoonmaken en verhuizen klinkt zwaarder dan het is. Het komt vooral neer op één principe: je migreert nooit de geïnfecteerde site, je bouwt een schone op en haalt alleen verifieerbare content terug. Wie dat principe vasthoudt, doorloopt zo’n migratie kalm. Wie de oude site letterlijk wil kopiëren, neemt de besmetting mee.

Er is een verschil tussen schoonmaken op je huidige hosting en schoonmaken plus verhuizen. Het tweede kost meer uren, maar geeft een diepere zekerheid. Vooral als je niet meer vertrouwt dat de huidige hosting wel volledig schoon te krijgen is, of als je toch al van plan was te verhuizen.

Hieronder de aanpak die ik standaard inzet. Geen scare-tactics, gewoon de techniek en de keuzes. Wil je alleen opschonen zonder verhuizen, lees dan WordPress website gehackt herstellen, waar de variant zonder hosting-wissel staat beschreven.

Waarom schoonmaken en verhuizen vaak samen gaan

Drie redenen waarom ik vaak een combinatietraject doe:

• De hosting is mogelijk op systeemniveau besmet (gedeelde server, andere accounts via dezelfde inlog gecompromitteerd). Een cleanup op die hosting laat een achterdeur openstaan.
• Backups van de hosting zijn besmet, of niet ver genoeg terug, of niet meer te vertrouwen.
• Een fresh start is administratief simpeler. Nieuwe credentials, nieuwe omgeving, schone monitoring.

Wanneer een combinatietraject niet nodig is: als de hack helder gelokaliseerd is (één plugin met een bekende kwetsbaarheid, één geïnjecteerde post), je hosting solide is, en je backups bewezen schoon zijn. Dan volstaat puur opschonen.

Eerste 24 uur: containment voor je iets verplaatst

Voor je een schone omgeving opzet, is het verstandig de besmetting niet verder te laten lopen. Concrete stappen:

• Site offline of in onderhoudsmodus, om bezoekers niet bloot te stellen.
• Alle wachtwoorden roteren: WP-admin, hosting-account, FTP/SFTP, MySQL, alle gekoppelde diensten (Cloudflare, mail, payment gateway-accounts).
• Twee-factor-authenticatie aanzetten waar mogelijk.
• Een snelle backup van de huidige (besmette) staat. Niet om terug te zetten, wel om later forensisch te kunnen kijken.
• Search Console: kijk of er een “Security Issues”-melding staat. Nog niet weghalen, dat komt aan het einde.

Deze fase is niet de migratie zelf. Dit is voorkomen dat je werkende handen omhoog gooien terwijl de besmetting nog actief data wijzigt.

Gehackte WordPress site schoonmaken en verhuizen via een clean-build

Het clean-build-principe in vijf stappen:

1. Nieuwe hosting opzetten. Een schone hosting-omgeving, idealiter bij een andere partij dan waar de besmetting plaatsvond. PHP-versie up-to-date, schoon account.
2. Schone WordPress-core installeren. Direct vanaf WordPress.org de laatste versie. Geen kopie van de oude wp-content-map.
3. Content selectief terugbrengen. Database na inspectie, uploads na scan, alles wat verder mee moet uitsluitend uit officiële bron.
4. Plugins en thema’s opnieuw installeren. Niet kopiëren vanaf de oude site, maar opnieuw downloaden uit WordPress.org of de officiële leverancier.
5. Redirects vanaf de oude hosting. Een tijdelijke periode waarbij requests op de oude hosting 301-doorverwijzen naar de nieuwe.

Dit is geen herbouw. Je content komt terug, je structuur komt terug, je URL’s blijven. Wat niet terugkomt is de PHP- en JavaScript-code die mogelijk besmet was. Dat is precies het verschil tussen een clean-build en een gewone migratie.

Wat je wel en niet meeneemt naar de nieuwe omgeving

Een complete checklist:

Niet meenemen:

• wp-content/themes/: opnieuw downloaden uit officiële bron (WordPress.org, of de website van de betaalde theme-leverancier).
• wp-content/plugins/: idem.
• wp-content/mu-plugins/: eerst inspecteren, dan opnieuw bouwen of weglaten. Vaak zit hier juist code die niet hoort.
• wp-config.php: opnieuw genereren op de nieuwe installatie, met nieuwe salts.
• .htaccess: laat WordPress een nieuwe maken.
• Losse PHP-bestanden in de root (index.php wordt de standaard, alles wat erbij staat is verdacht).
• Custom code in wp-content/uploads/ of wp-content/cache/ met .php-extensie (uploads horen geen PHP te zijn).

Wel meenemen, na controle:

• wp-content/uploads/: scannen op .php-bestanden en op JavaScript-injecties in beeldbestanden voor je het overzet.
• Database (SQL-dump): na inspectie van wp_users, wp_options, wp_posts en wp_term_taxonomy op vreemde rijen.

Wat hier vaak verkeerd gaat: mensen kopiëren de hele wp-content-map omdat ze “alles bij elkaar willen houden”. Daar zit precies waar de besmetting graag verstopt, dus dat is wat je juist niet wil. Het pakken van plugins uit officiële bron kost een halfuur extra en levert je een echt schone basis op.

Database opschonen voor de import

De database neem ik wel mee, na inspectie. Een SQL-dump van de oude database is de bron, en je loopt er een paar checks op uit:

• wp_users: zoek naar gebruikersnamen die je niet herkent. Vooral admins. Verwijder de regels (en bijbehorende wp_usermeta-records) voor je de SQL importeert.
• wp_options: zoek op eval, base64_decode, gzinflate, eval(base64. Dat zijn klassieke obfuscation-patronen. Vreemde regels in option_value met lange random strings zijn verdacht.
• wp_posts: kijk naar auteurs die niet bekend zijn. Posts met post_status = publish en een vreemde URL-slug, of body-content vol JavaScript-redirects.
• wp_options regel met key = 'cron': hier staan geplande taken. Vreemde scheduled events met PHP-functies die je niet kent zijn een belmoment.
• wp_term_taxonomy en wp_terms: minder vaak doelwit, maar check op vreemde tags die plotseling honderden posts categoriseren.

Een snelle methode is in phpMyAdmin de SQL openen of via wp-cli wp db query te draaien. Voor grote sites is een dedicated check via een script efficiënter dan handmatig kijken.

Uploads-map scannen voor je het overzet

De uploads-map (wp-content/uploads/) is meestal het lastigste deel. Hier staan jaren aan media die je niet wil verliezen, maar in een gehackte site verstoppen aanvallers graag PHP-bestanden of geïnjecteerde JavaScript in afbeeldingen.

Concrete scans:

find wp-content/uploads/ -name "*.php" -type f
find wp-content/uploads/ -name "*.phtml" -type f
find wp-content/uploads/ -name "*.shtml" -type f

Alles wat hieruit komt is bijna zeker geen legitieme upload en is verdacht. Verwijderen voor je de map verplaatst.

Daarna een malware-scan op de hele map. Tools die werken:

• Wordfence Command Line Scanner (gratis, voor server-side scans).
• MalCare of Sucuri SiteCheck voor cloud-based scans.
• ClamAV als algemene server-scanner.

Geen enkele scanner is perfect. De combinatie van een filter op .php-extensies plus een handmatig steekproef op verdachte mappen vangt het meeste.

Tijdelijke redirects en monitoring

Na de migratie blijft de oude hosting nog 7 tot 14 dagen live, met één doel: requests die nog naar het oude IP komen 301-doorsturen naar de nieuwe omgeving. Concrete instellingen:

• Alle URL’s 301-redirect naar de nieuwe host, behalve /wp-admin/ en /wp-login.php. Die laat je 404 geven, zodat eventuele backdoors die nog vanuit de oude omgeving werken geen toegang meer hebben.
• Een crawl-rapport van Search Console om te zien welke URL’s nog bezocht worden. Onverwachte URL’s (lange random paden, vreemde extensies) zijn een teken dat aanvallers nog scannen of je bestaat.
• Mail-monitoring: kijk of e-mailbevestigingen van orders, formulieren en abonnementen normaal blijven binnenkomen.

Search Console’s “Security Issues”-melding krijg je leeg via een reconsideration request, te starten zodra de site schoon is en alle scans niets meer rapporteren. Google reageert meestal binnen een paar dagen.

Voor de structurele beveiligings-baseline na de migratie is de WordPress.org Codex: Hardening WordPress een goede referentie. Niet alles tegelijk implementeren, wel rustig doorlopen in de week na de switch.

Wat kost een clean-build verhuizing

Een schoonmaak-plus-verhuizing reken ik tegen 95 euro per uur. Typische scope 12 tot 30 uur voor een kleine site met één malware-familie. Bij complexe infectie of e-commerce loopt het richting 30 tot 60 uur. Eerlijke schatting nadat ik de site heb bekeken.

Wat in die uren zit:

• Inspectie en scope-bepaling
• Database-cleanup en uploads-scan
• Schone nieuwe omgeving opzetten
• Selectieve migratie
• DNS-switch en nazorg-week
• Indien nodig: Search Console reconsideration en monitoring

Geen leverancier kan honderd procent malware-vrij garanderen. Wat een clean-build wel doet is het risico drastisch verkleinen door de besmettingsbron (de oude codebase) niet mee te nemen. Dat is meer dan een normale cleanup biedt. Speelt er een vermoeden van een datalek, dan stem ik de juridische kant af met een privacy-advocaat, dat valt buiten mijn vakgebied.

Verbeteren boven herbouwen geldt ook hier. Clean-build is geen herbouw: je content komt terug, je SEO-history blijft, je structuur blijft, alleen dan op een schone basis. Een rebuild vanaf nul is meestal niet nodig en kost het dubbele.

Hetzelfde clean-build-principe werkt voor gehackte Joomla- of Drupal-sites. Andere CMS-structuur, zelfde aanpak: nieuwe installatie, content selectief terug, plugins en thema’s uit officiële bron. Multi-stack maakt het pad iets anders maar het idee blijft.

Source-code is hier letterlijk waar het werk zit. Ik kijk in wp_options, scan PHP-bestanden, en herken patronen uit veertien jaar opruimwerk. Eén persoon, één traject, geen ticket-systeem.

Vragen die ik krijg over clean-build verhuizingen

Kan ik mijn huidige hosting houden en alleen schoonmaken?

Ja, dat kan. Dan doe je een pure cleanup zonder verhuizing. Voor wie de hosting vertrouwt en de scope van de hack helder is, kan dat de juiste keuze zijn. Voor wie liever een nieuwe omgeving wil of niet meer zeker is van de hosting, is de combinatie veiliger.

Hoe weet ik of mijn backup ook geïnfecteerd is?

Lastig zonder inspectie. Een backup uit een periode voor de eerste tekenen van een hack is vaak een veilige bron. Een backup van vorige week, terwijl de hack al twee weken speelt, is verdacht. De datum van de eerste vreemde activiteit in logs of in wp_options geeft een indicatie tot wanneer je terug moet.

Moet ik mijn klanten of bezoekers informeren?

Hangt af van wat er gebeurd is. Bij datalek (klantgegevens betrokken) is melding bij de Autoriteit Persoonsgegevens binnen 72 uur verplicht, plus communicatie naar betrokkenen. Bij een hack zonder datalek (alleen defacement of malware-injectie zonder toegang tot klantdata) is communicatie naar bezoekers vaak voldoende, of zelfs niet nodig. Bij twijfel rondom een datalek of meldplicht is overleg met een privacy-advocaat verstandig, dat valt buiten mijn vakgebied.

Hoe lang ben ik offline tijdens een clean-build?

De site zelf is meestal helemaal niet offline tijdens de migratie. De oude site blijft draaien terwijl ik de nieuwe opzet. De DNS-switch zelf is een paar minuten met een lage TTL. De totale doorlooptijd is meestal één tot drie weken, afhankelijk van de scope.

Wat voorkomt een herinfectie na de migratie?

Een combinatie van: nieuwe credentials overal, twee-factor-authenticatie, een security-plugin als Wordfence of Solid Security, automatische updates voor WordPress en plugins, een backup-schema, en discipline rond plugin- en thema-keuze. Geen exotische gratis plugins van obscure bron. Houd het beheer overzichtelijk en updates regulier.

Volgende stap

Clean-build verhuizing laten begeleiden

Stuur me je URL, de huidige hoster en wanneer de hack opviel. Ik kijk naar de site, schat de scope en mail terug met een uurraming en planning.

Stuur je vraag