---
title: "Cloaking 2.0 w WordPressie: malware, które pokazuje Googlebotowi inny świat (z weryfikacją IP po ASN)"
url: "https://helloblog.io/pl/cloaking-2-0-wordpress-malware-weryfikacja-ip-asn-googlebota/"
date: "2026-01-13"
modified: "2026-01-20"
author: "Piotr Kowalski"
language: "pl_PL"
categories: ["Bezpieczeństwo"]
tags: ["cloaking", "Googlebot", "malware", "SEO", "WordPress"]
featured_image: "https://helloblog.io/app/uploads/sites/8/2026/01/featured-3-1024x572.jpg"
excerpt: "Coraz częściej ataki SEO nie polegają na prostych przekierowaniach, tylko na selektywnym serwowaniu treści wyłącznie robotom Google. Ten wariant idzie dalej: weryfikuje Googlebota nie tylko po User-Agent, ale też po zakresach IP (ASN) i CIDR — z obsługą IPv6."
---

# Cloaking 2.0 w WordPressie: malware, które pokazuje Googlebotowi inny świat (z weryfikacją IP po ASN)

W klasycznych infekcjach WordPressa najłatwiej zauważyć „coś nie tak”: dziwne przekierowania, pop-upy, podejrzane skrypty. Coraz częściej jednak obserwuję inny trend: atak jest zaprojektowany tak, żeby właściciel strony podczas normalnego przeglądania widział czystą witrynę, a zainfekowana treść trafiała wyłącznie do crawlerów (robotów indeksujących). Efekt? Google widzi spam lub obce treści, a Ty w panelu i na froncie widzisz „wszystko OK” — aż do spadku w wynikach lub deindeksacji.

![Schemat ataku: malware przechwytuje Googlebota i serwuje mu inną treść](https://helloblog.io/app/uploads/sites/8/2026/01/Malware-Intercepts-Googlebot-via-IP-820x385-1.png)

**Forrás: Sucuri Blog**

## Co wykryto: selektywne wstrzyknięcie treści w index.php

W opisywanym przypadku złośliwy kod został umieszczony w głównym pliku **index.php** WordPressa. To newralgiczne miejsce: standardowo ten plik inicjuje ładowanie środowiska i przekazuje sterowanie do właściwego „front controllera”. Po modyfikacji zaczyna zachowywać się jak bramka (gatekeeper): najpierw próbuje ustalić, kto odwiedza stronę, a dopiero potem decyduje, czy uruchomić WordPressa normalnie, czy wstrzyknąć zewnętrzny payload.

Taki wzorzec wpisuje się w techniki **SEO cloaking** (cloaking = pokazywanie innych treści robotom i ludziom), tylko że tu autor zadbał o znacznie mocniejszą identyfikację robota niż w typowych „if (Googlebot) { … }” opartych wyłącznie o nagłówek User-Agent.

![Zrzut pokazujący, że Google widzi inną treść niż zwykły użytkownik](https://helloblog.io/app/uploads/sites/8/2026/01/What-Google-sees.png)

*W praktyce właściciel widzi normalną stronę, a robot indeksujący dostaje spam lub obcą treść. — *Forrás: Sucuri Blog**

## Co było nietypowe: weryfikacja Googlebota po ASN i CIDR (z IPv6)

Większość cloakerów zatrzymuje się na sprawdzeniu `HTTP_USER_AGENT`. To proste do obejścia (User-Agent da się podszyć w sekundę). W tym wariancie malware zawierało dużą, zahardcodowaną listę zakresów IP Google powiązanych z **ASN** (Autonomous System Number) zapisanych w formacie **CIDR**. Następnie skrypt wykonywał matematyczną weryfikację, czy IP odwiedzającego faktycznie mieści się w którymś z tych zakresów — i robił to również dla **IPv6**, co w starszych skryptach często jest pomijane.

### ASN: po co atakującemu „tożsamość sieciowa” Google?

**ASN (Autonomous System Number)** możesz traktować jako identyfikator organizacji w globalnym routingu internetu. Google ma własne ASN-y i przypisane do nich pule adresów IP używane przez ich infrastrukturę (m.in. do wyszukiwarki i crawlerów). Jeśli ruch faktycznie pochodzi z takich pul, jest dużo większa szansa, że to prawdziwy robot Google, a nie ktoś udający go nagłówkiem.

### CIDR: co oznacza zapis z ukośnikiem?

**CIDR** to skrótowy zapis zakresu adresów IP w postaci „adres bazowy + maska”, np. `192.168.1.0/24`. Zamiast wypisywać każdy adres osobno, definiujesz blok i jego rozmiar. To standardowy format używany w firewallach, routingach i konfiguracjach sieciowych.

![Ilustracja formatu CIDR na przykładzie zakresu adresów IP](https://helloblog.io/app/uploads/sites/8/2026/01/CIDR-format.png)

**Forrás: Sucuri Blog**

## Jak działa ten malware krok po kroku

W praktyce to zestaw kilku warstw filtrów, które mają jeden cel: podać złośliwą treść tylko prawdziwemu Google (i powiązanym narzędziom), a wszystkich innych odesłać na normalną stronę — tak, żeby infekcja była trudna do zauważenia ręcznie.

### 1) Wielowarstwowa identyfikacja: User-Agent + IP

Najpierw skrypt przegląda `HTTP_USER_AGENT` w poszukiwaniu ciągów znaków związanych z Googlebotem i usługami Google (nie tylko „Googlebot”, ale też frazy kojarzone z narzędziami weryfikacji, inspekcji czy crawlerami API). Dopiero potem uruchamia weryfikację IP, bo sam User-Agent jest niewiarygodny.

![Schemat wielowarstwowej weryfikacji: User-Agent i walidacja IP](https://helloblog.io/app/uploads/sites/8/2026/01/Multi-Layer-Identity-Verification.png)

**Forrás: Sucuri Blog**

### 2) Walidacja IP w stylu „sieciowym” (operacje bitowe)

Zamiast porównywać tekstowo, malware sprowadza adresy IP i maskę do postaci liczbowej i sprawdza dopasowanie do sieci poprzez operacje bitowe (typowe podejście w narzędziach sieciowych). Dla IPv4 logika sprowadza się do porównania adresu po nałożeniu maski (tzw. network match).

```
// Idea sprawdzania dopasowania IP do zakresu CIDR (IPv4):
// (ip & maska) == (adres_sieci & maska)
($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal);
```

![Ilustracja walidacji zakresu IP metodą bitową](https://helloblog.io/app/uploads/sites/8/2026/01/Bitwise-IP-Range-Validation.png)

**Forrás: Sucuri Blog**

### 3) Pobranie payloadu z zewnątrz przez cURL

Jeśli weryfikacja przejdzie, skrypt pobiera zdalną treść i wypisuje ją bezpośrednio w odpowiedzi HTTP. W analizowanym przypadku źródłem była domena `amp-samaresmanor[.]pages[.]dev` (w raporcie wskazano, że była blocklistowana przez część vendorów na VirusTotal). Dla robota wygląda to tak, jakby treść była hostowana natywnie na Twojej domenie.

```
// Malware używa cURL do pobierania zewnętrznej treści i wstrzyknięcia jej w odpowiedź.
// W raporcie wskazano URL w postaci: hxxps://amp-samaresmanor[.]pages[.]dev
// (zapis „hxxps” i [.] to forma bezpiecznego cytowania).
```

![Schemat pobierania zdalnego payloadu przez cURL i podania go robotowi](https://helloblog.io/app/uploads/sites/8/2026/01/Remote-Payload-Execution-via-cURL.png)

**Forrás: Sucuri Blog**

### 4) Rozbudowane filtrowanie User-Agent (nie tylko „Googlebot”)

Warto zwrócić uwagę na szeroki zestaw identyfikatorów w `HTTP_USER_AGENT`. Celem jest objęcie nie tylko klasycznego indeksowania, ale też sytuacji, gdy Google testuje stronę narzędziami (np. inspekcją URL) lub gdy treść przechodzi przez inne komponenty infrastruktury.

![Przykład filtrowania po HTTP User-Agent dla wielu usług Google](https://helloblog.io/app/uploads/sites/8/2026/01/User-Agent-Filtering.png)

**Forrás: Sucuri Blog**

### 5) Logika warunkowa, fallbacki i logowanie błędów

Najbardziej „profesjonalny” element tej próbki to dopracowana decyzyjność: osobna ścieżka dla prawdziwego bota, osobna dla podszywki, osobna dla zwykłych użytkowników. Skrypt ma też mechanizmy logowania zdarzeń i zachowania awaryjne, żeby Google nie zobaczyło pustej/błędnej strony, jeśli pobranie payloadu się nie powiedzie (np. przekierowanie do `/home/`).

- **Prawdziwy bot** (User-Agent pasuje + IP w zakresach ASN): pobierz payload i zwróć go; jeśli pobranie się nie uda, przekieruj, aby uniknąć „broken page”.
- **Fałszywy bot** (User-Agent pasuje, ale IP nie): zaloguj zdarzenie typu „Fake GoogleBot detected” i przekieruj na normalną stronę.
- **Zwykli użytkownicy**: od razu dostają standardową stronę (lub przekierowanie), więc infekcja jest niewidoczna podczas ręcznego przeglądania.

![Schemat logiki warunkowej: bot prawdziwy, bot fałszywy, użytkownik](https://helloblog.io/app/uploads/sites/8/2026/01/Conditional-Logic-and-Error-Logging.png)

**Forrás: Sucuri Blog**

## Dlaczego atak celuje w pliki core WordPressa (wp-load.php, wp-blog-header.php)

W tej rodzinie infekcji istotne jest to, że atakujący nie „psuje” całej strony — on ją przechwytuje tylko w wybranych warunkach. Dlatego malware często stara się zachować zgodność z normalnym bootstrappingiem WordPressa.

- `wp-load.php` — dołączenie tego pliku uruchamia środowisko WordPressa (konfigurację, dostęp do bazy, stałe, itp.), co daje atakującemu wygodny kontekst do dalszych działań.
- `wp-blog-header.php` — w klasycznym `index.php` ten plik pojawia się na końcu łańcucha ładowania frontu; złośliwa modyfikacja może warunkowo „ominąć” standardową ścieżkę lub do niej wrócić, jeśli odwiedzający nie spełnia kryteriów.

```
// Fragment wskazany w raporcie jako element bootstrapu:
require_once __DIR__ . '/wp-load.php';
```

## Konsekwencje: mniej “hackowania”, więcej szkody SEO

Ten typ infekcji jest nastawiony przede wszystkim na reputację w wyszukiwarce i wykorzystanie zaufania domeny. Skutki bywają dotkliwe mimo tego, że użytkownik końcowy nic nie zauważa.

- blacklisting lub filtr ręczny po stronie wyszukiwarki
- deindeksacja (wypadnięcie z wyników) lub indeksowanie spamowych podstron zamiast właściwych
- przejęcie zasobów (Twoja domena „hostuje” cudzą treść dla Google)
- opóźnione wykrycie, bo infekcja jest niewidoczna w typowym QA i podczas przeglądania strony w przeglądarce

## Sygnały ostrzegawcze, które realnie da się zauważyć

Jeśli podejrzewasz, że coś przechwytuje ruch crawlerów, nie polegaj wyłącznie na tym, co widzisz w przeglądarce. W tym scenariuszu to właśnie „normalne wejścia” mają wyglądać czysto.

- nietypowe snippety w wynikach Google (inne tytuły/opisy, obce języki, spam)
- świeżo modyfikowane pliki core, szczególnie `index.php`
- podejrzane URL-e/domeny w kodzie lub w logach
- zaskakujące wpisy w logach serwera (nietypowe żądania, przekierowania, błędy związane z cURL)

#### Uwaga na „selektywne” infekcje

Jeśli malware serwuje payload tylko dla zweryfikowanych IP Google, testy typu „wejdę na stronę w incognito” niczego nie pokażą. Weryfikuj integralność plików i analizuj to, co trafia do indeksu w Google Search Console.

## Remediacja i prewencja (praktyczny checklist)

1. Usuń nieznane pliki i katalogi oraz podejrzane fragmenty w plikach core (szczególnie `index.php`).
2. Zrób audyt użytkowników WordPressa: usuń podejrzanych administratorów, „pomocnicze” konta, które nie powinny istnieć.
3. Zresetuj hasła: WP admin, FTP/SFTP, panel hostingu, baza danych (i klucze/sekrety, jeśli masz je w środowisku).
4. Przeskanuj swój komputer (także stację deweloperską) antywirusem/antymalware — zdarza się, że infekcja wraca przez wykradzione dane dostępowe.
5. Zaktualizuj WordPress core, wtyczki i motywy; usuń porzucone komponenty, które nie dostają poprawek.
6. Rozważ WAF (Web Application Firewall) — filtr aplikacyjny, który potrafi blokować znane złośliwe wzorce i ograniczać komunikację z infrastrukturą C2 oraz utrudniać upload złośliwych plików.

## Najważniejsze wnioski

To nie jest „głośny” malware, który od razu przekierowuje użytkowników na scam. To cichy mechanizm przechwytujący zaufanie wyszukiwarki: Twoja witryna staje się kontrolowaną bramką do obcej treści, ale tylko dla prawdziwej infrastruktury Google. Dlatego kluczowe są dwie rzeczy: **monitoring integralności plików** (żeby wykryć nieautoryzowane zmiany w core, np. `index.php`) oraz regularna kontrola tego, co faktycznie indeksuje Google (np. pod kątem nieoczekiwanych stron i treści).

## Odniesienia / Źródła

- [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)
- [Sucuri Website Firewall](https://sucuri.net/website-firewall/)
- [File Integrity Monitoring / Malware Detection Scanning](https://sucuri.net/malware-detection-scanning/)
- [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/)