Techniki anti-forensics – timestomping rejestru

W poprzednim poście zajmowaliśmy się jedną z popularniejszych technik anti-forensic – timestompingiem. Zmienialiśmy więc sygnatury czasowe plików tak aby zmylić analityków i sprawić aby pliki wydawały się niepowiązane ze złośliwą aktywnością. Tym razem spróbujemy timestomping przenieść na grunt kolejnego źródła dowodów – rejestru systemu Windows. Rejestr jest zdecydowanie jednym z najważniejszych źródeł dowodów. Znajdziemy tam informacje zarówno o systemie operacyjnym i konfiguracji komputera, jak i aktywności użytkownika. Jego zawartość nie jest również prosta do ukrycia przez napastników. Podobnie jak zwykłe usunięcie pliku nie prowadzi do fizycznego skasowania go z dysku, tak usunięte klucze i wartości będą często możliwe do odzyskania.

Zacznijmy od podstaw – struktury rejestru i tego dlaczego napastnicy mieliby w ogóle być zainteresowani zmienianiem sygnatur czasowych. Rejestr jest przechowywany w plikach hive, które zawierają kluczowe informacje konfiguracyjne dotyczące systemu i aktywności użytkownika. Rejestr składa się z czterech głównych kluczy:

• HKEY_CLASSES_ROOT
• HKEY_CURRENT_USER
• HKEY_LOCAL_MACHINE
• HKEY_USERS

W systemie plików większość rejestru znajduję się w katalogu Windows\system32\config:

A dokładnie będą nas interesować pliki DEFAULT, SAM, SECURITY, SOFTWARE i SYSTEM. W rejestrze pliki te będą zawierać klucze w ramach HKEY_LOCAL_MACHINE i przechowywać informacje o konfiguracji maszyny, serwisów, urządzeniach, kontach użytkowników, politykach haseł i aplikacjach. Poza danymi związanymi z komputerem, każdy z użytkowników ma swoją sekcje rejestru przechowywaną w plikach NTUSER.DAT i UsrClass.DAT. Zawarte tam klucze są niezwykle przydatne dla analityków DFIR gdyż pozwalają uzyskać wiele informacji o zachowaniu użytkownika jak ostatnio wyszukiwane pliki, adresy wpisane w przeglądarkę internetową, otwarte pliki czy foldery. W takcie analizy powłamaniowej pozwalają więc na prześledzenie aktywności napastników w systemie.

Na załączonych obrazkach widzimy parameter „Last write timestamp”, który pozwala określić czas ostatniej zmiany klucza. Z perspektywy analizy incydentu, sygnatura ta w połączeniu z tym jakie informacjami przechowywanymi w kluczach pomaga analitykom w odtworzeniu przebiegu zdarzeń. Przywołując przykład informacji o ostatnio wyszukiwanych plikach, możemy choćby ustalić czy w trakcie złośliwej aktywności wyszukiwane był pliki powiązane z określonymi, poufnym projektami. Timestomping rejestru przez atakujących może więc sprawić, że czas aktywności ustalony na podstawie kluczy nie będzie zgadzał się z informacjami pozyskanymi z innych artefaktów znacząco zakłócając przebieg dochodzenia.

Stwórzmy więc artefakt, który mógłby zasymulować działanie napastników próbujących uzyskać stały dostęp do środowiska. Jednym z najbardziej interesujących miejsc są klucze tworzone w związku z automatycznym uruchamianiem programów czy poleceń przy starcie, co może być wykorzystane do utrzymania dostępu do środowiska. Umieśćmy więc taki przykładowy wpis w kluczu HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run:

Ulubione narzędzie wszystkich atakujących – kalkulator – jest więc na miejscu. Teraz spójrzmy na sygnaturę czasową ostatniego wpisu do klucza:

Jest to 2 luty, godzina 22:37. Aby zmienić te wartość skorzystamy z narzędzia napisanego przez Joachima Schichta „SetRegTime”. Korzysta ono z funkcji NtSetInformationKey dostępnej w API systemu Windows. Jak przeczytamy w dokumentacji umożliwia ona modyfikacje parametrów zawartych w strukturze KEY_SET_INFORMATION_CLASS gdzie z kolei znajdziemy KEY_WRITE_TIME_INFORMATION przechowujące informacje o czasie ostatniego zapisu do klucza. Dodatkowo autor wykorzystał funkcje NtFlushKey aby zaraz po zmianie wymusić zapisanie zmian na dysku. Program ma dwie funkcjonalności, pierwsza pozwala na odczytanie wartości dla konkretnego klucza:

Wyświetlony czas zgadza się z tym co widzieliśmy w oknie Registry Explorer. Druga to już zmiana atrybutu. Przesuniemy czas ostatniego zapisu o kilka dni do tyłu. Warto zauważyć, że podobnie jak w przypadku sygnatur czasowych plików, dokładność obejmuje nie tylko sekundy. W przypadku kluczy rejestru są to 100 nanosekundowe interwały:

I ponownie zaglądamy do RegistryExplorera aby zweryfikować działanie:

Zgodnie z oczekiwaniami sygnatura czasowa jest taka jak wybrana przez nas wartość. Warto zaznaczyć w tym miejscu, że zmiany dokonujemy na poziomie klucza. W naszym przykładzie klucz Run zawiera trzy wartości, więc nie określimy której dotyczy sygnatura – to już kwestia znajomości tego co powinno znajdować się w systemie. Dodatkowo należy zwrócić uwagę, że narzędzie zmodyfikuje tylko konkretny klucz, który podamy jako parametr. Może wydawać się to oczywiste, jednak nie jest do końca zgodne z tym jak zachowuje się system operacyjny. W przypadku kluczy zawierających podklucze wartość ostatniej modyfikacji będzie się pokrywać z czasem ostatniej modyfikacji podklucza. Jak możemy zaobserwować na przykładzie:

W tym zakresie narzędzie jest więc aż nazbyt precyzyjne, a atakujący aby zatrzeć ślady będzie również musiał zmodyfikować wartość nadrzędnego klucza. Co więcej będzie musiał uważać na wszystkie sygnatury czasowe w ramach klucza aby nie doprowadzić do sytuacji w której jeden z kluczy będzie wciąż zawierał datę późniejszą niż czas modyfikacji głównego klucza.

Jakie więc mamy możliwości detekcji? Do sprawy możemy podejść z trzech stron:

1. Wykrywanie modyfikacji wartości rejestru.
2. Wykrywanie skutków modyfikacji rejestru.
3. Wykrywania działania samego narzędzia.

Jeżeli chodzi o pierwszą opcję to za monitorowanie zmian w rejestrze odpowiada log 4657 w dzienniku Security – wartość rejestru została zmodyfikowana. Niestety jednak w naszym przypadku nie będzie on pomocny. Obejmuje on bowiem zmiany wartości, a czas ostatniego zapisu do rejestru nie jest wartością rejestru więc zapis nie zostanie utworzony.

Dlatego też w zakresie detekcji opartych o rejestr pozostaje nam obserwacja anomalii w zakresie zgodności wartości kluczy i podkluczy. Łączy się to z koniecznością modyfikacji całego zestawu kluczy aby zachować zgodność sygnatur czasowych:

Podchodząc do tematu trochę na około, możemy starać się zestawić wartości rejestru z artefaktami dotyczącymi efektów modyfikacji. Jeżeli więc spotkamy się z artefaktem świadczącym o dodaniu aplikacji do autostartu to analiza tego kiedy program faktycznie zaczął się uruchamiać wraz ze startem systemu pomoże stwierdzić czy wartość jest prawdziwa. Możemy więc poszukać choćby logów 4688 – proces został utworzony, w celu weryfikacji uruchomień aplikacji zapisanej w wartości klucza.

W końcu być może najskuteczniejszym rozwiązaniem jest monitorowanie procesów i wywołań API, na załączonym obrazku, w monitorze procesów widzimy wyraźnie funkcje wywołaną przez SetRegTime w celu modyfikacji czasu:

Widzimy również jak zaraz po modyfikacji danych dzięki NtFlushKey program wymusza zapis zmian na dysk.

Aby skutecznie zastosować te metodę monitorowanie musi być prowadzone w czasie rzeczywistym. Jeżeli chodzi o analizę obrazu pamięci to zrzut pamięci musiałby bowiem zostać wykonany w momencie modyfikacji rejestru aby przechwycić wywołanie funkcji. Narzędzia służące do monitorowania procesów wychwycą również uruchomienia narzędzia z parametrem:

Jednak funkcja równie dobrze może być zaimplementowana w ramach innego pliku wykonywalnego i nie zostawiać tak oczywistego śladu. Z drugiej strony jeżeli udało się pozyskać próbki złośliwego oprogramowania to wykrycie wykorzystania NtSetInformationKey podczas analizy może naprowadzić nas na właściwe tory w zakresie poszukiwania nieprawidłowości w rejestrze.

Podsumowując, timestomping rejestru nie jest prosty do wykrycia. Najpewniejszą metodą jest monitorowanie procesów, które pozwoli na stworzenie detekcji opartej o wywołania funkcji odpowiedzialnych za zmianę wpisu i ewentualnie również wykorzystanie funkcji NtFlushKey do szybkiego wprowadzenia zmian do systemu. Pamiętajmy jednak, że timestomping w takiej formie ma ograniczoną użyteczność. O ile zmienimy czas ostatniej modyfikacji klucza, to już zapisane w nim wartości – jak czas ostatniego logowania użytkownika – nie zostaną zmienione. Ostatecznie więc najważniejsze będzie zestawienie dowodów pochodzących z różnych źródeł i ustalenie gdzie napastnicy mogli modyfikować artefakty oraz jakie był ich intencje.