Anatomia włamania na WooCommerce – jak rozpoznać i usunąć zaawansowaną infekcję

Analiza prawdziwego ataku na sklep internetowy, od rekonesansu po ponowną infekcję. 420 000 linii logów, każdy krok atakujących i kompletny poradnik jak przeprowadzić skuteczne czyszczenie.

Twój sklep na WordPressie działa. Zamówienia wchodzą. Klienci kupują.

A pod spodem ktoś właśnie wrzuca setki stron o kasynach online.

To nie jest scenariusz z filmu. Przeanalizowaliśmy ponad 420 000 linii logów dostępowych z prawdziwego sklepu WooCommerce, który trafił do nas po tym, jak właściciel zauważył dziwne strony w Google Search Console. Odtworzyliśmy każdy krok atakujących i na tej podstawie przygotowaliśmy poradnik, który pomoże Ci rozpoznać podobny atak i skutecznie go wyeliminować.

Faza 1: Rekonesans – jak atakujący zbierają informacje

WordPress ma wbudowany endpoint REST API, który domyślnie zwraca listę użytkowników każdemu, kto o nią zapyta. Wystarczy wejść na:

twoja-strona.pl/wp-json/wp/v2/users

Dostajesz loginy, ID, nazwy wyświetlane, wszystko co potrzebne, żeby wiedzieć na jakie konto celować. To pierwszy krok niemal każdego zautomatyzowanego ataku na WordPressa.

Jak się chronić: Zablokuj endpoint /wp-json/wp/v2/users dla niezalogowanych użytkowników. Możesz to zrobić snippetem w functions.php, wtyczką typu Disable REST API, lub regułą w .htaccess.

Faza 2: Brute-force przez xmlrpc – ukryta furtka WordPressa

Większość ludzi myśli o brute-force jako o setkach prób logowania na stronie wp-login.php. To łatwo wykryć i zablokować.

Ale WordPress ma też plik xmlrpc.php, stary protokół do zdalnej komunikacji. Problem? Pozwala testować wiele haseł w jednym zapytaniu przez metodę system.multicall. Jeden request = kilkadziesiąt prób.

Klasyczny rozproszony atak. Z jednego IP leci 20-30 prób, pod progiem wykrycia większości wtyczek bezpieczeństwa. Dopiero analiza całości logów ujawnia wzorzec.

Jak się chronić: Zablokuj xmlrpc.php całkowicie (jeśli nie używasz aplikacji mobilnej WP lub Jetpacka). W .htaccess lub na poziomie serwera. Dodaj limit prób logowania nie tylko na wp-login, ale też na xmlrpc.

Faza 3: Przejęcie kontroli – 22 minuty wystarczą

Kiedy hasło zostaje złamane, atakujący loguje się do panelu WordPress. W analizowanym przypadku od zalogowania do pełnej kontroli nad stroną minęły 22 minuty. Oto co zrobił:

1. Wyłączył masowo pluginy: szczególnie te bezpieczeństwa, żeby nic mu nie przeszkadzało
2. Włączył Yoast SEO: zmienił ustawienia indeksowania, żeby Google crawlował jego spam
3. Otworzył Theme Editor: wbudowany edytor plików WordPressa
4. Wstrzyknął kod do functions.php motywu: kod tam wrzucony wykonuje się przy każdym załadowaniu strony
5. Wgrał plugin PHP-Console: narzędzie do zdalnego wykonywania kodu PHP
6. Wykonał kod przez PHP-Console: jeden POST z czasem odpowiedzi 19 sekund. Mógł zainstalować cokolwiek
7. Wyłączył PHP-Console: zamiatanie śladów

22 minuty od zalogowania do pełnej kontroli. Wszystko przy użyciu wbudowanych narzędzi WordPressa, żadnych exploitów zero-day.

Kluczowy wniosek: Theme Editor i możliwość instalacji pluginów z panelu to najgroźniejsze narzędzia w rękach atakującego. Dwie linijki w wp-config.php wyłączają oba:

define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', true);

Faza 4: Spam SEO – po co hakerzy włamują się na sklepy

W ciągu kilku dni w indeksie Google pojawiło się prawie 2700 stron:

Wszystkie zwracały HTTP 200. Google traktował je jako prawdziwe strony sklepu. Googlebot i Bingbot indeksowały je na pełnych obrotach.

To jest jeden z najczęstszych celów włamań na WordPressa. Atakujący nie chcą kraść danych, chcą pożyczyć autorytet Twojej domeny, żeby pozycjonować swoje treści. Zaufany sklep z naturalną żywnością nagle „publikuje” treści o kasynach. Efekt? Rankingi organiczne sklepu lecą, a haker zarabia na affiliate kasynowym.

Jak to rozpoznać: Regularnie sprawdzaj Google Search Console: Strony. Jeśli widzisz URL-e, których nie tworzyli Twoi redaktorzy, masz problem. Alternatywnie: site:twojadomena.pl casino w Google.

Dlaczego pierwsze czyszczenie prawie nigdy nie działa

To jest pułapka, w którą wpada większość osób próbujących oczyścić zhakowaną stronę. Widzisz problem, kasujesz oczywiste rzeczy, zmieniasz hasła i myślisz, że jest czysto.

W analizowanym przypadku po pierwszym czyszczeniu usunięto fałszywe konta admin, podejrzane pluginy i zmieniono hasła. Standardowa procedura.

Dlaczego to się stało? Bo czyszczenie było niekompletne. Oto najczęstsze powody, przez które infekcja wraca:

1. Backdoor w nieaktywnym motywie

Atakujący wstrzyknął kod do functions.php motywu, który był zainstalowany, ale nieaktywny. Czyszczenie skupiło się na aktywnym motywie, nieaktywny przetrwał nietknięty.

2. Wstrzyknięcia w bazie danych

Złośliwy kod w wp_options, w serializowanych polach, w snippetach WPCode. Skanery plików tego nie złapią, trzeba przeszukać bazę danych.

3. Zaplanowane zadania (wp_cron)

Atakujący mogą dodać cron job, który po pewnym czasie pobiera i instaluje backdoor od nowa. Nawet jeśli wyczyścisz pliki, cron przywraca infekcję.

4. Drugi kanał dostępu

Zmiana hasła WordPressa nie pomaga, jeśli atakujący zostawił webshell w katalogu uploads/ lub ma dane do FTP/bazy danych.

Skuteczne czyszczenie to nie usuwanie tego co widać. To systematyczne zamykanie wszystkich kanałów dostępu i weryfikacja każdego elementu instalacji.

Kompletna procedura czyszczenia – krok po kroku

Na podstawie analizy tego i dziesiątek podobnych incydentów, oto procedura, która naprawdę działa. Kolejność ma znaczenie.

Checklista prewencyjna – zrób to zanim Cię zhakują

Większość włamań na WordPressa wykorzystuje domyślne ustawienia, które trzeba świadomie zablokować. Oto co możesz zrobić już dziś. Pamiętaj też o samym rdzeniu WordPressa: wydania 7.0.2 i 7.0.3 łatały kolejne luki bezpieczeństwa, więc aktualizuj bez zwłoki.

Podsumowanie

Cały atak da się streścić w jednym zdaniu:

Atakujący przeczytali listę loginów z publicznego API, złamali hasło przez xmlrpc brute-force i wykorzystali wbudowane narzędzia WordPressa do przejęcia kontroli.

Żadna z tych rzeczy nie wymaga exploita zero-day ani zaawansowanej wiedzy. To domyślne ustawienia WordPressa, które trzeba świadomie zablokować. A największy błąd przy czyszczeniu? Usuwanie tylko tego co widać, zamiast systematycznego przejścia przez całą instalację.

Jeśli prowadzisz sklep na WordPressie, przejdź checklistę powyżej. Większość punktów zajmie Ci 5 minut, a może uchronić przed tygodniami problemów.

Sprawdź swoją stronę. Dzisiaj.