Website gehackt: wat nu? Eerst schade stoppen, dan bewijs bewaren
Je ziet meteen dat er iets mis is: de website oogt anders of je krijgt meldingen van bezoekers of klanten. Wat je ook waarneemt, één ding is duidelijk: je website is gehackt. En nu?
De eerste neiging is vaak om direct alles op te schonen of terug te zetten. Maar als je dat doet voordat je de schade stopt en bewijs bewaart, loop je het risico dat de hack terugkomt of dat je belangrijke informatie kwijtraakt. Dit artikel helpt je stap voor stap om de schade te beperken, bewijs veilig te stellen en je website gecontroleerd terug te zetten, zodat de kans dat het meteen weer misgaat zo klein mogelijk is.
Eerste stappen: schade stoppen en bewijs bewaren
Zodra je merkt dat er iets mis is, is het belangrijk om eerst de schade te stoppen. Daarna kun je bewijs verzamelen en pas daarna overgaan op herstel. Doe dit in deze volgorde:
1. Zet je website tijdelijk offline of afgeschermd
- Dit helpt om te voorkomen dat bezoekers schade oplopen (bijvoorbeeld door malware) en beperkt dat de aanvaller verder kan gaan.
- Hoe? Bij veel hostingproviders kun je de website in een onderhoudsmodus zetten of tijdelijk uitschakelen via het controlepaneel. Als je niet zeker weet hoe, neem dan contact op met je hostingprovider.
2. Bewaar bewijs voordat je iets aanpast
- Maak een volledige backup van je website (bestanden én database).
- Bewaar logs, schermafbeeldingen en gegevens over het tijdstip die laten zien wat er is veranderd.
- Doe dit voordat je iets opschoont of herstelt, anders raak je mogelijk belangrijke informatie kwijt.
3. Niet doen: direct opruimen of wijzigingen doorvoeren
- Als je meteen begint met opschonen, loop je het risico dat je bewijs wist of dat de hacker nog steeds toegang heeft.
- Wacht met grote wijzigingen totdat je weet wat er precies is gebeurd.
Als je deze stappen hebt doorlopen, weet je wat voor soort hack het is en kun je bepalen wat je daarna moet doen.
Hoe ziet de hack eruit? Kies de volgende stap
Niet alle hacks zijn hetzelfde. Wat je ziet, bepaalt wat je daarna moet doen. Kies hieronder de situatie die het beste past bij wat jij waarneemt.
| Wat zie je? | Wat moet je direct doen? | Waar ligt je focus bij herstel? | Wanneer moet je hulp inschakelen? |
|---|---|---|---|
| Website zichtbaar kapot (inhoud is vervangen) | Zet de site tijdelijk offline of afgeschermd | Vervang bestanden uit een schone bron en zoek naar plekken die later opnieuw kunnen terugkomen | Als je niet zeker weet of er meer is dan "alleen inhoud" (bijv. accounts of data) |
| Doorverwijzingen of rare links (mogelijk kwaadaardige redirects) | Zet de site tijdelijk offline of afgeschermd | Check op ingespoten doorverwijscode en verdachte bestanden. Controleer of de bestanden overeenkomen met een bekende-goede versie | Als bezoekers of klantdata mogelijk geraakt zijn, of als het blijft terugkomen |
| Mogelijk account- of datadiefstal (vreemde inlog, nieuwe gebruikers, rare wijzigingen buiten zicht) | Sluit de toegang voorlopig af en voorkom verder misbruik | Plan volledige rotatie van toegang (wachtwoorden én toegangscodes). Controleer de database en gebruikers | Als klantdata mogelijk is gelekt of de omvang onduidelijk is |
Twijfel je tussen twee opties? Kies dan altijd de strengste route. Bijvoorbeeld: als je niet zeker weet of er alleen inhoud is aangepast of dat er ook data is gelekt, ga dan uit van de mogelijkheid dat er data is gelekt.
Voordat je schoonmaakt: bewijs en backups bewaren
Voordat je begint met opschonen of herstellen, is het belangrijk om bewijs te bewaren. Dit helpt je later om te controleren wat er is gebeurd en om ervoor te zorgen dat je website echt schoon is.
| Nu doen | Wat je moet bewaren | Wat je niet moet doen | Waarom dit belangrijk is |
|---|---|---|---|
| Maak een volledige backup | Bestanden én database | Wis of "ruim op" mogelijke geïnfecteerde bestanden op het originele systeem | Je hebt een referentie om later mee te vergelijken en om herstel veilig te laten verlopen |
| Bewaar logs, schermafbeeldingen en info over wanneer/wat | Server- en applicatielogs, CMS-activiteit (wijzigingen en gebruikers), schermafbeeldingen met tijdstip | Verander of verwijder logs voordat duidelijk is wat er is gebeurd | Je houdt overzicht van wat er is veranderd en wat mogelijk als eerste is misbruikt. Als je kunt: maak cryptografische hashes/checksums van je backup en logexports en bewaar die apart. |
Weet je niet precies waar je logs kunt vinden? Bewaar dan in elk geval wat je wél kunt exporteren en zet dat naast je backups. Zo heb je altijd een referentie.
Wachtwoorden resetten is niet genoeg: sluit alle toegangen af
Veel mensen denken dat het resetten van wachtwoorden voldoende is om een hacker buiten te houden. Helaas is dat vaak niet zo. Een hacker kan op verschillende manieren toegang houden, zelfs nadat je wachtwoorden hebt gewijzigd. Daarom: maak waar mogelijk de belangrijkste toegangen ongeldig (scope hangt af van je platform en toegangscode-type).
| Wat je moet doen | Wat dit voorkomt | Wat "ongeldig maken" betekent | Misvatting om te vermijden |
|---|---|---|---|
| Wachtwoorden wijzigen (accounts) | Toegang via inloggegevens | Wijzig wachtwoorden van alle betrokken accounts | "Als ik wachtwoorden reset, is het klaar." (Dat is vaak niet genoeg) |
| Hosting- en CMS-paneel, SFTP/FTP, database en e-mailherstel | Directe beheertoegang | Vervang wachtwoorden en toegang bij hosting, FTP/SFTP, database en herstelopties | "Alleen het CMS-wachtwoord is genoeg" |
| CDN, WAF, API-koppelingen, bezoekersstatistieken en Search Console | Verborgen koppelingen | Vervang toegangscodes voor integraties en meldkanalen | "Als de website er normaal uitziet, is de toegang weg" |
| Sessies en toegangscodes (cookies en andere toegangscodes) | Bestaande of langdurige toegang | Maak sessies ongeldig en trek toegangscodes in waar mogelijk | "Wachtwoorden of cookies wijzigen maakt toegang automatisch ongeldig" (Vaak niet) |
| Ondertekende toegangscodes en sleutels | Toegangscodes die nog werken | Trek waar mogelijk de gebruikte ondertekeningssleutels in | "Sleutels roteren is hetzelfde als intrekken" (Dat is het niet) |
De exacte opties hangen af van je platform, maar het doel is hetzelfde: zorg dat geen enkele bestaande toegang nog werkt.
Voordat je verder gaat met deze tabel: een hacker kan soms blijven inloggen via "blijvend ingelogd"-toegang (sessies/toegangscodes). Daarom kijk je niet alleen naar wachtwoorden.
Herinfectie voorkomen: controleer cron en geplande taken
Zelfs als je alles hebt opgeschoond en hersteld, kan een hack terugkomen. Dit gebeurt vaak via automatische taken die de hacker heeft ingesteld. Controleer daarom altijd op geplande taken voordat je je website weer online zet.
| Waar moet je kijken? | Voorbeelden van locaties | Wat zoek je? | Waarom dit belangrijk is |
|---|---|---|---|
| Linux/Unix cron | Voorbeelden (afhankelijk van je Linux-distributie): cron directories zoals cron.hourly/daily/weekly/monthly | Verdachte cronregels, ongebruikelijke uitvoerfrequentie, aanmaak of wijzigingen door onverwachte gebruikers | Als de site "opnieuw kapot" gaat na een schone restore, is dit vaak de oorzaak |
| Linux/Unix crontab en anacron | Kan o.a. voorkomen in: crontab/cron-spool locaties (vraag dit bij je hostingprovider op als je geen servertoegang hebt) | Cronregels die opnieuw commando's draaien of bestanden wegschrijven naar webmappen | Je ziet vaak snelle herhaling, soms binnen minuten |
| Windows: Geplande taken | Taakplanner + extra enumeratie/logs (verborgen taken kunnen buiten de normale interface vallen; op Windows is specifieke controle nodig, bv. via registry Security Descriptor deletion) | Taken die "weg" lijken in de normale weergave, of verdachte acties op vaste tijden | Herinfectie kan doorgaan zolang een geplande taak automatisch draait |
Kun je deze locaties niet zelf controleren? Vraag dan je hostingprovider om dit voor je te doen. Het gaat erom dat je zeker weet dat er geen automatische taken meer draaien die de hack kunnen herstellen.
Weer online: check deze voorwaarden voordat je live gaat
Je website weer online zetten is een belangrijke stap, maar doe dit alleen als je het kunt verifiëren met de voorwaarden hieronder.
| Voorwaarde | Hoe controleer je dit? | Wanneer is het in orde? | Wat doe je na het live zetten? |
|---|---|---|---|
| Bestanden kloppen weer | Vergelijk met een bekende-goede bron (bijv. schone backups of officiële bronnen). Voor WordPress: gebruik de officiële verificatie-/herstelmogelijkheden van je hosting/maintainer (of vraag dit bij je host) om bestanden te vergelijken met een bekende-goede versie. | Je hebt alleen bekende en goede bestanden teruggezet. Afwijkende of corrupte bestanden zijn vervangen | Blijf 7-14 dagen opletten (zie volgende sectie) |
| Geen blijvende besmetting of her-toegangspunten | Onderbouw waar mogelijk dat bekende reinfectieplekken en her-toegangspaden weg zijn, er geen nieuwe of ongebruikelijke admins zijn en er geen verdachte bestanden of database-injecties zijn | Je kunt aantonen dat bekende reinfectieplekken weg zijn en dat toegang en updates zijn gecontroleerd | Blijf 7-14 dagen opletten op inlogpieken, verdachte POST-verzoeken en meldingen (bijv. via Search Console) |
Ga pas weer online als je deze voorwaarden kunt controleren zonder te gokken.
Na herstel: blijf 7-14 dagen monitoren
Zelfs als je website weer online is en alles er goed uitziet, is het belangrijk om alert te blijven. Hackers proberen vaak opnieuw binnen te komen of laten automatische taken achter die pas later actief worden. Gebruik de watch-items uit de "Monitor 7-14 dagen"-kolom in de vorige tabel.
Hulp inschakelen: wanneer en wat je opvraagt
Soms is het verstandig om hulp in te schakelen. Bijvoorbeeld als je niet zeker weet wat er is gebeurd, als er mogelijk klantgegevens zijn gelekt, of als de hack steeds terugkomt. In dat geval kun je het beste een expert of je hostingprovider inschakelen. Maar wat moet je dan precies vragen?
| Wanneer schakel je hulp in? | Wat vraag je? | Wat moet je als antwoord krijgen? |
|---|---|---|
| Klantsensitieve data mogelijk gecompromitteerd of meldplichten | Serverlogs, CMS-activiteit (inhoud, wijzigingen, gebruikers) en input over vermoedelijke kwetsbaarheden in je CMS of technische omgeving | Een onderbouwd beeld van de impact en welke rotatie en opschoning echt zijn uitgevoerd |
| Omvang of oorzaak is onduidelijk, of het groeit | Backups voor analyse, logs (toegang, fouten, beveiliging) en informatie over de oorzaak | Een duidelijk stappenplan en bevestiging van rotatie en hoe reinfectie wordt voorkomen |
| Herinfectie blijft terugkomen na opschonen of herstel | Bewijs van verwijdering van persistente toegang (cron, geplande taken), bevestiging van toegangscode- en sessie-ongeldigmaking en monitoringafspraken | Harde bevestiging dat de punten om opnieuw binnen te komen echt zijn gesloten en dat er na het live zetten monitoring komt |
Als je escalatie doet, wil je vooral: logs, backups, rotatiebewijs en afspraken over het blijven opletten.
Als je hulp wilt: vraag technische ondersteuning aan
Wil je hulp bij het herstel? Of wil je extra zekerheid voordat je weer online gaat? Dan kun je technische ondersteuning aanvragen. Zorg dat je de volgende informatie bij de hand hebt:
- Wat je al hebt gedaan (bijv. site offline gezet, backups gemaakt)
- Welke bewijzen en logs je hebt bewaard
- Wat je al hebt geroteerd of ongeldig gemaakt
Stuur die informatie mee; dan kunnen we je helpen bepalen welke vervolgstappen nodig zijn voor controles en het blijven opletten.
FAQ: de meest voorkomende vragen in de crisis
Kan ik dit zelf oplossen?
Ja, dat kan, als je de stappen in dit artikel volgt. Begin met het stoppen van de schade en het bewaren van bewijs. Daarna kun je verder met het sluiten van toegangen en het herstellen van je website. Twijfel je of heb je niet genoeg technische kennis? Schakel dan hulp in.
Wat als ik geen backups heb?
Als je geen backups hebt, wordt het lastiger om je website veilig te herstellen. Je kunt proberen om losse bestanden te herstellen via je hostingprovider of een expert inschakelen. Zorg in de toekomst altijd voor regelmatige backups.
Waar vind ik de logs van mijn website?
Logs vind je meestal in het controlepaneel van je hostingprovider of via FTP in mappen zoals /logs of /var/log. Weet je niet waar je moet zoeken? Vraag dan je hostingprovider om hulp.
Moet ik melding maken van de hack?
Als er mogelijk klantgegevens zijn gelekt, kan er een meldplicht gelden. In Nederland kun je terecht bij de Autoriteit Persoonsgegevens (AP) voor meer informatie. Twijfel je? Schakel dan juridisch advies in.
Wat als mijn website op een onbekend CMS draait?
De stappen in dit artikel gelden voor de meeste CMS'en, maar sommige details kunnen verschillen. Vraag je hostingprovider of een expert om hulp bij het controleren van logs, geplande taken en het herstellen van je website.
Hoe voorkom ik dat mijn website opnieuw gehackt wordt?
Zorg voor regelmatige updates van je CMS, plugins en thema's. Gebruik sterke wachtwoorden en beperk het aantal admin-gebruikers. Overweeg ook om een beveiligingsplugin te installeren of een expert in te schakelen voor doorlopend websitebeheer.