Dlaczego pirackie motywy WordPress kończą się malware
Oszczędność jest zrozumiała. Motyw premium kosztuje 60–80 dolarów, a w sieci bez problemu znajdziesz „to samo”, tylko za darmo. Logika jest kusząca. Efekt zwykle też jest, tyle że inny niż oczekiwany.
Zajmujemy się sprzątaniem po takich decyzjach regularnie. Wystarczy powiedzieć, że nie jest to rzadkość.
Skąd się biorą pirackie motywy i co w nich siedzi
Strony z nullowanymi motywami nie prowadzą filantropi. Ktoś kupuje oryginalny motyw, coś do niego dorzuca i udostępnia za darmo. Pytanie, co dorzuca.
Najczęściej to jeden z kilku wariantów:
Backdoor — ukryty fragment kodu PHP, który pozwala na zdalny dostęp do serwera. Może wyglądać jak kilka linijek bazujących na eval(base64_decode(...)) schowanych w pliku functions.php, albo głębiej, w zagnieżdżonym pliku pomocniczym, którego nikt nie przegląda. Przez taki backdoor można wgrać dowolny plik, uruchomić dowolne polecenie, podmienić treść, założyć dodatkowe konto administratora.
Injektowany spam SEO — strona wygląda normalnie dla zalogowanego użytkownika i dla Google Search Console, dopóki Google nie zindeksuje ukrytych podstron z farmą linków do kasyn, aptek lub innych serwisów, które nie mogłyby się pojawić w normalnym wyszukiwaniu. Ten typ infekcji jest wyjątkowo nieprzyjemny, bo przez tygodnie lub miesiące nic nie wskazuje na problem. Dowiadujesz się, gdy klient pyta, dlaczego jego strona z usługami hydraulicznymi zajmuje się w Google również sprzedażą Viagry.
Redirection malware — kod sprawdza User-Agent przeglądarki mobilnej lub źródło ruchu. Użytkownicy wchodzący z Google na urządzeniu mobilnym są przekierowywani na zewnętrzne strony. Administrator sprawdzający stronę z laptopa nie widzi niczego nieprawidłowego. Ten wariant jest szczególnie trudny do wykrycia bez narzędzi zewnętrznych.
Kryptominer — mniej powszechny dziś niż kilka lat temu, ale nadal spotykany. Serwer pracuje na rzecz kogoś innego, rachunki za VPS rosną, load average jest permanentnie wysoki.
Jak to jest ukrywane
To nie jest prosty echo "hacked". Osoby przygotowujące nullowane motywy wiedzą, czego szukają skanery.
Kod bywa dzielony na fragmenty i składany dynamicznie w czasie wykonywania. Bywa kodowany wielokrotnie — base64, potem rot13, potem jeszcze jedna warstwa. Bywa chowany w obrazkach jako dane w metadanych EXIF albo w nazwach plików, które wyglądają jak zasoby systemowe.
Widzieliśmy przypadki, gdzie backdoor siedział w pliku o nazwie wp-class-loader.php w katalogu motywu. Nazwa celowo mylona z plikami rdzenia WordPress. Nikt nie zaglądał.
Inny klasyk: złośliwy kod aktywuje się dopiero po 30 dniach od instalacji motywu. Przez pierwszy miesiąc wszystko działa normalnie. Testy przed startem wypadają czysto. Potem już jest problem.
Co się dzieje po infekcji
Zależy od tego, co zostało wsadzone do motywu i co atakujący postanowi z tym zrobić.
Backdoor może siedzieć cicho miesiącami. Ktoś może go po prostu sprzedać dalej jako dostęp do przejętego serwera — to normalny rynek. Kupujący wchodzi, skanuje środowisko, patrzy czy masz WooCommerce, bazę danych z danymi klientów, dane kart, adresy, maile. Robi co trzeba.
Albo dostęp jest używany do rozsyłania spamu z Twojego serwera. Hosting banuje konto albo cały adres IP ląduje na blacklistach. Efekt: maile z Twojej domeny przestają dochodzić.
Albo serwer jest wciągany do botnetu i używany do ataków DDoS na innych. Twój problem zaczyna się, gdy provider zawiesza konto z powodu ruchu wychodzącego.
Czyste kopie baz danych trafiają na sprzedaż. Dane klientów sklepu WooCommerce z przed roku — ktoś za nie zapłaci.
Żaden z tych scenariuszy nie jest szczególnie dramatyczny w narracji, ale każdy jest bardzo konkretny w skutkach.
Dlaczego skanery tego nie zawsze łapią
Pluginy bezpieczeństwa jak Wordfence czy anty-malware skanują znane sygnatury. Problem w tym, że kod w nullowanych motywach jest często modyfikowany pod konkretną dystrybucję, żeby nie trafiać w bazy sygnatur. Świeże próbki przez jakiś czas nie są rozpoznawane.
Wordfence może nie zgłosić niczego i technicznie ma rację — nie zna tego wariantu. To nie jest wada Wordfence’a, to natura problemu.
Skanery online, które sprawdzają URL strony, widzą to samo co przeglądarka — renderowany HTML. Backdoor w PHP nie jest widoczny z zewnątrz dopóki nie zostanie aktywowany.
Bardziej skuteczna jest analiza plików bezpośrednio na serwerze — sprawdzenie find po eval i base64_decode w plikach PHP, analiza różnic między plikami motywu a oryginalną wersją, przegląd plików zmodyfikowanych w ostatnim czasie. To można zautomatyzować, ale wymaga dostępu do serwera, a nie tylko do panelu WordPress.
Na VPS robimy to regularnie. Na hostingu współdzielonym bywa trudniej, zależy od providera.
Dług techniczny zaczyna się od drobnych decyzji
Piracki motyw to zazwyczaj początek szerszego wzorca. Przy okazji dochodzi wtyczka podbrana z podobnego źródła, bo skoro działa raz, to czemu nie dwa. Potem środowisko nie jest aktualizowane, bo jakaś nullowana wtyczka nie działa na nowszym PHP. Backupy są, bo hosting ma automatyczne, ale nikt nie sprawdził czy działają. Cache ustawiony przez poprzedniego freelancera robi coś, ale nikt nie wie co.
To wszystko razem tworzy środowisko, w którym nie wiadomo skąd przyszedł problem i skąd może przyjść następny.
Sprzątanie po infekcji z nullowanym motywem w tle to nie jest wymiana jednego pliku. To audyt całego środowiska, bo nie ma pewności co jeszcze zostało zmodyfikowane i kiedy. Mieliśmy przypadki, gdzie usunięcie oczywistego malware nie kończyło sprawy, bo działał jeszcze drugi, niezależny backdoor wgrany przez pierwszy.
Co to oznacza w praktyce
Oryginalne motywy mają weryfikowane źródło, historię commitów, autorów, aktualizacje bezpieczeństwa. Nullowane nie mają niczego poza plikiem zip i obietnicą, że ktoś obcy zrobił ci przysługę.
Jeśli korzystasz z motywu pobranego spoza oficjalnego marketplace lub bezpośrednio od autora — sprawdź go przed instalacją. Nie przez interfejs WordPressa, tylko przez analizę kodu. grep -r "eval(base64" . w katalogu motywu to minimum. Możesz też użyć narzędzi jak Theme Check plugin albo skanu przez dedykowany skaner malware bezpośrednio na plikach.
Jeśli masz aktywny motyw z wątpliwego źródła i nigdy go nie sprawdzałeś — to dobry moment, żeby to zmienić.
Backup aktualny, na zewnątrz serwera, sprawdzony pod kątem przywrotu — obowiązkowo. Nie backupy z hostingu przechowywane na tym samym koncie.
Monitoring integralności plików — zmiana w functions.php powinna generować alert, nie być odkrywana przez przypadek trzy miesiące później.
To nie jest skomplikowane. Jest tylko często pomijane, dopóki nie pojawi się problem, który przestał być tani.