Cztery sniffery JavaScript, które czekają na ciebie w sklepach internetowych

Praktycznie każdy z nas korzysta z usług sklepów internetowych, więc prędzej czy później ryzykujemy, że zostaniemy ofiarą snifferów JavaScript – specjalnego kodu, który przestępcy wprowadzają na stronę w celu kradzieży danych kart bankowych, adresów, loginów i haseł użytkowników.

Sniffery już dotknęły prawie 400 000 użytkowników witryny oraz aplikacji mobilnej linii lotniczych British Airways, a także odwiedzających brytyjską stronę sportowego giganta FILA i amerykańskiego dystrybutora biletów Ticketmaster. PayPal, Chase Paymenttech, USAePay, Moneris – te i wiele innych systemów płatności zostało zainfekowanych.

Analityk Threat Intelligence Group-IB Wiktor Okorokow opowiada o tym, jak sniffery są wprowadzane w kod strony i kradną informacje płatnicze, a także które systemy CRM atakują.

„Ukryte zagrożenie”

Tak się złożyło, że przez długi czas sniffery JS pozostawały poza zasięgiem analityków antywirusowych, a banki i systemy płatności nie postrzegały ich jako poważne zagrożenie. I to zupełnie niesłusznie. Eksperci Group-IB przeanalizowali 2440 zainfekowanych sklepów internetowych, których odwiedzający – łącznie około 1,5 miliona ludzi dziennie – byli narażeni na ryzyko kompromitacji. Wśród poszkodowanych znaleźli się nie tylko użytkownicy, ale także sklepy internetowe, systemy płatności i banki, które wydały skompromitowane karty.

Raport Group-IB był pierwszym badaniem rynku snifferów w darknecie, ich infrastruktury i sposobów monetyzacji, które przynoszą ich twórcom miliony dolarów. Zidentyfikowaliśmy 38 rodzin snifferów, z których tylko 12 było wcześniej znanych badaczom.

Szczegółowo omówimy cztery rodziny snifferów, które były badane w trakcie badania.

Rodzina ReactGet

Sniffery z rodziny ReactGet są wykorzystywane do kradzieży danych kart bankowych na stronach internetowych sklepów online. Sniffer może działać z wieloma różnymi systemami płatności używanymi na stronie: jedna wartość parametru odpowiada jednemu systemowi płatności, a poszczególne wykryte wersje sniffera mogą być używane do kradzieży danych logowania oraz danych kart bankowych z formularzy płatniczych kilku różnych systemów płatności, jako tzw. uniwersalny sniffer. Ustalono, że w niektórych przypadkach atakujący przeprowadzają ataki phishingowe na administratorów sklepów online w celu uzyskania dostępu do panelu administracyjnego strony.

Kampania z użyciem tej rodziny snifferów rozpoczęła się w maju 2017 roku, atakowi uległy strony zarządzane przez systemy CMS oraz platformy Magento, Bigcommerce, Shopify.

Jak ReactGet jest wprowadzany do kodu sklepu online

Oprócz «klasycznego» wstrzykiwania skryptu przez link, operatorzy snifferów z rodziny ReactGet używają specjalnej techniki: za pomocą kodu JavaScript sprawdzają, czy aktualny adres, na którym znajduje się użytkownik, odpowiada określonym kryteriom. Złośliwy kod zostanie uruchomiony tylko wtedy, gdy w bieżącym adresie URL znajduje się podciąg checkout lub onestepcheckout, onepage/, out/onepag, checkout/one, ckout/one. W ten sposób kod sniffera zostanie wykonany dokładnie w momencie, gdy użytkownik przechodzi do płatności i wprowadza dane płatnicze w formularzu na stronie.

Ten sniffer wykorzystuje niestandardową technikę. Dane płatnicze i osobowe ofiary są zbierane razem, kodowane za pomocą base64, a następnie uzyskany ciąg jest używany jako parametr do wysłania żądania na stronę przestępców. Najczęściej ścieżka do bramy imituje plik JavaScript, na przykład resp.js, data.js i tym podobnie, ale używane są również linki do plików obrazów, GIF i JPG. Ciekawostką jest to, że sniffer tworzy obiekt obrazu o wymiarach 1 na 1 piksel i wykorzystuje wcześniej uzyskany link jako parametr. src Obrazy. Oznacza to, że dla użytkownika takie zapytanie w ruchu będzie wyglądać jak zapytanie o zwykły obrazek. Podobną technikę zastosowano w snifferach rodziny ImageID. Ponadto technika używająca obrazu o wymiarach 1 na 1 piksel jest stosowana w wielu legalnych skryptach analityki internetowej, co także może wprowadzić użytkownika w błąd.

Analiza wersji

Analiza aktywnych domen używanych przez operatorów snifferów ReactGet ujawniła wiele różnych wersji snifferów tej rodziny. Wersje różnią się obecnością lub brakiem obfuskacji, a każdy sniffer jest zaprojektowany do obsługi określonej systemu płatności, który przetwarza płatności kartą bankową do sklepów internetowych. Przeanalizowawszy wartość parametru odpowiadającego numerowi wersji, specjaliści Group-IB uzyskali pełną listę dostępnych wariacji snifferów, a na podstawie nazw pól formularzy, które każdy sniffer wyszukuje w kodzie strony, określili systemy płatności, na które jest skierowany sniffer.

Lista snifferów i odpowiadających im systemów płatności

Sniffer haseł

Jedną z zalet snifferów JavaScript działających po stronie klienta jest ich uniwersalność: zainstalowany na stronie złośliwy kod może kraść dane każdego rodzaju, zarówno dane płatnicze, jak i login oraz hasło do konta użytkownika. Specjaliści Group-IB odkryli próbkę sniffera z rodziny ReactGet, zaprojektowaną do kradzieży adresów e-mail i haseł użytkowników strony.

Przecięcie z snifferem ImageID

W trakcie analizy jednego z zainfekowanych sklepów ustalono, że jego strona została zainfekowana dwukrotnie: oprócz złośliwego kodu sniffera z rodziny ReactGet, odkryto kod sniffera z rodziny ImageID. To przecięcie może być świadectwem, że operatorzy stojący za wykorzystaniem obu snifferów stosują podobne techniki do wprowadzenia złośliwego kodu.

Uniwersalny sniffer

W trakcie analizy jednej z nazw domen powiązanych z infrastrukturą snifferów ReactGet ustalono, że ta sama osoba zarejestrowała trzy inne nazwy domen. Te trzy domeny imitowały domeny rzeczywiście istniejących stron i wcześniej były wykorzystywane do hostowania snifferów. Analiza kodu trzech legalnych witryn ujawniła nieznany sniffer, a dalsza analiza pokazała, że to ulepszona wersja sniffera ReactGet. Wszystkie wcześniej śledzone wersje snifferów z tej rodziny były skierowane na konkretny system płatności, co oznacza, że dla każdego systemu płatności potrzebna była specjalna wersja sniffera. W tym przypadku jednak odkryto uniwersalną wersję sniffera, zdolną do kradzenia informacji z formularzy związanych z 15 różnymi systemami płatności i modułami ecommerce do przeprowadzania płatności online.

Na początku pracy sniffera poszukiwał podstawowych pól formularza zawierających dane osobowe ofiary: imię i nazwisko, adres fizyczny, numer telefonu.

Następnie sniffer przeszukiwał ponad 15 różnych prefiksów, odpowiadających różnym systemom płatności i modułom do płatności online.

Dane osobowe ofiary oraz informacje o płatnościach były zbierane w całość i wysyłane na kontrolowaną przez przestępcę stronę: w tym konkretnym przypadku odkryto dwie wersje uniwersalnego sniffera ReactGet, umiejscowione na dwóch różnych zhakowanych stronach. Obie wersje wysyłały jednak skradzione dane na tę samą zhakowaną stronę. zoobashop.com.

Analiza prefiksów używanych przez sniffera do wyszukiwania pól zawierających informacje dotyczące płatności ofiary pozwoliła określić, że ten wzór sniffera był skierowany na następujące systemy płatności:

• Authorize.Net
• Verisign
• First Data
• USAePay
• Stripe
• PayPal
• ANZ eGate
• Braintree
• DataCash (MasterCard)
• Realex Payments
• PsiGate
• Heartland Payment Systems

Jakie narzędzia są używane do kradzieży informacji o płatnościach

Pierwszym narzędziem odkrytym w trakcie analizy infrastruktury atakujących jest narzędzie do obfuskacji złośliwych skryptów odpowiedzialnych za kradzież kart bankowych. Na jednym z hostów atakujących znaleziono skrypt bash, który wykorzystuje CLI projektu javascript-obfuscator do automatyzacji obfuskacji kodu snifferów.

Drugie odkryte narzędzie służy do generowania kodu odpowiedzialnego za załadowanie głównego sniffera. To narzędzie generuje kod JavaScript, który sprawdza, czy użytkownik znajduje się na stronie płatności, poprzez wyszukiwanie w bieżącym adresie URL użytkownika ciągów checkout, cart i tak dalej, a jeśli wynik jest pozytywny, to kod ładuje główny sniffer z serwera przestępców. W celu ukrycia złośliwej aktywności wszystkie ciągi, w tym testowe ciągi do określenia strony płatności, jak również link do sniffera, są kodowane przy użyciu base64.

Ataki phishingowe

Podczas analizy infrastruktury sieciowej atakujących ustalono, że często w celu uzyskania dostępu do panelu administracyjnego docelowego sklepu internetowego, grupa przestępcza wykorzystuje phishing. Atakujący rejestrują domenę wizualnie podobną do domeny sklepu, a następnie uruchamiają na niej fałszywą formę logowania do panelu administracyjnego Magento. W przypadku sukcesu atakujący uzyskają dostęp do panelu administracyjnego CMS Magento, co daje im możliwość edytowania komponentów strony i wprowadzenia sniffera do kradzieży danych kart kredytowych.

Infrastruktura

Rodzina G-Analytics

Ta rodzina snifferów jest wykorzystywana do kradzieży kart klientów sklepów internetowych. Pierwsza domena używana przez grupę została zarejestrowana w kwietniu 2016 roku, co może świadczyć o rozpoczęciu działalności grupy w połowie 2016 roku.

W bieżącej kampanii grupa używa nazw domen imitujących rzeczywiste usługi, takie jak Google Analytics i jQuery, maskując aktywność snifferów legalnymi skryptami oraz podobnymi do legalnych nazwami domen. Atakowane były strony działające na CMS Magento.

Jak G-Analytics jest wdrażany w kodzie sklepu internetowego

Cechą wyróżniającą tej grupy jest wykorzystanie różnych metod kradzieży informacji o płatnościach użytkowników. Oprócz klasycznej techniki wstrzykiwania kodu JavaScript w część klienta strony, grupa przestępcza stosowała również technikę wstrzykiwania kodu w część serwerową strony, mianowicie w skrypty PHP przetwarzające dane wprowadzane przez użytkowników. Ta metoda jest niebezpieczna, ponieważ utrudnia wykrycie złośliwego kodu przez zewnętrznych badaczy. Specjaliści Group-IB odkryli wersję sniffera wstrzykniętego w kod PHP strony, wykorzystującą jako bramę domenę dittm.org.

Została również odkryta wczesna wersja sniffera, wykorzystująca do zbierania skradzionych danych tę samą domenę dittm.org, ale ta wersja jest już przeznaczona do instalacji po stronie klienta sklepu internetowego.

Później grupa zmieniła swoją taktykę i zaczęła zwracać większą uwagę na ukrywanie złośliwej aktywności i maskowanie.

Na początku 2017 roku grupa zaczęła używać domeny jquery-js.com, udającej CDN dla jQuery: po przejściu na stronę przestępców użytkownik jest przekierowywany na legitną stronę jquery.com.

A w połowie 2018 roku grupa przyjęła nazwę domeny g-analytics.com i zaczęła maskować działalność sniffera jako legitimaną usługę Google Analytics.

Analiza wersji

W trakcie analizy domen używanych do przechowywania kodu snifferów ustalono, że na stronie znajduje się wiele wersji, które różnią się obecnością obfuskacji, a także obecnością lub brakiem niedostępnego kodu dodanego do pliku w celu odwrócenia uwagi i ukrycia złośliwego kodu.

Ostatecznie na stronie jquery-js.com zidentyfikowano sześć wersji snifferów. Skradzione dane te sniffery wysyłają na adres znajdujący się na tej samej stronie co sam sniffer: hxxps://jquery-js[.]com/latest/jquery.min.js:

• hxxps://jquery-js[.]com/jquery.min.js
• hxxps://jquery-js[.]com/jquery.2.2.4.min.js
• hxxps://jquery-js[.]com/jquery.1.8.3.min.js
• hxxps://jquery-js[.]com/jquery.1.6.4.min.js
• hxxps://jquery-js[.]com/jquery.1.4.4.min.js
• hxxps://jquery-js[.]com/jquery.1.12.4.min.js

Późniejsza domena g-analytics.com, używana przez grupę w atakach od połowy 2018 roku, służy jako magazyn dla większej liczby snifferów. Ostatecznie wykryto 16 różnych wersji sniffera. W tym przypadku brama do wysyłania skradzionych danych została zamaskowana jako link do obrazu o formacie GIF: hxxp://g-analytics[.]com/__utm.gif?v=1&_v=j68&a=98811130&t=pageview&_s=1&sd=24-bit&sr=2560×1440&vp=2145×371&je=0&_u=AACAAEAB~&jid=1841704724&gjid=877686936&cid
=1283183910.1527732071:

• hxxps://g-analytics[.]com/libs/1.0.1/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.10/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.11/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.12/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.13/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.14/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.15/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.16/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.3/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.4/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.5/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.6/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.7/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.8/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.9/analytics.js
• hxxps://g-analytics[.]com/libs/analytics.js

Monetyzacja skradzionych danych

Grupa przestępcza monetyzuje skradzione dane, sprzedając karty za pośrednictwem specjalnie stworzonego podziemnego sklepu, który świadczy usługi dla koderów. Analiza domen używanych przez atakujących pozwoliła ustalić, że google-analytics.cm został zarejestrowany przez tego samego użytkownika, co domena cardz.vc. Domena cardz.vc dotyczy sklepu sprzedającego skradzione karty bankowe Cardsurfs (Flysurfs), który zyskał popularność jeszcze w czasach aktywności podziemnej giełdy AlphaBay jako sklep sprzedający karty bankowe, skradzione za pomocą sniffera.

Analizując domenę analytic.is, znajdującą się na tym samym serwerze co domeny używane przez sniffery do zbierania skradzionych danych, specjaliści Group-IB odkryli plik zawierający logi Cookie-stealera, który najwyraźniej został później porzucony przez twórcę. Jeden z wpisów w logach zawierał domenę iozoz.com, która wcześniej była używana w jednym z snifferów aktywnych w 2016 roku. Przypuszczalnie ta domena była wcześniej używana przez cyberprzestępcę do zbierania skradzionych danych za pomocą sniffera. Ta domena została zarejestrowana na adres e-mail kts241@gmail.com, który również był używany do rejestracji domen cardz.su i cardz.vc, związanych z kategorią sklepów Cardsurfs.

Na podstawie zebranych danych można przypuszczać, że rodzina snifferów G-Analytics i podziemny sklep ze skradzionymi kartami bankowymi Cardsurfs są zarządzane przez te same osoby, a sklep jest używany do sprzedaży kart bankowych skradzionych za pomocą sniffera.

Infrastruktura

Rodzina Illum

Illum to rodzina snifferów stosowanych do ataków na sklepy internetowe działające na CMS Magento. Oprócz wprowadzania złośliwego kodu, operatorzy tego sniffera również korzystają z wprowadzania pełnych fałszywych formularzy płatności, które wysyłają dane do kontrolowanych przez przestępców bramek.

Podczas analizy infrastruktury sieciowej używanej przez operatorów tego sniffera, zauważono dużą ilość złośliwych skryptów, exploitów, fałszywych formularzy płatności, a także zbiorczek wzorców złośliwych snifferów konkurencji. Z informacji dotyczących dat pojawiania się nazw domen używanych przez grupę można przypuszczać, że początek kampanii przypada na koniec 2016 roku.

Jak Illum wprowadza się w kod sklepu internetowego

Pierwsze wykryte wersje sniffera były wprowadzane bezpośrednio do kodu skompromitowanej strony. Skradzione dane były wysyłane na adres cdn.illum[.]pw/records.php, a brama była zakodowana za pomocą base64.

Później odkryto spakowaną wersję sniffera, używającą innej bramy — records.nstatistics[.]com/records.php.

Zgodnie z raportu Willem de Groot, ten sam host był używany w snifferze, który został wdrożony na stronie sklepu, należącego do niemieckiej partii politycznej CSU.

Analiza strony przestępców

Specjaliści Group-IB odkryli i przeanalizowali stronę, używaną przez tę grupę przestępczą do przechowywania narzędzi i zbierania skradzionych informacji.

Wśród narzędzi odkrytych na serwerze przestępców znaleziono skrypty i exploity do podwyższania uprawnień w systemie Linux: na przykład, Linux Privilege Escalation Check Script, opracowany przez Mike'a Czumaka, oraz exploit dla CVE-2009-1185.

Bezpośrednio do ataków na sklepy internetowe przestępcy użyli dwóch exploitów: pierwszy zdolny do wstrzyknięcia złośliwego kodu w core_config_data przy wykorzystaniu eksploatacji CVE-2016-4010, drugi eksploatuje podatność RCE w wtyczkach CMS Magento, pozwalając na wykonanie dowolnego kodu na podatnym serwerze WWW.

Podczas analizy serwera odkryto również różne próbki snifferów i fałszywych formularzy płatności, używanych przez przestępców do zbierania informacji płatniczych z hakowanych stron. Jak można zauważyć z poniższej listy, niektóre skrypty były indywidualnie tworzone dla każdej hakowanej strony, podczas gdy dla określonych CMS i bramek płatności używano uniwersalnego rozwiązania. Na przykład, skrypty segapay_standart.js i segapay_onpage.js są przeznaczone do wstrzykiwania na strony korzystające z bramki płatności Sage Pay.

Lista skryptów dla różnych bramek płatności

Host paymentnow[.]tk, używana jako brama w skrypcie payment_forminsite.js, została odkryta jako subjectAltName w kilku certyfikatach związanych z usługą CloudFlare. Ponadto na hoście znajdował się skrypt evil.js. Sądząc po nazwie skryptu, mógł on być użyty w ramach eksploatacji CVE-2016-4010, dzięki czemu można wstrzyknąć złośliwy kod do stopki strony zarządzanej przez CMS Magento. Jako bramę ten skrypt wykorzystał host request.requestnet[.]tk, używający tego samego certyfikatu, co host paymentnow[.]tk.

Fałszywe formularze płatności

Poniżej na rysunku pokazano przykład formularza do wprowadzenia danych karty. Ten formularz był używany do wstrzyknięcia na stronę sklepu internetowego i kradzieży danych kart.

Na następnym rysunku znajduje się przykład fałszywego formularza płatności PayPal, który był wykorzystywany przez cyberprzestępców do infiltracji stron korzystających z tej metody płatności.

Infrastruktura

Rodzina CoffeMokko

Rodzina snifferów CoffeMokko, przeznaczonych do kradzieży danych kart bankowych użytkowników sklepów internetowych, jest używana co najmniej od maja 2017 roku. Prawdopodobnie operatorami tej rodziny snifferów jest grupa przestępcza Group 1, opisana przez specjalistów RiskIQ w 2016 roku. Ataki miały miejsce na stronach działających na takich CMS-ach jak Magento, OpenCart, WordPress, osCommerce, Shopify.

Jak CoffeMokko infiltruje kod sklepu internetowego

Operatorzy tej rodziny tworzą unikalne sniffery dla każdego zainfekowania: plik sniffera znajduje się w katalogu src lub js na serwerze cyberprzestępców. Infiltracja kodu strony odbywa się poprzez bezpośredni link do sniffera.

W kodzie sniffera są sztywno zakodowane nazwy pól formularza, z których należy ukraść dane. Sniffer sprawdza również, czy użytkownik znajduje się na stronie płatności, porównując listę słów kluczowych z bieżącym adresem użytkownika.

Niektóre wykryte wersje sniffera były zablokowane i zawierały szyfrowany ciąg, w którym przechowywana była główna tablica zasobów: to w niej znajdowały się nazwy pól formularzy dla różnych systemów płatności, a także adres bramki, na który należało wysyłać skradzione dane.

Skradzione informacje płatnicze były wysyłane do skryptu na serwerze cyberprzestępców przez /savePayment/index.php или /tr/index.php. Prawdopodobnie ten skrypt służy do przekazywania danych z bramki na główny serwer, który konsoliduje dane ze wszystkich snifferów. Aby ukryć przesyłane dane, cała informacja płatnicza ofiary jest szyfrowana przy użyciu base64, a następnie następuje kilka zamian symboli:

• symbol «e» zamieniany jest na «:»
• symbol «w» zamieniany jest na «+»
• symbol «o» zamieniany jest na «%»
• symbol «d» zamieniany jest na «#»
• symbol «a» zamieniany jest na «-»
• symbol «7» zamieniany jest na «^»
• symbol «h» zamieniany jest na «_»
• symbol «T» zamieniany jest na «@»
• symbol «0» zamieniany jest na «/»
• symbol «Y» zamieniany jest na «*»

W wyniku zamian symboli zakodowane przy użyciu base64 dane są niemożliwe do dekodowania, nie przeprowadzając odwrotnej konwersji.

Oto fragment kodu sniffera, który nie był poddany obfuskacji:

Analiza infrastruktury

W wcześniejszych kampaniach przestępcy rejestrowali domeny podobne do domen legitnych stron internetowych sklepów online. Ich domena mogła różnić się od legitnej o jeden znak lub inny TLD. Zarejestrowane domeny były używane do przechowywania kodu sniffera, którego link był osadzony w kodzie sklepu.

Ta grupa również używała domen przypominających nazwy popularnych wtyczek jQuery (slickjs[.]org dla stron korzystających z wtyczki slick.js), bramek płatności (sagecdn[.]org dla stron korzystających z systemu płatności Sage Pay).

Później grupa zaczęła tworzyć domeny, których nazwa nie miała nic wspólnego ani z domeną sklepu, ani z tematyką sklepu.

Każdej domenie odpowiadała strona, na której tworzono katalog /js lub /src. W tym katalogu przechowywane były skrypty snifferów: po jednym snifferze na każde nowe zarażenie. Sniffer był wprowadzany do kodu strony przez bezpośredni link, ale w rzadkich przypadkach przestępcy modyfikowali jeden z plików strony i dodawali do niego złośliwy kod.

Analiza kodu

Pierwszy algorytm obfuskacji

W niektórych wykrytych próbkach snifferów tej rodziny kod był obfuskowany i zawierał zaszyfrowane dane niezbędne do działania sniffera: w szczególności adres bramy sniffera, listę pól formularza płatności, a w niektórych przypadkach – kod fałszywego formularza płatności. W kodzie wewnątrz funkcji zasoby były zaszyfrowane przy pomocy XOR za pomocą klucza, który był przekazywany jako argument tej samej funkcji.

Po odszyfrowaniu ciągu odpowiednim kluczem, unikalnym dla każdej próbki, można uzyskać ciąg zawierający wszystkie ciągi z kodu sniffera oddzielone separatorem.

Drugi algorytm obfuskacji

W nowszych próbkach snifferów tej rodziny zastosowano inny mechanizm obfuskacji: w tym przypadku dane były zaszyfrowane przy pomocy własnego algorytmu. Ciąg zawierający zaszyfrowane dane konieczne do działania sniffera był przekazywany jako argument funkcji deszyfrującej.

Za pomocą konsoli przeglądarki można odszyfrować zaszyfrowane dane i uzyskać tablicę zawierającą zasoby sniffera.

Związek z wcześniejszymi atakami MageCart

W trakcie analizy jednej z domen używanych przez grupę jako brama do zbierania skradzionych danych ustalono, że na tej domenie uruchomiona jest infrastruktura do kradzieży kart kredytowych, identyczna z tą, która była używana przez Grupę 1 — jedną z pierwszych grup, wykryta przez specjalistów RiskIQ.

Na hoście rodziny sniffersów CoffeMokko znaleziono dwa pliki:

• mage.js — plik zawierający kod sniffersów Grupy 1 z adresem bramy js-cdn.link
• mag.php — skrypt PHP odpowiedzialny za zbieranie danych skradzionych przez sniffers.

Содержимое файла mage.js
Ustalono także, że najwcześniejsze domeny używane przez grupę stojącą za rodziną sniffersów CoffeMokko były zarejestrowane 17 maja 2017 roku:

• link-js[.]link
• info-js[.]link
• track-js[.]link
• map-js[.]link
• smart-js[.]link

Format tych nazw domen pokrywa się z nazwami domen Grupy 1, które były używane w atakach w 2016 roku.

Na podstawie odkrytych faktów można wysunąć przypuszczenie, że istnieje związek między operatorami sniffersów CoffeMokko a grupą przestępczą Grupą 1. Przypuszczalnie operatorzy CoffeMokko mogli zapożyczyć od swoich poprzedników narzędzia i oprogramowanie do kradzieży kart. Jest jednak bardziej prawdopodobne, że grupa przestępcza odpowiedzialna za wykorzystanie sniffersów rodziny CoffeMokko to ci sami ludzie, którzy przeprowadzali ataki w ramach działalności Grupy 1. Po publikacji pierwszego raportu dotyczącego działalności grupy przestępczej wszystkie ich nazwy domen zostały zablokowane, a narzędzia dokładnie zbadane i opisane. Grupa była zmuszona do przerwy, aby poprawić swoje wewnętrzne narzędzia i przepisać kod sniffersów, aby kontynuować ataki i pozostać niezauważonymi.

Infrastruktura

Źródło: habr.com