Atak na 953 sklepy internetowe. Jak wykryć złośliwy kod w Magento, usunąć backdoora i zapobiec ponownemu włamaniu?

Sklep internetowy może posiadać wszystkie aktualne poprawki bezpieczeństwa, przechodzić kontrole antywirusowe i prawidłowo obsługiwać zamówienia, a mimo to pozostawać pod kontrolą cyberprzestępców. Potwierdza to kampania malware, którą badacze bezpieczeństwa Sansec śledzą od lipca 2025 roku. Według raportu opublikowanego 24 października 2026 roku działania napastników objęły łącznie 953 sklepy internetowe, przede wszystkim korzystające z Magento i Adobe Commerce.

Najbardziej niepokojący nie jest jednak sam rozmiar ataku. Znacznie poważniejszym problemem okazuje się możliwość wielokrotnego infekowania tych samych witryn. Przestępcy potrafili ponownie umieszczać złośliwy kod w sklepach, w których wcześniej wykryto zagrożenie. W jednym z udokumentowanych przypadków nowe podejrzane skrypty pojawiły się na serwerze z aktualnym oprogramowaniem Magento, zaledwie godzinę po kontroli, która nie wykazała infekcji.

Oznacza to, że aktualizacja sklepu, usunięcie podejrzanego JavaScriptu lub przywrócenie kopii zapasowej nie muszą oznaczać zakończenia włamania. Jeśli napastnik pozostawił ukryte konto administratora, webshell albo inny mechanizm zdalnego dostępu, może odzyskać kontrolę nad witryną i ponownie zagrozić jej klientom.

Jak rozpoznać podobny atak? Gdzie szukać ukrytego kodu? Co zrobić, aby rzeczywiście usunąć infekcję, a nie jedynie jej najbardziej widoczny element?

Co ujawniono w najnowszym raporcie o atakach na Magento?

Październikowa analiza Sansec dotyczy kampanii wykorzystującej niewielkie fragmenty JavaScriptu umieszczane w treściach sklepów internetowych. Kod jest ładowany podczas otwierania strony przez klienta i może komunikować się z serwerami kontrolowanymi przez napastników.

Jednym z takich serwerów jest domena deepveindrilling.com. Zarejestrowano ją 6 października 2026 roku, a już następnego dnia zaczęły pojawiać się pierwsze sklepy pobierające z niej zewnętrzne skrypty.

Badacze zidentyfikowali tę domenę w 83 sklepach. Spośród nich aż 60 było wcześniej powiązanych z poprzednimi etapami tej samej kampanii. W 34 przypadkach ślady wcześniejszej infekcji sięgały października 2025 roku.

Wyniki dochodzenia pokazują kilka istotnych zjawisk:

• Długotrwała obecność napastników: część sklepów pozostawała zagrożona przez wiele miesięcy.
• Wielokrotne infekowanie tych samych witryn: przestępcy ponownie wykorzystywali wcześniej uzyskany dostęp.
• Zmieniająca się infrastruktura: złośliwe skrypty komunikowały się z kolejnymi domenami, utrudniając blokowanie zagrożenia.
• Ukrywanie aktywności: mechanizm analizował środowisko przeglądarki, próbując odróżnić prawdziwych użytkowników od automatycznych narzędzi kontrolnych.
• Wykorzystywanie luk i pozostawionych backdoorów: wcześniejsze włamania wiązano między innymi z podatnościami PolyShell i SessionReaper.

Liczba 953 oznacza łączną liczbę sklepów zidentyfikowanych w całej kampanii od lipca 2025 roku. Nie należy jej interpretować jako liczby nowych włamań z jednego dnia ani potwierdzonych przypadków kradzieży danych płatniczych.

Badacze nie przechwycili jeszcze końcowego ładunku wykonywanego przez najnowszą wersję skryptu. Potwierdzili natomiast istnienie infrastruktury pozwalającej dostarczać nieautoryzowany kod do przeglądarek odwiedzających zainfekowane sklepy.

Dlaczego sklep może wyglądać normalnie pomimo infekcji?

Wielu właścicieli sklepów kojarzy włamanie ze zmianą strony głównej, wyświetlaniem reklam, zablokowaniem panelu administracyjnego albo niedziałającym formularzem płatności.

Nowoczesne kampanie wymierzone w e-commerce nie muszą wywoływać takich objawów.

Z perspektywy klienta produkt nadal ma prawidłową cenę, koszyk działa, a zamówienie można złożyć. Administrator widzi standardowy panel zarządzania, natomiast serwer odpowiada bez zauważalnych problemów.

Równolegle w kodzie strony może działać niewielki fragment JavaScriptu, którego zadaniem jest pobranie dodatkowych instrukcji z zewnętrznego serwera.

Napastnik nie musi przy tym modyfikować głównych plików Magento. Może umieścić odpowiedni kod w bazie danych, na przykład w bloku treści odpowiedzialnym za wyświetlanie informacji na stronie.

Złośliwe skrypty ukryte w blokach CMS

Magento przechowuje wiele elementów zawartości strony w bazie danych. Dotyczy to między innymi bloków informacyjnych, banerów, komunikatów i innych treści wykorzystywanych na różnych podstronach.

W standardowej instalacji bloki takie znajdują się w tabeli cms_block.

Jeżeli cyberprzestępca uzyska odpowiednie uprawnienia, może zmodyfikować treść bloku i umieścić w nim JavaScript. Następnie kod zostanie automatycznie dołączony do strony podczas jej wyświetlania.

Właśnie taki mechanizm zaobserwowano w opisywanej kampanii.

Badanie samych plików szablonu lub rozszerzeń może nie wykazać nieprawidłowości, ponieważ szkodliwa zawartość znajduje się w rekordzie bazy danych.

Rozpoznawanie przeglądarki i omijanie skanerów

23 października napastnicy zmodyfikowali sposób działania wykorzystywanego kodu. Nowa wersja zbierała informacje o środowisku przeglądarki, zanim wysłała żądanie do zewnętrznego serwera.

Sprawdzane mogły być między innymi parametry urządzenia, rozdzielczość ekranu, język, strefa czasowa, informacje o sprzęcie graficznym oraz oznaki korzystania z automatycznej przeglądarki.

Serwer kontrolowany przez przestępców mógł na tej podstawie zdecydować, czy dostarczyć dodatkowy kod, czy odpowiedzieć w sposób, który nie wzbudzi podejrzeń.

W praktyce oznacza to, że narzędzie automatycznie analizujące witrynę może otrzymać inną odpowiedź niż prawdziwy klient sklepu.

Brak wykrycia zagrożenia podczas jednorazowego skanowania nie daje więc pewności, że witryna jest bezpieczna.

Kod pozostający w pamięci przeglądarki

W jednej z wersji ataku wykorzystano mechanizm localStorage, który umożliwia stronie internetowej zapisywanie danych w przeglądarce użytkownika.

Skrypt sprawdzał wartość przechowywaną pod kluczem fpCode i mógł uruchamiać zapisany w niej kod podczas kolejnych odwiedzin.

Takie zachowanie ma ważną konsekwencję: zablokowanie domeny wykorzystywanej przez napastników nie musi natychmiast wyeliminować wcześniej dostarczonego kodu, jeśli zainfekowana strona nadal zawiera mechanizm jego uruchamiania.

Usunięcie złośliwego fragmentu z witryny przerywa ten konkretny sposób wykonywania zapisanych instrukcji. Nie rozwiązuje jednak problemu dostępu przestępcy do serwera lub bazy danych.

Najważniejsze domeny wykorzystywane przez cyberprzestępców

W trakcie kampanii operatorzy zmieniali adresy serwerów używanych do dostarczania kodu. Poniższe domeny zostały wymienione w analizie Sansec jako elementy kolejnych etapów operacji.

Wartości te nie oznaczają odrębnych grup sklepów. Ta sama witryna mogła być wykrywana podczas kilku etapów kampanii, dlatego sumowanie poszczególnych liczb prowadziłoby do zawyżonego wyniku.

Badacze wymienili także domeny hdfdsi84j3h.top oraz c85grt98sd.com, zaobserwowane w mniejszej liczbie przypadków.

Adresy te mogą służyć jako wskaźniki kompromitacji, określane skrótem IOC. Ich występowanie w bazie danych, żądaniach przeglądarki lub zapisach sieciowych wymaga wyjaśnienia.

Jednocześnie brak wymienionych domen nie wyklucza włamania. Adresy mogą zostać zakodowane, zastąpione innymi lub ukryte wewnątrz skryptu.

Jak sprawdzić, czy sklep Magento został zainfekowany?

Skuteczna diagnostyka powinna obejmować jednocześnie zawartość bazy danych, pliki serwera, konta administratorów oraz zachowanie witryny w przeglądarce.

Jeżeli istnieją przesłanki wskazujące na aktywne włamanie, przed rozpoczęciem naprawy należy zabezpieczyć dostępne logi i kopię aktualnego stanu systemu. Pozwoli to ustalić przebieg incydentu oraz uniknąć przypadkowego zniszczenia dowodów.

1. Sprawdzenie zawartości tabeli cms_block

Pierwszym miejscem wymagającym kontroli jest tabela zawierająca bloki CMS.

Administrator posiadający odpowiednie uprawnienia do bazy danych może wykonać zapytanie:

SELECT block_id, identifier, update_time
FROM cms_block
WHERE content LIKE '%fpCode%'
   OR content LIKE '%se_referrer%'
   OR content LIKE '%localStorage.getItem%'
   OR content LIKE '%deepveindrilling%'
   OR content LIKE '%additionalver%';

Zapytanie odczytuje identyfikatory i daty modyfikacji bloków zawierających wybrane charakterystyczne fragmenty kodu lub nazwy domen.

Jeżeli baza wykorzystuje prefiks tabel, należy zastosować właściwą nazwę tabeli.

Wykryte rekordy trzeba sprawdzić w kontekście zawartości sklepu. Samo wystąpienie jednego z analizowanych ciągów znaków nie jest jeszcze wystarczającym dowodem kompromitacji.

Istotne mogą być również daty ostatnich modyfikacji. Warto porównać je z historią prac administracyjnych oraz dostępnością logów dokumentujących zmiany.

2. Kontrola stron przechowywanych w bazie danych

Kolejnym obszarem jest tabela cms_page, która zawiera treści stron CMS.

Można ją sprawdzić analogicznym zapytaniem:

SELECT page_id, identifier, update_time
FROM cms_page
WHERE content LIKE '%fpCode%'
   OR content LIKE '%se_referrer%'
   OR content LIKE '%localStorage.getItem%'
   OR content LIKE '%deepveindrilling%'
   OR content LIKE '%additionalver%';

Warto przyjrzeć się szczególnie stronom zawierającym niestandardowe skrypty oraz treściom modyfikowanym bez wiedzy osób odpowiedzialnych za sklep.

Oba zapytania wykonują wyłącznie odczyt. Nie usuwają rekordów ani nie zmieniają danych.

Nie stanowią jednak kompletnego wykrywacza malware. Wyszukują określone wskaźniki, podczas gdy inne odmiany złośliwego kodu mogą pozostawać niewidoczne.

3. Poszukiwanie plików umożliwiających zdalny dostęp

W analizowanej kampanii stwierdzono przypadki pozostawiania na serwerach plików działających jako webshell.

Webshell jest programem, zwykle napisanym w języku obsługiwanym przez serwer, który umożliwia wykonywanie nieautoryzowanych operacji po uzyskaniu odpowiedniego dostępu.

Niektóre z wykrytych plików były zamaskowane jako obrazy PNG i znajdowały się w katalogach związanych z przesyłanymi plikami.

W katalogu głównym instalacji Magento można sprawdzić wskazane przez badaczy lokalizacje:

find pub/media/custom_options/ pub/media/customer_address/ -type f ! -name '.htaccess'

Warto także wyszukać nazwę pliku pojawiającą się w analizach kampanii:

find . -type f -name 'accesson.php'

Obie komendy wyszukują pliki bez ich modyfikowania. Jeżeli określony katalog nie istnieje w instalacji, pierwsze polecenie może zwrócić stosowny komunikat.

Znalezienie pliku w jednej z tych lokalizacji nie oznacza automatycznie, że jest złośliwy. Konieczne jest sprawdzenie jego rzeczywistego typu, zawartości, historii utworzenia i sposobu obsługi przez serwer.

Szczególnie istotna jest konfiguracja pozwalająca uruchamiać skrypty w katalogach przeznaczonych wyłącznie na pliki użytkowników. Taka możliwość znacząco zwiększa skutki niektórych podatności związanych z przesyłaniem plików.

4. Weryfikacja użytkowników z uprawnieniami administracyjnymi

Włamanie może nie pozostawić widocznego śladu w interfejsie sklepu, ale doprowadzić do utworzenia dodatkowego administratora.

W Magento należy skontrolować tabelę admin_user oraz konfigurację przypisanych ról.

Szczególnej uwagi wymagają konta:

• Nieznane właścicielowi sklepu lub administratorowi systemu.
• Utworzone w okresie podejrzanej aktywności.
• Posiadające uprawnienia szersze niż wynika to z ich przeznaczenia.
• Powiązane z nieznanymi adresami e-mail.
• Nieużywane przez firmę, ale nadal aktywne.
• Wykazujące logowania z nietypowych adresów IP.

Także klucze API, konta integracyjne i dostęp SSH powinny zostać objęte audytem.

W jednym ze sklepów opisanych przez Sansec wcześniej wykryto zarówno nieautoryzowanego administratora, jak i mechanizm zdalnego dostępu GSocket. Pomimo aktualnego stanu poprawek Magento w witrynie pojawił się później kolejny złośliwy loader.

5. Analiza połączeń wykonywanych podczas zakupów

Kontrola przeglądarki powinna uwzględniać nie tylko stronę główną, ale także strony produktów, koszyk i finalizację zamówienia.

W narzędziach deweloperskich przeglądarki można sprawdzić, z jakimi serwerami komunikuje się witryna i jakie skrypty są uruchamiane.

Nie każde połączenie z zewnętrzną domeną jest niebezpieczne. Sklepy korzystają przecież z legalnych systemów analitycznych, płatniczych i marketingowych.

Problem stanowią żądania, których nie można przypisać do zatwierdzonych usług, szczególnie gdy kod pobierany jest z nieznanych domen i wykonuje operacje na stronie.

Ze względu na mechanizmy ukrywania aktywności zastosowane w kampanii analiza powinna uwzględniać możliwość różnego zachowania skryptu wobec narzędzi automatycznych i zwykłych przeglądarek.

Co zrobić po wykryciu infekcji? Procedura usuwania malware z Magento

Przywrócenie bezpieczeństwa powinno przebiegać w określonej kolejności. Chaotyczne usuwanie plików i natychmiastowa zmiana haseł, zanim uda się ustalić zakres włamania, mogą utrudnić dochodzenie lub doprowadzić do ponownego przejęcia sklepu.

Etap pierwszy: zatrzymanie aktywnego zagrożenia

Jeżeli złośliwy kod jest nadal dostarczany odwiedzającym, trzeba ograniczyć ryzyko narażania kolejnych klientów.

W zależności od charakteru incydentu może być konieczne tymczasowe wyłączenie sklepu, zablokowanie płatności albo ograniczenie dostępu do wybranych funkcji.

Nie wystarczy przy tym zablokować jednego zidentyfikowanego adresu. Napastnicy mogą wykorzystywać kolejne domeny, a kod zapisany wcześniej w przeglądarkach nie zawsze zależy od bieżącej dostępności zewnętrznego serwera.

Działania ochronne należy prowadzić w sposób umożliwiający zachowanie danych niezbędnych do analizy.

Etap drugi: ustalenie momentu i sposobu włamania

Przed czyszczeniem systemu warto zabezpieczyć:

• Logi serwera WWW.
• Logi aplikacji Magento.
• Historię aktywności administracyjnej, jeżeli jest dostępna.
• Dane dotyczące logowań SSH.
• Informacje o zmianach w bazie danych.
• Listę i zawartość podejrzanych plików.
• Stan kont i uprawnień w systemie.
• Kopię plików aplikacji oraz spójny zrzut bazy danych.

Zebrane informacje pozwalają ustalić, kiedy prawdopodobnie doszło do nieautoryzowanego dostępu oraz jakie działania podejmował napastnik.

Ważne jest oddzielenie pierwszego włamania od późniejszych zmian. Przestępca mógł zainstalować backdoora kilka miesięcy wcześniej, a złośliwy JavaScript podmienić dopiero niedawno.

Etap trzeci: wyczyszczenie zainfekowanych treści

Po ustaleniu zakresu zmian należy usunąć nieautoryzowane skrypty i przywrócić prawidłową zawartość odpowiednich bloków oraz stron CMS.

Trzeba również skontrolować inne miejsca umożliwiające umieszczenie JavaScriptu w witrynie, zwłaszcza:

• Ustawienia nagłówka i stopki HTML.
• Konfigurację poszczególnych widoków sklepu.
• Szablony wykorzystywane przez storefront.
• Rozszerzenia dodające własny kod do strony.
• Systemy zarządzania tagami.
• Integracje marketingowe i płatnicze.

Po odtworzeniu poprawnych treści należy wyczyścić odpowiednie pamięci podręczne Magento oraz sprawdzić kod rzeczywiście otrzymywany przez przeglądarkę.

Na tym etapie zagrożenie widoczne dla klientów może zostać ograniczone, ale proces naprawy nie jest jeszcze zakończony.

Etap czwarty: usunięcie wszystkich mechanizmów trwałego dostępu

To jeden z najważniejszych elementów całej procedury.

Należy przeprowadzić kontrolę obejmującą nieznane konta użytkowników, klucze SSH, podejrzane procesy, zaplanowane zadania, pliki wykonywalne, zmodyfikowane rozszerzenia oraz nieautoryzowane uprawnienia.

Warto porównać pliki produkcyjnego sklepu z zaufanym repozytorium kodu i oryginalnymi pakietami dystrybucyjnymi.

Jeżeli nie można wiarygodnie potwierdzić integralności serwera, bezpieczniejszym rozwiązaniem może być uruchomienie nowego środowiska i odtworzenie aplikacji ze sprawdzonych źródeł.

Przeniesienie całego katalogu starego sklepu na nowy serwer bez weryfikacji może przenieść również złośliwe pliki.

Podobnie przeniesienie bazy danych zawierającej niebezpieczne wpisy CMS może spowodować ponowne wyświetlanie szkodliwego kodu.

Etap piąty: instalacja właściwych poprawek bezpieczeństwa

Po usunięciu nieautoryzowanego dostępu należy upewnić się, że pierwotna luka wykorzystana do włamania została zamknięta.

W związku z omawianą kampanią szczególne znaczenie mają dwie podatności Magento.

PolyShell otrzymał ocenę 9,6 w skali CVSS 3.1. Adobe udostępniło poprawki w ramach biuletynu APSB26-73, opublikowanego 14 lipca 2026 roku.

W przypadku SessionReaper producent opublikował także poprawkę VULN-32437-2-4-X-patch.

Nie należy ograniczać przeglądu bezpieczeństwa wyłącznie do tych dwóch podatności. Konieczna jest kontrola wszystkich aktualizacji istotnych dla wykorzystywanej wersji Magento, Adobe Commerce i zainstalowanych rozszerzeń.

Trzeba wyraźnie rozróżnić aktualizację oprogramowania od usunięcia skutków wcześniejszego włamania. Poprawka ogranicza możliwość ponownego wykorzystania znanej luki, ale nie usuwa automatycznie wcześniej pozostawionego konta administratora czy webshella.

Etap szósty: wymiana danych uwierzytelniających

Po zabezpieczeniu środowiska należy potraktować potencjalnie ujawnione hasła i tokeny jako niewiarygodne.

Zmiany powinny objąć stosownie do ustalonego zakresu incydentu:

• Hasła administratorów Magento.
• Dane dostępowe do bazy danych.
• Konta systemowe i dostęp SSH.
• Tokeny API.
• Klucze wykorzystywane przez integracje płatnicze.
• Dane dostępowe do zewnętrznych usług.
• Poświadczenia wykorzystywane podczas wdrażania aplikacji.

Nieznane konta trzeba zablokować lub usunąć po zabezpieczeniu potrzebnych dowodów, a nieautoryzowane klucze unieważnić.

Dodatkowo należy rozważyć unieważnienie aktywnych sesji i włączenie uwierzytelniania wieloskładnikowego dla kont uprzywilejowanych.

Nowe hasła powinny być ustawiane z zaufanego środowiska. Zmiana danych dostępowych na nadal kontrolowanym przez napastnika serwerze nie zapewnia ich bezpieczeństwa.

Etap siódmy: testy bezpieczeństwa przed ponownym uruchomieniem sprzedaży

Przywrócenie działania sklepu wymaga potwierdzenia, że zidentyfikowane drogi ataku zostały zamknięte.

Kontrola powinna obejmować cały proces zakupowy, a nie tylko stronę główną.

Należy sprawdzić formularze, koszyk, przekierowania do operatora płatności, zewnętrzne skrypty oraz komunikację z usługami wykorzystywanymi podczas finalizacji zamówienia.

Warto też porównać aktualny stan plików i bazy danych z oczekiwaną konfiguracją oraz upewnić się, że nie powstają nowe nieautoryzowane rekordy ani konta.

Po przywróceniu sklepu do działania monitoring powinien zostać utrzymany ze zwiększoną częstotliwością, ponieważ kolejne próby dostępu mogą ujawnić przeoczony mechanizm utrwalania infekcji.

Dlaczego aktualny Magento 2.4.7-p10 również został ponownie zainfekowany?

Jeden z przypadków udokumentowanych przez Sansec szczególnie dobrze pokazuje ograniczenia tradycyjnego podejścia do zabezpieczania witryn.

23 października 2026 roku sklep działający na Magento 2.4.7-p10 zaczął ładować skrypt pochodzący z domeny deepveindrilling.com. Według badaczy w instalacji nie brakowało poprawek dotyczących rdzenia systemu.

Co istotne, około godzinę wcześniej kontrola nie wykazała infekcji.

Analiza historii sklepu ujawniła jednak wcześniejsze problemy. We wrześniu odnaleziono nieautoryzowane konto administracyjne, a następnie backdoora wykorzystującego GSocket.

Ten przypadek pokazuje, dlaczego zabezpieczanie sklepu nie może sprowadzać się do sprawdzenia numeru jego wersji.

Aktualny system nadal może być zagrożony, jeżeli cyberprzestępca uzyskał wcześniej dostęp i pozostawił sobie możliwość modyfikowania plików lub danych.

Dlatego przy podejrzeniu włamania konieczna jest analiza całego środowiska: aplikacji, bazy danych, kont użytkowników, procesów systemowych i infrastruktury serwerowej.

Czy przestępcy mogli przechwytywać dane płatnicze klientów?

Złośliwy JavaScript działający w sklepie internetowym stanowi potencjalnie poważne zagrożenie dla danych klientów. Jego rzeczywiste możliwości zależą od zawartości pobranego kodu oraz sposobu, w jaki sklep obsługuje płatności.

W atakach typu web skimming cyberprzestępcy mogą próbować przechwytywać informacje wprowadzane do formularzy, manipulować elementami strony lub kierować klientów do fałszywych formularzy płatniczych.

Nie oznacza to jednak, że każdy sklep objęty opisywaną kampanią utracił dane kart płatniczych.

W chwili publikacji październikowego raportu Sansec nie dysponował przechwyconym końcowym ładunkiem najnowszego loadera. Nie ma więc podstaw, aby automatycznie przypisywać wszystkim 953 przypadkom potwierdzoną kradzież danych płatniczych.

Jeżeli jednak w sklepie wykryto nieautoryzowane skrypty, zwłaszcza w obszarze zamówień i płatności, należy zbadać możliwość naruszenia poufności danych.

W zależności od wyników analizy mogą być konieczne dodatkowe działania, w tym współpraca z operatorem płatności, ocena obowiązków wynikających z RODO oraz odpowiednie poinformowanie właściwych podmiotów.

Jak zabezpieczyć sklep przed ponownym włamaniem?

Najskuteczniejsza ochrona e-commerce opiera się na kilku wzajemnie uzupełniających się mechanizmach. Nawet dobre zabezpieczenie jednego obszaru nie rekompensuje całkowitego braku kontroli w innym.

Regularnie kontroluj integralność plików i bazy danych

Monitoring plików powinien wykrywać nieautoryzowane zmiany w kodzie aplikacji, konfiguracji oraz katalogach, które normalnie nie powinny zawierać nowych plików wykonywalnych.

W przypadku Magento równie ważne jest monitorowanie bazy danych. Kampania Sansec pokazuje, że modyfikacja bloków CMS może wystarczyć do umieszczenia szkodliwego kodu w witrynie.

Kontrolą warto objąć również administratorów, role użytkowników, integracje oraz kluczowe ustawienia związane z generowaniem zawartości strony.

Nie pozwalaj na wykonywanie kodu w katalogach przesyłanych plików

Katalogi przeznaczone do przechowywania obrazów, dokumentów i innych materiałów przesyłanych przez użytkowników nie powinny umożliwiać uruchamiania dowolnych skryptów serwerowych.

Należy weryfikować konfigurację serwera WWW, uprawnienia do zapisu oraz sposób obsługi plików przesyłanych do aplikacji.

Sama kontrola rozszerzenia pliku nie zapewnia odpowiedniego poziomu bezpieczeństwa. Plik przedstawiany jako obraz może zawierać innego rodzaju dane, a niewłaściwa konfiguracja serwera może zwiększać ryzyko jego wykorzystania.

Ogranicz uprawnienia kont i integracji

Każde konto administracyjne powinno mieć jasno określony cel i zakres dostępu.

Nie należy udostępniać pełnych uprawnień podmiotom, które potrzebują jedynie obsługi zamówień, produktów lub wybranych funkcji sklepu.

Po zakończeniu współpracy z wykonawcą trzeba odebrać zbędny dostęp oraz zweryfikować pozostawione konta i klucze integracyjne.

Warto okresowo kontrolować również konta techniczne, które często pozostają aktywne znacznie dłużej, niż wymaga tego ich pierwotne przeznaczenie.

Monitoruj skrypty uruchamiane na stronach sklepu

W witrynach e-commerce działa wiele skryptów pochodzących od zewnętrznych dostawców. Obsługują one reklamy, analitykę, personalizację, płatności i dodatkowe funkcje sprzedażowe.

Każdy niepotrzebny lub niekontrolowany skrypt zwiększa złożoność środowiska, które trzeba zabezpieczać.

Warto prowadzić rejestr zatwierdzonych zasobów i monitorować pojawianie się nowych połączeń, zwłaszcza na stronach koszyka oraz finalizacji zamówienia.

Dodatkową warstwą ochrony może być prawidłowo skonfigurowana polityka Content Security Policy (CSP), ograniczająca źródła kodu uruchamianego przez przeglądarkę.

Konfiguracja CSP musi jednak uwzględniać rzeczywiste działanie sklepu. Nieprzemyślane ograniczenia mogą powodować błędy w legalnych integracjach, a zbyt szerokie wyjątki znacząco zmniejszają skuteczność zabezpieczenia.

Nie opieraj bezpieczeństwa wyłącznie na skanerze

Regularne skanowanie podatności jest potrzebne, ale nie powinno być jedynym źródłem informacji o stanie sklepu.

W omawianej kampanii kod rozpoznawał cechy przeglądarek używanych do automatycznej analizy. Utrudnia to wykrywanie szkodliwej aktywności poprzez zwykłe pobranie strony i wyszukanie podejrzanych fragmentów.

Skuteczniejsza kontrola łączy monitoring zmian w aplikacji i bazie danych, analizę logów, inspekcję plików oraz obserwację faktycznego działania witryny w przeglądarce.

Utrzymuj kopie zapasowe poza serwerem produkcyjnym

Kopia zapasowa przechowywana wyłącznie na tym samym serwerze co sklep może zostać zmodyfikowana, usunięta albo zaszyfrowana przez napastnika.

Dlatego backupy powinny być odpowiednio odizolowane, objęte kontrolą dostępu i regularnie testowane pod kątem możliwości przywrócenia danych.

Warto przechowywać historię kopii umożliwiającą odtworzenie środowiska sprzed wykrytej infekcji.

Nie wolno jednak zakładać, że najstarszy dostępny backup jest automatycznie czysty. W przypadku wielomiesięcznych kampanii nieautoryzowany dostęp mógł istnieć na długo przed pierwszym widocznym incydentem.

Czy zagrożenie dotyczy również WooCommerce, PrestaShop i Shopify?

Raport Sansec opisuje przede wszystkim kampanię wymierzoną w Magento i Adobe Commerce. Nie potwierdza, że ta sama grupa wykorzystała identyczne podatności do przejęcia sklepów działających na WooCommerce, PrestaShop czy Shopify.

Warto jednak odróżnić konkretną lukę bezpieczeństwa od ogólnego mechanizmu ataku.

Wstrzykiwanie nieautoryzowanego JavaScriptu, wykorzystywanie przejętych kont administratorów i pozostawianie ukrytych mechanizmów dostępu nie jest problemem ograniczonym do jednego silnika sklepowego.

Na różnych platformach zagrożenie może powstawać z innych przyczyn: podatnej wtyczki, niebezpiecznej integracji, przejętego konta, błędnej konfiguracji hostingu lub niekontrolowanego kodu zewnętrznego.

Poszczególne platformy zapewniają różne poziomy dostępu do serwera i mechanizmy ochrony, dlatego sposób diagnostyki musi być do nich dostosowany.

Wspólna pozostaje podstawowa zasada: właściciel sklepu powinien wiedzieć, jakie skrypty są uruchamiane w jego witrynie, kto może modyfikować jej zawartość i jak wykrywane są nieautoryzowane zmiany.

Najczęściej zadawane pytania dotyczące infekcji sklepów Magento

Jak rozpoznać złośliwy kod w sklepie Magento?

W pierwszej kolejności należy sprawdzić bloki i strony CMS, nieznane skrypty JavaScript, podejrzane połączenia zewnętrzne, pliki znajdujące się w katalogach uploadu oraz konta administracyjne. Warto porównać pliki aplikacji z zaufaną wersją i przeanalizować historię zmian. Brak widocznych objawów nie wyklucza infekcji.

Czym jest deepveindrilling.com?

To domena wykorzystywana w kampanii malware opisanej przez Sansec w październiku 2026 roku. Złośliwe skrypty umieszczane w sklepach komunikowały się z tym adresem, a serwer mógł dobierać odpowiedź na podstawie parametrów przeglądarki odwiedzającego.

Czy rzeczywiście zainfekowano 953 sklepy internetowe?

Sansec zidentyfikował 953 sklepy objęte kampanią prowadzoną od lipca 2025 roku. Liczba ta nie oznacza 953 nowych włamań w październiku. Najnowszy loader wykryto w 83 sklepach, przy czym 60 z nich było związanych z wcześniejszymi etapami operacji.

Czy skasowanie złośliwego JavaScriptu wystarczy?

Nie zawsze. Usunięcie kodu z bloków CMS może zatrzymać jego wykonywanie na stronie, ale nie eliminuje innych sposobów dostępu napastnika. Konieczne jest sprawdzenie kont, plików, procesów, poświadczeń oraz potencjalnych backdoorów.

Co to jest backdoor w sklepie internetowym?

Backdoor to mechanizm zapewniający nieautoryzowany dostęp do aplikacji lub serwera. Może mieć postać złośliwego pliku, ukrytego konta, zmodyfikowanego komponentu albo innej metody pozwalającej napastnikowi wykonywać działania bez standardowej procedury uwierzytelniania.

Czy można mieć aktualne Magento i nadal być zainfekowanym?

Tak. Instalacja poprawek nie usuwa automatycznie zmian dokonanych przez przestępcę przed aktualizacją. Zagrożenie może także pochodzić z rozszerzenia, przejętych danych dostępowych lub niewłaściwie zabezpieczonego środowiska serwerowego.

Czy infekcja Magento oznacza kradzież numerów kart płatniczych?

Nie. Złośliwy kod w witrynie stwarza ryzyko naruszenia danych, ale sam fakt infekcji nie dowodzi kradzieży informacji płatniczych. Ustalenie zakresu zdarzenia wymaga analizy wykonywanego kodu, przepływu danych i dostępnych zapisów aktywności.

Jak sprawdzić, czy sklep został ponownie zainfekowany po naprawie?

Należy monitorować zmiany w plikach, blokach CMS, konfiguracji, kontach użytkowników oraz żądania wykonywane przez przeglądarkę. Warto również obserwować nietypowe procesy i próby logowania. Ponowne pojawienie się nieautoryzowanego kodu może wskazywać, że pierwotny mechanizm dostępu nie został całkowicie wyeliminowany.

Czy przywrócenie kopii zapasowej rozwiązuje problem włamania?

Tylko wtedy, gdy kopia pochodzi z wiarygodnego, niezainfekowanego stanu i jednocześnie usunięto przyczynę naruszenia. Przywrócenie aplikacji bez zamknięcia wykorzystanej luki może prowadzić do ponownego ataku.

Jak najlepiej chronić sklep przed podobnymi kampaniami?

Podstawę stanowią aktualizacje bezpieczeństwa, ograniczenie uprawnień, wieloskładnikowe uwierzytelnianie, kontrola skryptów zewnętrznych, monitoring zmian w aplikacji i bazie danych, właściwe zabezpieczenie serwera oraz sprawdzone kopie zapasowe. Istotne jest również szybkie reagowanie na sygnały wskazujące na naruszenie bezpieczeństwa.

Bezpieczeństwo sklepu wymaga usunięcia przyczyny włamania, nie tylko jego objawów

Kampania obejmująca 953 sklepy internetowe pokazuje, jak poważnym problemem może być długotrwała obecność przestępcy w środowisku e-commerce. Złośliwy kod nie musi zakłócać sprzedaży ani powodować widocznych błędów. Może funkcjonować w bazie danych, kontaktować się z zewnętrznym serwerem i unikać wykrycia podczas automatycznych kontroli.

Największe ryzyko pojawia się wtedy, gdy po znalezieniu podejrzanego skryptu właściciel sklepu usuwa wyłącznie ten fragment kodu i uznaje problem za rozwiązany.

Jeżeli nadal istnieje nieautoryzowane konto, webshell, podatne rozszerzenie albo skradzione dane dostępowe, napastnik może wprowadzić kolejne modyfikacje.

Pełne przywrócenie bezpieczeństwa wymaga więc ustalenia sposobu uzyskania dostępu, identyfikacji wszystkich nieautoryzowanych zmian, zabezpieczenia infrastruktury oraz przeprowadzenia kontroli działania sklepu po zakończeniu prac.

Dopiero wyeliminowanie możliwości ponownego dostępu daje podstawę do uznania incydentu za skutecznie opanowany. W przypadku sprzedaży internetowej ma to znaczenie nie tylko dla ochrony serwera, lecz również dla bezpieczeństwa danych klientów, ciągłości realizacji zamówień i wiarygodności całej firmy.

Źródła

• Sansec Forensics Team – deepveindrilling.com: Magento CMS block loader hits 953 stores, 24 października 2026
• Adobe Security Bulletin APSB26-73 – Security update available for Adobe Commerce
• Adobe Commerce – Critical Security Update APSB25-88, CVE-2025-54236
• Adobe Commerce – Best practices to respond to a security incident