Kort gezegd: Wilt u malware van uw website laten verwijderen, dan volstaat het wissen van afzonderlijke bestanden zelden. Wij veiligstellen eerst de bevindingen, vinden webshells, achterdeuren en verborgen taken, bouwen opnieuw op vanuit betrouwbare bronnen en sluiten de toegangspoort. Pas dan is de reiniging betrouwbaar.
Waaraan u malware op de website herkent
Schadelijke code op websites valt vaak pas indirect op. Typisch zijn doorverwijzingen naar vreemde sites, spaminhoud die alleen voor zoekmachines of mobiele apparaten zichtbaar is, een Google-waarschuwing in het zoekresultaat, klachten van klanten of een blokkade door de hoster wegens spamverzending. Op de server verschijnen onbekende PHP-bestanden, nieuwe beheerdersaccounts, gewijzigde .htaccess-bestanden of onverklaarbare cronjobs.
Na PHP2Shell komt er nog een zorg bij: via CVE-2026-109618 en CVE-2026-109619 kunnen aanvallers zonder inloggen code uitvoeren. Er zijn geen gepubliceerde, bevestigde Indicators of Compromise; detectie berust op gedragsanalyse. Hoe webshells er typisch uitzien en waar ze staan, beschrijft Webshells herkennen en verwijderen.
Malware van de website verwijderen: waarom grondig belangrijker is dan snel
Aanvallers plaatsen zelden slechts één bestand. Gebruikelijk zijn meerdere achterdeuren op verschillende plaatsen: in uploadmappen, in plugins of thema's, in must-use-plugins, in de database, in cronjobs of in extra gebruikersaccounts. Wordt alleen het meest opvallende bestand gewist, dan komt de schadelijke code terug.
Tegelijk is de besmette toestand een bewijsmiddel. Wie te snel reinigt, verliest de mogelijkheid vast te stellen of klantgegevens zijn getroffen. Daarom maken wij vóór elke wijziging een kopie. Dat kost weinig tijd en houdt alle wegen voor u open, ook een latere melding aan de toezichthouder of verzekeraar.
Een PHP-update of CMS-update verwijdert geen schadelijke software die al op de server staat. En een gereinigde website wordt opnieuw besmet zolang de toegangspoort openstaat.
Waar schadelijke code zich typisch verstopt
De volgende plaatsen controleren we bij elke reiniging, omdat ze in de praktijk steeds weer getroffen zijn:
| Plaats | Typische bevinding |
|---|---|
| Uploadmappen | PHP-bestanden met onschuldig ogende namen of vermomd als afbeelding |
| Plugins, thema's, modules | extra bestanden of gewijzigde originele bestanden |
| Configuratie | ingebrachte regels in .htaccess, .user.ini of startbestanden |
| Database | vreemde beheerdersaccounts, scripts in inhoud of opties |
| Systeem | cronjobs, extra SSH-sleutels, processen zonder herkenbaar doel |
| Caches en tijdelijke mappen | kopieën van schadelijke code die na het wissen weer opduiken |
Belangrijk is het verband: een afzonderlijke vondst verklaart zelden het hele incident. Pas het totaalbeeld laat zien hoe de aanvaller te werk is gegaan en of hij toegangsgegevens heeft meegenomen.
Hoe helpt PHP SOS concreet?
- Veiligstellen: wij maken een kopie van bestanden, database en logs in de besmette toestand. Die blijft behouden voor een latere analyse.
- Zoeken: wij vergelijken programmabestanden met de originelen van de fabrikant, controleren uploadmappen op uitvoerbare code en doorzoeken database, cronjobs, gebruikersaccounts en serverconfiguratie. Voor WordPress-omgevingen gaan we te werk zoals beschreven onder Achterdeuren in WordPress vinden.
- Reinigen: kern, extensies en thema's installeren we opnieuw uit betrouwbare bronnen, in plaats van verdachte bestanden een voor een te lappen. Eigen inhoud en uploads controleren we afzonderlijk en we nemen alleen over wat onbedenkelijk is.
- Oorzaak sluiten: wij patchen PHP en de toepassing, verwijderen vreemde accounts en vervangen alle toegangsgegevens en sleutels die de aanvaller gezien kan hebben.
- Nacontrole: wij houden de website na de reiniging in de gaten op nieuwe wijzigingen en helpen u een Google-waarschuwing via de Search Console te laten controleren. Meer daarover onder Google-waarschuwing verwijderen.
Voor beheerders een ongevaarlijke eerste blik op onlangs gewijzigde PHP-bestanden:
# PHP-bestanden in de webmap die in de afgelopen 10 dagen zijn gewijzigd
find /var/www -type f -name "*.php" -mtime -10 -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort
Het resultaat is een aanwijzing, geen bewijs: aanvallers kunnen tijdstempels wijzigen.
Wat u krijgt en wat wij nodig hebben
U ontvangt een rapport met de gevonden schadelijke onderdelen en hun vindplaats, de maatregelen voor de reiniging, de lijst van vervangen toegangsgegevens en de waarschijnlijke toegangspoort. Daarbij maken wij duidelijk onderscheid tussen wat aangetoond, wat waarschijnlijk en wat onbekend is.
Wij hebben van u nodig:
- toegang tot server of hostingpaneel, CMS-backend en database
- een aanspreekpunt dat wachtwoordwijzigingen en uitschakelingen kan goedkeuren
- informatie over bureau, ontwikkelaar of hoster en over eigen aanpassingen aan het systeem
- bestaande back-ups met datum, zodat we kunnen inschatten welke stand schoon kan zijn
- toegang tot de Google Search Console, als er een waarschuwing wordt getoond
Wat we niet beloven
Wij beloven niet dat elke achterdeur op elk systeem zeker wordt gevonden als logs ontbreken of de besmetting lang geleden is. Bij een onduidelijke situatie adviseren we de heropbouw op een verse server, waarnaar alleen gecontroleerde inhoud wordt overgebracht. Dat is bewerkelijker, maar vaak de betrouwbaardere weg. We voorspellen ook niet wanneer Google of andere diensten een waarschuwing verwijderen; dat beslissen die aanbieders.
Moet bewijskrachtig worden vastgesteld wat er precies is gebeurd en welke gegevens zijn getroffen, dan halen we de IT-forensica met gespecialiseerde partners erbij. Bij een acute, nog lopende aanval begint het werk met de noodhulp bij een gehackte website.
Veelgestelde vragen
Volstaat een malwarescanner-plugin om mijn website te reinigen?
Een scanner vindt bekende patronen, maar niet elke achterdeur. Webshells zijn vaak versluierd, staan in afbeeldingen, caches of de database, of zijn verankerd als cronjob. Een scanner is een hulpmiddel, geen volledige reiniging.
Kan ik gewoon een oude back-up terugzetten?
Alleen als zeker is dat de back-up van vóór de inbraak stamt en de toegangspoort daarna wordt gesloten. Anders is de website even schoon en wordt hij op dezelfde manier opnieuw besmet.
Waarom duikt de malware na het verwijderen steeds weer op?
Meestal is er een tweede achterdeur, een cronjob, een gemanipuleerd beheerdersaccount, of het lek staat nog open. Pas als alle persistentiemechanismen zijn gevonden en de oorzaak is weggenomen, blijft de reiniging bestendig.
Verwijdert een PHP-update bestaande malware?
Nee. Een patch dicht het lek, maar verwijdert geen reeds binnengebrachte schadelijke software. Het zijn gescheiden werkstappen.