Automatyzacja analizy złośliwego oprogramowania

Istotnym elementem, który ma wpływ na analizę złośliwego oprogramowania jest czas. Chodzi o to aby w jak najkrótszym czasie zidentyfikować funkcje pliku wykonywalnego/biblioteki. W przypadku złośliwego oprogramowania, którego celem jest infekcja stacji roboczych klientów banków przede wszystkim należy sprawdzić, klienci których banków są celem. Dla pracowników banków z kolei ważne jest w jaki sposób następuje kradzież środków, gdyż można próbować modyfikować mechanizmy wykrywające infekcje (np. kod javascript uruchamiany w kontekście sesji przeglądarki www z systemem bankowości internetowej, który ma wykryć malware, utrudnić „wstrzyknięcie” złośliwego kodu, uniemożliwić podmianę rachunku w schowku, i tak dalej).

Poniżej opiszemy jak uzyskać część z w/w informacji w sposób bardziej zautomatyzowany.

Z roku na rok zauważamy wzrost złośliwego oprogramowania, które przeznaczone jest dla 64 bitowego systemu operacyjnego. Zajmiemy się  plikiem, który jest wykrywany przez część z programów AV jako EMOTET (niektóre komponenty działają wyłącznie na 64 bitowym systemie operacyjnym). Dodatkowo twórcy malware w celu utrudnienia analizy szyfrują komunikację pomiędzy zainfekowaną stacją roboczą a serwerami C&C.

Pod koniec ubiegłego roku na jednej z konferencji w Warszawie pokazywaliśmy jak monitorować/modyfikować działanie malware za pomocą pakietu Microsoft Detours. Pakiet ten ma jedną wadę – wersja 64 bitowa jest płatna.

Jest co najmniej kilka rozwiązań, które mogą być alternatywą dla Detours włączając również Microsoft Debugging Tools. My dzisiaj opiszemy bibliotekę MinHook.

Zasada działania MinHook jest taka sama jak biblioteki Detours. Nadpisywane są pierwsze instrukcje funkcji które chcemy monitorować lub modyfikować (ang. „hooking”). Początek funkcji nadpisywany jest instrukcją JMP i wskazuje na nasz kod.

Na podanej poniżej stronie umieściliśmy szablon biblioteki, którą będziemy wstrzykiwali w proces, który chcemy monitorować. Należy również pobrać skompilowana wersję lub kod źródłowy biblioteki MinHook.

Dodawanie funkcji, którą chcemy monitorować składa się z kilku kroków:

•  Deklarujemy i tworzymy wskaźnik do oryginalnej funkcji:

typedef int(WINAPI *CRYPTDECRYPT)(HCRYPTKEY hKey, HCRYPTHASH hHash, BOOL Final, DWORD dwFlags, BYTE *pbData, DWORD *pdwDataLen);
CRYPTDECRYPT fpcryptdecrypt = NULL;

• Definiujemy funkcję, która zostanie wywołana zamiast oryginalnej funkcji:

int WINAPI Prevenitycryptdecrypt(HCRYPTKEY hKey, HCRYPTHASH hHash, BOOL Final, DWORD dwFlags, BYTE *pbData, DWORD *pdwDataLen)
{
    LoggerW(L"CryptDecrypt call");
    WriteToLogFile("Before CryptDecrypt call: ",pbData, rozmiar);
    dane = fpcryptdecrypt(hKey, hHash, Final, dwFlags, pbData, pdwDataLen);
    WriteToLogFile("After CryptDecrypt call: ",pbData, rozmiar);
    return dane;
}

WriteToLogFile() to kolejna przygotowana przez nas funkcja. Jej celem jest zapisywanie istotnych informacji dot. przechwytywanych funkcji. Czasami warto funkcję WriteToLogFile() wywołać dwa razy (przed wywołaniem oryginalnej funkcji i po jej wywołaniu - tutaj przykład z funkcją CryptDecrypt() wykorzystywaną przez analizowany malware).

pbData[in, out] to wskaźnik do bufora zawierającego dane do odszyfrowania co oznacza że zapiszemy w pliku dane przed odszyfrowaniem i po odszyfrowaniu.

•  Odczytujemy i zapisujemy adres funkcji, która będziemy modyfikowali:

LPVOID pcryptdecrypt = NULL;
pcryptdecrypt = GetProcAddress(GetModuleHandleA("Advapi32.dll"), "CryptDecrypt");

•  Wywołujemy MH_CreateHook(), która modyfikuje funkcję ale jeszcze nie aktywuje jej:

 MH_CreateHookEx(pcryptdecrypt, &Prevenitycryptdecrypt, &fpcryptdecrypt);

•  Włączamy wszystkie modyfikacje:

 MH_EnableHook(MH_ALL_HOOKS);

Analogicznie powtarzamy punkty 1-4 dla innych funkcji, które pozwolą nam zidentyfikować zachowanie złośliwego oprogramowania. Aby sprawdzać co jest wysyłane i odbierane przez analizowany malware przechwycimy 3 funkcje:

• CryptDecrypt()
• CryptEncrypt()
• CrypthashData()

Po kompilacji otrzymany bibliotekę, którą musimy wstrzyknąć do procesu ze złośliwym kodem. W tym konkretnym przypadku malware wstrzykuje złośliwy kod do procesu explorer.exe. Dostępny na podanej poniżej stronie szablon zawiera drugi projekt simple_injector. Jest to aplikacja która wstrzykuje bibliotekę mh_template.dll do wskazanego procesu. Wyniki działania funkcji WriteToLogFile() będą zapisywane w lokalizacji C:\Prevenity.

Uruchamiamy program, który załaduje bibliotekę do wskazanego procesu:

C:\simple_injector.exe
Podaj PID: 1148
Injecting DLL to PID: 1148

Sprawdzamy, czy w przestrzeni adresowej znajduje się nasza biblioteka.

 

Poniżej fragment szyfrowanej komunikacji pomiędzy malware a serwerami C&C.

 Poniżej fragment pliku z odszyfrowaną komunikacją:

•  Wysyłane dane przez malware przed zaszyfrowaniem:

•  Odebrana i odszyfrowana komunikacja z serwera C&C:

Analizowany malware co kilka minut pobierał nową konfigurację. Oprócz nazw banków, skryptów, serwerów C&C znajdowały się również adresy polskich serwerów na których umieszczone jest złośliwe oprogramowanie.

Źródła:
[1] https://github.com/TsudaKageyu/minhook
[2] https://github.com/Prevenity/malware_monitor
[3] MD5: BBB080336BC3BFA054D9C8491DB5E2D4
[4] http://research.microsoft.com/en-us/projects/detours/