Podmieniona strona główna, przekierowania na obce serwisy, ostrzeżenie w Google, zablokowane konto u hostingodawcy. Usuwamy złośliwy kod z plików i z bazy danych, przywracamy rdzeń WordPressa z sum kontrolnych, zamykamy wejście, przez które weszli — i przekazujemy raport z listą każdego znalezionego pliku. Złośliwy kod na stronie nie leży bezczynnie — pracuje na koszt Twojej domeny. Jeśli rozpoznajesz choć jeden z poniższych objawów, liczy się każda godzina. W wynikach pojawia się „Ta witryna może być zhakowana", a przeglądarka wyświetla czerwony ekran ostrzeżenia. Ruch spada niemal do zera w ciągu godzin. Automat hostingodawcy wykrył złośliwą treść i wyłączył stronę. Bez wyczyszczenia serwera i zgłoszenia z wykazem prac nie zdejmie blokady. Zamiast Twojej oferty ładuje się obca strona — najczęściej hazard, apteka albo kryptowaluty, zwykle w obcym języku. Dla Twojej domeny Google pokazuje podstrony z japońskimi lub chińskimi znakami i linkami do sklepów, których nie prowadzisz. Na liście użytkowników pojawiają się obce konta — albo, co gorsza, konta istnieją w bazie, ale są przed Tobą ukryte. Na komputerze strona wygląda normalnie, ale wejście z telefonu albo z wyników Google przerzuca użytkownika na obcą domenę. Uwaga na pozorny spokój. Najczęstszy scenariusz, jaki widzimy: infekcja siedzi na serwerze kilka dni i nic nie zdradza jej obecności, aż do momentu, w którym atakujący podmienia stronę główną albo hosting blokuje konto. Jeśli w logach albo na liście plików widzisz coś, czego nie umiesz wyjaśnić — lepiej sprawdzić od razu, niż tłumaczyć klientom, dlaczego ich dane trafiły w obce ręce. Ataki na WordPressa są zautomatyzowane. Boty non stop skanują internet w poszukiwaniu znanych podatności i nie interesuje ich, czy prowadzisz sklep za milion, czy stronę wizytówkę. Schemat jest niemal zawsze ten sam. Najczęściej podatność pozwalająca wgrać plik przez formularz albo wykonać kod bez logowania. Nikt nie musi znać Twojego hasła — wystarczy komponent, którego nikt nie aktualizował od kilku miesięcy. Wgrany plik PHP, który daje atakującemu menedżer plików i konsolę systemową wprost w przeglądarce. Bywa ukryty pod nazwą przypominającą plik WordPressa albo pod rozszerzeniem graficznym — w jednym z naszych przypadków webshell udawał plik .png w katalogu popularnej wtyczki. Konta administratora ukryte przed listą użytkowników, pliki w katalogu mu-plugins ładowane automatycznie przez WordPressa, keylogger przechwytujący hasło przy logowaniu, wpisy w bazie danych. Wszystko po to, żeby wrócić po Twoim „posprzątaniu". Dlatego usunięcie jednego podejrzanego pliku niczego nie kończy. Oto realna chronologia z naszych prac — od pierwszego webshella do blokady konta minęły niecałe trzy dni:
① luka we wtyczce do wysyłania plików → ② webshelle w katalogu uploads → ③ nowe konto administratora → ④ cztery pliki w mu-plugins (w tym keylogger hasła admina i trzy ukrywające fałszywe konta) → ⑤ podmieniona strona główna → ⑥ automatyczna blokada konta przez hostingodawcę.
Czyszczenie musi objąć wszystkie warstwy naraz — pliki, rdzeń, katalog mu-plugins, bazę danych i konta. Inaczej infekcja wraca w ciągu kilku godzin, tą samą drogą. Kompletne czyszczenie od backupu po skan kontrolny. Nie odhaczamy „przeskanowano wtyczką" — przechodzimy każdą warstwę, w której infekcja potrafi się schować. Pełna kopia plików i bazy, zanim cokolwiek ruszymy. Zawsze jest do czego wrócić. Ustalamy, kiedy i przez co weszli. Bez tego zamykasz drzwi, zostawiając otwarte okno. Szukamy sygnatur złośliwego kodu, nie tylko świeżych dat modyfikacji — także w plikach .png, .jpg, .ico, .css i .js. Czyste pliki z wordpress.org i weryfikacja sum kontrolnych, bez dotykania wp-config.php i katalogu uploads. Usuwamy pliki ładowane automatycznie, podrobione wtyczki i pozostałości po komponentach, których już nie ma. Fałszywe konta admina, wstrzyknięcia w treściach, wpisy po złośliwych wtyczkach, osierocone zadania cron. Nowe hasła, nowe klucze salt, unieważnienie wszystkich sesji. Wykradzione hasło przestaje działać. Aktualizacja lub usunięcie podatnego komponentu, blokada wykonywania PHP w uploads, blokada xmlrpc.php. Hasła do bazy i klucze przenosimy poza katalog publiczny, żeby wyciek jednego pliku nie oddawał całej instalacji. Dokument z listą znalezionych plików i wykonanych działań oraz powtórny audyt po kilku dniach. Kolejność nie jest przypadkowa. Najpierw zabezpieczamy stan obecny, potem szukamy przyczyny, a dopiero na końcu sprzątamy — bo czyszczenie bez znalezienia wejścia to praca na jeden dzień. Bierzemy dostęp SSH lub FTP oraz do panelu. Robimy pełny backup i wstępne rozpoznanie skali infekcji. Logi serwera i daty plików. Ustalamy, przez co i kiedy weszli oraz co zdążyli zrobić na serwerze. Pliki, rdzeń, mu-plugins, baza danych, konta. Skanujemy po zawartości, aż kolejne przejście nie zwraca nic. Zamknięcie luki, rotacja haseł i kluczy salt, blokady wykonywania PHP i xmlrpc, dane wrażliwe poza webrootem. Dokumentacja prac plus powtórny audyt po kilku dniach, żeby potwierdzić, że nic nie wróciło. Po każdym etapie dostajesz informację, co zostało zrobione i co wyszło — nie musisz pytać, na czym stoimy. Zgłoszenie przyszło już po fakcie: hostingodawca zablokował konto, bo na serwerze wykryto złośliwą treść. Poniżej realna chronologia — najpierw ataku, potem prac naprawczych. Nazwa klienta i domena — do udostępnienia po jego zgodzie. Liczby i przebieg pochodzą z rzeczywistych raportów z tych prac. Wyczyszczenie serwera to połowa roboty. Druga połowa to odkręcenie tego, co infekcja zrobiła z widocznością Twojej domeny i z relacją z hostingodawcą. Sprawdzamy zgłoszenia bezpieczeństwa oraz — co często umyka — czy atakujący nie dodał własnej weryfikacji Twojej domeny w narzędziach Google. Taki kod znaleźliśmy w realnym przypadku, w podmienionej stronie głównej. Nieautoryzowany dostęp usuwamy. Po wyczyszczeniu składamy w Search Console zgłoszenie do sprawdzenia. Ostrzeżenie „Ta witryna może być zhakowana" i czerwony ekran w przeglądarce znikają zwykle w ciągu kilku dni od zatwierdzenia. Sprawdzamy, ile wstrzykniętych adresów Google zdążył zaindeksować (m.in. typowy japoński spam SEO) i wnioskujemy o ponowne zindeksowanie czystych wersji, żeby obce treści wypadły z wyników. Przygotowujemy zgłoszenie z wykazem usuniętych plików i wdrożonych zabezpieczeń — hostingodawcy zdejmują blokadę właśnie na podstawie takiego opisu, nie samego zapewnienia, że „już jest dobrze". Dlaczego liczy się czas: dopóki strona jest zainfekowana, wyszukiwarka indeksuje kolejne obce podstrony, a hostingodawca zbiera kolejne zgłoszenia. Każdy dzień zwłoki to więcej adresów do wyczyszczenia z indeksu i dłuższy powrót do dawnych pozycji. Samo czyszczenie serwera trwa tyle samo w poniedziałek i w piątek — różnica jest w tym, co zostaje po infekcji w Google. Cenę podajemy po krótkim rozpoznaniu, a nie w trakcie prac. Jeśli infekcja okaże się rozległa — powiemy to od razu, razem z konkretną kwotą, zamiast dobijać ją po fakcie. Jedna strona WordPress, standardowa infekcja plikowa. od 690 zł netto≈ 159 € · rozliczenie jednorazowe Sklep, portal z danymi użytkowników albo powtórna infekcja. od 1 290 zł netto≈ 299 € · rozliczenie jednorazowe Dla tych, którzy nie chcą przechodzić tego drugi raz. Wycena indywidualnaabonament miesięczny Nie wiesz, który wariant Cię dotyczy? Napisz, co widzisz na stronie i czy hostingodawca już zablokował konto. Po krótkim rozpoznaniu — zwykle w ciągu kilku godzin roboczych — podajemy konkretną cenę i termin. Standardowe wyczyszczenie jednej strony to zwykle 24–48 godzin od momentu, w którym mamy dostępy. Rozległa infekcja — wiele stron na jednym koncie, backdoory w bazie danych, powtórne włamanie — może zająć kilka dni. Realny termin podajemy po pierwszym rozpoznaniu, a nie „na oko" przy zgłoszeniu. Nie. Prace zaczynamy od pełnego backupu plików i bazy danych, a rdzeń WordPressa przywracamy bez nadpisywania wp-config.php i katalogu uploads. Treści, zamówienia, konta klientów i media zostają na miejscu. Usuwamy wyłącznie to, co nie należy do Twojej instalacji. Wtyczka wykrywa część znanych plików i bardzo pomaga zapobiegawczo, ale po włamaniu zwykle nie wystarcza. Webshell podszywający się pod plik graficzny, backdoor w katalogu mu-plugins, wstrzyknięcie w bazie danych czy narzędzie do zarządzania bazą ukryte pod nazwą pliku WordPressa — takie rzeczy przechodzą przez standardowy skan. Dlatego skanujemy po zawartości plików i weryfikujemy rdzeń sumami kontrolnymi. Infekcja wraca w dwóch sytuacjach: gdy nie zamknięto wejścia, przez które weszli, albo gdy została jedna furtka. Dlatego czyszczenie zawsze kończymy zabezpieczeniem serwera i skanem kontrolnym po kilku dniach. Jeśli po naszych pracach infekcja wróci tą samą drogą — wracamy do tematu bez dodatkowej opłaty. Tak, to bardzo częsty punkt startowy. Hostingodawcy zwykle zostawiają dostęp FTP lub SSH przy wyłączonej stronie albo odblokowują ją na czas prac po zgłoszeniu. Pomagamy takie zgłoszenie napisać, a po czyszczeniu przygotowujemy wykaz usuniętych plików i wdrożonych zabezpieczeń — właśnie na tej podstawie blokada jest zdejmowana. Dostępu SSH lub FTP, dostępu do panelu WordPress (jeśli jeszcze działa) oraz do panelu hostingu. Bardzo przydają się logi serwera z ostatnich dni — to z nich odtwarzamy chronologię ataku. Jeśli nie wiesz, gdzie tego szukać, przeprowadzimy Cię krok po kroku; nie musisz się na tym znać. W większości przypadków tak — logi serwera pozwalają wskazać podatny komponent, moment wejścia i to, co atakujący zdążył zrobić. Wszystko trafia do raportu razem z listą usuniętych plików. Jeśli logi zostały już zrotowane przez hosting, opieramy się na analizie samych plików i mówimy o tym wprost, zamiast zgadywać. Specjalizujemy się w WordPressie i WooCommerce — stamtąd pochodzi większość zgłoszeń i tam mamy najwięcej wypracowanych procedur. Przy innych systemach opartych na PHP zwykle też jesteśmy w stanie pomóc. Napisz, co to za system — odpowiemy szczerze, czy się do tego nadajemy, zamiast uczyć się na Twojej awarii. Każda godzina to kolejne obce podstrony w indeksie Google i większe ryzyko blokady u hostingodawcy. Napisz, co widzisz na stronie — zrobimy szybkie rozpoznanie i powiemy wprost, ile zajmie i ile kosztuje naprawa.Strona zainfekowana? Czyścimy, zamykamy lukę i dajemy raport.
Objawy, których nie da się przeczekać
Google ostrzega przed stroną
Hosting zablokował konto
Podmieniona strona główna
Obce wyniki w wyszukiwarce
Konta administratora, których nie tworzyłeś
Przekierowania tylko na telefonie
To nie pech — to jedna nieaktualna wtyczka
Luka we wtyczce lub motywie
Webshell
Backdoory i ukryte konta
Co dokładnie robimy
Backup przed czyszczeniem
Analiza logów serwera
Skan po zawartości plików
Przywrócenie rdzenia WordPressa
Katalog mu-plugins i wtyczki
Czyszczenie bazy danych
Rotacja haseł i kluczy
Zamknięcie wektora wejścia
Dane dostępowe poza webroot
Raport i skan kontrolny
Pięć kroków do czystego serwera
Zgłoszenie i dostępy
Analiza wektora
Czyszczenie
Zabezpieczenie
Raport i skan kontrolny
Portal branżowy z WooCommerce — od blokady hostingu do czystego serwera
Chronologia
Ostrzeżenie w Google i blokada hostingu — też to załatwiamy
Search Console i przejęcie domeny
Wniosek o ponowną weryfikację
Obce podstrony w indeksie
Odblokowanie konta u hostingodawcy
Jasna kwota, zanim zaczniemy
Usunięcie infekcji
Zgłaszam infekcję
Audyt powłamaniowy + zabezpieczenie
Poproś o wycenę
Opieka i monitoring
Zapytaj o opiekę
Usuwanie wirusów ze strony — częste pytania
Strona zainfekowana? Nie czekaj do rana.