Når Google ser noget andet end dine brugere: WordPress-malware der “fanger” Googlebot med ASN- og CIDR-tjek

Vi er vant til at tænke malware som noget, der enten smadrer en side, viderestiller alle besøgende eller smider en popup i hovedet på folk. Men en nyere variant, som Sucuri har analyseret, går mere stille til værks: Den ændrer en central fil i WordPress, og viser kun et ondsindet “payload” til søgemaskinens infrastruktur. For ejeren og almindelige brugere ser sitet helt normalt ud.

I denne gennemgang får du et klart billede af, hvordan den type infektion fungerer, hvorfor den er svær at opdage med manuel test, og hvilke tegn og kontroller der typisk afslører den.

Hvad er det for et angreb?

Case’en handler om en kompromitteret WordPress-installation, hvor index.php (den primære entrypoint i roden) er blevet modificeret. I stedet for bare at starte WordPress som normalt, fungerer filen som en gatekeeper: den afgør, hvem der besøger sitet, og vælger derefter mellem to adfærdsmønstre:

• Hvis besøgende identificeres som Google-relateret crawler/inspektionsværktøj, hentes og udskrives eksternt indhold fra et tredjepartsdomæne.
• Hvis besøgende er en almindelig bruger (eller en bot der ikke kan verificeres korrekt), får de den normale, “rene” side eller bliver sendt til forsiden.

Konsekvensen er klassisk cloaking (SEO-cloaking): Google indekserer noget, som dine brugere ikke ser. Det er effektivt, fordi mange website-ejere kun opdager problemer via browseren — og i denne model får browseren den pæne version.

Det nye: IP-verificering på Googles ASN-ranges (ikke kun User-Agent)

Cloaking i sig selv er ikke nyt. Det interessante i denne variant er, at den ikke nøjes med at kigge på User-Agent (HTTP-headeren der identificerer klienten — fx browser, device og OS). User-Agent er triviel at spoofe, så ældre og mere simple scripts er ofte nemme at “narre” ved at sende en request med Googlebot i headeren.

Her tager malwaren et ekstra skridt: Den indeholder en stor, hardcoded liste over Googles ASN-tilknyttede IP-ranges i CIDR-format og verificerer, at den besøgendes IP faktisk ligger i et Google-ejet netværksblok.

Kort fortalt: ASN og CIDR i den her kontekst

Et ASN (Autonomous System Number) kan du tænke på som en organisations “internet-identitet” hos BGP-routing: en samling IP-adresser og netværksruter, der hører til den samme aktør. Når en request kommer fra Googles ASN-områder, er det en stærk indikator for, at den faktisk kommer fra Googles infrastruktur (Search-crawlere, inspektionsværktøjer, cloud-tjenester osv.) og ikke fra en tilfældig maskine der udgiver sig for at være Googlebot.

CIDR (Classless Inter-Domain Routing) er den kompakte notation for IP-blokke, fx 192.168.1.0/24, som dækker et helt interval af adresser i én linje. Det gør det muligt at tjekke “tilhører IP’en dette netværk?” uden at liste alle adresser enkeltvis.

Sådan er malwaren typisk bygget op (trin for trin)

I Sucuris fund er logikken lagt ind i index.php og opdelt i flere lag. Pointen er at reducere “støj”: Kun når både identitet (User-Agent) og netværk (IP) matcher Googles infrastruktur, aktiveres payload.

1) Multi-layer identitetstjek (User-Agent + IP)

Først matches der på User-Agent for Google-relaterede klienter. Derefter kommer det afgørende: IP’en verificeres mod de hardcodede ASN/CIDR ranges. Kombinationen gør det svært at reproducere med en almindelig browser eller et simpelt curl-kald fra din egen maskine.

2) Bitwise netværksmatch (lav-niveau validering)

I stedet for at lave simple string-sammenligninger, bruger scriptet bitvise operationer til at afgøre om en IP falder i en given netmask. Den type matematiske tjek er standard netværksteknik, men det er usædvanligt at se det implementeret så gennemført i cloaking-malware — og med ordentlig IPv6-understøttelse, som mange ældre scripts ignorerer.

// Principielt netværksmatch for IPv4:
// (ip & netmask) == (range & netmask)
// Bruges til at afgøre om en besøgendes IP ligger i en CIDR-blok.

($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

// Principielt netværksmatch for IPv4:
// (ip & netmask) == (range & netmask)
// Bruges til at afgøre om en besøgendes IP ligger i en CIDR-blok.

($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

3) Remote payload via cURL (eksternt indhold printes som om det var lokalt)

Når requesten er “godkendt” som legitim Google-trafik, bruger malwaren cURL til at hente indhold fra et eksternt endpoint (i casen et pages.dev-domæne) og printer output direkte i responsen. For Google ligner det derfor, at indholdet bliver serveret af dit site.

// Når bot + IP verificeres, hentes fjernindhold og sendes direkte i responsen
// (domænet er angivet i Sucuris analyse)
$url = 'hxxps://amp-samaresmanor[.]pages[.]dev';

// ... cURL request ...
// echo $remote_content;

// Når bot + IP verificeres, hentes fjernindhold og sendes direkte i responsen
// (domænet er angivet i Sucuris analyse)
$url = 'hxxps://amp-samaresmanor[.]pages[.]dev';

// ... cURL request ...
// echo $remote_content;

4) Bred User-Agent filtrering (mere end bare “Googlebot”)

Ud over klassiske strenge som Googlebot kigger scriptet efter flere varianter relateret til Googles økosystem — fx værktøjer til site-verificering, inspektion og API-crawlere. Det øger sandsynligheden for, at det ondsindede indhold både bliver crawlet, valideret og indekseret på tværs af Googles flows.

5) Conditional logic, redirects og logging (støjsvag drift)

Den sidste del er “beslutningsmotoren”: Hvis både User-Agent og IP passer, serveres payload. Hvis noget fejler, håndteres det pænt, så Google ikke ser en broken page. Hvis nogen prøver at spoofe Googlebot uden at komme fra en legitim Google-range, logges det som en falsk bot og sendes videre til normal side.

Hvorfor index.php og WordPress core-filer er interessante mål

At lægge logikken i index.php giver maksimal kontrol, fordi al trafik typisk passerer her. Samtidig kan angriberen stadig “boote” WordPress-miljøet efter behov.

• wp-load.php kan inkluderes for at indlæse konfiguration og give adgang til database og WordPress-miljø (bootstrapping).
• wp-blog-header.php bliver normalt inkluderet til sidst i den rene WordPress index.php for at køre den almindelige request-cyklus.

Det er netop det, der gør angrebet svært at spotte: Sitet fungerer normalt for de fleste besøgende, fordi angriberen stadig lader den legitime pipeline køre i “default”-stien.

Hvad det gør ved dit site (SEO og omdømme rammes først)

Denne type infektion handler typisk mindre om at stjæle data fra dine brugere og mere om at misbruge dit domænes tillid. Når Google indekserer noget, du ikke selv hoster, kan du blive ramt af:

• SEO-cloaking konsekvenser (manglende tillid, manuelt review, deindexering).
• Blacklisting og advarsler i søgeresultater.
• Resource hijacking: dit site bruges som distributionskanal for tredjepartsindhold.
• Forsinket opdagelse, fordi ejerens egen browser viser den rigtige side.

Typiske advarselstegn (det du kan se uden at reverse engineere alt)

Hvis du har mistanke om, at dit WordPress-site er kompromitteret på den her måde, er det ofte disse spor, der dukker op først:

• Mærkelige eller irrelevante sider/titler i Google-resultater for dit domæne.
• Uventede ændringer i kernefiler (især index.php) eller nyligt ændrede timestamps.
• Mistænkelige URLs eller ukendte domæner i kildekode/logs.
• Uventede serverlogs, fx mange requests der kun giver “anderledes” output til bestemte klienter.

I Sucuris analyse nævnes domænet amp-samaresmanor[.]pages[.]dev som den fjernkilde, der blev hentet indhold fra, og at det på analysetidspunktet var blocklistet af flere sikkerhedsleverandører via VirusTotal.

Praktisk oprydning og forebyggelse (uden at gøre det kompliceret)

Når infektionen sidder i en kernefil, skal du tænke i både fjernelse og lukning af indgangen. En effektiv baseline ser sådan ud:

1. Fjern ukendte filer og mapper: Alt du ikke kan forklare (plugins, mu-plugins, drop-ins, tilfældige PHP-filer).
2. Tjek og gendan kernefiler: Er index.php eller andre core-filer ændret, så gendan fra en kendt ren kilde (og dobbelttjek at ændringen ikke kommer tilbage).
3. Auditer brugere: Kig især efter skjulte/hjælpe-accounts og mistænkelige administratorer.
4. Nulstil credentials: WordPress-admin, FTP/SFTP, hostingpanel og database. (Og roter evt. API keys).
5. Scan din egen maskine: En kompromitteret udvikler-pc kan forklare, hvorfor filer bliver re-inficeret efter oprydning.
6. Opdatér alt: WordPress core, temaer, plugins — og fjern forladte komponenter.
7. Brug en WAF: En Web Application Firewall kan blokere kendte C2-/payload-domæner og reducere risikoen for upload af ondsindede plugins.

Det vigtigste takeaway for WordPress-udviklere

Det her er et godt eksempel på, at moderne SEO-malware ikke behøver at være larmende. Ved at kombinere User-Agent filtrering med ASN/CIDR-baseret IP-verificering kan angriberen målrette Googles crawler meget præcist — og samtidig holde webstedsejeren i den “rene” oplevelse.

I praksis betyder det, at klassiske kontroller som “tjek sitet i browseren” ikke er nok. Du har brug for grundlæggende file integrity checks (så ændringer i fx index.php opdages hurtigt) og løbende overvågning af, hvad Google faktisk indekserer for dit domæne.