Trzy rodziny backdoorów w jednej instalacji WordPress

Strona klienta była niedostępna przez kilka dni. Pod spodem: trzy niezależne rodziny backdoorów, chiński serwer C&C, ukraiński bot na Telegramie i phishing kit podszywający się pod japoński sklep. Wszystko w jednej instalacji WordPress, która z zewnątrz wyglądała na zdrową.

Kiedy klient skontaktował się z nami, nie było jednego objawu „coś nie działa”. Był konkretny, mierzalny problem: witryna firmowa nie odpowiadała. Pod tą awarią kryło się kilkanaście drobnych sygnałów, które pojedynczo nic nie znaczą, ale razem układały się w obraz systematycznego, długoletniego dostępu osób trzecich do serwera. Historię skończyliśmy w jeden dzień. Mechanizm, który dał nam pewność, że problem naprawdę zniknął, zostawiliśmy klientowi na stałe. Jeśli szukasz dokładnie takiej opieki, zajrzyj do naszej oferty utrzymania i rozwoju stron.

W przypadku firmowej strony pełniącej rolę witryny i źródła leadów to prosta droga do mierzalnej straty:

• zero zapytań ofertowych przez cały okres niedostępności
• pozycje w wyszukiwarce do odbudowania przez tygodnie po powrocie (Google wywala z indeksu w kilka godzin, przywraca w kilka tygodni)
• utrata zaufania klientów, którzy w międzyczasie trafili na komunikat błędu
• ryzyko trwałego oznaczenia domeny jako „deceptive site” przez Google Safe Browsing i Microsoft SmartScreen, co blokuje stronę w Chrome, Edge, Firefoxie i w ostrzeżeniach antywirusowych nawet po usunięciu kodu

Nasza robota zaczęła się od wyjścia z awarii: przywrócenie dostępności serwisu dla zwykłego ruchu było pierwszym krokiem, a diagnoza i cleanup toczyły się równolegle, dopiero po uruchomieniu strony.

Branża i kontekst

Klient prowadzi firmowy serwis typu landing + oferta, oparty o WordPressa z Elementor Pro i rodziną wtyczek Jet. Hosting współdzielony. Standardowy stack, który obsługuje setki tysięcy firm w Polsce. Właśnie dlatego ten case jest ciekawy: niczym specjalnym się nie wyróżnia. To mogła być strona dowolnej firmy. Dla porównania, podobny WordPressowy case robiliśmy dla szkoły numerologii: inna branża, ten sam poziom skomplikowania pod maską.

Punkt wyjścia

W serwisie zaczęły się dziać drobne, trudne do powiązania rzeczy:

• okresowo pojawiały się nowe pliki index.php w losowych podfolderach wtyczek
• plik license.txt w głównym katalogu miał zerowy rozmiar i był regularnie „muskany” (zmiana timestampu bez zmiany zawartości) co kilkanaście dni
• w Google Search Console pojawiały się strony indeksowane po japońsku, których nikt nie publikował
• obok WordPressa, pod /quiz/, działał quiz „oblicz koszt instalacji fotowoltaicznej” po polsku, choć klient nie zajmuje się fotowoltaiką

Każdy z tych sygnałów osobno można zignorować. Razem to podręcznikowy wzorzec długoterminowej kompromitacji.

Diagnoza: trzy rodziny backdoorów + phishing kit

Dochodzenie pokazało, że serwer został zaatakowany kilkukrotnie na przestrzeni ponad trzech lat, przez różne grupy, z różnymi celami. Poniżej skrócony opis każdej z rodzin, a pod każdym opisem rozwijana sekcja z detalem technicznym dla ciekawych.

Rodzina 1: Japanese SEO cloak + chiński RCE

Główny index.php serwisu, który normalnie uruchamia WordPressa, został przerobiony tak, że trzymał trzy nakładające się warstwy złośliwego kodu. Zwykły użytkownik z Polski widział normalną stronę. Googlebot z Japonii widział fałszywy sklep. Atakujący z właściwym parametrem w URL dostawał zdalne wykonanie kodu.

Rodzina 2: dropper z losowymi hashami

Druga rodzina to remote loader, który co jakiś czas tworzył nowy folder z losowym hashem i wrzucał do niego PHP, który przez curl pobierał z serwera C&C odpowiedź tekstową i wykonywał ją przez eval. Trzy generacje droppera żyły w serwerze równolegle, w różnym wieku. Najstarsza z grudnia 2022 roku.

Rodzina 3: magic-URL admin creator z auto-heal

To była najgroźniejsza rodzina, bo potrafiła sama się odbudowywać. Jedno żądanie HTTP z odpowiednim parametrem w URL powodowało, że serwer sam tworzył konto administratora WordPressa i od razu logował atakującego. Drugi plik, w ukrytej lokalizacji, odbudowywał całość jeśli ktoś usunął pierwszy.

Dodatek: phishing kit /quiz/

Niezależnie od backdoorów, w podfolderze /quiz/ działał quiz oparty o SaaS Marquiz. Konfiguracja quizu: polski scam lead gen dla fotowoltaiki. Leady z formularza były wysyłane w dwóch kanałach: na firmową skrzynkę klienta (atakujący podszył się pod jego adres jako nadawcę) i na ukraiński bot Telegrama (identyfikator chatu + token bota zaszyte w kodzie).

Timeline ataku (zrekonstruowany)

Trzy lata persistencji, w tym cała seria aktywnych operacji w ostatnim miesiącu. Klient nie wiedział o niczym.

Co zrobiliśmy

Krok 1: Przywrócenie dostępności

Pierwsze godziny poszły na to, żeby strona w ogóle działała, bez względu na to co znajdziemy pod spodem. Wyłączenie ruchu z zewnątrz, przywrócenie czystego punktu wejścia (index.php), usunięcie oczywistych 500-ek. Dopiero potem zaczęła się właściwa diagnoza.

Krok 2: Enumeracja wszystkich dropperów

Pełne skanowanie webroota po charakterystycznych markerach (goto + base64, 2DUAN, eval(curl(...)), nietypowe cudzysłowy w nazwach folderów jako anti-lstat trick). Każdy znaleziony plik: backup off-site + usunięcie.

Krok 3: Rozcięcie łańcucha regeneracji

Rodzina 3 regenerowała się przez fixer.php. Dopóki fixer.php żył, pozostałe pliki wracały. Musieliśmy ustalić, że fixer.php istnieje w trzech lokalizacjach jednocześnie i usunąć wszystkie trzy w jednym przelocie. Po pierwszym podejściu, w którym usunęliśmy tylko kopię w motywie, pliki wróciły w ciągu kilku minut.

Krok 4: Phishing kit + Telegram

Usunięcie całego katalogu /quiz/ oraz powiązanego konta Marquiz (klient dostał od nas listę kroków do przeprowadzenia u siebie). Zablokowanie wysyłki z własnej domeny jako nadawcy (SPF + DMARC reject).

Krok 5: Watcher mu-plugin (zostaje na stałe)

Zbudowaliśmy dedykowany mu-plugin, nazwijmy go „forensic watcher”, który żyje w wp-content/mu-plugins/ i uruchamia się przy każdym żądaniu PHP. Jest częścią pakietu, który dołączamy do każdej umowy w ramach utrzymania i rozwoju stron.

Krok 6: Audit bazy danych

Dodatkowo sprawdziliśmy przez watchera, że w bazie nie ma śmieci po atakujących: wp_users (jedyny admin to konto klienta, zero kont stworzonych przez atakujących), wp_options.autoload (czysty), WP-Cron (czysty, zero zarejestrowanych hooków, których nie da się przypisać do standardowych wtyczek).

Dlaczego to w ogóle się stało

Trzy niezależne wektory są rzadkie, ale konkretne powody wejścia atakujących to w 95% przypadków jedna z trzech rzeczy:

1. Nieaktualne wtyczki z publicznym CVE. Serwer miał kilka wtyczek z rodziny Jet w wersji sprzed kilkunastu miesięcy. Jedna z nich w okresie 2022-2023 miała publicznie opisaną lukę pozwalającą na authenticated file upload.
2. Słabe hasło administratora albo wyciek z zewnętrznego serwisu (data breach). Pierwotna kompromitacja mogła nie być „techniczna”: wystarczy, że ktoś używał tego samego hasła w kilku miejscach, a jedno z nich wyciekło.
3. Współdzielony hosting. Niektóre udokumentowane ataki na hosting współdzielony polegały na przejściu z jednej skompromitowanej strony sąsiada na drugą przez wspólny tmp lub prawa katalogu domyślnego.

Rezultaty w liczbach

Czego nauczył nas ten case

1. Backdoory potrafią współistnieć

Przyzwyczajenie „jeden atak = jeden rodzaj szkodnika” jest mylące. Jeśli strona była wystawiona i podatna przez lata, mogła być skompromitowana kilka razy, przez różne grupy, z różnymi celami. Każda z nich zostawia własny mechanizm persistencji i każdy z nich trzeba znaleźć osobno. Zatrzymanie się po usunięciu pierwszego pliku to typowy błąd.

2. Auto-heal to główny mechanizm przeżycia nowoczesnego malware

Pliki w widocznych miejscach to przynęta. Prawdziwym mechanizmem przeżycia jest regenerator w nieoczywistej lokalizacji, który odbudowuje widoczne pliki za każdym razem, gdy ktoś je usunie. Jeśli po „wyczyszczeniu” strony pliki wracają w ciągu kilku godzin, znaczy to, że czyszczono tylko objawy.

3. Twoja domena może być narzędziem, nawet jeśli Twoja strona wygląda OK

Phishing kit z Telegram botem nie zrobił nic widocznego z perspektywy odwiedzającego stronę. Nie pokazywał reklam, nie przekierowywał, nie zmieniał SEO. Po prostu wykorzystywał domenę jako nadawcę. Dla Google, Microsoftu, Barracudy i reszty operatorów antyspamowych wygląda to tak, jakby to Ty wysyłałeś phishing. Konsekwencje (SPAMhaus blacklist, utrata deliverability) są poważniejsze niż defacement.

4. Monitoring plików to nie luksus

Większość klientów rozpoznaje atak, dopiero gdy coś wizualnie się zepsuje: strona nie ładuje się, pojawia się ostrzeżenie Chrome „deceptive site”, Google wywala z indeksu. W tym momencie szkodliwa aktywność na serwerze trwa często miesiącami. Prosty watcher, który loguje zmiany .php, daje czas reakcji liczony w godzinach, nie w miesiącach. To standardowy element każdej naszej umowy utrzymaniowej.

5. Backupy sprzed daty X zawierają backdoory

Standardowy odruch po wykryciu kompromitacji („przywrócę backup sprzed tygodnia”) w tym case’ie nie zadziałałby. Backup sprzed tygodnia zawierał kompletny zestaw backdoorów. Backup sprzed roku też. Jedyna droga to pełen cleanup forensyczny + świeże backupy od zera.

Dla kogo ten case jest ważny

• Właściciele firmowych stron na WordPressie, którzy „mają hosting od agencji” i nie wiedzą, kto odpowiada za jego security
• Firmy, które przestały aktualizować wtyczki, bo „działa, nie ruszać”
• Każdy, kto widział w swoim serwisie dziwne pliki index.php w nieoczekiwanych lokalizacjach i usunął je ręcznie, zakładając że to koniec sprawy

Jeśli brzmi to znajomo, dobry pierwszy krok to audyt wszystkich plików .php w webroocie serwera + lista kont administracyjnych w WordPressie. Taki audyt zajmuje nam zwykle kilka godzin, a sam pokazuje, czy problem w ogóle istnieje. Jeszcze więcej case’ów znajdziesz w zasobach, pełna oferta jest w naszej ofercie.