Przegląd najnowszych wirusów pocztowych. Danabot wciąż aktywny

Niekorzystanie z poczty elektronicznej obsługiwanej w ramach pakietów chmurowych to ciekawe przeżycie. Pozwala przekonać się, do jakiego stopnia e-mail świadczony przez Microsoft lub Google różni się od tego prawdziwego. Nie tylko w kwestii zgodności ze standardami, ale także pod względem ilości i rodzaju... spamu. Filtry antyspamowe Google są bowiem naprawdę szczelne. Maile znajdujące się w katalogu „Spam” to wszakże nie cały spam, przychodzący pod adres na GMailu. Lądują tam tylko wiadomości, co do których nie ma obrzydliwie wysokiej pewności, że są śmieciem.

Danabot wciąż aktywny (Pixabay)

Kamil J. Dudek

23 czerwca 2019, 16:16

Taką pewność trudniej osiągnąć, gdy używa się własnego, dedykowanego rozwiązania pocztowego. Wtedy też o wiele łatwiej być narażonym na stare dobre wirusy pocztowe. Ponieważ dzisiaj kont pocztowych innych, niż GMail i Outlook używają głównie firmy (a nie osoby prywatne), w dodatku te, które nie chcą z jakiegoś powodu używać pakietów chmurowych, wirusy w e-mailach usiłują celować w podrabiane faktury, polecenia zapłaty i awiza od kuriera. Ponaddwudziestoletnia metoda polegająca na zwykłym nadużyciu zaufania, w dalszym ciągu okazuje się być skuteczna. Jej opłacalności dowodzą nieustające kampanie, wykorzystujące łatwe do podważenia faktury i dokumenty. Przyjrzyjmy się najnowszym nośnikom ataku.

System Windows potrafi montować pliki ISO za pomocą software'owego urządzenia Virtual DVD Drive

Obrazy dyskietek magnetycznych

Ponieważ dołączenie pliku EXE żywcem jako załącznik nie wchodzi już dziś w grę, przestępcy starają się „owinąć” je w coraz bardziej wymyślne opakowania, nie redukując przy okazji dostępności. Od kilku lat nie działa już prosty trik z plikiem ZIP, ponieważ skanery antywirusowe już dawno nauczyły się zaglądać wewnątrz archiwów. Zmiana formatu kompresji również przestała już przynosić skutek, bowiem dziś jedyne formaty, które wciąż omijają antywirusy to zarazem formaty nieobsługiwane przez większość oprogramowania u ofiar. Pogoń za efektywnym nośnikiem doprowadziła nas do poziomu z wirusami w formatach ARJ i ACE, przez co trzeba się wykazać solidnym wysiłkiem, żeby w ogóle móc dostać się do szkodliwej zawartości.

Najnowsza metoda to używanie plików obrazów dyskowych ISO oraz IMG. Systemy Windows 7 i nowsze potrafią montować owe pliki pod literką dysku i przeglądać je tak samo, jak fizyczne media. Zwiększa to szanse, że zawartość nie zostanie przeskanowana na serwerze pocztowym, jeszcze przed zamontowaniem pliku u ofiary. Wewnątrz bywa już gorzej. Nierzadko środku pliku z obrazem znajduje się po prostu bezczelny EXE z trojanem, natychmiast wykrywanym np. przez Defendera.

Windows Defender wydaje się niepozorny, ale pod spodem kryje się skuteczny i rozbudowany mechanizm ochronny

AutoIT

Z rzadka pojawi się coś ciekawszego. Na przykład plik EXE wykorzystujący jednego z moich ulubionych trojanów, których istnienie jest zniewagą względem ludzkości lub dowodem na jej głęboki upadek: automatyzator AutoIT lub backdoor TeamViewer. Program o przebojowej nazwie PO-13466______________________________________________________________.exe to tak naprawdę bundle programu AutoIT ze zintegrowanymi skryptami, wykonującymi zaprogramowane „kliknięcia”. To dość zuchwała metoda, a sam plik nie jest wykrywany przez skanery antywirusowe. Co więcej, AutoIT w zamierzeniu działa jako aktor symulujący ręczne akcje (np. klik), więc jego zachowanie może oszukać w ten sposób skanery behawioralne.

COMPMGMTLAUNCHER1 uruchamia przystawkę Zarządzanie Komputerem, zapewne po to, by dokonać automatycznego podniesienia uprawnień przez wzniecania alarmów UAC. Jest to możliwe na domyślnych ustawieniach systemu, wybranych wskutek negatywnego przyjęcia systemu Windows Vista. Dlatego zawsze należy ustawiać suwak Kontroli Konta Użytkownika na samą górę, bez wyjątku.
BIWINRT2 wykorzystuje słabość LOLBin(https://www.dobreprogramy.pl/Model-zaufania-w-Windows-10-wciaz-latwo-ominac-aktualizacje-raczej-nie-pomoga,News,91359.html), polegającą na zbyt ufnym tworzeniu aplikacji i bibliotek, będących częściami składowymi Windows. Część z nich, jak na przykład biblioteki DLL środowiska WinRT, dają się wykorzystać do uruchomienia innych programów. W ten sposób, na liście procesów znajduje się zaufany program od Microsoftu, a nie jakiś niepodpisany wirus z Chin. Z tego samego powodu, dziś coraz częściej wirusy nie przyjmują postaci plików EXE, a bibliotek DLL. Dzięki temu na liście procesów figuruje program RUNDLL32.EXE, będący częścią składową Windows.

SECURITYHEALTHSERVICE3 wyłącza, korzystając z nabytych uprawnień, usługę Usługa Stanu Zabezpieczeń, monitorującą stan antywirusa, zapory, szyfrów, integralności TPM i innych. Jest to następca usługi „Centrum Zabezpieczeń”, która naturalnie również istnieje w systemie, równolegle, i w dodatku nie da się jej wyłączyć, mimo że jest niepotrzebna. Wyłączenie programu SecurityHealthService sprawia, że zatrzymanie ochrony antywirusowej programu Windows Defender nie będzie raportowane przez żaden interfejs (acz stosowna adnotacja pojawi się w Dzienniku Zdarzeń)ACTIVATIONCLIENT4 woła Usługi Aktywacji Systemu Windows, z dość niejasnego powodu, ponieważ na nic to nie wpływa. Przy okazji jednak ukrywa w systemie plików katalog, odbierając mu prawa odczytu przez zwykłego użytkownikaIGFXHK5 tworzy w Rejestrze klucz autouruchamiania, o nazwie łudząco podobnej do narzędzia karty graficznej Intel, służącego do przechwytywania kombinacji klawiszy wywołującej rotację ekranu. Klucz ten odpowiada za aktywowanie programu uruchamianego z ukrytej i nieusuwalnej lokalizacji. Jest przy okazji kolejnym dowodem na zbędność i szkodliwość narzędzi dostarczanych do przestrzeni użytkownika wraz ze sterownikami. Dlatego zawsze warto „ogolić” z nich system, korzystając na przykład z narzędzia Sysinternals Autoruns.

Danabot nie odpuszcza

Nowości na polu pocztowych wirusów to jednak rzadkość. Większość stanowią kolejne iteracje kampanii Danabot, aczkolwiek ten nienowy już trojan napisany w Delphi również uległ pewnej ewolucji. Najnowsze kampanie mailowe nie są już tekstowymi listami z jednozdaniową treścią. Tym razem jest to już kompletna wiadomość z szablonem i papeterią, napisana porządniejszym językiem i sprawiająca wrażenie prawdziwej korespondencji. Jednakże, jak zwykle coś musi być nie tak. Tym razem, bez BCC, na liście odbiorców tego rzekomo personalnego maila znajdowali się (poza redakcją) producent kas pancernych oraz sklep odzieżowy. Mail nie zawierał żadnych złośliwych odnośników, ale za to posiadał oczywisty załącznik ze skryptem VBS w środku.

Jedyna zawartość zdalna w tym mailu to obrazek z logo firmy kurierskiej

Skrypt ten jest jednak o wiele bardziej zaawansowany, niż poprzednie. Dawne wersje były zaciemnione i pełne martwego kodu, ale efekt ten osiągano ręcznie. W dodatku, sam skrypt nie dostarczał żadnego kodu wykonywalnego – pobierał go z zewnętrznego serwera. Serwery te, mimo nieodpowiadania wirusem za każdym razem (!) były prędko wykrywane i zamykane, wymuszając wysłanie nowych maili. Pełniejszy opis tego mechanizmu jest przedstawiony w listopadowej analizie.

Nowy, lepszy Danabot

Nowa wersja skryptu jest zaciemniana w sposób bezsprzecznie zautomatyzowany, ponieważ plik jest naprawdę długi, zawiły, skomplikowany i w dodatku kompletnie nieczytelny. Poza tym, skrypt przechowuje wewnątrz plik binarny, ale zdekomponowany i zaciemniony. Usuwa to konieczność polegania na serwerach pośredniczących. Plikiem tym jest, podobnie jak w poprzedniej wersji, biblioteka DLL, ona jednak również uległa skromnym zmianom.

Zarówno skrypt, jak i dostarczany program, pełen jest śmieci, martwego kodu i tzw. ściółki

Odkręcenie zaciemnienia skryptu Visual Basic Script wymaga nieco zabawy z narzędziami sed i grep. Gdy osiągnie się już czytelniejszą postać, wciąż potrzebne jest nieco ręcznej zabawy, ale końcowy efekt pozwala zapoznać się z pomysłem wykorzystywanym w najnowszym nośniku Danabota.

Najważniejszy element: dekoder

Kod wirusa DLL jest zapisany w formie czterdziestu pięciu jednowymiarowych tablic z liczbami całkowitymi (Int). Każda z nich zawiera 12300 elementów. Z kolei każdy element jest liczbą będącą kodem ASCII... plus 132. Odszumiony dekoder okazuje się więc robić coś takiego:


Function convertArrayToStringStream(inputArray)
	i = 0
	outputString = ""
	Do While i =< UBound(inputArray)
		outputString = outputString + ChrW(inputArray(i) - 132)
		i = i + 1
	Loop
	convertArrayToStringStream = outputString
End Function

Odszyfrowanych 45 tablic jest następnie składanych do obiektu typu ADODB Stream. Wybór owego typu wynika zapewne z tego, że jest to najbardziej swobodna metoda przechowywania luźnych bajtów w środowisku programowania VBS. Pamiętajmy, że to zwykły Visual Basic, a nie środowisko .NET, gdzie można po prostu użyć tablicy typu Byte(), a następnie wlać ją do pliku. Tutaj nawet tablica liczb całkowitych musi być mała (dlatego jest ich 45), a strumieni bajtowych nie ma.

Wystarczy trochę śmieci, by kompletnie zmylić wszystkie liczące się antywirusy...

Nie da się użyć stringów, ze względu na... kodowanie (Windows 95 nie obsługiwał standardu Unicode, dzięki czemu w środowisku VBS string stringowi nierówny). Pozostaje więc wykorzystać obiekt COM o domyślnie dużym rozmiarze, eksponujący metody dostępu pozwalające na swobodne pisanie bajt po bajcie. Jednym z kandydatów jest właśnie bazodanowy strumień danych ADO. Ach to programowanie w latach dziewięćdziesiątych. Proszę zobaczyć, jakie piękne:


Function mergeStreamsIntoFile()
	Dim inputStreamUnicode
	Set inputStreamUnicode = CreateObject("ADODB.Stream")
	inputStreamUnicode.Type = 2
	inputStreamUnicode.Charset = "ISO-8859-1"
	inputStreamUnicode.Open()
	inputStreamUnicode.WriteText convertArrayToStringStream(payload)
	inputStreamUnicode.SaveToFile "malware.blob", 2
	inputStreamUnicode.Close()
End Function

Nieco szamotaniny

Następnie, skrypt wykonuje kilka dziwnych i potencjalnie zbędnych akcji. Najpierw, wyświetla komunikat o treści „An unexpected error has occurred. You request cannot be processed at this time. Please try again later. (0x1282904)”. Jest on również zaszyfrowany i niewidoczny podczas przewijania skryptu. Następnie, sprawdza na podstawie Rejestru, czy znajdujemy się w Australii lub Nowej Zelandii (identyfikatory tych państw zostały wybrane świadomie, bo nie padają po sobie po kolei). Nic nie robi z tą informacją, podejmując te same kroki niezależnie od wyniku. Czyżby pozostałość po wersji celującej tylko w te kraje? Wreszcie, skrypt tworzy plik o nazwie "jVBgGY.BsEom" i treści "VVfR". Nie wiadomo, czemu. Być może jest to jakaś forma znacznika „tu byłem” lub aktywator dla wirusa DLL. Możliwe, że bez jego obecności, wirus „wie”, że jest uruchamiany w środowisku testowym i ukrywa swoje zamiary.

WIDEO


Function displayBanner()
	uName = CreateObject("WScript.Network").UserName
	scam = "An unexpected error has occurred. You request cannot be processed at this time. Please try again later. (0x1282904)"
	box = MsgBox("User "+ uName + " " + scam, vbSystemModal, "Microsoft Word")
End Function

Function writeTriggerFile()
	Dim fso: Set fso= CreateObject("Scripting.FileSystemObject")
	With fso.createTextFile("trigger.file")
		.Write("VVfR")
		.Close
	End With
End Function

Aktywacja

Końcowym krokiem jest aktywacja wirusa DLL. Jest to kolejna wersja przeklętego botnetu Danabot, tak samo nieczytelna, wielokrotnie złożona (o wiele mocniej, niż ten skrypt...) i skompilowana do nieprzenikalnego formatu produkowanego przez Embarcadero Delphi. Tym razem jednak, zamiast wołać funkcję biblioteki DLL poprzez RUNDLL32, wykorzystywana jest rejestracja klasy w systemowej przestrzeni nazw, za pomocą narzędzia REGSVR32.

Oznacza to, że Danabot został zaktualizowany. Zaletą jest ominięcie definicji behawioralnej. Wadą natomiast – potencjalne podpadanie pod inną, ponieważ zmienione podejście wcale nie jest jakieś genialne. Rejestrowanie biblioteki systemowej zapisanej do pliku tekstowego w katalogu tymczasowym to scenariusz, który naprawdę się wyróżnia i nie ma prawa być niczym godnym zaufania. Żaden normalny program się tak nie zachowuje.


Function registerLibrary()
	With CreateObject("WScript.Shell")
		.Exec("regsvr32.exe -s malware.blob")
	End With
End Function

Reszta historii to już zwyczajny DanaBot. Windows Defender wykrywa go jako Win32/Ditertag, aczkolwiek dopiero od wczoraj. Mimo skromnej różnicy względem poprzedniej wersji, minęło 48 godzin od mailowej kampanii do czasu powstania definicji pokrywającej złośliwy plik DLL. Jest to kolejny dowód na nieskuteczność antywirusów. Nie samego Defendera, a antywirusów w ogóle. Jeszcze wczoraj trojana wykrywało osiem silników AV. Dzisiaj – trzydzieści. Drugie tyle siedzi cicho.

Warto wyłączyć skojarzenie plików VBS i JS z Hostem Skryptów Windows na komputerach, które ma się pod swoją opieką


displayBanner
Do
    mergeStreamsIntoFile
    writeTriggerFile
    checkRegion
    registerLibrary
    WScript.Sleep 70000
Loop

Jeszcze lepiej sprawa ma się w kwestii samego skryptu. Automatyczne zaciemnienie okazało się bowiem skuteczne. Jako złośliwy plik oznaczają go tylko trzy eksperymentalne antywirusy, które w dodatku nie robią tego, gdy przeskanuje się oryginalny załącznik, w postaci pliku ZIP. Można więc powiedzieć, że względem złośliwych plików VBS, ochrona antywirusowa w zasadzie nie istnieje. To kolejny argument za tym, by zmienić domyślne skojarzenie tego typu pliku, z akcji uruchomienia go(!) na wyświetlenie w Notatniku. Będzie to zdecydowanie bezpieczniejsze, gdy już zdecydujemy się zajrzeć do rozpakowanego załącznika sfałszowanego listu od obcej osoby, piszącej nam (i sprzedawcom sejfów), że jesteśmy dłużni pieniądze. Wysłanego z domeny kupionej tydzień wcześniej. Na podstawione nazwisko. Korzystając z jeszcze innej domeny jako nadawcy. 🤣 I tak dalej, i tak dalej...

Kamil J. Dudek

Administrator Windows Server i RHEL. Zajmuje się cyberbezpieczeństwem gdzieś w Fortune 500. Przejściowo nauczyciel akademicki. Wykazuje niezdrowe zainteresowanie filozofią, polityką i rujnowaniem rytmu dobowego. Jednordzeniowy.

Źródło artykułu:

www.dobreprogramy.pl