Ostatnia aktualizacja: 18.03.2024 – 16:00 CEST
Uwaga: Poniższy artykuł opisuje prosty przypadek zainfekowanej strony WordPress. To nie uniwersalne podejście ani najlepsza metoda radzenia sobie z tego typu infekcją — niektóre kroki, np. sprawdzenie bazy danych, zostały tutaj pominięte. Na końcu artykułu znajdują się źródła do dalszej lektury. Nie gwarantuję, że opisane niżej kroki pomogą w każdej sytuacji.
TABLE OF CONTENTS
Odkrycie włamania
Przypadek 1 – zainfekowane pliki WordPress (Front End)
Kilka dni temu zgłosił się znajomy, którego strona grafpoint.net przestała działać bez wyraźnego powodu. Na początku myślałem, że to zwykły problem z aktualizacją i spróbowałem przełączyć debugowanie – bez efektu. Dopiero na telefonie zauważyłem, że w niektórych przypadkach zamiast strony pojawiał się dziwny chiński tekst i reklamy torebek. Okazało się, że strona działała prawidłowo tylko wtedy, gdy przeglądarka nie korzystała z żadnych filtrów – coś ewidentnie było nie tak.
-
- Błąd 500
-
- Zhakowany Ekran Mobilka
Przypadek 2 – złośliwy kod w bazie danych
W grudniu 2023 roku inny znajomy zgłosił, że jego strona zawszenawakacjach.pl przekierowuje mobilnych użytkowników na podejrzane strony. Po analizie odkryłem, że winny jest Balada Injector, co potwierdziły wpisy na blogu Sucuri.
Potencjalny Wirus w Kodzie strony
Odkrycia na zapleczu (Back End – pliki)
Zalogowałem się przez FTP i znalazłem podejrzane pliki i foldery, m.in. o losowych, niezrozumiałych nazwach („26sos5p7”, „FoxEx-v1” i inne). Te pliki sugerowały ingerencję z zewnątrz i wymagały natychmiastowego usunięcia (bez pobierania na lokalny komputer).
-
- Podejrzane katalogi
-
- Podejrzane pliki
Ręczne usuwanie
Na pierwszej stronie wyczyściłem wszystkie podejrzane pliki. Były jednak pliki, których nie dało się usunąć – sprawdziłem logi i usunąłem je ręcznie. Gdy strona nadal nie działała, okazało się, że zostały zmodyfikowane pliki rdzenia WordPressa – zdecydowałem się więc je nadpisać najnowszymi wersjami.
Na drugiej stronie infekcji nie było w plikach, ale znalazłem złośliwy wpis w tabeli wp_options bazy danych. Usunięcie go (np. przez phpMyAdmin) naprawiło przekierowania.
phpMyAdmin ma świetne narzędzie do wykonywania prostych operacji na bazach danych
Tymczasowe działania “na już”
- Nadpisałem pliki rdzenia WordPressa przez FTP.
- Utworzyłem nową, czystą instalację WP w tym samym folderze z nową bazą danych – co pozwoliło zalogować się do pulpitu i bezpiecznie zaktualizować wtyczki.
- Włączyłem tryb konserwacji, by użytkownicy nie widzieli “zainfekowanej” strony.
- To opóźniło efekt, zapobiegło karze od Google i zyskałem czas na dalsze czyszczenie.
Info o problemach technicznych
Sprzątanie i wzmacnianie bezpieczeństwa
Po tym etapie:
- Zaktualizowałem wszystko, co się da.
- Użyłem wtyczek: Sucuri Security, Malcare i iThemes Security, by usunąć resztki infekcji i wzmocnić zabezpieczenia.
- Ostatecznie przełączyłem stronę, by korzystała z oryginalnej bazy danych – i okazało się, że działa!
Dodatkowo:
- Powiadomiłem hosting o włamaniu i poprosiłem o dokładniejsze sprawdzenie serwera.
- Zgłosiłem klientowi dalsze kroki dla lepszej ochrony.
Na drugiej stronie (z przekierowaniami) wystarczyło usunąć złośliwy wpis z bazy i zaktualizować wszystko.
Wnioski i zalecenia
Z waleniem się zainfekowaną stroną WP nie ma żartów — czasem nawet skanery zawodzą. Oto podstawowe środki prewencyjne:
- Zawsze aktualizuj WordPress i wtyczki.
- Włącz dwuetapowe logowanie (2FA).
- Używaj wtyczki ograniczającej próby logowania.
- Stosuj silne hasła.
- Regularnie sprawdzaj stronę (pomimo niewystarczających skanerów).
- Korzystaj z aktualnej wersji PHP.
- Weryfikuj stronę suw. Sucuri Site Check.
Jeśli potrzebujesz pomocy ze zhakowaną stroną — zapraszam do kontaktu przez stronę lub bezpośrednio na Codeable.
🧾 Dalsza lektura:
