W tym artykule skupimy się na sposobach jakie używają cyberprzestępcy w celu zatajenia swojej aktywności w logach Microsoft.

Na temat natywnych logów rejestrowanych przez system operacyjny Windows szeroko rozpisywaliśmy się w kilku artykułach na Kapitanie Hack’u, dlatego nie będziemy podawać przykładów jak poprawnie audytować aktywności, lecz opowiemy jak te aktywności w logach zatajać. Dlaczego piszemy o logach Microsoft? Ponieważ systemy te zdominowały infrastrukturę informatyczną w firmach (przynajmniej tę biurową). Zanim jednak przejdziemy do konkretów przedstawmy na początek wirtualną Microsoftową rzeczywistości oraz jak tę rzeczywistość możemy zakrzywiać w różnych kierunkach wykorzystując do tego odpowiednie narzędzia i metody. Na koniec pokażemy sposoby na radzenie z tymi problemami.


Jaką rolę pełnią logi dla współczesnych systemów bezpieczeństwa?

Większość rozwiązań do bezpieczeństwa IT dostępnych na rynku, w głównej mierze bazuje na informacji pochodzącej z logów systemowych Microsoft i/lub innych systemów/urządzeń oraz aplikacji. W Polsce istnieją także wymogi prawne dla firm należących do infrastruktury krytycznej oraz branży finansowej, które wymuszają monitorowanie i gromadzenie logów. Niektóre firmy do problemu monitorowania logów podchodzą ambitnie i ostrożnie wdrażając zaawansowane systemy klasy SIEM (ang. Security Information and Event Management), inne zbierają logi wykorzystując do tego inne aplikacje w tym systemy kolekcji ułatwiające przeszukanie repozytorium, a jeszcze inne po prostu archiwizują logi stosując do tego skrypty, żeby je mieć na wypadek awarii lub do celów dowodowych. Jest też odsetek takich firm, które problem monitorowania logów taktują po macoszemu, jeszcze ich on nie dotknął lub nie posiadają na to odpowiednio przygotowanej infrastruktury i dedykowanego działu bezpieczeństwa IT.

W ciągu kilkunastu lat naszej obecności w środowiskach IT, w tym wśród działów Bezpieczeństwa spotkaliśmy się ze stwierdzeniem, że „Administratorzy dostarczają nam wszystkie logi z systemów, więc na pewno jesteśmy w stanie dobrze monitorować bezpieczeństwo”. Jak się okazuje podejście to może czasem bywać złudne, ponieważ to sam administrator definiuje audyt logów. Automatycznie rodzą nam się pytania: A kto pilnuje administratora? Czy inspekcja zdarzeń (audyt) jest właściwie zdefiniowana? Co się stanie, jeśli ktoś przechwyci nam konto administratora i zmieni audyt (np. zmieniając ustawienia w lokalnych lub domenowych politykach GPO)? Tworzy się nam się błędne koło i szereg pytań jak zatem efektywnie monitorować logi i cały chaos z informacją w nich zawartą.

Pisząc o audycie (inspekcji logów) w kontekście środowiska Microsoft nie sposób nie wspomnieć o logach Security będących kopalnią wiedzy o logowaniach użytkowników, informacjach o adresach IP, zmianach w systemie, odpalanych procesach, uzyskiwanych dostępach i wielu innych aktywnościach. O tym jak wydobyć ciekawe informacje z logów pisaliśmy w artykule: Jakie przydatne informacje z logów może pozyskać hacker?

Na dodatek, żeby nie było tak kolorowo Microsoft zostawił po sobie furtkę pozwalającą obejść rejestrowanie w logach Security niektórych operacji zmian w Active Directory np. wykorzystując atak DCShadow czy DCSync omawiany w innym naszym poście. Więcej o audycie Microsoft i jego słabościach pisaliśmy także w osobnym artykule.


Czy jest możliwe oszukanie mechanizmów rejestrowania logów tak, aby pozostać niezauważonym?

Niestety, ale odpowiedź i w tym przypadku pozostaje twierdząca. Mało się o tym mówi, ale w 2017 roku wyciekły z NSA narzędzia pozwalające ukrywać po sobie aktywności w logach Microsoft. Stwarza to ogromne możliwości twórcom złośliwego oprogramowania w tworzeniu kodu i funkcji, które będą czyściły działania malware po fazie exploitacji. Często w spotykanych na rynku malware obserwujemy zaimplementowane komendy, które czyszczą logi– najczęściej są to komendy z PowerShell Clear-Eventlog lub wevtutil.

Grupa pod nazwą Shadow Brokers opublikowała kilka narzędzi i exploitów skradzionych Equation Group, którzy prawdopodobnie pracowali dla amerykańskiej Agencji Bezpieczeństwa Narodowego (NSA). Jednym z narzędzi ujawnionych przez Shadow Brokers w kwietniu 2017 jest DanderSpritz, poeksploatacyjny framework, który pozwala hakerom zbierać dane, omijać i dezaktywować systemy bezpieczeństwa oraz przemieszczać się różnymi kontami pomiędzy komputerami w zarażonej sieci (tzw. Lateral movement). Interesującą wtyczką DanderSpritz jest EventLogEdit, który służy do manipulowania plikami dziennika zdarzeń Windows, aby pomóc napastnikom w ukrywaniu ich śladów. Podczas gdy narzędzia hakerskie, które modyfikują dzienniki zdarzeń, są niezauważane, EventLogEdit jest bardziej wyrafinowany w porównaniu do innych, ponieważ umożliwia usuwanie pojedynczych wpisów z dzienników zabezpieczeń, aplikacji i systemu, nie pozostawiając żadnych oczywistych wskazówek, że pliki zostały edytowane. Więcej o narzędzi EventLogEdit i o zasadzie jego działania tutaj.

Ponieważ większość systemów bezpieczeństwa (np. SIEM, parsery logów itp.) bazuje na natywnych logach systemowych, w tej sytuacji nie będą one w stanie poprawnie wychwycić zmian/logowań – ponieważ w systemie operacyjnym nie będzie po tym śladu. Dziennik logów Microsoft (Security, Application, czy System ) nie będzie posiadał zdarzeń sugerujących działanie malware.


Wyłączenie rejestrowania logów w systemie?

Czy zastanawiałeś się co byłoby jakbyś w ogóle stracił materiał dowodowy – logi? Z pewnością masz backup albo zbierasz logi „na boku”. Bardzo dobrze, ale jak się okaże poniżej te starania mogą pójść na marne. Oprócz natywnej komendy Microsoft auditpol, którą można zdefiniować jakie logi będą odkładane w logach systemowych Windows, do ukrywania po sobie aktywności w logach służy cyberprzestępcom także znany sposób jeszcze z czasów pojawienia się na rynku Windows 2012 – tajemniczy wpis w rejestrze systemowym „MiniNT”.

Jeśli atakujący ma szczęście i zdobędzie uprawnienia administracyjne do komputera, może jednym wpisem w rejestrze zablokować możliwość generowania jakichkolwiek logów!

W celu zablokowania rejestrowania jakichkolwiek logów w dzienniku zdarzeń w systemie Microsoft wystarczy do rejestru systemowego dodać jeden klucz:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MiniNT

Po wymuszeniu restartu systemu, wchodząc do dziennika zdarzeń Microsoft (event viewer) otrzymamy takie oto powiadomienie:

„Podgląd zdarzeń nie może otworzyć dziennika zdarzeń lub widoku niestandardowego. Sprawdź, czy jest uruchomiona usługa Dziennik zdarzeń i czy zapytanie nie jest zbyt długie. Żądanie nie jest obsługiwane (50)”

lub w języku angielskim

„Event Viewer cannot open the event log or custom view. Verify that Event Log service is running or query is too long. The request is not supported (50)”

Od tej pory logi przestają być odkładane, bo system operacyjny myśli, że jest specjalną wersją okrojonego Windows PE (Preinstallation Environment) służącego do instalowania, wdrażania i naprawy systemu Windows 10 dla wersji stacjonarnych (Home, Pro, Enterprise i Education), Windows Server i innych systemów operacyjnych Windows.

Powyższy klucz w rejestrze jest wymagany także przy implementacji rozrzedzonego systemu plików ReFS, który pojawił się od wersji Windows 10 v1511.


Jak sobie radzić w sytuacji manipulacji logów i jak się przed tym uchronić?

Odpowiedzi na to pytanie jest kilka. Przede wszystkim najlepiej, abyśmy w pierwszej kolejności:

  1. Wdrożyli odpowiednią politykę bezpieczeństwa w firmie. Zdefiniowali odpowiednio role i dostępy użytkowników oraz wyeliminowali użycie kont uprzywilejowanych na stacjach roboczych. Odpowiednie zabezpieczenie kont gwarantuje nam 90% bezpieczeństwa, ponieważ większość ataków wykorzystuje konta uprzywilejowane i słabości w implementacji mechanizmów uwierzytelniania Microsoft (patrz kampania KILLCHAIN).
  2. Zabezpieczyli końcówki klienckie, z których może dojść do ataku. Wdrożyli system antywirusowy, systemy antymalware oraz web proxy. Systemy te powinny sprawdzać podpinane urządzenia do komputerów, pocztę email oraz ruch internetowy – ponieważ to są najczęstsze źródła zagrożeń.
  3. Monitorowali wszystkie konta uprzywilejowane i stosowali się do odpowiednich polityk ich użycia.

Jeśli powyższe mechanizmy zawiodą lub nie będą w pełni wystarczalne, bo może się zdarzyć, że malware wykorzystuje nieznane do tej pory podatności systemu lub interakcja z systemem nastąpiła w sposób niekontrolowany do tej pory. Powinniśmy zastanowić się nad niezależnym alternatywnym systemie audytu logów, w którym:

  1. Dostarczyć niezależne od logów systemowych i wiarygodne źródło wiedzy na temat aktywności oraz zmian w środowisku. W sytuacji, kiedy powyższe metody zawiodą, a malware przedostanie się do systemu operacyjnego, będziemy w stanie niezależnie od logów systemowych dostarczyć materiał dowodowy posiadający swój własny mechanizm rejestrowania zdarzeń. Taki system powinien dostarczyć nam informacje o logowaniach i zmianach w systemie oraz uzupełnić informacje, których brakuje w logach Microsoft.
  2. Wdrożyli system do analizy ruchu sieciowego (dekodujący pakiety sieciowe do warstwy 7). Z takiego systemu dowiemy się, czy nastąpiła komunikacja pomiędzy poszczególnymi urządzeniami w sieci i jaka aktywność została zarejestrowana.

Podsumowanie

Jak widać na podstawie powyższego artykułu i opierając się na odpowiednich dowodach/narzędziach, jesteśmy w stanie doprowadzić do sytuacji, w której, zdefiniowany nawet najbardziej restrykcyjny audyt logów nie uchroni nas przed atakiem! Jak wskazują dobre praktyki, w dzisiejszych czasach samo monitorowanie logów nie jest wystarczające i nie gwarantuje nam 100% przejrzystości w działaniu systemów. Jeśli nie podejdziemy do tematu z pewnym rozsądkiem i profesjonalnie, będziemy wciąż narażeni na niekontrolowane włamania i niewiedzę co się wydarzyło w środowisku. Na rynku są dostępne metody maskowania po sobie aktywności, ale to, czy na to zezwolimy bądź nie, zależeć będzie od stanu konfiguracji naszego środowiska IT, jego odpowiedniego zabezpieczenia oraz świadomości zagrożeń. W dzisiejszych czasach istnieją wyrafinowane metody łamania zabezpieczeń i tylko od nas samych zależy w jakim stopniu będziemy wstanie sprostać tym problemom.