Kiedy strona zostaje zhakowana, naturalna reakcja jest prosta: „usuńmy wirusa jak najszybciej”. Problem w tym, że widoczny wirus często jest tylko jednym z efektów włamania. Jeżeli nie sprawdzimy, którędy ktoś wszedł i co jeszcze zmienił, strona może wyglądać dobrze przez kilka godzin, a potem infekcja wróci.

Dlatego traktuję naprawę po włamaniu jak proces. Najpierw zabezpieczam stan strony, potem ograniczam dalsze szkody, następnie szukam źródła problemu i dopiero wtedy przechodzę do czyszczenia i zabezpieczeń.

Jak rozpoznać, że WordPress mógł zostać zhakowany?

Włamanie nie zawsze oznacza wielki czerwony komunikat na ekranie. Czasem strona działa pozornie normalnie, ale w tle powstają spamowe podstrony, pojawiają się nowe konta administratorów albo użytkownicy z Google są przekierowywani na obce domeny.

• WordPress przekierowuje na reklamy lub podejrzane strony,
• Google pokazuje ostrzeżenie o niebezpiecznej witrynie,
• hosting blokuje konto albo informuje o malware,
• pojawiają się nieznane konta administratorów,
• w plikach są dziwne skrypty PHP lub JavaScript,
• strona nagle zwalnia lub generuje nietypowe błędy,
• w Google pojawiają się podstrony, których nie ma w panelu WordPressa,
• problem wraca po wcześniejszym czyszczeniu.

Krok 1: zrób kopię obecnego stanu

Nawet jeżeli wiesz, że strona jest zainfekowana, kopia plików i bazy danych jest bardzo cenna. Pozwala później porównywać zmiany, sprawdzać daty modyfikacji i wrócić do elementów, które podczas analizy okażą się ważne.

Nie traktowałbym automatycznego backupu sprzed pięciu minut jako jedynej kopii. Jeżeli infekcja trwa od tygodnia, taki backup może zawierać ten sam problem. Dobrze jest zachować także aktualny stan do celów diagnostycznych.

Krok 2: ogranicz dalszy dostęp

Jeżeli podejrzewasz przejęcie panelu lub hostingu, trzeba założyć, że dotychczasowe dane dostępowe mogą nie być bezpieczne. Zmieniam hasła do panelu, hostingu, FTP/SFTP i poczty używanej do resetowania hasła, a następnie sprawdzam listę użytkowników WordPressa.

Nieznane konto administratora to bardzo mocny sygnał alarmowy. Samo jego usunięcie nie kończy sprawy, ale odcina jedną z możliwych dróg powrotu.

Krok 3: sprawdź pliki WordPressa, motyw i wtyczki

Najpierw porównuję pliki rdzenia WordPressa z prawidłową wersją, a później przechodzę do wp-content, aktywnego motywu i wtyczek. Szczególną uwagę zwracam na pliki PHP w nietypowych miejscach, fragmenty kodu mocno zaciemnione, dynamiczne pobieranie treści z zewnętrznych domen oraz pliki, które nie należą do żadnego znanego komponentu.

Nie kasuję wszystkiego, co wygląda „dziwnie”. W zaawansowanych instalacjach legalny kod też może być nietypowy. Ważne jest porównanie go z oryginałem i zrozumienie, do czego służy.

Krok 4: sprawdź bazę danych

Malware może siedzieć nie tylko w plikach. Złośliwy JavaScript bywa wstrzyknięty do treści wpisów, widgetów, opcji motywu, ustawień wtyczek albo innych pól w bazie danych. Dlatego podmiana plików na czyste nie zawsze rozwiązuje problem.

W bazie sprawdzam też nieznane konta, podejrzane opcje autoload, zadania CRON i elementy, które mogą odtwarzać usunięty kod.

Krok 5: znajdź backdoor i przyczynę włamania

To jest moment, w którym wiele „szybkich napraw” się kończy, a nie powinno. Jeżeli zostanie choć jeden backdoor albo podatna wtyczka, problem może wrócić.

Źródłem włamania może być nieaktualna wtyczka, porzucony motyw, słabe lub przejęte hasło, stary staging, zapomniana instalacja WordPressa w podkatalogu, błędne uprawnienia plików albo problem na tym samym koncie hostingowym.

Krok 6: zaktualizuj i zabezpiecz WordPressa

Po usunięciu złośliwego kodu aktualizuję WordPressa, motyw i wtyczki, usuwam rozszerzenia, które nie są potrzebne, kontroluję konta administratorów i zmieniam klucze bezpieczeństwa. Tam, gdzie ma to sens, dokładam dodatkowe zabezpieczenia logowania i monitoring zmian w plikach.

Nie chodzi o zainstalowanie jak największej liczby „security pluginów”. Chodzi o ograniczenie powierzchni ataku i zamknięcie konkretnej luki, przez którą doszło do problemu.

Krok 7: sprawdź skutki w Google i hostingu

Infekcja może zostawić ślady nawet po oczyszczeniu strony. W Google mogą znajdować się spamowe adresy URL, a hosting lub przeglądarka może nadal wyświetlać ostrzeżenie bezpieczeństwa.

Po czyszczeniu warto sprawdzić Google Search Console, mapę witryny, indeksację oraz komunikaty bezpieczeństwa. Jeżeli witryna została oznaczona jako niebezpieczna, po naprawie można przygotować ją do ponownej weryfikacji.

A jeśli zhakowany został sklep WooCommerce?

W WooCommerce trzeba zachować szczególną ostrożność, ponieważ baza danych zmienia się w trakcie działania sklepu. Pojawiają się nowe zamówienia, statusy płatności, konta klientów i dane sprzedażowe. Przywrócenie starej kopii „na ślepo” może usunąć prawidłowe transakcje wykonane już po utworzeniu backupu.

Dlatego dla sklepów przygotowaliśmy osobną usługę usuwania wirusów WooCommerce, która uwzględnia ciągłość sprzedaży i ochronę aktualnych danych.

Czego nie robić po włamaniu?

• nie kasować losowo plików bez kopii,
• nie przywracać starego backupu bez ustalenia przyczyny,
• nie zakładać, że jeden skaner znalazł wszystko,
• nie zostawiać tych samych haseł po incydencie,
• nie aktualizować wszystkiego w ciemno na jedynej kopii produkcyjnej,
• nie ignorować spamowych adresów, które mogły trafić do Google.

Czy zhakowany WordPress można naprawić samemu?

Jeżeli masz doświadczenie z plikami WordPressa, bazą danych, hostingiem i potrafisz odróżnić legalny kod od złośliwego, część przypadków można naprawić samodzielnie. Jeżeli jednak strona generuje sprzedaż, ma wielu użytkowników, infekcja wraca albo nie wiesz, gdzie znajduje się źródło problemu, eksperymentowanie na produkcji może kosztować więcej niż samo czyszczenie.

Jeżeli potrzebujesz pomocy, zobacz usługę usuwania wirusów WordPress. Zaczynamy od diagnozy i kopii, a dopiero później ustalamy zakres prac.

Najczęstsze pytania