Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Badacze bezpieczeństwa opisali nową kampanię typu Magecart, w której cyberprzestępcy przechwytują dane kart płatniczych na stronach sklepów internetowych i wykorzystują zaufaną infrastrukturę usług płatniczych do hostowania kodu oraz przechowywania wykradzionych informacji. To istotna zmiana taktyczna, ponieważ ruch do legalnych i powszechnie dopuszczanych domen trudniej wykryć przy użyciu standardowych mechanizmów filtrowania.
W praktyce oznacza to odejście od klasycznego modelu exfiltracji do podejrzanych serwerów kontrolowanych przez napastników. Zamiast tego atakujący nadużywają rozpoznawalnych usług chmurowych i płatniczych, które często są już obecne w środowisku e-commerce i objęte domyślnym zaufaniem.
W skrócie
- Złośliwy kod został osadzony w kontenerze Google Tag Manager.
- Skrypt aktywował się na stronach koszyka i finalizacji zakupu.
- Ładunek był pobierany z metadanych obiektu klienta w Stripe.
- Skimmer przechwytywał numer karty, datę ważności, CVV oraz dane osobowe i rozliczeniowe.
- Wykradzione informacje były zapisywane jako metadane kolejnych obiektów klienta w Stripe.
- Celem kampanii były środowiska Magento i Adobe Commerce.
Kontekst / historia
Rodzina zagrożeń Magecart od lat koncentruje się na kompromitowaniu sklepów internetowych i osadzaniu skryptów JavaScript kradnących dane płatnicze podczas procesu checkout. W większości wcześniejszych kampanii przestępcy polegali na zewnętrznych serwerach kontrolowanych przez operatora ataku, co zwiększało szansę na wykrycie przez systemy monitorujące ruch sieciowy, polityki Content Security Policy oraz listy blokujące znane domeny wykorzystywane do exfiltracji.
W opisywanym przypadku napastnicy odchodzą od tej praktyki i nadużywają usług, które są często domyślnie zaufane przez sklepy internetowe. Badacze wskazali, że kampania była ukierunkowana na środowiska Magento i Adobe Commerce. Ustalono również, że powiązany rekord klienta w Stripe został utworzony 24 grudnia 2025 roku, co sugeruje, że operacja mogła pozostawać aktywna co najmniej od tego momentu.
Analiza techniczna
Mechanizm infekcji rozpoczyna się od złośliwego kontenera Google Tag Manager, który ładowany jest jako pozornie legalny element stosu marketingowo-analitycznego. Po wejściu użytkownika na stronę płatności skrypt inicjuje komunikację z API Stripe i pobiera rekord konkretnego klienta. W polach metadanych tego obiektu ukryto fragmenty kodu JavaScript, które są następnie scalane i wykonywane dynamicznie przy użyciu mechanizmu new Function().
Aktywny skimmer monitoruje formularze płatnicze i przechwytuje kluczowe dane transakcyjne: numer karty, datę ważności, kod bezpieczeństwa CVV, imię i nazwisko posiadacza, adres rozliczeniowy, adres e-mail oraz numer telefonu. Zamiast natychmiastowej wysyłki do zewnętrznego serwera, dane są łączone w pojedynczy ciąg znaków, maskowane przy użyciu operacji XOR i tymczasowo przechowywane lokalnie.
Osobny moduł uruchamiany po załadowaniu strony, a następnie cyklicznie co minutę, odpowiada za exfiltrację. Odczytuje on lokalnie zapisany pakiet danych, dzieli go na części i tworzy nowy obiekt klienta w Stripe, zapisując wykradzione informacje w metadanych. W praktyce każda przechwycona karta staje się osobnym fałszywym rekordem klienta w infrastrukturze usług płatniczych. Po zakończeniu procesu lokalne artefakty są usuwane, aby ograniczyć ślady i zapobiec wielokrotnemu przesyłaniu tych samych danych.
Badacze zidentyfikowali także wariant kampanii wykorzystujący usługę Google Firestore zamiast Stripe. W tej wersji ładunek pobierany jest z dokumentu o nazwie przypominającej legalny komponent obsługi płatności lub ochrony antybotowej, a wykradzione dane zapisywane są pod innym kluczem w localStorage. Taki dobór nazw dodatkowo utrudnia analizę ruchu i odróżnienie aktywności przestępczej od standardowych operacji aplikacji.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem kampanii jest kradzież pełnych danych kart płatniczych wraz z informacjami osobowymi użytkowników. Dla organizacji prowadzących sprzedaż internetową oznacza to ryzyko strat finansowych, incydentów związanych z naruszeniem danych, kosztów obsługi chargebacków, szkód reputacyjnych oraz możliwych konsekwencji regulacyjnych.
Z perspektywy obrony szczególnie groźne jest wykorzystanie zaufanych usług chmurowych i płatniczych jako kanału hostowania oraz exfiltracji. Wiele sklepów dopuszcza ruch do takich domen w sposób szeroki, a mechanizmy CSP, WAF lub monitoringu sieciowego mogą traktować go jako prawidłowy. To powoduje, że tradycyjne wskaźniki kompromitacji, takie jak nietypowa domena odbiorcy czy komunikacja z nieznaną infrastrukturą, przestają być wystarczające.
Atak pokazuje również, że rozbudowane ekosystemy skryptów zewnętrznych pozostają jednym z najsłabszych punktów bezpieczeństwa e-commerce. Każdy dodatkowy tag, integracja marketingowa lub komponent analityczny zwiększa powierzchnię ataku i utrudnia weryfikację, czy ładowany kod rzeczywiście realizuje wyłącznie deklarowaną funkcję biznesową.
Rekomendacje
Organizacje powinny przeprowadzić przegląd wszystkich kontenerów Google Tag Manager oraz skryptów ładowanych na stronach checkout, ze szczególnym uwzględnieniem nieautoryzowanych zmian i nietypowych wywołań do API usług zewnętrznych. Kluczowe jest monitorowanie integralności kodu front-endowego oraz wdrożenie procesu zatwierdzania zmian w tagach i szablonach sklepu.
Warto ograniczyć zaufanie do zewnętrznych domen wyłącznie do niezbędnych ścieżek i metod komunikacji, zamiast dopuszczać całe usługi w sposób ogólny. Polityki CSP powinny być maksymalnie precyzyjne, a ich logi regularnie analizowane pod kątem anomalii związanych z checkoutem. Dodatkowo należy monitorować użycie localStorage, dynamiczne wykonywanie kodu JavaScript oraz nietypowe operacje na metadanych obiektów w zewnętrznych API.
Administratorzy platform Magento i Adobe Commerce powinni zweryfikować integralność motywów, modułów i skryptów checkout, a także sprawdzić, czy nie doszło do nieautoryzowanych zmian w konfiguracji menedżerów tagów. Zespoły SOC i AppSec powinny rozszerzyć detekcję o scenariusze nadużycia legalnych usług chmurowych jako kanałów command-and-control lub exfiltracji.
Po stronie użytkowników końcowych dobrym środkiem ograniczającym skutki incydentu jest stosowanie kart wirtualnych jednorazowych lub kart z niskimi limitami transakcyjnymi. Pomaga to zminimalizować potencjalne straty nawet w przypadku skutecznego przechwycenia danych przez skimmer.
Podsumowanie
Opisana kampania potwierdza ewolucję zagrożeń Magecart w kierunku bardziej dyskretnych i trudniejszych do wykrycia technik. Zamiast korzystać z jawnie złośliwej infrastruktury, operatorzy ataku wykorzystują powszechnie zaufane usługi do hostowania ładunku i przechowywania wykradzionych danych. Dla sektora e-commerce oznacza to konieczność odejścia od prostego modelu zaufania do znanych domen i przejścia do dokładniejszej kontroli zachowania skryptów, integracji zewnętrznych oraz przepływu danych na stronach płatności.
Źródła
- BleepingComputer – Credit card theft campaign abuses Stripe to host stolen payment info — https://www.bleepingcomputer.com/news/security/credit-card-theft-campaign-abuses-stripe-to-host-stolen-payment-info/
- Sansec – Research and incident reporting on ecommerce skimming threats — https://sansec.io/
- Google Tag Manager Documentation — https://developers.google.com/tag-platform/tag-manager
- Stripe API Documentation — https://docs.stripe.com/api
- Adobe Commerce Security Best Practices — https://experienceleague.adobe.com/