---
title: "Googlebotra céloz, neked láthatatlan: IP-tartományokra építő WordPress cloaking malware"
url: "https://helloblog.io/hu/googlebot-ip-tartomanyokra-epito-wordpress-cloaking-malware/"
date: "2026-01-13"
modified: "2026-01-20"
author: "Nagy Eszter"
language: "hu_HU"
categories: ["Biztonság"]
tags: ["cloaking", "Googlebot", "malware", "SEO spam", "WordPress biztonság"]
featured_image: "https://helloblog.io/app/uploads/sites/2/2026/01/featured-3-1024x572.jpg"
excerpt: "Egyre gyakoribb, hogy a támadók nem a látogatókat, hanem a keresőrobotokat verik át: a böngészőben minden rendben, közben a Google teljesen más tartalmat kap. Megnézzük, hogyan működik az IP-ellenőrzéssel megtámogatott cloaking, és mire figyelj WordPress-ben."
---

# Googlebotra céloz, neked láthatatlan: IP-tartományokra építő WordPress cloaking malware

Az egyik legkellemetlenebb WordPress-es fertőzés az, amit nem is nagyon tudsz „észrevenni”. A site neked és a normál látogatóknak rendben betölt, nincs látványos átirányítás, nem ugrik fel gyanús popup – közben viszont a keresőmotorok (különösen a Google) teljesen más tartalmat kapnak. Ennek eredménye tipikusan SEO-spam, indexelési káosz, reputációromlás, rosszabb esetben feketelistázás.

A Sucuri egy olyan esetről írt, ahol a támadók nem elégedtek meg a szokásos, könnyen hamisítható User-Agent szűréssel. A malware a Google infrastruktúrájához tartozó IP-tartományokat is ellenőrizte (ráadásul IPv4 és IPv6 esetén is), és csak akkor szolgálta ki a rejtett payloadot, ha a kérést tényleg „igazi” Googlebotnak gondolta.

## Mi történt a gyakorlatban? Index.php mint kapuőr

A vizsgált fertőzés a WordPress oldal fő belépési pontjába, az `index.php` fájlba került. Ez különösen veszélyes hely: ha a támadó itt dönt arról, hogy mi fusson le, akkor gyakorlatilag a teljes alkalmazás indítása előtt tud szelektálni.

A logika lényege: a módosított `index.php` először azonosítani próbálja a látogatót. Ha „átlagos” felhasználó vagy, a WordPress a megszokott módon szolgál ki. Ha viszont a látogató egy keresőrobotnak tűnik, akkor a támadó által megadott külső forrásból tölt be tartalmat, és azt adja vissza a robotnak – mintha az az oldal saját tartalma lenne.

![Áttekintő ábra az IP-ellenőrzéssel kombinált feltételes logikáról](https://helloblog.io/app/uploads/sites/2/2026/01/IP-Verified-Conditional-Logic.png)

*A támadás szelektíven dönt: tiszta oldal a felhasználónak, külső payload a robotnak. — *Forrás: Sucuri Blog**

## Miért újdonság ez? Nem csak User-Agent alapján szűr

A cloaking (amikor a keresőrobot mást lát, mint a felhasználó) nem új trükk. Az viszont ritkább, hogy a támadó ennyire „precízen” azonosít: a script egy nagy, hardcode-olt listát tartalmazott Google ASN-hez (Autonomous System Number) köthető IP-tartományokról CIDR formátumban.

### ASN röviden: mit jelent, és miért fontos?

Az ASN (Autonomous System Number) lényegében egy hálózati „azonosító” az interneten: IP-címblokkok és útvonalak szerveződnek alá, tipikusan nagy szolgáltatókhoz (például Google) kapcsolódva. Ha egy kérés a Google ASN-hez tartozó hálózatból érkezik, az jó eséllyel valódi Google infrastruktúra – nem csak valaki, aki beírta a User-Agentbe, hogy Googlebot.

### CIDR: hogyan írunk le IP-tartományt tömören?

A CIDR (Classless Inter-Domain Routing) egy tömör jelölés IP-tartományokra. Például a `192.168.1.0/24` azt jelenti, hogy a `192.168.1.0`–`192.168.1.255` tartomány egy blokk. A perjel utáni szám (itt 24) a hálózati maszk méretét adja meg, vagyis hogy mekkora a tartomány.

![CIDR formátumot magyarázó ábra](https://helloblog.io/app/uploads/sites/2/2026/01/CIDR-format.png)

*A CIDR jelölés azt mutatja meg, mekkora IP-blokkot fed le a tartomány. — *Forrás: Sucuri Blog**

## Hogyan működik a malware? Többrétegű ellenőrzés és távoli tartalom betöltése

A minta alapján ez a fertőzés egy klasszikus „kapuőr” (gatekeeper) megoldás: több lépésben próbálja biztosítani, hogy csak a megfelelő célpont (Google robot és kapcsolódó eszközök) kapja meg a rejtett tartalmat.

### 1) Többlépcsős azonosítás: User-Agent + IP validálás

Első körben a script megnézi a `HTTP_USER_AGENT` fejlécet. A User-Agent egy szöveg, amit a böngésző (vagy crawler) minden kérésnél elküld, és tipikusan tartalmazza, hogy milyen kliensről, eszközről, operációs rendszerről van szó. Ezt nagyon könnyű hamisítani, ezért jön a második lépés: az IP-tartomány ellenőrzése.

![Ábra a többrétegű azonosításról (User-Agent és IP ellenőrzés)](https://helloblog.io/app/uploads/sites/2/2026/01/Multi-Layer-Identity-Verification.png)

*A támadók a könnyen hamisítható User-Agentet IP-szintű ellenőrzéssel erősítik meg. — *Forrás: Sucuri Blog**

### 2) Bitműveletes IP-tartomány ellenőrzés (IPv4/IPv6)

A technikailag érdekes rész az, hogy a script nem „string keresést” végez IP-címekre, hanem számol: bitműveletekkel ellenőrzi, hogy a látogató IP-je beleesik-e egy adott CIDR tartományba. A Sucuri példája IPv4-re ezt a logikát mutatja:

```
// IPv4 hálózati egyezés ellenőrzésének alapelve (a Sucuri elemzése alapján)
// (ip & netmask) == (range & netmask)
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);
```

A gyakorlati következmény: ha te manuálisan tesztelsz, hiába állítod át a User-Agentet Googlebotra, a payload akkor sem fog megjelenni, mert az IP-d nem a Google hálózatából jön. Ráadásul a kód IPv6-tal is foglalkozott, amit sok régebbi cloaking script egyszerűen ignorál.

![Ábra a bitműveletes IP tartomány validálásról](https://helloblog.io/app/uploads/sites/2/2026/01/Bitwise-IP-Range-Validation.png)

*Nem csak ellenőriz, hanem „számol”: így sokkal nehezebb egyszerű trükkökkel lebuktatni. — *Forrás: Sucuri Blog**

### 3) Távoli payload betöltése cURL-lel

Ha a látogató átment az ellenőrzésen, a script cURL-lel (PHP-s HTTP kliens) letölt egy külső oldalról tartalmat, majd azt közvetlenül a válaszba írja. A vizsgált esetben a távoli domain a forrás szerint ez volt: `hxxps://amp-samaresmanor[.]pages[.]dev`.

![Ábra a távoli tartalom cURL-es betöltéséről](https://helloblog.io/app/uploads/sites/2/2026/01/Remote-Payload-Execution-via-cURL.png)

*A Google azt látja, mintha a spam tartalom a saját oldalad része lenne. — *Forrás: Sucuri Blog**

### 4) Széles User-Agent szűrés: nem csak „Googlebot”

A szűrés nem áll meg a Googlebot névnél. A script több, Google-höz köthető azonosítót is figyelembe vett (például site verification és különböző ellenőrző/inspekciós eszközök). Ez arra utal, hogy a támadó célja nem pusztán az indexelés, hanem az is, hogy a rejtett tartalom a Google különböző ellenőrzési folyamataiban is konzisztensen megjelenjen.

![Ábra a részletes User-Agent alapú szűrésről](https://helloblog.io/app/uploads/sites/2/2026/01/User-Agent-Filtering.png)

*Minél több Google-eszközt fed le a szűrés, annál stabilabb a cloaking. — *Forrás: Sucuri Blog**

### 5) Feltételes logika, hibakezelés és naplózás

A döntési fa kifejezetten „üzembiztosra” van összerakva: ha legit Google User-Agent + legit Google IP, akkor jön a payload, és a script naplózza a sikert. Ha a távoli tartalom nem tölthető be, a botot `/home/` felé tereli, hogy ne egy hibás oldal kerüljön indexbe. Ha valaki hamis Googlebot (csak User-Agent, de nem Google IP), a kód „Fake GoogleBot detected” jellegű bejegyzést készít és visszairányít a normál kezdőoldalra. Minden más látogató szintén a normál oldalra kerül.

![Ábra a feltételes logikáról és naplózásról](https://helloblog.io/app/uploads/sites/2/2026/01/Conditional-Logic-and-Error-Logging.png)

*A malware nem csak szűr, hanem figyeli is, mennyire működik az átverés. — *Forrás: Sucuri Blog**

## Miért fáj ez ennyire? SEO, reputáció és késleltetett észlelés

Ennek a fertőzésnek a fő „haszna” a támadónak SEO-manipuláció: a Google spam tartalmat lát, te meg a saját oldaladat. A tipikus következmények a forrás alapján:

- Indexelési problémák és deindexelés (eltűnő oldalak, „furcsa” találatok).
- Keresőmotoros feketelistázás és reputációromlás.
- Erőforrások eltérítése (a domained tekintélyét más tartalomra használják).
- Késleltetett detektálás, mert manuális böngészésnél nem jön elő a payload.

## Gyanús jelek: mikor kezdj el azonnal vizsgálódni?

Cloaking esetén a klasszikus „a site feltört” jelek sokszor hiányoznak. Érdemes célzottan ezeket figyelni:

- Rossz minőségű vagy irreleváns Google találatok a domainre (spam jellegű snippetek, furcsa title-ek).
- Frissen módosított core fájlok (különösen: `index.php`).
- Ismeretlen, gyanús URL-ek felbukkanása (Search Console-ban vagy logokban).
- Szokatlan szerverlog minták: botoknál más válaszméret, eltérő útvonalak, váratlan átirányítások.

#### Konkrét indikátor a Sucuri esetéből

A forrásban szereplő távoli domain: `amp-samaresmanor[.]pages[.]dev`. A Sucuri szerint ezt az URL-t a VirusTotal 2 vendor alapján blokkolta a cikk írásakor, és több (5) oldalnál találtak vele kapcsolatot.

## Mit csinál a WordPress core fájlokkal? (wp-load.php és wp-blog-header.php)

A támadók nem véletlenül nyúlnak core fájlokhoz: így a saját kódjuk úgy tud futni, hogy közben a WordPress normál működését is „megtartják” – vagy épp szelektíven elindítják.

- `wp-load.php`: a malware a forrás szerint behúzza (`require_once __DIR__ . '/wp-load.php'`), ezzel „bootstrappel” WordPress környezetet, hozzáfér a konfigurációhoz és az adatbázishoz.
- `wp-blog-header.php`: a normál WordPress `index.php` végén szereplő behúzás; a támadó ezt úgy alakíthatja, hogy csak bizonyos esetekben jusson el idáig a futás.

## Takarítás és megelőzés: mire érdemes fókuszálni?

A Sucuri javaslatai alapján ennél a típusú fertőzésnél nem elég „ránézni” a frontend-re. A célzott védekezéshez a következő lépések kellenek:

1. Ismeretlen fájlok és könyvtárak törlése: ami nem a tiéd vagy a fejlesztődé, menjen karanténba és vizsgáld meg.
2. Felhasználók auditja: gyanús adminok, „segéd” fiókok törlése.
3. Minden jelszó cseréje: WordPress admin, FTP/SFTP, hosting, adatbázis, és ahol még hozzáférés van.
4. Saját géped átvizsgálása: teljes vírusirtó/malware scan, mert a belépési adatok ellopása gyakori belépési pont.
5. Minden frissítése: WordPress core, bővítmények, sablonok – különösen az elhagyott (abandoned) komponensek veszélyesek.
6. WAF használata: Web Application Firewall (alkalmazásrétegű tűzfal), ami tudja blokkolni a gyanús forgalmat és csökkentheti az elsődleges feltöltés/kompromittálás esélyét.
7. File Integrity Monitoring bevezetése: fájlintegritás-ellenőrzés, ami azonnal jelez, ha core fájlok (pl. `index.php`) változnak.
8. Google Search Console rendszeres átnézése: váratlan URL-ek, hirtelen megugró indexelt oldalszám, ismeretlen tartalmak gyors kiszúrása.

## Összefoglaló: a „csendes” malware korszakában a botok a célpontok

Ez a támadás jó példa arra, merre tart a WordPress elleni malware: nem feltétlenül látványos átirányításokkal dolgozik, hanem célzottan a keresőrobotoknak épít alternatív valóságot. A User-Agent szűrést IP-tartomány validálással (ASN + CIDR, bitműveletek, IPv6 támogatás) erősíti meg, így a fertőzés sokáig rejtve maradhat. Ha a Google-ben furcsa találatok jelennek meg, az `index.php` és a core fájlok integritása legyen az első ellenőrzési pontod.

![Példa arra, hogy a Google spam tartalmat lát, miközben a látogatók az eredeti oldalt](https://helloblog.io/app/uploads/sites/2/2026/01/What-Google-sees.png)

*Cloakingnál a keresőrobotok és a felhasználók eltérő tartalmat kaphatnak ugyanarról az URL-ről. — *Forrás: Sucuri Blog**

## Hivatkozások / Források

- [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: amp-samaresmanor.pages](https://publicwww.com/websites/amp-samaresmanor.pages/)
- [Web Application Firewall](https://sucuri.net/website-firewall/)
- [File Integrity Monitoring](https://sucuri.net/malware-detection-scanning/)