---
title: "När Google ser något helt annat än besökare: WordPress-malware som verifierar Googlebots IP på ASN-nivå"
url: "https://helloblog.io/sv/wordpress-malware-googlebot-asn-ip-verifiering/"
date: "2026-01-13"
modified: "2026-01-20"
author: "Elin Andersson"
language: "sv_SE"
categories: ["Säkerhet"]
tags: ["cloaking", "Googlebot", "malware", "SEO", "WordPress"]
featured_image: "https://helloblog.io/app/uploads/sites/13/2026/01/featured-3-1024x572.jpg"
excerpt: "En ny typ av SEO-cloaking dyker upp i WordPress där angriparen inte nöjer sig med att kolla User-Agent – de räknar matematiskt på IP:n för att bara visa spam för Googles riktiga infrastruktur."
---

# 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).

![Diagram som visar IP-verifierad villkorslogik för att avgöra vilken payload som ska serveras](https://helloblog.io/app/uploads/sites/13/2026/01/IP-Verified-Conditional-Logic.png)

**Forrás: Sucuri Blog**

## 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.

![Illustration av flerlagers verifiering där User-Agent kontrolleras och därefter IP-intervall verifieras](https://helloblog.io/app/uploads/sites/13/2026/01/Multi-Layer-Identity-Verification.png)

**Forrás: Sucuri Blog**

### 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);
```

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.

![Diagram som visar bitvis validering av IP-intervall mot nätmask i CIDR-format](https://helloblog.io/app/uploads/sites/13/2026/01/Bitwise-IP-Range-Validation.png)

**Forrás: Sucuri Blog**

![Illustration av CIDR-format och hur ett prefix som /24 avgränsar ett IP-block](https://helloblog.io/app/uploads/sites/13/2026/01/CIDR-format.png)

**Forrás: Sucuri Blog**

### 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
```

![Diagram som visar hur payload hämtas via cURL från extern domän och skrivs ut i responsen](https://helloblog.io/app/uploads/sites/13/2026/01/Remote-Payload-Execution-via-cURL.png)

**Forrás: Sucuri Blog**

### 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).

![Flödesschema över villkorslogik: legitim bot får payload, fejkad bot loggas och omdirigeras, vanliga användare får normal sida](https://helloblog.io/app/uploads/sites/13/2026/01/Conditional-Logic-and-Error-Logging.png)

**Forrás: Sucuri Blog**

## 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

![Exempel på hur Google kan se spam-innehåll medan vanliga besökare fortfarande ser den riktiga webbplatsen](https://helloblog.io/app/uploads/sites/13/2026/01/What-Google-sees.png)

**Forrás: Sucuri Blog**

## 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

#### Extra lurigt i felsökning

Eftersom IP-verifieringen kan kräva Googles riktiga ASN-IP:n räcker det inte att testa med en spoofad User-Agent lokalt. Du kan få helt ”rent” resultat i din egen browser och ändå vara infekterad.

## 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.

## Referenser / Källor

- [Malware Intercepts Googlebot via IP-Verified Conditional Logic](https://blog.sucuri.net/2026/01/malware-intercepts-googlebot-via-ip-verified-conditional-logic.html)
- [Google Sees Spam, You See Your Site: A Cloaked SEO Spam Attack](https://blog.sucuri.net/2026/01/google-sees-spam-you-see-your-site-a-cloaked-seo-spam-attack.html)
- [VirusTotal URL report (amp-samaresmanor.pages.dev)](https://www.virustotal.com/gui/url/5a006beedf563c6215a31746d011d13fd4f2561a1bf3b557484c4532b13e1ec6?nocache=1)
- [PublicWWW results for amp-samaresmanor.pages.dev](https://publicwww.com/websites/amp-samaresmanor.pages/)