Najnowsze usprawnienia w dostarczaniu wirusów. Ciekawe, ale łatwe do powstrzymania

Obecność kampanii malware stosujących ten wektor ataku sugeruje, że mimo swojej prostoty, pozostają opłacalne dla przestępców. Oznacza to, że użytkownicy są niewyuczalni. I choć nikt nie uruchamia szkodliwego oprogramowania dla zabawy, w niektórych scenariuszach lepiej polegać na antywirusach, niż na edukacji. Niestety, programy AV kiepsko radzą sobie z rozpoznawaniem nowych zagrożeń, ale powoli uczą się definicji behawioralnych, blokujących np. wywołanie PowerShella z Worda. Dlatego przestępcy również muszą się wykazać pewną dozą kreatywności. Oto kilka najnowszych pomysłów.

Podsyłana wiadomość wciąż dotyczy rzekomych "faktur", "umów" i podobnych ogólnie opisanych "dokumentów", ale zaczęła zawierać kilka nowych elementów. Przede wszystkim w stopce wiadomości znajduje się fraza "Wysłane ze smartfona Samsung Galaxy". Wiele skanerów antyspamowych nauczyło się, że wiadomości z podobnymi stopkami pochodzą od zaufanych osób, dzięki czemu taka wiadomość ma odrobinę mniejszą szansę wylądować od razu w spamie.

Nagłówki dalej są częściowo sfałszowane i choć da się w nich wyczytać takie bzdury jak to, że źródłem wiadomości jest Kazachstan, a nadawcą – firma wyciągnięta z rejestru KRS, to kilka nowych nagłówków pełni nieco inną rolę. Sekcja "X-SpamExperts" ma na celu udawanie, że niniejszy mail został przekazany dalej przez jednego z uczestników rozmowy i w swojej podróży zagościł na serwerach zaopatrzonych w filtr antyspamowy. Tenże filtr miałby odpowiadać za oszacowanie "reputacji" maila, która to – co oczywiste – jest rzekomo "wysoka".

Do wiadomości załączono zwyczajowy dokument Worda, ale i tutaj pojawiły się modyfikacje. Plik ma rozszerzenie DOC, więc skanery oczekują pliku binarnego. Poprzednią sztuczką było nazywanie plików DOCX rozszerzeniem DOC, aby skaner nie próbował ich otworzyć i analizować (pliki DOCX to tak naprawdę archiwum ZIP). Tym razem wewnątrz kryje się plik... RTF, który jest plikiem tekstowym. Rozszerzenie się nie zgadza, ale plik wewnątrz nie jest ani binarny ani skompresowany, więc skanery dają mu spokój. Tymczasem w środku dokumentu znajduje się binarny blob, ale inny.

Pliki RTF nie mogą zawierać makr, więc są bezpieczne, prawda? Można je otworzyć bez problemu... Otóż nie do końca. Nie działa to na każdej wersji pakietu Office (starsze wersje nie ładują wszystkich komponentów od razu, a załatane wersje nowych nie dają się nabrać), ale można tu wykonać pewien złośliwy trik. Owszem, makra odpadają. Ale RTF obsługuje... OLE! Możliwe jest wbudowanie w dokument dowolnego komponentu zgodnego z COM, a takim komponentem jest na przykład arkusz Microsoft Excel. Z makrami. Przed którymi ochrona może być wyłączona, bo przecież otworzyliśmy plik RTF.

Ten wysoce bezczelny zabieg sprawia, że możliwe jest załadowanie makr bez klikania w żółtą belkę informacyjną o zablokowanej treści. Oczywiście, wewnętrzne makro również uległo modyfikacjom. Przede wszystkim składa się z pięciu modułów, korzystających z łańcuchów tekstowych będących cechami arkusza. Co to oznacza? Otóż aby teraz odkręcić wysoce zaciemniony kod makra, nie wystarczy rozpracować jednego pliku, a pięć. Nie trwa to jeszcze pięciokrotnie dłużej, ale jest zauważalnie bardziej męczące.

W końcu jednak udaje się dotrzeć do właściwej postaci makra. Jak zwykle, jest to stary, dobry downloader, pobierający plik z dziwnych zakamarków sieci. Język VBA nie pozwala na pobieranie plików bezpośrednio. Możliwe jest jednak zawołanie ActiveX i poproszenie o to przeglądarki Internet Explorer. Ta jednak, już w czasach dawnego Office 2003, domyślnie ustawia tak wysoką strefę zabezpieczeń dla takich scenariuszy wywołania, że uruchomienie pobranego pliku EXE jest niemożliwe. Pozostaje więc sprawdzony PowerShell.

On jednak domyślnie również zakazuje uruchamiania niepodpisanych skryptów, więc zamiast tego cały skrypt jest podawany jako parametr wiersza poleceń do programu powershell.exe. W środowiskach zautomatyzowanego CI/CD jest to przepiękna funkcja pozwalająca ominąć problemy z kodowaniem znaków. W tym scenariuszu jest jednak mocno złowroga, bo nie służy niczemu korzystnemu. Co więcej, domyślne zasady grupy, umożliwiające wyłączenie Wiersza Poleceń, Interpretera PowerShell i uruchamiania niepodpisanych skryptów, nawet ustawione w najbezpieczniejszy sposób nie chronią przed takim uruchomieniem kodu. Należy zakazać użytkownikowi uruchamiania programu powershell.exe w całości.

Nawet tak ukryty PowerShell został usprawniony i mocniej zaciemniony. Wykorzystuje on w swoim kodzie... drukarskie cudzysłowy. Przyznam szczerze, nie sądziłem, że to w ogóle możliwe. Jak się okazuje, drukarski cudzysłów jest rozumiany przez interpreter PowerShell i niejawnie rozkładany na ten zwykły, obecny na klawiaturze. Co gorsza, skopiowanie takiego cudzysłowu z okna PowerShell również skutkuje jego rozłożeniem na zwykły (niektóre symbole reagują tak tylko raz). Oto szybka metoda sprawdzenia, które cudzysłowy są poprawnie rozumiane przez PowerShell:

Umyka mi zasadność takiego rozwiązania, ale wyprowadza to w pole analizator składni IntelliSense, więc całkiem możliwe, że skanery antywirusowe również dadzą sobie spokój z takimi symbolami. Niemniej, dokonywanie takich odkryć nieco odbiera mowę...

Ostatnim krokiem jest pobranie właściwego wirusa (pliku binernego) do systemu i uruchomienie go. W kwestii samego kodu, jest to tak samo mocno zaciemniony twór, jak poprzednie Danabot, Emotet i Ursnif. Nie ma tu zbyt wiele nowego do powiedzenia. Oprogramowanie antywirusowe ich nie rozpoznaje, kod rejestruje się w systemie jako biblioteka dynamiczna za pomocą RUNDLL32 i czeka na rozkazy z zewnątrz. Zmieniła się jednak metoda dostarczania go.

Zawirusowane instancje WordPressa (wp-admin...) i serwery HTTP na niestandardowych portach, odpowiadające czystym tekstem, stosowane w poprzednich wariantach kampanii, stały się na tyle wykrywalne przez urządzenia bezpieczeństwa sieciowego, że serwowanie wirusów tymi kanałami przestało być skuteczne. Dlatego obecnie wirusy są dostarczane za pomocą małych dysków chmurowych i usług tymczasowego udostępniania małych plików. Adres URL w odszyfrowanym skrypcie wskazuje na "skracacz" adresów bit.ly, który z kolei wysyła nas do skromnego uploadera plików dla "osób ceniących prywatność".

Poproszenie o (rzekomy) plik tekstowy poskutkuje otrzymaniem pliku o innej nazwie, również rzekomo tekstowego, a w praktyce binarnego. Co ciekawe, dostawca dysku (put.re) oferuje plik informując, że jest tekstowy, czyli sądzi po rozszerzeniu, a nie na podstawie typu MIME. Nieładnie. W ten sposób w logach sieciowych nie pojawia się informacja o próbie pobrania pliku binarnego.

Jest jednak kilka dobrych wiadomości. Operator dysku zdjął plik po zgłoszeniu, że nie jest to żaden dokument tekstowy, a wirus Fuerboos.C. Paradoskalnie, więksi dostawcy reagowaliby znacznie wolniej na takie przejawy złowrogiej działalności, aczkolwiek np. taki OneDrive automatycznie blokuje linki udostępniania serwujące wirusy, jeżeli wykryje je ichniejszy Defender. Jeżeli jesteśmy w stanie zgłosić operatorowi, że link prowadzi do wirusa, warto to zrobić, żeby pomóc w zwalczaniu kampanii. Myślenie "dobrze im tak" jest krótkowzroczne. Często straty wskutek takich wirusów ponoszą ludzie przypadkowi, którzy niewiele mieli wspólnego z otwieraniem podejrzanych wiadomości.

Wykrywanie linków do złośliwego oprogramowania okazuje się jednak coraz trudniejsze. Najnowsza wersja kampanii stosuje zaciemnienie tak silne, że próby usuwania go celem odkrycia linków trwałyby długie godziny. O wiele łatwiej jest zrobić coś innego: skorzystać ze znacznie mniejszych możliwości zaciemniania kodu VBA względem PowerShella. O ile ten drugi pozwala składać kod z drukarskich cudzysłowów, VBA jest jedynie niezwykle męczący i dokonuje długich podróży po zmiennych i substytucjach.

Dlatego zawsze gdzieś w głębi kodu makra znajduje się czysta, niezaciemniona funkcja "Shell" lub "Application.ShellExecute". Zastąpienie jej wywołania zapisaniem parametrów do pliku pozwoli odkryć, co tak naprawdę makro próbuje uruchomić. Należy tu zwrócić uwagę na to, że lepiej zapisać treść do pliku, niż wyświetlić ją na ekranie, ponieważ skomplikowany kod VBA pod koniec pracy doprowadza do zawieszenia Worda, żeby nie dało się skopiować do schowka efektów badania. Zapis do pliku sprawdzi się, ponieważ nastąpi chwilę przed zawieszeniem edytora.

Co zrobić, by się ochronić? Jak zwykle, przede wszystkim "nie brać cukierków od obcych" i nie uruchamiać dokumentów znikąd. Jeżeli jednak odpowiadamy za zabezpieczenie stacji roboczych, to mogą nam pomóc następujące wnioski ze zaktualizowanej wersji kampanii:

Aktualizować nie tylko Windows, ale i Office, bowiem w 2017 roku wykryto sporo metod uruchomienia złośliwego kodu od samego tylko wyświetlenia dokumentu Worda Jeżeli PowerShell jest potrzebny, umożliwić jego uruchamianie jedynie skryptom administracyjnym (uruchamianym "jako komputer") i serwisowym administratorom. Jeśli pracownicy nie są np. programistami, należy przypiąć do kontenera w którym się znajdują zasadę grupy zabraniającą uruchamiania wszystkiego, co się nazywa "powershell.exe" Dodać rosyjski układ klawiatury do listy układów (i wyłączyć skrót klawiaturowy pozwalający na jego zmianę. Skrypt sprawdzał obecność owego układu u użytkownika i grzecznie kończył pracę, gdy go znalazł!

Nie ma wątpliwości, że nadchodzące warianty będą jeszcze bardziej męczące pod względem swojej złożoności. Na szczęście przed większością zagrożeń owej klasy wciąż skutecznie chroni zdrowa nieufność.