Przykład na to, dlaczego narzędzia wykorzystywane do badania systemu nie powinny (zbytnio) modyfikować jego stanu.
Jak szukałem rootkita i znalazłem RootkitRevealer
Badając wspomnianego wcześniej rootkita postanowiłem znaleźć wszystkie pliki wykonywalne, które zostały utworzone w okolicach utworzenia podejrzanego wpisu w rejestrze. Zrobiłem sobie obraz dysku badanego systemu, załadowałem go do ProDiscover Basic, wyszukałem plików stworzonych po określonej dacie wykorzystując do tego charakterystyczny nagłówek plików wykonywalnych. Jednym ze znalezionych plików był plik o obiecującej nazwie LXRWGLKX.exe. Przeszukanie pliku rejestru pokazało, że istnieje usługa LXRWGLKX, która korzysta z tego pliku: Image: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\LXRWGLKX.exe. Sposób rozumowania był prosty - usługa o podejrzanej nazwie, proces nie występuje w zrzutach - musi być ukryty przez rootkita, czyli trzeba spróbować znaleźć ukryte procesy. Próba pierwsza z wykorzystaniem CsrWalker zakończyła się niepowodzeniem. Drugie podejście to zrzut pamięci fizycznej komputera (win32dd) i wyszukiwanie w nim procesów za pomocą Volatility również zakończyło się niepowodzeniem.
Po odzyskaniu podejrzanego pliku z obrazu pierwsza rzecz, która rzuciła się w oczy, to podejrzanie znajoma ikonka... Tak, ten plik, to RootkitRevealer, a właściwie jego część. Dlaczego RootkitRevealer zachowuje się w ten sposób? Jego zasada działania jest prosta - narzędzie to szuka różnic między obrazem systemu (system plików, rejestr), który może uzyskać korzystając z API systemu, a obrazem, który tworzy sam (bez wykorzystania funkcji API "modyfikowanych" przez rootkity). Rootkit chcąc "ukryć" się przed RootkitRevealer po prostu nie chowa się przed nim - nie ma różnic w obrazie, nie ma czego raportować. RootkitRevealer stara się ukryć przed rootkitem swoje działanie. Tworzy swoją kopię o losowej nazwie, tworzy usługę i dopiero w ten sposób uruchamia właściwy proces skanujący. Ślad pozostawiony w systemie jest wyraźny, ale przy okazji trudny (przynajmniej na pierwszy rzut oka) do odróżnienia od działania malware, w końcu tworzenie plików o losowych nazwach i tworzenie nowych usług jest typowym zachowaniem zwykle właśnie dla tych złych programów...
Z tych samych powodów nie używam narzędzia Gmer, nie dlatego, by było to złe narzędzie, ale nie podoba mi się kopiowanie plików do %systemroot% i %systemroot%\system32\drivers. W tym wypadku co prawda prawdopodobieństwo pomyłki w tym wypadku jest mniejsze (pliki mają charakterystyczne nazwy), to jednak przez kopiowanie mogą zostać usunięte ciekawe pozostałości w rekordach MFT czy w indeksach katalogów.
