Telefon o siódmej rano, w słuchawce właściciel sklepu: strona przekierowuje na jakieś kasyno, ale tylko z Google, bo po wpisaniu adresu wszystko wygląda normalnie. Klasyka. Zhakowany WordPress rzadko wygląda spektakularnie. Zwykle działa cicho i wychodzi na jaw przypadkiem, przez skargę klienta albo ostrzeżenie w wynikach wyszukiwania. To, co zrobisz w kolejnych dwóch godzinach, decyduje o tym, czy sprawa skończy się w jeden dzień, czy będzie wracać przez kwartał.
Spis treści
Pierwsze piętnaście minut: zatrzymaj szkodę, nie kasuj dowodów
Odruch jest zawsze ten sam: znaleźć dziwne pliki i je usunąć. No i tu się zaczyna problem, bo kasując je, niszczysz jedyny materiał, z którego da się później odtworzyć wektor wejścia. Bez daty modyfikacji i bez treści wgranego skryptu zostajesz ze zgadywaniem.
Kolejność, która działa: najpierw odetnij ruch, trybem konserwacji albo regułą na serwerze WWW. Potem snapshot całego katalogu i zrzut bazy w stanie zainfekowanym. Dopiero wtedy zaczynaj sprzątać, czy to samodzielnie, czy zlecając usuwanie wirusów ze strony komuś, kto robi to na co dzień.
Snapshot musi wylądować poza serwerem produkcyjnym. Archiwum położone obok wp-content ginie razem z resztą przy odtworzeniu albo, co gorsza, samo zostaje przeczytane przez napastnika. Haseł nie zmieniaj, zanim nie zabezpieczysz logów – ktoś z aktywną sesją i tak siedzi w środku, a ty stracisz zapisy, których serwer nie trzyma w nieskończoność.
Ustal, co to za infekcja: trzy typowe scenariusze
Pierwszy wariant to spam SEO żyjący w bazie. Przekierowania odpalają się tylko dla Googlebota albo dla ruchu przychodzącego z wyszukiwarki, ukryte odnośniki siedzą w wp_options i wp_posts, a właściciel przeglądający własną stronę nie widzi niczego. Stąd te zgłoszenia od klientów, nie od redakcji.
Drugi to backdoor w plikach: kod dopisany na końcu wp-config.php, podrzucony plik udający element wp-includes, pojedynczy skrypt PHP w katalogu uploads, gdzie żaden PHP nie ma prawa być. Trzeci scenariusz jest najprostszy i najczęściej lekceważony – przejęte konto administratora albo świeżo dopisany użytkownik z tą rolą, zwykle z adresem e-mail w obcej domenie.
Mylące bywają objawy hostingowe. Nagły skok transferu i zapchana kolejka poczty to zwykle nie awaria serwera, tylko twoja witryna rozsyłająca spam. Sprawdź to, zanim rozmowa zejdzie na utrzymanie serwisów WWW i przenosiny na mocniejszy pakiet.
Godzina pierwsza: dowody z logów i bazy
Logi dostępu zestawione z datami modyfikacji plików potrafią zawęzić moment wejścia do kilku minut. Szukasz żądań POST kierowanych do plików w uploads albo do nietypowo nazwanych skryptów w katalogu wtyczek. To najczęstszy pierwszy trop i zwykle prowadzi prosto do podatnego komponentu.
W bazie sprawdzasz kilka miejsc w ustalonej kolejności, od najbardziej prawdopodobnego:
- wp_users i wp_usermeta – lista kont, daty rejestracji, przypisane role, zwłaszcza wpisy dodane po dacie z logów.
- wp_options z autoload = yes – tam ląduje kod uruchamiany przy każdym żądaniu, często zakodowany base64.
- Zaplanowane zadania cron – wpis odtwarzający backdoora po każdym sprzątaniu.
- wp_posts i wp_postmeta – wstrzyknięte odnośniki, ukryte bloki, podmienione treści starych wpisów.
- Klucze API i dane integracji – wszystko, co dało się wyeksportować, uznaj za wyniesione.
Godzina druga: czyszczenie kontra odtworzenie z backupu
Ręczne czyszczenie ma sens wyłącznie wtedy, gdy znasz moment wejścia i masz czysty punkt odniesienia: oryginalne pliki rdzenia i wtyczek do porównania bajt po bajcie. Bez tego przeglądasz kilkanaście tysięcy plików wzrokiem i przegapiasz jedną linijkę. Zawsze tę jedną.
Backup sprzed infekcji też bywa pułapką. Jeśli backdoor siedział na serwerze tygodniami, a kopia ma retencję kilku dni, odtwarzasz witrynę razem z problemem i po dwóch dniach wracasz do punktu wyjścia.
Przy niepewności bezpieczniejsza jest odbudowa: świeża instalacja rdzenia i wtyczek z oficjalnych źródeł, przeniesienie wyłącznie treści, mediów i zweryfikowanego kodu motywu potomnego. Motywy i wtyczki z podejrzanych źródeł, łącznie z „odblokowanymi” wersjami premium, trafiają na listę do wyrzucenia, nie do naprawy. Były wektorem wystarczająco często, żeby nie było o czym dyskutować.
Zamknięcie wektora, czyli dlaczego strona hakuje się drugi raz
Nawrót po kilku dniach prawie zawsze znaczy jedno: posprzątano skutek, przyczyna została. Typowe niedomknięte drzwi? Nieaktualizowana wtyczka z publicznie dostępnym exploitem, konto FTP współdzielone przez trzy firmy, hasło z dawnego wycieku użyte ponownie albo klucz API zapomniany w repozytorium.
Rotacja sekretów obejmuje wszystko naraz: hasła użytkowników, hasło bazy, klucze soli w wp-config.php, hasła aplikacji do REST API, dostępy do panelu hostingu. Połowiczna wymiana daje złudzenie porządku.
Jeśli na tym samym koncie hostingowym stoją inne serwisy, sprawdzasz je razem z zaatakowanym. Infekcja przechodzi między katalogami w obrębie konta i wraca z sąsiedniej strony, o której nikt już nie pamiętał. Przy okazji takiego audytu często wychodzi, że część serwisów kwalifikuje się raczej do modernizacji starej aplikacji niż do kolejnego łatania.
Skutki poza serwerem: Google, poczta, dane osobowe
Search Console pokazuje ostrzeżenie o zabezpieczeniach i pozwala zgłosić stronę do ponownego sprawdzenia po wyczyszczeniu. Zgłoszenie przed faktycznym usunięciem infekcji tylko wydłuża sprawę, bo weryfikacja kończy się odrzuceniem.
Domena, z której wyszedł spam mailowy, trafia na listy blokujące i wymaga osobnej obsługi. Stan witryny nie ma tu już znaczenia, delisting prowadzi się równolegle. A jeśli sklep lub formularze przetwarzały dane osobowe, incydent ma wymiar formalny i ktoś musi ocenić obowiązek zgłoszenia. Najlepiej tego samego dnia.
Zostaje komunikacja. Klienci i partnerzy dowiadują się szybciej, niż zakłada właściciel, zwykle od własnej przeglądarki albo z ostrzeżenia w wynikach. Krótka, konkretna informacja własnymi słowami znosi połowę pytań. Cisza generuje resztę.
Co zrobić, żeby nie zaczynać od zera przy kolejnym incydencie
Hosting z kopiami zapasowymi trzymanymi poza serwerem produkcyjnym, z retencją liczoną w tygodniach, nie w dniach, i z odtworzeniem testowanym regularnie. Kopia, której nikt nigdy nie przywracał, to hipoteza, nie zabezpieczenie.
Aktualizacje wtyczek działają, gdy są procesem: środowisko testowe, przegląd zmian, wdrożenie w ustalonym rytmie. Zrywy raz na kwartał kończą się skokiem przez dwadzieścia wersji naraz i rozjechanym układem strony, więc nikt ich potem nie powtarza.
Reszta to zwykła higiena dostępów: osobne konta zamiast jednego wspólnego, dwuskładnikowe logowanie do panelu i hostingu, zablokowane wykonywanie PHP w katalogu uploads. Monitoring integralności plików i alert o zmianie liczby administratorów skracają wykrycie z tygodni do godzin, a to zwykle przesądza o skali sprzątania.
Podsumowanie
Pierwsze dwie godziny rozstrzygają, czy incydent zamknie się jednorazowym czyszczeniem, czy zamieni w miesiące nawrotów. Kolejność jest niezmienna: odciąć, zabezpieczyć dowody, ustalić wektor, dopiero potem odtwarzać.
Zhakowany WordPress to zwykle objaw zaniedbanego utrzymania, nie pech. Nieaktualizowany serwis z dwoma wtyczkami spoza oficjalnego katalogu i jednym hasłem dzielonym przez cały zespół prędzej czy później znajdzie swojego napastnika. Zespołowi, który sam pilnuje strony, dużo daje przejście przez szkolenia z WordPressa obejmujące aktualizacje i zarządzanie dostępami.
Jeśli potrzebujesz kogoś, kto przejdzie przez taki incydent od strony technicznej albo przejmie utrzymanie serwisu na stałe, odezwij się do nas. Zajmujemy się też audytami, integracjami, automatyzacją i modernizacją aplikacji, które przerosły swój pierwotny projekt.
