Ewolucja złośliwego oprogramowania 2008

Przeczytaj także: Ewolucja złośliwego oprogramowania I-VI 2008

Rootkity

W 2008 roku miały miejsce dwa główne zdarzenia związane z rootkitami. Pierwszym z nich była analiza niesławnego rootkita Rustock.c. O rootkicie tym głośno było nie tyle ze względu na wykorzystane w nim technologie, co pogłoski na temat niemożności zidentyfikowania go. Drugim wydarzeniem było pojawienie się na wolności ogromnej liczby wariantów bootkita (Sinowal). Kaspersky Lab klasyfikuje rootkita Rustock.c jako Virus.Win32.Rustock.a ze względu na jego zdolność infekowania plików.

Rustock.c: trendy

1. Infekowanie plików jako metoda autostartu.

Metoda infekowania plików wykorzystana przez rootkita Rustock.c przypomina metodę stosowaną przez standardowe wirusy plikowe. Jedyna różnica polega na tym, że Rustock.c infekuje sterownik systemowy, co daje mu kilka przewag pod względem maskowania swojej aktywności. Rootkit nie wykorzystuje osobnego sterownika, dlatego nie ma potrzeby ukrywania go ani na dysku twardym, ani w pamięci. Nie trzeba również ukrywać skojarzonego z nim klucza rejestru. Oprócz ukrycia obecności rootkita w systemie zainfekowanie sterownika systemowego utrudnia wyczyszczenie zainfekowanej maszyny. Jeżeli komputer jest zainfekowany standardowym rootkitem, wystarczy tylko usunąć komponenty rootkita z dysku twardego. Jednak w tym przypadku do przywrócenia zainfekowanego sterownika niezbędna jest kopia zapasowa lub wykorzystane rozwiązanie antywirusowe musi zawierać procedurę leczenia.

2. Personalizacja rootkita oraz połączenie z komponentami sprzętowymi.

Jedną z istotnych cech rootkita Rustock.c jest to, że dropper rootkita przechwytuje informacje systemowe dotyczące zaatakowanych maszyn i wysyła je do serwera internetowego, gdzie na podstawie otrzymanych danych tworzone jest ciało rootkita. Zaszyfrowane ciało rootkita jest następnie wysyłane do droppera. Połączenie z komponentami sprzętowymi, wraz z szyfrowaniem ciała rootkita oraz technikami zapobiegającymi emulacji zintegrowanymi w rootkicie, utrudniają zarówno automatyczne wykrywanie jak i analizę.

Techniki zaimplementowane w rootkicie Rustock.c były dalej rozwijane. W grudniu 2008 roku wykryto występującą na wolności próbkę tego rootkita (obecnie firma Kaspersky Lab klasyfikuje ją jako Trojan.Win32.Pakes.may), która wykorzystuje tę samą technikę. Rootkit ten infekuje sterownik systemowy ndis.sys w czasie pobierania zaszyfrowanego ciała rootkita z panda-server.ru. Kod, który infekuje ndis.sys, jest zaszyfrowany. Podczas pobierania uruchamiany jest specjalny kod, który deszyfruje sterownik i przekazuje mu kontrolę. Wspomniana próbka implementuje wszystkie główne technologie wykorzystane w rootkicie Rustock.c: zaszyfrowane ciało rootkita jest pobierane ze strony cyberprzestępców, w celu ochrony rootkita przed analizą wykorzystywana jest kryptografia oraz techniki zapobiegające debugowaniu. Rootkit ten działa również w sposób podobny do Rustocka; wysyła spam poprzez wstrzykiwanie do procesów systemowych kodu, który pobiera szablony i parametry masowych wysyłek. Kod ten przeprowadza również masowe wysyłki.

Bootkity

Próbki bootkita (proof of concept lub wersje demonstracyjne), które skutecznie implementowały wykorzystane technologie, pojawiły się w latach 2005-2006, po publikacji materiałów znanych jako eEye Bootroot. Występujące na wolności próbki rootkitów były wykrywane w 2007 roku, a ich największa liczba pojawiła się w 2008 roku. Najsławniejszym bootkitem jest Trojan-Spy.Win32.Sinowal. Bootkit ten wykorzystuje koncepcję podobną do tej wykorzystywanej przez wirusy sektora rozruchowego z ery DOS-a. Bootkit infekuje sektor rozruchowy lub sektor MBR dysku systemowego, co pozwala mu przejąć kontrolę, zanim zostanie załadowane jądro systemu operacyjnego i uruchomiony program antywirusowy. Po przejęciu kontroli bootkit lokalizuje się w przestrzeni adresowej jądra i maskuje swoje sektory na dysku. Wykorzystywane są do tego klasyczne metody, zwykle filtrowanie pakietów IRP. Dropper bootkita otwiera dysk w trybie odczytu/zapisu sektora, co pozwala na wykrywanie takich operacji przy użyciu emulacji, systemu oceny zagrożeń lub systemu HIPS/PDM, a następnie blokowanie droppera.