Case study
Odwirusowanie Joomla 4 i migracja do Joomla 6 po infekcji plików i bazy
Ponad 330 złośliwych plików, malware w bazie, 16 starych instalacji i utracone ustawienia wyglądu. Oczyściliśmy środowisko, odtworzyliśmy serwis i przenieśliśmy go do Joomla 6.1.2.
Podsumowanie
Serwis na Joomla 4.3 został zaatakowany w plikach i bazie danych. Usunęliśmy ponad 330 złośliwych plików i furtek, zamknęliśmy wektor włamania, odtworzyliśmy wygląd oraz etapowo zaktualizowaliśmy Joomla do 6.1.2 wraz z PHP 8.3, MySQL 8 i kluczowymi rozszerzeniami.
Sytuacja wyjściowa
System działał na niewspieranej Joomla 4.3. Włamanie uszkodziło konfigurację wyglądu, pozostawiło ponad 330 złośliwych plików i mechanizmy dostępu, a dodatkowy kod znalazł się bezpośrednio w bazie. Na koncie hostingowym pozostawało 16 starych instalacji i około 127 tys. plików.
Problem biznesowy
Serwis obsługiwał treści, formularze, zapisy i rezerwacje ważne dla codziennej sprzedaży usług. Klient potrzebował szybkiego przywrócenia wiarygodnego wyglądu i działania, ale samo usunięcie widocznych plików nie rozwiązywało infekcji zapisanej w bazie i porzuconych systemach na tym samym koncie.
Ryzyka
Atak obejmował mechanizm przygotowany do przejęcia administratora oraz kod podmieniający treść widoczną dla wyszukiwarek. Producent szablonu zakończył jego rozwój, a SP Page Builder, SP Booking i Helix wymagały aktualizacji. Istniało ryzyko odtworzenia infekcji z nieużywanych instalacji i utraty ustawień podczas migracji.
Zakres odpowiedzialności
Odpowiadaliśmy za kopie plików i bazy, analizę plików i rekordów bazy, usunięcie malware, zamknięcie luki, hardening katalogów mediów, migrację Joomla, PHP i MySQL, aktualizację rozszerzeń, własne poprawki szablonu, rekonstrukcję ustawień z archiwum, porządkowanie hostingu oraz testy frontu i panelu. Prace wykonaliśmy white-label.
Rozwiązanie
Joomla została przeprowadzona z 4.3 do 6.1.2 przez wymagane wersje pośrednie. PHP podniesiono do 8.3, bazę przeniesiono do MySQL 8, SP Page Builder zaktualizowano z 4.0.10 do 6.6.2, SP Booking z 2.0.4 do 2.2.1, a Helix Ultimate z 2.0.12 do 2.2.9. Niewspierany szablon dostosowaliśmy własnymi poprawkami, a wygląd odtworzyliśmy z archiwalnego widoku.
Architektura i integracje
Docelowe środowisko działa na Joomla 6.1.2, PHP 8.3, MySQL 8, Apache, SP Page Builder 6.6.2, SP Booking 2.2.1 i Helix Ultimate 2.2.9. Katalogi mediów blokują wykonywanie skryptów, a 16 dawnych instalacji zostało spakowanych i odłączonych od publicznego dostępu.
Rezultaty
Serwis odzyskał treść, wygląd, menu, zdjęcia, formularze i funkcje rezerwacyjne. Liczba plików na koncie spadła z około 127 tys. do niespełna 14 tys. Wszystkie wskazane podstrony, panel i elementy specjalne przeszły testy bez komunikatów o błędach, a stara wersja została zachowana do czasu potwierdzenia odbioru.
Technologie
Joomla 4 i 6, PHP 8.3, MySQL 8, Apache, SP Page Builder 4 i 6, SP Booking, Helix Ultimate, analiza malware w plikach i bazie, hardening mediów, rekonstrukcja ustawień z archiwum.
Dalsze kroki
Zaleciliśmy monitoring po incydencie, regularne aktualizacje, dalszą rotację dostępów oraz okresową kontrolę całego konta hostingowego. Poprzednia wersja i kopie etapowe pozwalają na rollback do czasu pełnego odbioru.
Rozległy incydent, kontrolowana odbudowa
To realizacja white-label, dlatego nie pokazujemy klienta, domeny ani charakterystycznych widoków. Fotografia rekonstruuje prawdziwy układ pracy: serwis eventowo-rezerwacyjny, raport bezpieczeństwa, migrację i kopie.
- Infekcja obejmowała zarówno pliki, jak i bazę danych, w tym mechanizm przygotowany pod przejęcie konta administratora.
- Ustawienia wyglądu odtworzyliśmy na podstawie archiwalnej wersji sprzed włamania.
- SP Page Builder, SP Booking i Helix Ultimate zostały zaktualizowane, a niewspierany szablon dostosowany własnymi poprawkami.
- Każdy kluczowy etap bazy poprzedzała osobna kopia, a finalny serwis przeszedł testy treści, formularzy, rezerwacji i panelu.
