Fałszywe faktury wciąż zalewają skrzynki mailowe. Jak omijają antywirusy?

Głównym powodem, dlaczego zawirusowana poczta nie jest już podstawowym źródłem ataków jak niegdyś, nie jest zwiększona świadomość użytkowników. Jest nim niemożność przesyłania plików wykonywalnych i skryptów z wykorzystaniem skrzynek pocztowych głównych dostawców, jak GMail i Hotmail. Gdyby nie to ograniczenie, epidemie mailowe trwałyby nadal. Zwłaszcza, że od dwudziestu lat, z kompletnie bezsensownych już dziś powodów, Windows domyślnie uruchamia, a nie wyświetla pliki skryptowe typu VBS (Visual Basic Script).

Twórcy wirusów starają się obejść powyższe zabezpieczenie jakimś „bezkosztowym” sposobem, np. stosowaniem kompresji. W ten sposób załącznikiem staje się plik RAR a nie VBS, ale GMail jest dziś odporny i na to. Prawdziwą skalę zjawiska złośliwych maili można zatem poznać dopiero korzystając z nieco mniej standardowej poczty. Statystyka każe najwyraźniej zakładać, że nietypowe skrzynki pocztowe są najczęściej używane w firmach. Dlatego też najczęstsza postać mailowych wirusów to pliki o nazwie „faktura”, przesyłane na konta firmowe i opatrzone (sfałszowanym) nagłówkiem nadawcy – innej firmy.

Wewnątrz załącznika kryje się plik VBS. Mowa tu o tym samym formacie VBS, który w 1999 roku wywołał epidemię „I love you”. Naturalnie, dzisiejsze wirusy nie mogą już stosować tych samych sztuczek co kiedyś. Nikt nie używa już Książki Adresowej programu Outlook Express, w której trzyma maile wszystkich znajomych. Dlatego wirus VBS w 2018 musi korzystać z zupełnie innych rozwiązań. Na tyle zaciemnionych, że łatwo tu o przeoczenie prawdziwego mechanizmu działania. Złożoność działania jest na tyle duża, że podobne „przeoczenia” przytrafiają się antywirusom (wszystkim bez wyjątku!) oraz automatycznym analizatorom, opartym o maszyny wirtualne. Jeżeli więc aby zdobyć zaufanie odbiorcy, wystarczy się nazwać „faktura”, to co takiego należy zrobić, by zyskać sobie pobłażliwość antywirusów? Dużo i mało. Oto pobieżna analiza prezentów, przychodzących bez ustanku na naszą skrzynkę i na adresy setek innych firm, nie tylko w Polsce (acz w każdym kraju treść podana jest we właściwym języku).

Pierwszy krok to krótki mail ze stopką (z KRS?) i załącznikiem RAR. Niniejsze archiwum zawiera ręcznie zaciemniony skrypt pełen pętli, martwego kodu i podejrzanie dużej liczbie odliczań (wywołań funkcji „Sleep” na kilka lub kilkanaście sekund). Sprowadzając kod do prostszej, czytelnej postaci, nie wolno pominąć owych wywołań! Bez nich skrypt nie funkcjonuje poprawnie. Co takiego próbuje zrobić? Załadować pewną stronę internetową jako tekst, a następnie ten tekst wywołać jako kod.

Jakkolwiek niewiarygodnie może to brzmieć, Visual Basic Script potrafi pracować asynchronicznie! Oznacza to, że próba wykonania strony jako kod natychmiast po próbie jej pobrania zakończy się wykonaniem pustki, ponieważ strona nie zdążyła się jeszcze pobrać. Dlatego aby wywołać rzeczywisty ładunek, pobierany z szemranego serwera, konieczna jest doza cierpliwości. Dopiero po kilku chwilach otrzymujemy odpowiedź od serwera. Co w niej jest? Cyferki.

Cyferki są zazwyczaj niegroźne. A już na pewno nieszkodliwe jest wywołanie np. liczby „323914311” jako polecenie. System po prostu zwróci błąd i będzie pracował dalej, niewzruszony. Czyżby zatem skrypt już nie działał, bo serwer kontrolujący kampanię przestał wysyłać ładunki, a zamiast tego śle cyferki? Otóż nie. Sytuacja jest... nieco gorsza.

Analizatory heurystyczne w antywirusach oraz całe dedykowane maszyny wirtualne (stawiające „honeypot”), celem oceny zagrożenia łączą się adresem URL w skrypcie z lewej faktury. Niestety, serwer pod owym adresem odpowiada przeważnie niegroźnymi cyferkami. Dlatego analiza kończy się wnioskiem, że kod jest najwyraźniej niegroźny. Łatwo dojść do innych wniosków, jeżeli nie ulegnie się iluzji i odpyta tenże serwer jeszcze kilkanaście razy. Wszak skrypt z maila działa w pętli, prawda?

Po kilku minutach zamiast cyferek zaczynają przychodzić inne rzeczy. Pierwszą z nich jest drugi, mniejszy skrypt VBS. Niestety, również zaciemniony. Po odszyfrowaniu okazuje się być… kodem PowerShell. Kod ten ma w zamierzeniu pobierać plik o losowej, czteroliterowej nazwie (z innego serwera!). Wspomniany plik ponownie jest dostępny do pobrania tylko czasami – w większości przypadków pobranie skończy się zgłoszeniem kodu 404. Jak poprzednio, ma to na celu wojnę na wyniszczenie i pilnowanie pozorów, że serwer ten jest wadliwy, ale niegroźny.

Kolejne minuty obfitują w kolejne elementy układanki. Drugim otrzymanym skryptem jest półmegabajtowy(!) kod składający bibliotekę DLL, zapisaną w postaci base64. Dlaczego DLL, a nie EXE? Bo wrzucenie DLL w analizator nie poskutkuje uruchomieniem go. Nawet, jeżeli środowisko testowe (lub tester) będzie mądre i uruchomi DLL z wykorzystaniem rundll32, otrzymany plik nie jest standardową biblioteką. Aby ją uruchomić, należy wywołać konkretny identyfikator eksportu, czyli parametr. Próba uruchomienia domyślnego eksportu skończy się natychmiastowym zakończeniem działania. Sprytne. Zawsze trochę testów „wymięknie” na takiej architekturze, a przecież wcale nie jest ona taka znowu genialna. Który eksport należy uruchomić? Tego jeszcze nie wiadomo. Póki co udało się otrzymać jedynie bibliotekę DLL i żądanie zapisania jej pod konkretną nazwą w systemowym katalogu tymczasowym.

Po odsianiu kilkuset jałowych odpowiedzi pełnych cyferek, wreszcie przychodzi ciąg dalszy: nazwa eksportu, który należy uruchomić. Poza nim, następna część skryptu robi coś ciekawego. Modyfikując systemowy Rejestr, ale wyłącznie w gałęzi użytkownika (HKCU), zmienia skojarzenie typu pliku MSC. Pliki MSC to przystawki Microsoft Management Console, przeznaczone do użycia wyłącznie przez administratorów. Na koncie ograniczonym, większość przystawek odmówi działania, ale niektóre z nich wyświetlą ograniczony zbiór opcji. Na koncie administracyjnym, przy domyślnych ustawieniach Kontroli Konta Użytkownika, przystawka MMC zostanie uznana za tzw. zaufaną aplikację i samodzielnie dokona ona podniesienia uprawnień do poziomu administratora. Tę cechę wykorzystuje omawiany złośliwy skrypt. Używa przystawki Zarządzanie Komputerem, by samodzielnie uruchomić się z rozszerzonymi uprawnieniami. To doskonały przykład na to, jak łatwo obejść Kontrolę Konta Użytkownika (UAC), która zawsze, niezmiennie powinna być ustawiona na najwyższy poziom („Zawsze pytaj”), najlepiej w zestawieniu z używaniem konta o ograniczonym dostępie (a więc nie administratora).

Gdy kod otrzyma już prawa administracyjne, serwer w pętli podaje już tylko kolejne, lekko zmienione wersje biblioteki DLL i usiłuje z niej wykonać eksport o identyfikatorze „f1”. Co takiego robi owa biblioteka? Samodzielnie – bardzo niewiele. Ze względu na swoje silne zaciemnienie, jej start zajmuje kilkanaście sekund i zmusza procesor do dość wytężonej pracy, ale chwilę później jest już spokój. Na liście procesów znajdują się dwie instancje RUNDLL32, nie powstały nowe pliki ani klucze Rejestru, nie otwarto żadnych nowych połączeń. Ponownie wynika to założenia, że program wymaga cierpliwości. Sam z siebie nie zawiera szczególnie rozbudowanego zbioru funkcjonalności, żeby nie prowokować antywirusów. Dlatego połączenia do kolejnych serwerów wykonuje dopiero po pewnym czasie. Będzie usiłował pobierać z nich nowe „wtyczki”, wykonujące kolejne polecenia. Sam również ma kilka własnych, wbudowanych wtyczek, ale są one zaciemnione i składane w locie (wyróżniają się, gdy czyta się kod biblioteki „żywcem” na ekranie, w skompilowanej postaci). Trudno wyciągnąć, co owe wtyczki próbują zrobić, ale nazwy wołanych funkcji wskazują na to, że program usiłuje roznieść się po sieci, korzystając z udziałów sieciowych i poświadczeń domenowych AD.

Zgadza się to z opisem botnetu „Danabot”, o którym już pisaliśmy i przed którym ostrzegał m.in. ESET. Jak się jednak okazuje, wspomniane technologie omijania antywirusów i systemów detekcji zagrożeń w większości nie są skomplikowanymi algorytmami i są oparte na pętlach, przedawnieniach połączeń oraz pozorowaniu niewinnej komunikacji. Tak proste sztuki okazują się wystarczające do oszukania najpopularniejszych mechanizmów zabezpieczeń. Opisywany malware mocno korzysta również z wysokiej granularyzacji zadań, nie serwuje całego szkodnika od razu, wiele poszczególnych elementów, uruchamianych bez relacji z innymi, nie stanowi żadnego zagrożenia. Wydłuża to i utrudnia badania takiego oprogramowania.

Nie wiemy, w jaki ładunek zostanie zaopatrzony fakturowy Danabot. Nie wiedzą tego również inni analizatorzy, np. badacze z włoskiego CERT, którzy najwyraźniej dokonali bardzo zbliżonego rozbioru. Niezależnie jednak od potencjalnego zagrożenia, jeżeli będzie ono dalej serwowane w taki sposób, dość łatwo się przed nim zabezpieczyć kilkoma krokami:

• Wyłączyć skojarzenie plików VBS z Hostem Skryptów i zamiast tego skojarzyć je z Notatnikiem
• Przesunąć suwak Kontroli Konta Użytkownika na samą górę, a najlepiej korzystać z konta ograniczonego
• Po prostu nie otwierać niespodziewanych faktur o podejrzanych rozszerzeniach (i w zasadzie tyle wystarczy 😉)

Najmniej kreatywną częścią całej kampanii Danabot jest niewątpliwie metoda propagacji, oparta o załączniki poczty e-mail. Kolejne elementy łańcucha są już znacznie bardziej przemyślane, a sama biblioteka DLL jest już inżynieryjnym wyczynem. Oznacza to, że w tworzeniu botnetu bierze udział wiele osób o różnym poziomie umiejętności. Ten fakt, zestawiony z idącą w setki listą domen kupionych tylko na potrzeby malware’u dowodzi, że na wirusach pocztowych dalej da się zarobić, ponieważ użytkownicy masowo „biorą cukierki od obcych” i otwierają bezmyślnie wszystko, co otrzymają. Przed tym nie ustrzeże nas najlepszy antywirus.