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.

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.

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.

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.

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

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

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

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

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.

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.

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';

// 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)

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