Analiza złośliwego systemu Emotet v4

Wstęp

Emotet jest modularnym koniem trojańskim, który po raz pierwszy został zaobserwowany w czerwcu 2014 roku przez Trend Micro. Ten rodzaj złośliwego systemu jest ściśle powiązany z innymi rodzajami, takimi jak Geodo, Bugat czy Dridex, które uznawane są za warianty należące do jednej rodziny.

Zadebiutował jako zaawansowany banker – u swych początków wykorzystywany był do wykradania pieniędzy z kont zainfekowanych ofiar. Jego początkowa wersja była wymierzona w klientów niemieckich i austriackich banków. Przejmowanie kont odbywało się z użyciem techniki Man-in-the-Browser, polegającej na przejęciu kontroli nad przeglądarką i przechwytywaniu komunikacji sieciowej przez podsłuchiwanie wywołań odpowiednich funkcji systemowych.

W kolejnej wersji (v2) arsenał Emoteta został uzupełniony o automatyczne wyprowadzanie pieniędzy z kont przy pomocy systemów ATS (Automatic Transfer System) (dokładniejszy opis tej techniki można znaleźć na 20 stronie raportu CERT Polska z 2013 r.). Jest to sposób powszechnie wykorzystywany również w innych bankerach, m.in. w ISFB (Gozi) i Tinbie.

Na początku kwietnia 2017r. zaobserwowaliśmy szeroką kampanię spamową, w której były dystrybuowane fałszywe maile pochodzące rzekomo od firmy kurierskiej DHL. Maile zawierały odnośnik prowadzący do nieznanego wcześniej, nowego wariantu złośliwego systemu znanego pod nazwą Emotet.

W przypadku tej kampanii, zmiany w kodzie oprogramowania, a także w sposobie komunikacji z serwerami Command&Control wskazywały, iż mamy do czynienia z Emotetem w wersji 4. Z tego względu postanowiliśmy szczegółowo przeanalizować to zagrożenie.

Dropper

Skrypt do którego prowadziły odnośniki zawarte w mailach nie był mocno zobfuskowany. Łańcuchy znaków zostały jedynie odwrócone, stąd można było bez większego trudu odczytać adresy URL, prowadzące do pliku zawierającego omawiany malware.

Adresy URL prowadzące do Emoteta:

Moduł główny

Emotet jest złośliwym oprogramowaniem o strukturze modułowej. Podstawowym zadaniem pobieranego przez dropper pliku wykonywalnego jest rejestracja bota i pobranie modułów pełniących konkretne zadania. Złośliwe oprogramowanie dostarczane jest w postaci spakowanej przy pomocy generycznego packera, który w zamierzeniu ma zmylić silniki antywirusowe i utrudnić analizę. Po rozpakowaniu, sterowanie przekazywane jest do głównego kodu.

Na samym początku ładowane są biblioteki i rozwiązywane są adresy funkcji WinAPI, wykorzystywane przez malware m.in. do szyfrowania i komunikacji z serwerem Command&Control. Nazwy potrzebnych funkcji i bibliotek przechowywane są w postaci tablic wartości funkcji skrótu z nazwy danego elementu. Emotet wykorzystuje w tym celu prostą funkcję haszującą sdbm. Aby dodatkowo zróżnicować tablice, zawarte w nich wartości XORowane są dodatkowo ze stałą wartością określoną w pliku.

Charakterystyczne łańcuchy znaków również nie występują jawnie – są dekodowane na czas użycia przy pomocy 4-bajtowego klucza XOR skojarzonego z danym łańcuchem.

Główny plik wykonywalny zawiera również listę adresów IP i portów, kierujących do serwerów C&C. Podobnie jak w poprzednich wersjach – komunikacja z serwerem kontrolera przebiega z użyciem protokołu HTTP.

Szyfrowanie komunikacji

Największe zmiany względem poprzedniej wersji Emoteta można zaobserwować w komunikacji. Wcześniej do szyfrowania wykorzystywany był algorytm RC4. W wersji czwartej wykorzystywany jest 128-bitowy AES.

Przykładowe żądanie wygląda następująco:

Treść żądania zawarta jest w nagłówku Cookie. Nazwa „ciasteczka” generowana jest losowo i stanowi 16-bitową wartość zakodowaną szesnastkowo. Wartość ciasteczka zawiera żądanie zakodowane w Base64.

Wartość po odkodowaniu ma następującą strukturę:

Przed wysłaniem żądania tworzone są dwa klucze. Najpierw ładowany jest 768-bitowy klucz publiczny RSA, zawarty w pliku wykonywalnym. Następnie generowany jest losowy klucz AES-128-CBC, który posłuży do szyfrowania komunikacji z C&C. Wygenerowany klucz AES szyfrowany jest kluczem RSA-768 i dołączany jest do żądania z użyciem PKCS#1v2.0 (OAEP).

Kryptografia zrealizowana jest przy pomocy zestawu funkcji Microsoft CryptoAPI.

Generowanie i importowanie kluczy:

Szyfrowanie żądania:

Komunikacja z C&C

Po przechwyceniu i odszyfrowaniu komunikatu z żądaniem – żądanie prezentowało się następująco:

W komunikacji wykorzystywany jest protokół bazujący na Google Protocol Buffers. Protocol Buffers stanowi rozwiązanie, które pozwala na proste budowanie protokołów, przy użyciu struktur definiowanych w języku protobuf. Na podstawie tak określonych struktur, Protocol Buffers generuje moduły, dostarczające parsery i serializery dla poszczególnych elementów protokołu, które mogą być bezpośrednio wykorzystane w aplikacji. Protocol Buffers pozwala na generowanie modułów dla wielu języków programowania. Wśród wspieranych języków jest m.in. Python, Java, PHP czy C++. Zastosowanie tego typu rozwiązań nie jest nowością w przypadku złośliwego systemu i było wykorzystywane wcześniej, np. w Gootkicie.

W przypadku Emoteta, autor pokusił się o małą modyfikację. Jeden z elementów wykorzystuje niestandardowe kodowanie, przez co nie jest poprawnie odczytywany przez standardowe parsery (przykładowo protoc –decode_raw zwraca błąd).

Mimo to udało nam się odtworzyć strukturę protokołu:

W żądaniu rejestracji wysyłany jest numer komendy (16) i podstawowe dane o systemie operacyjnym, na którym bot zostaje uruchomiony. Poszczególne pola struktury RegistrationRequestBody zawierają następujące informacje:

Pole botId

Pole botId zawiera identyfikator bota unikalny dla danej maszyny. Jego wartość ma następującą strukturę:

• host_name – zawiera wyłącznie znaki z grupy 0..9a..zA..Z-, pozostałe zastąpione są znakami zapytania (?)
• locale – zawiera identyfikator kraju. W tym wypadku również myślnik „-” jest zastępowany „?”
• host_id – 32-bitowa heksadecymalna wartość funkcji skrótu sdbm (tej samej, która wykorzystywana jest przez API resolver). Skrót bazuje na wartości, która jest wynikiem operacji xor na nazwie aktualnie zalogowanego użytkownika i numerze seryjnym dysku, na którym zainstalowany jest system Windows.

Pole osVersion

32-bitowe pole określające wersję systemu operacyjnego Windows. Poszczególne bity zawierają informację o następujących elementach struktury OSVERSIONINFOEX

Pole procList

Zawiera listę nazw uruchomionych procesów, oddzielonych przecinkiem.

Pole mailClient

Informacje o wykorzystywanym kliencie poczty (wartość pozyskiwana z klucza rejestru HKLM\Software\Clients\Mail). jeżeli jest to Microsoft Outlook i jego plik DLL MAPI (Messaging Application Program Interface) jest 64-bitowy, do nazwy dodawany jest przyrostek „x64” po spacji.

Odpowiedź

W odpowiedzi C&C dostarcza listę modułów złośliwego oprogramowania. Bez względu na to czy zostało wysłane poprawne żądanie, czy nie – odpowiedź zawsze zawiera status 404 Not Found. Mimo to, przy poprawnym skomunikowaniu się z serwerem, w treści otrzymujemy zaszyfrowaną odpowiedź.

Struktura zaszyfrowanej odpowiedzi jest podobna do struktury żądania. Do szyfrowania wykorzystywany jest klucz AES wygenerowany przez próbkę i przekazany w żądaniu. Po odszyfrowaniu, otrzymujemy komunikat o strukturze odpowiadającej następującemu plikowi protobuf:

W tym przypadku wykorzystywane jest niestandardowe kodowanie, o którym wspomnieliśmy na samym początku. Otóż pole repeated Module modules = 1 [packed=true]; jest niedozwolone w kontekście języka struktur protobuf, ponieważ atrybut packed może być zastosowany wyłącznie do typów liczbowych, a nie do obiektów typu Message.

Przenosząc to na opis odpowiadający kodowaniu wykorzystywanemu w Protocol Buffers, odpowiedź ma następującą strukturę:

Warto zaobserwować, iż elementy Module są powtarzane bez poprzedzającego tagu, co jest charakterystyczne dla kodowania packed.

Pole type

Pole type definiuje typ bufora i sposób w jaki należy potraktować jego zawartość. Może przyjmować następujące wartości:

Moduły

W poprzednich wersjach wśród modułów zawarte były elementy odpowiadające za takie funkcjonalności jak:

• Wykradanie pieniędzy z kont bankowych (atak Man in the Browser)
• Bot rozsyłający spam
• Wykradanie maili i danych dostępowych do kont pocztowych
• Moduł DDoS
• Wykradanie historii i haseł z przeglądarki

W wersji 4 dystrybuowanej m.in. w ostatniej kampanii podszywającej się pod DHL, nie zaobserwowaliśmy modułu dość charakterystycznego dla Emoteta, czyli modułu bankowego. Zachowanie pozostałych modułów w większości pozostało jednak bez zmian. Poniżej zawarty jest opis modułów zaobserwowanych w omawianej kampanii:

Moduły wykradające dane dostępowe

Wśród zaobserwowanych modułów znajdowały się dwa, służące do wykradania haseł i danych dostępowych z przeglądarki i klienta pocztowego.
Oba moduły do swoich celów wykorzystywały oprogramowanie firmy NirSoft:

• Mail PassView (Email Password-Recovery) v1.86
• WebBrowserPassView v1.80

Obie aplikacje zawarte były bezpośrednio w pliku wykonywalnym modułów, zakodowane prostą operacją XOR z 32-bitowym kluczem. Po odkodowaniu i zapisaniu do %TEMP%, wykonywane były z parametrem /scomma [nazwa pliku tymczasowego], co prowadziło do zapisania wszystkich haseł do pliku w %TEMP% (nazwa generowana przez GetTempFileNameW). Następnie dane wysyłane były do serwera C&C.

Moduł spamowy

Trzeci zaobserwowany przez nas moduł, służący do rozsyłania spamu zawierającego link do Emoteta jest szczególnie interesujący. Na początku moduł prosi serwer C&C o szablon wiadomości, listę odbiorców i listę kont, z których ma być przeprowadzone rozsyłanie.
Struktura żądania wygląda następująco:

Pola flags i additionalData służą do określania, jakie dane zostały już pozyskane od kontrolera i jakich oczekujemy w odpowiedzi.
Odpowiedź serwera ma następującą strukturę:

Do poszczególnych botów wysyłane są nie tylko dane dotyczące rozsyłanych wiadomości, ale również lista danych dostępowych do kont, z których ma być przeprowadzone rozsyłanie. Konta prawdopodobnie są pozyskiwane przez moduł wykorzystujący Mail PassView, opisany wcześniej.

Przykładowy szablon wiadomości:

Podsumowanie

Podstawową funkcją Emoteta obserwowaną w niedawnych kampaniach jest wykradanie danych dostępowych. W przypadku infekcji zalecamy przede wszystkim zmianę haseł do wykorzystywanych skrzynek mailowych z poziomu lokalnego klienta poczty, a także haseł do serwisów, które były zapisane w przeglądarce.
Emotet jest wciąż aktywny w sieci i istnieje szansa, iż ten rodzaj zagrożenia pojawi się w przyszłych kampaniach.

Informacje dodatkowe

• Szczegółowa analiza Kaspersky’ego z 2015 roku (Emotet v2 i v3)
• Raport CERT Orange z 2014r. opisujący kampanię poprzedniej wersji Emoteta.

Analiza oparta jest na próbce c53956c95100c5c0ba342977f8fc44fcad35aabc24ec44cb12bb83eee1ed34fa

Lista skrótów MD5 modułów (widoczne 13 kwietnia):

Lista adresów C&C

Klucz publiczny C&C:

Reguły Yara: