När Google ser något helt annat än besökare: WordPress-malware som verifierar Googlebots IP på ASN-nivå

Det klassiska mönstret med “redirect alla till en skum domän” blir allt mindre vanligt. I stället ser vi attacker som är selektiva på riktigt: vanliga besökare (och ofta även sajtägaren) får se en helt normal WordPress-sajt, medan sökmotorer får ett helt annat innehåll. Det här är extra lurigt, eftersom det främst slår mot SEO och varumärke – och kan pågå länge utan att någon märker något.

I en nyligen analyserad incident hittades en sådan selektiv injektion direkt i sajtens index.php. Den fungerade som en grindvakt: beroende på vem som gjorde requesten laddade den antingen WordPress som vanligt, eller hämtade och skrev ut fjärrinnehåll från en extern källa.

Vad som gör den här varianten mer avancerad än vanlig cloaking

SEO cloaking i sig är ingen ny teknik: många skript tittar på User-Agent och levererar spam till “Googlebot” och vanligt innehåll till människor. Det nya här var hur långt angriparen gick för att säkerställa att det verkligen var Google som tittade.

I stället för att enbart lita på User-Agent (som är trivial att fejka), innehöll malwaren en stor, hårdkodad lista med Googles IP-intervall kopplade till Googles ASN (Autonomous System Number). En ASN kan ses som en organisations “internet-identitet” – ett sätt att gruppera IP-utrymmen som faktiskt ägs och används av exempelvis Google för Search, Gmail och Google Cloud.

Listan var angiven i CIDR-format (Classless Inter-Domain Routing), alltså ett kompakt sätt att beskriva IP-block. Ett enkelt exempel är 192.168.1.0/24, vilket representerar 256 adresser (192.168.1.0–192.168.1.255). Prefixet /24 beskriver storleken på nätet (nätmasken).

Så fungerar attackkedjan i praktiken

Det infekterade index.php-flödet var byggt för att (1) identifiera Googles crawlers, (2) verifiera att trafiken kommer från Googles riktiga IP-utrymme och (3) bara då leverera angriparens innehåll. För alla andra blir allt ”som vanligt”.

1) Flerlagers identifiering: User-Agent + IP-verifiering

Första filtret var HTTP_USER_AGENT: skriptet letade inte bara efter “Googlebot” utan även strängar för Googles olika verifierings- och inspektionsflöden (t.ex. verktyg och API-crawlers). Poängen är att få det injicerade innehållet både indexerat och “bekräftat” genom flera Google-tjänster.

2) Bitvis IP-matchning mot CIDR (IPv4 + IPv6)

Det mest intressanta var IP-kontrollen. I stället för enkla jämförelser använde skriptet bitvisa operationer för att räkna ut om en IP-adress ligger inom ett visst CIDR-intervall. För IPv4 beskrevs logiken som en maskad jämförelse, i stil med:

// Principen: maska både IP och nätverk och jämför resultatet
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

// Principen: maska både IP och nätverk och jämför resultatet
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);

Dessutom fanns robust stöd för IPv6, vilket många äldre cloaking-skript struntar i. Resultatet blir att man inte kan avslöja attacken genom att bara spoof:a en Googlebot-User-Agent från sin egen dator – IP:n måste också matcha Googles faktiska nät.

3) Remote payload via cURL och ”native”-illusion

När både User-Agent och IP-verifiering passerade hämtade skriptet fjärrinnehåll via cURL från en extern URL och skrev ut det direkt i svaret. För sökmotorn ser det därmed ut som att innehållet hostas av den komprometterade sajten.

hxxps://amp-samaresmanor[.]pages[.]dev

hxxps://amp-samaresmanor[.]pages[.]dev

4) Villkorslogik, felhantering och loggning

Skriptet hade en tydlig beslutsmotor och loggning för att övervaka att attacken fungerar:

• Legitim bot (rätt User-Agent + IP matchar): fjärrinnehåll serveras. Om payloaden inte kan hämtas skickas boten vidare till /home/ för att undvika att Google ser en trasig sida.
• Fejkad bot (User-Agent matchar men IP faller): loggar ett fel i stil med “Fake GoogleBot detected” och skickar vidare till den riktiga startsidan.
• Vanliga användare: skickas direkt till normal hemsida (för att hålla ägaren omedveten).

Varför index.php och WordPress-kärnfiler är en favoritplats

Att lägga logiken i index.php ger angriparen en tidig kontrollpunkt i requesten. I den aktuella varianten användes också WordPress egna bootstrap-filer för att hålla normal funktionalitet intakt när malwaren väljer att inte leverera payload.

• wp-load.php: inkluderades för att initiera (bootstrapa) WordPress-miljön så skriptet får tillgång till konfiguration och databas.
• wp-blog-header.php: normalt en del av standardflödet i index.php när WordPress ska rendera sidan som vanligt.

Konsekvenser: SEO-skada och sökrykte snarare än “synligt hack”

Den här typen av infektion är byggd för att vara tyst. I stället för att sabotera sajten för riktiga besökare manipulerar den det som sökmotorer ser. Effekterna blir typiskt:

• blacklisting och/eller deindexering i sökmotorer
• spam-innehåll i sökresultat trots att sajten ser korrekt ut vid manuell kontroll
• ”resource hijacking” där din domän används som distributionsyta för angriparens innehåll
• fördröjd upptäckt eftersom ägare och kundtjänst inte ser problemen i browsern

Tecken att leta efter i en WordPress-miljö

Om du misstänker den här typen av crawler-interception är det sällan frontenden som avslöjar det. Titta i stället efter indikatorer som matchar beteendet:

• märkliga eller försämrade Google-resultat (nya titlar, sidor eller snippet-texter du inte känner igen)
• kärnfiler med oväntade ändringar – särskilt index.php
• misstänkta externa URL:er/domäner i koden
• ovanliga loggrader eller nya loggfiler kopplade till redirect/payload-hämtning

Snabb sanering och förebyggande åtgärder (praktiskt fokus)

När den här typen av kod hamnar i en kärnfil är grundregeln: utgå från att du behöver både sanera och täppa igen hålet som gjorde intrånget möjligt.

1. Rensa okända filer och kataloger: ta bort allt du inte känner igen (eller jämför mot en ren WordPress-distribution).
2. Granska användare: leta efter misstänkta administratörer/hjälpkonton och ta bort dem.
3. Återställ inloggningar: byt lösenord för WP-admin, FTP/SFTP, hostingpanel och databas.
4. Skanna din egen dator: ett komprometterat utvecklarmaskineri kan återinfektera sajten via sparade credentials.
5. Uppdatera allt: WordPress core, teman och plugins.
6. Sätt en WAF: en Web Application Firewall kan hjälpa till att blockera kända C2-/payload-domäner och stoppa vissa uppladdningsförsök i första ledet.
7. Övervaka filintegritet: larma på ändringar i kärnfiler som index.php.

Domänen som användes som payload-källa i fallet

I analysen pekade malwaren ut en extern källa på amp-samaresmanor[.]pages[.]dev. Vid tidpunkten för publicering var den URL:en flaggad av ett mindre antal säkerhetsleverantörer på VirusTotal, och flera webbplatser hade identifierats med samma infektion via PublicWWW.

Det viktiga här är inte just domännamnet utan mönstret: en komprometterad WordPress-sajt används som trovärdig yta, medan det faktiska innehållet hostas någon annanstans och bara visas för verifierade crawlers.

Sammanfattning

Det här är en tydlig påminnelse om att modern WordPress-malware ofta är byggd för att undvika mänsklig upptäckt. Genom att kombinera User-Agent-filter med ASN-baserad IP-verifiering (inklusive IPv6) kan angriparen leverera spam nästan uteslutande till Googles egna system. För dig som utvecklar eller driftar WordPress är filintegritetsövervakning och regelbunden kontroll av indexerade sidor i Google Search Console två av de mest träffsäkra sätten att upptäcka den här typen av tyst SEO-kapning i tid.