Nazywam się HDRoot! Część 1

Jakiś czas temu, śledząc aktywność grupy Winnti, natknęliśmy się na intrygującą próbkę.

Była ona chroniona przez komercyjny program wykonywalny VMProtect Win64, podpisany przy użyciu znanego, zhakowanego certyfikatu chińskiej organizacji Guangzhou YuanLuo Technology. Co więcej, właściwości tego programu wykonywalnego sugerowały, że jest to Net Command (net.exe) Microsoftu, i nawet po uruchomieniu próbki otrzymaliśmy dane wyjściowe typowe dla oryginalnego narzędzia net.exe:  

Podszywanie się pod net.exe

Wszystko to wskazywało, że próbka jest raczej podejrzana.

Bootkit

Ponieważ kod programu był chroniony, analiza jego funkcjonalności stanowiłaby żmudne zadanie. Na szczęście, zrzut ujawnił kilka unikatowych i dość istotnych ciągów oraz cztery kolejne próbki ukryte wewnątrz początkowej próbki: wersje Win32 i Win64 jednej biblioteki i jednego sterownika: 

Ciągi w kodzie szkodliwego oprogramowania

Ciągi te pozwoliły nam przypuszczać, że próbka ta stanowiła w rzeczywistości instalatora bootkita. Dzięki pewnym wyraźnym artefaktom znaleźliśmy podobną próbkę bez ochrony kodu, która potwierdziła nasze podejrzenia. 

Na początek, uruchommy to narzędzie:

Oryginalne dane wyjściowe HDD Rootkita

Parametry programu mówią same za siebie – narzędzie to instaluje bootkita, który infekuje system operacyjny na etapie rozruchu przy użyciu backdoora określonego jako parametr. Backdoor ten musi być programem wykonywalnym Win32 lub biblioteką dołączaną dynamicznie. 

Narzędzie to nosi nazwę „HDD Rootkit”; stąd też podstawa nazw naszego werdyktu HDRoot. 22 sierpnia 2006 r. numer wersji wynosił 1.2. 

Można zatem stwierdzić, że chroniona wersja stanowiła to samo narzędzie, zmodyfikowane w celu wykorzystania go po stronie ofiary, tak aby w przypadku wykrycia go przez kogoś spoza kręgu atakujących, nie został ujawniony cel tego narzędzia.

HDD Rootkit utrzymuje grupę zasobów, które również posiadają wiele mówiące nazwy:

Zasoby HDD Rootkita

Możemy przeczytać następujące informacje:  

„MBR” przechowuje pierwszy fragment szkodliwego kodu, który jest wstrzykiwany do rekordu MBR zainfekowanego komputera;

“BOOT” – drugi fragment szkodliwego kodu rozruchowego;
“RKIMAGE” – trzeci fragment szkodliwego kodu rozruchowego;  
“DLLLOAD” – dynamicznie dołączana biblioteka, która jest spychana przez szkodliwy kod rozruchowy do systemu plików oraz autouruchamianie systemu operacyjnego. 

Spróbujmy uruchomić jakiś program wykonywalny przy użyciu bootkita. W naszym eksperymencie rolę programu wykonywalnego odgrywa nieszkodliwy program, który nie robi nic poza utworzeniem pliku w folderze głównym na dysku C:. Spróbuję uruchomić go przy użyciu narzędzia HDD Rootkit z następującym poleceniem:      

hdroot.exe inst write_to_c.exe c:

wskazując, że chciałbym zainstalować bootkita na dysku C: który spowoduje uruchomienie programu write_to_c.exe podczas uruchomienia systemu.

Instalacja bootkita HDRoot na żywo

Narzędzie sprawdza, czy istnieje wolne miejsce na wskazanym dysku, i odmawia zainstalowania bootkita, gdy wartość ta jest mniejsza niż 30% całkowitego miejsca.

Sprawdzanie wolnego miejsca na dysku

A zatem bootkit został zainstalowany. Sprawdźmy, co się wydarzyło. Najpierw fragment kodu w głównym rekordzie rozruchowym jest zastępowany szkodliwym fragmentem z zasobu „MBR”:  

Zasób „MBR”

Dwa pierwsze bajty rozszerzonego sektora inicjującego EB 70 oznaczają przeskok do 72-go offsetu, gdzie zlokalizowana jest reszta pierwszego bloku kodu rozruchowego. Zera przed 0x70 i po 0xB0 oznaczają, że kod oryginalnego rekordu MBR na tych pozycjach pozostaje nietknięty. Poniżej przedstawiono załatany rekord MBR po zainstalowaniu bootkita:      

Szkodliwy kod wstrzyknięty do rekordu MBR

Pierwszy fragment ładuje następny blok kodu rozruchowego, który został umieszczony przez instalatora bootkita w 11 sektorze (Offset: 0x1400 bajtów). Drugi blok jest pobierany z zasobu „BOOT”.

Drugi blok rozruchowy

Bajt na ósmym offsecie drugiego bloku rozruchowego stanowi numer dysku, a kolejna wartość DWORD stanowi offset w sektorach, w których zlokalizowana jest kolejna część rozruchowa. Przykład ma wartość 0x80, która oznacza dysk 0 i offset 0x5FD9A0, co po pomnożeniu przez 0x200 bajtów (rozmiar sektora) daje 0xBFB34000. Jest to offset w bajtach względem początku dysku, gdzie instalator bootkita umieścił trzeci blok rozruchowy pobrany z jego zasobu „RKIMAGE”.  

Zasób „RKIMAGE” posiada duży fragment kodu, który implementuje wstrzykiwanie DLL (biblioteka DLL jest pobierana z zasobu „DLLLOAD”) do systemu plików i dokonuje zmian w rejestrze systemu, tak aby biblioteka DLL została załadowana i uruchomiona wraz ze startem systemu. Ponieważ ten fragment kodu jest wykonywany na wczesnym etapie rozruchu, nie istnieje żaden interfejs API w celu uzyskania dostępu do systemu plików, a kod samodzielnie analizuje systemy plików (FAT32 i NTFS).     

Obsługiwane systemy plików

Szkodnik szuka zakodowanego na sztywno specjalnego pliku, którego zawartość jest zastępowana biblioteką DLL pobieraną z określonego miejsca na dysku. Większość znalezionych przez nas wersji HDRoota wykorzystuje do tych celów plik %windir%\WMSysPr9.prx. Czasami biblioteka DLL nadpisuje jakąś istniejącą bibliotekę systemową, co z pewnością nie jest bezpiecznym sposobem działania szkodliwego oprogramowania, ponieważ w niektórych przypadkach może spowodować awarię systemu operacyjnego i powiadomić użytkownika o infekcji. Wśród plików, które mogą zostać wykorzystane do nadpisania, zauważyliśmy:     

%windir%\twain.dll
%windir%\msvidc32.dll
%windir%\help\access.hlp
%windir%\help\winssnap.hlp
%windir%\system\olesvr.dll
%windir%\syswow64\C_932.NLS
%windir%\syswow64\C_20949.NLS
%windir%\syswow64\dssec.dat
%windir%\syswow64\irclass.dll
%windir%\syswow64\msvidc32.dll
%windir%\syswow64\kmddsp.tsp

Następnie, kod odczytuje zawartość pliku %windir%\system32\config\system, który przechowuje zawartość gałęzi rejestru HKEY_LOCAL_MACHINE\SYSTEM. Gałąź rejestru zawiera między innymi informacje dotyczące zainstalowanych usług. Wiele usług systemowych jest uruchamianych podczas logowania się do systemu operacyjnego jako ServiceDll za pośrednictwem svchost.exe, gdzie ścieżka do biblioteki funkcji, która ma zostać uruchomiona, zostaje określona w wartości rejestru ServiceDll dla określonej usługi. Szkodliwy kod rozruchowy wyszukuje w pliku „system” zakodowaną na sztywno ścieżkę do biblioteki systemowej   powiązanej z usługą systemową i zastępuje tę wartość ścieżką do wstrzykniętej biblioteki DLL (np. %windir%\WMSysPr9.prx). We wszystkich wersjach, jakie napotkaliśmy, ustaliliśmy, że HDRoot wykorzystał następujące usługi:   

A zatem, gdy system operacyjny zaczyna uruchamiać usługi, zamiast załadować oryginalną usługę DLL svchost.exe, ładuje szkodliwą. Ta szkodliwa biblioteka nie robi nic poza ładowaniem i uruchamianiem backdoora pobieranego z wyznaczonego offsetu na dysku twardym, gdzie umieścił go instalator HDD Rootkit. Znaleźliśmy dwie wersje HDRoota, które wykonują tę czynność przy użyciu różnych metod. Pierwsza z nich zapisuje jedynie backdoora jako plik %windir%\temp\svchost.exe i wykonuje go z pomocą funkcji API WinExec. Wszystko wskazuje na to, że autor tego szkodliwego oprogramowania uznał później, że nie jest to najlepszy sposób uruchamiania backdoora, ponieważ jest on widoczny dla rozwiązań antywirusowych, a fakt uruchomienia aplikacji może zostać zauważony podczas sprawdzania zdarzeń w logach systemu. Inna wersja biblioteki DLL nie umieszcza pliku, ale alokuje backdoora w pamięci, przygotowuje go do właściwego wykonania (ładuje biblioteki zgodnie z tabelą importu) i uruchamia go tam samodzielnie. Podejście to jest bardziej utajnione, ponieważ znacznie zmniejsza szanse wykrycia backdoora nawet w przypadku zidentyfikowania biblioteki DLL lub zatrutego rekordu MBR.       

Powracając do naszego eksperymentu, gdy zostanie wykonane polecenie

hdroot.exe inst write_to_c.exe c:

uruchamiamy ponownie system operacyjny. Po tym, jak zostanie załadowany, możemy zobaczyć wynik uruchomienia naszego programu write_to_c.exe, który zachowuje się, jak gdyby był backddorem: 

Stworzony plik testowy zzz.bin

Plik C:\zzz.bin jest widoczny od razu po załadowaniu się systemu Windows, co potwierdza, że program write_to_c.exe został poprawnie wykonany. 

Cały proces infekcji HDRoota wygląda następująco:

Schemat działania HDRoota

Co ciekawe, szkodnik ten nie posiada funkcjonalności uruchamiania oryginalnej usługi, która została podmieniona podczas procesu rozruchu. Ponieważ „zainfekowane” usługi są częścią systemu operacyjnego, zaniechanie tej czynności mogłoby spowodować niewłaściwe działanie systemu Windows i zdradzić infekcję. Jest to jeszcze dziwniejsze, zważywszy na to, że szkodliwe oprogramowanie próbuje zatrzeć swoje ślady. „Próbuje”, gdyż tak naprawdę nie udaje mu się to. Umieszczona biblioteka DLL posiada funkcję przywracania oryginalnej wartości ServiceDll w rejestrze, przechowując ścieżkę do biblioteki DLL związanej z tą usługą. Jednak z powodu zawierającego błędy kodu w trzecim bloku rozruchowym (od „RKIMAGE”), który w niewielkim stopniu łata zawartość „DLLLOAD” przed wstrzykiwaniem, biblioteka DLL zaczyna przechowywać niewłaściwe dane na zakodowanych na sztywno offsetach i uniemożliwia bibliotece DLL znalezienie poprawnej ścieżki rejestru do ServiceDll w celu przywrócenia oryginalnej wartości. To dlatego, na przykład, po zalogowaniu się do system Windows nadal widoczny jest “C:\WINDOWS\WMSysPr9.prx” zamiast “C:\WINDOWS\system32\wuauserv.dll”

Ścieżka prowadzi do wstrzykniętej szkodliwej biblioteki DLL w rejestrze

Błędna ścieżka rejestru i nazwa wartości

Rejestr SubKey omyłkowo nadpisany pierwotną wartością ServiceDll

Należy stwierdzić, że szkodliwe oprogramowanie zostało stworzone dość niedbale, co nie pasuje do tak poważnego ugrupowania stosującego ataki APT jak Winnti. Zauważyliśmy jednak, że autor tego szkodnika starał się, aby bootkit działał poprawnie na etapie rozruchu, aby nie dopuścić do całkowitego uniemożliwienia załadowania systemu operacyjnego. Jednak wspomniane wyżej błędy stanowią dość wyraźne oznaki infekcji na komputerze. Na przykład, nie działają oryginalne usługi, takie jak Windows Update czy Harmonogram zadań, ale wygląda na to, że nikt tego nie zauważył.        

Podczas dochodzenia wykryliśmy kilka backdoorów wykorzystywanych przez bootkita Windows Update do infekowania systemów operacyjnych. Te szkodliwe programy zostaną opisane w kolejnej części naszego artykułu.