Japoński spam SEO na WordPressie — jak rozpoznać i usunąć atak

Strona klienta działała bez zarzutu. A w Google wyświetlała setki japońskich stron sklepu, którego nigdy nie było. To nie pomyłka wyszukiwarki ani literówka w adresie — to klasyczny Japanese keyword hack, jeden z najczęstszych i najbardziej podstępnych ataków na WordPressa. Podstępny, bo właściciel strony zwykle nie ma pojęcia, że padł ofiarą. Niedawno sprzątałem dokładnie taki przypadek i w tym artykule pokazuję, jak go rozpoznać, dlaczego potrafi działać miesiącami w ukryciu i jak usunąć go do końca — a nie tylko zamieść pod dywan.

Jak wyglądał atak

Pierwszym sygnałem nie była sama strona, tylko Google. Wpisanie komendy site:domena.pl zwracało listę wyników, których nigdy nikt nie publikował: setki podstron z tytułami i opisami po japońsku, datami sprzed kilku dni i cenami w jenach.

Klikając w którykolwiek wynik, trafiało się na stronę wyglądającą jak prawdziwy sklep — japońskie opisy, zdjęcia torebek i zegarków marek premium, ceny w jenach, przyciski „dodaj do koszyka”. Wszystko podłożone pod cudzą, zaufaną domenę.

Cloaking — dlaczego właściciel niczego nie widział

Najważniejszy element tego ataku, i powód, dla którego potrafi pozostać niewykryty przez wiele miesięcy: wchodząc na stronę bezpośrednio, właściciel widział swoją normalną zawartość. Dopiero wejście z wyników wyszukiwania Google lub Bing serwowało wersję po japońsku.

To technika zwana cloakingiem. Skrypt atakującego sprawdza, kto i skąd odwiedza stronę — analizuje nagłówek Referer (czy ktoś przyszedł z wyszukiwarki), User-Agent (czy to robot Google), a czasem to, czy odwiedzający jest zalogowanym administratorem. Na tej podstawie podejmuje decyzję:

• Właściciel wpisujący adres ręcznie albo zalogowany admin → dostaje oryginalną, czystą stronę. Wszystko wygląda normalnie.
• Googlebot oraz użytkownik klikający z wyników wyszukiwania → dostaje japońską stronę spamową.

Efekt jest taki, że osoba prowadząca stronę może codziennie ją otwierać i nie zauważyć absolutnie niczego. Atak żyje wyłącznie w przestrzeni między wyszukiwarką a użytkownikiem przychodzącym z wyszukiwarki — czyli dokładnie tam, gdzie właściciel nie zagląda. Stąd żelazna zasada: stanu strony nie ocenia się po tym, jak wygląda po zalogowaniu, tylko po tym, co widzi Google. Komenda site:twojadomena.pl to pierwsze i najszybsze narzędzie diagnostyczne.

Atak nie ograniczał się zresztą do Google. Poniżej ten sam przypadek widziany z poziomu Bing — w indeksie obok prawdziwych, norweskich podstron sklepu (logowanie, regulamin) siedzą wstrzyknięte japońskie strony produktowe. To pokazuje skalę: spam trafił do wielu wyszukiwarek naraz.

Po co komuś japoński spam na cudzej stronie

Ten atak nie ma na celu zniszczenia strony ani wyłudzenia danych. To parasite SEO — pasożytowanie na cudzym autorytecie.

Zbudowanie zaufania domeny w Google zajmuje lata. Atakujący nie chce go budować — chce go ukraść. Podkładając tysiące podstron pod dobrze ocenianą, istniejącą domenę, błyskawicznie wprowadza swój spam do indeksu z gotowym autorytetem. Te strony rankują na japońskie frazy zakupowe, a ruch z nich jest przekierowywany do realnych (najczęściej scamowych) sklepów albo sprzedawany dalej. Ofiara płaci za to:

• utratą pozycji — Google obniża ranking całej domeny, gdy wykryje spam,
• ostrzeżeniem o złośliwym oprogramowaniu w wynikach i przeglądarce,
• spaleniem reputacji domeny, której odbudowa trwa miesiącami.

Szczególnie obrywają sklepy. Instalacje WooCommerce i inne platformy e-commerce mają zwykle więcej wtyczek (czyli większą powierzchnię ataku), a fałszywe podstrony produktowe wtapiają się w prawdziwy katalog — przez co atak dłużej pozostaje niezauważony. Nieprzypadkowo spam udaje właśnie oferty sklepowe: ceny, przyciski „dodaj do koszyka”, karty produktów.

W analizowanym przypadku część spamowych nagłówków zdradzała nawet mechanikę generowania treści — sztywne szablony „marka + model + słowo zakupowe” po japońsku, powielane tysiące razy.

Lawina linków wewnętrznych

Drugą rzeczą, która rzuca się w oczy po analizie, jest skala linkowania wewnętrznego. Pojedyncza spamowa podstrona zawierała kilkaset odnośników do kolejnych podstron tego samego sklepu — w analizowanym przypadku audyt linków (na zrzucie poniżej, z mojego narzędzia UPER) wykrył 328 linków wewnętrznych na jednej stronie.

Co więcej, linkowała praktycznie każda grafika. Zdjęcia produktów były hotlinkowane z zewnętrznego CDN-u — atakujący nie trzymał ich nawet na zaatakowanym serwerze — a każda taka miniaturka japońskiego ogłoszenia była jednocześnie odnośnikiem do następnej podstrony WordPressa. To celowy mechanizm: gęsta sieć wzajemnych linków sprawia, że robot Google błyskawicznie odkrywa i indeksuje całe tysiące spamowych adresów, zamiast utknąć na jednej stronie.

Zanim przejdziemy do wykrywania — oto cały mechanizm w pięciu krokach:

Jak rozpoznać, że to ten atak

Zanim zaczniesz cokolwiek czyścić, potwierdź diagnozę. Sygnały Japanese keyword hack:

Najwięcej powie Ci Google Search Console. Jeśli nie masz do niej dostępu — to pierwszy krok, który trzeba wykonać przed czymkolwiek innym. To ona pokaże prawdziwą, „googlebotową” wersję strony, której cloaking nie ukryje.

Najczęstszy błąd przy czyszczeniu — ukryta sitemapa

Tu zaczyna się część, na której potyka się większość osób sprzątających ten atak samodzielnie. Usuwają japońskie strony, kasują podejrzane pliki, strona wygląda na czystą — a po kilku dniach spam wraca, albo Google dalej indeksuje setki japońskich URL-i, mimo że żadnej z tych stron już nie ma.

Samo poprawienie .htaccess i zaktualizowanie wtyczek zwykle pomaga tylko na chwilę — po kilku dniach albo tygodniach strona infekuje się ponownie. Dopóki nie wyczyścisz serwera do końca, atak wraca, bo złośliwe skrypty PHP bywają zaszyte głęboko w strukturze katalogów: w podfolderach wp-content/uploads, w plikach udających elementy motywu lub wtyczki, czasem w kilku kopiach naraz. Jedna przeoczona linijka wystarczy, żeby backdoor odtworzył całą resztę.

Trzeba też pamiętać o sąsiednich stronach. Jeśli na jednym koncie hostingowym trzymasz kilka serwisów, a open_basedir nie jest poprawnie ustawione (nie izoluje katalogów od siebie), infekcja jednej witryny zwykle rozlewa się na wszystkie pozostałe. Klasyczny scenariusz: w katalogu /blog/ stoi WordPress, a obok — sklep na Magento czy PrestaShop. Dziurawy WordPress staje się wtedy furtką do sklepu, mimo że sam sklep był aktualny i dobrze zabezpieczony. Dlatego i przy czyszczeniu, i przy planowaniu, co gdzie postawić, trzeba patrzeć na całe konto hostingowe, a nie pojedynczą stronę.

Powód, który świetnie udokumentowało Sucuri: podmieniona, ukryta sitemapa. Atak często zostawia własny plik mapy strony (np. sitemap.xml wskazujący na spamowe URL-e albo dodatkowy plik typu wp-sitemap-xxxx.xml) i zgłasza go do Google. Nawet po usunięciu wszystkich spamowych stron Google nadal trzyma w kolejce indeksowania adresy z tej sitemapy. Dopóki jej nie znajdziesz i nie usuniesz, walczysz z wiatrakami.

Dlatego czyszczenie tego ataku to nie jest kasowanie widocznych stron. To usunięcie całego mechanizmu:

1. Backdoora — pliku PHP, który pozwala atakującemu wrócić (często ukryty w wp-content/uploads, podszywający się pod nazwę systemowego pliku).
2. Fałszywego konta administratora — dodanego, żeby utrzymać dostęp nawet po zmianie haseł.
3. Wpisów w .htaccess — odpowiadających za cloaking i przekierowania.
4. Doklejonego kodu w wp-config.php i plikach motywu.
5. Złośliwej sitemapy i wszystkich plików, które ją generują.

Jak usunąć atak krok po kroku

Skrócony, sprawdzony przepływ usuwania:

1. Zrób kopię zapasową całości (pliki + baza) przed jakąkolwiek ingerencją — to materiał dowodowy i siatka bezpieczeństwa.
2. Zidentyfikuj zakres w Google Search Console — ile URL-i, jakie wzorce, od kiedy.
3. Usuń fałszywe konta administratorów i zresetuj hasła wszystkim pozostałym.
4. Wyczyść pliki — porównaj instalację z czystym WordPressem, usuń backdoory, przywróć oryginalny .htaccess i wp-config.php. Skaner (np. Wordfence) pomaga, ale nie zastępuje ręcznego przeglądu.
5. Wyczyść bazę danych ze spamowych wpisów i opcji dodanych przez atak.
6. Znajdź i usuń złośliwą sitemapę, a poprawną zgłoś ponownie w GSC.
7. Zaktualizuj wszystko — rdzeń, motyw, wszystkie wtyczki. Usuń te nieużywane.
8. Poproś Google o ponowne sprawdzenie w raporcie „Problemy związane z bezpieczeństwem”.

Jeśli na którymkolwiek kroku nie masz pewności, czy plik jest częścią WordPressa, czy backdoorem — to moment, żeby oddać sprawę komuś, kto robił to wcześniej. Pominięty backdoor oznacza, że za tydzień zaczynasz od zera.

A jeśli nie masz aktualnej kopii zapasowej ani strony w repozytorium (Git)? Wtedy ręczne czyszczenie bywa loterią — nigdy nie masz stuprocentowej pewności, że wyłapałeś każdy backdoor, bo nie ma czystego punktu odniesienia do porównania. W takiej sytuacji najskuteczniejszym rozwiązaniem jest często postawienie strony od nowa: świeża instalacja, zabezpieczona od pierwszej minuty, z możliwie najmniejszą liczbą zewnętrznych wtyczek — wyłącznie w aktualnych wersjach. Brzmi drastycznie, ale zwykle jest szybsze i pewniejsze niż tropienie pojedynczych zainfekowanych plików w instalacji, której nie da się z niczym zestawić.

Jak się zabezpieczyć na przyszłość

Najpierw szersza perspektywa: WordPress napędza ponad 40% wszystkich stron w internecie i właśnie ta popularność czyni go najczęściej atakowanym systemem. Boty automatycznie skanują tysiące witryn naraz w poszukiwaniu znanych podatności w popularnych wtyczkach — nie musisz być „ciekawym celem”, wystarczy, że masz nieaktualny, dziurawy dodatek. Skalę problemu widać w publicznych bazach podatności — Patchstack, Wordfence Intelligence czy WPScan — gdzie niemal codziennie przybywają nowe wpisy o SQL injection, XSS czy obejściu uwierzytelniania w konkretnych wtyczkach. To nie znaczy, że WordPress jest zły; po prostu im więcej osób czegoś używa, tym bardziej opłaca się to atakować.

Sam atak prawie zawsze wchodzi przez nieaktualną wtyczkę lub motyw z publicznie znaną podatnością, słabe hasło albo piracki motyw premium z doklejonym kodem. WordPress jako taki jest bezpieczny — dziurą jest zwykle jeden zaniedbany dodatek.

Minimum higieny:

• Aktualizuj rdzeń, motyw i wtyczki natychmiast po wydaniu łatek.
• Ogranicz liczbę wtyczek — każda to potencjalny wektor ataku.
• Silne hasła + 2FA dla wszystkich kont z dostępem do panelu.
• Nie instaluj motywów i wtyczek z nieoficjalnych źródeł („darmowych” wersji premium).
• Monitoruj stronę i jej linki — Google Search Console i Bing Webmaster Tools (oba darmowe), a profil linków w narzędziach takich jak Ahrefs. To one pierwsze pokażą nagły skok zaindeksowanych stron albo spam ukryty cloakingiem.
• Regularne kopie zapasowe trzymane poza serwerem strony.

Jedno zastrzeżenie do „aktualizuj wszystko”: sama aktualność nie gwarantuje bezpieczeństwa. Zdarza się, że backdoora zawiera oficjalna, najnowsza wersja wtyczki — gdy ktoś przejmie konto jej autora i wstrzyknie złośliwy kod do paczki w repozytorium (atak na łańcuch dostaw). Opisałem taki przypadek w artykule o ataku na łańcuch dostaw wtyczek WordPress. Dlatego im mniej wtyczek i im bardziej zaufane ich źródło, tym mniejsze ryzyko — a aktualizacje warto wdrażać z krótką zwłoką i po sprawdzeniu, co dana wersja faktycznie zmienia.

Z tego samego powodu opcja „włącz automatyczne aktualizacje” przy każdej wtyczce nie zawsze jest dobrym pomysłem. Wygodnie łata znane dziury, ale jednocześnie potrafi w środku nocy zaciągnąć przejętą wersję, zanim ktokolwiek zdąży ją wychwycić — czyli dokładnie ten scenariusz, w którym auto-aktualizacja sama wpuszcza backdoora na serwer. Rozsądny kompromis to auto-aktualizacje rdzenia i krytycznych łatek bezpieczeństwa, ale ręczna, świadoma kontrola przy wtyczkach, którym ufasz najmniej.

Pełną, praktyczną listę zabezpieczeń WordPressa — od konfiguracji po wtyczki — zebrałem w osobnym przewodniku: jak zabezpieczyć WordPress. Warto też zajrzeć do oficjalnej dokumentacji: Hardening WordPress.

Warto też zadać sobie szczersze pytanie: czy ta strona w ogóle musi być na WordPressie? Jeśli to witryna wizytówkowa albo firmowa, która rzadko się zmienia, to cała powierzchnia ataku — wtyczki, panel, PHP, baza — jest zbędnym ryzykiem. Statyczna strona zbudowana w nowoczesnym stacku (jak ten, na którym stoi spoko.space) nie ma panelu logowania ani bazy do przejęcia, więc ten konkretny atak jest na niej fizycznie niemożliwy. Różnice w bezpieczeństwie i utrzymaniu rozpisałem w porównaniu strony statycznej z aplikacją webową, ale warto mieć je z tyłu głowy przy kolejnym „znowu mnie zhakowali”.

Podsumowanie

Japoński spam SEO jest groźny właśnie dlatego, że jest cichy. Cloaking sprawia, że właściciel widzi czystą stronę, podczas gdy Google indeksuje tysiące japońskich podstron i obniża ranking całej domeny. Klucz do skutecznego sprzątania to zrozumienie, że widoczne strony to objaw, a nie choroba — trzeba usunąć backdoora, fałszywe konto, wpisy w .htaccess oraz ukrytą sitemapę, inaczej spam wróci. A najlepszą obroną pozostaje profilaktyka: aktualizacje, mniej wtyczek, silne hasła i regularne zaglądanie do Google Search Console — bo to ona, a nie Twoja przeglądarka, widzi prawdę o stanie strony.