Jak już wspominałem na blogu, threat intelligence to w istocie threat counterintelligence – proces mający na celu powstrzymanie wrogiej infiltracji środowiska. Tym razem zajmiemy się ściśle technicznym zagadnieniem związanym z tym jak napastnicy mogą próbować (anti-forensic) ukrywać ślady swoich działań i jak wykryć takie aktywności. Punktem wyjścia dla naszych rozważań będą zagadnienia z zakresu informatyki śledczej i reagowania na incydenty (DFIR). Analiza incydentów i dowodów pozostawionych przez napastników to wyzwanie na wielu płaszczyznach. o ile spojrzymy na przykład rejestru systemu Windows – jednego z najbardziej przydatnych artefaktów w informatyce śledczej – to przecież nie został on stworzony na potrzeby analizy powłamaniowej. Jego pierwotnym przeznaczeniem jest gromadzenie informacji o zachowaniach użytkownika aby usprawniać pracę systemu, nie gromadzić dowody. Trudno więc oczekiwać, iż będzie posiadał dodatkowe zabezpieczania przeciwko złośliwej manipulacji. Jednakże ostatecznie rejestr jest całkiem odpornym artefaktem, ze względu na strukturę bazy danych zwykłe skasowanie kluczy i wartości nie powoduje, iż stają się one faktycznie niedostępne dla celów analizy. Tak jak w przypadku innych dziedzin bezpieczeństwa informatyka śledcza i anti-forensic to wyścig zbrojeń pomiędzy napastnikami i analitykami.
Anti-forensic to w szerokim ujęciu techniki stosowane w celu utrudnienia dostępu do dowodów pozostawionych w trakcie złośliwej aktywności lub zniekształcenia ich w taki sposób aby uniemożliwić ich efektywne wykorzystanie w analizie. Na counterintelligence.pl zajmujemy się najczęściej typowymi operacjami sieciowymi, więc być może Czytelnicy w pierwsze kolejności pomyślą o dowodach pomagających ujawnić i powstrzymać aktywność np.: grupy APT. Musimy jednak spojrzeć na anti-forensic szerzej, gdyż największe znaczenie jakość dowodów będzie miała w przypadku gdy materiały muszą zostać przekazane do sądu. Tak będzie choćby w sprawach związanych z CSAM (Child Sexual Abuse Material), dowodami udziału w grupach przestępczych, czy szpiegostwie przemysłowym dokonywanym przez pracowników firmy. Członkowie blue teamów będą więc skupieni raczej na uzyskaniu informacji umożliwiających działania operacyjna pozwalające na usunięcie napastników ze środowiska, natomiast organy ścigania czy działy prawne firmy będą również zainteresowane tym aby dowody były możliwie niepodważalne.
W zakresie konkretnych technik, skupimy się na operacjach, których można dokonać na poziomie logicznej manipulacji plików i konfiguracji systemu. Nie będziemy więc zajmować się fizycznym niszczeniem nośników lub całego komputera. Aby usystematyzować techniki posłużymy się metodologią MITRE ATT&CK. Większość technik związanych z anti-forensic znajdziemy w ramach identyfikatora T1070 – Indicator Removal.
Techniki wskazane w ATT&CK obejmują więc usuwanie logów generowanych przez narzędzia audytowe, usuwanie konkretnych artefaktów jak pliki implantów czy klucze sieciowe i modyfikacja adekwatności plików na czele ze zmianą czasu dostępu do zasobu – timestompingiem.
Przyjrzyjmy się więc temu czym jest timestomping i jak wygląda z punktu widzenia analizy środowiska Windows. Technika ta polega na modyfikacji sygnatur czasowych pliku tak aby ukryć moment jego stworzenia lub modyfikacji. Napastnik może w ten sposób próbować dopasować czas modyfikacji do innych plików w folderze lub ustawić datę sugerującą, iż plik nie ma związku z incydentem. Timestompingu można dokonać korzystając z funkcjonalności systemu Windows i PowerShell, kopiując plik do folderu do którego mamy uprawnienia i wykorzystując polecenie Get-Item aby odczytać i zmodyfikować wartości „creationtime”, „lastaccesstime” lub „lastwritetime”. Parametry te odpowiadają zapisom adekwatności w Master File Table (MFT) czyli bazie danych przechowującej informacje o adekwatnościach plików w systemie Windows. MFT przechowuje cztery sygnatury, znane jako MACE:
- M – modified – modyfikacja pliku
- A – accessed – dostęp do pliku
- C – created – stworzenie pliku
- E – entry modification – zmiana wpisu w MFT
Alternatywnie możemy się spotkać z zapisem MACB:
- M – modified – modyfikacja pliku
- A – accessed – dostęp do pliku
- C – changed – zmiana wpisu w MFT
- B – birth – stworzenie pliku
Dodatkowo musimy mieć na uwadze, iż (MFT) zapisuje informacje of sygnaturach czasowych w dwóch zestawach danych – $FILE_NAME ($FN) i $STANDARD_INFORMATION ($SI). O ile $SI mogą być zmieniane przez użytkownika, to $FN powinny być modyfikowane tylko przez system operacyjny. Tutaj jednak z pomocą przychodzi wspomniane wcześniej kopiowanie plików. o ile bowiem zmienimy manualnie atrybuty Standard Information, to podczas kopiowania pliku z powrotem do oryginalnego folderu wartości zostaną zapisane do atrybutów $FN.
Przyjrzyjmy się technice krok po kroku, korzystając z przykładowego pliku tekstowego:
Przesuwamy datę stworzenia pliku o kilka dni do tył korzystając z Get-Item.creationtime:
W rezultacie uzyskujemy plik z dobranym przez nas czasem modyfikacji i dostępu.
Przykładem stosowania timestompingu w praktyce było działanie NOBELLIUM podczas ataków wykorzystujących dostęp do systemu SolarWinds. Napastnicy modyfikowali atrybuty plików tak aby biblioteki DLL wyglądały na normalne pliki systemu Windows. Podobnie grupa Temp.Veles odpowiedzialna za ataki z wykorzystaniem malware’u Triton modyfikowała atrybuty $SI korzystając właśnie z funkcjonalności PowerShella. W raporcie analitycy wskazują choćby na wyszukiwanie parametrów jak „.CreationTime=” jako metodę detekcji złośliwej aktywności.
Przechodząc więc do detekcji, jakie możliwości mają analitycy wobec tej techniki anti-forensic? Najprostszą metodą jest przyjrzenie się dokładnie sygnaturze czasowej pliku, a konkretnie wartości nanosekund. System Windows bowiem rejestruje czas z taką dokładnością, jednak nie wszystkie narzędzia mają możliwość ustawienia parametru uwzględniając taką precyzję. Wracają do naszego przykładu i korzystając z narzędzia nTimeview widzimy, iż czas stworzenia pliku wyróżnia się na tle innych wartości:
Jednakże w zestawie znajdziemy również narzędzie pozwalające ustawić wartości nanosekund, nTimestomp:
I upewniając się z nTimeview:
Dzięki któremu, jak widzimy na przykładzie czasu ostatniego dostępu do pliku, możemy również ustawić dowolną wartość nanosekund – jak mało rzucające się w oczy 1234567.
Jaka metoda będzie więc pewniejsza? Wspominaliśmy już o tym, iż możemy porównać wartość Standard Information i File Name zawarte w MFT. I faktycznie wylistowanie danych wskaże na nieprawidłowości:
Atakujący może jednak ominąć problem edycji pola $FILE_NAME kopiując plik do lokalizacji docelowej. Poszukajmy więc bardziej pewnej metody. Z pomocą przychodzi dziennik USN (Update Sequence Number), który rejestruje wszystkie zmiany zachodzące w systemie plików. Plik dziennika możemy wydobyć z obrazu dysku gdzie znajdziemy go w alternatywnym strumieniu danych w ścieżce $Extend\$UsnJrnl:
Następnie możemy plik przekonwertować, do przyjaznego w obróbce formatu CSV dzięki narzędzia MFTECmd autorstwa Erica Zimmermana:
Analiza USN pokaże prawdziwe wartości czasu stworzenia pliku i historię zmian. Aby pokazać całą historię pliku musiałem jednak użyć dwóch nazw plików jako filtrów, gdyż nasz przykład został początkowo utworzony jako „New Text Document.txt”:
Wiersze „BasicInfoChange” to właśnie ślady manipulacji adekwatnościami pliku. W trakcie analizy warto również zwrócić uwagę na pliki LNK, tworzone przez system przy otwieraniu plików i które również posiadać będą atrybuty czasu:
W tym przypadku widzimy trzy takie pliki znajdujące się pomiędzy szeregiem wpisów co nie jest szczególnie dziwne. o ile jednak napastnik zdecydowałby się na uruchomienie pliku już po jego timestompowaniu, albo zmieniłby czas na przyszły (np.: aby wykluczyć plik z analizy zdarzeń mających miejsce w dniu ataku) to z porównania sygnatur czasowych pliku i stworzonych plików LNK mogłoby wynikać choćby, iż plik został uruchomiony przed jego stworzeniem.
Zależnie od tego jak intensywnie użytkowany jest komputer możemy również skorzystać z zawartości $LogFile, czyli pliku zapisującego zmiany metadanych w systemie plików. Możemy tam znaleźć wpisy powiązane ze zmianą atrybutów $STANDARD_INFORMATION i $FILE_NAME, a więc również artefakty związane z timestompingiem. Konkretnie filtrując wartości według pół Operation and CurrentAttribute możemy znaleźć zmiany wartości pól w $FILE_NAME. Niestety w moim przykładzie nie udało mi się odnaleźć w $LogFile dowodów mojej złośliwej działalności (jeżeli odkryje przyczynę z pewnością uaktualnię wpis), jednak dla ilustracji, oto przykładowe wpisy:
Tym sposobem poznaliśmy jeden z wielu sposobów stosowanych przez napastników do utrudniania życia analityków informatyki śledczej. Uwzględnienie metod anti-foresic dokłada kolejną warstwę wysiłku wymaganego do ustalenia co zaszło w środowisku jednak jest niezbędne aby być pewnym, iż dowody które analizujemy nie prowadzą nas w złym kierunku.