Evil: prosty ransomware, napisany w języku JavaScript

Wstęp

Evil jest nową odmianą ransomware, którą pierwszy raz zaobserwowaliśmy ósmego stycznia 2017 roku – wtedy został nam zgłoszony pierwszy incydent z nią związany. Było to wtedy zupełnie nowe zagrożenie i nie było na jego temat żadnych informacji dostępnych publicznie. Nie mieliśmy też żadnych próbek do analizy.

Pierwszą działającą próbkę zdobyliśmy dzień później, dziewiątego stycznia. W tym artykule opiszemy w skrócie naszą analizę i wnioski. Od tamtej porty dostaliśmy relatywnie dużo raportów o infekcji, więc istnieje ryzyko, że ta rodzina stanie się większym zagrożeniem w przyszłości.

Evil nie ma żadnego panelu służącego do deszyfrowania (podobnie jak np. CryptoMix) – zamiast tego dostarczany jest adres email twórców, pod który należy się skontaktować.

Obfuskacja

Świat się zmienia, a Evil poszedł z duchem czasu. Jest on napisany w 100% w języku JavaScript. Nie jest to przełomowe (robił to np. Ransom32 pół roku temu), ale na pewno nietypowe. Czy javascriptowe malware jest przyszłością? Nie wiemy, chociaż na pewno upraszacza nam to analizę.

Jako że niektóre rzeczy trudno zrobić za pomocą samego JavaScriptu, twórcy malware uciekli się do użycia zewnętrznych programów. Obraz jest wart tysiąc słów, więc spójrzmy na drzewo procesów:

Jak widzimy, najpierw usuwane są wszystkie pliki wykonywalne z folderów %TEMP% i %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup.

Prawdopodobnie dzieje się tak, żeby utrudnić analizę i odnalezienie działającej próbki programu, a także żeby przy okazji usunąć inne złośliwe programy zainstalowane na komputerze użytkownika.

Następnie poleceniem dir /b /s /x generowana jest lista plików, które zostaną zaszyfrowane przy użyciu tajemniczo nazwanego programu 443.exe. Ten proces okazał się być AESCryptem – pisanie własnego szyfrowania od zera jest trudne, więc przestępcy coraz częściej uciekają się do korzystania z gotowych rozwiązań. Ostatecznie, pokazywana jest wiadomość z żądaniem okupu (przy użyciu domyślnej przeglądarki).

Na tym etapie analizy jedynym pytaniem, na które nie znamy jeszcze odpowiedzi, to sposób generacji klucza deszyfrującego. Oczywistym się wydaje, że słabe generowanie klucza mogłoby nam pozwolić odzyskać zaszyfrowane dane.

Kod jest mocno obfuskowany, więc nie możemy zacząć analizować go od razu. Przykład takiego kodu:

Na szczęście używając zmodyfikowanego skryptu, którym dzieliliśmy się we wcześniejszym artykule: https://www.cert.pl/news/single/newest-addition-a-happy-family-kbot/, można uzyskać w miarę czytelny kod.

Zasadniczo wszystko zgadza się z tym co wydedukowaliśmy z samego drzewa procesów:

• Usuwanie plików z folderów:

• Generowanie listy plików:

• Trochę zabezpieczeń przed degugowaniem

Jak zwykle, trzymanie procesu nazwanego VBoxService w tle okazuje się dobrym sposobem na uchronienie komputera przed infekcją.

• Generacja klucza

W końcu interesująca część, generowanie klucza i szyfrowanie:

Niestety – wygląda na to, że klucz nie jest w ogóle generowany po stronie klienta, a wysyłany z serwera (w nagłówku X-Token). To problematyczne, ponieważ nie ma przez to żadnego sposobu na jego przewidzenie.

• Czyszczenie po sobie

Ostatecznie pokazywane jest żądanie okupu i ponownie usuwane są wszystkie pliki z %TEMP%.

Inne informacje:

Hash próbki: 1817853fdaf2d35988ca22a6db2c939e0f56664576593d325cfd67d24e8fb75c

Adres email: [email protected]

Szyfrowane rozszerzenia:

Rozszerzenie po zaszyfrowaniu: .file0locked

Żądanie okupu: