Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
W środowisku e-commerce ponownie rośnie aktywność kampanii web skimming, których celem jest przechwytywanie danych kart płatniczych bezpośrednio podczas finalizacji zakupów. Najnowszy wariant ataku wymierzonego w sklepy oparte na Magento i Adobe Commerce wykorzystuje nietypową technikę ukrycia złośliwego kodu w pozornie niegroźnym obrazie SVG o rozmiarze zaledwie 1×1 piksela.
To podejście utrudnia wykrycie zagrożenia, ponieważ złośliwy ładunek nie musi być ładowany jako osobny plik JavaScript z zewnętrznej domeny. Zamiast tego jest osadzany bezpośrednio w kodzie strony, co zmniejsza liczbę klasycznych wskaźników kompromitacji.
W skrócie
Badacze bezpieczeństwa opisali kampanię, w której skimmer płatniczy jest ukrywany inline w atrybucie onload elementu SVG. Po wejściu użytkownika w końcowy etap zakupu skrypt uruchamia fałszywą nakładkę płatności, która imituje legalny formularz checkout i zbiera dane karty oraz informacje rozliczeniowe.
- złośliwy kod ukryto w 1-pikselowym elemencie SVG,
- ładunek jest dekodowany po stronie przeglądarki,
- atak przechwytuje dane karty, datę ważności, CVV i dane klienta,
- dane są walidowane i wyprowadzane do infrastruktury atakującego,
- kampania jest łączona z wcześniejszym wykorzystywaniem luki PolyShell.
Kontekst / historia
Ataki MageCart i web skimming od lat należą do najgroźniejszych zagrożeń dla sklepów internetowych. Ich skuteczność wynika z faktu, że cyberprzestępcy nie muszą przełamywać zabezpieczeń operatorów kart płatniczych. Wystarczy, że zmodyfikują kod sklepu, szablon checkoutu lub mechanizm renderowania strony tak, aby przechwycić dane wpisywane przez klienta.
W opisywanym przypadku kampania została powiązana z falą aktywnego wykorzystywania podatności określanej jako PolyShell, ujawnionej w marcu 2026 roku. Oznacza to, że zagrożenie nie ogranicza się wyłącznie do prostego osadzenia skryptu w HTML, ale może być efektem wcześniejszego uzyskania dostępu do środowiska sklepu i utrzymania tam trwałej obecności.
Analiza techniczna
Kluczowym elementem ataku jest osadzenie złośliwego ładunku w niewielkim obiekcie SVG, który na pierwszy rzut oka wygląda jak neutralny element interfejsu lub techniczny zasób strony. Faktyczna funkcja tego obiektu nie polega jednak na renderowaniu grafiki, lecz na uruchomieniu kodu JavaScript przez atrybut onload.
Ładunek jest zapisany w postaci zakodowanego ciągu, zwykle Base64, a następnie dekodowany funkcją atob() i wykonywany z opóźnieniem przy użyciu mechanizmów takich jak setTimeout(). Taki model działania daje napastnikom kilka istotnych korzyści:
- eliminuje potrzebę pobierania zewnętrznego skryptu,
- utrudnia analizę ruchu sieciowego,
- zmniejsza widoczność podejrzanych odwołań do obcych domen,
- pozwala ukryć pełną logikę malware w pojedynczym fragmencie HTML.
Po uruchomieniu skrypt przechwytuje interakcję użytkownika z procesem płatności i wyświetla fałszywą warstwę udającą bezpieczny formularz transakcyjny. Ofiara wpisuje dane karty płatniczej, nie zdając sobie sprawy, że trafiają one bezpośrednio do przestępców. Formularz może dodatkowo wykorzystywać walidację numeru karty, na przykład z użyciem algorytmu Luhna, aby zwiększyć wiarygodność interfejsu i poprawić jakość wykradanych rekordów.
Wyprowadzanie danych odbywa się zazwyczaj w postaci JSON, który przed transmisją jest zaciemniany przez kodowanie Base64 i prosty mechanizm XOR. Nie jest to silne szyfrowanie, ale wystarcza, aby utrudnić szybkie rozpoznanie zawartości przez podstawowe systemy monitoringu. Dodatkowe artefakty mogą obejmować wpisy w localStorage oraz żądania do zasobów przypominających legalne usługi telemetryczne lub analityczne.
Konsekwencje / ryzyko
Dla operatorów sklepów skutki takiej kompromitacji są wielowymiarowe. Najpoważniejszym następstwem jest oczywiście kradzież danych kart płatniczych klientów, co może prowadzić do oszustw finansowych, wzrostu liczby chargebacków, kosztownych audytów bezpieczeństwa i pogorszenia relacji z partnerami płatniczymi.
Równie istotne są konsekwencje reputacyjne. Klienci, którzy padną ofiarą incydentu, często tracą zaufanie do marki, a odbudowa wiarygodności po ujawnieniu naruszenia może być długotrwała i kosztowna. Jeśli dodatkowo doszło do szerszego przejęcia środowiska, incydent może oznaczać obecność backdoorów, nieautoryzowanych kont administracyjnych oraz dalsze ryzyko kradzieży danych osobowych.
Szczególnie niebezpieczne jest to, że technika ukrycia skimmera w SVG obniża skuteczność tradycyjnych metod detekcji skoncentrowanych na zewnętrznych skryptach. Bez monitorowania zmian w kodzie front-endu i analizy rzeczywistego zachowania checkoutu taki malware może pozostać aktywny przez długi czas.
Rekomendacje
Administratorzy sklepów Magento i Adobe Commerce powinni potraktować ten scenariusz jako incydent wysokiego priorytetu. Niezbędne są zarówno działania doraźne, jak i długofalowe mechanizmy ograniczające ryzyko ponownej kompromitacji.
- przeprowadzić audyt kodu HTML, szablonów i komponentów checkout pod kątem ukrytych tagów SVG z atrybutem
onload, - wyszukiwać wzorce zawierające
atob(),setTimeout()oraz nietypowo długie ciągi Base64, - sprawdzić pliki motywu, bloki CMS, własne moduły i miejsca umożliwiające dynamiczną injekcję kodu,
- przeanalizować logi aplikacyjne, przeglądarkowe oraz zawartość
localStorageisessionStorage, - monitorować połączenia do nieznanych domen oraz endpointów podszywających się pod analitykę,
- wdrożyć wszystkie dostępne poprawki i hotfixy bezpieczeństwa dla Magento lub Adobe Commerce,
- wymusić rotację haseł administracyjnych, kluczy API i innych sekretów,
- uruchomić kontrolę integralności plików oraz przegląd zadań cron, kont administracyjnych i niestandardowych modułów,
- wdrożyć Content Security Policy ograniczające wykonywanie skryptów inline i połączenia do nieautoryzowanych domen,
- stosować MFA, segmentację dostępu administracyjnego i regularne skanowanie checkoutu z perspektywy przeglądarki użytkownika.
W razie potwierdzenia naruszenia organizacja powinna uruchomić formalny proces reagowania na incydent, zabezpieczyć materiał dowodowy, ocenić zakres kompromitacji i przeanalizować obowiązki notyfikacyjne wynikające z regulacji dotyczących ochrony danych oraz wymagań branży płatniczej.
Podsumowanie
Nowa kampania wymierzona w Magento pokazuje, że web skimming staje się coraz bardziej ukryty i trudniejszy do wykrycia. Wykorzystanie 1-pikselowego obrazu SVG jako nośnika dla zakodowanego skryptu pozwala omijać część klasycznych mechanizmów bezpieczeństwa i skutecznie przechwytywać dane płatnicze klientów podczas finalizacji zakupów.
Dla operatorów sklepów oznacza to konieczność połączenia szybkiego patch managementu z ciągłym monitoringiem front-endu, kontrolą integralności plików i analizą zachowania formularzy checkout. Ochrona samej warstwy serwerowej nie wystarcza, jeśli atakujący mogą manipulować tym, co użytkownik widzi i wypełnia w przeglądarce.