Een adviesbureau met veertien medewerkers meldde zich omdat er nieuwe pagina’s op hun website stonden die niemand had gemaakt. Geen spam in zoekresultaten, geen waarschuwingsscherm, gewoon acht pagina’s in een vreemde taal, netjes gepubliceerd via het beheerscherm. Toen bleek dat een oud account was gehackt: dat van een stagiair die begin 2021 was vertrokken.
Dit is een geanonimiseerd verslag van dat traject. Het staat hier omdat het het saaiste soort inbraak is dat er bestaat, en tegelijk de meest voorkomende. Er was geen kwetsbaarheid, geen verouderde plugin en geen slimme aanval. Er was een deur die nooit op slot was gedaan.
Hoe het werd ontdekt
De ontdekking kwam van een medewerker die in het overzicht van pagina’s iets zag staan wat er niet hoorde. Dat is laat, maar nog altijd eerder dan gemiddeld. Uit de logboeken bleek dat de eerste succesvolle inlog met dat account elf dagen eerder had plaatsgevonden.
In die elf dagen was er weinig gebeurd. Twee dagen niets, daarna twee pagina’s, en pas in het laatste weekend nog eens zes. Dat patroon is typisch: een geautomatiseerd systeem test eerst of het account werkt en of niemand ingrijpt, en pas daarna wordt de site in gebruik genomen.
Het account had beheerdersrechten. Dat was destijds ingesteld omdat de stagiair een keer een plugin moest installeren, en daarna nooit teruggedraaid. Bij vertrek was zijn mailaccount netjes opgeheven en zijn laptop ingeleverd, maar aan de website had niemand gedacht.
Hoe men binnenkwam
Het wachtwoord van dat account bleek voor te komen in een bekend datalek van een dienst die niets met het bureau te maken had. De stagiair had bij het aanmaken hetzelfde wachtwoord gebruikt dat hij ook privé gebruikte, iets wat toen niemand controleerde.
Vervolgens is het simpel. Er wordt geautomatiseerd geprobeerd of combinaties uit lekken werken op willekeurige WordPress-inlogschermen. Er was geen limiet op inlogpogingen ingesteld en geen tweestapsverificatie, dus de eerste juiste poging was meteen raak. Hoe die aanvalsvorm precies verloopt, staat bij het uitproberen van gelekte inloggegevens op bestaande accounts.
Opvallend detail uit de logboeken: er waren in de weken daarvoor duizenden mislukte pogingen op andere gebruikersnamen geweest. Niemand keek daarnaar, want er was geen melding en geen logboek dat werd gelezen.
Wat er is aangetroffen
Naast de acht pagina’s stonden er twee dingen die er niet hoorden. Een tweede beheerdersaccount met een onopvallende naam, aangemaakt op dag drie. En een klein bestand in de uploadmap dat als achterdeur diende, zodat toegang behouden bleef als het oorspronkelijke account zou worden geblokkeerd.
Dat tweede account is het onderdeel dat mensen het vaakst missen. Wordt alleen het gehackte account verwijderd, dan verandert er niets, want er ligt allang een reservesleutel klaar.
De acht pagina’s verwezen naar externe verkoopsites. Ze stonden niet in het menu maar wel in de sitemap, en drie ervan waren al door Google opgepikt. Dat was uiteindelijk het onderdeel dat het langst nawerkte.
Het herstel
- Site in onderhoudsmodus, kopie en logboeken veiliggesteld.
- Beide kwaadaardige accounts verwijderd en de gebruikerslijst volledig doorgenomen: van de negentien accounts bleken er zes van mensen die er niet meer werkten.
- De acht pagina’s verwijderd en voorzien van een foutcode, zodat Google ze zou laten vallen in plaats van door te sturen.
- De achterdeur in de uploadmap verwijderd en het uitvoeren van PHP daar geblokkeerd.
- Wachtwoorden van alle overgebleven accounts vervangen, beveiligingssleutels vernieuwd en sessies verbroken.
- Tweestapsverificatie verplicht gesteld voor de vier accounts die beheerdersrechten hielden; de overige gebruikers kregen een lagere rol.
- Een limiet op inlogpogingen ingesteld en een logboek met meldingen bij nieuwe beheerders.
Het technische deel besloeg ruim een werkdag. Het opschonen in Google duurde bijna zes weken, omdat de drie geïndexeerde pagina’s pas na herhaalde verzoeken uit de resultaten verdwenen.
De kosten, eerlijk opgeteld
Het herstel zelf was overzichtelijk: één dag werk. Wat er verder bij kwam, was minder zichtbaar maar telde op. Een halve dag intern overleg. Een gesprek met hun jurist over de vraag of er een meldplicht speelde, wat uiteindelijk niet zo bleek omdat er geen aanwijzingen waren dat gegevens waren ingezien. En zes weken waarin er bij het zoeken op hun bedrijfsnaam iets tussen stond wat er niet hoorde.
Daar staat tegenover wat het voorkomen had gekost: een kwartier per vertrekkende medewerker om het account op te heffen. Dat is het hele verhaal.
Wat dit geval bruikbaar maakt
Drie punten die breder gelden en die weinig met techniek te maken hebben.
Toegang tot de website hoort in uw uitdienstprocedure. Laptop, mailaccount, telefoon en sleutels staan er meestal wel op; de website vrijwel nooit. Wat er verder bij zo’n vertrek hoort, staat bij het intrekken van toegang na een vertrek.
Beheerdersrechten zijn geen standaardinstelling. In dit bureau hadden negentien mensen ooit toegang gekregen en vrijwel iedereen als beheerder, omdat het bij het aanmaken de makkelijkste keuze was. Vier daarvan hadden het echt nodig.
Zonder signalering merkt u niets. Er waren weken van mislukte pogingen zichtbaar geweest als iemand had gekeken, en een melding bij een nieuw beheerdersaccount had de inbraak op dag drie zichtbaar gemaakt in plaats van op dag elf.
Sinds dit traject loopt bij dit bureau twee keer per jaar een controle van de gebruikerslijst mee in het beheer, wat een vast onderdeel is van het beschermen en bewaken van hun WordPress-omgeving. Die controle duurt tien minuten en is het goedkoopste onderdeel van het hele pakket.
Concrete volgende stap: open vandaag de gebruikerslijst van uw website en tel hoeveel accounts er beheerdersrechten hebben. Staat daar iemand tussen die niet meer bij u werkt, dan heeft u nu de belangrijkste taak van deze week te pakken.
