Een WordPress-site die er weer normaal uitziet, is niet hetzelfde als een WordPress-site die weer veilig is. Bij een besmetting die wij recent onderzochten, leek de website zelf op het eerste gezicht schoon — terwijl er elders binnen hetzelfde hostingaccount nog actieve kwaadaardige bestanden stonden. Dit artikel legt uit waarom “de verdachte bestanden verwijderen” vaak niet het einde van het probleem is, en welke stappen wij zetten om een besmetting daadwerkelijk af te sluiten.
Een praktijkcase (geanonimiseerd)
Bij een recent onderzoek op een hostingaccount met meerdere domeinen bleek dat een besmetting van maanden eerder nooit volledig was opgeruimd. De zichtbare website functioneerde normaal en de reguliere malwarescanner sloeg geen alarm. Verder onderzoek — buiten de webroot van de site zelf — bracht een zelfreplicerend bestandenpakket aan het licht dat op meerdere plekken binnen hetzelfde account stond, inclusief mappen die niet direct via de browser bereikbaar waren. Op basis van bestandstijdstempels bleek dit teruggeplaatst te kunnen worden vanaf een moment vóórdat de eerdere opschoning had plaatsgevonden.
Binnen de gecontroleerde scope werden geen actuele malware-indicatoren meer gevonden. Dat is een momentopname, geen permanente garantie — en dat onderscheid is precies waar dit artikel over gaat.
Waarom “de bestanden zijn verwijderd” niet het hele verhaal is
Wanneer een website eenmaal besmet is geweest, is de kans reëel dat er meer is gebeurd dan alleen de bestanden die opvallen. Een paar redenen waarom een oppervlakkige opschoning onvoldoende kan zijn:
- Een website kan schoon lijken terwijl er malware elders binnen hetzelfde hostingaccount staat — buiten de map van de site zelf.
- Oude domeinmappen, statistiekenmappen en verouderde back-ups worden bij een opschoning vaak over het hoofd gezien, terwijl ze besmette bestanden kunnen bevatten.
- Een backdoor die buiten
public_htmlis geplaatst, is niet direct via de browser bereikbaar — en kan daardoor later opnieuw worden teruggeplaatst zonder dat de website zelf iets laat zien. - Officiële WordPress-checksums vergelijken alleen WordPress-kernbestanden met de officiële versie. Ze zeggen niets over plugins, thema’s, de database, uploadmappen of bestanden die geen deel uitmaken van WordPress zelf.
- Beheerdersaccounts — zijn alle WordPress-beheerders bekend en legitiem, of is er een account bijgekomen dat niemand heeft aangemaakt?
- Cronjobs — zowel WordPress-eigen als serverniveau-cronjobs, want een geplande taak is een veelgebruikte manier om toegang te behouden.
- Database — onder andere op verdachte opties, geïnjecteerde content en ongebruikelijke wijzigingen in tabellen.
- Triggers en persistentiemechanismen — constructies die ervoor zorgen dat een verwijderd bestand zichzelf later herstelt.
- Uploadmappen — en of PHP-uitvoering daarin technisch mogelijk is, want dat is een veelgebruikt instapmechanisme.
- SSH-toegang — welke sleutels geautoriseerd staan en of daar recent daadwerkelijk mee is ingelogd.
- Hostingconfiguratie — zoals gedeelde accounts, rechten tussen domeinen onderling en overige serverinstellingen die de blootstelling beïnvloeden.
- PHP-uitvoering in uploadmappen blokkeren. Een uploadmap hoort afbeeldingen en documenten te bevatten, geen uitvoerbare code.
- Gestolen of verdachte toegangssleutels intrekken. Elke sleutel of login-key waarvan de vertrouwelijkheid niet met zekerheid vaststaat, wordt behandeld als gecompromitteerd.
- Wachtwoorden, salts, sessies en relevante API-credentials gecontroleerd roteren. Niet blind alles tegelijk, maar met een volgorde, een test na elke stap en een rollbackmogelijkheid.
- Besmette archieven niet blind terugzetten. Een back-up van vóór de besmetting is waardevol, maar een back-up van tijdens of net na de besmetting kan het probleem simpelweg terugzetten.
- Quarantaine in plaats van direct verwijderen. Zo blijft bewijs beschikbaar (bestandshashes, tijdstempels, locaties) mocht dat later nodig zijn.
- Rollback en functionele tests. Na elke ingrijpende wijziging wordt gecontroleerd of de site nog normaal werkt, met een weg terug als dat niet zo is.
Met andere woorden: het verwijderen van de bestanden die opvallen, lost het zichtbare symptoom op — maar bevestigt niet dat de onderliggende toegang ook is afgesloten.
Wat een grondig onderzoek daadwerkelijk controleert
Bij een malwareonderzoek kijken wij verder dan de eerste vondst. Onder meer de volgende punten komen aan bod:
Dit is bewust een combinatie van bestandsniveau, database, account en infrastructuur — een besmetting die alleen op bestandsniveau wordt bekeken, laat de andere lagen ongecontroleerd.
Herstel: meer dan bestanden verwijderen
Een zorgvuldig herstel bestaat uit een aantal stappen die in de praktijk regelmatig worden overgeslagen bij een snelle opschoning:
Monitoring: weten vóórdat een klant het meldt
Een van de meest onderschatte oorzaken waardoor een besmetting maandenlang onopgemerkt blijft, is niet het ontbreken van een scanner — maar het ontbreken van werkende alarmering daaromheen. Een detectie die nergens naartoe wordt verzonden, is in de praktijk hetzelfde als geen detectie. Aantoonbaar ontvangen waarschuwingen — dus een test die daadwerkelijk is gecontroleerd van trigger tot ontvangst — horen bij een volledige beveiligingsaanpak, niet alleen het aanzetten van een scanner.
Wat wij niet beweren
Voor de duidelijkheid: geen enkele partij kan absolute veiligheid garanderen, en dat beweren wij ook niet. Een grondig onderzoek en herstel verkleinen het risico aantoonbaar en sluiten bekende toegangswegen af — ze zijn geen garantiebewijs tegen elke toekomstige aanval. Bij de praktijkcase in dit artikel is bewust niet gesteld dat de exacte toegangsmethode volledig bewezen is; waar alleen een sterke aanwijzing bestaat, benoemen wij dat ook als zodanig, niet als vaststaand feit.
Veelgestelde vragen
Mijn website ziet er weer normaal uit. Kan ik ervan uitgaan dat de hack voorbij is?
Niet automatisch. Een site kan er normaal uitzien terwijl er elders binnen hetzelfde hostingaccount nog besmette bestanden staan, of terwijl een verborgen toegangsweg nog open staat. Een normaal ogende voorkant zegt niets over wat daarachter zit.
Is een WordPress-core-checksumcontrole niet voldoende om zeker te zijn?
Nee. Een checksumcontrole vergelijkt alleen WordPress-kernbestanden met de officiële versie. Plugins, thema’s, de database, uploadmappen en bestanden buiten WordPress zelf vallen daarbuiten — en dat zijn juist veelgebruikte plekken voor een backdoor.
Waarom zou ik verdachte bestanden niet gewoon zelf verwijderen?
Dat kan het zichtbare probleem tijdelijk laten verdwijnen, maar als de onderliggende toegangsweg (bijvoorbeeld een gestolen sleutel, een rogue beheerdersaccount of een cronjob) niet wordt gevonden en afgesloten, kan dezelfde besmetting terugkomen.
Hoe lang duurt een malwareonderzoek?
Dat hangt af van de omvang van de site en het hostingaccount. Na een kort kennismakingsgesprek geven wij een concrete inschatting, voordat er iets wordt uitgevoerd.
Kunnen jullie garanderen dat mijn site daarna nooit meer gehackt wordt?
Nee, en die garantie kan geen enkele partij oprecht geven. Wat wij wel doen: bekende toegangswegen sluiten, het risico aantoonbaar verkleinen en monitoring inrichten die u waarschuwt als er weer iets gebeurt.
Wat wij voor u kunnen doen
Vermoedt u dat uw website gehackt is, of wilt u vooraf zekerheid over de staat van uw WordPress-omgeving? Wij bieden hiervoor concrete, afgebakende diensten.
Mijn website is mogelijk gehackt
Neem direct contact op voor een malwareonderzoek — wij brengen eerst in kaart wat er precies aan de hand is, vóórdat er iets wordt uitgevoerd.
Nog geen concrete aanwijzing van een hack, maar wel behoefte aan zekerheid? Een WordPress-beveiligingsscan brengt de actuele status in kaart — core-checksums, plugins en thema’s, beheerdersaccounts, cronjobs en uploadmappen — met een kort, concreet bevindingenrapport.