Jak sprawdzić, czy strona Joomla jest zainfekowana — objawy, miejsca ukrycia i 6 testów
O infekcjach WordPressa napisano wszystko. O Joomli znacznie mniej, a stron na Joomli w Polsce jest wciąż bardzo dużo: firmowe wizytówki z lat 2012–2019, katalogi produktów, strony stowarzyszeń. Wiele z nich nikt nie aktualizował od lat, i właśnie one trafiają do nas najczęściej. Ten wpis jest o tym, jak rozpoznać infekcję w Joomli i gdzie jej szukać.
Objawy, które widać bez logowania
- Hosting pisze o malware albo strona zwraca 403 z krótkim komunikatem. W Joomli to najczęstszy pierwszy sygnał, bo stare instalacje rzadko ktoś ogląda.
- Strona przekierowuje na obcy adres, zwykle tylko z telefonu albo tylko przy wejściu z Google.
- Dziwne adresy w Google po wpisaniu
site:twojadomena.pl: podstrony o lekach, kasynach, w obcym języku, których nigdy nie było. - Strona nagle zwolniła albo hosting zgłasza przekroczenie limitu procesora bez wzrostu ruchu. Kod rozsyłający spam potrafi obciążyć konto bardziej niż odwiedzający.
- Poczta na domenie trafia do spamu, bo z serwera wychodzą tysiące maili, których nie wysyłałeś.
Objawy widoczne w panelu administratora
- Nowi Super Użytkownicy w Użytkownicy → Zarządzaj, założeni w nocy, z adresami na losowych domenach.
- Nieznane rozszerzenia w Rozszerzenia → Zarządzaj → Zarządzaj. Nazwy udają rzeczy systemowe:
plg_system_cache,mod_core_helper,com_update. - Wyłączone rozszerzenia bezpieczeństwa albo wyczyszczone logi akcji użytkowników.
- Data modyfikacji
configuration.phpnowsza niż ostatnia zmiana, którą pamiętasz.
Gdzie Joomla chowa malware
W WordPressie wszyscy sprawdzają wp-content/uploads. W Joomli odpowiedniki są inne:
| Katalog | Co tam znajdujemy |
|---|---|
images/, media/ |
pliki PHP z nazwami udającymi obrazki (logo.php, thumb.php) |
tmp/, cache/, administrator/cache/ |
droppery i web‑shelle, bo te katalogi mają prawa zapisu |
templates/nazwa/ |
zainfekowany index.php szablonu albo doklejony kod w error.php |
libraries/, plugins/system/ |
podmienione pliki rdzenia i wtyczki systemowe ładowane przy każdym żądaniu |
.htaccess w tysiącach podkatalogów |
allowlisty web‑shelli (opisaliśmy to w osobnym wpisie) |
Osobna kategoria to pliki w katalogu głównym o nazwach jak about.php, radio.php, lock360.php, wp-login.php. Joomla nie ma pliku wp-login.php. Jeśli jest, to backdoor.
6 testów, które zrobisz sam
1. Sprawdź wersję i datę wydania
Plik libraries/src/Version.php (Joomla 3.x i nowsze) albo libraries/cms/version/version.php (starsze) pokaże wersję. Joomla 3 nie dostaje poprawek bezpieczeństwa od sierpnia 2023. Jeśli strona stoi na 3.x lub starszej, zakładaj, że luki są publicznie znane i że ktoś je wykorzystał.
2. Poszukaj plików PHP tam, gdzie nie powinno ich być
Przez SSH:
find images media tmp cache -name "*.php" -o -name "*.phtml" -o -name "*.php.*"
Przez FTP: przejrzyj te katalogi ręcznie i sortuj po dacie modyfikacji. Jeden plik PHP w images/ to prawie zawsze infekcja.
3. Sprawdź najnowsze zmiany
find . -type f -mtime -30 -name "*.php" | head -50
Pokaże pliki PHP zmienione w ostatnich 30 dniach. Jeśli nikt nic nie aktualizował, lista powinna być pusta.
4. Porównaj z oficjalnym wydaniem
Pobierz paczkę tej samej wersji Joomli z oficjalnej strony projektu i porównaj sumy kontrolne plików w libraries/, administrator/ i components/. Każda różnica w pliku rdzenia to kandydat na infekcję. Robimy to automatycznie w CleanOps, ale ręcznie też się da dla kilku kluczowych plików.
5. Przeszukaj pod kątem typowych konstrukcji
grep -rl "eval(base64_decode\|gzinflate(base64_decode\|str_rot13(" --include="*.php" . | head
Trafienia w libraries/vendor/ bywają niewinne (biblioteki używają tych funkcji legalnie). Trafienia w images/, tmp/, templates/ niewinne nie są.
6. Obejrzyj stronę jak Googlebot i jak telefon
curl -s -A "Googlebot/2.1" https://twojadomena.pl | grep -i "<script\|location.href" | head
curl -s -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" https://twojadomena.pl | head -40
Jeśli odpowiedź różni się od tego, co widzisz w przeglądarce na komputerze, kod rozpoznaje odwiedzającego i serwuje różne treści.
Co dalej
Jeden test z wynikiem pozytywnym wystarczy, żeby nie kasować niczego na własną rękę. Zrób kopię całego katalogu i bazy, a potem naprawiaj metodycznie: najpierw porównanie z wydaniem, potem reguły na znane wzorce, na końcu analiza niejednoznacznych plików. W CleanOps sprawdzenie Joomli jest bezpłatne i niczego nie zmienia na serwerze, dopiero naprawa jest płatna.
