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

Wirusy propagowane przez dokumenty Office wciąż korzystają z bardzo starych dziur w pakiecie. Stoi to w opozycji do rosnącej złożoności przestępczej infrastruktury, z którą łączą się gdy zostaną skutecznie uruchomione. Staje się ona bowiem niemal profesjonalna.

Pobrana z Pastebina druga część wirusa łączy się z dedykowanym serwerem, produkującym wirusy na zamówienie! I tym razem nie jest to byle statyczny link, oddzielny dla kampanii: skrypt wykonuje zapytanie POST za pomocą obecnego na serwerze przestępców REST API, wysyłając do niego dane telemetryczne z zainfekowanego komputera. Są one następujące:

• UUID komputera (każdy komputer z Windows generuje swój unikatowy identyfikator na podstawie sprzętu, do celów wszelakich)
• Nazwa komputera
• Nazwa systemu operacyjnego
• Język
• Domena lub grupa robocza
• Oprogramowanie antywirusowe
• Procesor
• Karta graficzna

To niezwykle zaawansowana infrastruktura jak na zwykły malware. Przesyłanie tak rozbudowanych informacji może mieć kilka powodów:

• Wykrywanie maszyny wirtualnej: jeżeli wirus jest badany przez automatyczny analizator lub eksperta w VM, UUID i model karty graficznej zdradzą, że wirus nie pracuje na prawdziwym komputerze i API nie zaserwuje prawdziwego ciągu dalszego wirusa
• Wykrywanie zgodności: skrypt PowerShell 5.1 lub aplikacja .NET 4.8 wywalą się brzydko, zdradzając swoją obecność, na systemach starszych niż Windows 10. Przestępcy chcą uniknąć dowodów wizualnych na trwającą infekcję
• Wykrywanie obecności w firmie: jeżeli grupą roboczą nie jest WORKGROUP, komputer znajduje się w sieci i firmowej i przestępcy mogą zaserwować wirusa "w wersji dla firm". Zamiast kraść hasła do banku, zaszyfruje pliki w sieci lokalnej i zażąda okupu
• Wykrywanie skutecznego antywirusa: gdy przestępcy wiedzą już, że ich wirus jest wykrywany przez AV zainstalowany u ofiary, nie podrzucą mu szkodnika i skupią się na atakowaniu tych, których antywirusy są jeszcze ślepe na zagrożenie

Wreszcie, atak może być o wiele bardziej ukierunkowany. Być można bardzo szeroka kampania tak naprawdę wycelowana jest tylko w kilka/kilkanaście konkretnych komputerów, o znanych UUID i gdzie indziej nie zrobi nic?

Trudno orzec, czy wspomniany serwer steruje aż tak kierowaną kampanią, faktem jest jednak, że jest bardziej rozbudowany niż te, które zazwyczaj spotykamy w kampaniach mailowych "na załącznik". Poza REST API, serwer wyprowadza także interaktywne strony WWW z panelem logowania. Wygląda to tak, jakby nabywca złośliwej kampanii mógł się zalogować aby zobaczyć jej skuteczność i wprowadzić nowe polecenia dla utworzonego botnetu. Malware-jako-usługa. Serwer nie miał nazwy domenowej, łączność z nim następuje po IP, choć ten pierwszy już miał wpis DNS.

Rekord wskazywał na domenę w mało renomowanym, za to tanim, TLD o końcówce ".xyz". Rekord ten nie uległ w Polsce pełnej propagacji na lokalne DNS-y dostawców. Całkiem możliwe, że wynika to bardzo niskiej reputacji, jaką ma registrar, u którego dokonano zakupu domeny. W dodatku jego kraj pochodzenia (łatwo zgadnąć, który) każe podejrzewać, że zgłaszanie nadużyć na adres Abuse może nie spotkać się ze szczególnie solidarną reakcją.

API REST-owe niniejszego złośliwego serwera odpowie tylko wtedy, gdy UUID jest poprawne składniowo. W przeciwnym wypadku odpowie pustym JSON-em ({}). Opowiedź, wykonywana od razu jako skrypt PowerShell, pobiera kolejny srogo zaciemniony skrypt PowerShell z Pastebina, stosujący dokładnie taką samą sztuczkę z chorymi nazwami zmiennych, co poprzedni.

Odkręcony, okazuje się komunikować z systemowym Harmonogramem Zadań i pobierać kolejny plik HTA, w postaci pliku 1.txt, z jeszcze innego adresu.

Jeżeli skrypt wykryje pracę jako administrator, zarejestruje zadanie dla wszystkich użytkowników i nada mu najwyższe uprawnienia. W przeciwnym razie zarejestruje uruchamiane co godzinę zadanie wykonujące plik HTA. Co w nim siedzi?

Otóż, jest to z powrotem ten sam skrypt pobierający pierwszego Pastebina. Ścieżka jest ustawiona na sztywno, a zadanie uruchamiane co godzinę, co może oznaczać, że w pewnym momencie plik 1.txt zostałby podmieniony na właściwy ciąg dalszy kampanii. Dziś już się tego nie dowiemy, ponieważ serwer ten, poza plikiem 1.txt serwujący także tysiące(!) innych złośliwych plików DOC dziś już nie odpowiada.

Tymczasem oprogramowanie antywirusowe w międzyczasie nie zdążyło nauczyć się wykrywać owego zagrożenia. Znowu. Stanowi to kolejny element bardzo długiego ciągu rozczarowań tą kategorią ochrony. Jak więc się zabezpieczyć? Tym razem wyłączenie makr nic nie da, bo wirusa nie uruchomiło makro. Zablokowanie MSHTA na zaporze także nie pomoże, ponieważ za łączność odpowiada WSH/IEFrame/PowerShell.

Najprostsze rozwiązanie to po prostu… zaktualizować pakiet Office. I tyle. Uchroni nas to przed dawno załatanymi dziurami. Aby otrzymać ochronę przed tymi przyszłymi, wskazane jest włączenie reguły redukcyjnej 26190899-1602-49e8-8b27-eb1d0a1ce869. Zapobiega ona tworzeniu procesów potomnych przez Office. O regułach redukcyjnych pisaliśmy przy okazji serii o Defenderze. Microsoft jednak często zmienia zdanie w kwestii tego, czy reguły redukcyjne ASR są w ogóle obsługiwane w wersjach konsumenckich.

Kamil J. Dudek, współpracownik redakcji dobreprogramy.pl