Jak hakerzy mogą wykorzystać dzienniki zdarzeń Windows?

Techniki opisywane w poście są niezwykle interesujące, szczególnie teraz, gdy w czasach wszechobecnego systemu Windows 10 i Windows 11 ilość informacji w EventLogach eksplodowała. W czasach WinXP i Windows 2000/2003 istniała Wielka Trójka: dzienniki zdarzeń bezpieczeństwa, systemu i aplikacji. Teraz, w naszym systemie Windows 10 „katalog” folderu winevt\logs ujawnia pewnie ponad 400 plików z rozszerzeniem „.evtx”. Oczywiście nie wszystkie dzienniki są wypełnione, a nawet włączone.

Niestety z naszych obserwacji wynika, że większość logów niestandardowych nie jest w ogóle używana do analizy bezpieczeństwa w zespołach SOC. W rzeczywistości, podobnie jak Rejestr, dzienniki zdarzeń systemu Windows są w dużej mierze źle rozumiane przez wielu analityków. Co więcej, istnieje wiele szkoleń z analizy kryminalistycznej systemu Windows, które polegają na identyfikowaniu rekordów dziennika zdarzeń systemu Windows wyłącznie na podstawie ID zdarzenia, nawet jeśli stwierdzono i pokazano, że identyfikatory zdarzeń nie są unikalne. Na przykład często odwołujemy się do „identyfikatora zdarzenia 4624” podczas sprawdzania udanych zalogowań, ale gdy źródłem zdarzenia jest „EventSystem”, identyfikator ten ma zupełnie inne znaczenie i kontekst. Nic nie stoi na przeszkodzie, aby ktoś stworzył aplikację, która zapisuje swoje dzienniki do bieżącego lub własnego dziennika zdarzeń systemu Windows, używając tego samego identyfikatora zdarzenia. Tylko w ciągu ostatniego roku widzieliśmy kilka narzędzi wykorzystywanych przez cyberprzestępców do tworzenia rekordów w EventLogu, z których dwa używają identyfikatora zdarzenia „zero” (EventID=0) do wszystkiego.

Krótko mówiąc, używanie pliku dziennika zdarzeń systemu Windows jako trwałego repozytorium to świetny pomysł dla cyberprzestępców, ponieważ zespoły reagowania i analitycy raczej nie będą tam zaglądać ani uważać go za cenne źródło informacji. Na przykład wykorzystanie dziennika zdarzeń „Key Management Service” jest dość interesujące, ponieważ chociaż jest on włączony domyślnie w systemach, nie jest wypełniany w znacznej większości z nich.

Spróbujmy użyć jednego z poleceń Tima, tylko trochę zmodyfikowanego, aby stworzyć nowy rekord w poniższym logu:

Stworzone zdarzenie będzie wyglądało następująco:

Jest to pierwszy wpis zapisany w tym pliczku wevt i jak można się spodziewać, odzwierciedla to czas ostatniej modyfikacji pliku. Przykład pokazuje, dlaczego konkretny plik dziennika zdarzeń systemu Windows służy jako całkiem przyzwoite trwałe repozytorium. Możemy zmienić używany plik dziennika, ale musimy znaleźć taki, który ma bardzo niski poziom głośności.

Tim idzie o krok dalej w swoim artykule i pokazuje, że można wiele zrobić za pomocą kilku prostych (natywnych) narzędzi, odrobiny wiedzy i wyobraźni.

Narzędzia takie jak Chainsaw i Events Ripper nie będą skuteczne w wykrywaniu użycia tej techniki, zwłaszcza jeśli Windows EventLog używany w tej technice nie został uwzględniony w procesie zbierania danych. Wtyczka Events Ripper, która zawiera listę wszystkich par źródło‑identyfikator i ich częstotliwość, może stanowić punkt zwrotny dla analityka, ale oś czasu aktywności systemu z pewnością pokaże wszelkie podejrzane rekordy, o ile log evtx, którego dotyczy problem, znajduje się w kolekcji.

Pytanie o tworzenie własnych rekordów w logach pojawiło się na StackOverflow i zaowocowało kilkoma sprytnymi sposobami wykorzystującymi natywne metody, jak eventcreate.exe, Powershell itp. Należy pamiętać, że użycie eventcreate.exe jest ograniczone tylko do dziennika zdarzeń Application, ale dostępność wszystkiego, co jest w nim zapisane, można dostosować za pomocą rozmiaru pliku i ustawień przechowywania.