Usunięcie malware z Prestashop - poradnik i support

Spis treści

Kiedy koszyk nie jest tym, czym się wydaje

PrestaShop napędza około 300 000 sklepów internetowych na świecie, więc skala jest spora. I właśnie dlatego ataki podmieniające checkout to ciągle żywy problem, który nabrał tempa w 2026 roku.

Dlaczego właśnie teraz: fala ataków 2026

Świeży przykład? W dniach 16-20.02.2026 firma Sansec wykryła aktywny skimmer w sieci spożywczej o przychodach rzędu 100 mld €. Atak trwał kilka dni, mimo że zespół bezpieczeństwa dostał powiadomienia. To pokazuje, jak trudno jest wyłapać taki malware w praktyce, nawet w dużych organizacjach.

A co więcej, styczeń 2026 przyniósł oficjalny alert od zespołu PrestaShop dotyczący skryptów wstrzykiwanych w „head.tpl” i domen typu „plvb.su/bt.js”. To nie był jednorazowy incydent, raczej część większej fali ataków, która się nie zatrzymała.

Problem w tym, że właściciele sklepów często nie widzą podrobionego checkoutu, bo malware potrafi się ukrywać przed administratorami (pokazuje fałszywą stronę tylko klientom). Dla biznesu to oznacza realne straty: utratę zaufania klientów, chargebacki, kar RODO za wyciek danych. Jak rozpoznać taki atak i co zrobić, żeby go usunąć? Dokładnie to pokażę w kolejnych sekcjach.

Jak działa skimmer na PrestaShop: mechanika ataku

Skimmer podmieniający checkout to nie jest prosty „złośliwy skrypt”. To elastyczna infrastruktura, która ukrywa się w wielu miejscach i dynamicznie dostosowuje zachowanie, żeby zbierać dane tylko wtedy, gdy musi i tylko od klientów.

Wejście i ukrywanie: gdzie szukają atakujący

Infekcja ląduje w kilku typowych lokalizacjach:

szablony motywów, zwłaszcza themes/…/_partials/head.tpl lub header.tpl,
moduły checkoutu (np. onepagecheckoutps/…/payment.tpl),
fałszywe lub zainfekowane moduły („mloader”, „simplefilemanager”),
pliki core PrestaShop, np. smarty_cacheresource.php albo IndexController.php,
wpisy w bazie danych (tabele configuration, hook_module, module).

Obfuskacja jest wielowarstwowa. JS używaatob(…) do odkodowania base64, czasem kilka razy w łańcuchu. Klasy mają nazwy jak z natywnych bibliotek (np. „smarty_internal_validation”). MutationObserver śledzi zmiany DOM, a skimmer sprawdza obecność selektora #header_employee_box lub zmiennej psAdmin, żeby ukryć się przed zalogowanym adminem.

Od triggera do kradzieży: aktywacja i exfiltracja

Aktywacja jest warunkowa. Skimmer odpala się tylko na stronach checkoutu. Używa jednego z trybów: „replace” (całkowite podmienienie formularza), „overlay” (nakładka graficzna na prawdziwym), „popup” (okienko pytające o dane płatnicze). Czasem stosują „double-tap skimming”, gdzie najpierw pokazują fejkowy formularz, zbierają dane, a potem pozwalają dokończyć transakcję normalnie.

Zebrane dane trafiają jako JSON w base64 via GET lub POST do domen jakstylemercedes.top/api/send-metrics, często z parametrem typu ?pop=7. Niektóre warianty używają openssl_public_encrypt i wysyłają do endpointów w stylu fastfixtuning.nl/cache/cache.php.

Persistence? Ciasteczka blokują powtórne pojawianie się skimmingu u tego samego użytkownika. Webshelle (np.blm.php) pozwalają atakującym wracać. Loader uruchamia kolejne ładunki przez Function(x.responseText)() i trzyma dostęp latami.

Rozpoznaj infekcję: objawy, IoC i szybka weryfikacja

Kiedy PrestaShop zaczyna się dziwnie zachowywać, potrzebujesz szybkiej listy kontrolnej. IoC (Indicators of Compromise) to konkretne ślady, które potwierdzają, że coś jest nie tak, zanim zaczniesz grzebać w kodzie na oślep.

Szybka lista IoC: co powinno zapalić czerwoną lampkę

Sprawdź te sygnały natychmiast:

Ostrzeżenie Google Safe Browsing o złośliwym oprogramowaniu przy Twojej domenie
Przyciski na checkoucie aktywują się co 1,5 sekundy (zauważalne przy powolnym wypełnianiu)
Checkout wygląda inaczej dla zalogowanego admina niż dla zwykłego klienta
LocalStorage przeglądarki zawiera klucze typu „mn_cardNum” po próbie zakupu
Pliki core mają zmienione timestampy z ostatnich dni, choć nie aktualizowałeś sklepu
Spam z Twojej domeny nagle eksplodował (bounce’y w skrzynce)

W kodzie szukaj: znaczniki<script> z „XMLHttpRequest” lub „atob(„, zwłaszcza w head.tpl motywu. Długie ciągi base64 w nieoczekiwanych miejscach. Podejrzane PHP jak „blm.php”, „get-file-admin.php”, „XsamXadoo_Bot.php” w katalogach modułów.

Gdzie sprawdzić: pliki, konsola i logi

Otwórz DevTools (zakładka Sieć) i przejdź przez checkout. Szukaj requestów do domen typu „stylemercedes.top/api/send-metrics”, „fastfixtuning.nl/cache/cache.php” albo dziwnych zapytań „/index.php?pop=7”. Jeśli widzisz POST z danymi karty, masz potwierdzenie.

Przejrzyj katalogi motywu (/themes/) i modułów płatności. Logi serwera pokażą nietypowe requesty z ostatnich tygodni. Timestampy plików to prosty trop, wystarczy ls -la i patrzeć na daty. Większość infekcji zostawia bałagan właśnie tam.

Natychmiastowe odcięcie i czyszczenie krok po kroku

Kiedy potwierdzisz infekcję, czas na działanie. Cel jest prosty: odciąć atakującego od sklepu i przywrócić zaufaną wersję plików. Bez paniki, ale też bez zwłoki – szybki support prestashop 24h.

Izolacja i backup przed jakimkolwiek ruszaniem plików

Najpierw pełna kopia. Skopiuj całą strukturę katalogów PrestaShop (FTP/SSH) oraz zrzuć bazę danych (phpMyAdmin lubmysqldump). To twój dowód i bezpieczna sieć na wypadek, gdyby coś poszło nie tak. Włącz tryb konserwacji w panelu albo po prostu zmień hasło FTP tymczasowo, żeby nikt nie wchodził. Zapisz znaczniki czasu plików (np. ls -lR > timestamps.txt) – przyda się to później do analizy, kiedy dokładnie coś zostało zmienione.

Skanowanie i usuwanie: co sprawdzić i jak czyścić

Użyj narzędzi typu Quttera, skanerów MoeSec lub własnych skryptów do wykrycia webshelli. Ręcznie sprawdź:

Szablon „head.tpl” (tam najczęściej siedzi skimmer JavaScript)
Moduły checkoutu jak „onepagecheckoutps” lub podobne
Katalogi /modules/, /override/, /img/ na pliki typu „blm.php”, „XsamXadoo_Bot.php”
Podejrzane skrypty JS w /js/ (np. „dfsasdf3124sfcad2.js”)

Skasuj wszystko złośliwe. Przywróć oryginalne pliki z czystej paczki tej samej wersji PrestaShop (pobierz ze strony oficjalnej). Niektórzy używają „cleaner.php” – skrypt tworzy backup i nadpisuje kluczowe pliki rdzenia, ale ostrożnie, może nadpisać twoje customizacje.

Po wyczyszczeniu zmień wszystkie hasła: admin PrestaShop, baza danych, FTP, SSH, panel hostingu. Następnie aktualizuj rdzeń PS i wszystkie moduły/szablony do najnowszych wersji z poprawkami bezpieczeństwa (luki z 2022 roku dalej krążą).

Dowody, zgłoszenia i zgodność z RODO

Od IoC do raportu: co musi znaleźć się w dokumentacji

Wyciągnięcie złośliwego kodu to dopiero połowa roboty. Teraz musisz zbudować solidną dokumentację incydentu, bo bez niej zarówno zgłoszenie RODO, jak i ewentualne śledztwo rozmyją się w domysłach.

Na początek: zachowaj kopie wszystkich logów serwera i aplikacji z okresu, w którym malware mogło działać. Zarchiwizuj konkretne IoC, czyli wskaźniki kompromitacji:

domeny jak „stylemercedes.top/api/send-metrics” czy inne egzotyczne endpointy,
ścieżki typu „/index.php?pop=7” lub podejrzane pliki w katalogach modułów,
znaczniki czasowe pierwszego i ostatniego pojawienia się kodu w plikach szablonów checkout,
user-agenty i IP, z których próbowano pobrać skradzione dane.

Teraz ustal zakres wycieku: które dane klientów mogły wyciec? Numery kart, data ważności, CVV, adres rozliczeniowy, user-agent przeglądarki. Pamiętaj, że większość skimmerów świetnie ukrywa się przed adminem zalogowanym w panelu (warunek !preg_match('/employeeprofile/i', $currentController) blokuje wyświetlanie w backoffice). Odtwórz oś czasu na podstawie logów – w znanym przypadku z 2025 roku aktywność trwała między 16 a 20 lutego, co pozwoliło oszacować liczbę potencjalnie dotkniętych transakcji.

RODO w praktyce: 72 godziny i kogo powiadomić

Od momentu wykrycia naruszenia masz 72 godziny na zgłoszenie do PUODO (choć w praktyce licznik biegnie od chwili stwierdzenia, więc ważne, żeby mieć dowód, kiedy zauważyłeś problem). Jeśli ryzyko dla praw klientów jest wysokie – a wyciek danych kart prawie zawsze spełnia ten warunek – musisz też powiadomić poszkodowanych.

Oprócz PUODO poinformuj:

operatora płatności lub bank akceptujący karty (możliwa blokada na poziomie bramki),
klientów, których transakcje przypadły na okno ataku (jasny komunikat: co się stało, jakie dane, co robisz),
ubezpieczyciela cyber-polisy, jeśli masz.

Wszystko zapisz w rejestrze naruszeń: co się stało, kiedy wykryłeś, kogo powiadomiłeś, jakie kroki podjąłeś. To nie tylko obowiązek prawny, ale też dowód, że działałeś rozsądnie i w terminie.

Utwardzanie sklepu: trwała ochrona przed podmianą checkoutu

Kiedy już raz oczyścisz sklep, ostatnie czego chcesz to powtórka za tydzień. Prewencja kosztuje grosze w porównaniu do kolejnego ataku, więc teraz czas na zabezpieczenia, które rzeczywiście działają.

Aktualizacje, WAF i monitoring: trzy filary prewencji

Zacznij od podstaw. PrestaShop w najnowszej wersji to nie fanaberia, to konieczność. Historyczne luki, takie jak łańcuch SQLi/eval z 2022 roku, pokazały, jak szybko przestarzały rdzeń staje się otwartą bramą. To samo dotyczy modułów: audytuj dodatki regularnie, zwłaszcza te od mniejszych twórców. Pamiętasz „pkfacebook”? Exploitowany wielokrotnie, a ludzie wciąż go używali.

WAF typu Sucuri odsieje większość prób wstrzyknięcia skryptów zanim dotrą do serwera. Dodaj twarde nagłówki bezpieczeństwa i reCAPTCHA przeciw botom, które próbują dropować pliki przez stare formularze. Monitoring integralności to Twój radar wczesnego ostrzegania: narzędzia jak Prestavault, Quttera czy MoeSec powinny alarmować przy każdej zmianie w „head.tpl”, szablonach czy core. Jeśli coś się pojawi nocą w pliku kasy, chcesz to wiedzieć od razu.

Dobre praktyki specyficzne dla PrestaShop

Uprawnienia: osobne konta dla każdego, kto dotyka sklepu, zero współdzielonych loginów FTP. Kopie zapasowe offline i regularne testy odtwarzania, bo backup bez weryfikacji to iluzja bezpieczeństwa.

Przejrzyj moduły checkout (np. „onepagecheckoutps”) pod kątem aktualizacji. Cache Smarty w MySQL? Używaj ostrożnie lub wyłącz, jeśli masz wątpliwości. Porzuć niesupportowane rozwiązania, naprawdę. Segmentacja hostingów per serwis też pomaga: jeśli coś się włamie do sklepu, nie dostaną od razu dostępu do bazy mailingowej.

W sumie to tyle. Większość ataków liczy na lenistwo właściciela, więc samo bycie o krok przed nimi daje przewagę.

Bezpieczny checkout to przewaga, nie luksus

Kiedy sklep zostaje oczyszczony z malware, właściciele często odetchną z ulgą i wracają do normalności. Ale to moment, żeby zrobić krok dalej. Checkout, który przeszedł atak, teraz może być najmocniejszym argumentem sprzedażowym. Klienci coraz częściej patrzą na bezpieczeństwo jako na podstawowy wymóg, nie dodatek. Sklep, który transparentnie komunikuje swoje zabezpieczenia (certyfikaty SSL, regularne audyty, aktualizacje), buduje zaufanie szybciej niż konkurencja, która po prostu milczy na ten temat.

Bezpieczny proces płatności to już nie tylko kwestia ochrony danych. To sygnał, że sklep traktuje klientów poważnie. A to się zwraca, dosłownie. Wyższe współczynniki konwersji, mniej porzuconych koszyków, lepsza reputacja. Trudno o lepszy zwrot z inwestycji w coś, co i tak powinno być zrobione od początku.

Zainfekowany PrestaShop – jak usunąć malware podmieniające checkout