WordPress-malware die Googlebot selectief bedient met ASN/IP-verificatie: zo werkt het (en waar je op let)

De klassieke “redirect iedereen naar spam” zie je steeds minder. Aanvallers worden subtieler: ze willen dat alleen zoekmachinecrawlers de payload zien, terwijl normale bezoekers (en vaak ook de site-eigenaar) niets merken. Een recente variant die ik tegenkwam is extra interessant, omdat de malware niet alleen op de User-Agent vertrouwt, maar Googlebot ook verifieert op IP-niveau via Google’s ASN-ranges — inclusief IPv6 — met bitwise checks.

In dit artikel leg ik uit wat er technisch gebeurt, waarom dit zo lastig te spotten is, welke signalen je wél kunt zien, en welke praktische maatregelen dit type aanval sneller boven water halen.

Wat er werd aangetroffen: selectieve content injection in index.php

De kern van de infectie zat in een plek waar je ’m misschien niet direct verwacht, maar die wel maximale controle geeft: het hoofdbestand index.php van een WordPress-site. In plaats van altijd de normale WordPress-bootstrapping te doen, fungeert die aangepaste index.php als een poortwachter.

Afhankelijk van wie de bezoeker is, gebeurt één van de volgende dingen:

• WordPress laadt ‘gewoon’ en bezoekers zien de originele site.
• Een crawler (specifiek Google-infra) krijgt extern opgehaalde content geserveerd, alsof die op jouw site staat.

Waarom deze variant opvalt: Googlebot-check op ASN/IP-range (niet alleen User-Agent)

Cloaking (verschillende content tonen aan bots versus mensen) is niet nieuw. Wat hier opvalt, is de uitvoering. Veel scripts blijven steken op een simpele User-Agent-match (bijv. “Googlebot”). Dat is makkelijk te spoofen, dus makkelijk te testen.

Deze malware gaat een stap verder: er zit een hardcoded lijst in met Google’s ASN (Autonomous System Number) IP-ranges, genoteerd in CIDR-formaat. Daardoor wordt de payload alleen getoond als (1) de User-Agent past én (2) het IP-adres daadwerkelijk binnen Google’s eigen netwerkblokken valt.

ASN en CIDR in één alinea (praktisch bekeken)

Een ASN kun je zien als de “internet-identiteit” van een organisatie: een set netwerkblokken die bij bijvoorbeeld Google horen. CIDR is de compacte notatie voor zo’n blok, zoals 192.168.1.0/24, waarmee je een hele range beschrijft in plaats van losse IP’s. Handig voor routing en filtering — en dus ook voor malware die heel precies wil selecteren.

Het technische mechanisme: bitwise IP-validatie en IPv6-support

In plaats van IP-adressen ‘tekstueel’ te vergelijken, gebruikt de code bitwise operaties om te controleren of een IP binnen een bepaald netwerkblok valt. Dat is precieser, lastiger fout te implementeren (dus opvallend “kwalitatief”), en werkt goed met grote lijsten ranges.

// Voor IPv4 wordt de match vaak gedaan via bitwise AND met een netmask
// (ip & netmask) == (network & netmask)
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

// Voor IPv4 wordt de match vaak gedaan via bitwise AND met een netmask
// (ip & netmask) == (network & netmask)
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

Daarnaast had deze variant expliciete ondersteuning voor IPv6. Dat is relevant omdat veel oudere cloaking-scripts IPv6 negeren, terwijl zoekmachine-infra en cloudproviders steeds vaker via IPv6 crawlen. Door IPv6 mee te nemen, vergroot de aanvaller de kans dat de cloaking consistent werkt en minder snel ‘lekt’ naar normale tests.

Remote payload via cURL: content komt van buitenaf, maar lijkt lokaal

Na succesvolle verificatie (Google-achtige User-Agent én IP binnen Google ASN-ranges) haalt de malware via cURL content op bij een externe endpoint en print die direct in de response. Voor de crawler lijkt het daardoor alsof jouw WordPress-site de content host.

// De malware haalt HTML op van een externe bron en echo't die in de pagina
// In de case werd o.a. deze host genoemd:
// hxxps://amp-samaresmanor[.]pages[.]dev

// (URL expres niet als klikbare https opgenomen)

// De malware haalt HTML op van een externe bron en echo't die in de pagina
// In de case werd o.a. deze host genoemd:
// hxxps://amp-samaresmanor[.]pages[.]dev

// (URL expres niet als klikbare https opgenomen)

Brede User-Agent filtering: niet alleen “Googlebot”

Een interessante nuance: de filtering keek niet uitsluitend naar “Googlebot”. Het script bevatte meerdere strings die passen bij Google tooling voor verificatie, inspectie en API-crawlers. Dat vergroot de kans dat spamcontent niet alleen wordt gecrawld, maar ook ‘goed’ door Google-systemen heen komt (bijv. via inspectietools en verificatiestappen).

Conditionele logica met logging: de aanvaller monitort z’n ‘succes’

Dit soort malware is niet alleen selectief, maar ook verrassend ‘product-ready’: er zit beslislogica en error handling in. In grote lijnen:

• Legitieme bot: User-Agent match + IP-validatie ok → remote content serveren en succes loggen. Als remote ophalen faalt, kan de bot worden omgeleid (bijv. naar /home/) zodat Google geen kapotte pagina indexeert.
• Fake bot: iemand spoofed de User-Agent, maar IP-check faalt → log ‘Fake GoogleBot detected’ en redirect naar de normale homepage.
• Normale bezoeker: direct door naar de reguliere homepage/flow.

Waarom dit vooral een SEO-probleem is (maar niet alleen)

De primaire impact zit in SEO en reputatie: Google indexeert content die jij niet publiceert. Dat kan leiden tot deindexing, blacklisting, reputatieschade en een lange detectietijd omdat ‘normale’ checks niets opleveren. Daarnaast kan je site misbruikt worden als doorgeefluik (resource hijacking), waarbij de aanvaller jouw domeinautoriteit inzet als vehikel.

Signalen om op te letten (ook als je site ‘normaal’ lijkt)

Omdat deze aanval bewust buiten het zicht van normale bezoekers blijft, moet je anders kijken dan alleen ‘even de homepage openen’. Dit zijn praktische indicatoren die in dit soort cases vaak naar voren komen:

• Vreemde of slechte zoekresultaten in Google (onverwachte titles/descriptions, spammy sitelinks, onbekende paden).
• Onverklaarbare recente wijzigingen in core files, met name index.php (maar ook alles rondom de WordPress bootstrap).
• Verdachte externe URL’s of domeinen in code of logs (zoals een pages.dev endpoint).
• Onverwachte logregels of foutmeldingen die wijzen op bot-detectie/redirects.

Waarom core files hiervoor aantrekkelijk zijn: wp-load.php en wp-blog-header.php

Wat deze aanpak slim maakt, is dat de aanvaller WordPress niet per se ‘breekt’. Door WordPress core bestanden op de juiste momenten aan te roepen, kan de malware zowel zijn eigen flow draaien als de site normaal laten functioneren.

• wp-load.php: wordt gebruikt om de WordPress omgeving te bootstrappen (config, database, functies). Daarmee kan de malware meeliften op de bestaande sitecontext.
• wp-blog-header.php: normaal gesproken onderdeel van de standaard WordPress flow; door dit pas aan het einde (of conditioneel) aan te roepen, kan de aanvaller eerst beslissen wat er überhaupt gerenderd wordt.

Remediatie in de praktijk: wat je direct wilt doen

Als je dit soort selectieve cloaking vermoedt, is het belangrijk om zowel de malware zelf te verwijderen als de toegangsvector te dichten. De actiepunten hieronder zijn bewust ‘saai’, maar effectief.

1. Verwijder onbekende bestanden en directories (alles wat niet door jou of je team is geplaatst).
2. Controleer WordPress gebruikers en verwijder verdachte admin-accounts (ook ‘helper’-accounts die niemand herkent).
3. Reset alle credentials: WordPress admin(s), FTP/SFTP, hostingpanel en databasewachtwoorden.
4. Scan je eigen machine: als je workstation gecompromitteerd is, blijft herinfectie een risico.
5. Update WordPress core, thema’s en plugins (en verwijder ongebruikte of verlaten plugins).
6. Zet een WAF (Web Application Firewall) voor je site om bekende kwaadaardige communicatie en uploads eerder te blokkeren.

Preventie die hier echt het verschil maakt: file integrity en Search Console-hygiëne

Omdat dit soort malware graag in core files verstopt zit en alleen onder specifieke omstandigheden actief wordt, werken twee controles opvallend goed:

• File Integrity Monitoring: detecteert ongeautoriseerde wijzigingen in bestanden zoals index.php (en andere WordPress core bestanden) voordat SEO-schade groot wordt.
• Regelmatige check in Google Search Console: let op onverwachte URL’s in de index, rare canonical’s, of coverage issues die niet passen bij je release-ritme.

De belangrijkste takeaway: aanvallers misbruiken steeds vaker het vertrouwen van zoekmachines, en bouwen malware die zich gedraagt als een gecontroleerde content gateway. Als je monitoring alleen op ‘wat zie ik in de browser?’ leunt, loop je achter de feiten aan.