Stan zagrożeń w internecie znajduje się obecnie na poziomie standardowym. Nie występują duże epidemie a eksperci z Kaspersky Lab nie zanotowali żadnych poważnych incydentów związanych z bezpieczeństwem. Poziom zagrożenia: 1

Złodziej informacji Madi - szczegółowa analiza

Tagi:

Nicolas Brulez
Ekspert z Kaspersky Lab

Dnia 17 lipca 2012 r. opublikowaliśmy informacje na temat wykrycia szkodliwego oprogramowania Madi i trwającej kampanii infiltracji systemów komputerowych na całym Bliskim Wschodzie, szczególnie skoncentrowanej na podmiotach w Iranie, Izraelu, Afganistanie i innych rozrzuconych po całym świecie. Poniżej przedstawiamy szczegółową analizę modułu kradnącego informacje, używanego w tej kampanii.


INSTALACJA

Moduł wykradający informacje jest instalowany przez jeden z wielu downloaderów wykorzystywanych w kampanii Madi. Downloadery mogą zostać podzielone na dwie kategorie:

  • Downloadery używające do uśpienia czujności użytkownika sztuczek socjotechnicznych (wyświetlające obrazy, filmy, dokumenty itd.).
  • Downloadery, które jedynie pobierają i instalują moduł wykradający informacje.

Oba typy downloaderów kopiują się jako pliki „UpdateOffice.exe” do folderu „Printhood”, np. „C:\Documents and Settings\%USER%\Printhood\UpdateOffice.exe”, gdzie są uruchamiane.

Zarówno moduł wykradający informacje, jak i downloadery, tworzą w odpowiednich folderach fałszywe pliki o losowych nazwach. Downloadery ładują również pliki, które są użyteczne dla samego szkodnika (szczegóły można znaleźć w naszej poprzedniej analizie).

Tylko jeden plik będzie używany przez moduł wykradający informacje: nam.dll. Plik ten jest tworzony przez downloader w katalogu „Templates” (np. „C:\Documents and Settings\%USER%\Templates\nam.dll”) i zawiera wstępnie skonfigurowanego bota, który będzie wykorzystywany przez moduł kradnący dane podczas łączenia się z serwerem centrum kontroli (C&C). Aby pobrać i zainstalować moduł wykradający informacje, downloadery łączą się z serwerem C&C i zgłaszają żądanie dostępu do strony HTM.

Starsze warianty downloaderów używają adresu: „http://[adres_serwera_C&C]/ASLK/khaki/Abi/UUUU.htm”, natomiast nowsze egzemplarze korzystają z adresu: „http://[adres_serwera_C&C]/ASLK/asgari/mah/UeUeUeUe.htm”.

Strona HTM jest kopią indeksu Google z wbudowanym plikiem wykonywalnym zakodowanym podwójnie w Base64:

Słowo kluczowe „tamamshodfile”, występujące na spodzie strony, zostanie wyjaśnione w dalszej części analizy.

Downloadery parsują plik HTM, dwukrotnie dekodują ładunek Base64, a wynikowy plik PE zapisują w katalogu „Templates” jako „iexplore.exe”. Po pobraniu, uruchamiana jest funkcja kradzieży informacji.


ANALIZA MODUŁU WYKRADAJĄCEGO DANE: IEXPLORE.EXE

Każda wersja modułu wykradającego informacje posiada ikonę przeglądarki Internet Explorer i jest napisana w Delphi.

Wersja użyta w niniejszej analizie najprawdopodobniej została skompilowana 10 czerwca 2012 r. i spakowana z wykorzystaniem UPX 3.08.

Rozmiar pliku jest raczej duży: w wersji spakowanej 415 KB, a po rozpakowaniu 1,14 MB.

Specyfiką modułu wykradającego informacje wykorzystywanego w kampanii Madi jest nadużywanie timerów Delphi. W sumie jest ich aż 52, co można zaobserwować na poniższej ilustracji:

.

Podczas analizy modułu wykradającego informacje wykryliśmy całą masę błędów, jednakże nie będziemy o nich dyskutować w niniejszym artykule, ponieważ nie chcemy zdradzać autorom szkodnika informacji, w jaki sposób mogliby poprawić swoje „dzieło”.


TFORM4.FORMCREATE

Po uruchomieniu, pierwsza czynność wykonywana przez moduł kradzieży informacji ma miejsce wewnątrz TForm4.FormCreate.

Działania rozpoczynają się konfigurowaniem keyloggera. W tym celu Madi używa funkcji Windows „SetWindowsHookEx” z przechwytem parametru „WH_KEYBOARD_LL”.

Po zainstalowaniu keyloggera, moduł kradzieży informacji odczytuje plik „nam.dll” (który jest podrzucany przez downloader) w celu pobrania prefiksu BOT i połączenia go z nazwą komputera. W dalszej części tekstu będziemy ten prefiks oznaczać "BOTID_TMP". Jak zobaczymy później, wynikowy identyfikator BOTID zawiera kilka numerów pochodzących z numeru seryjnego woluminu „C:\”.

Następnie, poniższe timery są wyłączane w następującej kolejności:

Timer 1, Timer 16, Timer 18, Timer 17, Timer 20, Timer 19, Timer 24, Timer 8, Timer 30, Timer 31, Timer 33, Timer 34, Timer 36, Timer 37, Timer 38, Timer 39, Timer 40, Timer 41, Timer 44, Timer 45, Timer 46, Timer 48, Timer 49, Timer 50.

Szkodnik wykorzystuje wiele plików zewnętrznych do otrzymywania poleceń, co jest kolejnym wskaźnikiem słabej znajomości tajników programowania przez autorów Madi. Pliki te są wykorzystywane do informowania złośliwego oprogramowania o stanie infekcji. W celu uniknięcia nieporozumień w tym artykule, kiedy odnosimy się do pliku, oznacza to, że znajduje się on w folderze szkodnika (katalog „Templates”), chyba że zaznaczono inaczej.

Moduł wykradający informacje poszukuje poniższych plików:

„fsdiskget.dll”: jeżeli plik zostanie odnaleziony, uruchamiany jest Timer 23 – w przeciwnym przypadku jest wyłączany.

„nrbindek.dll”: jeżeli plik zostanie odnaleziony, uruchamiany jest Timer 28 – w przeciwnym przypadku jest wyłączany.

„specialfile.dll”: jeżeli plik zostanie odnaleziony, jest usuwany.

„filesend.xls”: ten plik zostaje usunięty.

„begirnagir.htp”: jeżeli plik NIE zostanie odnaleziony, wyłączny jest Timer 3.

„filebind.xls”: jeżeli plik zostanie odnaleziony uruchamiany jest Timer 29 – w przeciwnym razie jest wyłączany.

W kolejnym kroku wyłączany jest Timer 14 i Timer 13.

Trojan poszukuje biblioteki „First.dll”, która tworzona jest podczas pierwszego uruchomienia szkodnika.

Gdy biblioteka zostanie znaleziona, kod zwraca TForm4.FormCreate. W przeciwnym razie wykonywane są działania opisane poniżej.

Tworzona jest biblioteka first.dll z zakodowanym strumieniem bajtów (nie jest to prawdziwa biblioteka .dll, jak zobaczymy później, gdy dokonamy szczegółowej analizy timerów).

Podobnie jak downloadery, również moduł kradzieży informacji generuje fałszywe pliki o losowych nazwach. Przed zwróceniem TForm4.FormCreate wykonywanych jest 6 pętli:

XLS: 51 fałszywych plików XLS o losowych nazwach (7 znaków) - tworzonych z wykorzystaniem zakodowanego strumienia bajtów.

EXE: 51 fałszywych plików EXE o losowych nazwach (6 znaków) - tworzonych z wykorzystaniem zakodowanego strumienia bajtów.

DLL: 201 fałszywych plików DLL o losowych nazwach (9 znaków) - tworzonych z wykorzystaniem zakodowanego strumienia bajtów.

TXT: 51 fałszywych plików TXT o losowych nazwach (4 znaków) - tworzonych z wykorzystaniem zakodowanego strumienia bajtów.

XML: 51 fałszywych plików XML o losowych nazwach (8 znaków) - tworzonych z wykorzystaniem zakodowanego strumienia bajtów.

HTM: 51 fałszywych plików HTM o losowych nazwach (8 znaków) - tworzonych z wykorzystaniem zakodowanego strumienia bajtów.


ANALIZA KEYLOGGERA

Jak wspomnieliśmy wcześniej, konfiguracja keyloggera wykonywana jest w TForm4.FormCreate. Do przychwytywania znaków wprowadzanych z klawiatury keylogger wykorzystuje funkcję „SetWindowsHookEx” z identyfikatorem „WH_KEYBOARD_LL”.

Sam przechwyt jest raczej prymitywny. Dla przykładu, aby dowiedzieć się, czy ofiara użyła klawisza "Backspace", keylogger wykorzystuje GetAsyncKeyState z identyfikatorem ”VK_BACK”.

Każdy wciśnięty klawisz jest rejestrowany w buforze keyloggera „poki65_pik_log”:

Nie jest więc niespodzianką, że keylogger jest bardzo prosty i do jego konstrukcji nie zastosowano jakiejkolwiek zaawansowanej technologii.

Szkodnik Madi używa 52 timerów. Aby uczynić ich analizę bardziej przejrzystą, pogrupowaliśmy je ze względu na działania, jakie wykonują.

 

CENTRUM KONTROLI: PROTOKÓŁ

Omówimy teraz wszystkie timery odpowiedzialne za kontakt z serwerem C&C i otrzymywanie poleceń do wykonania na zainfekowanej maszynie, oraz wszystkie różne przechwyty używane do wykonywania działań zgodnie z otrzymywanymi poleceniami.

Uwaga: w wielu procedurach Madi tworzy pliki „.bat”, aby pingować serwer C&C w celu sprawdzenia, czy jest on aktywny czy nie, a wynik zapisuje w specjalnym pliku. Każdy plik ma inną nazwę. Jeśli będziemy odwoływać się do tych plików, podamy numer timera odpowiedzialnego za jego powstanie.

Menedżer serwera wygląda następująco:

Graficzny interfejs użytkownika powstawał prawdopodobnie w pośpiechu, ale spełnia swoje zadanie. Może być wykorzystywany do tworzenia konkretnych zadań dla poszczególnych ofiar. Timer 12 pokazuje, w jaki sposób każde polecenie jest obsługiwane przez moduł kradzieży informacji.

 

Timer 1: Meldowanie

Interwał: 25 sekund

Przed rozpoczęciem odbierania poleceń, moduł kradzieży informacji łączy się z centrum kontroli przy pomocy specjalnej strony. Nazwaliśmy ten etap procedurą "meldowania". Oto opis:

Timer 1 pobiera "Nazwę aplikacji" i łączy ją z rozszerzeniem ".pkklm" (w opisie Timera 15 przedstawione są szczegóły tworzenia tego pliku). Stara się otworzyć ten plik, poszukując ciągu znaków definiującego "Odpowiedź od" (kiedy adres IP odpowie na ping). Kiedy ciąg nie zostanie znaleziony, Timer 1 jest wyłączany i następuje powrót.

Jeżeli ciąg zostanie znaleziony, generowana jest ostatnia część identyfikatora BOTID przy pomocy numeru seryjnego woluminu „C:\”.

Zasadniczo, funkcja API GetVolumeInformationW jest wywoływana w celu pobrania numeru seryjnego woluminu, który następnie jest łączony z identyfikatorem BOTID_TMP wygenerowanym w TForm4.FormCreate. Następnie generowany jest finalny identyfikator BOTID, a ostateczny adres URL, który zostanie odwiedzony, tworzony jest w następujący sposób:

BOTID|NAZWAKOMPUTERA|NumerSeryjnyWoluminu/dastor/file.htm
np. "abaanu5|MYCOMPUTER-8712422C|6D8704FE/dastor/file.htm"

Finalny adres URL jest odwiedzany z wykorzystaniem instrumentarium Internet Explorer (IE).
(np. "http://C&C/abaanu5MYCOMPUTER-8712422C6C7704EF/dastor/file.htm")

Po odwiedzeniu wspomnianego adresu włączany jest Timer 18, Timer 1 jest wyłączany i następuje powrót.

Proces meldowania zawiadamia napastników kiedy komputer ofiary jest gotowy na otrzymywanie poleceń.

Gdy napastnicy postanowią wysłać polecenia do zainfekowanego komputera, w folderze „/dastor/” pojawi się plik „das.htm”.

 

Timer 16: Przejście na stronę z poleceniami

Interwał: 25 sekund

Timer 16 pobiera "Nazwę aplikacji" i łączy ją z rozszerzeniem ".pkxm" (wyniki pingowania z Timera 11). Stara się otworzyć ten plik, poszukując ciągu znaków definiującego "Odpowiedź od" (kiedy adres IP odpowie na ping).

Kiedy ciąg nie zostanie znaleziony, Timer 16 jest wyłączany i następuje powrót.

Końcowy identyfikator BOTID jest obliczany (zobacz opis Timera 1), aby utworzyć adres URL, który jest odwiedzany w celu pobrania poleceń do wykonania. Przed otwarciem tego adresu URL plik „dast.xls” jest usuwany (zobacz opis Timera 17 poniżej).

Adres URL jest odwiedzany z wykorzystaniem instrumentarium IE. Timer 17 jest włączany, a Timer 16 jest wyłączany.

 

Timer 17: Zapisanie strony z poleceniami w pliku „dast.xls”

Interwał: 20 sekund

Uwaga: Podczas pracy modułu kradzieży informacji Madi, uruchamianych jest wiele instancji IE.

Timer 17 przechodzi przez wszystkie instancje IE, poszukując stron, które w tytule posiadają frazę „dastor”. Kiedy taka strona zostanie napotkana, zawartość strony (bez tytułu) jest zapisywana jako „dast.xls”.

Jeżeli strona nie zostanie znaleziona, sprawdzana jest kolejna instancja IE. Proces sprawdzania kontynuowany jest do momentu, gdy nie pozostaną żadne instancje. Jeśli nic nie zostanie znalezione, uruchamiana jest procedura czyszczenia.

Na samym końcu swego działania, Timer 17 poszukuje nagłówka " - dastor - Windows Internet Explorer" i innych wariantów z nazwą (Internet Explorer), a następnie używając funkcji "PostMessageW" wysyła polecenie "WM_Close" w celu zamknięcia strony. Wśród wszystkich nagłówków wyszukiwane są również te z błędem 404 (np. " - 404 - Błąd wczytywania strony").

Po zakończeniu czyszczenia, Timer 17 wyłącza się i następuje powrót. Na tym etapie mamy lokalny plik zawierający polecenia, które mają zostać wykonane na zainfekowanym komputerze.

 

Timer 12: Przydzielanie rozkazów

Ten timer jest odpowiedzialny za parsowanie pliku z rozkazami. W celu uczynienia opisu trochę łatwiejszym do zrozumienia, zamieszczamy przykładowy plik z rozkazami (poleceniami do wykonania):

Kiedy akcja zakończy się, Timer 12 jest wyłączany.

Trojan kradzieży informacji następnie sprawdza, czy obecny jest plik „dast.xls” (utworzony przez Timer 17, zobacz opis powyżej).

Jeżeli plik nie rezyduje, Timer 12 jest ponownie włączany i następuje powrót.

Na kolejnym etapie procesu otwierany jest plik „dast.xls”, który wyszukuje polecenia do wykonania (zobacz plik z rozkazami powyżej). Wiele poleceń można przesyłać jednocześnie, co oznacza, że Timer 12 nie zaprzestanie parsowania, kiedy odnalezione zostanie jedno polecenie. Oto pełna logika parsowania:

PIK:
Jeśli plik polecenia zawiera słowo „pik”, sprawdzany jest stan działania Timera 3 (Timer 3 jest procedurą zbierania zrzutów ekranu poczty elektronicznej, sieci społecznościowych i komunikatorów internetowych). Jeżeli jest wyłączony, Timer 3 jest włączany i rozpoczyna się monitorowanie ekranu. Parsowanie poleceń jest kontynuowane. Jeżeli polecenie „pik” nie zostanie znalezione, Timer 3 jest wyłączany.

DESK:
Jeśli plik polecenia zawiera słowo „desk”, sprawdzany jest stan działania Timera 13 (Timer 13 jest procedurą zbierania zrzutów ekranu). Jeżeli jest wyłączony, Timer 13 jest włączany i rozpoczyna się monitorowanie ekranu. Parsowanie poleceń jest kontynuowane. Jeżeli polecenie „desk” nie zostanie znalezione, Timer 13 jest wyłączany.

SOUND:
Jeśli plik polecenia zawiera słowo „sound”, sprawdzany jest stan działania Timera 14 (Timer 14 jest procedurą nagrywania dźwięku). Jeżeli jest wyłączony, Timer 14 jest włączany i rozpoczyna się rejestrowanie dźwięku. Parsowanie poleceń jest kontynuowane. Jeżeli polecenie „sound” nie zostanie znalezione, Timer 14 jest wyłączany.

Jeśli plik polecenia zawiera słowo „newfi”, nic się nie dzieje. Jest to prawdopodobnie pozostałość po starszym kodzie.

UPDATE:
Jeśli plik polecenia zawiera słowo „update”, sprawdzane jest również, czy zawiera numer wersji. Musi on być różny od obecnej wersji („1.1.6” w analizowanej próbce). Jeśli żaden z tych dwóch warunków nie jest spełniony, parsowane jest kolejne polecenie. Procedura sprawdzania jest bardzo uproszczona i zakłada, że numer wersji będzie wyższy, a nie niższy. Możliwe jest zatem załadowanie starszej wersji trojana.

Jeżeli wymagane kryteria aktualizacji są spełnione, tworzony jest plik "Update.dll" (plik Update.dll jest tworzony z zakodowanego strumienia bajtów i nie jest prawidłową biblioteką DLL).

Trojan następnie lokalizuje folder „STARTUP”, gdzie rezyduje kopia pliku "UpdateOffice.exe" (downloader Madi) i uruchamia ją przy pomocy funkcji ShellExecute (w pierwszej części artykułu wyjaśniliśmy, w jaki sposób downloader pobiera i instaluje moduł kradzieży informacji).

Downloader trojana jest konieczny, aby wykonać proces aktualizacji. Jeśli z jakiegoś powodu downloader został usunięty, aktualizacja nie będzie możliwa.

Po wykonaniu opisanego zadania, Timer 12 kończy swoje działanie, ponieważ plik wykonywalny modułu kradzieży informacji (iexplore.exe) za chwilę zostanie nadpisany nowszą wersją przez downloader i cała procedura uruchamiania rozpocznie się od nowa.

DELETE:
Jeśli plik polecenia zawiera słowo „delete”, utworzony zostanie plik "delete.dll", z wykorzystaniem dokładnie tego samego strumienia bajtów, który był używany w pliku "update.dll".

Następnie trojan lokalizuje i usuwa folder „STARTUP”, gdzie zlokalizowany jest downloader "UpdateOffice.exe". Po usunięciu foldera cały proces jest przerywany.

W tym momencie, po kolejnym uruchomieniu komputera infekcja nie jest wznawiana.

Uwaga: Moduł kradzieży informacji nie wznawia samoczynnie swojego działania, ale jego automatyczna aktualizacja może postępować przy każdym kolejnym ponownym uruchomieniu komputera.

Z drugiej strony, wszystkie pozostałe pliki downloadera (nie wykazujące złośliwej natury) pozostają w folderze /printhood/. Zarówno folder modułu kradzieży informacji, jak i wszystkie pliki samego szkodnika pozostają w systemie ofiary.

BIND:
Jeżeli ani słowo „update” ani „delete” nie zostaną znalezione, Timer 12 sprawdza, czy polecenie zawiera słowo „bind” i tworzy plik "nrbindek.dll" z wykorzystaniem dokładnie tego samego strumienia bajtów, który był używany w pliku "update.dll".

Nic innego nie dzieje się na tym etapie. Jednakże, tak jak wspomnieliśmy wcześniej na etapie działań wewnątrz TForm4.FormCreate, przy uruchomieniu szkodliwy program sprawdza obecność pliku "nrbindek.dll".

Jeżeli plik zostanie znaleziony, Timer 12 włącza Timer 28.

Jeżeli słowo „bind” nie zostanie odnalezione w rozkazie, parsowane jest kolejne polecenie.

DISKGO:
Jeśli plik polecenia zawiera słowo „diskgo”, tworzony jest plik "lbdiskgo.dll", z wykorzystaniem dokładnie tego samego strumienia bajtów, który był używany w pliku "update.dll". Parsowanie jest kontynuowane.

Uwaga: Obecność pliku "lbdiskgo.dll" jest sprawdzana przez Timer 42 i Timer 43.

DISKGET:
Jeśli plik polecenia zawiera słowo „diskget”, tworzony jest plik "fskdiskget.dll", z wykorzystaniem dokładnie tego samego strumienia bajtów, który był używany w pliku "update.dll" i włączany jest Timer 23.

Timer 12 następnie sprawdza, czy obecny jest plik "specialfile.dll". Jeżeli plik NIE WYSTĘPUJE, Timer 12 będzie szukać rozszerzeń plików zawartych w poleceniu, które otrzymał. Napastnicy wybierają spośród 27 rozszerzeń, które są dostarczane przez serwer centrum kontroli i mogą zostać wybrane przy pomocy narzędzia zdalnej kontroli (na początku opisu Timera 12 dostępne rozszerzenia są wypisane w przykładowym pliku z rozkazami). Każde rozszerzenie pliku jest oddzielone za pomocą specjalnego znacznika „$.$”.

Timer 12 poszukuje znacznika "$.$". Jeżeli znacznik nie zostanie znaleziony, parsowanie zatrzymuje się w tym miejscu.

Jeżeli znacznik zostanie znaleziony, rozszerzenia są zapisywane w specjalnym pliku "specialfile.dll" i włączany jest Timer 26.

Uwaga: Plik specialfile.dll jest używany do wskazania szkodnikowi, jakich plików ma poszukiwać, a Timer 26 obsługuje polecenie diskget.

Po wykonaniu powyższych czynności (lub gdy plik specialfile.dll był już wcześniej utworzony), sprawdzana jest obecność pliku "logfi.dll". Jeżeli plik nie zostanie znaleziony, parsowanie poleceń jest zatrzymywane.

Jeżeli plik logfil.dll jest obecny, określone pliki są wyszukiwane na ustalonych dyskach twardych i napędach wymiennych. Słabe umiejętności programowania są dość widoczne w tej części kodu.

Warto również zauważyć, że pliki "MHTML" będą wyszukiwane, mimo iż nie ma takiej opcji w narzędziu zdalnej kontroli po stronie serwera, a autorzy popełnili błąd wprowadzając dwukrotnie tę samą pozycję na zakodowanej liście plików, które mają być wyszukiwane (dwukrotny wpis htm).

Wyszukiwane typy plików:

*.*txt/*.*jpg/*.*doc/*.*pdf/*.*bmp/*.*docx/*.*mdb/*.*xls/*.*csv/*.*html/*.*avi/
*.*mp3/*.*wave/*.*htm/*.*rar/*.*zip/*.*htm
(znowu?!)/*.*gif/*.*7z/*.*jar/*.*JPEG/*.*mp4/*.*3gp/
*.*dat/*.*MPEG/*.*SWF/*.*WMV/*.*xml/*.*MHTML/

Całość to 29 rozszerzeń, z jednym duplikatem. 27 rozszerzeń jest obecnych w narzędziu zdalnej kontroli, jednego brakuje (MHTML).

Plik dziennika typu "logfi.dll" jest zapisywany dla każdego dysku twardego, ponadto tworzona jest jego kopia zapasowa "logfi.dll.BMH". Nadpisuje ona logi dla każdej iteracji pętli.

Kiedy parsowanie zostanie zakończone, Timer 12 rozłącza się i następuje powrót.

 

MONITOROWANIE

 

Timer 3: przechwyt PIK – zbieranie zrzutów ekranu sieci społecznościowych / komunikatorów internetowych / poczty webmail

Interwał: 60 sekund

Timer 3 tworzy plik „begirnagir.htp”.

Następnie sprawdza, czy użytkownik korzystał z poniższych serwisów, jeśli tak - inicjuje tryb zbierania zrzutów ekranu:

gmail, hotmail, yahoo! mail, google+, msn messenger, blogger, massenger (?), profile, icq, paltalk, yahoo! messenger for the web, skype, facebook.

Zrzuty ekranu są zapisywane jako obrazy JPG z nazwami o strukturze: mm-dd-rrrr-ggmmss. Wykorzystywane są funkcje „Now” i „FormateDateTime”.

 

Timer 13: przechwyt DESK – zrzut ekranu

Interwał: 3 minuty

Uwaga: Niby GUI używany do kontroli bota mówi, że ten czas to 2 minuty, ale kod nie kłamie.

Timer 13 zbiera zrzuty ekranu co kolejne 3 minuty. Zapisywane są one z nazwami o strukturze: mm-dd-rrrr-ggmmss. Wykorzystywane są funkcje „Now” and „FormateDateTime”.

Pliki są w formacie JPG.

 

Timer 14: przechwyt SOUND – nagrywanie dźwięku

Ten timer jest odpowiedzialny za uruchomienie nagrywania dźwięku przy pomocy funkcji mci* z biblioteki winmm.dll.

Używane są polecenia: "OPEN NEW TYPE WAVEAUDIO ALIAS mysound", "SET mysound TIME FORMAT MS BITSPERSAMPLE 8 CHANNELS 1 SAMPLESPERSEC 8000 BYTESPERSEC 8000" oraz "RECORD mysound". Po wysłaniu poleceń, włączany jest Timer 30 natomiast Timer 14 kończy.

 

Timer 30: uruchamiany przez Timer 14 (przechwyt polecenia SOUND)

Interwał: 60 sekund

Ten timer nie robi w zasadzie nic poza uruchomieniem Timera 31 kiedy nadejdzie czas zapisu nagranego dźwięku.

 

Timer 31: uruchamiany przez Timer 30 (kiedy nadejdzie czas zapisu nagranego dźwięku)

Kiedy wystarczająco dużo czasu minęło od rozpoczęcia nagrywania dźwięku, Timer 31 wyłącza Timer 30 i zatrzymuje nagrywanie, wysyłając następujące polecenie: „STOP mysound”.

W celu zapisu nagranych ścieżek dźwięku wysyłane jest polecenie „SAVE mysound„. Pliki są zapisywane przy użyciu następującej konwencji nazw: mm-dd-rrrr-ggmmss. Wykorzystywane są funkcje „Now” i „FormateDateTime”.

Plik wynikowy jest zapisywany jako .wav.BMH.

Następnie Timer 31 jest wyłączany, a Timer 14 (obsługa polecenia Sound) jest przygotowywany do ponownego rozpoczęcia nagrywania.

 

Timer 32: Konfiguracja keyloggera

Interwał: 60 sekund

Mimo iż instalacja keyloggera ma miejsce przy uruchomieniu aplikacji, w procedurze FormCreate Timer 32 konfiguruje keylogger co 60 sekund. Szczegóły instalacji i konfiguracji keyloggera zostały podane we wcześniejszej części naszej analizy.

 

Timer 2: Tworzenie logów keyloggera

Interwał: 10 sekund

Timer 2 rozpoczyna działanie od pobrania nazwy aktualnego użytkownika (funkcja API GetUserName), a następnie sprawdza, czy obecny jest plik "poki65.pik". Ten plik jest dziennikiem aktualnych przechwytów naciśnięć klawiszy. Jeżeli plik nie zostanie odnaleziony, Timer 2 rozpoczyna poszukiwanie pliku "solt.html", który pokazuje, czy keylogger utworzył już swój pierwszy dziennik.

Jeżeli żaden z powyżej wymienionych plików nie zostanie znaleziony, oznacza to, że keylogger dopiero rozpocznie pierwsze logowanie.

Pierwszy plik dziennika różni się od kolejnych plików dziennika, ponieważ zawiera dużo więcej informacji. Pliki keyloggera Madi używają tagów HTML i kolorowych oznaczeń ułatwiających ich czytanie.

Przy pierwszym logowaniu wykonywane jest polecenie "cmd.exe /c ipconfig /allcompartments > ipconfig.txt"

Po odczekaniu 5 sekund zawartość pliku "ipconfig.txt" jest dodawana do zawartości specjalnie utworzonego pliku HTML.

Nazwa komputera i obecna nazwa użytkownika są dołączane do dziennika, następnie podawana jest lista dostępnych napędów: stacja dyskietek, dysk twardy, dysk sieciowy, napęd CD-ROM i dysk RAM.

Na końcu pliku dziennika dodawana jest pełna lista zainstalowanego oprogramowania, z uwzględnieniem poprawek bezpieczeństwa, co można zobaczyć na obrazku poniżej:

Po zakończeniu tej części tworzony jest plik o nazwie "solt.htm" zawierający słowo "wertik".

Plik dziennika poki65 podlega dalszemu formatowaniu. Na samym początku można zaobserwować opcję "Content-Language", która posiada wartość "fa", co oznacza język perski.

W ten sposób generowane są dzienniki keyloggera.

 

Timer 4: Wstawianie w dzienniki keyloggera znaczników czasowych i etykiet do wyświetlania przechwyconych zrzutów ekranu

Interwał: 1 milisekunda

Timer 4 jest odpowiedzialny za wstawianie do dziennika keyloggera etykiet IMG. Odpowiada również za wstawienie znaczników czasowych pobieranych z serwera C&C (zobacz sekcję RÓŻNE poniżej, Timer 7 i 8).

 

Timer 6: Tworzenie kopii zapasowej dziennika keyloggera do ekstrakcji

Timer 6 szuka pliku poki65.pik - aktualnej sesji logowania. Jeżeli nie napotka tego pliku, nastąpi powrót.

Następnie szuka wielkości pliku dziennika. Jeżeli rozmiar jest mniejszy niż 15 KB, nastąpi powrót. Przesyłane są jedynie pliki o rozmiarze większym od 15 KB. Jeżeli kryterium rozmiaru pliku do ekstrakcji zostanie spełnione, plik jest kopiowany z zachowaniem konwencji nazwy: mm-dd-rrrr-ggmmss.HTM. Następnie Timer 6 usuwa plik „poki65.pik” i kończy swoje działanie.

Uwaga: Nowy dziennik zostanie utworzony przez Timer 2 (solt.html nakazuje keyloggerowi nie rejestrować ponownie napędów, zainstalowanego oprogramowania itd).

 

KRADZIEŻ DANYCH

Kradzież danych jest obsługiwana przez kilka timerów. Każdy rodzaj skradzionych danych jest przechowywany w specjalnym folderze na serwerze. Pliki wysyłane do serwerów C&C są zakodowane w Base64.

 

BIND:

Timer 28: Uruchomiony podczas procedury FormCreation (w odniesieniu do polecenia BIND)

Uwaga: kiedy moduł kradzieży rozpoczyna działanie, Timer 28 jest włączany, jeśli obecny jest plik „nrbindek.dll” (tworzony przez rozkaz BIND).

Timer 28 szuka plików "*.*exe" na wszystkich ustalonych dyskach twardych. Dla każdego znalezionego pliku *EXE*, który nie należy do folderu "Windows", "Program Files" lub "Program Files (x86)", do pliku filebind.xls dodawany jest wpis (pełna ścieżka dostępu do pliku *EXE*).

Gdy dyski twarde zostały zeskanowane, Timer 28 kończy swoje działanie.

Plik filebind.xls zawiera więc spis wszystkich plików wykonywalnych, za wyjątkiem tych w katalogach Windows i Program Files.

 

Timer 29: Uruchomiony podczas procedury FormCreation (w odniesieniu do polecenia BIND)

Uwaga: kod tego timera jest chyba najgorszy z całego kodu ciała modułu kradzieży informacji. Zdolności programistyczne stoją tutaj na naprawdę mizernym poziomie.

Timer 28 generuje listę plików *EXE*, które nie należą do folderów "Windows", "Program Files" lub "Program Files (x86)". Dla każdego wpisu takiego pliku, Timer 29 tworzy kopię zapasową plików wykonywalnych. Do ich oryginalnych nazw dodawane jest rozszerzenie *.bind*.

Wiele plików jest używanych do monitorowania stanu ekstrakcji plików wykonywalnych.

Jednakże, Timer 29 aktualnie nic nie robi - zapewne ze względu na błędy.

 

Timer 9: Poszukiwanie plików, które mogą już zostać przesłane

Interwał: 5 sekund

Timer 9 jest wyłączany. Jeżeli Timer 19 lub Timer 20 jest włączony, oznacza to, że trwa aktualnie zadanie ekstrakcji danych. Timer 9 jest włączany i wykonywany jest powrót.

W przeciwnym razie Timer 9 szuka plików *.*KILOP oraz *.htm.BMH* w katalogu szkodnika. Pliki KILOP są zakodowanymi Base64 wersjami plików, które mają zostać poddane ekstrakcji. Jeżeli żaden z plików nie zostanie odnaleziony, Timer 9 jest włączany i wykonywany jest powrót.

Jeżeli pliki zostaną odnalezione i Timer 19 jest włączony, wówczas może rozpocząć się ich wysyłanie. Przed wykonaniem powrotu włączany jest Timer 9.

 

Timer 19: Sprawdzanie, czy instrumentarium IE było używane do odwiedzenia strony ładowania

Interwał: 25 sekund

Timer 19 poszukuje określonego nagłówka strony:

Jeżeli napotkana zostanie strona "new title hastam - Microsoft Internet Explorer", Timer 19 kończy działanie.

„OKshodiha - Windows Internet Explorer” oznacza, że plik może zostać przesłany– Timer 20 jest włączany i następuje powrót.

Jeżeli żaden ze wspomnianych nagłówków nie zostanie odnaleziony, Timer 19 uruchamia funkcję IE_Instrumentation i odwiedza stronę Sendfilejj.html, włącza Timer 20, następnie wykonywany jest powrót.

 

Timer 20: Przesyłanie pliku

Timer 20 szuka plików *.*KILOP, wylicza identyfikator BOTID (zobacz opis Timera 1, aby dowiedzieć się więcej) i wypełnia parametry POST. Formularze „S0”, „S1” i „S2” obecne na stronie Sendfilejj.html są „uzupełniane” i plik jest przesyłany z użyciem Instrumentarium IE.

T3 to BOTID + folder używany do przesyłania (zobacz poniżej);

T2 to nazwa pliku;

T1 to zakodowana w Base64 zawartość pliku.

Aby wyliczyć T3, do identyfikatora BOTID dodawany jest następujący folder (każda ofiara posiada na serwerze centrum kontroli swój folder główny z nazwą obejmującą BOTID):

„/Pi/” dla .jpg.BMH - przechwycone zrzuty ekranu

„Te/ dla .htm.BMH - dzienniki keyloggera

„/So/ dla .wav.BMH - ścieżki zarejestrowanych dźwięków

„/Fi/” dla important.file.BMH

/Fi/CoolDisk/” dla .fildik.BMH - dane skradzione z napędów wymiennych

Pliki są przesyłane za pośrednictwem strony Sendfilejj.html hostowanej na serwerze C&C, która jest wrapperem dla skryptu „sik.php” wykorzystywanego do przejmowania przesyłanych danych.

 

Timer 5: Koder Base64 dla danych poddanych ekstrakcji

Interwał: 1 milisekunda

Po uruchomieniu kodera, Timer 5 jest wyłączany, wyszukiwane są pliki *.*BMH (pliki, które zostaną poddane ekstrakcji gdy tylko skończy się kodowanie Base64) w folderze szkodliwego oprogramowania. Kiedy jeden z plików zostanie odnaleziony, sprawdzane jest, czy plik istotnie rezyduje na dysku i czy jest dostępny. Jest kodowany w Base64 i zapisywany jako nazwapliku.BMH.KILOP. Niekodowana wersja (BMH) jest usuwana, Timer 5 jest ponownie włączany i następuje powrót. Pliki są przetwarzane jeden po drugim, ale ze względu na bardzo mały interwał timera jest to proces niemalże natychmiastowy.

Uwaga: wynikowe zakodowane pliki to te przetworzone przez Timer 20 opisany powyżej. Proces przebiega następująco: Timer 9 włącza Timer 19, który z kolei włącza Timer 20 do ładowania plików generowanych przez Timer 5.

 

Timer 21: Parser filesend.xls

Plik filesend.xls zawiera listę plików, które mają zostać poddane ekstrakcji.

Po uruchomieniu parsera, Timer 21 jest wyłączany. Jeżeli plik „filesend.xls” jest obecny, jest on otwierany i odczytywany.

Wszystkie pliki, które mają zostać poddane ekstrakcji, są rozdzielone znakiem „*”, co pokazuje poniższy przykład:

*C:\Documents and Settings\%USER%

\Desktop\tools\ukradnijmnie.txt**C:\Documents and Settings\%USER%

\Desktop\tools\ukradnijmnie.txt*

Timer 21 parsuje każdy wpis i sprawdza, czy dany plik istnieje. Jeżeli odpowiedź jest pozytywna, w katalogu szkodnika tworzona jest kopia pliku z rozszerzeniem .file.BMH. (w naszym przykładzie mamy: "ukradnijmnie.txt.file.BMH".)

 

Timer 10: Śledzenie postępów ekstrakcji i czyszczenie stron instrumentarium IE

Kiedy plik został przesłany z wykorzystaniem Timera 20, POST jest wykonywany na pliku sik.php, zwracana strona zawiera nazwę załadowanego pliku oraz zakodowany ciąg znaków „Save Shode”, co można zobaczyć na obrazku poniżej:

Timer 10 jest odpowiedzialny za przechowywanie informacji o śladach przesyłanych plików. Pliki poddane ekstrakcji dodawane są do archiwum „rafteha.zip”, które zawiera listę plików, które zostały już obsłużone. Ostatnia ścieżka dostępu pliku do obsługi jest zapisywana w pliku „fileomade.xls”.

 

Timer 15: Poszukiwanie „filesend.xls”

Timer 15 jest wyłączany po uruchomieniu, plik „filesend.xls” jest poszukiwany. Jeżeli zostanie odnaleziony, Timer 15 jest włączany i następuje powrót.

Jeżeli plik nie zostanie odnaleziony, sprawdzane jest, czy Timer 1 jest włączony. Jeżeli Timer 1 jest włączony, włącza on Timer 15 i wykonuje powrót.

Jeżeli Timer 1 nie jest włączony, Timer 15 sprawdza stan Timera 18. Jeżeli jest on włączony, Timer 15 włącza się samoistnie i wykonuje powrót.

Jeżeli plik „filesend.xls” nie jest obecny i zarówno Timer 1, jak i Timer 18 jest wyłączony, tworzony jest plik "pangtkp.bat", który zawiera instrukcję "ping C&C_IP >C:\DOCUME~1\%USER%\TEMPLA~1\iexplore.exe.pkklm".

Komenda jest wykonywana, a przed wykonaniem powrotu włączany jest Timer 1 i Timer 5.

Istnieją inne timery, które są w ten, czy inny sposób związane z ekstrakcją i kradzieżą danych, ale wszystkie one są dość podobne. Istnieje wiele redundancji w tym złośliwym oprogramowaniu.

 

Timer 23: Wyliczenie wszystkich napędów wymiennych obecnych na komputerze

Timer 23 wylicza wszystkie napędy wymienne obecne na komputerze, włącza Timer 24, a następnie Timer 23 wyłącza się samoczynnie i wykonywany jest powrót.

 

Timer 24: Wyszukiwanie i kopiowanie plików z nośnika wymiennego

Timer 24 otrzymuje listę urządzeń wymiennych przygotowaną przez Timer 23 i przeszukuje wszystkie pliki obecne na urządzeniach dokonując jednocześnie ich kradzieży.

Skradzione pliki sa kopiowane do katalogu szkodnika z rozszerzeniem fildik.BMH, a po zakodowaniu (Base64) zmieniają rozszerzenie na fildik.BMH.KILOP i są wysyłane do C&C.

Listy przetworzonych plików przechowywane są wewnątrz archiwum raftehacool.zip.

 

RÓŻNE

Moduł kradzieży informacji zawiera 52 timery. Niektóre z nich nie wykonują żadnych znaczących działań. Autorzy zdecydowali się na pingowanie serwera C&C i zapis rezultatów w plikach o specyficznych nazwach. Pliki te są sprawdzane i analizowane (parsowane) w celu ustalenia, czy C&C jest dostępne i jakie działania mogą być podjęte. Jest to dość amatorskie podejście do programowania.

 

Timer 44: Proste pingowanie przez pangtipo.bat

Timer 44 jest wyłączany tuż po uruchomieniu. Timer 44 sprawdza, czy Timer 45 jest włączony i jeżeli jest, wykonuje powrót. Przed wykonaniem powrotu Timer 44 jest włączany. Jeżeli Timer 45 jest wyłączony, tworzony jest plik "pangtipo.bat", który zawiera rozkaz "ping C&C_IP >C:\DOCUME~1\%USER%\TEMPLA~1\iexplore.exe.pkxml".

Komenda jest wykonywana, Timer 44 jest włączany i wykonuje powrót.

 

Timer 11: Proste pingowanie przez pangtip.bat

Timer 11 jest wyłączany tuż po uruchomieniu. Jeżeli Timer 16 jest aktualnie włączony, Timer 11 włącza się samoczynnie i wykonuje powrót. Jeżeli aktualnie włączony jest Timer 17, Timer 11 jest włączany ponownie i wykonywany jest powrót.

Jeżeli żaden z podanych timerów nie jest włączony, tworzony jest plik "pangtip.bat", który zawiera rozkaz "ping C&C_IP >C:\DOCUME~1\%USER%\TEMPLA~1\iexplore.exe.pkxm" wykonywany poprzez funkcję ShellExecute.

Timer 16 jest włączany i następuje powrót.

Uwaga: Timery 1, 7, 11, 15, 44 i 48 generują te pliki wsadowe pod różnymi nazwami i wyniki ich działań również zapisywane są pod różnymi nazwami.

 

Timer 7: Czy otwarto już „timeip.php”?

Timer 7 jest wyłączany tuż po uruchomieniu. Timer 7 sprawdza, czy odwiedzana była już strona timeip.php. Jeżeli tak się nie stało, instrumentarium IE zostanie użyte do otwarcia wspomnianej strony. Następnie Timer 7 wyłączy się i włączy Timer 8 (zobacz opis poniżej).

Utworzony zostanie plik "pangip.bat", który będzie zawierał polecenie "ping C&C_IP”. Rezultaty zapisywane są jako plik „iexplore.exe.pkam”.

Uwaga: nazwa pliku używana do zapisu wyników poleceń pingowania oparta jest na nazwie pliku wykonywalnego modułu kradzieży informacji, która brzmi: „iexplore.exe”. Jeśli nazwa pliku wykonywalnego zostanie zmieniona, pliki wynikowe również będą posiadały różne nazwy.

 

Timer 8: Przetwarzanie wyników otwarcia skryptu timeip.php

Skrypt timeip.php zwraca aktualną datę systemową i adres IP komputera ofiary. Wyniki odwiedzin szkodliwej strony (Timer 7) są zapisywane w buforze, który jest używany podczas tworzenia dziennika keyloggera (zobacz opis Timera 4).

 

Timer 22: Upewnienie się, że istnieje kopia zapasowa downloadera UpdateOffice

Uwaga: downloader jest jedyną częścią szkodnika, która uruchamia się po wystartowaniu systemu Windows. Dlatego ważne jest, aby downloader posiadał różne kopie zapasowe.

Timer 22 sprawdza, czy plik „UpdateOffice.exe” jest obecny w katalogu modułu kradzieży ("Templates"). Nie powinno go tam być, ponieważ znajduje się w katalogu "Printhood" (zobacz opis downloadera na początku niniejszego artykułu).

Ponieważ plik nie jest obecny, Timer 22 wywołuje procedurę pobrania ścieżki dostępu do katalogu „Printhood” (funkcja GetSpecialFolderLocation z parametrem CSIDL_PRINTHOOD). Podczas łączenia nazwy pliku „UpdateOffice.exe” i folderu „Printhood” brakuje znaku „\” - procedura jest napisana błędnie. Zwracany ciąg znaków to: "C:\Documents and Settings\%USER%\PrintHoodUpdateOffice.exe" zamiast "C:\Documents and Settings\%USER%\PrintHood\UpdateOffice.exe".

Timer 22 następnie kopiuje (albo przynajmniej bardzo się stara, ponieważ ścieżka dostępu jest błędna!) "C:\Documents and Settings\%USER%\PrintHoodUpdateOffice.exe" jako "srAntiq.dll" do folderu Templates.

Jeżeli zdarzy się, że plik „OfficeUpdate.exe” nie jest obecny w folderze „printhood”, jego kopia jest przywracana z fałszywej biblioteki „srAntiq.dll”.

Timer 22 uzyskuje ścieżkę dostępu do folderu autouruchamiania przy pomocy polecenia CSIDL_STARTUP: "C:\Documents and Settings\%USER%\Start Menu\Programs\Startup".

Następnie Timer 22 sprawdza, czy downloader „OfficeUpdate.exe” jest obecny w tym folderze. Jeżeli odpowiedź jest negatywna, plik srAntiq.dll jest kopiowany do autostartu, a Timer 22 wykonuje powrót.

 

Timer 25: Poszukiwanie „fsdiskget.dll”

Timer 25 sprawdza, czy plik „fsdiskget.dll” jest obecny w katalogu szkodnika; a jeśli tak nie jest - wykonuje powrót.

Jeżeli plik zostanie znaleziony, Timer 25 włącza Timer 23 (szczegółowy opis znajduje się w sekcji KRADZIEŻ DANYCH).

 

Timer 42: Sprawdzanie lbdiskgo.dll / soltanik.dll / res.exe

Timer 42 sprawdza, czy flaga (ustawiania przez Timer 34 i czyszczona przez Timer 33) jest ustawiona na 0 i czy pliki lbdiskgo.dll, soltanik.exe oraz res.exe są obecne. Jeżeli są obecne, włączany jest Timer 33; w przeciwnym razie wykonywany jest powrót.

 

Timer 43: Sprawdzanie lbdiskgo.dll / ladine.dll / res.exe

Timer 43 wykonuje niezwłoczny powrót, jeżeli pliki „lbdiskgo.dll” lub „ladine.dll” są obecne. Jeżeli obecny jest plik res.exe, Timer 43 włącza Timer 44 i Timer 48; w przeciwnym razie wykonywany jest powrót.

 

Timer 45: Odwiedzenie strony ReReReRe.htm

Timer 45 usuwa plik pangtipo.bat i odczytuje plik iexplore.pkxml, aby sprawdzić, czy serwer C&C odpowiedział (opisy Timera 1 i Timera 16 podają więcej szczegółów na temat użycia plików .bat).

Używa funkcji FindWindow, aby sprawdzić czy wykorzystano instrumentarium IE do odwiedzenia specjalnej strony ReReReRe.html o tytule: ”r!r!r!r!”.

Poszukiwane są różne warianty jak np. „r!r!r!r! - Windows Internet Explorer” czy "r!r!r!r! - Microsoft Internet Explorer".

Kiedy jeden z nich zostanie odnaleziony, oznacza to, że strona została odwiedzona przy pomocy IE. Timer 45 jest wyłączany i wykonywany jest powrót.

Jeżeli żaden z wariantów nie zostanie znaleziony, Timer 45 otworzy adres URL http://C&CIP/ASLK//asgari/mah/ReReReRe.htm, włączy Timer 46 (zobacz poniżej), wyłączy się i wykona powrót.

 

Timer 46: Parsowanie „ReReReRe.htm” (pobieranego przez Timer 45)

Timer 46 przechodzi przez wszystkie uruchomione instancje przeglądarki IE, sprawdzając nagłówek każdej strony HTM. Poszukuje ciągu „r!r!r!r!".

Ta strona to plik ReReReRe.htm pobierany przez Timer 45. Timer 46 poszukuje specjalnego znacznika EOF (End Of File - koniec pliku): „tamamshodfile„. Ten znacznik jest używany przez moduł kradzieży informacji do sprawdzenia, czy strona HTM została w pełni pobrana.

Kiedy strona zostanie potwierdzona jako prawidłowa, Timer 46 szuka identyfikatora S1, który zawiera podwójnie zakodowane (Base64) pliki PE.

Dane zakodowane w Base64 są zapisane jako: ASLASLKK223.dll.

 

Timer 47: Dwukrotne dekodowanie ładunku z ReReReRe.htm zakodowanego w Base64

Uwaga: Timer 46 zapisuje ładunek jako ASLASLKK223.dll.

Ponieważ plik z ładunkiem jest dwukrotnie zaszyfrowany, deszyfracja przebiega w dwóch etapach:

  • Plik ASLASLKK223.dll jest dekodowany do postaci ASLASLKK224.dll w celu uzyskania jednokrotnie szyfrowanego pliku Base64.
  • ASLASLKK224.dll jest dekodowany do postaci „res.exe”: finalnego pliku PE.

Res.exe jest kopią narzędzia Resource Hacker. Plik ASLASLKK224.dll jest usuwany. Użycie pliku res.exe jest objaśnione poniżej w opisie Timera 39.

Kiedy Timer 47 zakończy wyliczanie wszystkich instancji IE, uruchamia procedurę czyszczenia. Poszukuje: " - r!r!r!r! - Windows Internet Explorer" i innych wariantów opisanych w Timerze 45, a następnie wysyła polecenie "WM_Close" w celu ich zamknięcia.

Wśród wszystkich nagłówków wyszukiwane są również te z błędem 404 (np. " - 404 - Błąd wczytywania strony").

Po zakończeniu czyszczenia, Timer 47 wyłącza się samoczynnie i wykonuje powrót.

 

Timer 49: Odwiedzenie strony SeSeSeSe.htm

Timer 49 jest niemalże identyczny jak Timer 45. Jedyna różnica to odwiedzana strona: SeSeSeSe.htm zamiast ReReReRe.htm

Szczegóły można znaleźć w opisie Timera 45.

 

Timer 50: Parsowanie „SeSeSeSe.htm” (pobieranego przez Timer 49)

Timer 50 jest niemalże identyczny jak Timer 46. Jedyna różnica to parsowana strona: SeSeSeSe.htm zamiast ReReReRe.htm i lokalne nazwy plików. Podwójnie kodowany ładunek jest zapisywany jako „ASLASLKK2231.dll”.

Zobacz opis Timera 46, aby dowiedzieć się więcej.

 

Timer 51: Dwukrotne dekodowanie ładunku z SeSeSeSe.htm zakodowanego w Base64

Uwaga: Timer 50 zapisuje ładunek jako ASLASLKK2231.dll.

Ponieważ plik z ładunkiem jest dwukrotnie zaszyfrowany, deszyfracja przebiega w dwóch etapach:

  • Plik ASLASLKK2231.dll jest dekodowany do postaci ASLASLKK2241.dll w celu uzyskania jednokrotnie szyfrowanego pliku Base64.
  • Plik ASLASLKK2241.dll jest dekodowany do postaci „Ladine.dll”: jest to finalny plik PE.

Uwaga: W momencie powstawania tej analizy, strona SeSeSeSe.htm została usunięta z serwera centrum kontroli.

Serwer C&C używany przez starsze warianty modułu kradzieży informacji jest nadal dostępny, a nazwa starszej wersji strony to: „SSSS.htm”. Osadzony plik jest szablonem pliku wykonywalnego downloadera (w celu uzyskania dalszych informacji zobacz opisy Timerów 35, 36, 37, 38 i 39).

Kiedy Timer 51 zakończy wyliczanie instancji IE, wywoła procedurę czyszczenia. Rozpocznie poszukiwanie nagłówków " - s!s!s!s! - Windows Internet Explorer" i innych wariantów opisanych w Timerze 45, a następnie wyśle do Windows Internet Explorer polecenie "WM_Close" w celu pozamykania otwartych stron.

Wśród wszystkich nagłówków wyszukiwane są również te z błędem 404 (np. " - 404 - Błąd wczytywania strony").

Po zakończeniu czyszczenia, Timer 51 wyłącza się i wykonywany jest powrót.

 

FUNKCJE NIE DZIAŁAJĄCE LUB BĘDĄCE W FAZIE BETA: TWORZENIE NOWYCH PLIKÓW WYKONYWALNYCH

W module kradzieży informacji znajduje się kilka timerów, które odnoszą się do brakującego pliku. Udało nam się pobrać brakujący plik z serwera starszego centrum kontroli. Dzięki temu mogliśmy poznać intencje autorów tego złośliwego oprogramowania.

Brakujący plik jest pobierany przez Timer 50: SeSeSeSe.htm. Nie występuje on na aktualnych serwerach C&C.

Jeśli zastąpimy plik SeSeSeSe.htm starszą kopią (pierwotnie SSSS.htm), Timer 51 utworzy plik o nazwie „Ladine.dll”, który jest szablonem pliku wykonywalnego downloadera trojana używanym do instalacji modułu kradzieży informacji.

 

Timer 52: Skopiowanie Ladine.dll do „Soltanik.exe”

Timer 52 pod nazwą „soltanik.exe” tworzy kopię pliku „Ladine.dll”, który jest plikiem szablonu.

 

Timer 35: Wyczyszczenie plików z Timera 39

Timer 35 jest wyłączony. Specjalny identyfikator BOTID jest tworzony przez dołączenie frazy "CoolDiskGo" (do "BOTID_TMP"), np. "CoolDiskGo(MYCOMPUTER-8712422C6C7704EF)".

Adres serwera C&C jest dodawany przez Timer 35 do zmiennej globalnej, która będzie używana przez Timer 38.

Timer 35 próbuje usunąć pliki utworzone przez Timer 39: 1.txt, res.ini, res.log, Icon_1.ico, output.rc i server.exe.

Robi też dużo innych rzeczy, jednakże nie są one w żaden sposób związane z tematem naszej analizy, więc pominiemy je w tym miejscu.

Timer 36 jest włączany jeszcze przed zakończeniem działania Timera 35.

 

Timer 36: Włączenie Timera 37, jeśli plik 1.txt nie został odnaleziony – błąd logiczny / kodowania

Timer 36 jest wyłączany w momencie wykonania. Jeżeli plik „1.txt” nie jest obecny, włączany jest Timer 37. W przeciwnym razie wywoływana jest funkcja dekodowania Base64. 1.txt musi być poprawnym strumieniem bajtów, zakodowanym w Base64 inaczej wystąpi krytyczny wyjątek i Timer 36 zakończy działanie.

 

Timer 37: Aktualizacja zasobów szablonu downloadera: Soltanik.exe

Timer 37 jest wyłączany w momencie wykonania. Uchwyt obsługi strukturalnego wyjątku jest instalowany przed odczytem pliku 1.txt.

W razie wystąpienia wyjątku, uchwyt SEH włączy Timery 42, 34, 33, 35, a Timer 37 zakończy działanie.

Timer 37 oczekuje obecności pliku 1.txt i tu pojawia się błąd logiczny. Timer 37 jest uruchamiany przez Timer 36 tylko wtedy, gdy plik 1.txt nie jest obecny. Zignorujmy w tym miejscu to "niedociągnięcie" i kontynuujmy analizę zamiarów autorów szkodnika Madi.

Timer 37 wywołuje funkcję BeginUpdateResource (z parametrem bDeleteExistingResources ustawionym na 0) i zaczyna uaktualniać zasoby szablonu pliku wykonywalnego (soltanik.exe) w RCDATA.

Dodawany jest wpis MAHDI z zakodowaną w Base64 zawartością z pliku 1.txt. Działa to dokładnie w ten sam sposób, co downloadery ze znamionami sztuczek inżynierii społecznej.

Timer 37 kończy działanie, włączany jest Timer 38.

Uwaga: w końcowej fazie działania Timera 37, Soltanik jest modyfikowany i otrzymuje nowy zasób: MAHDI.

 

Timer 38: Aktualizacja kolejnych zasobów downloadera szablonu (Soltanik.exe)

Kilka wpisów jest dodawanych do RCDATA:

  • Shelikn: specjalny identyfikator BotID generowany przez Timer 35;
  • SiteW: adres IP serwera C&C;
  • Bind: pusty (zgodnie z analizą downloaderów, które używają trików inżynierii społecznej, w tym miejscu powinno znajdować się rozszerzenie wbudowanego pliku, który jest podrzucany ofiarom socjotechniki. Jeżeli MAHDI zawiera zaszyfrowany w Base64 obrazek, wpis Bind powinien zostać ustawiony jako .JPG).
  • Filee: SCR
  • Roze: 0

Gdy zasoby zostaną uaktualnione, następuje powrót i uruchamiany jest Timer 39.

 

Timer 39: Tworzenie finalnego pliku binarnego „Server.exe” z uaktualnioną ikoną

W końcowym etapie działania Timera 38, plik soltanik.exe został w pełni uaktualniony o nowe zasoby. Podczas uruchamiania, Timer 39 wyłącza się i rozpoczyna tworzenie specjalnej linii komend dla narzędzia Resource Hacker (narzędzie zostało wdrożone jako „res.exe” przez Timer 47).

Linia komend wygląda następująco:

W tej procedurze jest błąd. Zaraz po parametrze „-extract” brakuje nazwy pliku wykonywalnego.

Wiersz poleceń wykonuje na dysku zrzut głównej ikony (Icon_1.ico) i tworzy plik o nazwie „output.rc”.

W tym momencie nie wiadomo, który plik przeznaczony był do stosowania jako źródło nowej ikony. Dla zachowania ciągłości naszej analizy załóżmy, że nie ma żadnego błędu i dostarczona została prawidłowa nazwa pliku.

Następnie, druga linia poleceń jest przekazywana do „res.exe”:

Finalna linia poleceń generuje plik Server.exe, kopię pliku soltanik.exe, którego ikona zostaje zmieniona na ikonę uzyskaną w poprzednim poleceniu.

Plik Server.exe jest w pełni uaktualniany, jego zasoby są uzupełniane, a ikona zostaje zmieniona. Nie jest do końca jasne, dlaczego autorzy zdecydowali się na taki ruch, ale mimo wszystkich błędów można zrozumieć ogólny cel całej procedury: utworzyć plik Server.exe z pliku soltanik.exe, z nową ikoną i dodanymi zasobami. Co dzieje się z Server.exe? Nic. Ta funkcja po prostu nie działa. Wygląda na to, że Madi posiada zdolność generowania nowych downloaderów, przynajmniej w teorii.

Pozostałe 7 timerów nie zostanie opisane, ponieważ nie są one godne uwagi.

 

WNIOSKI

W niniejszym artykule przeanalizowaliśmy funkcje kradzieży danych zaimplementowane w kampanii Madi. Styl kodowania, użycie Delphi oraz nieskomplikowane techniki programistyczne wskazują na dość prymitywne podejście.

Większość działań kradzieży danych i komunikacji z serwerami centrum kontroli wykonywanych jest za pośrednictwem zewnętrznych plików, co prowadzi do niezłego bałaganu. Ktokolwiek to kodował, prawdopodobnie jest jeszcze na etapie zgłębiania pierwszych rozdziałów podręczników do Delphi.

Jest to dosyć zaskakujące, biorąc pod uwagę efektywność kampanii oraz dane otrzymane z leja. Podczas prowadzonej obserwacji, do serwerów przyłączonych było ponad 800 ofiar. Wszystkie cele padły ofiarą różnych metod socjotechniki, wykorzystywanych przez złośliwe oprogramowanie.

Podsumowując, możemy powiedzieć, że:

  • komponenty kampanii Madi są zaskakująco mało wyrafinowane;
  • nigdzie w szkodliwym oprogramowaniu nie zostały użyte exploity oraz luki 0-day;
  • mimo powyższego, sukces samej kampanii jest zaskakująco duży;
  • niemniej jednak należy pamiętać, że nawet mało wysublimowane szkodliwe oprogramowanie może kraść dane;
  • Madi jest projektem niskobudżetowym, lecz obliczonym na wysokie zyski;
  • autorzy kampanii pozostają nieznani.

Szkodliwe oprogramowanie Madi będzie przez nas monitorowane, a wszelkie nowe spostrzeżenia opublikujemy w odrębnych artykułach.