Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Badacze bezpieczeństwa opisali nową kampanię typu Magecart, w której złośliwy skimmer kart płatniczych nie tylko przechwytuje dane z formularzy checkout, ale również wykorzystuje zaufaną infrastrukturę usług zewnętrznych do pobierania ładunku i przechowywania wykradzionych informacji. To istotna zmiana taktyki, ponieważ ruch związany z atakiem nie musi trafiać do oczywiście podejrzanych domen, lecz może ukrywać się w usługach powszechnie dopuszczanych przez sklepy internetowe.
W praktyce oznacza to, że klasyczne podejście do ochrony front-endu e-commerce, oparte głównie na listach dozwolonych domen i podstawowym monitoringu skryptów, może nie wystarczyć do wykrycia kompromitacji.
W skrócie
- Kampania została powiązana z atakami na środowiska Magento i Adobe Commerce.
- Złośliwy kod był dostarczany przez kontener Google Tag Manager.
- Skimmer aktywował się na stronach płatności i przechwytywał dane kart oraz dane osobowe klientów.
- Skradzione informacje były maskowane i zapisywane z użyciem infrastruktury Stripe.
- Zaobserwowano również wariant wykorzystujący Google Firestore.
Kontekst / historia
Grupy powiązane z technikami Magecart od lat koncentrują się na kompromitacji warstwy front-end sklepów internetowych. Tradycyjny model takich ataków polegał na wstrzyknięciu złośliwego JavaScriptu do strony płatności, a następnie przesyłaniu przechwyconych danych do serwerów kontrolowanych bezpośrednio przez operatorów kampanii.
W opisywanym przypadku mechanizm został rozwinięty i lepiej dostosowany do współczesnych środowisk e-commerce. Zamiast oczywistej infrastruktury atakującego wykorzystano usługi, które w wielu sklepach są uznawane za zaufane i nie wzbudzają podejrzeń. Dodatkowo skimmer był osadzany w pozornie legalnych kontenerach Google Tag Manager, co zwiększało szansę na długotrwałe pozostawanie niezauważonym.
Z opisu incydentu wynika również, że infrastruktura używana w tej operacji mogła funkcjonować co najmniej od końca grudnia 2025 roku, co sugeruje zaplanowaną i długofalową kampanię wymierzoną w sektor handlu internetowego.
Analiza techniczna
Mechanizm działania ataku obejmuje kilka etapów. Najpierw użytkownik odwiedza sklep internetowy, który ładuje zainfekowany kontener Google Tag Manager. Złośliwy kod może zostać pobrany razem z innymi skryptami wykorzystywanymi przez witrynę, jednak właściwa aktywacja następuje dopiero w kontekście procesu checkout.
Następnie skrypt komunikuje się z API Stripe i pobiera metadane przypisane do określonego rekordu klienta. W tych polach przechowywane są fragmenty kodu JavaScript, które po złożeniu są wykonywane dynamicznie z użyciem mechanizmu new Function(). Takie podejście utrudnia prostą analizę statyczną i pozwala operatorom kampanii modyfikować logikę skimmera bez hostowania pełnego ładunku na własnej domenie.
Po aktywacji malware przechwytuje dane wpisywane do formularza płatności, w tym numer karty, datę ważności, kod CVV, imię i nazwisko, adres e-mail, numer telefonu oraz informacje bilingowe. Dane nie są od razu wysyłane poza przeglądarkę. Najpierw są łączone, maskowane prostą operacją XOR i zapisywane lokalnie.
Za eksfiltrację odpowiada oddzielny komponent, który po załadowaniu strony oraz cyklicznie w ustalonych odstępach odczytuje lokalnie zapisane informacje, dzieli je na części i tworzy nowe obiekty klienta w Stripe. Skradzione dane trafiają do pól metadanych, dzięki czemu mogą być przechowywane wewnątrz legalnej infrastruktury usługi. Po skutecznym zapisaniu lokalne artefakty są usuwane, co ogranicza ślady po stronie przeglądarki.
Badacze wskazali również wariant wykorzystujący Google Firestore. W tej wersji zarówno dostarczanie ładunku, jak i przechowywanie wykradzionych informacji odbywa się przy użyciu innej zaufanej usługi chmurowej. Pokazuje to, że operatorzy kampanii traktują renomowane platformy SaaS jako elastyczne zaplecze dla operacji skimmerskich.
Konsekwencje / ryzyko
Największe zagrożenie wynika z nadużycia zaufanych domen i usług, które są często dopuszczane w politykach bezpieczeństwa treści, filtrach sieciowych oraz mechanizmach kontroli ruchu. Sklep może formalnie komunikować się wyłącznie z legalnymi usługami, a mimo to pozostawać ofiarą aktywnej kompromitacji.
Dla operatorów e-commerce oznacza to zwiększone ryzyko niezauważonego wycieku danych płatniczych klientów, naruszenia zgodności regulacyjnej, strat finansowych i poważnych szkód reputacyjnych. Wykorzystanie Google Tag Manager dodatkowo rozszerza powierzchnię ataku, ponieważ błędna konfiguracja, przejęcie kontenera lub nieautoryzowana publikacja zmian mogą natychmiast wpłynąć na działanie całego checkoutu.
Dla klientów skutki mogą obejmować nieautoryzowane transakcje, przejęcie danych osobowych, wzrost ryzyka phishingu oraz dalsze nadużycia oparte na profilowaniu ofiary. Połączenie danych płatniczych z danymi kontaktowymi zwiększa wartość wykradzionego pakietu dla cyberprzestępców.
Rekomendacje
Organizacje prowadzące sprzedaż internetową powinny traktować skrypty po stronie klienta jako obszar wysokiego ryzyka i wdrożyć stały monitoring integralności checkoutu, kontenerów tag managera oraz wszystkich zewnętrznych zasobów ładowanych w przeglądarce.
- Ograniczyć możliwość publikacji zmian w Google Tag Manager do ściśle kontrolowanych ról.
- Wymusić silne uwierzytelnianie i regularnie audytować historię zmian w kontenerach.
- Analizować zachowanie skryptów, a nie tylko ich domenę pochodzenia.
- Monitorować użycie mechanizmów dynamicznego wykonania kodu, takich jak
new Function()ieval(). - Wdrażać rozwiązania klasy client-side security oraz narzędzia do wykrywania web skimmerów.
- Kontrolować nietypowe wywołania do API usług SaaS i nadużycia pól metadanych.
Po stronie aplikacji warto także wdrożyć detekcję manipulacji DOM, monitorowanie zmian w nasłuchiwaczach zdarzeń oraz mechanizmy wykrywające nieautoryzowany odczyt wrażliwych pól formularzy płatniczych. Regularne testy bezpieczeństwa powinny obejmować również supply chain front-end, a nie tylko warstwę serwerową.
Użytkownicy końcowi mogą ograniczać skutki podobnych incydentów poprzez korzystanie z kart wirtualnych, ustawianie niskich limitów transakcyjnych oraz włączenie natychmiastowych powiadomień o każdej operacji.
Podsumowanie
Opisana kampania pokazuje wyraźną ewolucję zagrożeń Magecart. Cyberprzestępcy coraz częściej odchodzą od prostych metod eksfiltracji na rzecz nadużywania legalnej infrastruktury chmurowej i płatniczej, co znacząco utrudnia wykrywanie incydentów tradycyjnymi metodami.
Dla sektora e-commerce to ważny sygnał, że ochrona checkoutu musi obejmować cały łańcuch zależności po stronie przeglądarki. Same allowlisty domen i zaufanie do renomowanych usług nie gwarantują bezpieczeństwa, jeśli zabraknie ciągłej kontroli zachowania skryptów i zmian w środowisku front-end.