Cloaking po infekcji WordPressa – jak malware pokazuje Google tysiące fałszywych stron

Jeśli Twoja strona nagle straciła pozycje w Google, liczba zaindeksowanych adresów gwałtownie wzrosła albo w Google Search Console pojawiły się setki lub tysiące nieznanych podstron, problem nie zawsze leży w samym SEO.

Jedną z możliwych przyczyn jest infekcja wykorzystująca cloaking – mechanizm, który pokazuje użytkownikom prawidłową stronę, a robotom Google zupełnie inną zawartość.

To szczególnie niebezpieczne, ponieważ podczas zwykłego wejścia na stronę wszystko może wyglądać poprawnie. Dopiero porównanie odpowiedzi serwera dla standardowego użytkownika i Googlebota ujawnia, że wyszukiwarka otrzymuje spamerskie treści, produkty i tysiące wygenerowanych adresów URL.

Poniżej pokazujemy techniczny przykład takiej infekcji oraz sposób, w jaki udało się ustalić jej mechanizm działania.

Jednym z trudniejszych do wykrycia rodzajów infekcji strony internetowej jest cloaking, czyli zwracanie różnej zawartości w zależności od tego, kto odpytuje serwer.

W analizowanym przypadku zwykły użytkownik otrzymywał prawidłową stronę WordPress, natomiast Googlebot dostawał całkowicie inny dokument HTML – rozbudowany sklep z tysiącami linków do nieistniejących produktów i kategorii.

Dopiero analiza zainfekowanego pliku pozwoliła ustalić dokładny mechanizm działania.

Dwie różne wersje tej samej strony

Do diagnostyki wykonano dwa zapytania:

curl -L "$URL" -o normal.html

oraz:

curl -L -A "Googlebot/2.1 (+http://www.google.com/bot.html)" "$URL" -o googlebot.html

Różnica była bardzo duża.

Normalna odpowiedź zawierała właściwy kod WordPressa. Wersja zwracana Googlebotowi była wielokrotnie większa i zawierała strukturę obcego sklepu internetowego.

W przeanalizowanych plikach:

• normalna wersja zawierała około 115 linków,
• wersja dla Googlebota zawierała ponad 2400 linków,
• ponad 1400 z nich prowadziło do unikalnych adresów wewnętrznych.

To właśnie te linki mogły być następnie odkrywane przez Google i powodować gwałtowny wzrost liczby adresów widocznych w Google Search Console.

Źródło infekcji znajdowało się w pliku WordPressa

Złośliwy kod został umieszczony wewnątrz pliku należącego do WordPress Core.

Początek pliku wyglądał prawidłowo – znajdowały się tam standardowe informacje o wersji WordPressa. Dopiero w dalszej części został dopisany dodatkowy kod.

Pierwszy etap infekcji zawierał duży zaszyfrowany ciąg znaków.

Schemat działania wyglądał w uproszczeniu tak:

zakodowany ciąg
        ↓
Base64
        ↓
odszyfrowanie danych
        ↓
odtworzenie kodu PHP
        ↓
eval()

Payload nie został więc zapisany w pliku jako czytelny PHP. Zastosowano własną warstwę zaciemnienia wykorzystującą szyfrowanie blokowe zbliżone do XTEA, dzięki czemu proste wyszukiwanie charakterystycznych fragmentów złośliwego kodu mogło go nie wykryć.

Po odszyfrowaniu kod był wykonywany przez:

eval($payload);

To właśnie odszyfrowany drugi etap odpowiadał za cloaking.

Malware sprawdza User-Agent

Najciekawszym elementem infekcji okazała się analiza nagłówka:

User-Agent

Kod pobierał go bezpośrednio z:

$_SERVER['HTTP_USER_AGENT']

i porównywał z bardzo rozbudowaną listą robotów oraz narzędzi.

Na liście znajdowały się między innymi:

bingbot
AhrefsBot
SemrushBot
Screaming Frog
GPTBot
curl
wget
python-requests
HeadlessChrome
Selenium
Playwright
Puppeteer

Jeżeli któryś z tych ciągów został wykryty, złośliwy mechanizm nie był uruchamiany.

Co istotne – na tej liście nie znajdował się Googlebot.

To tłumaczy bardzo ważne zachowanie podczas diagnostyki.

Polecenie:

curl "$URL"

identyfikuje się domyślnie jako curl, więc infekcja celowo przestawała działać i administrator otrzymywał prawidłową stronę.

Natomiast:

curl -A "Googlebot/2.1 (+http://www.google.com/bot.html)" "$URL"

nie wpadało już w filtr ochronny malware i uruchamiało kolejny etap.

W efekcie to samo narzędzie mogło zwrócić dwie całkowicie różne strony tylko po zmianie User-Agent.

Decyzja o zwracanej treści była podejmowana zdalnie

Sam zainfekowany plik nie zawierał sklepu ani tysięcy produktów.

Pełnił funkcję loadera komunikującego się z zewnętrznym serwerem sterującym.

Po przejściu kontroli User-Agent malware tworzyło pakiet zawierający między innymi dane:

$_SERVER
$_POST

i wysyłało go do zewnętrznego serwera.

Oznaczało to, że serwer sterujący otrzymywał informacje o aktualnym żądaniu, m.in.:

User-Agent
Request URI
Host
metodę żądania
referer
adres IP widziany przez PHP
nagłówki HTTP
parametry POST

Na tej podstawie mógł zdecydować, jaką zawartość zwrócić.

Dzięki temu osoba kontrolująca infekcję mogła centralnie określić:

• komu pokazać prawidłowy WordPress,
• komu zwrócić spam,
• jaki sklep wygenerować,
• jakie produkty umieścić na stronie,
• jakie adresy URL utworzyć.

Zewnętrzna odpowiedź również była ukrywana

Odpowiedź serwera sterującego nie była przesyłana jako zwykły HTML.

Kod oczekiwał danych umieszczonych pomiędzy znacznikami:

<figure>...</figure>

Następnie wykonywał:

Base64 decode
        ↓
dekompresja
        ↓
JSON decode

Dopiero po tych operacjach otrzymywał właściwe instrukcje.

Jeżeli odpowiedź zawierała przygotowany HTML, malware wykonywało:

echo $html;
exit;

W tym momencie wykonywanie właściwego WordPressa było przerywane.

Googlebot dostawał więc nie zmodyfikowany fragment strony, lecz całkowicie zastępowaną odpowiedź HTML.

Mechanizm mógł również ustawić własny nagłówek HTTP przed wysłaniem treści.

Dlaczego Google zaczyna indeksować tysiące adresów?

Fałszywa strona dostarczana Googlebotowi zawierała ogromną liczbę linków wewnętrznych.

Robot wyszukiwarki widział więc strukturę przypominającą pełnoprawny sklep:

kategorie
    ↓
podkategorie
    ↓
produkty
    ↓
kolejne produkty

Googlebot odwiedzał znalezione linki.

Jeżeli również pod tymi adresami infekcja zwracała kolejne strony sklepu z dalszymi linkami, tworzyła się automatycznie rozrastająca struktura.

W ten sposób jedna infekcja może doprowadzić do pojawienia się w Google Search Console tysięcy, a nawet dziesiątek tysięcy nieistniejących URL-i.

Google ich nie generuje. Odkrywa je w HTML dostarczanym przez zainfekowany serwer.

Dlaczego infekcja była trudna do wykrycia?

Zastosowano jednocześnie kilka mechanizmów ukrywania:

1. malware znajdowało się wewnątrz prawidłowego pliku WordPressa,
2. właściwy kod był zaszyfrowany,
3. odszyfrowany kod był uruchamiany dynamicznie przez eval(),
4. curl i popularne narzędzia SEO były celowo wykluczane,
5. właściwa zawartość spamu była pobierana z zewnętrznego serwera,
6. serwer sterujący mógł zdecydować, komu wysłać spam,
7. pobierana odpowiedź była dodatkowo kompresowana i kodowana.

Dlatego samo wejście na stronę w przeglądarce albo wykonanie zwykłego:

curl "$URL"

mogło sugerować, że witryna działa całkowicie prawidłowo.

Jak diagnozować podobny przypadek?

Jeżeli Google Search Console nagle pokazuje tysiące nieznanych stron, jednym z pierwszych testów powinno być porównanie kilku User-Agentów:

curl -L "$URL" -o normal.html

curl -L -A "Googlebot/2.1 (+http://www.google.com/bot.html)" "$URL" -o googlebot.html

Następnie warto porównać:

diff normal.html googlebot.html

oraz wielkość obu plików:

ls -lh normal.html googlebot.html

Jeżeli różnice są ogromne, trzeba rozpocząć analizę po stronie PHP i serwera.

W przypadku WordPressa szczególnie istotne jest sprawdzenie integralności plików Core. Złośliwy kod może znajdować się nie tylko we wtyczce lub motywie, ale również bezpośrednio w plikach systemowych WordPressa.

Najważniejszy wniosek

W tym przypadku problem nie polegał na błędnej indeksacji Google.

Google prawidłowo indeksowało zawartość, którą otrzymywało od serwera.

Problemem był zainfekowany WordPress, który:

rozpoznawał sposób wejścia → kontaktował się z serwerem sterującym → pobierał przygotowaną treść → zastępował nią właściwą stronę → dostarczał Google tysiące linków do fikcyjnych podstron.

To dobry przykład, dlaczego przy nietypowym wzroście liczby stron w Google Search Console należy analizować nie tylko samą witrynę widoczną w przeglądarce, ale również surową odpowiedź HTTP zwracaną konkretnie Googlebotowi.

Nagły spadek pozycji, nietypowy wzrost liczby stron w Google Search Console czy pojawienie się obcych produktów w wynikach wyszukiwania może być sygnałem, że problem wykracza poza standardowe działania SEO.

W przypadku cloakingu samo poprawienie treści, meta tagów czy usunięcie adresów z Google nie rozwiąże problemu. Najpierw trzeba znaleźć źródło infekcji, usunąć złośliwy kod i sprawdzić, co serwer rzeczywiście zwraca Googlebotowi.

Jeżeli zauważyłeś podobne objawy na swojej stronie – spadki pozycji, tysiące nieznanych adresów w Google Search Console lub podejrzane wyniki wyszukiwania – skontaktuj się z nami.

Możemy przeanalizować stronę od strony technicznej i SEO, sprawdzić odpowiedzi serwera dla Googlebota, zweryfikować pliki WordPressa oraz ustalić, czy witryna nie została wykorzystana do generowania spamerskich treści.