Zmiana hasła administratora przez bota, złośliwy kod w sklepie i błędy logowania mogą być objawami tego samego problemu: ktoś uzyskał dostęp do aplikacji. Przywrócenie działania serwisu to pierwszy etap. Drugi to ograniczenie możliwości kolejnego ataku. Dwa przypadki z naszej praktyki pokazują, dlaczego warto doprowadzić oba etapy do końca.
Przypadek pierwszy: bot zmienił hasło administratora WordPressa
Administrator serwisu o wydarzeniach zauważył, że bot zmienił hasło jego konta. Odzyskał dostęp, ustawił nowe hasło i zakończył podejrzaną sesję. Sprawdził też pozostałych użytkowników i dane kont. To były właściwe działania doraźne, ale nadal trzeba było ustalić, jak napastnik dostał się do środka.
Przeanalizowaliśmy logi, aktywność kont i stan aplikacji. Ustalenia wskazały na automatyczny atak wykorzystujący podatność używanej wcześniej wersji WordPressa. Zmiana hasła sama w sobie nie usuwała jego przyczyny.
Kontrola objęła pliki systemu, wtyczki, konta, uprawnienia i aktywne sesje. Nie znaleźliśmy nowych kont administratorów, backdoora ani zmian plików powiązanych z analizowanym incydentem. To wynik przeprowadzonych kontroli, a nie obietnica, że pojedynczy skan odpowie na każde pytanie dotyczące włamania.
Zweryfikowaliśmy zaktualizowany system, wymieniliśmy klucze uwierzytelniające i unieważniliśmy sesje administratorów. Mechanizm wykorzystany w ataku zablokowaliśmy dodatkowo na poziomie serwera dla siedmiu domen tego samego konta hostingowego. Po zmianach sprawdziliśmy stronę, logowanie i API. Serwis działał prawidłowo.
W tym przypadku reakcja objęła zarówno skutki incydentu, jak i drogę wykorzystaną do ataku. Dalsze zalecenia dotyczyły logowania dwuskładnikowego, haseł używanych również w innych usługach oraz monitorowania logów.
Przypadek drugi: infekcja sklepu PrestaShop
W sklepie działającym na PrestaShop 1.6 znaleźliśmy złośliwy kod w kilku miejscach aplikacji. Część plików udawała obrazy lub arkusz stylów, choć zawierała kod służący infekcji. Zmiany obejmowały też biblioteki szablonów, kontrolery i mechanizm logowania administratorów.
Dlatego usunięcie jednego podejrzanego pliku nie kończyło naprawy. Trzeba było sprawdzić kod aplikacji, moduły i pamięć podręczną. Zainfekowane pliki przenieśliśmy do kwarantanny, a potwierdzone zastrzyki w plikach objętych kontrolą wersji usunęliśmy przez przywrócenie sprawdzonych wersji. Zachowaliśmy przy tym modyfikacje sklepu, które nie nosiły śladów infekcji.
Wyczyszczenie pamięci podręcznej szablonów było częścią naprawy: zapisane wcześniej skompilowane pliki mogły nadal wywoływać błędy po poprawieniu kodu źródłowego. Po czyszczeniu sprawdziliśmy składnię kluczowych plików, odpowiedź sklepu i obecność rozpoznanych markerów infekcji. Sklep ponownie odpowiadał prawidłowo, a sprawdzane markery nie występowały.
Znaleźliśmy również kod służący do przechwytywania danych logowania administratorów. Z tego powodu zaleciliśmy zmianę haseł oraz dalsze zabezpieczenie środowiska. Przywrócenie plików nie zastępuje uporządkowania dostępu do sklepu.
Po wcześniejszym czyszczeniu nie uzyskaliśmy zgody na wdrożenie zalecanych zabezpieczeń. Problem później powrócił i sklep wymagał kolejnej interwencji. Ten przypadek pokazuje praktyczny skutek pozostawienia etapu zabezpieczenia poza zakresem naprawy. Nie oznacza to, że ustaliliśmy identyczną drogę wejścia przy każdym incydencie — oznacza, że samo oczyszczenie nie zapewniło trwałego rozwiązania problemu.
Co powinna obejmować naprawa po włamaniu?
Najpierw trzeba zachować materiał potrzebny do analizy i ustalić zakres incydentu. Następnie usunąć potwierdzony złośliwy kod, przywrócić sprawdzone pliki oraz zweryfikować działanie aplikacji. Równolegle należy ocenić dostęp administratorów, aktywne sesje i sekrety, które mogły zostać ujawnione.
Plan dalszych prac powinien odpowiadać stanowi konkretnej strony: może obejmować aktualizację systemu i modułów, ograniczenie dostępu, dodatkowe reguły serwera albo migrację starszej aplikacji. Ważne, żeby właściciel wiedział, co zostało już wykonane, a co pozostaje zaleceniem. Działająca strona i zakończony proces zabezpieczenia to dwa odrębne wyniki prac.
Potrzebujesz pomocy ze stroną lub sklepem?
Jeśli zauważasz nieznane konta, podejrzane przekierowania, zmiany haseł lub błędy po infekcji, skontaktuj się z Projectic. Przeanalizujemy problem, zaproponujemy zakres naprawy i pomożemy zaplanować zabezpieczenia po przywróceniu działania. Możemy też omówić stałą opiekę techniczną nad Twoją stroną lub sklepem.