Nie próbujcie tego w domu: wyciągamy trojana Emotet na światło dzienne

Pierwszym krokiem jest, jak wiemy, dystrybucja rozpoczyna się od pliku z dokumentem programu Word 97-2003 (DOC). Plik ten jest rozsyłany mailem o dość sztampowej treści: faktura, zaliczka, zaległe dokumenty, notatka prasowa i tak dalej. Wbrew myśleniu życzeniowemu, większości biznesów nie da się prowadzić na białych listach adresów i zamkniętym pierścieniu zaufania. Skanery antywirusowe również są ślepe z definicji. Stąd też podejrzane maile z "fakturami" często nie lądują od razu w koszu.

Dokument ten zawiera makra. Teoretycznie, samo otwarcie dokumentu jest niegroźne. Pakiet Office domyślnie bowiem już od lat blokuje uruchamianie makr i wymaga ręcznego kliknięcia celem odblokowania. W praktyce jednak wcale nie oznacza to, że takie dokumenty możemy otwierać bezkarnie. Jest kilka powodów przeciwko:

• Nieostrożność: w otwartym dokumencie możemy po prostu... przypadkiem kliknąć przycisk odblokowania makr. Nikt nigdy nie kliknął czegoś podczas kichnięcia?
• Domyślne ustawienia Office są *domyślne, co znaczy, że można je zmienić. Lepiej nie polegać na przekonaniu, że \powinno być wyłączone\
• Połączenie z innymi dziurami. Makra może i są domyślnie wyłączone, ale np. dziura w Edytorze Równań(https://www.dobreprogramy.pl/17letni-blad-w-Office-naprawiony-na-binarce-Microsoft-zgubil-kod-zrodlowy,News,84304.html) wymagała jedynie otwarcia dokumentu.

Na potrzeby badania, dokument otworzyliśmy w załatanym, domyślnie zabezpieczonym pakiecie Office w maszynie wirtualnej*. Należy podkreślić, że maszyny wirtualne także nie są panaceum na niebezpieczeństwo, a bardziej szczegółowe wytłumaczenie znajduje się poniżej. Naturalnie, po otwarciu nic się nie wydarzyło. Dokument, wstawionym w stronę obrazkiem, informuje nas, że nasza kopia pakietu Office "musi zostać aktywowana". Istotnie, kopie Office 365 podczas logowania korporacyjnego lub po długim nieuruchamianiu "gubią" licencję i informują użytkownika o konieczności przelogowania się... zółtym paskiem o identycznej formie, jak alert o wyłączeniu makr. Zestawiając to z faktem, jak często strony internetowe przyzwyczajają nas do klikania na paski powiadomień (ciasteczka...), ryzyko kliknięcia wzrasta, z powodu nabytych, szkodliwych nawyków.

Do dokumentu podpięte jest makro, złożone z trzech modułów języka Visual Basic for Applications oraz z kilku samodzielnie zdefiniowanych pól-cech dokumentu. Kod VBA jest bardzo mocno zaciemniony, ale w sposób wskazujący na... ręczną robotę. Wiele elementów kodu jest powtórzonych, komentarze pochodzą z generatora wyrazów, ale zostały rozrzucone bez ładu i składu.

Kod ten jednak wcale nie jest olbrzymi. Jest to raptem kilkaset linii, które można samodzielnie odkręcić. Należy w tym celu usunąć linie z komentarzami oraz operacje na zmiennych nieużywanych nigdzie indziej. Prędko też okaże się, że niektóre fragmenty są po prostu przeklejone parokrotnie w kilku miejscach, tworząc zbędne pętle:

Cały ten bałagan można w zasadzie sprowadzić do kilku linijek VBA. Widać w nich dwie główne funkcje: tworzenie obiektu COM oraz jakaś substytucja łańcuchów tekstowych. Jak można jednak zaobserwować, źródła owych łańcuchów pochodzą z obiektów należących nie do makra, ale do głównego dokumentu. Są więc niewidoczne w edytorze makr, ale także niewidoczne w głównym dokumencie. Zostały prawdopodobnie dodane do dokumentu w sposób programowy:

W razie braku pomysłów na wydobycie zawartości powyższych zmiennych, zawsze można potraktować plik jak archiwum i po prostu rozłożyć go na strumienie. Doskonale w tym celu sprawdzi się 7-Zip, który przedstawi zawartość pliku DOC jako zbiór katalogów. Jednym z nich jest katalog "Objects", a w nim kilka podkatalogów. Każdy z nich jest przeznaczony na oddzielny obiekt i zawiera dwa meta-pliki: nazwę i zawartość. Znalezienie odpowiedniej nazwy pozwoli odkryć zserializowaną treść obiektu:

Tak, zapewne da się to zrobić mniej brutalnie. Ale to nie moment na przejmowanie się estetyką. Mamy wartości obiektów, które okazały się łańcuchami tekstowymi. Możemy ręcznie wywalić z nich wplecione tam dla zaciemnienia "67" i wtedy okaże się, że makro w bardzo skomplikowany sposób wywołuje polecenie "powershell -encodedcommand". Polecenie to uruchamia interpreter Windows PowerShell i od razu podaje mu polecenie do wykonania, zakodowane w postaci base64. Tutaj ciekawa uwaga na marginesie: domyślnie, Windows blokuje wykonywanie skryptów PowerShell. Dwuklik na pliku *.ps1 zakończy się błędem (ExecutionPolicy). Uruchomienie polecenia "powershell.exe mój_skrypt.ps1", uruchamiajace skrypt z Wiersza Poleceń, również nie zadziała.

Ale niniejsze makro nie uruchamia skryptu, a zakodowane polecenie (polecenia są kodowane w base64 po to, by łatwo przesłać przez powłokę łamańce z groźnymi symbolami, jak cudzysłów lub średnik). Aby usunąć taką możliwość, należałoby całkowicie wyłączyć Windows PowerShell, a tego system domyślnie nie robi. Być może powinien, aczkolwiek większość znanych mi wdrożeń korporacyjnych potrzebuje PowerShella i VSH na końcówkach. Więc może należałoby to domyślnie wyłączyć w wersji Home...?

Kod PowerShella jest przeplatany znakami niedrukowalnymi, symbolami Unicode i NULL-ami, przez co na pierwszy rzut oka w ogóle go nie przypomina. Wystarczy jednak usunąć zbędne symbole i odpowiednio połamać linie, by odkryć z czym mamy do czynienia.

Nieco porządków w kodzie i umieszczenie wcięć znacznie zwiększają czytelność. W ten sposób możemy dostrzec, że kod PowerShella, za pomocą klasy .NET Frameworka "Net.WebClient", usiłuje pobrać plik EXE z jednego z pięciu adresów, zapisać go pod nazwą "126.exe" w katalogu domowym i uruchomić. Skrypt sprawdza też, czy pobrany plik jest większy, niż 35609 bajtów. Nie jest to ślepa próba, mająca na celu zaciemnienie kodu. Otóż część serwerów serwujących wirusa jest dostarczana przez CloudFlare.

Pracują tam całkiem łebscy ludzie, którzy często samodzielnie wykrywają, że jakiś ich klient serwuje trojany. Wtedy, zamiast pliku EXE, CloudFlare wysyła "landing page", w postaci strony-blokady informującej, że prawdopodobnie zaraz pobierze się trojana. Strona ta ma 32 kilobajty, czyli mniej, niż sprawdzany warunek. Aby nie uruchomić pliku HTML jako EXE i nie narazić się na podejrzane okienko "126.exe nie jest prawidłową aplikacją Win32", zdradzające obecność trojana, skrypt sprawdza rozmiar pliku.

Czas dać się złapać w pułapkę i pobrać serwowanego trojana. O ile kampania jeszcze trwa. Serwery są ubijane na bieżąco, w większości bowiem (na co wskazuje URL) są to przejęte serwery WordPressa, a nie coś postawionego od zera celem siania chaosu. Tutaj bardzo pozytywnie zaskakują przeglądarki internetowe. Najnowszy Firefox ostrzega przed wejściem na część z adresów, informując o wysokim ryzyku. Ponadto, na stronach gdzie nie ostrzega, obecnie nawet bez antywirusa w systemie blokuje pliki EXE Emoteta, twierdząc, że to malware. Bardzo ładnie.

W końcu jednak udaje się pobrać plik. Jego nazwa jest za każdym razem inna, ale w każdym przypadku jest to ten sam plik wykonywalny o rozmiarze 342 kilobajtów. Jest bardzo dziwny. Zawiera ikonkę globusa, ma zdefiniowane UI i jest wręcz najeżony symbolami z Cygwina i MingW, co jest albo skomplikowanym zaciemnieniem, albo bardzo nietypową metodą kompilacji. Uruchomienie go w maszynie wirtualnej nie daje żadnych widocznych efektów. Więc teraz wspomnijmy trochę o tym, dlaczego maszyny wirualne nie są lekiem na całe zło w badaniu wirusów:

• Jeżeli hipernazdorca jest stary, a badany szkodnik jest naprawdę wredny, kod może \uciec\ z maszyny wirtualnej na zewnątrz. Były takie przypadki. Dlatego aktualizujmy VirtualBoksy!
• Korzystanie z uwspólnionych katalogów i przydzielenie nadmiernych uprawnień może pozwolić programom w VMcie siać spustoszenie na hoście. Ostrożnie z udostępnianiem katalogów i schowka.
• Jeżeli maszyna ma być wpięta do internetu (np. żeby zbadać co próbuje pobrać) i nie tworzymy na jej potrzeby dedykowanego, sztucznego internetu, niech przydzielony jej interfejs sieciowy będzie wyNAT-owany poza segment, w którym znajdują się pozostałe urządzenia. Szczególnie należy uważać na mostkowane połączenia, które przydzielają systemom-gościom adres IP z tej samej puli, co host
• twórcy trojanów dobrze wiedzą, że ich wynalazki są badane w maszynach wirtualnych i bardzo tego nie lubią. Dlatego ich kod nie tylko potrafi wykryć VM i wtedy siedzieć cicho. Usiłuje też wykraść poświadczenia z maszyny wirtualnej. Dlatego poza uniemożliwieniem routowania maszyny do sieci systemu-hosta, należy w maszynie stosować inne nazwy użytkownika i hasła, niż na hoście. Emotet robi użytek właśnie z nich! Zastosowanie tej samej nazwy użytkownika i hasła w maszynie i na hoście, przy zmostkowaniu połączeń sprawi, że trojan nic nie zrobi w maszynie. Uda się bowiem na hosta!

Koniecznie należy podkreślić, że stosowanie maszyn wirtualnych nie znaczy, że jesteśmy chronieni. Nie uda się całkowicie zlikwidować ryzyka podczas badania złośliwego oprogramowania. Nie warto się dręczyć, że nie wpadło się na jakąś metodę potencjalnej mitygacji zagrożeń. Twórcy trojanów oszustwami zarabiają na życie, to ich chleb powszechni. Nie wolno o tym zapomnieć.

Gdy podstawowa wiedza z zakresu debugowania i okna programu OllyDBG prowadzą na manowce, warto skorzystać z pomocy stron trzecich. Wirtyna Reverse.it świadczy usługę analizy podsyłanych im programów EXE oraz umożliwia podgląd działania programu w piaskownicy zaopatrzonej w maskowanie pracy w maszynie witualnej. Gdy VirusTotal informuje, że wirusa zna dopiero tylko 8 silników, istnieje szansa, że poznaliśmy coś nowego.

Czego dowiadujemy się z analizy? Według silnika Falcon, nasza próbka:

• Maskuje pobieranie innych plików poprzez przenoszenie się z katalogu do katalogu
• Zawiera w sobie drugi, mniejszy plik EXE (CHOREPINK)
• Odpytuje BIOS o typ procesora (wykrywanie maszyny wirtualnej)
• Wyszukuje poświadczenie logowania w systemie
• Rejestruje się jako kernel debugger

Każde z tych zachowań jest wysoce podejrzane. Ciekawsze jest jednak, że program nic poza tym nie zrobił. Więc albo wykrył maszynę wirtualną, albo środowisko nie spełniło kryteriów. Bowiem program nawet nie próbuje się łączyć z internetem. Jest jednak kandydatem do odstrzału. Co zatem pozostało nam zrobić? Ano przydać się. Tak wyłuskane kody wirusa przydaje się zgłosić do działu Microsoft Security Intelligence, celem opracowania definicji. Obecnie Windows Defender poprawnie wykrywa zarówno dokument DOC, jak i docelowy EXE.

Interesującym pozostaje, że dostarczane pliki DOC są bardzo podobne, ale końcowe pliki EXE z trojanem są bardzo odmienne. Ponieważ stworzenie wielu wariantów trojana jest znacznie droższe, niż opracowanie złośliwego DOCX i kampania mailowa, obecność nowych wersji świadczy o nieustającej opłacalności przestępczej inicjatywy.