Cyberprzestępcy wykorzystują coraz bardziej zaawansowane metody kradzieży danych kart płatniczych podczas zakupów internetowych. Badacze bezpieczeństwa z firmy Ohey opisali kampanię RTCGnaw, w której złośliwy kod JavaScript jest umieszczany w zainfekowanych sklepach Magento i WooCommerce. Oprogramowanie potrafi ukrywać swoją infrastrukturę za pomocą technologii blockchain, pobierać kolejne elementy ataku przez WebRTC i dostosowywać sposób przechwytywania danych do systemu płatności wykorzystywanego przez konkretny sklep. Szczególnie niebezpieczne są warianty podstawiające fałszywy formularz płatniczy w miejsce oryginalnego formularza operatora. Klient może wówczas nieświadomie przekazać numer karty, datę ważności, kod CVV oraz dane osobowe bezpośrednio cyberprzestępcom.
Według danych Ohey, podsumowanych 30 października 2026 roku, kod RTCGnaw wykryto na 23 witrynach internetowych od 4 września, przy czym 16 z nich odnotowano w ciągu ostatnich 30 dni. W październiku zidentyfikowano osiem nowych zainfekowanych witryn. Podczas analizy przeprowadzonej 29 października badacze potwierdzili również, że infrastruktura przestępców dostarcza różne wersje złośliwego oprogramowania zależnie od sklepu i wykorzystywanej integracji płatniczej. Nie jest to nowo odkryta podatność Magento ani WooCommerce, lecz aktywna kampania wymierzona w instalacje, do których przestępcy zdołali wcześniej wprowadzić nieautoryzowany kod.
Czym jest RTCGnaw i dlaczego stanowi zagrożenie dla e-commerce?
RTCGnaw należy do kategorii zagrożeń określanych jako web skimming lub Magecart. Ataki tego rodzaju polegają na umieszczaniu złośliwego JavaScript na stronach sklepów internetowych, przede wszystkim w miejscach, w których klienci wpisują dane potrzebne do opłacenia zamówienia. W przeciwieństwie do tradycyjnego phishingu, który często przekierowuje użytkownika na fałszywą witrynę, web skimming może działać bezpośrednio w legalnym sklepie. Kupujący odwiedza prawidłową domenę, widzi znany interfejs sprzedażowy i może nie zauważyć żadnych zmian sugerujących naruszenie bezpieczeństwa.
Każdy sklep internetowy przyjmujący płatności kartą jest potencjalnym celem tego rodzaju przestępstw, ale samo korzystanie z Magento lub WooCommerce nie oznacza obecności RTCGnaw. Atak wymaga wcześniejszego umieszczenia złośliwego skryptu w zasobach sklepu lub doprowadzenia do jego załadowania przez przeglądarkę klienta. Może się to zdarzyć po przejęciu dostępu administracyjnego, wykorzystaniu podatności w oprogramowaniu albo naruszeniu bezpieczeństwa zewnętrznego komponentu. W przypadku RTCGnaw badacze potwierdzili obecność nieautoryzowanego JavaScript, ale nie wskazali jednego wspólnego mechanizmu pierwotnego włamania do wszystkich zainfekowanych sklepów.
Najważniejszą cechą tej kampanii jest rozdzielenie niewielkiego skryptu uruchamiającego atak od właściwego kodu odpowiedzialnego za kradzież danych. Dzięki temu przestępcy mogą zmieniać działanie skimmera bez konieczności każdorazowego modyfikowania wszystkich zainfekowanych sklepów. Dodatkowo stosują techniki utrudniające identyfikację infrastruktury oraz wykrycie niebezpiecznych zmian przez administratorów.
Jak RTCGnaw infekuje sklepy Magento?
W przypadku Magento badacze Ohey zidentyfikowali wariant złośliwego oprogramowania dołączony do pliku JavaScript o nazwie cookies.js. Jest to szczególnie niebezpieczny sposób ukrywania infekcji, ponieważ administratorzy często koncentrują się na nieznanych plikach lub podejrzanych zewnętrznych skryptach, a rzadziej analizują zmiany dopisane do istniejących zasobów aplikacji.
Plik może zachowywać swoją pierwotną funkcjonalność, jednocześnie uruchamiając dodatkowy kod kontrolowany przez napastników. W rezultacie strona sklepu nadal działa, produkty są wyświetlane prawidłowo, a klienci mogą przechodzić do realizacji zamówienia. Sama obecność dodatkowych instrukcji JavaScript nie musi powodować błędów widocznych w interfejsie.
Wariant RTCGnaw wykryty w Magento wykorzystuje własny mechanizm komunikacji JSON-RPC do pobierania informacji z infrastruktury blockchain. Otrzymana odpowiedź może być dekodowana z Base64 i przekształcana w wykonywalny kod JavaScript za pomocą mechanizmu Blob. Badacze zaobserwowali także, że warianty związane z Magento mogą gromadzić aktualne wartości pól input, select i textarea przed uruchomieniem kolejnego etapu komunikacji.
Takie zachowanie jest szczególnie niepokojące na stronach finalizacji zamówienia, gdzie formularze zawierają dane kontaktowe, adresy rozliczeniowe i informacje związane z płatnościami. Nie oznacza ono jednak automatycznie, że każdy formularz w każdym zainfekowanym sklepie Magento został wykorzystany do przechwycenia pełnych numerów kart. Rzeczywisty zakres kradzieży zależy od wersji złośliwego kodu, dostępnych pól oraz sposobu działania konkretnej integracji płatniczej.
Fałszywy formularz płatniczy może wyglądać identycznie jak prawdziwy
Jednym z najbardziej niebezpiecznych elementów RTCGnaw jest możliwość podmieniania formularzy płatniczych. Podczas analizy z 29 października 2026 roku badacze uzyskali dwa różne warianty skimmera przygotowane dla zainfekowanych sklepów WooCommerce. Pierwszy był dostosowany do integracji Stripe, natomiast drugi do systemu GoDaddy Poynt.
W potwierdzonym wariancie Stripe złośliwy JavaScript ukrywa oryginalny formularz operatora płatności i zastępuje go własnym elementem iframe. Fałszywy formularz przypomina prawdziwy interfejs, wykorzystując podobną kolorystykę, oznaczenia organizacji kartowych oraz komunikaty dotyczące poprawności numerów kart. Może również sprawdzać wprowadzane dane, aby klient nie zauważył nietypowego zachowania.
Najważniejsze jest to, że formularz podstawiony przez przestępców znajduje się w kontekście strony sklepu, a złośliwy kod ma dostęp do wpisywanych znaków. W ten sposób może odczytywać numer karty, datę ważności, kod bezpieczeństwa i dane rozliczeniowe. Informacje te nie są wprowadzane do prawdziwego, zabezpieczonego formularza operatora płatności, lecz do elementu kontrolowanego przez napastników.
Nie należy jednak utożsamiać tej konkretnej implementacji fałszywego formularza Stripe z każdym wariantem RTCGnaw. Ohey potwierdziło ją podczas analizy wybranych instalacji WooCommerce. W przypadku Magento badacze udokumentowali odmienny sposób uruchamiania złośliwego kodu, w tym modyfikację cookies.js i pobieranie wartości pól formularzy.
Dlaczego klient może nie zauważyć kradzieży danych karty?
RTCGnaw wykorzystuje szczególnie podstępną metodę ukrywania kradzieży danych płatniczych. W zbadanych wariantach WooCommerce skimmer przechwytuje pierwszą próbę opłacenia zamówienia, pobiera informacje wpisane przez klienta, a następnie wyświetla komunikat sugerujący odrzucenie karty.
Po przechwyceniu danych złośliwy formularz jest usuwany, a na stronie ponownie pojawia się prawdziwy formularz operatora płatności. Klient, przekonany, że pierwsza próba zakończyła się zwykłym błędem autoryzacji, może wpisać dane karty ponownie. Tym razem transakcja jest obsługiwana przez rzeczywisty system płatniczy, a zamówienie zostaje prawidłowo opłacone.
W rezultacie właściciel sklepu może nie zauważyć problemu, ponieważ zamówienie pojawia się w systemie, płatność została zaksięgowana, a klient otrzymuje standardowe potwierdzenie zakupu. Pierwsza próba, podczas której doszło do kradzieży danych, mogła w ogóle nie trafić do operatora płatności.
Badacze ustalili również, że złośliwe oprogramowanie może wykorzystywać plik cookie ak_bmsc_login, aby przez określony czas nie wyświetlać ponownie fałszywego formularza. Takie działanie ogranicza ryzyko wzbudzenia podejrzeń u klienta, który właśnie otrzymał informację o nieudanej płatności.
To właśnie dlatego zainfekowane sklepy internetowe mogą przez dłuższy czas normalnie realizować sprzedaż, podczas gdy część kupujących nieświadomie przekazuje swoje dane płatnicze przestępcom.
Blockchain i WebRTC służą do ukrywania infrastruktury ataku
RTCGnaw wyróżnia się również nietypowym sposobem komunikacji z infrastrukturą kontrolowaną przez cyberprzestępców. Zamiast przechowywać wszystkie adresy serwerów bezpośrednio w kodzie JavaScript, część wariantów odczytuje je z inteligentnych kontraktów blockchain.
Badacze wykryli wykorzystanie sieci testowej BNB Smart Chain oraz sieci Polygon. Złośliwy kod może pobierać z nich informacje potrzebne do ustalenia, z którym serwerem należy się połączyć, aby otrzymać dalsze instrukcje.
Taka metoda utrudnia tradycyjne blokowanie infrastruktury przestępczej, ponieważ adres serwera odpowiedzialnego za dostarczanie złośliwego oprogramowania nie musi być na stałe zapisany w plikach sklepu. Osoba analizująca kod widzi jedynie komunikację z publicznie dostępnymi usługami blockchain, a właściwy adres kolejnego etapu może zostać wyznaczony dopiero podczas uruchomienia skryptu.
Drugą charakterystyczną technologią jest WebRTC. Zwykle kojarzy się ona z komunikacją głosową, obrazem i bezpośrednim przesyłaniem danych pomiędzy przeglądarkami. W przypadku RTCGnaw może służyć jako kanał dostarczania kolejnego etapu złośliwego JavaScript. Badacze zaobserwowali wykorzystanie RTCPeerConnection oraz kanałów danych do odbierania fragmentów kodu, które są następnie składane i wykonywane w przeglądarce.
Samo korzystanie przez stronę z technologii WebRTC lub blockchain nie dowodzi infekcji. Podejrzenia powinno natomiast wzbudzać nieoczekiwane połączenie z taką infrastrukturą podczas wpisywania danych płatniczych, szczególnie jeśli sklep nie posiada funkcjonalności wymagających tych technologii.
Skala kampanii RTCGnaw. Co potwierdzili badacze?
Według danych Ohey z 30 października 2026 roku zidentyfikowano łącznie 23 witryny zawierające kod RTCGnaw od początku obserwacji prowadzonych od 4 września. Piętnaście nowych infekcji odnotowano we wrześniu, a kolejnych osiem w październiku. W ciągu ostatnich 30 dni złośliwy kod wykryto na 16 witrynach.
Wśród pięciu stron ponownie zbadanych po upływie co najmniej 25 dni od pierwszego wykrycia, cztery nadal udostępniały złośliwy kod. Jest to istotny sygnał wskazujący, że przynajmniej część infekcji pozostaje aktywna przez dłuższy czas. Nie można jednak na podstawie tak niewielkiej próby wnioskować, że 80% wszystkich zainfekowanych sklepów pozostaje niezabezpieczonych.
Badacze potwierdzili obecność wariantów RTCGnaw zarówno w środowiskach WordPress/WooCommerce, jak i Magento. Nie przedstawili jednak pełnego podziału wszystkich 23 wykrytych witryn według platform, dlatego nie należy interpretować tej liczby jako liczby wyłącznie zainfekowanych sklepów Magento.
Co równie ważne, RTCGnaw nie jest nową podatnością oznaczoną numerem CVE. Nie istnieje jedna wersja Magento lub WooCommerce, której aktualizacja automatycznie usuwa wszystkie warianty tego zagrożenia. Jest to rodzina złośliwego oprogramowania umieszczanego w już naruszonych instalacjach sklepowych.
Jak rozpoznać obecność RTCGnaw w sklepie Magento?
Administratorzy Magento powinni rozpocząć kontrolę od sprawdzenia integralności plików JavaScript, zwłaszcza tych, które są ładowane podczas finalizacji zamówienia. Szczególne znaczenie ma analiza plików cookies.js, ponieważ w jednym z potwierdzonych wariantów właśnie do takiego zasobu dopisano złośliwy kod.
Należy porównać pliki używane przez działający sklep z ich zaufanymi odpowiednikami pochodzącymi z właściwych wersji Magento, motywu i rozszerzeń. Niepokojące mogą być nieznane fragmenty JavaScript dodane na końcu istniejących plików, szczególnie jeśli wykorzystują zaciemnianie kodu, nietypowe operacje dekodowania danych lub dynamiczne wykonywanie pobranych instrukcji.
Badacze Ohey wymieniają kilka technicznych sygnałów mogących pomóc w identyfikacji RTCGnaw:
- Nieznane wywołania JSON-RPC do sieci blockchain podczas wyświetlania strony płatności.
- Obecność charakterystycznego selektora
0xe2179b8elub dodatkowych mechanizmów odczytu danych z kontraktów. - Nietypowe użycie
RTCPeerConnectioni kanałów WebRTC do pobierania kodu JavaScript. - Obecność zmiennej
window.__OWE_EARLY, którą zaobserwowano w wariantach związanych z Magento. - Nieoczekiwane żądania do zewnętrznych domen przypominających usługi ochrony witryn, systemy analityczne lub zasoby CDN.
- Nowe skrypty dołączone do plików Magento, których nie ma w zaufanej kopii aplikacji.
Jednym z adresów infrastruktury zaobserwowanych przez badaczy jest cdn[.]api-middle-connect[.]com, a innym wskaźnikiem jest adres 103[.]141[.]13[.]26, powiązany z infrastrukturą komunikacyjną WebRTC. Zapis z nawiasami kwadratowymi służy wyłącznie bezpiecznej prezentacji wskaźników i nie jest przeznaczony do bezpośredniego otwierania.
Pojedynczy wskaźnik nie stanowi jeszcze ostatecznego dowodu infekcji. Z drugiej strony jego brak nie gwarantuje bezpieczeństwa, ponieważ przestępcy mogą zmieniać domeny, adresy i sposób działania kodu. Dlatego najważniejsze pozostaje sprawdzenie faktycznej integralności zasobów oraz obserwacja zachowania strony checkout.
Co powinien sprawdzić administrator WooCommerce?
W instalacjach WooCommerce mechanizm ukrywania złośliwego kodu może wyglądać inaczej. Ohey opisało między innymi wariant uruchamiany wyłącznie w momencie pojawienia się formularza płatności oraz kod dostosowany do sposobu optymalizacji skryptów przez WP Rocket. Oznacza to, że samo sprawdzenie strony głównej, katalogu produktów czy koszyka może nie ujawnić zagrożenia.
Kontrola powinna obejmować rzeczywistą stronę finalizacji zamówienia, wszystkie skrypty uruchamiane przez przeglądarkę oraz żądania sieciowe wysyłane w trakcie wyboru metody płatności. Szczególnie istotna jest weryfikacja, czy oryginalny formularz operatora płatności nie zostaje ukryty i zastąpiony dodatkowym elementem iframe.
Badacze wskazują również na podejrzany schemat transakcji, w którym klient najpierw otrzymuje informację o odrzuceniu karty, a po kilku sekundach realizuje prawidłową płatność. Jeżeli pierwsza próba nie pozostawia żadnego śladu u operatora płatności, może to uzasadniać dokładniejsze sprawdzenie strony checkout. Nie jest to jednak jednoznaczny dowód infekcji, ponieważ błędy płatności mogą występować również z innych powodów.
Dlaczego zwykła aktualizacja Magento może nie wystarczyć?
W przypadku RTCGnaw podstawowym problemem nie jest znana podatność określonej wersji Magento, lecz obecność złośliwego kodu w zainfekowanym środowisku. Administrator może więc korzystać z aktualnego wydania platformy, a mimo to nadal udostępniać klientom zmodyfikowany plik JavaScript, jeżeli nie został on usunięty podczas aktualizacji.
Podobny problem dotyczy zasobów przechowywanych w pamięci podręcznej serwera, CDN lub systemach optymalizacji JavaScript. Nawet po przywróceniu prawidłowego pliku na serwerze zainfekowana wersja może pozostawać dostępna w wcześniej wygenerowanych zasobach, jeżeli odpowiednie kopie nie zostaną usunięte.
W przypadku podejrzenia infekcji administrator powinien:
- Porównać pliki JavaScript z zaufaną wersją sklepu, jego motywu i rozszerzeń.
- Usunąć złośliwe fragmenty kodu oraz sprawdzić inne pliki, do których napastnik mógł uzyskać dostęp.
- Przeanalizować historię logowań do panelu administracyjnego, kont hostingowych i systemów wdrożeniowych.
- Sprawdzić aktualność Magento, zainstalowanych modułów i zależności, a także możliwe pierwotne źródło włamania.
- Unieważnić podejrzane sesje oraz wymienić dane uwierzytelniające, które mogły zostać ujawnione.
- Wyczyścić pamięć podręczną Magento, warstwy CDN i systemów optymalizujących pliki JavaScript.
- Ponownie przetestować cały proces płatności, korzystając z metod testowych bez podawania prawdziwych danych karty.
Samo usunięcie pojedynczego fragmentu JavaScript może okazać się niewystarczające, jeżeli osoba atakująca nadal posiada dostęp do panelu administracyjnego lub plików serwera. Konieczne jest więc ustalenie pierwotnego sposobu naruszenia bezpieczeństwa i sprawdzenie, czy nie pozostawiono dodatkowych mechanizmów umożliwiających ponowne wprowadzenie skimmera.
Jakie konsekwencje może mieć przechwycenie danych kart klientów?
W zbadanych wariantach RTCGnaw dla WooCommerce złośliwe oprogramowanie mogło gromadzić numer karty, datę ważności, kod CVV oraz dane rozliczeniowe, w tym imię, nazwisko, adres, telefon i adres e-mail. Taki zestaw informacji jest szczególnie niebezpieczny, ponieważ może zostać wykorzystany do prób przeprowadzania nieautoryzowanych transakcji lub dalszych oszustw wymierzonych w właściciela karty.
Dodatkowym problemem jest fakt, że dane płatnicze mogą zostać przechwycone przed przekazaniem ich do właściwego operatora płatności. Sklep może korzystać z bezpiecznej bramki, a sama transakcja może zostać prawidłowo obsłużona przez operatora, podczas gdy złośliwy JavaScript działa bezpośrednio w przeglądarce klienta.
Oznacza to, że zastosowanie uznanego systemu płatności nie wystarcza do ochrony kupujących, jeśli kod strony checkout został naruszony. Bezpieczeństwo obejmuje również kontrolę wszystkich skryptów uruchamianych podczas składania zamówienia oraz integralność zasobów dostarczanych przez serwer sklepu.
Jeżeli administrator potwierdzi infekcję i możliwość przechwytywania danych kart, powinien niezwłocznie skontaktować się z operatorem płatności lub agentem rozliczeniowym oraz uruchomić odpowiednią procedurę obsługi incydentu. Konieczne może być również ustalenie okresu obecności złośliwego kodu, zakresu potencjalnie przechwyconych informacji i liczby klientów, którzy korzystali w tym czasie z podatnego formularza.
W przypadku naruszenia danych osobowych należy przeprowadzić ocenę ryzyka zgodnie z RODO. W zależności od ustaleń może być wymagane zgłoszenie naruszenia organowi nadzorczemu, co do zasady w ciągu 72 godzin od jego stwierdzenia, oraz poinformowanie osób, których dotyczy wysokie ryzyko naruszenia praw lub wolności. Niezależnie od tego incydent dotyczący danych kart może powodować dodatkowe obowiązki wynikające z umów z operatorem płatności oraz wymagań bezpieczeństwa PCI DSS.
Czy RTCGnaw oznacza nową lukę bezpieczeństwa w Magento?
Nie. RTCGnaw jest aktywną kampanią wykorzystującą złośliwy JavaScript umieszczony w naruszonych sklepach internetowych. Nie przypisano jej jednego numeru CVE ani konkretnego zakresu podatnych wersji Magento czy WooCommerce.
Badacze potwierdzili infekcje sklepów korzystających z obu platform, ale nie wskazali, że wszystkie przypadki wynikały z wykorzystania tej samej podatności oprogramowania. To ważne rozróżnienie, ponieważ właściciel sklepu nie powinien zakładać, że wystarczy instalacja jednej poprawki bezpieczeństwa, aby wyeliminować wszystkie zagrożenia związane z RTCGnaw.
Najistotniejsze nowe ustalenia z 29–30 października 2026 roku dotyczą sposobu dostosowywania złośliwego kodu do konkretnych integracji płatniczych oraz dalszych obserwacji infrastruktury przestępców. Sama kampania była wykrywana już we wrześniu, dlatego nie należy przedstawiać jej jako zagrożenia odkrytego dopiero pod koniec października.
Jak ograniczyć ryzyko podobnych ataków w przyszłości?
RTCGnaw pokazuje, że tradycyjne sprawdzanie aktualności oprogramowania powinno być uzupełnione o kontrolę integralności kodu wykonywanego w przeglądarkach klientów. W przypadku sklepów korzystających z Magento i WooCommerce szczególnie istotne jest monitorowanie zasobów JavaScript ładowanych podczas płatności oraz wykrywanie nieoczekiwanych zmian w plikach aplikacji.
Warto wdrożyć mechanizmy monitorowania integralności plików, ograniczyć dostęp administracyjny do niezbędnych osób oraz stosować wieloskładnikowe uwierzytelnianie wszędzie tam, gdzie jest dostępne. Administratorzy powinni także kontrolować dodatkowe rozszerzenia, zewnętrzne skrypty i usługi analityczne, które mają możliwość wykonywania kodu na stronie sklepu.
Dodatkową ochronę mogą zapewniać odpowiednio skonfigurowane mechanizmy Content Security Policy, pozwalające ograniczać źródła skryptów oraz wybrane połączenia sieciowe wykonywane przez przeglądarkę. Nie są one jednak uniwersalnym rozwiązaniem, ponieważ złośliwy kod umieszczony w zaufanym pliku aplikacji może wymagać odrębnych metod wykrywania. Dlatego kontrola CSP powinna być połączona z monitorowaniem rzeczywistych zmian i analizą zachowania strony checkout.
Regularne testowanie procesu zakupowego powinno obejmować nie tylko sprawdzenie, czy klient może złożyć zamówienie i zapłacić za produkt, lecz również ustalenie, jakie skrypty są uruchamiane, dokąd wysyłane są informacje oraz czy formularz płatniczy pochodzi od właściwego operatora.
RTCGnaw pokazuje, że działający sklep nie zawsze jest bezpieczny
Kampania RTCGnaw stanowi poważne ostrzeżenie dla branży e-commerce, ponieważ pokazuje, jak zaawansowane mogą być współczesne ataki na proces finalizacji zamówienia. Przestępcy nie muszą doprowadzać do całkowitego unieruchomienia sklepu ani zmieniać jego widocznego wyglądu. Wystarczy umieszczenie odpowiednio przygotowanego JavaScript, który uruchamia się w określonych warunkach, przechwytuje dane płatnicze i ukrywa swoje działanie przed klientem oraz administratorem.
Potwierdzone warianty RTCGnaw wykorzystują elementy infrastruktury blockchain, WebRTC, ukryte skrypty i mechanizmy dopasowywania kodu do konkretnej bramki płatniczej. W Magento zaobserwowano modyfikację istniejącego pliku cookies.js, natomiast w WooCommerce udokumentowano między innymi podstawianie fałszywych formularzy Stripe i GoDaddy Poynt.
Najważniejszym zadaniem administratorów nie jest więc wyłącznie sprawdzanie numeru wersji Magento lub WooCommerce, ale również kontrolowanie integralności skryptów, zachowania formularzy płatniczych i ruchu sieciowego generowanego podczas checkout. Jeżeli sklep został naruszony, konieczne jest zarówno usunięcie złośliwego kodu, jak i ustalenie sposobu, w jaki przestępcy uzyskali możliwość jego umieszczenia.
Przypadek RTCGnaw przypomina, że prawidłowo zaksięgowana płatność i działający proces sprzedaży nie gwarantują bezpieczeństwa danych karty. Dlatego monitoring rzeczywistego zachowania strony płatności powinien być stałym elementem ochrony każdego sklepu, który przyjmuje transakcje internetowe.