Stan zagrożeń w internecie znajduje się obecnie na poziomie standardowym. Nie występują duże epidemie a eksperci z Kaspersky Lab nie zanotowali żadnych poważnych incydentów związanych z bezpieczeństwem. Poziom zagrożenia: 1

Winnti 1.0 - Analiza techniczna

Tagi:

Spis treści

Początkowa biblioteka DLL

Wszystko rozpoczyna się od biblioteki DLL. Złośliwy plik DLL udaje jedną ze standardowych bibliotek systemu Windows,winmm.dll lub apphelp.dll. Ponieważ w większości wykrytych przypadków próbki maskowały się jako bibliotekawinmm.dll, przyjmujemy, że ta nazwa będzie reprezentowała złośliwe biblioteki w dalszej części niniejszego artykułu.

Winmm.dll jest biblioteką systemową Windows, która odpowiada za funkcje multimediów. Biblioteka znajduje się w folderze „%WINDIR%\System32”. Napastnicy, wiedząc że jest to biblioteka podstawowych funkcji systemu, mieli świadomość, że prawdopodobieństwo załadowania tej biblioteki za pośrednictwem innego programu jest bardzo wysokie (to samo tyczy się biblioteki apphelp.dll). Dla przykładu, biblioteka winmm.dll jest ładowana przez procesexplorer.exe, który jest uruchamiany wraz z systemem operacyjnym. Jeżeli szkodliwy plik DLL o nazwie winmm.dllznajduje się w tym samym folderze, co program, który ładuje bibliotekę systemową o tej nazwie, szkodnik DLL zostanie uruchomiony w momencie uruchomienia programu, zamiast oryginalnej biblioteki zlokalizowanej w „%WINDIR%\System32\winmm.dll”. Korzystając z przywileju kontroli zainfekowanego komputera, cyberprzestępcy umieszczają złośliwą bibliotekę w folderze „%WINDIR%”. W tym samym folderze rezyduje aplikacja explorer.exe. To daje napastnikom pewność, że szkodnik DLL zostanie załadowany przy uruchomieniu systemu operacyjnego: procesexplorer.exe załaduje szkodliwy plik winmm.dll z folderu „%WINDIR%”, kiedy tylko uruchomi się wraz z systemem operacyjnym.

Ale w jaki sposób program, którego praca zależy od oryginalnej biblioteki, działa poprawnie, jeśli zamiast oryginalnej biblioteki uruchamiany jest złośliwy plik winmm.dll? Autorzy szkodliwego oprogramowania mają na to odpowiedź: złośliwa biblioteka została zaprojektowana do ładowania oryginalnej biblioteki winmm.dll z folderu „%WINDIR%\System32”. Cyberprzestępcy nie zawracali sobie głowy stworzeniem autorskiego rozwiązania, które zapewniałoby załadowanie oryginalnej biblioteki winmm.dll. Zamiast tego wykorzystali dobrze znany program AheadLib.


AheadLib to program, który ma na celu ułatwienie analizy złośliwych bibliotek – został stworzony przez chińskiego programistę zatrudnionego przez producenta oprogramowania antywirusowego. Program przyjmuje bibliotekę DLL jako dane wejściowe i tworzy kod C, który przechwytuje funkcje zawarte w bibliotece. Kod C może zostać z powrotem skompilowany do postaci biblioteki DLL, która może być następnie stosowana do analizy zachowania szkodliwych plików.



Funkcje przechwytujące (kod wygenerowany przez legalny program AheadLib)

Elastyczność tego narzędzia pozwala na dostosowanie logiki szkodliwej aplikacji podczas analizy i przeciążenia funkcji kodu w celu wyprodukowania pewnych wyjściowych danych debugowania. Część kodu może zostać dodana w celu wyświetlenia parametrów przechwyconych funkcji, aby dowiedzieć się, które wartości są przekazywane do funkcji pierwotnych podczas ich wywoływania. Sposób ten stosuje się w tak zwanej analizie dynamicznej złośliwych aplikacji.


Określanie adresów rzeczywistych funkcji
(komunikat błędu w ramce: „Nie można odnaleźć funkcji %hs, 
program nie będzie działał prawidłowo”)


Zmodyfikowany moduł ładujący oryginalną bibliotekę DLL 
(komunikat błędu w ramce: „Nie można załadować %s, program nie będzie działał prawidłowo”)

Jak na ironię, autorzy złośliwego oprogramowania znaleźli w omawianym narzędziu do analizy idealne rozwiązanie do tworzenia szkodliwych bibliotek. Załadowali do programu rzeczywistą bibliotekę (tzn. winmm.dll) i uzyskali wyjściowy szablon kodu źródłowego (w postaci pliku C) do stworzenia zmodyfikowanej biblioteki DLL. Dodając szkodliwy ładunek, napastnicy stworzyli kompletny wariant złośliwego oprogramowania, który, oprócz szkodliwej funkcjonalności, obejmował również wszystkie cechy realnej biblioteki DLL. Dziwnie jest to, że napastnicy przechowywali kod wiadomości debugujących AheadLib we wczesnych wersjach swoich „produktów” (kod ten oznaczony jest czerwoną obwódką na zrzutach ekranu powyżej). Ciągi debugujące można również znaleźć w kompilacjach złośliwych plików binarnych:


„Nie można odnaleźć funkcji %hs, program nie będzie działał prawidłowo”


„Nie można załadować %s, program nie będzie działał prawidłowo”

Później te komunikaty zostały usunięte z pliku C tworzonego przez AheadLib.

Kontrolna biblioteka DLL

W kodzie złośliwej biblioteki winmm.dll znajduje się kolejna biblioteka, która jest odszyfrowywana „w locie” i ładowana do pamięci procesu. Oryginalna nazwa tej dodatkowej biblioteki to PlusDLL. Jest to główny składnik sterujący złośliwą platformą. Kiedy dodatkowa biblioteka DLL zostanie poprawnie ulokowana w pamięci, biblioteka winmm.dll przekazuje jej kontrolę z parametrem, który jest ciągiem konfigurującym ustawienia bota. Ciąg ustawień jest również przechowywany w postaci zaszyfrowanej w kodzie biblioteki winmm.dll – zaraz za słowem „PLUSUNIT”.


Zaszyfrowane ustawienia bota

Po odszyfrowaniu ciąg wygląda następująco:

url=lp.gasoft.us:80|ver=1018|tag=33|group=lp80wi

Najwyraźniej szkodliwe oprogramowanie Winnti przyciągnęło już wcześniej uwagę badaczy: cyberprzestępcy wprowadzili drobne zmiany metod stosowanych do przechowywania ustawień początkowych. W niektórych próbkach ustawienia zostały ukryte w nagłówku pliku wykonywalnego:


Zaszyfrowane ustawienia na początku złośliwego programu

W innych wariantach zmodyfikowany został ciąg „PLUSUNIT”:


UUUSUN"" zamiast PLUSUNIT

Biblioteka PlusDLL posiada wbudowany sterownik. Sterownik jest przechowywany w pliku „%WINDIR%\System32\<nazwa_sterownika.sys>”, zarejestrowanym jako usługa i uruchamianym przez API funkcji systemowej „NtLoadDriver”. Natychmiast po tej operacji plik sterownika jest usuwany wraz ze wszystkimi wpisami rejestru utworzonymi podczas rejestracji usługi. Plik wykonywalny zachowuje oryginalne nazwy sterowników, którymi są „PortLess” oraz „PointFilter”, jednakże, pliki sterownika, używane podczas infekcji, zapisywane są jako „sp1itter.sys” i „acplec.sys” (według wzoru ). Zadaniem tego sterownika jest ukrycie połączeń sieciowych nawiązywanych przez złośliwe oprogramowanie. Dla przykładu, jeżeli użytkownik zdecyduje się sprawdzić listę ustanowionych połączeń sieciowych (np. używając polecenia netstat –a lub programu tcpview) kiedy bot komunikuje się z serwerem centrum kontroli, sterownik będzie chronił i ukrywał wszelkie połączenia nawiązywane przez złośliwe oprogramowanie. To podejście jest wykorzystywane przez sporo rootkitów dla platformy Windows. Sterownik korzysta z nietypowej metody, aby określić, które adresy powinny być ukryte, a które nie. Te informacje są dostępne w bibliotece kontrolnej PlusDLL, która normalnie działa w kontekście procesu explorer.exe, kiedy infekcja jest aktywna na komputerze. Informacje te są przesyłane z trybu użytkownika, w którym pracuje PlusDL, do poziomu jądra, na którym operuje sterownik, za pośrednictwem funkcji „NtSetQuotaInformationFile”, która jest dostępna w obu trybach.

Podczas uruchamiania sterownik przechwytuje funkcję „NtSetQuotaInformationFile”:


Przechwyt funkcji „NtSetQuotaInformationFile”

Za każdym razem, gdy funkcja jest wywoływana, sterownik sprawdza jej parametry, zwłaszcza: „HANDLE FileHandle” oraz „PVOID Buffer”. Parametr „FileHandle” przechowuje deskryptor opisujący partycje dysku twardego, na których zadaniem funkcji jest ustawianie limitów przestrzeni. Parametr „Buffer” jest buforem zawierającym informacje o potrzebie ustawienia nowych limitów. Sterownik sprawdza, czy wartość parametru „FileHandle” nie jest równa -2 (minus dwa). Kiedy system wywołuje funkcję „NtSetQuotaInformationFile” w celu przeprowadzenia bieżącej zmiany limitów, deskryptor musi być związany z jednym z dysków, co oczywiście oznacza, że nie może być równy -2. Ujemna wartość jest ustawiana przez bibliotekę PlusDLL w celu spowodowania, aby sterownik wykrył, że funkcja „NtSetQuotaInformationFile” została wywołana przez tę bibliotekę. Podczas wywołania funkcji „NtSetQuotaInformationFile”, biblioteka PlusDLL wysyła do sterownika za pośrednictwem parametru „Buffer” informacje na temat adresów sieciowych, które powinny zostać ukryte. Jeżeli wartość „FileHandle” nie jest równa -2, funkcja przechwytująca w kodzie sterownika przekazuje kontrolę systemowi, tak jak ma to miejsce na normalnej, niezainfekowanej maszynie.


Przesyłanie danych z biblioteki PlusDLL.dll do sterownika sp1itter.sys

Należy pamiętać, że 64-bitowe wersje systemu Windows nie zezwalają na uruchamianie niepodpisanych sterowników. 64-bitowe wersje złośliwego sterownika zostały podpisane przy pomocy skradzionych certyfikatów. W czasie, gdy śledziliśmy grupę Winnti, odkryliśmy 11 certyfikatów, które zostały wykorzystane do podpisywania złośliwego oprogramowania stosowanego przez grupę (nie koniecznie tylko sterowników). Dziesięć z tych certyfikatów należy do różnych firm z branży gier komputerowych.

Uruchamianie głównej funkcji

Jak wspomniano wcześniej, biblioteka PlusDLL jest modułem sterującym. Przyjrzyjmy się, w jaki sposób cyberprzestępcy zrealizowali przejście złośliwych bibliotek DLL do wykonywania ich głównych zadań. Atakujący mogli po prostu bezpośrednio wywoływać odpowiednie funkcje lub utworzyć oddzielny wątek do wykonywania funkcji, ale z jakiegoś powodu uciekli się do podstępu: zmodyfikowali kod funkcji „SetWindowStationUser” w bibliotece user32.dll. Po wprowadzeniu modyfikacji, pierwszym rozkazem funkcji staje się polecenie „jmp <addr>”, gdzie „<addr>” jest adresem funkcji w bibliotece PlusDLL, która implementuje główne funkcje szkodliwej biblioteki.


Przechwyt funkcji „SetWindowStationUser”

Natychmiast po wprowadzeniu tej modyfikacji tworzony jest wątek („CreateThread”) wykonania kodu rozpoczynającego się adresu funkcji „SetWindowStationUser”. W rezultacie, kiedy kontrola ewentualnie zostanie przekazana do tej funkcji, wstawione polecenie „jmp <addr>” zwróci kontrolę z powrotem do kodu biblioteki PlusDLL.


Złośliwa biblioteka DLL uruchamiająca swój własny kod poprzez utworzenie wątku, który wywołuje funkcję „SetWindowStationUser”

Ta sama metoda jest stosowana do uruchamiania jeszcze dwóch innych funkcji biblioteki PlusDLL. Jedna z nich jest wykorzystywana do inicjowania procedury sieci; druga wykonuje procedury kończące pracę szkodliwego programu. Jedyną różnicą jest to, że zamiast funkcji „SetWindowStationUser”, modyfikowany jest kod dwóch innych funkcji z biblioteki user32.dll – odpowiednio „EndTask” i „WinHelpW”. Jest prawdopodobne, że zostało to zrobione w celu ukrycia prawdziwych adresów funkcji w bibliotece PlusDLL, na wypadek, gdyby jej kod był analizowany w oparciu o dziennik uruchamiania na automatycznym systemie (sandbox), który sprawdza wszystkie wywołania funkcji. Po użyciu tej sztuczki, dziennik uruchamiania pokaże tylko wątki rozpoczęte z adresami funkcji „SetWindowStationUser”, „EndTask” i „WinHelpW”, co potencjalnie powinno zmylić badaczy. Inna możliwość jest taka, że jest to funkcjonalność mająca na celu zakłócanie emulacji. Być może emulatory wbudowane w niektóre programy antywirusowe nie są w stanie poradzić sobie z tymi „skokami” – w tym przypadku emulacja nie spowoduje wykonania szkodliwych funkcji, co bardzo odpowiada założeniom cyberprzestępców.

Docelowa funkcjonalność

Co więc kontroluje biblioteka PlusDLL? Okazuje się, że docelowa funkcjonalność jest realizowana w różnych plikach. Każdy plik zawiera konkretną funkcję zdalnego sterowania i jest pobierany z serwera napastników za każdym razem, gdy uruchamiany jest system. Pliki te nie są zapisywane na dysku lub w rejestrze, ale są ładowane bezpośrednio do pamięci. Na samym początku operacji, po uruchomieniu sterownika, PlusDLL gromadzi informacje na temat infekowanego systemu. Unikalny identyfikator zainfekowanego komputera jest generowany na podstawie informacji o dysku twardym i adresie MAC karty sieciowej, np. TKVFP-XZTTL-KXFWH-RBJLF-FXWJR. Napastników interesuje głównie nazwa komputera ofiary, nazwa programu, który załadował szkodliwą bibliotekę oraz informacje na temat sesji z wykorzystaniem zdalnego pulpitu (nazwa sesji, nazwa klienta, nazwa użytkownika i czas sesji). Wszystkie te dane gromadzone są w buforze, który jest następnie kompresowany i przesyłany do serwera centrum kontroli. Bufor może wyglądać następująco:


Bot przesyła do centrum kontroli informacje o zainfekowanym systemie

W odpowiedzi na pierwszy komunikat bota, centrum kontroli przesyła listę dostępnych wtyczek. Wtyczki są bibliotekami DLL, które zapewniają konkretne funkcje zdalnej kontroli. Po otrzymaniu listy wtyczek, bot pobiera je, rozdziela w pamięci i przekazuje tym bibliotekom sterowanie.

Różne serwery centrum kontroli przesyłają różne wtyczki. W sumie odkryliśmy osiem funkcjonalnych bibliotek:

Nazwa wtyczkiPrzeznaczenie wtyczki
CmdPlus Daje operatorowi (atakującemu) dostęp do konsoli, tj. wiersza poleceń zainfekowanego komputera.
ListFileManager Współpracuje z systemem plików zainfekowanego komputera: pozwala przeglądać zawartość folderów, otwierać i usuwać pliki.
ListProc Dostarcza operatorowi informacji na temat procesów uruchomionych na zainfekowanym komputerze. Daje możliwość zatrzymywania procesów.
ListService Dostarcza operatorowi informacje na temat usług zainstalowanych na zainfekowanym komputerze.
PortMap Przekierowuje ruch sieciowy za pomocą przekierowania portów.
RemoteDesktop GUI zdalnego pulpitu, który pozwala napastnikowi podglądać, co dzieje się na ekranie monitora zainfekowanego komputera, jak i również umożliwia pracę na pulpicie komputera ofiary.
Socks5Client Biblioteka do przesyłania danych przez sieć za pomocą serwera proxy SOCKS5.
TransPlus Pozwala napastnikowi przesyłać pliki: odbierać pliki z zainfekowanej maszyny, pobierać / tworzyć / zapisywać pliki, jak i również uruchamiać programy na zainfekowanym komputerze.

Wtyczki te tworzą bazowy zestaw funkcji ofensywnych, których napastnicy używają podczas ataku.

Działanie złośliwej platformy


Schemat pracy na wstępnym etapie

Jak widać, cyberprzestępcy korzystają z całego inwentarza złośliwych narzędzi do skutecznego kontrolowania zdalnego komputera. Ponadto, podjęli oni środki ostrożności, aby ukryć swoje działania: wtyczki nie pojawiają się nigdzie, za wyjątkiem pamięci komputera; nie są zapisywane na dysku twardym; sterownik jest usuwany natychmiast po uruchomieniu; wszystkie ślady w rejestrze, które mogłyby wskazywać na uruchomienie złośliwego oprogramowania, są czyszczone. Jedynie początkowa biblioteka DLL pozostaje na dysku, ponieważ inicjuje ona cały proces i przechowuje zaszyfrowaną wersję biblioteki PlusDLL, która jest plikiem DLL sprawującym kontrolę. Jednym ze słabych punktów w tej architekturze jest to, że sterownik zostaje zapisany na dysku twardym przed uruchomieniem, więc produkty antywirusowe mogą wykryć pojawienie się tego pliku. Niemniej jednak, sytuację dodatkowo pogarsza fakt, że złośliwe sterowniki są podpisane (chociaż udało nam się wykryć pojedyncze próbki szkodliwego oprogramowania Winnti, które zawierały niepodpisane sterowniki). Niepodpisany sterownik sam w sobie nie ma środków do przeciwdziałania produktom antywirusowym, a jego kod może zostać łatwo rozpoznany jako szkodliwy, natomiast podpisane sterowniki mają większą szansę pozostać niewykrytymi przez produkty antywirusowe: niektóre produkty antywirusowe domyślnie uznają prawidłowo podpisane programy za legalne, aby w taki sposób zminimalizować ryzyko fałszywych alarmów.

Produkty Kaspersky Lab wykrywają złośliwe programy opisane powyżej: początkowe biblioteki DLL (winmm.dll iapphelp.dll), biblioteka sterująca (PlusDll.dll) i ładowane moduły funkcjonalne (CmdPlus.dll itd.) są wykrywane jakoBackdoor.Win32.Winnti lub Backdoor.Win64.Winnti. Sterowniki (sp1itter.sys i acplec.sys) są wykrywane jakoRootkit.Win32.Winnti lub Rootkit.Win64.Winnti.

Komunikacja z serwerem C&C

Dane, transmitowane podczas komunikacji między botem a serwerem C&C, oczywiście nie pojawiają się w żadnej wyraźnej formie ruchu danych w internecie. Ponieważ aktywny zdalny dostęp może generować znaczne ilości ruchu, cyberprzestępcy zdecydowali się na kompresję danych komunikacyjnych algorytmem LZMA, jednak nie zawarli oni odpowiedniego nagłówka, właściwego dla tego algorytmu. Dane są przesyłane po protokole TCP. Próbki, które analizowaliśmy ustanawiały połączenia pomiędzy serwerami C&C i portami 53, 80 oraz 443. Wybór tych portów nie jest zaskoczeniem: są one związane odpowiednio z protokołami DNS, HTTP i HTTPS. Wszystkie trzy porty są rutynowo używane podczas codziennej pracy, więc są one otwarte w niemalże wszystkich regułach zapór sieciowych. Poza tym, przez te porty zazwyczaj przechodzą duże ilości danych (no może za wyjątkiem portu 53), co znacznie ułatwia zachowanie niepozorności złośliwego ruchu sieciowego. Mimo iż porty są związane z pewnymi protokołami, nie koresponduje z nimi rzeczywista zawartość ruchu generowanego przez złośliwy program. Wczesne wersje platformy Winnti wykazywały następującą strukturę ruchu w komunikacji z serwerami C&C: każdy blok przesyłanych danych rozpoczynał się od magicznej liczby 0xdeadface, za którą występowała liczba bloków (wartość DWORD), następnie hash przesyłanego bloku (8 bajtów), rozmiar skompresowanych danych (DWORD), rozmiar danych źródłowych (DWORD) i w końcu – skompresowane dane.


Struktura jednostki bloku danych transmitowanych przez internet w wczesnych wersjach Winnti

Jest to miejsce, w którym ujawnia się kolejny słaby punkt backdoorów z rodziny Winnti. Dzięki takiej strukturze danych, szkodliwy ruch sieciowy mógł zostać łatwo dostrzeżony dzięki, na przykład, magicznej liczbie 0xdeadface. Cyberprzestępcy prawdopodobnie dość często tracili kontrolę nad komputerami ofiar, kiedy administratorzy systemu z pomocą systemów IDS / IPS wpadali na trop włamań poprzez analizę unikalnych nagłówków w pakietach danych i rozpoczynali czyszczenie sieci. W roku 2011 pojawiły się nowe wersje backdoorów Winnti, które mimo iż były wciąż oparte na tej samej platformie, zaczęły korzystać ze zaktualizowanego protokołu, który zawierał dodatkowe szyfrowanie komunikacji z C&C, więc przekazywane dane nie zawierały już w sobie statycznych oznaczeń. Przed wprowadzeniem szyfrowania, dane miały następującą strukturę (zresztą bardzo podobną do wcześniejszego formatu): pierwsze 4 bajty stanowiła magiczna liczba 0xaced1984, następnie wartość DWORD opisu pakietu, następnie DWORD o wartości zero, 8 bajtów hashu przesyłanego bloku, potem DWORD z wartością rozmiaru skompresowanych danych, DWORD z wartością rozmiaru danych źródłowych, a następnie skompresowane dane:


Struktura jednostki bloku danych transmitowanych przez internet w nowszych wersjach Winnti

Następnie spróbowano szyfrowania danych regularnym algorytmem XOR z losową wartością rozmiaru DWORD i przesyłania danych w takim formacie na serwer C&C. Wiedząc, że pierwsze cztery bajty danych źródłowych muszą stanowić wartość 0xaced1984, łatwo jest przywrócić klucz operacji XOR kiedy dane były szyfrowane.  Oto jak wyglądały powyższe dane (wartość XOR wynosiła 0x002a7b2e), kiedy zostały przechwycone w ruchu sieciowym:


Zaszyfrowany blok danych transmitowanych przez internet w nowszych wersjach Winnti

Ponieważ klucz szyfrowania (wartość, którą szyfrowane są dane źródłowe w operacji XOR) jest różny za każdym razem, gdy przesyłana jest część danych, w ruchu sieciowym nie pojawiają się statyczne, unikalne etykiety, które szybko pozwoliłyby zidentyfikować przekazywane dane jako pakiety należące do backdoora Winnti. Wykorzystując tę szybką i podstawową metodę cyberprzestępcy sprawili, że znacznie trudniej jest wykrywać ruch sieciowy generowany przez ich programy.

Niezależnie od tego, który protokół jest używany (z szyfrowaniem lub bez dodatkowego szyfrowania), przepływ komunikacji pomiędzy botem a serwerem C&C jest identyczny na początkowym etapie operacji:

  1. Bot wysyła pierwszy blok danych, sygnalizując w ten sposób swoją gotowość.
  2. W odpowiedzi serwer C&C przesyła listę dostępnych wtyczek.
  3. Bot rozpoczyna pobieranie wtyczek, wysyłając po jednym żądaniu dla każdej wtyczki. Na raz wysyłane jest tylko jedno żądanie.
  4. Serwer C&C przesyła wymaganą wtyczkę.
  5. Bot przesyła wiadomość, że wtyczka została odebrana.

Należy tu zauważyć, że w celu przyspieszenia pobierania danych, twórcy tej platformy dość umiejętnie wdrożyli w swoim protokole asynchroniczną transmisję danych. Dla przykładu, wiadomość, że bot otrzymał pierwszą wtyczkę zostanie dostarczona do serwera C&C kiedy niemal wszystkie wtyczki zostaną już wysłane do bota. Po pobraniu szkodliwego ładunku, bot wdraża wtyczki w pamięci i uruchamia je. Teraz, gdy wszystko jest gotowe do przejęcia całkowitej zdalnej kontroli nad komputerem ofiary, bot przełącza się w tryb uśpienia, oczekując na podłączenie operatora i podtrzymując komunikację poprzez wysyłanie co 15 sekund „pustych” wiadomości do serwera C&C. Oprócz dostarczania wtyczek, żadne inne automatyczne działania nie są wykonywane przez serwery C&C: wszystkie czynności na drodze zbadania zainfekowanych komputerów wykonywane są ręcznie przez samych napastników.