Office i wirusy: polowanie na botnet (Część I)

Nowe trojany wykorzystujące pakiet Office korzystają ze starych sztuczek, ale są coraz trudniej wykrywalne i coraz mocniej zaciemnione. Antywirusy są na nie ślepe, choć po tak wielu latach już nie powinny.

Lata mijają, a dokumenty Microsoft Office rozsyłane w załącznikach pozostają jedną z najpopularniejszych metod rozpowszechniania wirusów. Producent pakietu reagował na to zagrożenie bardzo opieszale, ale ostatnie miesiące obfitowały w wartościowe zmiany na tym polu. Nowy Office domyślnie nie uruchamia makr, usunięto z niego w ogóle obsługę makro-formuł Excel 4.0, systemowy Windows Defender może zostać ustawiony tak, by blokował Office'a przed uruchamianiem procesów potomnych.

Kroki te na pewno zredukują popularność (i skuteczność) kampanii malware'owych wykorzystujących Office'a. Można jednak mieć wątpliwości, czy doprowadzą do tego… w Polsce. Kolejne przykłady złośliwych załączników pokazują, że kampanie celujące w nasz kraj przestają się opierać na makrach. Zamiast tego wykorzystują podatności w samym pakiecie. Dzięki temu nie jest konieczne uruchamianie makr. Aby wykonać złośliwy kod, wystarczy otworzyć dokument lub wyświetlić jego miniaturę.

Sęk w tym, że wykorzystywane podatności… dawno załatano. Dotyczą one parsowania obiektów OLE lub wyświetlania elementów Edytora Równań. Są to dziury z 2019 i 2017 roku. Złośliwe pliki są zapisane w formacie DOCX, a od 2010 roku, z czasem coraz dobitniej, Microsoft forsował przejście na subskrypcyjne wersje Office'a aktualizujące się samodzielnie.

Każe to wysnuć pewną hipotezę: celem dla wirusów office'owych jest niezałatany pakiet Microsoft Office 2007 Enterprise. Popularny w Polsce u użytkowników nieposiadających licencji. Była to bowiem ostatnia wersja pakietu niewymagająca aktywacji. Jej użytkownicy często, w obawie przed wykryciem, nie włączają aktualizacji automatycznych pakietu, a ta wersja nie robiła tego jeszcze automatycznie.

Warto wspomnieć tu przy okazji, że aktualizowanie "lewego" pakietu Office 2007 nie prowadzi do oznaczenia go jako "nielegalny". Dlatego przydałoby się go jednak zaktualizować.

Jedna z najnowszych kampanii wykorzystuje antyczną, pięcioletnią podatność CVE-2017-0199, dawno załataną przez Microsoft, także w wersji 2007 pakietu. Dotyczy ona zagnieżdżania obiektów OLE w dokumentach wewnątrz dokumentów Office (DOCX z OLE wewnątrz innego DOCX).

Otrzymywany mailowo dokument, w dniu premiery wykrywany przez 3 antywirusy, dziś wciąż jest wykrywany tylko przez 18 i wśród nich nie ma Defendera. A więc oprogramowanie antywirusowe nie potrafi wykryć zniekształconego dokumentu, wykorzystującego pięcioletnią dziurę.

Złośliwy element OLE LinkInfo służy do pobrania "pliku doc", który tak naprawdę jest dokumentem HTA. Dokument ten wciąż nie jest właściwym wirusem, a jedynie kolejnym downloaderem, przeznaczonym do pobrania kolejnej części malware'u. Tym razem jednak to nie MSHTA.EXE połączy się z siecią by pobrać tego wirusa. Zrobi to WSH, którego złośliwy plik HTA uruchamia celem uruchomienia… PowerShella i to dopiero on łączy się z internetem.

Ciąg dalszy wirusa ściągany jest z Pastebina. Wklejarka Pastebin usuwa wirusy, złośliwe linki i inne nielegalne treści, robi to automatycznie, ale tutaj nie wykryła żadnego wirusa. Pobierany kod jest bowiem zaciemniony. Bardzo, bardzo zaciemniony. Wygląda następująco:

Ten kompletny z pozoru chaos jest całkowicie poprawnym kodem języka PowerShell. Nie zawiera on żadnych błędów ani ignorowanych przez parser elementów. Stosuje jedynie sztuczkę będącą koszmarem antywirusów: olbrzymią wyrozumiałość w nazywaniu zmiennych. Tak długo, jak nazwa zmiennej znajduje się w klamerkach obok dolara, można w nią władować niemal wszystko. Toteż są tu zmienne o nazwie tylda-średnik-nawias-nawias-gwiazdka i temu podobne.

Uważne oko dostrzeże jednak, że plik jest podzielony na dwie części, oddzielone od siebie zmieniającym kolor reszty średnikiem. Wniosek jest prosty: wszystko powyżej średnika to translator, a wszystko poniżej - payload. Spróbujmy zatem odkręcić translator. Zmiana nazw zmiennych na sensowne sprawia, że proces ten wcale nie jest trudny.

Widać teraz, że druga część pliku z Pastebina to istotnie payload, w postaci ciągu liczb całkowitych które trzeba zrzutować na symbole alfanumeryczne. W ten sposób uzyskamy prawdziwy kształt skryptu zaciemnionego górą śmieciowych znaków. Po rozmiarze widać, że nie będzie to nic binarnego, a jedynie mocno spuchnięty skrypt, wykonywany jako string przez Invoke-Expression. Niemniej, efekt translacji jest… nieco zdumiewający.

O tym, co ujrzeliśmy po przetłumaczeniu skryptu z cyferek na kod i dlaczego nas to zaskoczyło - już jutro!