To nie była typowa awaria modułu płatniczego. W legalnym module sklepu znajdowała się krytyczna podatność, przez którą atakujący zapisał na serwerze backdoor. Następnie rozmieścił złośliwy kod w kilku miejscach: module statystycznym, plikach motywu i wygenerowanym cache JavaScript.
Fałszywy formularz imitował bramkę płatniczą, przechwytywał dane wprowadzane przez kupującego, wyświetlał pozorny błąd, a następnie przekierowywał klienta do prawdziwej płatności. Dzięki temu zamówienie mogło wyglądać na normalnie opłacone, mimo wcześniejszego przejęcia danych.
Sytuacja wyjściowa: płatności wyłączone, ale zagrożenie nadal działało
Operator płatności zablokował klucze dostępowe i zgłosił podejrzenie oszukanej metody płatności. Sklep został wyłączony, aby ograniczyć ryzyko dla kolejnych kupujących. Samo wyłączenie oficjalnej bramki nie rozwiązywało problemu, ponieważ podrobiony formularz był wstrzykiwany niezależnie od legalnej integracji.
Zatrzymać dalsze narażenie klientów
Sklep pozostał w trybie konserwacji do czasu usunięcia wszystkich rozpoznanych mechanizmów infekcji.
Ustalić źródło, a nie tylko usunąć objawy
Usunięcie jednego pliku nie wystarcza, gdy napastnik ma możliwość zapisywania kolejnych plików i wykonywania poleceń.
Co wykryła analiza sklepu?
Infekcja była rozłożona warstwowo. Każdy element pełnił inną funkcję i mógł podtrzymać atak nawet po częściowym czyszczeniu.
Podatny moduł filtrowania
Nieaktualna wersja legalnego modułu umożliwiała niezalogowanej osobie zapisanie pliku wykonywalnego w katalogu sklepu.
Backdoor z wykonaniem poleceń
Złośliwy plik pozwalał odczytywać konfigurację, uruchamiać komendy systemowe i modyfikować kolejne elementy sklepu.
Skimmer płatności
Skrypt wyświetlał pełnoekranową imitację płatności kartą, zbierał dane i dopiero później uruchamiał prawdziwą bramkę.
Loadery i zainfekowany cache
Kod uruchamiający skimmer znajdował się w motywie oraz wielu wygenerowanych plikach cache, co utrudniało szybkie usunięcie.
Złośliwy kod nie był osobnym modułem zainstalowanym przez pracownika. Został dopisany do legalnych elementów sklepu po wykorzystaniu podatności.
Jak przebiegała analiza powłamaniowa?
Plików nie uruchamiano. Analiza miała charakter statyczny, a ustalenia były potwierdzane w kilku niezależnych źródłach.
Zabezpieczenie materiału
Zachowano kopie plików, bazy i logów, aby czyszczenie nie zniszczyło śladów potrzebnych do ustalenia przebiegu zdarzeń.
Skanowanie plików i modułów
Sprawdzono strukturę katalogów, nietypowe daty, obfuskację, funkcje systemowe, zewnętrzne połączenia oraz zmiany w motywie i cache.
Kontrola bazy danych
Zweryfikowano ustawienia modułów, własny JavaScript, konta pracowników, sesje, cache filtrów oraz ślady wywołań nieistniejących plików.
Korelacja logów serwera
Połączono żądania HTTP, moment utworzenia webshella, wykonywanie poleceń i późniejsze wywołania skimmera.
Przygotowanie naprawy
Odtworzono czyste wersje zmodyfikowanych plików, zabezpieczono podatne miejsca i przygotowano paczkę z docelowymi ścieżkami FTP.
Chronologia: od rozpoznania do aktywnej kradzieży danych
Daty plików można zmieniać, dlatego głównym źródłem chronologii były logi dostępu. Pozwoliły odróżnić samo skanowanie od skutecznego wykonania kodu.
Automatyczne rozpoznanie podatności
Adresy zewnętrzne sprawdzały wersję modułu, pliki środowiska i typowe nazwy webshelli.
Skuteczne zapisanie pierwszego backdoora
Seria specjalnie przygotowanych żądań do strony kategorii zakończyła się pojawieniem nowego pliku PHP odpowiadającego kodem 200.
Odczyt konfiguracji i przygotowanie skimmera
Napastnik uzyskał dane bazy, sprawdził zamówienia i zaczął umieszczać elementy fałszywej płatności w module oraz motywie.
Testy i przesyłanie danych
Logi potwierdziły testowanie formularza, komunikację z przekaźnikiem oraz realne wywołania pochodzące z procesu zakupowego.
Rozbudowa mechanizmu ukrywania
Kolejna wersja kodu zaczęła pomijać administratorów i wybrane adresy IP, aby utrudnić wykrycie podczas testów sklepu.
Pełny zakres wykonanych prac naprawczych
- usunięcie wykrytych backdoorów i przekaźnika danych,
- usunięcie skimmera oraz loaderów z motywu sklepu,
- odtworzenie czystych wersji plików JavaScript i szablonów,
- wyczyszczenie zainfekowanych plików cache motywu i cache filtrów w bazie,
- zabezpieczenie katalogu modułu przed bezpośrednim wykonywaniem plików PHP,
- zablokowanie publicznego dostępu do dumpów SQL, logów i pomocniczych skryptów administracyjnych,
- sprawdzenie kont administratorów, sesji, integracji i zewnętrznych skryptów,
- przygotowanie paczki wdrożeniowej z zachowaniem struktury katalogów FTP,
- kontrola składni zmodyfikowanych plików i ponowny skan wskaźników infekcji,
- przygotowanie raportu technicznego, chronologii i listy dalszych działań.
Czyszczenie plików to nie koniec procedury
Po takim incydencie trzeba wymienić hasła i klucze do hostingu, SFTP/SSH, bazy, Redis, panelu sklepu, poczty, operatora płatności, integratora zamówień, przewoźników i pozostałych API. Klucze płatności powinny zostać wygenerowane ponownie dopiero po zakończeniu czyszczenia.
Rezultat: sklep przygotowany do bezpiecznego przywrócenia
Usunięte wykryte zagrożenia
Backdoory, skimmer, loadery i zainfekowane kopie cache zostały usunięte lub bezpiecznie zastąpione.
Ustalony wektor ataku
Logi potwierdziły wykorzystanie podatnego modułu, a nie ręczną instalację podejrzanej wtyczki przez pracownika.
Zakończenie tego samego dnia
Analiza, naprawa, wdrożenie zabezpieczeń i raport zostały przygotowane w trybie pilnym.
Klient otrzymał także listę kont i dostępów do zmiany, zalecenie wygenerowania nowych kluczy operatora płatności oraz aktualizacji pozostałych modułów do najnowszych wersji zgodnych z używaną wersją PrestaShop.
Nie deklaruję, że jakikolwiek sklep jest „bezpieczny w 100%”. Po incydencie kluczowe są również rotacja dostępów, aktualizacje, monitoring zmian plików i dalsza obserwacja logów.
Powiązane case studies
Najczęstsze pytania po infekcji sklepu PrestaShop
Czy wystarczy usunąć wykryty złośliwy plik?
Nie. Backdoor może służyć do tworzenia kolejnych kopii, a kod wykonujący skimmer może znajdować się jednocześnie w module, motywie, bazie i cache.
Czy atak wymagał hasła administratora?
W analizowanym przypadku nie. Podatność umożliwiała zapisanie pliku bez logowania do panelu. Po wejściu atakujący odczytał jednak konfigurację i mógł uzyskać kolejne dane dostępowe.
Czy komputery w biurze trzeba sprawdzić?
Tak, profilaktycznie należy przeskanować urządzenia używane do panelu, hostingu, FTP i poczty. Dostępne dowody wskazywały na podatność sklepu jako pierwotny wektor, ale hasła trzeba zmieniać dopiero z uznanego za bezpieczny komputera.
Kiedy można ponownie uruchomić płatności?
Po oczyszczeniu sklepu, aktualizacji podatnych elementów, wymianie dostępów i wygenerowaniu nowych kluczy operatora płatności. Wcześniejsze klucze należy traktować jako unieważnione.
Jak ograniczyć ryzyko podobnego incydentu?
Regularnie aktualizować moduły, usuwać nieużywane wtyczki z serwera, monitorować integralność plików, ograniczyć dostęp SFTP, przechowywać backupy poza katalogiem publicznym i analizować alerty operatorów płatności.