Zhakowany WordPress? 12 oznak włamania na stronę

Najpewniejsze oznaki, że strona na WordPressie została zhakowana, to konta administratorów, których nikt nie zakładał, pliki PHP tam, gdzie powinny leżeć wyłącznie obrazy, oraz strony ze spamem czy przekierowania, których właściciel nigdy nie widzi na własnym ekranie. Większość tych sygnałów jest celowo dyskretna. Atakującym zależy na tym, żeby strona działała dalej, dlatego ukrywają się przed zalogowanymi administratorami, a swoją zawartość pokazują tylko wyszukiwarkom lub wybranym odwiedzającym.

Poniżej opisujemy 12 oznak, pogrupowanych według miejsca, w którym można je zauważyć, a przy każdej podajemy konkretny sposób sprawdzenia. Część kontroli wykorzystuje WP-CLI, czyli wiersz poleceń WordPressa. Menedżer plików i narzędzie do bazy danych w panelu hostingu również wystarczą, tylko praca potrwa dłużej.

Zhakowany WordPress? Oznaki, które widzą odwiedzający

1. Przekierowania tylko na telefonach lub z Google

Wiele infekcji przekierowuje tylko część ruchu: osoby korzystające z telefonu albo te, które trafiają na stronę z wyszukiwarki Google. Zasady Google dotyczące spamu opisują oba triki: maskowanie (cloaking), czyli pokazywanie wyszukiwarkom innej treści niż ludziom, oraz przekierowywanie użytkowników mobilnych na domenę ze spamem. Kto wpisuje adres własnej strony na komputerze, widzi zwykłą witrynę i niczego nie zauważa.

Jak to sprawdzić: na telefonie, przez mobilną transmisję danych i bez logowania, wyszukać swoją stronę w Google i otworzyć wynik. W terminalu można porównać zwykłe zapytanie z zapytaniem „mobilnego użytkownika z Google”:

curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://example.com/
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' \
  -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)' \
  -e 'https://www.google.com/' https://example.com/

Kod 301 lub 302 kierujący na obcą domenę, który pojawia się wyłącznie w drugim wyniku, to poważny sygnał ostrzegawczy. Przekierowań w JavaScripcie ta metoda nie wychwyci, dlatego warto też przejrzeć źródło strony pod kątem nieznanych skryptów.

2. Ostrzeżenia przeglądarki lub programu antywirusowego

Pełnoekranowe ostrzeżenie przeglądarki, na przykład o witrynie wprowadzającej w błąd („Deceptive site ahead”), albo zgłoszenia klientów, że antywirus blokuje im Państwa stronę, zwykle oznaczają, że domena trafiła już na listę blokowanych z powodu złośliwego oprogramowania lub phishingu. Jak to sprawdzić: wpisać domenę w narzędziu Google Stan witryny w Bezpiecznym przeglądaniu i poprosić o zrzut ekranu z dokładną treścią ostrzeżenia.

Oznaki w wynikach wyszukiwania Google

3. Strony ze spamem w wynikach site:

Wstrzyknięte podstrony o kasynach, lekach czy podróbkach markowych produktów często pojawiają się w Google, zanim ktokolwiek zauważy je gdzie indziej. Jak to sprawdzić: wyszukać site:example.com i przejrzeć wyniki pod kątem tytułów w obcych językach lub tematów, których nigdy nie publikowano. Dodanie słów takich jak casino, viagra czy loan zawęża wyniki.

4. Problemy z bezpieczeństwem w Search Console

Jeśli strona jest zweryfikowana w Google Search Console, warto otworzyć sekcję Security & Manual Actions → Security issues. Google wymienia tam wykryte problemy, takie jak zhakowane treści czy złośliwe oprogramowanie. Jak to sprawdzić: upewnić się, że usługa jest zweryfikowana, a powiadomienia z niej trafiają do osoby, która je faktycznie czyta. Pusty raport to dobra wiadomość, ale nie dowód.

Oznaki na serwerze i koncie hostingowym

5. Zawieszenie konta lub wysokie obciążenie procesora

Firmy hostingowe zawieszają konta, z których wysyłany jest spam, na których działają strony phishingowe albo które przeciążają serwer. Skok obciążenia procesora bez wzrostu ruchu może oznaczać, że na koncie pracuje koparka kryptowalut lub skrypt rozsyłający spam. Jak to sprawdzić: przeczytać wiadomość od dostawcy w całości (często wymienia konkretne pliki) i obejrzeć wykresy zużycia zasobów w panelu. Przy dostępie przez SSH polecenie ps aux --sort=-%cpu | head pokazuje najbardziej obciążające procesy.

6. Wychodzący spam i adres IP na czarnej liście

Jeśli Państwa e-maile zaczynają wracać jako niedoręczone albo przychodzą zwroty wiadomości, których nikt nie wysyłał, możliwe, że jakiś skrypt rozsyła spam przez Państwa serwer. Jak to sprawdzić: zapytać dostawcę hostingu, czy zmieniła się liczba wysyłanych wiadomości, i sprawdzić adres IP serwera w publicznym narzędziu do weryfikacji list blokujących.

7. Pliki PHP w wp-content/uploads

Folder uploads powinien zawierać obrazy i dokumenty, a nie kod. Plik PHP w tym miejscu to często web shell, czyli tylna furtka (backdoor), przez którą atakujący może wykonywać polecenia. Jak to sprawdzić:

find wp-content/uploads -type f \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' \)

Niektóre wtyczki umieszczają w swoich folderach pusty plik index.php, żeby zablokować listowanie katalogów. Każde trafienie trzeba więc otworzyć i sprawdzić, co naprawdę zawiera.

8. Zmodyfikowane pliki rdzenia

Atakujący chętnie ukrywają kod w plikach rdzenia WordPressa, bo nikt ich nie czyta. Jak to sprawdzić: wp core verify-checksums porównuje pliki rdzenia z oficjalnymi sumami kontrolnymi z WordPress.org i ostrzega o każdym pliku, który się z nimi nie zgadza (opis polecenia). wp plugin verify-checksums --all robi to samo dla wtyczek, ale wyłącznie dla tych pobranych z WordPress.org.

9. Nieoczekiwane zmiany w .htaccess lub wp-config.php

Kilka dopisanych linijek w .htaccess wystarczy, by przekierowywać odwiedzających w zależności od strony, z której przyszli, lub od przeglądarki. Jedna linia w wp-config.php albo ustawienie auto_prepend_file w .user.ini potrafi załadować złośliwy kod, zanim WordPress w ogóle wystartuje. Jak to sprawdzić: porównać oba pliki z ostatnią kopią zapasową, co do której wiadomo, że była czysta, a potem poszukać typowych sztuczek z zaciemnianiem kodu i doklejaniem plików (prepend):

grep -rnE --include='*.php' 'eval\(|base64_decode\(|gzinflate\(|str_rot13\(' . | head -50
grep -rn 'auto_prepend_file' --include='.htaccess' --include='.user.ini' --include='php.ini' .

Z niektórych z tych funkcji korzystają także legalne wtyczki, dlatego trafienia należy traktować jako tropy, a nie wyroki.

Oznaki w kokpicie WordPressa

10. Nieznani administratorzy

Nowe konto administratora to klasyczny sposób na utrzymanie dostępu, a niektóre szkodliwe skrypty ukrywają je nawet przed ekranem Użytkownicy. Jak to sprawdzić:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --skip-plugins --skip-themes

Dwie flagi --skip sprawiają, że zwykły kod wtyczek i motywów, łącznie z ukrytym w nim malware, nie może filtrować listy. Wtyczki must-use i wp-config.php nadal się ładują, więc je również trzeba sprawdzić (oznaki 9 i 11). Jeśli WP-CLI pokazuje więcej administratorów niż ekran Użytkownicy, coś ukrywa konto. Warto też przejrzeć profil każdego administratora pod kątem haseł aplikacji (Application Passwords), których nikt z zespołu nie utworzył.

11. Wtyczki, których nikt nie instalował

Podejrzane są wtyczki o ogólnikowych nazwach, bez autora lub opisu, których instalacji nikt w zespole sobie nie przypomina. Wtyczki must-use w wp-content/mu-plugins ładują się automatycznie i łatwo je przeoczyć. Jak to sprawdzić: wp plugin list pokazuje zwykłe wtyczki razem z wtyczkami must-use i plikami drop-in, takimi jak object-cache.php; wp plugin list --status=must-use,dropin pokazuje tylko te dwie ostatnie grupy.

12. Podejrzane zadania cron

Złośliwe oprogramowanie często samo planuje swoje uruchomienia, żeby wrócić po usunięciu. Jak to sprawdzić:

wp cron event list --fields=hook,next_run_relative,recurrence

Każdy hook, którego nie da się powiązać z używaną wtyczką, warto sprawdzić. Znaczenie mają też zadania cron na poziomie serwera: pokazuje je polecenie crontab -l albo sekcja cron w panelu hostingu.

Co zrobić w pierwszej godzinie

Jeśli jedna lub kilka z tych oznak wskazuje na włamanie, najbliższa godzina zdecyduje o tym, ile jeszcze uda się ustalić. Należy działać spokojnie i w tej kolejności:

1. Nie kasować niczego w panice. Usunięcie podejrzanego pliku czy nieznanego administratora niszczy dowody i rzadko usuwa całą infekcję, bo atakujący zwykle zostawiają sobie więcej niż jedną drogę powrotu.
2. Zabezpieczyć dowody. Wykonać pełny snapshot lub kopię zapasową plików i bazy danych w stanie po włamaniu oraz pobrać logi dostępu i błędów serwera WWW, które wielu dostawców przechowuje tylko przez ograniczony czas. Kopię trzymać offline i oznaczyć jako zainfekowaną.
3. Zmienić hasła z czystego urządzenia. Najpierw konto hostingowe, potem SFTP/SSH, baza danych i wszyscy administratorzy WordPressa. Jeśli własny komputer może być zainfekowany, trzeba użyć innego, a każdemu administratorowi włączyć uwierzytelnianie dwuskładnikowe.
4. Skontaktować się z dostawcą hostingu. Ma wgląd w logi serwera, inne strony na tym samym koncie i pocztę wychodzącą, a często potrafi szybko odizolować stronę.
5. Zapisać czas. Zanotować, kiedy po raz pierwszy dowiedzieli się Państwo o włamaniu i co do tej pory zaobserwowano.

Ostatni punkt ma znaczenie dla RODO. Jeśli atakujący mógł dotrzeć do danych klientów, wiadomości z formularzy kontaktowych, kont użytkowników lub zamówień, włamanie jest zazwyczaj naruszeniem ochrony danych osobowych. Art. 33 RODO wymaga zgłoszenia go organowi nadzorczemu (w Polsce Prezesowi UODO) bez zbędnej zwłoki, w miarę możliwości nie później niż w terminie 72 godzin od stwierdzenia naruszenia, chyba że jest mało prawdopodobne, by skutkowało ono ryzykiem naruszenia praw lub wolności osób fizycznych. Jak to ocenić, wyjaśniamy w poradniku o zgłaszaniu naruszeń ochrony danych w ciągu 72 godzin.

Gdy dowody są już bezpieczne, można przejść do naszego planu usuwania malware z WordPressa krok po kroku: odizolować stronę, znaleźć drogę włamania, wyczyścić ją z pomocą zaufanych źródeł i zmienić wszystkie dane dostępowe.

Security Audit & Compliance, wtyczka WordPress od secaudit.eu, sprawdza za Państwa kilka z tych oznak, w tym ukryte konta administratorów, podejrzane zdarzenia cron, sumy kontrolne rdzenia, zmiany plików względem stanu bazowego i ukryty spam SEO. Wtyczka wykrywa i raportuje; usunięcie malware pozostaje zadaniem dla Państwa lub specjalisty.

Najczęściej zadawane pytania

Czy strona może zostać zhakowana bez żadnych widocznych oznak?

Tak. Wiele infekcji zaprojektowano tak, by właściciel ich nie zauważył: pomijają zalogowanych użytkowników, celują wyłącznie w wyszukiwarki albo działają tylko na serwerze. Dlatego opisane wyżej kontrole wykraczają poza obejrzenie strony głównej.

Czy każde włamanie jest naruszeniem ochrony danych w rozumieniu RODO?

Nie każde, ale wiele z nich. Jeśli dane osobowe zostały odczytane, zmienione, utracone lub stały się niedostępne, jest to naruszenie ochrony danych osobowych. Swoją ocenę warto udokumentować niezależnie od wyniku: art. 33 ust. 5 RODO wymaga ewidencjonowania każdego naruszenia, również tych, których się nie zgłasza.

Czy od razu przywrócić wczorajszą kopię zapasową?

Dopiero po zabezpieczeniu zainfekowanego stanu i ustaleniu, mniej więcej kiedy zaczął się atak. Kopia wykonana po włamaniu również zawiera tylną furtkę, a przywrócenie strony bez zamknięcia drogi wejścia pozwoli atakującemu od razu wrócić.

Ten artykuł ma charakter ogólnoinformacyjny i nie stanowi porady prawnej.