De belangrijkste les uit deze WordPress-hack: een geldig adminaccount is al bijna productie-toegang. Als zo’n account daarna een file-manager plugin kan gebruiken, kan een aanvaller bestanden plaatsen, spam injecteren en nieuwe achterdeuren maken zonder nog veel technische magie nodig te hebben.
Voor lezers die veiligheidsincidenten praktisch willen begrijpen is vooral dit relevant: een websitehack kun je reconstrueren als een tijdlijn. De les is praktisch: wat gebeurde er in grote lijnen, welke signalen wil je terugvinden, en welke maatregelen leveren meteen minder risico op?
Wat er in de case gebeurde
De zichtbare schade leek eerst simpel: een site toonde vreemde taal, gokachtige content en pagina’s die niet bij het merk hoorden. Dat is de buitenkant. De technische keten erachter was interessanter. Er was een geslaagde WordPress-login met adminrechten. Kort daarna werd een application password aangemaakt, de beheeromgeving bezocht en een file-manager gebruikt om PHP-bestanden in de contentomgeving te schrijven.
Vanaf dat moment hoefde de aanvaller niet steeds netjes via WordPress in te loggen. Een eigen PHP-endpoint kon posts maken, homepage-links plaatsen en spamcontent aansturen. Daarnaast werd persistence gezocht via een nep-plugin, aangepaste theme- of pluginbestanden en een verdacht extra adminaccount. Dat is precies waarom alleen de zichtbare spam verwijderen te weinig is.
Waarom dit voor deze site relevant is
Bij een digitale inbraak is de zichtbare schade zelden het begin. De eerste vraag is: wanneer kwam iemand binnen, met welk account, welke actie volgde direct daarna en welk bestand gaf de aanvaller blijvende toegang? Die tijdlijn maakt het verschil tussen schoonmaken en echt afsluiten.
De fout die vaak wordt gemaakt: men noemt het ‘een malwarebestand’ en verwijdert dat bestand. Daarmee is de oorzaak nog niet weg. Als dezelfde admin nog bestaat, dezelfde application password nog werkt of dezelfde file-manager actief blijft, kan de aanvaller dezelfde route opnieuw proberen.
De aanvalsketen in gewone taal
- Iemand krijgt geldige WordPress-admin toegang.
- Die admin maakt of gebruikt extra toegang, bijvoorbeeld een application password.
- Een file-manager of vergelijkbare beheerplugin geeft schrijfrechten op bestanden.
- Er wordt een PHP-bestand geplaatst dat als eigen endpoint werkt.
- Daarna volgen spamlinks, cloaking, nepplugins of extra accounts.
Die volgorde is belangrijk. Wie alleen bij stap vier begint, mist de vraag waarom stap vier mogelijk was. Wie bij stap één begint, komt uit bij beter toegangsbeheer: minder admins, MFA, logging, tijdelijke rechten en geen beheerplugins die permanent actief blijven.
Checklist voor dezelfde week
Werk van login naar bestand, niet andersom. Verzamel logs, maak een back-up voor bewijs, zet verdachte accounts uit en blokkeer de paden waar nieuwe PHP-bestanden nooit uitgevoerd hoeven te worden.
- Controleer alle administrator-accounts en verwijder wat niet aantoonbaar nodig is.
- Verwijder WordPress application passwords die geen duidelijke eigenaar en reden hebben.
- Haal file-manager plugins van productie af, of activeer ze alleen tijdelijk onder toezicht.
- Blokkeer PHP-uitvoering in uploads en direct in de root van
wp-content. - Controleer actieve plugins, mu-plugins, themebestanden,
index.phpen losse PHP-bestanden. - Bekijk de site als gewone bezoeker en als zoekmachinebot, zodat cloaking sneller opvalt.
Wat je niet moet overschatten
Niet elke WordPress-hack betekent dat de hele server is overgenomen. Dat onderscheid is belangrijk. Als het bewijs wijst naar WordPress-admin, plugins en bestanden binnen de site, begin je daar. Je roteert salts en sleutels, herinstalleert core waar nodig, zet verdachte plugins uit en bewaart bewijs. Pas als logs of systeemsignalen verder wijzen, trek je het onderzoek naar serverniveau.
Het omgekeerde is ook waar: noem het niet ‘alleen contentspam’ als er backdoors en persistence zijn gevonden. SEO-spam is vaak het verdienmodel, niet de volledige techniek. De echte les is dat beheerrechten, logging en file execution net zo belangrijk zijn als de malwarehandtekening zelf.
Verder lezen
Wil je dit breder plaatsen, lees dan ook 112 en veiligheid en veiligheidsartikelen. Die stukken sluiten inhoudelijk aan op deze checklist.