Je website werkt prima. Dat bewijst niets.

Een klant belde omdat een paar subdomeinen eruit lagen. De hoofdsite deed het prima. Dat leek het kleinste probleem van de week.

Het was precies andersom.

Wat we dachten dat het was

Zeven subdomeinen gaven een lege HTTP 500. DNS was in orde, de certificaten waren in orde, Apache antwoordde op alles. Het foutenlogboek zei duizenden keren hetzelfde:

PHP Parse error: syntax error, unexpected token "{" in .../index.php on line 2

Regel 2 was geen code van ons. Het was een webshell — een achterdeur, verstopt in een bestand dat de aanvaller naast de echte pagina had gezet.

En hier wordt het interessant. Die achterdeur was geschreven met $variabele{38}, een schrijfwijze die in PHP 7.4 verouderd werd verklaard en in PHP 8.0 volledig is verwijderd. De hoster had PHP geüpgraded. De malware kon niet meer draaien — en sleepte de hele pagina mee in de val.

De subdomeinen waren niet stuk. De malware erin was stuk.

De site die het wél deed

Terwijl wij naar de zeven kapotte sites keken, stond de hoofdsite netjes op 200. Niemand maakte zich er zorgen over.

Die had een andere variant: eentje die PHP 8 wél begrijpt. Geen foutmelding, geen witte pagina, niets. Hij deed het gewoon — en dus draaide hij nog.

De enige site die werkte, was de enige site waarvan de achterdeur nog leefde.

Dat is de hele les van deze week werk. Een werkende website bewijst niets. Onze eerste ingeving was om te kijken naar wat kapot was en te vertrouwen wat het deed. Die ingeving had ons bijna de enige actieve achterdeur laten missen.

Waarom het terugkwam

We hebben opgeruimd. Acht uur later stond het bestand er weer.

De verklaring lag in twee regels die aan een kernbestand van WordPress waren toegevoegd, zes seconden vóór de rest:

include "/home/.../backup/app/security/assets/css/16869";
include "/home/.../modules/cache/live-traffic/138527";

Bestanden zonder extensie, in een map die eruitzag als de cache van een beveiligingsplugin. Zoek naar *.php en je vindt ze nooit. Alleen het verschil met de originele WordPress-release verraadt ze — twee regels in een bestand van 26 kilobyte.

Er stonden er meer. Ruim elfduizend door de aanvaller geplaatste .htaccess-bestanden, die zijn eigen shells toestonden. Een scanner van de hoster meldde ondertussen "geen malware gevonden", terwijl er zes actief waren — en één achterdeur droeg de naam en de copyrightregel van diezelfde scanner in de kop. Wie een bestandslijst doorleest, ziet de naam van zijn eigen beveiligingssoftware en kijkt verder.

Wat u hieruit kunt meenemen

Een 200 is geen gezondheidsverklaring. Uw site kan er maandenlang perfect uitzien terwijl er iemand meekijkt. De meeste malware wil juist níét opvallen — opvallen is hoe het opgeruimd wordt.

Repareer geen foutmelding die u niet begrijpt. Was hier iemand langsgekomen die de "syntaxfout" netjes had opgelost, dan hadden zeven werkende achterdeuren teruggestaan. De crash was het enige wat ze onschadelijk hield.

Een groen dashboard is geen bewijs. Het is een leverancier die u vertelt dat hij niets gevonden heeft. Dat is iets anders dan dat er niets is.

Zet uw site in versiebeheer. Op dit account stond geen enkele site in Git. Er was dus geen bekende goede versie om mee te vergelijken — elk bestand moest op zijn inhoud beoordeeld worden. Dat, meer dan de malware zelf, maakte dit duur.

---

Wilt u weten wat er op uw eigen site staat? Onze Website Health Scan kijkt in drie werkdagen naar snelheid, technische SEO, beveiliging en cookies, en levert één geschreven lijst op: wat er stuk is, wat het u kost, en wat u in welke volgorde oplost. Vaste prijs, geen abonnement.