Hoe onderzoek naar een trage website uitmondde in forensisch onderzoek op een gehackte wordpress website en het ontwikkelen van nieuwe beveiligingstooling voor onze klanten.
Soms eindigt een technisch vraagstuk heel anders dan je verwacht.
Omdat we steeds vaker toename zien van geautomatiseerd verkeer op onze klanten websites zijn we afgelopen twee weken bezig geweest de bescherming en filtering te verbeteren op onze WordPress-infrastructuur. De verkeerstoename is niet alleen afkomstig van traditionele bots en hackers maar tegenwoordig ook met name van AI-bots die grote hoeveelheden pagina’s proberen op te halen.
Deze maatregelen waren nodig omdat dergelijke bots ongelimiteerd pagina’s ophalen. Hierdoor staan onze servers dermate onder druk te staan dat dit soms leidde tot Denial of service problemen. Kortom, bezoekers kunnen een website niet meer bereiken, omdat deze te druk is met het serveren van pagina’s aan AI-bots.
Omdat de bescherming en filtering invloed heeft op het algehele gedrag van de infrastructuur, moet je dit over een bepaalde periode nauw in de gaten houden. De maatregels zijn onder andere dat afwijkend verkeer eerder tegengehouden wordt en dat bots niet onbeperkt pagina’s mogen opvragen, maar slechts een maximaal aantal keer per seconde.
Dit leek allemaal goed te werken, tot een klant aangaf dat zijn website soms toch traag aanvoelde. Op zichzelf niets bijzonders, dit kan diversen oorzaken hebben en dan ga je individueel meten wat het kan zijn. Dus ik begon met een website specifiek performance onderzoek. Voor individuele websites kan je op server niveau voldoende inregelen, dus daar begon de dag mee.
Omdat ik een vreemd proces zag, vond ik dit verdacht en ben ik hier ingedoken. Er bleken kwaadaardige componenten geplaatst te zijn, een door hackers veel gebruikte zogenaamde backdoor. Vaak zie je niet dat dit gebeurd, omdat dit verborgen zit en op een later moment met kwaadaardige bedoelingen ingezet kan worden.
Dat proces hoort daar niet te draaien
Op het moment dat ik het vreemde proces zag, was ik van nature nieuwsgierig en ben ik pas gerust gesteld als ik precies weet wat er aan de hand is. Immers, de klanten van CAP5 weten dat er goed voor hun online services gezorgd wordt, en dat betekend dat vakkennis onontbeerlijk is, maar hier komt ook gedegen zoekwerk aan te pas komt.
De eerste gedachte over de performance was: Waren onze eerdere beveiligingsmaatregelen misschien te streng ingesteld? Moesten de server processen voor deze specieke website geoptimaliseerd worden?
Dat bleek allemaal niet het probleem te zijn. Maar dit ene proces met vreemde naam, van een specifieke website, hield continu één processor volledig bezet.
Dat is ongebruikelijk. Op onze systemen wordt belasting normaal gesproken verdeeld. Worden er meer processen voor individuele websites opgestart al naar gelang de hoeveelheid verkeer dat op een website aankomt.
Eén proces dat zich op een afwijkende manier gedraagt is voor mij aldus reden om verder te kijken. En soms is dat letterlijk het verschil tussen alleen een performanceprobleem oplossen en ontdekken dat er iets heel anders aan de hand is.
Het was dermate verdacht dat ik voor de betreffende website, op basis van bestaande gereedschappen direct een aantal scans kon starten. Die eerste scans bevestigden het vermoeden. Grote kans dat de website geïnfecteerd is.
WordPress websites staan soms bol van de plugins, met elk zijn eigen implementatie methode en bestanden. Dit staat allemaal op een vaste plek, namelijk een folder waar plugin, thema en content bestanden geplaatst worden.
Het probleem zat echter ook in de standaard WordPress bestanden. Dat is ook wat de scan aangaf. Tussen de normale WordPress bestanden stonden bestanden met namen die nét genoeg leken op echte systeembestanden om niet direct op te vallen. Maar deze hoorden daar niet thuis. Toen ik de inhoud van deze bestanden onderzocht, was het duidelijk: er draaide kwaadaardige code op de website.
Vanaf dat moment heb je geen performance probleem meer, maar een beveiligingsincident.
Een hack opruimen is niet hetzelfde als een paar bestanden verwijderen
Het is niet de eerste keer dat we een website inbraak 🇺🇸 meemaken dus vanuit ervaring weet je ruwweg wat er moet gebeuren. Daarbij gezegd hebbend dat geen enkele inbraak lijkt op de volgende, en je nooit weet wat je aan zal treffen.
Het allereerste wat je op zo’n moment doet is de website direct isoleren voor publiek, zodat er geen tussentijdse invloed van buitenaf mogelijk is.
Een waarschijnlijke ingang bleek een verouderde plugin met bekende kwetsbaarheden. Wij voeren updates dagelijks uit, en alhoewel dit van diverse factoren afhankelijk is, slipt er wel eens eentje tussen door. En als je website onderhavig is aan een recent gepubliceerde zwakheid, is het snel gebeurd.
Nu zul je denken, maar hoe weten hackers tussen die miljoenen website nu zo snel welke vatbaar is voor inbraak? Daar gebruiken hackers simpelweg google voor. Met hele geraffineerde zoek opdrachten, zijn deze via de zoekmachine te vinden. Dit is op zichzelf niet bijzonder. WordPress is enorm populair en daardoor ook een interessant doelwit. Zodra ergens een bekende kwetsbaarheid ontstaat, wordt daar op grote schaal automatisch naar gezocht door hackers.
Waarom het bestand steeds terugkwam
Het interessantste kwam erna pas. Nadat we de verdachte bestanden verwijderden, kwamen ze even later weer terug. Zelfs nadat we het verdachte proces verwijderd hadden. Daarmee werd duidelijk dat we niet naar één los stukje malware keken. Er zat ergens anders nog een mechanisme dat de besmetting opnieuw opbouwde.
WordPress gebruikt een scheduler mechanisme om intern huishoudelijk werk te verrichten op een website. De kwaadaardige software had een taak in de scheduler aangemaakt die om de zoveel tijd controleert of de backdoor bestanden nog aanwezig waren. Zo niet, dan werden deze opnieuw aangemaakt. Middels het bestand kan het proces weer opgestart worden. Het proces maakt vervolgens de scheduler taak weer aan als deze ontbreekt.
Aldus houdt alles zich samen in stand. Dat betekend dat iets waarvan je denk dat het nu schoon is, de volgende dag weer geactiveerd wordt, en de infectie aanwezig blijft.
Wij gebruiken al geruime tijd een beveiligingsplugin. Dit helpt maar is niet zaligmakend, en had het probleem dan ook niet gedetecteerd. De reden hiervan is dat een beveiligingsplugin kijkt naar de WordPress situate vanuit WordPress zelf. Het kwaadaardige proces draaide echter daarbuiten.
Dat maakt duidelijk waarom het bij een serieuze besmetting niet voldoende is om alleen te verwijderen wat zichtbaar verdacht lijkt. Je moet begrijpen hoe de infectie werkt.
Van schoonmaken naar gericht forensisch onderzoek
Dit is het punt waarop zo’n onderzoek steeds meer forensisch wordt. Niet in de ‘CSI van televisie’-betekenis, maar heel praktisch:
Wat hoort er niet thuis? Wat wordt er opgestart? Waar vandaan? En wat zorgt ervoor dat het terugkomt?
Daarbij kijk je niet alleen naar bestanden. Je kijkt naar processen, configuraties, geplande taken, plugins, thema’s en andere plekken waar code zich kan verstoppen.
Een veel gezien voorbeeld is een bestand met kwaadaardige php code erin hernoemen met een .jpeg extensie. Als je stopt bij de gedachte ‘dat is een afbeelding’ ben je het euvel al voorbij en blijft het bestaan. Dat betekend dat je ieder bestand op de website, en dat zijn er duizenden, een voor een inhoudelijk moet nalopen om te beoordelen of wat er in zit niet kwaadaardig is. Hier vind je meer achtergrond informatie over dergelijk onderzoek.
Tijdens het onderzoek bleek onze bestaande tooling daar niet voldoende voor. De standaardscanners vonden delen van het probleem, maar produceerden tegelijkertijd veel ruis. En als je duizenden bestanden moet beoordelen, is meer informatie niet altijd automatisch betere informatie.
Je wilt de afwijkingen zien die ertoe doen. Hier is een zogenaamde ‘deep-scan’ van programmeercode en bestandsinhoud nodig. Software code kan signaturen bevatten, ook wel finger prints genoemd, die verdacht zijn. Dus naast het controleren of een afbeelding ook daadwerkelijk afbeelding is, moet je per bestand, voor alle plugins en themas controleren. Ook moet je de WordPress bestanden zelf op daadwerkelijke inhoud en code scannen voor afwijkende signaturen.
Daar dit niet zonder meer specifiek voor WordPress het geval is, maar wij ook software ontwikkelen en daarbij ook security scans doen, hebben we hier de kennis voor in huis en hebben we tijdens het onderzoek een maatwerk scan methodiek gebouwd.
Wat begon als een hulpmiddel voor deze ene website, werd uiteindelijk tooling waarmee we heel gericht alle WordPress omgevingen kunnen controleren. Immers, als je bestaande gereedschap het bij de eerste website niet ziet, hoe weet je dan zeker dat er bij de andere websites geen probleem verborgen zitten.
Eén incident werd een controle van alle websites
Dit vond ik eigenlijk een van de belangrijkere momenten van het hele incident. Met de steeds slimmere manieren om inbraak te verbergen, en daar hadden we dit keer weer een nieuwe van gevonden, wilde ik ook weten hoe het met de andere websites zit. We beheren immers niet één website maar een hele vloot.
Het resultaat, we hebben we de tooling uitgebreid en gestandaardiseerd zodat we een complete WordPress installatie live kunnen controleren op afwijkingen, ongebruikelijke code in plugins en thema’s en verdachte scheduler taken.
Daarmee konden we vervolgens heel snel alle andere klantomgevingen controleren.
Dat is namelijk de kracht van gedeelde kennis en onze managed dienstverlening. Een probleem bij één klant leidt tot betere bescherming voor andere klanten.
Hoe voorkom je een gehackte wordpress website?
Het probleem met reguliere hosting is dat je dit simpelweg niet ziet, sterker nog, er op deze manier niet eens bij kan, als je al weet waar je naar moet zoeken. Het probleem is dat je niet zomaar bij de WordPress Scheduler kan of deep scans uit kan voeren in code bestanden, kortom voor de meeste mensen een onmogelijke opgave.
Wat je minimaal moet doen:
- zorg ten alle tijden dat alles up to date is, of je het nu zelf doet of uitbesteed.
- Installeer een beveiliging plugin als Wordfence. Zo zie je heel snel of je met risicovolle plugins werkt.
- Zorg dat je verouderde gebruikersaccounts en ongebruikte plugins verwijderd.
- Zorg dat je een specialist achter de hand hebt, die weet waar je naar moet kijken, en beter nog, hoe dit op te lossen is.
100% veilig bestaat niet
Belangrijk om je te realiseren is dat 100% risico vrij simpelweg niet bestaat. Dus wees alert als iemand die garantie geeft. Dat kunnen wij ook niet.
Een website staat nu eenmaal op het internet. Software verandert, nieuwe kwetsbaarheden worden ontdekt en aanvallers worden steeds slimmer. Met AI wordt het automatisch zoeken naar zwakheden en inbreken steeds eenvoudiger, en het gebeurd steeds sneller.
De relevante vraag is daarom niet: Kun je iedere aanval voorkomen? Maar: Wat kan je doen om je risico’s te minimaliseren? En vooral, wat is je plan als het toch fout gaat?
Daar zit uiteindelijk het grootste aspect van security management: Preventie. Detectie en Response.
Kortom, ‘voorkomen is beter dan genezen’. Dat geldt hier helemaal omdat herstel werk en de daarmee gepaard gaande kosten aanzienlijk hoger zijn dan regulier onderhoud.
Waar het mee begon
Dit incident begon met één klant die zei: “Mijn website voelt soms traag.”
We hadden niet alleen direct een website opgeschoond en beveiligd, maar anderhalve week later hadden we ook onze scan- en beveiligingstooling verbeterd en de overige klant omgevingen opnieuw gecontroleerd.
Precies dát is voor mij het verschil tussen ergens een website hosten en een website daadwerkelijk beheren.
Je hoeft als klant niet te weten hoe processen, schedulers, PHP-code of malware werken. Je moet erop kunnen vertrouwen dat iemand anders dat wel weet. En dat diegene er staat als het erop aankomt.
