Een gehackte website levert meestal eerst paniek op en daarna haast. De site moet offline. Of juist zo snel mogelijk weer online. Er is ergens een back-up. Iemand roept dat alle wachtwoorden moeten worden gewijzigd. Een ander stelt voor om meteen maar een nieuwe website te bouwen. Allemaal begrijpelijke reacties, maar technisch gezien is er maar één goede eerste stap: eerst vaststellen wat er daadwerkelijk is gebeurd. Pas daarna kun je zinnig kiezen tussen herstellen, terugzetten of opnieuw bouwen.
Dat klinkt misschien als een open deur, maar in de praktijk wordt die stap nogal eens overgeslagen. Er wordt malware verwijderd, een back-up teruggezet of een plugin geüpdatet en daarmee wordt de zaak als opgelost beschouwd. Soms is dat inderdaad voldoende. Soms staat dezelfde rommel een week later weer op de server.
Een back-up terugzetten is niet automatisch herstel
Stel: op dinsdag blijkt dat er kwaadaardige code op de website staat. Er is een back-up van zondagavond. Dan is de eerste gedachte al snel: mooi, zondag terugzetten en klaar.
Maar wanneer is de website gehackt? Maandag? Zaterdag? Drie weken geleden? Als de aanvaller zaterdag al binnen was, zet je op dinsdag keurig een besmette website terug.
Dat is voor mij altijd een van de eerste vragen bij een incident: hoe ver moeten we terug om redelijk zeker te zijn dat de omgeving nog schoon was? Daarna volgt meteen de tweede: weten we waardoor de aanvaller binnenkwam?
Want als je alleen een oude versie terugzet zonder de oorzaak op te lossen, heb je hooguit de klok teruggedraaid. De voordeur staat dan nog steeds open. Het NCSC adviseert bij een gehackte website onder meer om vanuit een schone back-up te herstellen, software bij te werken en wachtwoorden te wijzigen. Dat woord schone is hier belangrijker dan het misschien lijkt. Een back-up is pas nuttig als je voldoende vertrouwen hebt in de toestand waarin die is gemaakt.
Eerst wil ik weten wat er veranderd is
Bij een gehackte website kijk ik niet alleen naar dat ene verdachte PHP-bestand dat toevallig is gevonden. Ik wil weten of er meer is gebeurd. Zijn er beheerdersaccounts toegevoegd? Zijn bestanden gewijzigd? Staat er code op plekken waar die niet hoort? Zijn er scheduled tasks of cronjobs bijgekomen? Zijn configuraties aangepast? Zijn FTP-, hosting- of CMS-wachtwoorden mogelijk buitgemaakt?
En vooral: is het aannemelijk dat we alles kunnen zien? Dat laatste maakt een groot verschil. Bij een goed onderhouden website waarvan de code in versiebeheer staat, kun je vrij snel vergelijken wat er op productie is veranderd. Dat maakt onderzoek aanzienlijk eenvoudiger.
Bij een website die in vijftien jaar door vier bureaus, twee freelancers en de eigenaar zelf is aangepast, waarbij productie feitelijk de enige broncode is, wordt dat een ander verhaal. Dan kom je bestanden tegen waarvan niemand meer weet of ze verdacht zijn of gewoon oud maatwerk.
Dat is niet per se een reden om de website weg te gooien. Maar het telt wel mee in de vraag hoeveel vertrouwen je na herstel nog kunt hebben.
Wanneer herstellen logisch is
Een hack betekent wat mij betreft absoluut niet automatisch dat de website vervangen moet worden. Als ik een recente Drupal- of WordPress-site voor me heb die normaal wordt onderhouden en waarvan de oorzaak duidelijk is, dan is herstellen vaak gewoon de rationele keuze.
Denk aan een kwetsbaarheid in één module of plugin. Als we kunnen vaststellen welke ingang is gebruikt, welke onderdelen zijn gewijzigd en hoe we die ingang definitief sluiten, is opnieuw bouwen meestal onzin.
Dan bestaat herstel uit meer dan alleen malware verwijderen. Je wilt de oorzaak oplossen, ongewenste bestanden en wijzigingen verwijderen, accounts en rechten controleren, relevante wachtwoorden en sleutels vervangen, software bijwerken en daarna opnieuw controleren of de installatie overeenkomt met wat je verwacht. Dat klinkt uitgebreid, maar het verschil zit hem precies daarin. “De malware is weg” is niet hetzelfde als “de website is weer betrouwbaar”.
| Situatie | Herstellen | Back-up terugzetten | Opnieuw bouwen |
|---|---|---|---|
| Oorzaak van de hack is bekend | ✓ | ✓ | Soms |
| Moment van besmetting is redelijk bekend | ✓ | ✓ | Niet noodzakelijk |
| Aantoonbaar schone back-up beschikbaar | Niet vereist | Vereist | Niet vereist |
| Website draait op ondersteunde software | Meestal goede reden | Meestal goede reden | Minder aanleiding |
| Veel onbekend maatwerk / onbekende wijzigingen | Lastiger | Riskanter | Meestal goede reden |
| Platform ontvangt geen reguliere security-updates meer | Tijdelijke oplossing | Tijdelijke oplossing | Meestal goede reden |
| Website moet op korte termijn toch worden vervangen | Zelden uitgebreid herstellen | Eventueel als noodoplossing | Meestal goede reden |
Waarom een hack soms terugkomt
Ik kom regelmatig situaties tegen waarin een website al eens eerder “schoongemaakt” is. Er is toen een bestand verwijderd, een scanner over de site gehaald en misschien een plugin geüpdatet. Een paar weken later is het opnieuw raak.
Dat betekent niet noodzakelijk dat dezelfde hacker opnieuw belangstelling kreeg. Veel waarschijnlijker is dat de oorspronkelijke toegang nooit volledig is afgesloten. Een aanvaller hoeft maar één manier over te houden om terug te komen: een extra beheerder, een verborgen script, een gestolen wachtwoord of een kwetsbare plugin die nog steeds actief is.
Daarom vind ik het eigenlijk minder interessant hoeveel malwarebestanden iemand heeft gevonden dan of duidelijk is hoe de aanval mogelijk werd. Zonder dat antwoord blijft herstel deels gokken.
Wanneer terugzetten juist wél de beste keuze is
Soms is terugzetten vanaf een back-up veruit de snelste en beste oplossing. Bijvoorbeeld wanneer we weten dat de hack gisteren plaatsvond, er een goede back-up van drie dagen eerder beschikbaar is en de kwetsbaarheid inmiddels bekend en verholpen is.
Dan heeft het weinig zin om handmatig tientallen gewijzigde bestanden te repareren. Terugzetten, bijwerken, credentials vervangen, controleren en weer online. Prima aanpak.
Maar ik wil dan wel weten dat de back-up werkelijk bruikbaar is. En daar blijkt in de praktijk nog wel eens een tweede probleem te zitten. Veel organisaties hébben back-ups, maar hebben nooit geprobeerd er een website uit terug te zetten.
Dat zijn twee verschillende dingen. Een map met database-dumps en bestanden op een server klinkt geruststellend, totdat tijdens een incident blijkt dat de database-back-up corrupt is, uploads ontbreken of niemand meer weet welke configuratie erbij hoort.
Een back-up die nooit is getest, is vooral een aanname.
En wanneer zou ik opnieuw bouwen?
Opnieuw bouwen wordt interessant wanneer het herstel steeds meer begint te lijken op archeologie. Niet omdat een website een bepaalde leeftijd heeft. Leeftijd alleen zegt weinig.
Ik heb liever een twaalf jaar oude website waarvan ik exact weet welke code erop hoort te staan dan een website van drie jaar oud met 48 onbekende plugins en rechtstreeks gewijzigde productiebestanden.
Voor mij ligt het omslagpunt vooral hier: hoeveel aannames moeten we doen om na herstel nog te kunnen zeggen dat deze omgeving betrouwbaar is?
Als het antwoord ‘te veel’ wordt, moet je serieus naar nieuwbouw kijken. Dat geldt bijvoorbeeld bij een sterk verouderd CMS, software waarvoor geen beveiligingsupdates meer beschikbaar zijn, veel onbekend of slecht gedocumenteerd maatwerk, talloze plugins of modules waarvan de functie onduidelijk is, een hostingomgeving met een lange en onduidelijke beheergeschiedenis of een website die technisch veel ingewikkelder is dan de huidige functie rechtvaardigt.
In zo’n situatie kun je veel tijd steken in onderzoek en reparatie, terwijl je uiteindelijk nog steeds op een technisch doodlopend systeem zit. Dan wordt herstellen goedkoop op de korte termijn en duur op de lange termijn.
Een gehackte oude Drupal-site is een goed voorbeeld
Bij Drupal-websites zie je dit vrij duidelijk. Stel dat een organisatie nog een oude Drupal-site heeft die ooit behoorlijk uitgebreid was. In de loop der jaren zijn functies verdwenen. Er resteert vooral een informatieve website met nieuws, pagina’s en een paar formulieren. Die site wordt gehackt.
Dan is de vraag niet alleen: kunnen we Drupal herstellen? Dat kan technisch best mogelijk zijn. De betere vraag is: willen we nog serieus geld investeren in het herstellen van deze specifieke installatie?
Als het platform sterk verouderd is, er veel historisch maatwerk in zit en een nieuwe site met aanzienlijk minder complexiteit hetzelfde bedrijfsdoel kan vervullen, dan kan nieuwbouw rationeler zijn.
En nieuwbouw hoeft dan ook niet automatisch “dezelfde website opnieuw in Drupal” te betekenen. Soms is WordPress voldoende. Soms is een moderne Drupal-versie logisch. Soms is een veel eenvoudiger technische opzet beter dan beide.
De hack is dan niet de reden om opnieuw te bouwen. De hack is het moment waarop zichtbaar wordt dat de oude technische situatie eigenlijk al langer niet meer logisch was.
De kosten van zekerheid
Dit is uiteindelijk waar de keuze vaak op neerkomt. Niet alleen: hoeveel kost herstel? Maar ook: hoeveel zekerheid koop je met dat herstel?
Je kunt twintig uur besteden aan het opschonen van een verouderde omgeving en daarna nog steeds niet exact weten of je alles hebt gezien. Je kunt ook meer tijd investeren in een schone nieuwe omgeving waarvan je exact weet welke componenten erin zitten en waarom.
Dat betekent niet dat nieuwbouw altijd veiliger of goedkoper is. Een slecht beheerde nieuwe website kan over een jaar net zo goed gehackt worden. Maar bij een technisch rommelige bestaande omgeving kan het verschil in controleerbaarheid doorslaggevend worden.
Vergeet de data niet
Bij een hack gaat de aandacht vaak volledig naar de website zelf. Maar als persoonsgegevens betrokken kunnen zijn, komt er nog een ander vraagstuk bij.
Zijn gegevens ingezien, gewijzigd of geëxporteerd? Kunnen we dat vaststellen? Staan er persoonsgegevens in formulieren, gebruikersaccounts, bestellingen of exports?
Bij een mogelijk datalek kan op grond van de AVG een meldplicht ontstaan. De Autoriteit Persoonsgegevens hanteert daarbij in veel gevallen een termijn van 72 uur nadat de organisatie kennis heeft genomen van het datalek.
Dat is dus geen onderwerp om pas te bekijken nadat de website technisch weer draait. Technisch herstel en beoordeling van een mogelijk datalek moeten soms parallel lopen.
| Feit | Betekenis bij een gehackte website |
|---|---|
| Drupal 7 ontvangt sinds 5 januari 2025 geen reguliere community-securityupdates meer. (Drupal.org) | Bij een gehackte Drupal 7-site weegt de vraag ‘nog herstellen of vervangen?’ daardoor zwaarder. |
| Een meldplichtig datalek moet in beginsel binnen 72 uur na kennisname bij de Autoriteit Persoonsgegevens worden gemeld. (Autoriteit Persoonsgegevens) | Onderzoek naar mogelijk gelekte persoonsgegevens kan niet wachten tot het technisch herstel klaar is. |
| Het NCSC waarschuwt dat back-ups zelf al malware kunnen bevatten en daarom niet zonder meer geschikt zijn voor volledig systeemherstel. (NCSC) | ‘We hebben een back-up’ zegt nog niet dat terugzetten veilig is. |
Wat ik na een hack vooral niet zou doen
Ik zou niet meteen een nieuwe website laten bouwen omdat iemand zegt dat ‘het CMS blijkbaar onveilig is’. Ik zou ook niet zonder onderzoek een back-up terugzetten. En ik zou zeker niet concluderen dat het probleem is opgelost omdat een malwarescanner geen meldingen meer geeft.
Een scanner is een hulpmiddel. Geen bewijs.
Uiteindelijk wil je drie dingen weten:
- Hoe kwam de aanvaller binnen?
- Wat heeft hij kunnen wijzigen of bereiken?
- Waarom denken we dat die mogelijkheid nu verdwenen is?
Als die vragen goed beantwoord kunnen worden, is herstel vaak prima. Als dat nauwelijks meer mogelijk is, wordt opnieuw bouwen een veel serieuzere optie.
‘Hij doet het weer’ is geen eindcriterium
Na een hack is de druk begrijpelijk genoeg: de website moet weer online. Maar technisch gezien is dat het makkelijke deel. Een website aan de praat krijgen lukt vaak wel.
De moeilijkere vraag is of je de omgeving daarna weer durft te vertrouwen. Dat is voor mij uiteindelijk het criterium. Niet of alle pagina’s weer laden. Niet of Google geen waarschuwing meer toont. Niet of een scanner groen licht geeft.
Maar of we redelijk kunnen uitleggen wat er is gebeurd, wat we hebben veranderd en waarom dezelfde route niet opnieuw gebruikt kan worden. Pas dan vind ik een gehackte website hersteld.