Czym jest RootkitRevealer: jak działa, jak go używać i jakie są oznaki rootkitów

Informatec Digital » Bezpieczeństwo » Czym jest RootkitRevealer: jak działa, jak go używać i jakie są oznaki rootkitów

RootkitRevealer to jedno z tych legendarnych narzędzi, które powinien znać każdy profesjonalista korzystający z systemu Windows. Stworzył je zespół Sysinternals pod kierownictwem Marka Russinovicha i choć powstało wiele lat temu, nadal stanowi punkt odniesienia dla osób, które chcą zrozumieć, jak wykrywać rozbieżności między informacjami wyświetlanymi przez system, a tym, co faktycznie znajduje się na dysku, spowodowane przez rootkity .

W przeciwieństwie do innych skanerów, nie szuka on sygnatur ani wzorców: porównuje ogólny widok interfejsu API systemu Windows z surowym, niskopoziomowym odczytem dysku i rejestru. Ten pozornie prosty pomysł ujawnia, kiedy złośliwe oprogramowanie próbuje ukryć pliki, klucze lub wartości, manipulując wywołaniami systemowymi.

Czym jest RootkitRevealer i na jakich systemach działa?

To zaawansowane narzędzie do wykrywania oznak rootkitów zarówno w trybie użytkownika, jak i jądra . Zostało pierwotnie opracowane dla systemów Windows XP i Windows Server 2003 (32-bit) i jest powszechnie oferowane jako darmowe, w wersji anglojęzycznej i o rozmiarze około 231 KiB; wiele ofert wskazywało również na jego zgodność z systemami Windows NT/2000/XP/Vista w tamtym czasie.

Z czasem jego wersja działająca wyłącznie w wierszu poleceń została wyeliminowana, ponieważ niektórzy twórcy złośliwego oprogramowania zaczęli monitorować nazwy plików wykonywalnych. Aby tego uniknąć, program jest uruchamiany jako usługa z losowo nazwanej kopii samego siebie, co utrudnia wykrywanie po nazwie i komplikuje zapewnienie w 100% interfejsu konsoli.

Czym jest rootkit? Kluczowe pojęcia

Termin rootkit odnosi się do technik i mechanizmów, które pozwalają złośliwemu oprogramowaniu (wirusom, trojanom, oprogramowaniu szpiegującemu itp.) ukryć się przed użytkownikiem i narzędziami bezpieczeństwa . Wyróżnia się kilka rodzin rootkitów: trwałe (przetrwające ponowne uruchomienie), rezydentne (znikające po ponownym uruchomieniu), działające w trybie użytkownika i działające w trybie jądra, a także inne współczesne warianty.

Rootkit w trybie użytkownika może przechwytywać funkcje takie jak FindFirstFile/FindNextFile lub natywne enumeratory systemu, aby filtrować wpisy, które mogłyby ujawnić zmodyfikowane pliki, procesy lub klucze rejestru . Uniemożliwia to Eksploratorowi Windows, wierszowi poleceń lub edytorom rejestru sprawdzenie, co faktycznie istnieje.

Rootkity trybu jądra idą jeszcze dalej: oprócz przechwytywania natywnego API, mogą one bezpośrednio manipulować strukturami jądra, na przykład usuwając swój proces z listy aktywnych procesów, tak aby nie pojawiał się w Menedżerze zadań ani Eksploratorze procesów, nawet jeśli jest uruchomiony.

Istnieją hybrydy (częściowo oparte na użytkowniku, a częściowo na jądrze), oprogramowanie układowe (BIOS/UEFI i inne komponenty), boot lub bootkit (MBR/UEFI), wirtualne (umieszczające rzeczywisty system operacyjny w maszynie wirtualnej) oraz oparte na pamięci (nietrwałe). Te ostatnie bywają szczególnie trudne do uchwycenia, podczas gdy oprogramowanie układowe i bootloadery pozostają na dysku nawet po czystej reinstalacji systemu operacyjnego.

Jak działa RootkitRevealer

RKR zestawia ze sobą dwie migawki: widok wysokiego poziomu interfejsu API systemu Windows oraz surowy, niskopoziomowy odczyt plików poddrzewa woluminów i rejestru (hive). Jeśli rootkit manipuluje wywołaniami wysokiego poziomu, aby coś ukryć, zmiana ta zostaje ujawniona, ponieważ dane na dysku i w rejestrze nie zgadzają się z danymi API, generując możliwe do zdiagnozowania rozbieżności.

Teoretycznie rootkit mógłby również próbować ukryć się przed RootkitRevealer, przechwytując jego surowe odczyty i przepisując dane „w locie”. Aby to osiągnąć, potrzebowałby dogłębnej znajomości formatów NTFS, FAT i rejestru oraz umiejętności modyfikowania struktur bez powodowania niespójności lub oczywistych efektów ubocznych – niezwykle złożonego zadania technicznego , które rzadko się zdarza. Mimo to nie istnieje niezawodny „uniwersalny detektor”: nawet uruchomienie systemu z zewnętrznego środowiska (na przykład z użyciem najlepszych dystrybucji Linuksa ) może zostać sabotowane przez szczególnie zaawansowane i trwałe artefakty . W praktyce najskuteczniejszym podejściem jest połączenie analizy online z weryfikacją offline w zaufanych środowiskach.

Wymagania, dobre praktyki i realizacja

Aby uruchomić to skanowanie, konto musi mieć uprawnienia „Tworzenie kopii zapasowych plików i katalogów”, „Ładowanie sterowników” oraz „Konserwacja woluminów” (są one domyślnie przyznawane administratorom w systemie Windows XP i nowszych). Aby zminimalizować liczbę fałszywych alarmów, zaleca się uruchomienie skanowania przy wyłączonym systemie i bez otwartych aplikacji.

W trybie ręcznym wystarczy nacisnąć przycisk skanowania. W trakcie procesu program będzie na bieżąco informował o postępach i wyświetlał wszelkie rozbieżności. Dostępne są dwie istotne opcje: „Ukryj pliki metadanych NTFS” (domyślnie włączona, aby uniknąć wyświetlania standardowych metadanych ukrytych przez NTFS) oraz „Dziennik skanowania” (domyślnie włączona; odznaczenie tej opcji spowoduje pominięcie skanowania rejestru systemu Windows ).

W celu automatyzacji obsługuje parametry umożliwiające uruchamianie, logowanie i wychodzenie bez interwencji: rootkitrevealer outputfile]. Opcja -a rozpoczyna się i kończy automatycznie; -c wyświetl wynik w formacie CSV; -m wyświetla metadane NTFS; i -r wyłącza skanowanie rejestru. Plik wyjściowy musi znajdować się w dostępny wolumin lokalny.

Zdalne wykonywanie jest możliwe dzięki PsExec. Na przykład: psexec \\remote -c rootkitrevealer.exe -a c:\windows\system32\rootkit.log. Z -cpostęp nie jest wyświetlany, a rozbieżności są drukowane w pliku CSV, co ułatwia importowanie w bazach danych lub skryptach.

Interpretacja wyników i typowe rozbieżności

Rozbieżności typu „Ukryte przed API systemu Windows” są najczęstsze, gdy rootkit ukrywa wpisy. Jeśli nie włączono wyświetlania metadanych NTFS, różnice będą widoczne, ponieważ NTFS ukrywa swoje pliki wewnętrzne, takie jak $MFT lub $Secure , przed API . Niektóre programy antywirusowe również przechowują dane w strumieniach alternatywnych i ukrywają je, co powoduje podobne błędy.

Oto niektóre standardowe metadane zdefiniowane w systemie NTFS (Windows Server 2003): $AttrDef, $BadClus, $BadClus:$Bad, $BitMap, $Boot, $LogFile, $Mft, $MftMirr, $Secure, $UpCase, $Volume, $Extend, $Extend\$Reparse, $Extend\$ObjId, $Extend\$UsnJrnl, $Extend\$UsnJrnl:$Max, $Extend\$Quota.

RKR koreluje trzy źródła w systemie plików: interfejs API systemu Windows, główną tabelę plików (MFT) oraz indeksy katalogów na dysku. Mogą pojawić się kombinacje takie jak „Widoczne w interfejsie API, ale nie w indeksie ani w MFT”, „Widoczne w MFT, ale nie w API” itd., zwłaszcza jeśli plik zostanie utworzony lub usunięty podczas analizy i spowoduje to chwilową niespójność.

Przykład tworzenia podczas skanowania: C:\newfile.txt, o rozmiarze 8 bajtów, z komunikatem „Widoczne w API, ale nie w indeksie ani MFT”. Te przypadki niekoniecznie wskazują na rootkity, ale na zmiany współbieżne podczas badania.

Jeżeli pojawia się komunikat „Dostęp zabroniony”, coś jest nie tak: RootkitRevealer używa mechanizmów umożliwiających dostęp do dowolnego pliku, katalogu lub klucza, więc ten komunikat nie powinien pojawić się podczas normalnego działania programu.

W Rejestrze występuje kilka interesujących rozbieżności: „Długość interfejsu API systemu Windows jest niezgodna z surowymi danymi” (możliwa próba ukrycia faktycznej zawartości), „Niezgodność typu” (np. reklamowany jest REG_SZ, a powinien być REG_BINARY), „Nazwa klucza zawiera osadzone wartości NULL” (znana technika wykorzystująca różnicę między ciągami zakończonymi znakiem NULL a ciągami z liczbami). W tym ostatnim przypadku narzędzie RegDelNull firmy Sysinternals pomaga oczyścić klucze z osadzonymi wartościami NULL.

„Niezgodność danych” może wystąpić, jeśli wartość ulegnie zmianie podczas skanowania (np. w przypadku problemów z dostępnością serwera SQL Server, takich jak HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\RECOVERYMANAGER\MSSQLServer\uptime_time_utc). Musisz sprawdzić, czy wartość należy do legalne komponenty które aktualizują dane w czasie rzeczywistym.

Przykładem ilustrującym ten problem jest rootkit HackerDefender: jego usługi i sterowniki były niewidoczne dla interfejsu API systemu Windows, ale były obecne w surowym odczycie gałęzi rejestru; to samo dotyczyło jego plików, które zostały wykryte na dysku podczas bezpośredniej analizy systemu plików.

Typowe błędy i problemy z rootkitrevealer.exe w środowiskach kryminalistycznych

Niektóre zestawy narzędzi do analizy kryminalistycznej (np. WinTaylor) wymieniają typowe błędy związane z rootkitrevealer.exe , takie jak: „to nie jest prawidłowa aplikacja Win32”, „nie znaleziono”, „błąd aplikacji” lub „problem z uruchamianiem”. Komunikaty te pojawiają się zazwyczaj podczas instalacji, uruchamiania lub zamykania systemu albo w przypadku konfliktów z innymi aplikacjami rezydentnymi.

Najczęstszymi przyczynami są uszkodzone lub brakujące pliki, nieprawidłowe wpisy w rejestrze, infekcje złośliwym oprogramowaniem, niekompletne odinstalowania lub konflikty z innym oprogramowaniem. Źródłem może być uszkodzony wpis w rejestrze, przypadkowe usunięcie przez inne narzędzie, nieudane pobieranie lub wcześniejsza infekcja , która zmieniła plik binarny.

Jako ciekawostkę dotyczącą inwentaryzacji, niektóre listy dokumentują plik wykonywalny o przybliżonym rozmiarze 334 720 bajtów i skróty takie jak SHA‑1 i MD5 (np. SHA‑1 d39e8a3fe92adc7d7fbc5293edf8a7b965484a59, MD5 ee738fe9bcdd605821002cec8c7206db) i CRC32 98b1af0b; odnoszą się również do wersja 2.1 w aplikacji kontenerowej oraz w kategorii „Narzędzia kryminalistyczne/System operacyjny”.

Metody wykrywania i reagowania na rootkity

Wykrycie rootkita nie zawsze jest proste. Oprócz specjalistycznych narzędzi, w celu identyfikacji podejrzanych modułów stosuje się również techniki takie jak analiza sygnatur znanych zagrożeń, zimne porównywanie struktur, przeszukiwanie pamięci pod kątem haków i modyfikacji oraz przegląd zrzutów pamięci po awariach . Powszechne jest również poleganie na systemach zapobiegania włamaniom (IPS) w celu ochrony sieci i ograniczenia wektorów infekcji.

Wśród specjalistycznych narzędzi znajdują się GMER (do wykrywania ukrytych procesów i modyfikacji jądra), Kaspersky TDSSKiller (w szczególności do wykrywania bootkitów i rootkitów jądra), Malwarebytes Anti-Rootkit, Microsoft Defender Offline (do skanowania przed uruchomieniem systemu Windows) oraz RogueKiller. Uruchamianie ich z zaufanego rozruchowego dysku USB lub w trybie awaryjnym zmniejsza powierzchnię ataku.

W przypadku zagrożeń rozruchu lub oprogramowania sprzętowego zaleca się użycie nośnika ratunkowego, takiego jak Kaspersky Rescue Disk, i przywrócenie MBR za pomocą bootrec /fixmbr w razie potrzeby i w poważnych przypadkach zaktualizuj/przeprogramuj BIOS/UEFI do czystej wersji od producenta, aby wyeliminować trwałość niskiego poziomu.

Monitorowanie za pomocą Sysinternals jest nieocenione: Monitor Procesów (ProcMon) do monitorowania aktywności procesów i plików, Autoruns do sprawdzania, co się ładuje podczas uruchamiania, oraz RootkitRevealer do wykrywania rozbieżności wysokiego/niskiego poziomu. Platformy SIEM, takie jak Wazuh , oraz telemetria w środowiskach korporacyjnych mogą wykrywać nieoczekiwane zachowania sieci lub zmiany integralności.

Jeśli infekcja zostanie potwierdzona, rozsądna kolejność działań jest następująca: odłącz komputer od sieci, przeskanuj go z poziomu środowiska zewnętrznego, oceń integralność oprogramowania rozruchowego/firmware'owego, a jeśli nie ma gwarancji, wykonaj kopię zapasową danych, dokładnie wyczyść dysk (narzędziami takimi jak DBAN) i zainstaluj system ponownie ze zweryfikowanego nośnika, a następnie włącz zabezpieczenia takie jak Secure Boot i TPM.

Zapobieganie: rozsądna ochrona przed rootkitami

Zapobieganie jest kluczowe. Aktualizuj system, stosuj poprawki do oprogramowania innych firm, unikaj plików wykonywalnych z wątpliwych źródeł i nie używaj cracków ani keygenów: są one ulubionym wektorem pakowania dropperów i loaderów rootkitów .

Wyłącz automatyczne uruchamianie USB, skanuj dyski zewnętrzne przed ich otwarciem, a w środowiskach korporacyjnych ogranicz lub zablokuj porty i stosuj zapory sieciowe w razie potrzeby. Pracuj z kontami użytkowników bez uprawnień, stosuj zasadę najmniejszych uprawnień i wymagaj uprawnień administratora do wprowadzania krytycznych zmian, zmniejszając prawdopodobieństwo cichej eskalacji.

Na kompatybilnym sprzęcie włącz Secure Boot i TPM z poziomu UEFI, aby chronić łańcuch rozruchowy i klucz zabezpieczający. Regularnie twórz kopie zapasowe offline lub niezmienne i korzystaj z migawek/punktów przywracania, aby skrócić czas odzyskiwania w razie awarii.

Jak instaluje się rootkity: droppery, loadery i wektory

Atakujący zazwyczaj dystrybuują rootkity jako zagrożenia łączone: „dropper”, który dostarcza pakiet, oraz „loader”, który wykorzystuje luki w zabezpieczeniach (takie jak przepełnienia bufora), aby umieścić implant w niewłaściwym miejscu. Jest to maskowane pod postacią wiadomości phishingowych , fałszywych instalatorów lub fałszywych aktualizacji.

Do klasycznych wektorów ataku zalicza się przejmowanie kontroli nad klientami komunikatorów w celu rozprzestrzeniania złośliwych łączy, instalowanie oprogramowania trojańskiego na portalach pobierania, wykorzystywanie innego złośliwego oprogramowania jako nośnika oraz osadzanie w dokumentach o bogatej zawartości (np. niektórych plikach PDF), które po otwarciu automatycznie uruchamiają droppera.

Oznaki ataku i wskazówki dotyczące wykrycia

Celem rootkita jest pozostanie niewykrytym. Mimo to można zaobserwować zmiany konfiguracji bez interwencji użytkownika, nietypowe przerwy w działaniu sieci spowodowane ukrytym ruchem, nieznane procesy, usługi, których nie można zamknąć, oraz narzędzia bezpieczeństwa wyłączone bez wyjaśnienia.

Kolejną wskazówką są sprzeczne informacje między narzędziami, które wyświetlają pliki, procesy lub klucze rejestru, korzystając z różnych ścieżek (odczyt API lub odczyt surowych danych). To właśnie tutaj sprawdzają się podejścia takie jak RootkitRevealer: ten sam obiekt, który „jest” na dysku, ale „nie ma go” zgodnie z API, wskazuje na manipulację.

Główne typy rootkitów

Tryb użytkownika: Działają na poziomie procesów i bibliotek. Są bardziej stabilne i stosunkowo łatwiejsze do wykrycia, choć mogą ukrywać pliki, procesy i klucze. Klasycznym historycznym przykładem jest HackerDefender.

Tryb jądra: Wirusy te rezydują w jądrze, zapewniając pełną kontrolę i wysoki poziom ukrycia; są trudne do wyeliminowania i mają tendencję do powodowania niestabilności, jeśli są źle zaprojektowane. Przykładami tej rodziny są TDL/Alureon w jego ewolucji.

Hybrydy: łączą komponenty użytkownika i jądra w celu zapewnienia równowagi między ukryciem a stabilnością, co przekłada się na popularność wśród atakujących ze względu na ich praktyczną wszechstronność.

Oprogramowanie układowe/bootkity: Infekują one BIOS/UEFI lub sektor rozruchowy (MBR/UEFI), aby załadować się przed systemem operacyjnym. Technologie takie jak Secure Boot sprawiły, że wiele klasycznych bootkitów stało się przestarzałych, ale pojawiły się nowoczesne implanty UEFI.

Wirtualne i oparte na pamięci: VMBR ładują hiperwizor pod systemem operacyjnym i wirtualizują go; te oparte na pamięci znajdują się tylko w pamięci RAM i znikają po ponownym uruchomieniu, co jest bardzo przydatne w przypadku operacji efemerycznych.

Przykłady i wyróżniona chronologia

Pierwsze rootkity dla SunOS opracowano w latach 90. XX wieku. W 1999 r. Greg Hoglund opisał NTRootkit (Windows, tryb jądra), a w 2003 r. pojawił się HackerDefender (Windows 2000/XP, tryb użytkownika), co zapoczątkowało „przeciąganie liny” z narzędziami takimi jak RootkitRevealer.

W 2004 r. w tzw. greckim Watergate wykorzystano rootkita do włamania się do ponad 100 telefonów w sieci GSM; w 2005 r. odkryto, że firma Sony BMG umieściła rootkita chroniącego przed piractwem na niektórych płytach CD, co wywołało ogromne kontrowersje dotyczące bezpieczeństwa.

Od 2008 r. ewoluowały bootkity takie jak TDL (od TDL-1 do TDL-4); w 2009 r. „Machiavelli” udowodnił, że macOS (wówczas Mac OS X) również nie był odporny; w 2010 r. Stuxnet wykorzystał komponenty rootkita do sabotażu irańskich systemów przemysłowych.

W 2012 r. pojawił się Flame , ogromne modułowe złośliwe oprogramowanie ; w 2018 r. LoJax stał się pierwszym wykrytym na wolności rootkitem UEFI; a w 2019 r. Scranos połączył kradzież danych uwierzytelniających i ukryte generowanie przychodów z farmami kliknięć za pośrednictwem masowo zainfekowanych przeglądarek.

Zasoby i polecane lektury

Śledztwo Marka Russinovicha w sprawie Sony oraz jego artykuł „Unearthing Rootkits” w Windows IT Pro pomagają zrozumieć zjawisko i technikę stojącą za RKR; książka „Rootkits: Subverting the Windows Kernel” autorstwa Grega Hoglunda i Jamiego Butlera jest najbardziej dogłębnym opracowaniem na ten temat.

Materiały niezbędne dla każdego, kto chce głębiej zgłębić temat architektury i poważnych środków zaradczych, to Phrack Archive, „The Art of Computer Virus Research and Defense” Petera Szora, „Malware: Fighting Malicious Code” Eda Skoudisa i Lenny’ego Zeltsera oraz seria „Windows Internals” (od czwartego wydania ).

RootkitRevealer w ekosystemie Sysinternals

RKR współistnieje z innymi narzędziami Sysinternals przydatnymi podczas badań: AccessChk i AccessEnum (uprawnienia efektywne), Autoruns (wszystko, co zaczyna się w systemie), Process Explorer (kto co otworzył i za pomocą której biblioteki DLL), PsExec/PsTools (zdalne wykonywanie i administrowanie), PsLogList i PsLoggedOn (zdarzenia i sesje), Sigcheck (podpisy cyfrowe), SDelete (bezpieczne usuwanie), ShareEnum (zasoby współdzielone) i Sysmon (zaawansowana telemetria w dzienniku zdarzeń).

W historycznych repozytoriach często można znaleźć odniesienia do „Pobierz 1.71”, a także do „Uruchom teraz” w Sysinternals Live. Chociaż projekt jest weteranem, jego podejście – porównywanie podejść wysokiego i niskiego poziomu – pozostaje kluczowe w polowaniu na rootkity.

RootkitRevealer jest przede wszystkim lekcją inżynierii defensywnej: jeśli coś manipuluje informacjami zwracanymi przez API, należy zajrzeć pod spód i porównać to z tym, co faktycznie znajduje się na dysku i w rejestrze. Dzięki dobrym praktykom, właściwym narzędziom i weryfikacji offline, gdy jest to konieczne, można odkryć, co próbuje się ukryć tam, gdzie nikt nie zajrzy.