Danabot i Emotet mają nowego kolegę. Zaktualizowano kampanię rozsyłania wirusów

Ostatnie tygodnie dostarczają szeregu nowych wrażeń związanych ze złośliwym oprogramowaniem, również w tym całkowicie klasycznym wydaniu w postaci wirusów na system Windows. Trojan Emotet, mimo dość "antycznej" metody infekcji, jaką jest ręczne uruchomienie makr w dokumencie Microsoft Word, okazał się zbierać spore żniwo. W dodatku czyni to kolejny raz, bowiem w najnowszej kampanii używał cytatów z poczty wysłanej przez poprzednie ofiary kilka miesięcy wcześniej. Oznacza to, że stare metody wciąż są najlepsze i na tyle opłacalne, że kampanie są odświeżane.

Łatwo przy tym o błędny wniosek, że infrastruktura dystrybucji pozostaje zatem identyczna. Tak jednak nie jest: ruch sieciowy generowany przez pierwszy etap infekcji jest prosty, ale charakterystyczny. Dlatego zmiany, które wystarczy w nim wprowadzić, by nie łapał się w filtry, również są proste. Stąd też najnowszy wariant rozsyła się nieco inaczej. Prześledźmy zmiany wprowadzone ostatnio do łańcucha dostaw.

Pierwszym krokiem niezmiennie pozostaje adres e-mail z załącznikiem. Jest on dostosowany do polskich realiów: każda wiadomość ma w stopce prawdziwe dane losowo wybranej firmy z Krajowego Rejestru Sądowego. Są one jednak dość niekonsekwentne: podpis różni się od nazwiska w polu nadawcy wiadomości. Nie zgadza się także domena. W dalszym ciągu nagłówek nie jest fałszowany prawdziwą nazwą firmy i wiadomość wychodzi z maila z podstawionej domeny. Tym razem zarejestrowano ją dziesiątego września i obecnie wskazuje ona na fizyczny serwer w Rosji. Jedyną różnicą-awansem względem poprzednich kampanii jest użycie formatu XZ do skompresowania załącznika. Wcześniej stosowano ZIP lub RAR.

Wewnątrz znajduje się skrypt narzędzia Visual Basic Script o rozszerzeniu VBE, wskazującym na "zaszyfrowany skrypt". Skrypt ten nie jest jednak zaszyfrowany, a jedynie mocno zaciemniony: składa się z ponad 40 tysięcy linii, z czego większość to puste znaki. Inwokacją jest 15-linijkowy komentarz, będący wyciągiem z Wikipedii na temat Kanału Panamskiego. Mimo, że zaciemnienie przeprowadzono ręcznie, poza powyższymi zmianami wprowadzono szereg ulepszeń. Oto one:

• Skrypt okresowo w pętli odpytuje domeny Bing, Live i MSN - zupełnie, jak np. systemowy kafelek z Pogodą.
• Skrypt zakończy pracę, jeżeli znajdzie na dysku plik C:\WINDOWS\isolate.ini (bardzo ciekawy trop!)
• Podobnie, jak w poprzednich kampaniach, skrypt pobiera stronę internetową i wykonuje odpowiedź jako kod, ale tym razem nie dokonuje prostego odpytania, a składa żądanie HTTP POST

Poza tym, skrypt działa na tej samej zasadzie. Pobiera "stronę internetową", która zamiast kodu HTML okazuje się być zbiorem poleceń systemu Windows, i wykonuje ją jako kod.

Serwer dostarczający szkodliwe oprogramowanie wysyła kilkanaście żądań, powoli składających kod wirusa po stronie ofiary. Jest on łudząco podobny do poprzednich automatów, ale zawiera kilka dodatkowych kroków, celem odróżnienia od poprzedniej kampanii i prostego oszukania skanerów behawioralnych. Przez większość czasu, serwer odpowiada "Thank You!" i losową liczbą. Aczkolwiek raz na kilkanaście-kilkadziesiąt prób, podsyła coś innego. Robi to na miarę podobną do Danabota. Ten prosty trik pozwala wyprowadzić w pole automatyczne środowiska "detonujące" skrypty.

Pierwszym krokiem jest rejestracja w botnecie nowej ofiary. Serwer wysyła żądanie posłania "pinga" do innego serwera, celem potwierdzenia, że ofiara nie tylko otrzymuje polecenia, ale także wykonuje je. URL z którym należy się połączyć inicjalizuje połączenie HTTPS, ale nic nie zwraca. Chodzi tylko o to, żeby się odezwał. String "c h k e s o s o d" w adresie pokazuje, że mamy do czynienia z infrastrukturą do wynajęcia. Zupełnie inne kampanie stosowały ten sam URL, ale oczywiście inne domeny.

Następny krok to, tak samo, jak w przypadku Danabota, otrzymanie bardzo długiego polecenia tekstowego (925.9 KB) zawierającego kod wykonywalny zapisany w formacie base64. Polecenie składa przesłany kod w plik binarny o nonsensownej, acz nielosowej nazwie. Jest zapisywany w katalogu tymczasowym użytkownika, bez rozszerzenia, i czeka na dalsze polecenia.

Dopiero po jakimś czasie przychodzi żądanie zmiany nazwy pliku poprzez dodanie rozszerzenia DLL. Pobrany wirus, będący biblioteką dynamiczną, jest następnie rejestrowany w systemie jako rozszerzenie Eksploratora Windows, poprzez program RUNDLL32 wołający domyślny eksport DllRegisterServer. To nowy krok, poprzednie kampanie od razu wykonywały właściwy kod wirusa. Trudno powiedzieć, jaki jest cel owej zmiany, poza złamaniem poprzedniego łańcucha czynności.

Kolejne żądanie od serwera to polecenie zmiany skojarzenia pliku MSC. Od teraz przystawki administracyjne mają nie być uruchamiane przez Microsoft Management Console, a z użyciem pobranej biblioteki, wołanej przez RUNDLL32. Z perspektywy systemu, w dalszym ciągu systemowe pliki (*.msc) mają być otwierane przez systemowy program (rundll32.exe), ale w działaniu pośrednikiem jest obcy kod. Na liście procesów zawsze będzie jednak widniał wyłącznie program podpisany przez Microsoft.

Ponadto, przystawki MMC dokonują auto-podniesienia uprawnień. Windows ma nie pytać o pozwolenie na uruchomienie ich jako administrator i włączyć od razu. Dlatego też kolejnym poleceniem jest odpalenie przystawki Zarządzanie Komputerem (compmgmt.msc). Efektem będzie uruchomienie pobranego wirusa jako administrator bez pytania. To silny argument za tym, by suwak Kontroli Konta Użytkownika ustawić na samą górę, wbrew marudzeniu malkontentów.

Obecnie, pobrany wirus zwiększa użycie pamięci przez program explorer.exe, skanuje uruchomiony system pod kątem poświadczeń Windows (aby dokonać tzw. ruchu poziomego i rozsiać się po innych komputerach w lokalnej sieci). Później otwiera katalogi pamięci podręcznych przeglądarek Chrome i Firefox, zapewne w poszukiwaniu zapamiętanych haseł, po czym... kończy pracę. Zapewne wykrywa bycie obserwowanym. Pozostaje zgłosić się z nim do antywirusów.

W momencie działania kampanii, wirus był wykrywany przez 2 antywirusy (z 69!). Analizator Microsoft MSRC zaraportował z kolei, że wykrywa go jedynie silnik chmurowy, ale detekcje oparte o definicje są czyste. Dziś sytuacja wygląda inaczej i trojana widzi już 40 silników, ale prędkość odpowiedzi była niska, jak zwykle. Wersja definicji 1.305.731 programu Windows Defender umie już wykryć wirusa. Szkodnika zaklasyfikowano jako Win32/Ursnif.

Zwyczajowe metody ochrony w postaci... nieotwierania obcych załączników oraz ustawienia suwaka kontroli konta użytkownika na samą górę pozostają takie same, jak w przypadku poprzednich kampanii Emoteta i Danabota. Jeżeli jednak jesteśmy odpowiedzialni za zabezpieczenie firmowej sieci używanej przez niewyuczalnych ludzi (co wbrew powszechnemu myśleniu życzeniowemu domorosłych administratorów jest częste), warto rozważyć następujące usprawnienia w Zasadach Grupy:

• Poza zmianą skojarzenia plików VBS z Hosta Skryptów na Notatnik, to samo należy uczynić dla plików VBE
• Ponieważ możliwość całkowitego zablokowania zmiany skojarzeń (NoFileAssociate) została usunięta w Windows 8, należy zadbać o to, by lokalni administratorzy również byli zawsze pytani o uprawnienia przez UAC.
• Jako, że wirus ma \wyłącznik\ w postaci testu na obecność pliku, można rozważyć wymuszenie tworzenia pliku C:\WINDOWS\isolate.ini. Takich plików jest więcej. Np. obecność C:\hitchins.txt na dysku sprawia, że ransomware MaZe nie uruchamia się. To profilaktyka oparta o porażkę, ale działa.

Serwery, z których otrzymaliśmy trojany, dalej działają. Zresztą, na każdy zamknięty serwer przypada pięć nowych. A antywirusy często pomagają... ale tydzień po kampanii.