Strona główna  /  Bezpieczeństwo  /  Jak sprawdzić, czy WordPress jest zainfekowany?

Cyfrowa tarcza chroniąca serwer oraz lupa analizująca kod, symbolizujące proces wykrywania infekcji w WordPressie.

Jak sprawdzić, czy WordPress jest zainfekowany?

Infekcja WordPressa nie zawsze powoduje awarię strony. Najczęściej potwierdza się ją dopiero po połączeniu obserwacji zachowania witryny z analizą plików, użytkowników, logów i bazy danych. Zanim usuniesz jakikolwiek plik, wykonaj pełną kopię zapasową.

Po czym poznać, że WordPress jest zainfekowany?

Złośliwy kod może działać tylko w określonych warunkach, dlatego strona otwierana przez administratora nie zawsze wygląda podejrzanie. Przekierowanie może pojawiać się wyłącznie na telefonie, po wejściu z Google albo dla niezalogowanych użytkowników. Właśnie dlatego warto sprawdzić witrynę w trybie incognito, na innym urządzeniu i z innego połączenia internetowego.

Sygnały ostrzegawcze, które wymagają dalszej diagnostyki, to:

  • przekierowania na obce strony, fałszywe formularze logowania lub podejrzane reklamy,
  • dziwne tytuły, chińskie znaki i obce frazy w wynikach Google,
  • podstrony o hazardzie, lekach, kryptowalutach lub podróbkach, których nie tworzono,
  • nieznane konta użytkowników, szczególnie z rolą administratora,
  • nowe pliki PHP w katalogu wp-content/uploads, zmiany w .htaccess lub wp-config.php,
  • ostrzeżenie hostingu, przeglądarki albo Google o malware,
  • nagły wzrost obciążenia serwera, masowa wysyłka poczty lub powracające pliki po ich usunięciu.

Spam SEO polega na dodawaniu obcych treści i linków w celu manipulowania wynikami wyszukiwania. Odmianą takiego ataku może być cloaking, czyli pokazywanie innej wersji strony robotom Google niż zwykłym odwiedzającym. Wpisz w wyszukiwarce operator site:twojadomena.pl i sprawdź, czy w indeksie nie ma adresów, których nie rozpoznajesz. Zajrzyj też do Google Search Console, zwłaszcza do raportu dotyczącego problemów z bezpieczeństwem.

Jak technicznie sprawdzić WordPressa?

Jedno narzędzie nie daje pewności, że instalacja jest czysta. Skaner może wykryć znany wzorzec malware, ale nie zauważyć kodu w bazie danych, motywie albo zadaniu CRON. Najlepszy rezultat daje porównanie kilku niezależnych źródeł:

Narzędzie lub miejsce Co pozwala sprawdzić Ograniczenie
Google Search Console Ostrzeżenia dotyczące malware, phishingu i przejętych podstron Brak ostrzeżenia nie wyklucza infekcji
Logi serwera Nietypowe żądania, błędy PHP, próby logowania i uruchamianie skryptów Wymagają dostępu do hostingu i interpretacji wpisów
WP-CLI Zgodność plików rdzenia i wybranych wtyczek z oficjalnymi sumami kontrolnymi Nie sprawdza całej bazy danych, motywów ani plików autorskich
SFTP lub menedżer plików Nazwy, daty modyfikacji, rozmiary i zawartość plików Nietypowy plik nie zawsze jest złośliwy
Skaner hostingu lub wtyczka bezpieczeństwa Znane wzorce malware i zmiany w plikach Może pomijać ukryty kod i generować fałszywe alarmy

Jeśli masz dostęp do konsoli, sprawdź pliki rdzenia poleceniem:

wp core verify-checksums

Dla wtyczek z oficjalnego repozytorium można użyć:

wp plugin verify-checksums --all

Nieprawidłowa suma oznacza różnicę względem wersji referencyjnej, ale sama w sobie nie potwierdza włamania. Plik mógł zostać legalnie zmodyfikowany przez programistę. Z kolei poprawne sumy rdzenia nie wykluczają infekcji w bazie danych, motywie, katalogu uploads ani w autorskiej wtyczce.

W logach szukaj między innymi powtarzających się żądań do nieznanych plików PHP, prób zapisu w katalogu uploadów, błędów uruchamiania skryptów oraz aktywności w czasie, gdy nikt nie pracował w panelu. Sprawdź także zadania CRON skonfigurowane w WordPressie i na hostingu. Nieznane zadanie może odtwarzać usunięte pliki.

Infekcja czy błąd techniczny?

Wolne działanie strony nie musi oznaczać malware. Przyczyną może być przeciążony hosting, problem z bazą danych, wadliwa wtyczka albo nieoptymalna konfiguracja. Błąd 500 często pojawia się po nieudanej aktualizacji, błędzie PHP lub zmianie ustawień serwera.

Duża liczba nieudanych logowań świadczy o próbach ataku, ale nie dowodzi, że ktoś uzyskał dostęp. Podobnie zmodyfikowany plik może być rezultatem aktualizacji lub legalnej pracy programisty. Nie usuwaj więc plików tylko dlatego, że wskazał je automatyczny skaner. Najmocniejszym sygnałem jest kilka zgodnych oznak, na przykład nieznany administrator, spam w Google, podejrzane żądania w logach i pliki odtworzone po usunięciu.

Co zrobić po potwierdzeniu infekcji?

Nie rozpoczynaj czyszczenia bez zachowania obecnego stanu strony. Nawet zainfekowana kopia może być potrzebna do analizy, odzyskania danych albo ustalenia momentu włamania. Przed usuwaniem wykonaj kopię plików i bazy danych, najlepiej poza serwerem produkcyjnym. Zachowaj także logi oraz wiadomości od hostingu.

Bezpieczna kolejność działań wygląda następująco:

  1. Wykonaj kopię zapasową – pobierz pliki i eksport bazy danych, nie nadpisuj starszych kopii.
  2. Ogranicz dostęp – w razie przekierowań, phishingu lub zagrożenia dla odwiedzających włącz tryb konserwacyjny albo skonsultuj blokadę strony z hostingiem.
  3. Ustal źródło problemu – sprawdź historię zmian, logi, aktualizacje, konta użytkowników, CRON, bazę danych i pozostałe strony na tym samym koncie.
  4. Oczyść instalację – przywróć pliki rdzenia z zaufanego źródła, zweryfikuj motywy i wtyczki oraz przeanalizuj bazę danych. Nie usuwaj kodu bez potwierdzenia, co robi.
  5. Zmień dane dostępowe – obejmij zmianą hasła WordPress, hosting, SFTP lub FTP, bazę danych i konta użytkowników mających dostęp do zaplecza.
  6. Zaktualizuj i obserwuj stronę – zainstaluj poprawki, usuń nieużywane rozszerzenia, sprawdź ponownie logi i Search Console.

Backdoor to ukryty mechanizm, który pozwala napastnikowi wrócić na stronę po usunięciu widocznych objawów. Dlatego samo skasowanie jednego pliku, nieznanego administratora albo spamowych podstron może nie rozwiązać problemu. Jeśli infekcja powraca, trzeba szukać także w bazie danych, zadaniach CRON, kontach hostingowych i innych witrynach na tym samym serwerze.

Przed rozpoczęciem pracy sprawdź poniższe elementy:

  • mam kopię plików oraz bazy danych wykonaną przed czyszczeniem,
  • zapisałem komunikaty hostingu i odpowiednie fragmenty logów,
  • sprawdziłem administratorów, konta SFTP lub FTP oraz dostęp do hostingu,
  • zweryfikowałem motyw, wtyczki, katalog uploads, bazę danych i zadania CRON,
  • wiem, w jaki sposób przywrócę stronę, jeśli czyszczenie spowoduje awarię.

W przypadku sklepu internetowego, powracającej infekcji, podejrzenia kradzieży danych albo braku dostępu do logów lepiej zlecić analizę administratorowi serwera lub specjaliście od bezpieczeństwa. Własnoręczne usuwanie plików bez kopii może utrudnić późniejsze ustalenie źródła włamania i doprowadzić do utraty danych.

Po oczyszczeniu włącz uwierzytelnianie 2FA dla kont administracyjnych, ogranicz liczbę administratorów, aktualizuj WordPressa, motywy i wtyczki oraz przechowuj kopie poza serwerem. Jeżeli Google wyświetla ostrzeżenie, najpierw potwierdź usunięcie infekcji, a następnie zgłoś witrynę do ponownej weryfikacji w Google Search Console.

Redakcja wpinternals.pl

WordPressa znamy od kuchni – budujemy na nim strony, migrujemy serwisy i optymalizujemy ich wydajność. Piszemy o wtyczkach, motywach, hostingu i bezpieczeństwie tak, by poradzili sobie także początkujący. Dbamy o to, by Twoja strona była szybka, stabilna i bezpieczna.

Może Cię również zainteresować

Potrzebujesz więcej informacji?