Reakcja na wyciek danych: co zrobić, gdy Twój sklep zostanie zhakowany

Najgorszy moment na układanie planu reagowania na incydent to druga w nocy, kiedy patrzysz na e-mail od klienta: „podczas płatności karta została obciążona dwa razy, a teraz dostaję SMS-y phishingowe”. Jeśli prowadzisz sklep PrestaShop wystarczająco długo, istnieje realna szansa, że kiedyś trafisz na włamanie — małe i średnie sklepy są atakowane stale, nie dlatego, że ktoś wybrał je osobiście, ale dlatego, że automatyczne skanery masowo sprawdzają znane luki w PrestaShop i modułach w całej sieci, a potem naciskają każdą klamkę, która nie jest zamknięta. Ten poradnik to procedura na czas po uruchomieniu alarmu: spokojna, uporządkowana sekwencja tego, co sprawdzić, co zabezpieczyć i które miejsca typowe dla PrestaShop atakujący prawie na pewno dotknął. Celowo nie jest to poradnik prewencyjny — jeśli czytasz go, zanim cokolwiek poszło źle, zacznij raczej od checklisty wzmacniania bezpieczeństwa PrestaShop.

Przeczytaj to raz teraz, kiedy nic się jeszcze nie pali. Najważniejszym czynnikiem czystego odzyskania sklepu jest znajomość kolejności działań, zanim naprawdę będziesz jej potrzebować.

Zweryfikowano w czerwcu 2026 r. względem aktualnych układów plików i baz danych PrestaShop 1.6, 1.7, 8 i 9 oraz obowiązującej w chwili pisania zasady GDPR dotyczącej zgłoszenia naruszenia w ciągu 72 godzin.

Zanim czegokolwiek dotkniesz: zabezpiecz dowody

Lupa przesuwa się nad siatką świecących ikon plików i folderów, kilka z nich podświetlonych na pomarańczowo.

Jeśli masz dostęp do powłoki, skopiuj pliki, bazę danych i logi, zanim cokolwiek usuniesz. Dostosuj nazwę bazy danych i ścieżki do swojego hostingu.

#!/usr/bin/env bash
set -euo pipefail

stamp=$(date +%F-%H%M%S)
case_dir="/root/prestashop-incident-$stamp"
mkdir -p "$case_dir"

tar --xattrs --acls -czf "$case_dir/files.tgz" /var/www/html
mysqldump --single-transaction --routines --triggers prestashop > "$case_dir/database.sql"
cp -a /var/log/nginx /var/log/apache2 /var/log/php* "$case_dir/" 2>/dev/null || true

sha256sum "$case_dir"/* > "$case_dir/SHA256SUMS"
chmod -R go-rwx ";$case_dir

Naturalny odruch to zalogować się do panelu administracyjnego i zacząć usuwać podejrzane pliki. Powstrzymaj się. W chwili, gdy zaczynasz coś zmieniać, niszczysz ślady, które pokazują, jak atakujący dostał się do środka — a jeśli nie znajdziesz punktu wejścia, sklep zostanie ponownie przejęty w ciągu kilku dni. Twoje pierwsze działanie to kopiowanie, nie czyszczenie.

Wykonaj pełną migawkę przed jakąkolwiek naprawą:

• Cały katalog WWW — katalog PrestaShop wraz z ukrytymi plikami (.htaccess, .user.ini). Atakujący uwielbiają te miejsca, bo mało kto je audytuje.
• Zrzut bazy danych — wykonaj mysqldump całej bazy. Wstrzyknięty kod często znajduje się w bazie danych, nie tylko na dysku (więcej poniżej).
• Logi — logi dostępu i błędów serwera WWW (/var/log/nginx/ lub /var/log/apache2/), logi PHP-FPM oraz własne logi PrestaShop w var/logs/ (PS 1.7+) albo log/ (PS 1.6). Logi rotują i znikają; pobierz je jako pierwsze.

Przechowuj tę migawkę w miejscu, do którego atakujący nie ma dostępu — na swoim laptopie albo w świeżym zasobniku na dane, a nie w drugim folderze na tym samym przejętym serwerze. To właśnie o tę migawkę poprosi dział abuse hostingu, specjalista od informatyki śledczej albo ubezpieczyciel cybernetyczny, i tylko dzięki niej da się później odtworzyć oś czasu.

Zatrzymaj wyciek, nie niszcząc miejsca zdarzenia

Izolacja incydentu i informatyka śledcza ciągną w przeciwne strony: chcesz zatrzymać szkody, ale wyciągnięcie wtyczki może skasować ulotne dowody (aktywne sesje, procesy atakującego). Rozsądny kompromis dla typowego sklepu: wyłącz część sklepu widoczną dla klientów, ale zostaw sam serwer włączony, żeby można było prowadzić analizę.

PrestaShop ma wbudowany tryb konserwacji. W panelu administracyjnym przejdź do Parametry sklepu → Ogólne → Przerwa techniczna (PS 1.7/8/9), wyłącz sklep, a potem dodaj własny adres IP do pola IP przerwy technicznej, żeby móc dalej pracować, podczas gdy klienci zobaczą stronę informacyjną. Odpowiadają za to flagi PS_SHOP_ENABLE i PS_MAINTENANCE_IP w tabeli ps_configuration — przydatne, jeśli sam panel administracyjny jest zablokowany albo podmieniony i trzeba przełączyć sklep bezpośrednio w bazie danych.

Jeśli w grę mogą wchodzić dane płatnicze, tryb konserwacji nie wystarczy — i nie zaczynaj od przeszukiwania plików. Dwa telefony mają pierwszeństwo przed całą techniczną resztą:

• Twój operator płatności. Stripe, PayPal, Mollie, Adyen, bank rozliczeniowy — każdy, kto rozlicza Twoje pieniądze. Mają zespoły antyfraudowe, które mogą obserwować wzorce testowania kart i oznaczyć karty objęte incydentem. Jeśli do procesu płatności wstrzyknięto skimmer kart, właśnie tak narażone karty trafiają pod monitoring, zanim zostaną nadużyte.
• Twój hosting. Wiele przejęć zaczyna się na poziomie konta hostingowego, a nie samej instalacji PrestaShop, i hosting widzi rzeczy, których Ty nie zobaczysz: inne strony na tym samym koncie, spam wychodzący, cron kopiący kryptowaluty.

Gdzie atakujący naprawdę chowają się w PrestaShop

To jest część, którą ogólne artykuły typu „zostałeś zhakowany” zwykle pomijają, a od niej zależy wszystko. Znajomość konkretnych miejsc, w których żyją infekcje PrestaShop, zamienia beznadziejne „przeskanuj wszystko” w celowane polowanie. W przybliżonej kolejności częstotliwości, z jaką je widzimy:

Praktyczny pierwszy przegląd na serwerze: wypisz każdy plik PHP zmodyfikowany w ostatnich 30 dniach i przeczytaj każdy, którego nie rozpoznajesz. Z katalogu głównego WWW polecenie find . -name "*.php" -mtime -30 -ls pokaże niedawno dotykane pliki; porównaj je z czystą kopią tej samej wersji PrestaShop (pobierz dokładne wydanie z oficjalnej strony), żeby odróżnić pliki rdzenia od podmienionych. Szczególną uwagę zwróć na jakiekolwiek PHP znajdujące się w img/ lub upload/ — te katalogi nigdy nie powinny zawierać wykonywalnego PHP, a jedna linia w .htaccess, która blokuje wykonywanie PHP w tym miejscu, jest jednym z najtańszych sposobów utwardzenia sklepu po jego wyczyszczeniu.

Wrzuć niewielki plik .htaccess do każdego katalogu przesyłania plików (img/, upload/, download/), żeby nawet jeśli webshell znowu tam trafi, serwer odmówi jego uruchomienia. Dla Apache 2.4:

# img/.htaccess (and upload/, download/) — refuse to execute PHP
<FilesMatch "\.(php|php\d|phtml|phar)$">
    Require all denied
</FilesMatch>
php_flag engine off

To izolacja, nie naprawa: zatrzymuje wykonanie podrzuconego webshella, ale nie mówi nic o tym, jak plik został tam zapisany — od tego jest poniższe szukanie punktu wejścia.

Po stronie bazy danych zrzuć tabelę i porównaj listę ps_employee z osobami, które faktycznie zatrudniasz, a następnie przeszukaj treści CMS i konfigurację pod kątem <script, base64_decode, eval( oraz zewnętrznych domen, których nie rozpoznajesz. Jeśli okaże się, że naruszenie było konkretnie skimmerem w procesie płatności, warto dokładnie zrozumieć mechanikę wejścia i wyprowadzania danych kart — rozebraliśmy prawdziwy przypadek w artykule anatomia ataku w stylu Magecart na sklep PrestaShop.

Zamknij drzwi: rotacja każdego poświadczenia, które atakujący mógł zdobyć

Załóż, że atakujący ma kopię wszystkiego, co mógł odczytać, i wymień to wszystko. W PrestaShop „wszystko” oznacza więcej, niż większość osób zakłada, a pominięcie jednego elementu pozwala wrócić prosto do środka:

• Hasło każdego pracownika panelu administracyjnego — i usuń każde konto, którego nie potrafisz wyjaśnić. Wymuś reset w całym zespole, nie tylko u siebie.
• Poświadczenia bazy danych w config/settings.inc.php (PS 1.6) albo app/config/parameters.php (PS 1.7+). Zmień hasło użytkownika MySQL i zaktualizuj plik w tym samym kroku.
• Klucze cookies — stałe _COOKIE_KEY_/_COOKIE_IV_ w settings.inc.php w PS 1.6 albo wartości cookie_key/cookie_iv (oraz new_cookie_key, jeśli występuje w PS 8/9) w parameters.php w PS 1.7+. Jeśli wyciekły, stare administracyjne ciasteczka sesyjne mogą nadal być ważne. Sama rotacja kluczy nie wystarczy: po rotacji wyczyść aktywne sesje po stronie serwera i pamięć podręczną, a potem wymuś wylogowanie oraz reset hasła u każdego pracownika — dopiero to faktycznie zabija sesję atakującego.
• Loginy FTP/SFTP, SSH i panelu hostingowego — skradzione hasło FTP to najczęstszy sposób ponownego zainfekowania „wyczyszczonej” strony w ciągu kilku godzin.
• Wszelkie klucze API / sekrety webhooków dla integracji płatności i dostaw zapisane w konfiguracji modułów.

Po rotacji poświadczeń to właściwy moment, żeby na dobre zamknąć drzwi, włączając uwierzytelnianie dwuskładnikowe w panelu administracyjnym, tak aby samo wyciekłe hasło nie wystarczało — instrukcja jest w artykule uwierzytelnianie dwuskładnikowe, polityki haseł i bezpieczeństwo administracji w PrestaShop. Jeśli analiza pokazała, że atak wszedł przez masowe próby logowania albo nadużywające adresy IP, dołożenie blokad IP i reCAPTCHA na formularzu logowania ograniczy automatyczne ataki na logowanie. Nie traktuj tego jednak jako pełnej naprawy — reCAPTCHA da się obejść i nie pomaga przy automatycznym sprawdzaniu skradzionych loginów i haseł, dlatego połącz ją z 2FA, limitami prób logowania i ograniczaniem ruchu z IP, silnymi unikalnymi hasłami pracowników oraz monitoringiem logów.

Zegar 72 godzin: Twoje obowiązki wynikające z GDPR

Jeśli Twój sklep ma europejskich klientów — a jeśli wysyłasz do UE albo używasz europejskiego operatora płatności, to ma — GDPR zmienia incydent techniczny w sprawę prawną z twardym terminem. Zasada, na której ludzie często się potykają: masz 72 godziny od stwierdzenia naruszenia na powiadomienie organu nadzorczego (organu ochrony danych w Twoim kraju), chyba że naruszenie prawdopodobnie nie powoduje ryzyka dla praw osób. Naruszenie obejmujące hasła klientów, adresy albo dane płatnicze bez trudu przekracza ten próg, więc przygotuj się na zgłoszenie.

Jeśli naruszenie może powodować wysokie ryzyko dla osób fizycznych — a dane płatnicze i hasła znów się kwalifikują — musisz także powiadomić dotkniętych klientów bezpośrednio, prostym językiem, wyjaśniając, co się stało, jakie dane były objęte incydentem, co robisz i co oni powinni zrobić (zmienić hasło, obserwować wyciągi, spodziewać się phishingu odwołującego się do naruszenia). Właśnie dlatego migawka dowodowa z pierwszego kroku jest tak ważna: nie napiszesz uczciwego powiadomienia, jeśli zniszczysz dane pokazujące, do czego faktycznie uzyskano dostęp. Zegar 72 godzin startuje, gdy stajesz się świadomy naruszenia, a nie gdy kończysz analizę — dlatego pierwsze zgłoszenie często wychodzi, gdy naprawa wciąż trwa, a później dosyła się uzupełnienie. To dopuszczalne i oczekiwane.

Jedna praktyczna uwaga, którą łatwo przeoczyć: ten zegar biegnie równolegle do wszystkiego innego z tego poradnika. Izolacja, informatyka śledcza i zgłoszenie prawne dzieją się jednocześnie, co jest głównym powodem, aby od pierwszej godziny prowadzić bieżący, opatrzony znacznikami czasu dziennik każdego działania. Ten dziennik jest zarazem Twoją osią czasu incydentu i dowodem należytej staranności, jeśli zapyta o nią regulator.

Jak powiedzieć klientom, żeby nie pogorszyć sytuacji

Klienci wybaczają sklepowi, który powiedział im pierwszy, i mają pretensje do tego, o którym usłyszeli z banku albo z wiadomości. Zadaniem powiadomienia jest uczciwość i użyteczność, nie minimalizowanie problemu. Napisz ludzkim językiem, co się stało, dokładnie które z ich danych były objęte incydentem i jakie konkretne działania powinni podjąć — a odpowiedzi skieruj w miejsce, które nie zaleje zwykłego wsparcia. Osobny adres do obsługi naruszenia utrzyma spanikowane wiadomości „czy mnie to dotyczy?” poza kolejką pytań o zamówienia.

Przygotuj się też na oportunistów: powiadomienia o naruszeniach są pożywką dla phisherów, którzy podszyją się pod Ciebie, żeby „pomóc klientom zresetować hasło”. Powiedz klientom w powiadomieniu dokładnie, którego kanału będziesz używać i że nigdy nie poprosisz ich o hasło — kosztuje to jedno zdanie, a zapobiega drugiej fali ofiar.

Nie przywracaj infekcji: odbudowa z czystego stanu

Najczęstszy błąd podczas odzyskiwania to przywrócenie wczorajszej kopii zapasowej. Jeśli atakujący był w środku od dwóch tygodni, wczorajsza kopia zawiera również backdoor — przywrócisz naruszenie i odkryjesz je ponownie w przyszłym miesiącu. Cofaj się od migawki dowodowej, aby ustalić, kiedy pojawił się pierwszy złośliwy plik albo wiersz pracownika, a następnie albo przywróć kopię starszą niż ten moment, albo, bardziej niezawodnie, odbuduj sklep na czysto:

• Zainstaluj ponownie rdzeń PrestaShop ze świeżo pobranego dokładnego wydania — wymień pliki rdzenia w całości, zamiast próbować czyścić je chirurgicznie.
• Zainstaluj ponownie każdy moduł z jego oryginalnego źródła (od dewelopera, nie z potencjalnie podmienionej kopii). Wszystko, czego nie możesz pozyskać w czystej formie, usuń.
• Ponownie zastosuj tylko te pliki override/ i zmiany motywu, które potrafisz jednoznacznie uzasadnić.
• Migruj dane (zamówienia, klientów, produkty) z bazy danych, ale dopiero po wyczyszczeniu ich z wstrzykniętych ładunków.

To także właściwy moment, żeby poprawić strategię kopii zapasowych, tak aby czysta odbudowa była w ogóle możliwa następnym razem: automatyczne codzienne kopie, przechowywane poza serwerem produkcyjnym, z wystarczająco długą retencją (myśl o 30+ dniach), żeby dało się sięgnąć wstecz przed powoli rozwijające się przejęcie. Kopia zapasowa sięgająca tylko trzy dni wstecz jest bezużyteczna wobec atakującego, który siedział cicho przez dwa tygodnie.

Gdy kurz opadnie: zamknij wektor na dobre

Podczas analizy znalazłeś punkt wejścia — teraz zamknij go trwale, bo ponowne przejęcie przez tę samą dziurę jest najczęstszym dalszym ciągiem naruszenia. Naprawa zależy od tego, co wykazało dochodzenie:

• Nieaktualny PrestaShop albo podatny moduł? Zaktualizuj. Jeśli naprawdę nie możesz jeszcze podnieść rdzenia (częsta rzeczywistość w mocno modyfikowanych sklepach 1.6/1.7), wirtualne łatanie pozwala zablokować znany exploit na warstwie żądania bez dotykania kodu — opisaliśmy to w zaawansowanym wzmacnianiu sklepów, których nie da się jeszcze zaktualizować.
• Słabe albo używane ponownie hasło administratora? Polityka haseł plus 2FA, zgodnie z poradnikiem bezpieczeństwa administracji.
• Brak bezpieczeństwa transportu albo nieszczelny .htaccess? Popraw HTTPS (konfiguracja SSL/HTTPS) i dopnij reguły serwera (reguły bezpieczeństwa .htaccess), w tym blokadę wykonywania PHP w katalogach przesyłania plików.
• Nie wiesz nawet, od czego zacząć wzmacnianie? Przystępne omówienie dla osób nietechnicznych to zabezpieczanie sklepu PrestaShop, a pełna wersja to checklista wzmacniania bezpieczeństwa.

Najczęściej zadawane pytania

Skąd mam wiedzieć, czy mój sklep PrestaShop naprawdę został zhakowany, czy to tylko spam?

Szukaj rzeczy, których spamer nie podrobi: wiersza ps_employee, którego nie utworzyłeś, plików PHP zmodyfikowanych w ostatnich dniach bez Twojej ingerencji (find . -name "*.php" -mtime -7), wykonywalnego PHP w img/ lub upload/, niespodziewanego <script albo base64_decode na stronach CMS lub w konfiguracji, albo przekierowywania sklepu gdzie indziej dla odwiedzających, ale nie dla Ciebie. Śmieciowe koszyki i spam z formularzy są hałaśliwe, ale nieszkodliwe; nowe konta administratorów, wstrzyknięte skrypty i podmienione pliki rdzenia oznaczają przejęcie.

Czy powinienem od razu wyłączyć sklep?

Wyłącz część sklepu widoczną dla klientów trybem konserwacji, ale zostaw serwer uruchomiony, żeby móc prowadzić analizę. Wyłączenie całej maszyny usuwa ulotne dowody (aktywne sesje, procesy atakującego), zanim ustalisz, jak dostał się do środka — a bez punktu wejścia sklep zostanie ponownie zainfekowany w ciągu kilku dni. Jeden wyjątek to aktywny skimmer kart w procesie płatności: wtedy najpierw zatrzymujesz szkodę dla klientów i równolegle kontaktujesz się z operatorem płatności.

Czy nie mogę po prostu przywrócić wczorajszej kopii zapasowej i iść dalej?

Zwykle nie. Jeśli atakujący był w środku od dwóch tygodni, wczorajsza kopia zawiera też backdoor, więc przywrócisz naruszenie i odkryjesz je ponownie w przyszłym miesiącu. Cofnij się od migawki dowodowej, aby znaleźć moment pojawienia się pierwszego złośliwego pliku albo wiersza pracownika, a potem przywróć kopię starszą niż ten moment — albo, pewniej, odbuduj sklep na czysto ze świeżo pobranego rdzenia i oryginalnych źródeł modułów, migrując tylko dane, które zostały przeszukane i oczyszczone.

Czy muszę komuś zgłosić naruszenie?

Jeśli Twój sklep ma klientów z UE, a naruszenie dotknęło danych osobowych (haseł, adresów, danych płatniczych), GDPR daje Ci 72 godziny od stwierdzenia naruszenia na powiadomienie organu nadzorczego, a jeśli ryzyko dla klientów jest wysokie, musisz powiadomić ich bezpośrednio. Zegar startuje w chwili, gdy dowiadujesz się o naruszeniu, nie po zakończeniu dochodzenia, więc pierwsze zgłoszenie często wychodzi, gdy naprawa nadal trwa, a później dosyła się uzupełnienie. To normalne.

Jak zapobiec powtórce?

Zamknij dokładny wektor znaleziony przez analizę śledczą — załataj nieaktualny rdzeń albo moduł, wyeliminuj słabe hasło administratora, napraw nieszczelny katalog przesyłania plików — bo ponowne przejęcie przez tę samą dziurę jest najczęstszym dalszym ciągiem naruszenia. Potem dodaj warstwy, które utrudnią następny atak: 2FA w panelu administracyjnym, kopie zapasowe poza serwerem z retencją 30+ dni oraz szerszą checklistę wzmacniania bezpieczeństwa.

Naprawdę trudną częścią odzyskiwania po naruszeniu nie jest samo sprzątanie — tylko pewność, że wszystkie drzwi zostały naprawdę zamknięte, bo jeden pominięty backdoor oznacza powtórkę całej pracy. Jeśli nie chcesz brać tej niepewności wyłącznie na siebie, nasz zespół na co dzień buduje i audytuje sklepy PrestaShop oraz pracuje bezpośrednio z właścicielami sklepów przy dokładnie takich incydentach — bez pośredników i bez warstwy odsprzedawców. Co to oznacza w praktyce? Drugą parę oczu, która wie, gdzie chowają się infekcje PrestaShop, dzięki czemu możesz ponownie otworzyć sklep z przekonaniem, że naprawdę jest czysty, a nie tylko z nadzieją.

Jeszcze jedna rzecz, najważniejsza: gdy tylko minie bezpośredni kryzys, zapisz po kolei, co zrobiłeś, z godzinami i datami. Ten zapis to Twoje dowody na potrzeby GDPR, roszczenie ubezpieczeniowe i — kiedy przeczytasz go spokojnie za tydzień — najuczciwszy audyt bezpieczeństwa własnego sklepu, jaki kiedykolwiek dostaniesz. Większość naruszeń zaczyna się od odłożonej aktualizacji albo hasła, którego używali wszyscy. To nie pech; to lista zadań, której nie masz już wymówki ignorować.