Rozmowy z botnetem, czyli analiza zagrożenia krok po kroku

Mało jest w Polsce zespołów, które nie tylko analizują zagrożenia, ale także dzielą się publicznie wynikami swoich analiz. Takie inicjatywy zasługują na wsparcie i poparcie, zatem z przyjemnością przedstawiamy najnowszy raport zespołu SOC Exatel S.A.

Poniższy materiał powstał w oparciu o zapis działań operacyjnych pracowników Security Operations Center (SOC) Exatel SA. Jest to przykład działań analitycznych od momentu wykrycia zagrożenia aż po etap wyciągania wniosków. Treść raportu dostępna jest również do ściągnięcia w formacie PDF.

13 listopada 2015 r.  na skrzynkę jednego z pracowników Exatel trafiła wiadomość zatytułowana „You’ve Just accepted a voice mail! Dl5hi”. Załącznik wiadomości „80rashawn.zip” zawierał plik wykonywalny (emilfecko.exe), którego suma MD5 (bf992dec6fc27f9ff55daca7a864a8db) nie figurowała w bazie danych zagrożeń (Virustotal). System antywirusowy zainstalowany na komputerach pracowników również nie zidentyfikował pliku załącznika jako potencjalnego zagrożenia. Mimo to wiadomość została zatrzymana przez bramkę pocztową jako podejrzaną jeszcze przed dostarczeniem jej do pracownika. Wiadomość została przekazana przez oficera bezpieczeństwa do analizy celem ustalenia jej szkodliwości oraz potencjalnych zamiarów atakującego.

Poniższy tekst przedstawia wyniki tej analizy technicznej. Ujawniła ona, iż otrzymany plik wykonywalny był nową odmianą konia trojańskiego Bayrob, którego początki sięgają 2007 roku. Jego aktywność końcem 2015 roku związana była z rozpoczęciem fazy rozbudowy botnetu.

Wstępna analiza pliku załącznika (emilfecko.exe)

Plik przesyłany w załączniku wiadomości jest tak naprawdę modułem startowym (downloader’em) konia trojańskiego.  Ma on za zadanie nawiązanie komunikacji z serwerem wydawania rozkazów (C&C) kontrolowanym przez operatora botnetu i pobranie właściwego modułu konia trojańskiego.

Po uruchomieniu pliku „emilfecko.exe”, w katalogu głównym dysku C tworzony jest katalog o losowej nazwie, która nie jest generowana dynamicznie (jest statycznie wkompilowanym w kod wykonywalny stringiem). W utworzonym katalogu kod wykonywalny tworzy dwie kopie o również losowych nazwach oraz trzy pliki o wielkościach od 0 do 16 bajtów:

Następnie downloader instaluje się w systemie, zapewniając automatyczne uruchomienie wraz z jego  startem. Downloader  tworzy usługę systemową o nazwie składającej się z pięciu losowych słów –  najprawdopodobniej generowaną podczas tworzenia nowej mutacji trojana (używając do tego słownika predefiniowanego przez autora).

Proces „emilfecko.exe” uruchamia jedną ze swoich kopii, po czym kończy działanie. Nowo utworzony proces (vkhijxqnrz.exe) uruchamia swoją kopię binarną (wibmcmzur.exe), z przełącznikiem „WATCHDOG” przekazanym w linii komend. Jedyną funkcjonalnością tak utworzonego procesu jest monitorowanie czy jego proces potomny jest wciąż uruchomiony. W razie próby zamknięcia procesu potomnego – jest on natychmiast przywracany.

Już po tych kilku symptomach w sposobie zachowania (użycie przełącznika o nazwie „WATCHDOG”, charakterystyczny sposób budowy nazw losowych katalogów i plików, imię i nazwisko w nazwie pliku wykonywalnego) można rozpoznać rodzinę malware o nazwach kodowych Bayrob / Nivdort. Infekcję malware należącym do tej rodziny rejestrowano już w 2007 roku, a ostatnią dokładną analizę mutacji malware tej odmiany opublikował Jason Geffner w 2013 roku.

Kontynuując analizę zauważyliśmy, iż proces główny download’era zaraz po uruchomieniu rozpoczyna próby nawiązania komunikacji HTTP (port 80) z serwerem wydawania rozkazów (C&C). Następnie – w razie udanego połączenia lub po braku poprawnej odpowiedzi z kolejno odpytanych 85 domen – proces zaprzestaje prób nawiązania połączenia na 30 minut. Po tym czasie próbuje nawiązać kolejne połączenie z serwerem C&C i odebrać potencjalne rozkazy:

Przykładowa nieudana próba nawiązania połączenia (zdalny serwer nie jest serwerem kontrolowanym przez operatora botnetu) wygląda następująco:

Natomiast komunikacja HTTP, którą malware rozpoznaje jako poprawną (identyfikującą pozytywnie serwer: „followshout.net” jako będący jego C&C), zawiera odpowiedź binarną w następującej postaci:

Po poprawnej odpowiedzi C&C na pakiet powitalny malware (żądanie „GET \index.php”), proces wysyła pakiet POST z buforem zakodowanym Base64, zawierającym dane identyfikujące nowo przejętą maszynę:

Treść przesyłana jest zmienną o nazwie ‘post’ i zakodowana Base64:

a po zdekodowaniu wygląda następująco:

i zawiera kolejno:

• adres email (prawdopodobnie należący do ofiary, z której maszyny wysłano wiadomość po otrzymaniu rozkazu propagacji malware),
• nazwę katalogu, w którym instaluje się downloader malware (jikdfcd),
• nazwy utworzonych na dysku kopii downloadera: usługi systemowej i watchdog’a,
• dwie nazwy, z których jedna jest użyta jako nazwa usługi systemowej,
• niezidentyfikowaną wartość numeryczną (008),
• nazwę komputera (SANDBOX01),
• adres MAC karty sieciowej (000C29C000F6),
• sumę MD5 (7284fb795b1aa79249196a6898377f48) obliczoną na łańcuchu tekstowym: <adres_email_ofiary><nazwa_komputera>,

Poniżej przedstawiono proces budowy bufora. Najpierw pobierana jest nazwa komputera:

Następnie nazwa komputera jest sklejana ze stringiem zawierającym adres email ofiary:

Do wyjściowego bufora wstawiany jest string zawierający nazwę katalogu downloader’a, pobrany wcześniej z szyfrowanego bufora statycznych łańcuchów tekstowych, wkompilowanych w plik PE:

Podobnie wstawiane są nazwy kopii pliku binarnego downloader’a oraz nazwy usług systemowych:

Następnie z szyfrowanego pojemnika stringów pobierany jest łańcuch tekstowy „008”, podając jako argument wielkość bufora i identyfikator łańcucha w pojemniku (2D8F):

Zawartość tymczasowego bufora jest niszczona po użyciu, w celu uniknięcia wykrycia podczas analizy pamięci.

Na końcu procedury tworzona jest suma MD5 sklejonego wcześniej łańcucha, zawierającego nazwę komputera i adres email ofiary. Funkcja skrótu MD5 – podobnie jak inne funkcje kryptograficzne w kodzie konia trojańskiego – jest silnie zobfuskowana (zaciemniona). Poniższy fragment kodu przedstawia inicjalizację pętli głównej funkcji MD5 w kodzie malware (inicjalizację liczników A, B, C, D algorytmu MD5). Zielonym kolorem zaznaczono nadmiarowy kod – nie wpływający na logikę działania programu – umieszczony wyłącznie w celu utrudnienia analizy przez osobę przeprowadzającą inżynierię odwrotną kodu:

Generator nazw serwerów wydawania rozkazów

Analizowany malware nie posiada jednego stałego serwera wydawania rozkazów. Zastosowany został w nim mechanizm dynamicznego generowania nazw domenowych serwerów C&C (DGA: Domain Generation Algorithm), których wartość uzależniona jest od czasu. Generowane co pół godziny 85 zapytań http – będących próbą nawiązania komunikacji z serwerem C&C (i pobrania ew. rozkazów od operatora botnetu) – operuje na liście domen przesuniętej o 3 wiersze w stosunku do sekwencji domen, z którą komunikacja była nawiązywana przed 30 minutami.

Przykładowo, po uruchomieniu maszyny 17 sierpnia 2016 roku o godzinie 5:20, malware rozpocznie próbę nawiązania komunikacji ze swoim C&C, zaczynając od następującej sekwencji nazw domen:

Natomiast o godzinie 5:50 tego samego dnia, początek sekwencji będzie wyglądał następująco:

Generowane nazwy domen składają się ze sklejonych ze sobą dwóch słów anglojęzycznych, pobieranych z wkompilowanego w kod malware statycznego słownika zawierającego 384 pozycje.

Słownik generatora nazw jest zaszyfrowany. Jego deszyfracja następuje wyłącznie w trakcie próby połączenia z C&C, a po wygenerowaniu zestawu nazw jest on niszczony (zawartość bufora pamięci jest zerowana). Fragment bufora zawierającego deszyfrowany słownik przed zniszczeniem:

Nie próbowaliśmy analizować algorytmu, którego malware używa do generowania nazw. Zamiast tego zmodyfikowaliśmy kod konia trojańskiego tak, by po uruchomieniu malware sam wygenerował i zapisał do pliku kolejno wszystkie możliwe kombinacje nazw C&C.

W tym celu zmodyfikowaliśmy sekwencję kodu malware odpowiedzialną za rozwiązanie nazwy domeny (funkcja „gethostbyname”) serwera C&C:

Zerując wartość zwracaną przez funkcję gethostbyname (zwracaną w rejestrze EAX), powodujemy, że każde żądanie malware wysłane do serwera DNS o rozwiązanie nazwy (przed każdą kolejną próbą nawiązania połączenia z C&C) będzie wyglądało dla malware na niepowodzenie:

To spowoduje, że żadna z odpytanych domen nie zostanie zidentyfikowana przez malware jako C&C, a malware ponowi próby używając kolejnych z sekwencji 85 wygenerowanych nazw. Stosując „siłowe” zapętlenie pętli iterującej po kolejnych zapytaniach (usuwając warunek sprawdzający, ile domen już zostało odpytanych), utworzymy pętlę nieskończoną:

Po skonfigurowaniu debuggera tak, by logował do pliku argument przekazywany w wywołaniu funkcji gethostname (czyli nazwę domeny, którą malware chce rozwiązać) i ponownym uruchomieniu kodu konia trojańskiego, malware sam wygeneruje nam  do pliku pełną listę domen:

Otrzymujemy 32768 unikatowych domen z postfixem „.net”. Różnią się między sobą interwałem 8 minut i 53 sekund (po takim czasie koń trojański przesunie o jeden listę 85 żądanych co pół godziny domen). Jak łatwo policzyć, daje to operatorowi botnetu dokładnie 12 godzinne okno, w którym pierwszy element na liście 85 przesunie się na jej koniec. Jest to czas, w trakcie którego operator botnetu przy użyciu jednej zarejestrowanej domeny z listy, może wydać rozkaz wszystkim komputerom zainfekowanym badanym malware. Posiadając pełną, wygenerowaną listę nazw domen C&C (której pełna rotacja trwa dokładnie 198 dni), jesteśmy w stanie przewidzieć nazwy sekwencji domen z którymi danego dnia /o danej godzinie botnet będzie próbował nawiązać połączenie.  Daje nam to możliwość rejestracji domeny, przejęcia komunikacji z downloader’ami botnetu (utworzenia sinkhole’a), a nawet potencjalnie wydania rozkazu ich deaktywacji.

Pobranie i instalacja modułu głównego malware

Plik wykonywalny „emilfecko.exe” z załącznika ma jeden cel.  Jest nim ściągnięcie, zagnieżdżenie w systemie i uruchomienie głównego modułu malware, po nawiązaniu połączenia z C&C i otrzymaniu payload’u zawierającego plik PE modułu (nie każde udane połączenie z serwerem C&C kończy się otrzymaniem modułu).

Po otrzymaniu i zdeszyfrowaniu payload’u HTTP zawierającego wykonywalny plik PE poprzedzony identyfikatorem „mye” oraz łańcuchem tekstowym (1553920) zawierającym wielkość pliku PE:

sprawdzana jest wielkość payloadu (bez nagłówka HTTP). Jeśli jest większa niż 32768 (0x8000) bajtów:

plik PE z payloadu jest zapisywany na dysk do pliku tymczasowego (dla tej mutacji downloadera: C:\jikdfcd\okd5ctct.exe) i uruchamiany:

z przełącznikiem „UPDATESOX”  w linii komend:

Przełącznik „UPDATESOX” instruuje uruchomiony po raz pierwszy moduł główny, że ten ma jedynie zainstalować się w systemie (kopiując swoją kopię binarną do katalogu systemowego C:\windows\system32 i instalując usługę systemową) i zakończyć swoje działanie.

W tym czasie wątek downloader’a, który uruchomił moduł główny usypia się na 90 sekund, oczekując na zakończenie zagnieżdżania się w systemie modułu:

po czym usuwa utworzony wcześniej plik tymczasowy modułu:

Następnie uruchamiany jest moduł główny konia trojańskiego.

Składa się on z 3 kopii tego samego pliku PE (ściągniętego przez downloader) pełniących osobne funkcjonalnie role. Są nimi:
1. Usługa systemowa uruchamiana wraz ze startem maszyny i utrzymująca komunikację z C&C.
2. Watchdog monitorujący czy proces usługi jest aktywny i czy nie został zamknięty.
3. Backdoor oczekujący na połączenie TCP:

Proces watchdog’a uruchamiany jest podobnie jak w module dowloader’a. Przekazuje on  w linii komend parametr „WATCHDOG” i ścieżkę docelowego procesu usługi systemowej, którą watchdog ma monitorować:

Moduł główny stanowiący trzon logiki konia trojańskiego (odpowiedzialny za wykonywanie rozkazów napływających z C&C), uruchamiany jest jako usługa Windows wraz ze startem systemu. Plik usługi instaluje się w katalogu:

c:\windows\system32

W przypadku tej mutacji malware plik usługi instalowany jest pod nazwą:

akaolnasolh.exe

a sama usługa systemowa instaluje się pod nazwą:

Installer Controls Panel User Parental

używając podobnego jak w przypadku download’era schematu, losowej, łatwej do rozpoznania i nic nie znaczącej sekwencji słów.

Trzeci element stanowi proces typu backdoor, nasłuchujący na wysokim porcie o statycznym numerze wkompilowanym w plik PE. Plik backdoor’a instaluje się w katalogu:

C:\WINDOWS\TEMP

pod nazwą:

igqbupifx0y3gsdl.exe

Natomiast sam proces backdoor’a uruchamiany jest z argumentem„TESTPORT29861” zawierającym numer portu, na którym proces ma rozpocząć nasłuch TCP.

Pierwszy rozkaz z serwera C&C: poszukiwania niemieckich placówek edukacyjnych

Jednym z pierwszych  rozkazów otrzymanych z serwera C&C przez moduł główny, było pobranie i uruchomienie bezokienkowego interpretera JavaScript – PhantomJS:

a następnie pobranie i uruchomienie w silniku PhantomJS skryptu mającego na celu masowe odpytywanie niemieckiej strony z wyszukiwarką firm (gelbeseite.de):

Kod „gelbeseite.js” po uruchomieniu rozpoczął odpytywanie HTTP domeny gelbeseite.de (niemiecka odmiana „panoramy firm”) w poszukiwaniu niemieckich instytucji o charakterze edukacyjnym:

Można wnioskować, że celem atakującego mogła być dalsza propagacja malware w niemieckich szkołach i instytucjach szkoleniowych, bądź agregacja adresów email wykorzystywanych później w kampaniach spamowych.

Uformowanie botnetu

20 stycznia 2016 na skrzynki pocztowe Exatel trafiły kolejno 2 wiadomości zawierające mutacje malware Bayrob:

Oba download’ery w załącznikach posiadały te same słowniki, służące do generowania nazw domen C&C i nawiązywały próbę łączenia się z tą samą sekwencją C&C co downloader „emilfecko.exe” z listopada.

Pod koniec lutego, operator botnetu zaprzestał rejestracji dynamicznych domen C&C służących do komunikacji z download’erami . Żadna z 90 domen, z którymi download’ery starały się nawiązać co 30 minut połączenie http, nie identyfikowała się ze znanym im protokołem C&C.  Mogło to oznaczać koniec fazy formowania nowego botnetu przez jego operatora.

Postanowiliśmy dokonać dokładnej analizy modułu głównego malware w celu przybliżenia metodologii działania i zamiarów operatora botnetu, a także podjąć próbę identyfikacji potencjalnej listy ofiar.

Analiza modułu głównego malware

W przeciągu jednego miesiąca działania botnetu, różne downloader’y otrzymały rozkaz instalacji 5 kolejnych wersji modułu głównego malware:

Wszystkie analizowane wersje modułu głównego posiadały wkompilowaną, statyczną listę serwerów C&C. Najnowsza otrzymana wersja modułu (aagunyg.exe) posiadała siedem serwerów C&C:

W danym momencie, przeważnie dwa z serwerów były aktywne (odpowiadały na porcie 80).

Komunikacja z serwerem C&C przebiegała następująco: najpierw podejmowana była próba nawiązania komunikacji kolejno z adresami serwerów z listy statycznej. Jeśli żaden z serwerów nie odpowiedział poprawnie na komunikat powitalny konia trojańskiego zaszyfrowany w payloadzie HTTP (POST), rozpoczynana była próba nawiązania komunikacji z 85 serwerami z listy generowanej dynamicznie.

Lista serwerów generowanych dynamicznie różniła się w stosunku do listy downloader’ów i była budowana z użyciem innego słownika.

Taka budowa umożliwiała operatorowi botnetu aktywację statycznej domeny w razie przejęcia / wyłączenia przez dostawcę którejś z pozostałych domen, a w razie wyłączenia wszystkich statycznych – użycie domen dynamicznych.

Analiza run-time wyjścia procedury deszyfracji string’ów

Z uwagi na mocną obfuskację kodu malware (zarówno downloader’a jak i modułu głównego) w celu analizy logiki wykonania modułu głównego malware, wykorzystaliśmy element budowy malware, który został wbudowany przez jego autora, w celu utrudnienia analitykom przeprowadzenia inżynierii odwrotnej i zrozumienia działania malware.

Podłączyliśmy nasłuch procedury używanej do selektywnej deszyfracji pojemnika string’ów, umieszczając debuggerem logowanie wyjścia (zwracanych wartości) procedury deszyfracji. Korzystaliśmy tutaj z faktu, że łańcuchy tekstowe są zaszyfrowane, deszyfrowane na żądanie i niszczone w pamięci zaraz po użyciu.

Przykładowe wywołanie procedury deszyfrującej w kodzie modułu głównego malware wygląda następująco:

W tym konkretnym przypadku pobierany jest łańcuch ”mode=sox&v=”, używany w procedurze budowy payload’u HTTP POST, zawierającego dane identyfikujące maszynę ofiary przesyłane do C&C.

Po uruchomieniu modułu głównego malware (w miarę wykonywania kolejnych czynności) koń trojański pobierze i zniszczy kolejne łańcuchy tekstowe My  z kolei zarejestrujemy to w takiej kolejności, w jakiej nastąpiło wykonanie. Analizując treść i kolejność łańcuchów tekstowych, możemy sprofilować wykonane przez malware czynności:

W ten sposób, udało nam się zdobyć między innymi listę wszystkich dostępnych parametrów konfiguracyjnych / komend, jakie serwer C&C może wydać malware. Na poniższej liście przedstawiono wszystkie dostępne parametry konfiguracyjne / komendy, z wyróżnieniem na czerwono tych, które w trakcie całego czasu analizy malware zostały zarejestrowane w komunikacji z serwerami C&C:

Szczególnie interesująca wydaje się być komenda really_do_suicide, mogąca stanowić wbudowany przez autora w moduł główny mechanizm deaktywacji malware.

Inżynieria odwrotna algorytmu szyfrującego komunikację C&C

Dokonaliśmy analizy procedury szyfrującej payload HTTP w komunikacji z serwerami C&C. Odtworzyliśmy symetryczny algorytm szyfrujący, implementując go w Python. Algorytm używa czterobajtowego klucza, będącego łańcuchem tekstowym (ASCII) i składającym się z dużych liter wbudowanego bezpośrednio w kod maszynowy pętli szyfrującej:

Downloader’y i analizowane moduły główne używają tego samego algorytmu szyfrującego. Różnią się natomiast kluczami, którymi dla downloader’ów jest łańcuch „MAPS” (SPAM czytając od tyłu), natomiast dla modułu głównego –  „PELD” (bądź „DLEP”).

Poniżej algorytm szyfrujący w postaci schematycznej, używający klucza downloader’a:

W tym momencie jesteśmy w stanie szyfrować i deszyfrować komunikację konia trojańskiego z serwerami C&C. Co 30 minut moduł główny malware wysyła komunikat powitalny (GET), po czym wysyła w pakiecie POST dane identyfikujące przejętą maszynę. Treść wysłanego komunikatu przed zaszyfrowaniem i spakowaniem Base64 z zaznaczonym na czerwono identyfikatorem mutacji / instancji malware (numerem unikalnym dla danej ofiary) :

Odpowiedź serwera C&C po zdeszyfrowaniu:

Komunikat serwera zawiera:

• nową listę 6 statycznych serwerów C&C,
• nazwę serwera (fourcrazyworkroad.com ) i katalog (/dep/), z którego malware ma pobierać narzędzia nie będące integralną częścią malware (silnik PhantomJS, unzip, narzedzia do liczenia bitcoin’ów),
• zapamiętane na serwerze C&C informacje o procesorze ofiary,
• moduł rozkazu dynamicznego („plugin”) w postaci kodu wykonywalnego (pliku PE) doklejonego na końcu komunikatu (w tym przypadku jest to rozkaz „browser_passwords” mający za zadanie agregację i przesłanie na C&C haseł zapamiętanych w przeglądarce ofiary),
• liczbę sekund (parametr timer) po której należy uruchomić kod rozkazu dynamicznego PE.

Rozmowa z botnetem: piszemy kod zombie-repeater

Znając algorytm szyfrujący malware, posiadając implementację symetrycznej funkcji szyfrującej i rozumiejąc protokół komunikacji botnetu, jesteśmy w stanie własnoręcznie nawiązać komunikację z serwerami C&C i podszyć się pod malware o dowolnym identyfikatorze ofiary.

Stworzyliśmy skrypt „zombie-repeater” nawiązujący komunikację z C&C i udający moduł główny malware. Jego zadaniem było sekwencyjne zgłaszanie się do C&C, identyfikując się kolejnymi, następującymi po sobie wartościami identyfikatora SOX, umożliwiając w ten sposób podszycie się pod różne ofiary. Ponieważ, jak wcześniej zauważyliśmy, po nawiązaniu komunikacji z C&C serwer w pakiecie zwrotnym przekazuje zapamiętany (od ostatniego zgłoszenia maszyny zombie) łańcuch tekstowy z opisem procesora ofiary:

oraz biorąc pod uwagę fakt, że jeśli przy pomocy malware identyfikującego się danym SOX nie została zainfekowana jeszcze żadna ofiara, to serwer C&C zgłasza rozkaz podania nazwy komputera i typu procesora:

Możemy w ten sposób identyfikować w rozmowie z C&C te identyfikatory SOX, za którymi stoją zainfekowane maszyny będące już częścią botnetu.

Zauważono, że identyfikatory SOX nie są inkrementowane co 1 podczas budowy modułów głównych. Zamiast tego są one grupowane na początku „slotów” rozmieszczonych co 512 (0x200), zwykle z wartościami w przedziale od 1 do 20. Tak więc zamiast skanować całą 32-bitową przestrzeń, wystarczy odpytywać jedynie początkowe 20-30 numerów SOX, dla kolejnych slotów (wielokrotności 0x200):

Zauważyliśmy, że operator botnetu w miarę budowy i uruchamiania zombie-repeater’a zaczął „uczyć” botnet jak rozpoznawać fałszywe „końcówki”. Po ok. 2-3 dniach pracy zombie-repeater’a, operator zaczął blacklist’ować IP, z którego przychodziło połączenie, po ok. 5-10 minutach ciągłego odpytywania różnymi numerami SOX (prawdopodobnie korzystając z faktu, iż prawdziwy malware jest zaprogramowany by zgłaszać się dokładnie co 30 minut).

Po umieszczeniu IP na blackliście, serwer C&C niezależnie od podawanego później identyfikatora SOX odpowiada krótkim komunikatem zwrotnym:

W odpowiedzi zintegrowaliśmy kod zombie-repeater’a z siecią Tor, przepuszczając przez niego cały symulowany ruch malware i instruując kod repetera tak,  by po każdym rozpoznanym zblacklistowaniu resetował połączenie otrzymując w rezultacie nowe IP exit-node’a Tor. Nie wiemy, czy w odpowiedzi na to, czy z niezależnych przyczyn, po kilku dniach autorzy botnetu zmodyfikowali protokół.  Zmienili oni algorytm kodowania wiadomości i rozpoczęli proces wymiany modułów głównych botnetu na wersję z nowym protokołem. Ponieważ wprowadzona modyfikacja polegała jedynie na kompresji do GZIP zwracanego przez serwer C&C zaszyfrowanego bufora payloadu – co w przypadku bardzo dużej entropii, jaką posiadają dane zaszyfrowane nie umożliwiało kompresji i sprowadzało się praktycznie wyłącznie do dodania nagłówka formatu GZIP (0x1f8b)- można przypuszczać, iż decyzja o modyfikacji protokołu mogła nie być do końca przemyślana. Być może została podjęta w pośpiechu lub jej celem było jedynie utrudnienie komunikacji z „fałszywym” malware.

Po wprowadzeniu do zombie-repeater’a detekcji typu protokołu (detekcji nagłówka GZIP zaraz przed deszyfracją otrzymanego z C&C payload’u), byliśmy w stanie identyfikować oba protokoły komunikacji oraz dodatkowo obserwować sukcesywny proces wymiany modułów głównych poszczególnych ofiar (rozpoznając fakt wymiany po typie protokołu jakim serwer C&C odpowie na powitanie).

Kod zombie-repeater’a działał przez następne 2 tygodnie identyfikując aktywne identyfikatory ofiar, ich typy CPU i agregując wszystkie rozkazy dynamiczne (pliki PE), jakie operator wydawał w zależności od numeru SOX ofiary. Wydawanie rozkazów z użyciem plików PE dołączanych do payload’u, umożliwiało operatorowi elastyczne i szybkie tworzenie nowych dowolnie skomplikowanych rozkazów. Dało także możliwość ich przesłania i wykonania na komputerze wybranej ofiary, bez konieczności masowej wymiany modułów głównych całego botnetu.

W trakcie 2 tygodni rekonesansu, zombie-repeater zebrał 13 różnych typów plików PE z rozkazami dynamicznymi:

Rozkazy te umożliwiają operatorowi botnetu m.in.:

• eksfiltrację zawartych w Outlook’u danych dostępowych do kont pocztowych ofiary,
• eksfiltrację haseł zapamiętanych w przeglądarkach internetowych,
• eksfiltrację książek adresowych Outlook,
• użycie komputera ofiary do liczenia bitcoin’ów,
• deaktywację Windows Defendera,
• zautomatyzowane odpytywanie stron pornograficznych w tle (z użyciem PhantomJS) symulujące klikanie umieszczonych tam reklam,
• eksfiltrację haseł dostępowych do zapamiętanych na komputerze ofiary sieci wifi,
• detekcję możliwości rozsyłu spamu z komputera ofiary,
• eksfiltrację zawartości składowanych na dysku portfeli bitcoin.

Poniższa tabela przedstawia zestawienie typów procesorów ofiar, zebranych na bazie 443 identyfikatorów SOX, na które serwer C&C odpowiedział pozytywnie, podając łańcuchy tekstowe przekazane przez maszyny ofiar podczas infekcji:

Ostatni z procesorów w tabeli (QEMU Virtual CPU), to najprawdopodobniej maszyna sandbox’owa, wykorzystywana przez innego analityka pracującego nad analizą badanego przez nas malware.

Cel i pochodzenie operatora botnetu

Wśród rozkazów zebranych w czasie 2 tygodni rekonesansu dwoma najczęściej otrzymywanymi były:

1. komenda „miner_forced” uruchamiająca na komputerze ofiary ukryty proces zajmujący się mining’iem (liczeniem) bitcoin’ów, utrzymujący połączenie TCP z jednym z serwerów C&C na portach 8080 i 9999:

2. komenda „ads_xhorny.casper”, której celem jest symulowanie kliknięć reklam umieszczonych na stronach pornograficznych:

W celu poszukiwania informacji o pochodzeniu ofiar wykorzystaliśmy często pojawiający się rozkaz „cli_lease”:

Rozkaz zawiera listę IP i portów zainfekowanych maszyn (oczekujących na połączenie procesów ‘backdoor’) wraz z identyfikatorami SOX ich modułów głównych. Po otrzymaniu rozkazu, moduł główny który go odebrał, próbuje nawiązać krótkie, kilkubajtowe połączenie TCP na podanym porcie kolejno z każdą z maszyn z listy. Możliwym przeznaczeniem rozkazu może być decentralizacja komunikacji i umożliwienie połączeń P2P między ofiarami. Po zestawieniu wszystkich zebranych w trakcie rekonesansu adresów IP i ich numerów SOX zawartych w pakietach cli_lease, stworzono statystykę ofiar:

W tym miejscu, nasuwa się na myśl pewne spostrzeżenie. Opublikowany w 2013 raport Jasona Geffnera dotyczący analizy możliwości i celów ówczesnej wersji malware Bayrob, pokazuje podobnie wysoką (drugą) pozycję Rumunii w statystykach ofiar botnetu, zaraz po USA (odwrotnie niż w wynikach naszej analizy) i to pomimo zastosowania przez Gaffnera odmiennej od naszej metody analizy statystyk ofiar (sinkholing komunikacji C&C modułów downloader’a).

Zidentyfikowane przez Gaffnera w kodzie ówczesnej wersji downloader’a łańcuchy tekstowe, zawierające imiona rumuńskich artystów muzycznych oraz przekleństwa w języku rumuńskim, wskazują, iż autor malware może pochodzić z tego kraju. Biorąc pod uwagę fakt,  że głównym celem operatora botnetu wydają się być korzyści finansowe (o czym świadczy choćby agregacja informacji o typach procesorów maszyn ofiar w celu wykorzystania mocy obliczeniowej do mining’u bitcoin’ów i implementacja komend do kradzieży portfeli bitcoin’owych), wysoki poziom infekcji maszyn z rumuńskiej przestrzeni IP może wynikać nie tyle z faktu obrania za główny cel ataku akurat tego kraju, ale po prostu większej skuteczności kampanii rozbudowy botnetu. Efektywność pierwszej fazy wektora ataku stosowanego przez operatorów Bayrob (kampania spamowa propagująca pocztę zawierającą moduły downloader), w dużej mierze zależy od efektywnego wykorzystania inżynierii społecznej, a co za tym idzie dobrej znajomości lokalnego społeczeństwa, języka czy nawet nastrojów społecznych. Duża skuteczność w infekcji maszyn tego kraju, może również sugerować rumuńskie korzenie (bądź powiązania) autora.

Pod koniec kwietnia rozpoczęła się nowa (kolejna od ostatniego listopada) faza rozbudowy botnetu, co obrazuje poniższy wykres z systemu Virusradar:

Statystyki aktywności botnetu wskazują na zwiększony w tym czasie współczynnik infekcji maszyn będący efektem prawdopodobnie uruchomienia nowej kampanii. Szczyt współczynnika nowych infekcji malware Bayrob osiągnął 9 maja 2016 r.

——-

Centrum Operacyjne Bezpieczeństwa Cybernetycznego (SOC), Exatel

Security Operations Center (SOC) to nowoczesna, wyspecjalizowana komórka Exatel, skupiająca ekspertów z szerokimi kompetencjami w dziedzinie bezpieczeństwa teleinformatycznego. Zespół zajmuje się identyfikacją, prewencją i ochroną klientów przed cyberzagrożeniami, które mogą uniemożliwić prawidłowe funkcjonowanie organizacji. Skuteczność SOC Exatel wynika z bliskiej współpracy ekspertów z klientami oraz całodobowym wsparciu oferowanym przez 365 dni w roku.

Od redakcji z3s: Za publikacje powyższego artykułu nie wzięliśmy ani złotówki bo to dobra analiza była.