Kupowali w prawdziwych sklepach, a dane kart trafiały do hakerów. Cyberatak na Convertr

Kupujesz produkt w legalnie działającym sklepie internetowym, wpisujesz dane karty płatniczej do formularza i zatwierdzasz zamówienie. Nie widzisz żadnej fałszywej strony, podejrzanego przekierowania ani komunikatu ostrzegawczego. Mimo to numer Twojej karty, data ważności i kod CVV mogą trafić bezpośrednio do cyberprzestępców. Taki mechanizm wykorzystano podczas cyberataku na brazylijską platformę e-commerce Convertr. Napastnicy zmodyfikowali skrypt analityczny ładowany przez sklepy korzystające z jej infrastruktury, dodając do niego kod przechwytujący dane płatnicze klientów. Złośliwe oprogramowanie wykryto 24 października 2026 roku, a dopiero trzy dni później potwierdzono jego usunięcie. Sprawa pokazuje, jak naruszenie jednego zewnętrznego komponentu może zagrozić klientom wielu niezależnych sprzedawców.

Cyberatak został opisany przez badaczy firmy Sansec, specjalizującej się w analizowaniu zagrożeń dla sklepów internetowych. W centrum incydentu znalazła się brazylijska platforma Convertr, która zapewnia przedsiębiorcom infrastrukturę do prowadzenia sprzedaży internetowej oraz obsługi procesu zakupowego. Z jej rozwiązań korzystają dziesiątki marek, przede wszystkim działających w branży modowej. Według informacji publikowanych przez operatora łączna wartość sprzedaży przeprowadzonej przez jego klientów przekroczyła 2 miliardy reali brazylijskich.

Nie oznacza to, że przestępcy ukradli 2 miliardy reali ani że poznali dane kart wszystkich klientów platformy. Kwota ta obrazuje skalę działalności handlowej Convertr. Liczba rzeczywiście przechwyconych kart i wartość potencjalnych strat nie zostały dotąd publicznie potwierdzone.

Jeden zainfekowany skrypt analityczny zagroził wielu sklepom internetowym

Współczesne sklepy internetowe rzadko działają wyłącznie na oprogramowaniu napisanym i utrzymywanym przez jednego przedsiębiorcę. Korzystają z zewnętrznych narzędzi analitycznych, systemów reklamowych, modułów płatności, czatów, programów lojalnościowych i różnych rozwiązań wspomagających sprzedaż. Ich kod jest często ładowany automatycznie w przeglądarce klienta podczas odwiedzania strony.

Podobnie działała infrastruktura Convertr. Sklepy korzystające z platformy pobierały skrypt analityczny z domeny należącej do operatora. W normalnych warunkach jego zadaniem było zbieranie informacji potrzebnych do analizowania ruchu na stronach, a nie przetwarzanie poufnych danych płatniczych.

Przestępcom udało się jednak zmodyfikować plik JavaScript dostarczany przez ten system. Do legalnego kodu dołączyli złośliwy fragment, który był następnie uruchamiany w przeglądarkach klientów odwiedzających formularze zakupowe.

To istota ataku na łańcuch dostaw oprogramowania: zamiast włamywać się osobno do każdego sklepu, napastnik przejmuje element wykorzystywany przez wielu sprzedawców jednocześnie. Jedna kompromitacja może wówczas skutkować pojawieniem się złośliwego kodu na dziesiątkach niezależnych witryn.

W przypadku Convertr właśnie taki scenariusz został potwierdzony przez Sansec. Zainfekowany skrypt był dostarczany przez wspólną usługę analityczną i ładowany na stronach płatności sklepów korzystających z infrastruktury operatora.

Numer karty, data ważności, CVV i dane osobowe. Co przechwytywał skimmer?

Złośliwy kod wykorzystywał technikę określaną jako web skimming lub Magecart, polegającą na przechwytywaniu informacji wprowadzanych do formularzy płatniczych. W przeciwieństwie do klasycznego phishingu, w którym użytkownik zostaje przekierowany na fałszywą stronę, skimmer może działać bezpośrednio na prawdziwej witrynie sklepu.

Badacze ustalili, że malware został przygotowany do pozyskiwania numeru karty płatniczej, miesiąca i roku jej ważności, kodu CVV, imienia i nazwiska posiadacza oraz brazylijskiego numeru identyfikacji podatkowej CPF. Informacje były odczytywane z formularza zakupowego oraz komunikacji pomiędzy stroną płatności a interfejsem API wykorzystywanym przez platformę.

Następnie skrypt przesyłał zgromadzone dane do zewnętrznego serwera kontrolowanego przez napastników. Odbywało się to bez konieczności wyświetlania klientowi dodatkowego okna czy uzyskiwania jego zgody.

Najgroźniejszy aspekt ataku polegał na tym, że klient mógł prawidłowo zakończyć zakup, nie mając żadnych podstaw do podejrzewania, że jego dane zostały równolegle przechwycone.

Kod został dodatkowo ukryty w sposób utrudniający szybkie rozpoznanie jego przeznaczenia. Zamiast umieszczać wszystkie instrukcje w czytelnej postaci, napastnicy wykorzystali mechanizm kodowania i późniejszego wykonywania zrekonstruowanych poleceń. Takie rozwiązanie ma utrudniać analizę przez administratorów sklepów i automatyczne narzędzia bezpieczeństwa.

Cyberprzestępcy udoskonalili malware w trakcie ataku

Chronologia ujawniona przez Sansec pokazuje, że napastnicy nie ograniczyli się do jednorazowego umieszczenia złośliwego kodu w systemie. Przez kolejne dni modyfikowali jego działanie, dostosowując je do sposobu funkcjonowania formularzy zakupowych Convertr.

Ostatnią czystą wersję skryptu badacze zaobserwowali 24 października o godzinie 05:03 UTC. Tego samego dnia o godzinie 23:22 wykryli już wersję zawierającą złośliwy komponent.

Początkowo malware wykorzystywał bardziej uniwersalny mechanizm identyfikowania pól formularza płatności. 26 października napastnicy wprowadzili nową wersję, która była lepiej dopasowana do konkretnych nazw pól i sposobu komunikacji z API płatności Convertr.

To ważny szczegół, ponieważ wskazuje na aktywne rozwijanie ataku w czasie rzeczywistym. Przestępcy obserwowali działanie środowiska i dostosowywali narzędzia tak, aby zwiększyć skuteczność przechwytywania informacji.

Sansec opublikował pierwszą analizę 26 października. W tym momencie zainfekowany skrypt nadal był dostępny w infrastrukturze Convertr, co oznaczało, że zagrożenie nie zostało jeszcze w pełni wyeliminowane.

Dopiero 27 października operator poinformował o usunięciu złośliwego kodu i aktualizacji systemu analitycznego, a badacze niezależnie potwierdzili, że wskazany wcześniej plik został oczyszczony.

Convertr korzystał z nieaktualnej wersji Plausible. Możliwa przyczyna włamania

W toku analizy Sansec ustalił, że Convertr korzystał z własnej instalacji Plausible Analytics, narzędzia analitycznego stanowiącego alternatywę dla Google Analytics. Platforma działała na starszej wersji Community Edition, w której wcześniej wykryto poważną podatność bezpieczeństwa.

Chodzi o CVE-2026-8467, błąd umożliwiający w określonych warunkach wykonanie poleceń na serwerze bez wcześniejszego uwierzytelnienia. Problem został usunięty przez producenta Plausible w maju 2026 roku, w wersji 3.2.1.

Według ustaleń Sansec środowisko Convertr korzystało z wersji z podatnej gałęzi 3.0, która nie otrzymała wymaganej aktualizacji. Mogło to stworzyć przestępcom możliwość naruszenia serwera, na którym znajdował się skrypt analityczny dostarczany następnie do sklepów.

Nie potwierdzono jednak, że właśnie CVE-2026-8467 została wykorzystana do przeprowadzenia włamania. Badacze nie dysponowali dziennikami zdarzeń z serwera Convertr, dlatego wskazali ten mechanizm jako prawdopodobną drogę uzyskania dostępu, a nie definitywnie ustaloną przyczynę.

To istotne rozróżnienie. Obecność niezałatanej podatności i późniejsza modyfikacja plików są poważnymi okolicznościami, ale samo ich współwystępowanie nie stanowi jeszcze pełnego dowodu przebiegu cyberataku.

Po ujawnieniu problemu Convertr zaktualizował Plausible do poprawionej wersji. Operator poinformował również o rozpoczęciu powiadamiania sprzedawców, dostawców usług płatniczych i odpowiednich instytucji.

To nie pierwszy atak tej grupy. Przestępcy infekowali również Magento, WooCommerce i OpenCart

Sansec powiązał kampanię przeciwko Convertr z brazylijską grupą cyberprzestępczą, której działalność obserwuje od lipca 2024 roku. Napastnicy specjalizują się w modyfikowaniu kodu sklepów internetowych i przechwytywaniu informacji związanych z płatnościami.

Wcześniejsze działania grupy obejmowały przede wszystkim ataki na pojedyncze witryny wykorzystujące Magento, WooCommerce oraz OpenCart. Złośliwe oprogramowanie było dostosowywane do różnych formularzy i dostawców płatności działających na brazylijskim rynku e-commerce.

Badacze odnotowali również warianty służące do podmieniania kodów QR wykorzystywanych w brazylijskim systemie płatności PIX. Taki mechanizm może prowadzić do skierowania pieniędzy na rachunek kontrolowany przez przestępców zamiast do właściwego odbiorcy.

Atak na Convertr był jednak jakościowo inny. Zamiast przejmować kolejne sklepy jeden po drugim, grupa uzyskała możliwość dystrybucji malware przez wspólny komponent wykorzystywany przez wielu sprzedawców.

To znacznie bardziej wydajny model działalności przestępczej. Z punktu widzenia napastnika każda nowa witryna korzystająca ze skompromitowanego skryptu może stać się dodatkowym miejscem przechwytywania danych.

Z punktu widzenia legalnie działających przedsiębiorców jest to natomiast poważne ostrzeżenie: nawet sklep utrzymywany zgodnie z dobrymi praktykami bezpieczeństwa może narazić klientów, jeśli ładuje kod pochodzący od zewnętrznego dostawcy, którego infrastruktura została przejęta.

Czy dane kart rzeczywiście zostały skradzione? Co wiemy o skali?

Analiza techniczna potwierdziła, że złośliwy skrypt był aktywny na stronach obsługiwanych przez Convertr i został przygotowany do przesyłania danych płatniczych na infrastrukturę napastników. Sansec wskazał również konkretne mechanizmy odczytu formularzy i transmisji informacji.

Nie oznacza to jednak, że znamy pełną skalę szkód.

Nie opublikowano dotychczas wiarygodnej liczby przechwyconych kart, liczby unikalnych poszkodowanych klientów ani łącznej wartości nieautoryzowanych transakcji. Brakuje również publicznego zestawienia wskazującego wszystkie sklepy, w których klienci mogli zostać narażeni podczas dokonywania zakupów.

Istotne jest także to, że nawet po usunięciu złośliwego kodu z serwera pewne ryzyko mogło utrzymywać się przez krótki czas z powodu przechowywania starszej wersji skryptu w pamięci podręcznej przeglądarki. Sansec zwrócił uwagę, że w niektórych przypadkach kopia zainfekowanego pliku mogła pozostawać dostępna lokalnie jeszcze przez około dobę.

Dlatego moment technicznego usunięcia malware nie musi być identyczny z chwilą całkowitego wyeliminowania jego wpływu na wszystkich użytkowników.

Jak to możliwe, że bank nie zatrzymał kradzieży danych karty?

Jednym z pytań, które mogą pojawić się w związku z takimi incydentami, jest skuteczność zabezpieczeń stosowanych przez banki i operatorów płatności. Jeżeli sklep korzysta z HTTPS, a transakcje kartowe mogą wymagać dodatkowego potwierdzenia, dlaczego przestępca w ogóle może przechwycić dane?

Odpowiedź tkwi w miejscu działania złośliwego kodu. HTTPS szyfruje połączenie pomiędzy przeglądarką a serwerem, ale nie uniemożliwia skryptowi uruchomionemu na stronie odczytania informacji, do których został mu przyznany dostęp. Jeśli malware działa bezpośrednio w formularzu zakupowym, może próbować pozyskać dane zanim zostaną one przesłane właściwemu dostawcy płatności.

Dodatkowe uwierzytelnianie, takie jak 3-D Secure, może ograniczać możliwość wykorzystania skradzionych danych w części transakcji. Nie oznacza jednak, że przejęcie numeru karty, daty ważności czy kodu CVV staje się nieszkodliwe.

Przestępcy mogą próbować wykorzystywać zdobyte informacje w różnych kanałach, prowadzić dalsze oszustwa lub łączyć dane płatnicze z informacjami tożsamościowymi.

Dlatego prawidłowy certyfikat HTTPS i obecność znanej bramki płatniczej nie są wystarczającą gwarancją, że wszystkie skrypty działające na stronie sklepu są bezpieczne.

Co powinni zrobić klienci sklepów i właściciele witryn?

Sansec zalecił osobom, które od 24 października dokonywały płatności kartą w sklepach korzystających z formularza Convertr, skontaktowanie się z bankiem w celu zabezpieczenia i ewentualnej wymiany karty. W przypadku potwierdzonej ekspozycji danych płatniczych takie postępowanie może ograniczyć ryzyko późniejszego ich wykorzystania.

Klienci powinni również monitorować historię transakcji i reagować na operacje, których nie rozpoznają. W przypadku podejrzenia nieautoryzowanego obciążenia należy niezwłocznie zgłosić sprawę do banku i zachować dokumentację transakcji.

Właściciele sklepów korzystających z Convertr powinni uzyskać od operatora informacje o zakresie incydentu, aktualizacji infrastruktury i ewentualnych obowiązkach związanych z powiadamianiem osób poszkodowanych. Znaczenie ma również współpraca z dostawcami płatności, którzy mogą pomóc w identyfikowaniu podejrzanych transakcji.

Z perspektywy administratorów innych sklepów internetowych szczególnie ważne jest regularne aktualizowanie oprogramowania, ograniczanie niepotrzebnych zewnętrznych skryptów i monitorowanie zmian w kodzie dostarczanym przez partnerów technologicznych. Rozwiązania takie jak Content Security Policy i Subresource Integrity mogą ograniczać część zagrożeń, jeśli zostaną prawidłowo zaprojektowane i wdrożone. Nie zastępują jednak bieżącej kontroli zależności oraz reagowania na incydenty.

Prawdziwy sklep nie zawsze oznacza bezpieczny zakup

Cyberatak na Convertr pokazuje jeden z najbardziej niebezpiecznych kierunków rozwoju przestępczości internetowej. Przestępcy nie muszą już zawsze przygotowywać fałszywych sklepów, kupować domen przypominających znane marki ani przekonywać użytkowników do odwiedzenia podejrzanej witryny. Mogą próbować przejąć element infrastruktury, który jest już wykorzystywany przez legalne przedsiębiorstwa.

Dla konsumenta oznacza to szczególnie trudną sytuację. Osoba dokonująca zakupu może nie popełnić żadnego oczywistego błędu: odwiedza prawdziwy sklep, wybiera rzeczywisty produkt i korzysta ze standardowego formularza płatności. Zagrożenie znajduje się w kodzie dostarczanym przez zewnętrzny system, na który klient nie ma bezpośredniego wpływu.

W przypadku Convertr potwierdzono obecność złośliwego kodu przechwytującego informacje płatnicze oraz jego usunięcie 27 października. Nadal nie znamy jednak ostatecznej liczby skradzionych kart i skali ewentualnych strat finansowych.

Sprawa powinna być ostrzeżeniem przede wszystkim dla przedsiębiorstw prowadzących sprzedaż internetową. Bezpieczeństwo sklepu nie zależy wyłącznie od jego własnego oprogramowania, certyfikatu SSL i zabezpieczeń panelu administracyjnego. Równie ważna jest kontrola wszystkich usług zewnętrznych, których kod trafia do przeglądarek klientów.

Jedna przejęta biblioteka, jeden skrypt analityczny lub jeden źle zabezpieczony dostawca może narazić klientów wielu sklepów jednocześnie. A skutki takiego ataku mogą być dla kupującego niemal niemożliwe do zauważenia w momencie dokonywania płatności.