Atak na sklepy internetowe: 953 witryny z ukrytym loaderem JavaScript, głównie na Magento

Wprowadzenie do problemu / definicja

Eksperci ds. bezpieczeństwa opisali szeroko zakrojoną kampanię wymierzoną w sklepy internetowe, w której napastnicy osadzają złośliwy kod JavaScript w komponentach CMS platformy Magento. Nie chodzi tu o pojedynczy skrypt dodany do strony, lecz o trwały loader umożliwiający pobieranie dalszych poleceń z infrastruktury atakującego i ukrywanie aktywności przed częścią narzędzi analitycznych.

Taki model działania jest szczególnie niebezpieczny dla e-commerce, ponieważ złośliwy kod uruchamia się w przeglądarce klienta w legalnym kontekście sklepu. Oznacza to możliwość dalszej rozbudowy ataku bez konieczności ciągłego modyfikowania widocznych elementów witryny.

W skrócie

Kampania objęła 953 sklepy internetowe.
Większość ofiar stanowią wdrożenia Magento.
Loader był umieszczany głównie w tabeli cms_block.
Nowsze warianty wykorzystują fingerprinting przeglądarki i zapis ładunku w localStorage.
Infrastruktura sterująca odpowiada selektywnie, głównie rzeczywistym użytkownikom.
Część infekcji powiązano z wcześniejszym wykorzystaniem luk oraz z nieautoryzowanymi kontami administracyjnymi.

Kontekst / historia

Opisana operacja nie wygląda na jednorazowy incydent, ale na kampanię prowadzoną etapami i rozwijaną w czasie. Operatorzy regularnie zmieniali domeny służące do dostarczania loadera, co pozwalało im utrzymywać skuteczność ataku mimo wykryć i blokad po stronie obrońców.

Według ustaleń badaczy aktywność trwa co najmniej od lipca 2025 roku. Najnowsza domena sterująca została zarejestrowana 6 października 2026 roku i zaczęła być wykorzystywana dzień później, co wskazuje na ciągłe utrzymywanie i rozwijanie infrastruktury kampanii.

Znaczenie ma również szerszy kontekst bezpieczeństwa ekosystemu Magento i Adobe Commerce. W części analizowanych przypadków loader nie był początkiem incydentu, lecz kolejnym etapem po wcześniejszym przejęciu sklepu, uzyskaniu dostępu do serwera lub utworzeniu trwałych mechanizmów obecności w środowisku.

Analiza techniczna

Mechanizm ataku opiera się na wstrzyknięciu niewielkiego fragmentu JavaScript do bloków CMS renderowanych na stronach sklepu. To skuteczna technika, ponieważ złośliwy kod trafia do nagłówka, stopki lub innych współdzielonych elementów interfejsu i może być ładowany na wielu podstronach jednocześnie.

W jednej z zaobserwowanych wersji loader odczytuje kod zapisany wcześniej w localStorage i uruchamia go po stronie przeglądarki. Dzięki temu raz dostarczony ładunek może być wykonywany ponownie podczas kolejnych odwiedzin, nawet jeśli komunikacja z domeną atakującego zostanie tymczasowo zakłócona.

Nowsze warianty kampanii stosują fingerprinting przeglądarki i środowiska wykonawczego. Analizowane są między innymi cechy wskazujące na automatyzację, właściwości związane z Selenium i ChromeDriverem, a także parametry urządzenia i sesji, takie jak rozdzielczość ekranu, strefa czasowa, języki, liczba rdzeni procesora, dostępna pamięć czy identyfikatory WebGL.

Na podstawie zebranego profilu serwer decyduje, czy zwrócić dalszy kod, przekierowanie, pustą odpowiedź czy całkowicie zignorować żądanie. Tego typu selektywna obsługa utrudnia analizę incydentu, ponieważ sklep może zachowywać się inaczej wobec realnego klienta, a inaczej wobec skanera bezpieczeństwa lub badacza korzystającego ze środowiska testowego.

W poprzednich etapach kampanii operatorzy korzystali również z mechanizmów dystrybucji ruchu typu TDS. Analiza źródeł kompromitacji wskazuje ponadto na kilka możliwych wektorów wejścia, w tym wykorzystanie luk określanych jako PolyShell i SessionReaper, a także przejęcia przez nieautoryzowane konta administracyjne, webshelle i backdoory ukryte w strukturze plików sklepu.

Konsekwencje / ryzyko

Skala ryzyka dla operatorów sklepów internetowych jest wysoka. Atakujący zyskują możliwość dynamicznego dostarczania dowolnego kodu do przeglądarki klienta, co może prowadzić do kradzieży danych płatniczych, przejęcia sesji, osadzania fałszywych formularzy płatności, przekierowań do stron phishingowych lub ładowania kolejnych modułów malware.

Dodatkowym problemem jest mechanizm unikania detekcji. Jeżeli złośliwy serwer odpowiada wyłącznie realnym użytkownikom, podstawowe skanowanie HTTP lub testy wykonywane w zautomatyzowanym środowisku mogą nie ujawnić kompromitacji. To wydłuża czas obecności napastnika w środowisku i zwiększa skalę potencjalnych strat.

Istotna jest również trwałość ataku. Samo usunięcie jednego fragmentu JavaScript z warstwy front-end nie oznacza zakończenia incydentu, jeżeli napastnik utrzymał dostęp do bazy danych, panelu administracyjnego lub systemu plików. Obecność kodu w localStorage dodatkowo komplikuje proces czyszczenia i może powodować dalsze wykonywanie ładunku po stronie użytkownika.

Rekomendacje

Administratorzy Magento i Adobe Commerce powinni traktować taki incydent jako pełne naruszenie środowiska, a nie jedynie problem pojedynczego skryptu w warstwie prezentacji. Reakcja powinna obejmować zarówno aplikację, jak i bazę danych, konta administracyjne oraz serwer.

Przeprowadzić przegląd zawartości cms_block oraz cms_page pod kątem nietypowych znaczników <script>, odwołań do zewnętrznych domen, zakodowanych ciągów i wzorców związanych z localStorage.
Zweryfikować listę użytkowników administracyjnych oraz logi zmian w panelu pod kątem nieautoryzowanych kont i podejrzanych działań.
Wykonać audyt systemu plików, katalogów uploadów, mediów, rozszerzeń i niestandardowych modułów w poszukiwaniu webshelli, backdoorów i ukrytych artefaktów.
Zaktualizować Magento lub Adobe Commerce do bezpiecznych wersji oraz wdrożyć najnowsze poprawki bezpieczeństwa producenta.
Wymusić rotację haseł do panelu administracyjnego, bazy danych i integracji API po zakończeniu czyszczenia środowiska.
Wdrożyć monitoring integralności plików, polityki CSP, detekcję zmian w bazie danych oraz rozwiązania HIDS lub EDR dla hosta aplikacyjnego.
Testować sklep z użyciem rzeczywistych przeglądarek i różnych profili użytkowników, a nie wyłącznie prostych skanerów automatycznych.

Podsumowanie

Kampania wymierzona w sklepy internetowe pokazuje, że współczesne ataki na e-commerce łączą kompromitację aplikacji, trwałe osadzenie kodu w bazie danych oraz selektywne ukrywanie złośliwych ładunków przed analizą. W przypadku Magento szczególnie groźne jest wykorzystanie legalnych mechanizmów CMS do dystrybucji złośliwego JavaScriptu.

Dla zespołów bezpieczeństwa najważniejszy wniosek jest jednoznaczny: obecność takiego loadera należy traktować jako wskaźnik głębszego przejęcia środowiska. Skuteczna odpowiedź wymaga dochodzenia obejmującego aplikację, bazę danych, konta administracyjne, system plików oraz historię wdrożonych poprawek.