Makrowirusy: nowości w rozwoju złośliwych dokumentów

Mimo bycia łatwym do uniknięcia zagrożeniem, makrowirusy wciąż ewoluują, utrudniając wykrycie przez oprogramowanie antywirusowe. Ale ich rozwój odbywa się także na innym polu: najnowsze kampanie wykorzystujące złośliwe dokumenty Office wprowadziły modyfikacje utrudniające badanie ich za pomocą narzędzi ekstrahujących makra. Oznacza to, że przestępcy chcą nie tylko ominąć antywirusy. Chcą także utrudnić życie specjalistom do spraw bezpieczeństwa, badającym ich payload.

Niestety, archaiczna struktura środowiska edycji makr oferuje wiele możliwości na tym polu. Stosowany w pakiecie Office edytor VBA to (także najnowszej wersji) zaadaptowana wersja programu Visual Studio 98. Pochodzi on z czasów, w których konieczne było zachowanie zgodności z systemem Windows 95. W konsekwencji, makra nie są dziś zapisywane w czytelnym formacie XML skompresowanym do archiwum ZIP (tym właśnie jest plik DOCX). Zamiast tego stosowane są strumienie OLE2. Są one nie tylko binarne, ale także niezgodne z Unicode.

Nie można ich zatem "po prostu wyciągnąć" z dokumentu, konieczne jest użycie dedykowanych narzędzi. Standardowym rozwiązaniem jest tutaj wykorzystanie języka Python oraz pakietu oletools. Niestety, w przypadku nowych wirusów, oletools napotyka na problemy. Ze względu na kodowanie znaków niezgodne z Unicode, Python podczas pracy musi przetwarzać symbole prowadzące do awarii.

Wyprowadzanie wyjścia do pliku kończy się jego "urwaniem" przed kluczowym momentem, a wyprowadzenie na ekran obarczone jest inną, zabawniejszą wadą. Zachodzi rozbieżność w kodowaniu między Pythonem, oknem Wiersza Poleceń, strumieniem OLE, Edytorem Visual Basic a systemem operacyjnym.

Z tego powodu, oletools nie umie rozpakować fragmentu kodu składającego złośliwe działanie: uruchomienie funkcji konwertującej string o nietypowym kodowaniu na polecenie Windows. Statyczna analiza pliku nie pozwala więc wyciągnąć wywołania MSHTA pobierającego blog BlogSpota ze złośliwym skryptem Visual Basic, do którego dostęp jest uzyskiwany przez skracacz linków Bitly.

Ten ostatni etap był już stosowany w poprzednich kampaniach rozsyłających pakiet Agent Tesla. Stosowały one także sztuczkę z pobieraniem payloadu wirusa z archiwum archive.org. Tak jest i tym razem, natomiast kampania wydaje się być o wiele bardziej zgodna z modelem "trojan na żądanie": istnieje o wiele więcej wariantów złośliwego kodu, a wewnątrz składanych plików wykonywalnych znajdują się adresy IP z unikatowym URL-em. Najwyraźniej każda kampania ma "raportować" postęp pod inny adres.

Kod jest oczywiście niewykrywany przez oprogramowanie antywirusowe i nie zmieniło się to nawet po kilku dniach. Tym razem najwyraźniej nie jest to Agent Tesla, a złodziej poświadczeń przechowywanych w menedżerze haseł Google Chrome (i Edge). Próba dostępu do pęku kluczy Chrome'a przez program inny niż sam Chrome powinna wywołać detekcję behawioralną. Dzieje się tak rzadziej niż byśmy chcieli.

Do grona programów składających pobierany payload dołączył kompilator wstępny ASP.NET 4, czyli aspnet_compiler.exe. Narzędzia ASP.NET są dostępne w systemie także wtedy, gdy nie działa w nim serwer IIS i są niemożliwe do odinstalowania.

Podobnie, jak w przypadku poprzednich kampanii, wyłączenie makr uniemożliwi infekcję. Gdy makra są jednak potrzebne i zostaną nieopatrznie uruchomione na złośliwym pliku, przed atakiem uchroni nas powstrzymanie z użyciem systemowej zapory dostępu do internetu dla programu MSHTA.EXE.