Een praktijkmanager van een tandartspraktijk in Noord-Brabant belde ons op een woensdag met een verhaal dat wij vaker horen. Een patiënt had gezocht op de naam van de praktijk en kreeg tussen de normale resultaten door Japanse teksten te zien. Titels met Japanse tekens, adressen met de eigen domeinnaam erin, en beschrijvingen over merkhorloges en tassen. De website zelf zag er gewoon uit.
Wanneer een website gehackt is, verwacht men een defecte site of een schermvullende boodschap. Deze variant werkt anders: hij houdt uw site juist in de lucht, want een werkende site levert de aanvaller meer op. Deze case beschrijft wat er aan de hand was, hoe het onderzoek verliep en hoeveel tijd het volledige herstel kostte, inclusief het deel dat u niet kunt versnellen.
De situatie
De praktijk had een overzichtelijke site: informatie over behandelingen, een team-pagina, openingstijden en een afspraakformulier. Geen webshop, geen inloggedeelte voor patiënten, geen medische dossiers online. Dat was een opluchting, want daarmee was de kans op een datalek met gezondheidsgegevens klein. Wel stonden er honderden formulierinzendingen in de database met namen, telefoonnummers en soms een omschrijving van een klacht.
De site was vier jaar eerder gebouwd. Updates gebeurden onregelmatig: de praktijkmanager deed ze als er een melding in beeld kwam en er tijd was. Er was geen back-upsysteem buiten de standaardvoorziening van de hostingpartij, die zeven dagen terugging.
Wat de praktijk zelf al had gecontroleerd: de homepage, een paar onderliggende pagina’s, en of ze konden inloggen. Alles leek normaal. Dat is logisch, want de spampagina’s bestaan niet als gewone pagina’s in het beheer. Ze worden op het moment van opvragen gegenereerd, en alleen wanneer de bezoeker eruitziet als een zoekmachine.
Het onderzoek
Wij begonnen met vaststellen hoe groot het probleem was. Een zoekopdracht met site: gevolgd door hun domeinnaam liet ruim vierduizend geïndexeerde adressen zien, waar er ongeveer veertig hoorden te staan. In Search Console, dat gelukkig was ingesteld, stond een piek in het aantal geïndexeerde pagina’s die exact zes weken eerder begon.
Daarna zochten wij de bron. Drie dingen kwamen samen:
- Een gewijzigd kernbestand. Eén van de standaardbestanden van WordPress was aangepast met code die controleerde of de bezoeker een zoekmachine was en zo ja, andere inhoud terugstuurde.
- Een bestand in de uploadsmap. Verstopt tussen de foto’s van 2022 stond een bestand dat de spampagina’s samenstelde uit gegevens die het van een externe server ophaalde.
- Een extra beheerdersaccount. Aangemaakt kort na de eerste besmetting, met een e-mailadres bij een gratis dienst.
De ingang bleek een contactformulierplugin met een lek dat vier maanden eerder was gedicht in een update die nooit was uitgevoerd. Hoe die specifieke spamvariant werkt en waarom hij zo lang onopgemerkt blijft, hebben wij algemeen beschreven in het artikel over de Japanse zoekresultaten-hack.
De aanpak
Het herstel liep over twee dagen, in deze volgorde.
- Volledige kopie gemaakt van bestanden en database, om te kunnen onderzoeken zonder iets kwijt te raken.
- Kernbestanden vervangen door de originele versie van WordPress, en alle plugins opnieuw geïnstalleerd vanaf de bron in plaats van bijgewerkt.
- De uploadsmap doorzocht op uitvoerbare bestanden en uitvoering van PHP daar geblokkeerd via de serverconfiguratie.
- Het onbekende account verwijderd en alle wachtwoorden vernieuwd, inclusief die van de database, FTP en het hostingpaneel.
- De beveiligingssleutels vervangen, zodat elke openstaande sessie verviel.
- De kwetsbare plugin bijgewerkt en twee plugins verwijderd die al meer dan een jaar geen onderhoud kregen.
- Een firewall geplaatst en het aantal inlogpogingen begrensd.
- Google geïnformeerd: de spampagina’s aangeboden voor verwijdering en een herbeoordeling aangevraagd met een beschrijving van wat er was gebeurd.
- Bestandscontrole ingericht, zodat een wijziging aan een kernbestand voortaan een melding oplevert.
Daarnaast is de formulierhistorie opgeschoond. Inzendingen ouder dan een jaar zijn verwijderd en er is een automatische bewaartermijn ingesteld. Dat was strikt genomen geen onderdeel van de hack, maar wel de grootste hoeveelheid persoonsgegevens die op die site stond, en die stond er zonder reden.
Het resultaat
De site was na twee dagen technisch schoon. De zoekresultaten waren dat niet. Google verwijdert vierduizend adressen niet in een middag; het aantal zakte in ongeveer drie weken naar normaal. In die periode kwamen er nog steeds patiënten die de vreemde resultaten hadden gezien.
Het bezoek via zoekmachines lag tijdens de besmetting ruwweg een derde lager dan daarvoor, en herstelde in de zes weken erna grotendeels. Volledige garanties zijn hier niet te geven, en het is eerlijk om te zeggen dat wij niet met zekerheid kunnen stellen dat elke positie is teruggekeerd.
Er is een interne afweging gemaakt over het melden van een datalek. Omdat niet uit te sluiten viel dat de formulierinzendingen zijn ingezien, is de melding gedaan. De praktijk heeft daarnaast een korte brief opgesteld voor patiënten die ernaar vroegen. Dat laatste bleek achteraf het meest gewaardeerd: open zijn kostte een uur en voorkwam wekenlang gedoe.
Wat de praktijk hieruit meenam
Controleer af en toe hoe uw site in Google staat. Een zoekopdracht met site:uwdomein.nl duurt tien seconden en had dit zes weken eerder aan het licht gebracht. Zet Search Console aan; die had bij de indexeringspiek een melding kunnen geven.
Wat u verder in zo’n zoekopdracht kunt herkennen, en welke andere signalen wijzen op een besmetting die u zelf niet ziet, staat in ons overzicht van signalen bij een gehackte website.
Updates die blijven liggen zijn de regel, niet de uitzondering. De praktijkmanager deed dit erbij, tussen patiënten door. Dat is geen verwijt maar een constatering: werk dat niemands vaste taak is, gebeurt onregelmatig. De praktijk heeft het daarom ondergebracht bij een vaste beveiligingsroutine met updates, scans en een maandrapport, zodat het niet meer afhangt van wie er toevallig tijd heeft.
Ruim op wat u niet nodig heeft. Oude formulierinzendingen, ongebruikte plugins, verlopen accounts. Bij een besmetting bepaalt dat het verschil tussen een technisch probleem en een meldplichtig incident.
Ziet u zelf vreemde resultaten in Google op uw domeinnaam, wacht dan niet af in de hoop dat het overwaait. Elke week dat het doorloopt, kost meer tijd om terug te draaien dan het schoonmaken zelf.
