Windows Event Log Analysis - Kompletny Przewodnik - Security Bez Tabu

Windows Event Log Analysis – Kompletny Przewodnik

Kompletny przewodnik po dzienniku zdarzeń

Windows nieustannie rejestruje zdarzenia dotyczące działania systemu, zabezpieczeń i aplikacji. Dla analityków bezpieczeństwa logi zdarzeń Windows (Windows Event Log) stanowią bezcenne źródło informacji – to właśnie w nich często znajdziemy pierwsze ślady ataku lub awarii.

W tym przewodniku, omówimy analizę logów zdarzeń Windows w praktyczny sposób, tak jakbyśmy wspólnie rozwiązywali problem w zespole inżynierów.Skupimy się na ważnych identyfikatorach zdarzeń (Event ID), konfiguracji audytu, interpretacji wpisów pod kątem bezpieczeństwa oraz narzędziach takich jak wevtutil czy PowerShell do pozyskiwania logów. Nie będzie tu encyklopedycznych definicji – zamiast tego otrzymasz konkretne porady operacyjne i przykłady z rzeczywistego środowiska SOC i forensics.

Rozszerzenie tego artykułu o komendy MS Windows i nie tylko znajdziesz w naszym artykule Windows Commands Dla Analityków Bezpieczeństwa – Pełny Przewodnik Z Przykładami.

Dlaczego to ma znaczenie

Dlaczego warto przejmować się logami Windows? Ponieważ w codziennej pracy zespołów SOC i Blue Team logi to często pierwsza linia obrony. To one pozwalają wykryć nietypowe aktywności: próby logowania na konta, które nie powinny mieć miejsca, uruchomienie podejrzanego procesu, zmianę konfiguracji systemu czy dostęp do wrażliwych plików. Bez wnikliwej analizy dzienników zdarzeń atakujący mógłby pozostać niezauważony aż do momentu, gdy wyrządzi poważne szkody.

Z perspektywy forensics logi stanowią dowód – chronologiczny zapis działań użytkowników i procesów w systemie. Wyobraź sobie dochodzenie powłamaniowe: próbujesz odtworzyć krok po kroku działania intruza. Jeśli wcześniej zadbano o właściwe logowanie zdarzeń i audyt, śledczy mogą sprawdzić kto, co, kiedy zrobił na zainfekowanym hoście. Bez logów jesteśmy ślepi. Co więcej, logi systemowe przydają się nie tylko po incydencie – w ramach monitoringu proaktywnego analitycy tworzą reguły w systemach SIEM/EDR na bazie logów, aby generować alerty (np. wiele nieudanych logowań w krótkim czasie może wywołać alarm o brute-force). Krótko mówiąc: umiejętność analizy Windows Event Log jest kluczowa, bo pozwala nam zrozumieć normalną aktywność systemu i wychwycić anomalie świadczące o incydencie bezpieczeństwa.

Rodzaje dzienników w systemie Windows

Zanim zagłębimy się w konkretne zdarzenia, warto znać podstawowy podział dzienników Windows. System Windows domyślnie utrzymuje trzy główne dzienniki dostępne w Podglądzie zdarzeń (Event Viewer):

  • Application Log (Dziennik aplikacji) – Zawiera zdarzenia generowane przez aplikacje zainstalowane w systemie. Aplikacje zapisują tu m.in. błędy, ostrzeżenia i informacje diagnostyczne. Z perspektywy SOC mogą się tu pojawić np. logi aplikacji antywirusowych lub niestandardowego oprogramowania, które warto monitorować.
  • System Log (Dziennik systemowy) – Zapisuje zdarzenia generowane przez sam system operacyjny i usługi Windows. Znajdziemy tu informacje o zdarzeniach podczas uruchamiania systemu, ładowania sterowników, start/stop usług, błędach systemowych, aktualizacjach itp. Przykładowo awaria usługi lub sterownika będzie odnotowana właśnie w System Log – co może mieć znaczenie, jeśli atakujący próbuje np. wyłączyć usługę związaną z bezpieczeństwem.
  • Security Log (Dziennik zabezpieczeń) – Najważniejszy z punktu widzenia bezpieczeństwa. Rejestruje zdarzenia związane z zabezpieczeniami systemu: logowania (udane i nieudane) do kont, użycie uprawnień administracyjnych, zmiany w kontach użytkowników, dostępy do obiektów (jeśli włączono audyt) itd. Ten dziennik jest kluczowy dla Blue Team – to tutaj szukamy śladów włamań, eskalacji uprawnień czy działań malware.

Wskazówka: Oprócz powyższych, Windows posiada wiele dodatkowych dzienników w sekcji “Dzienniki aplikacji i usług” (Applications and Services Logs) w Podglądzie zdarzeń. Są tam m.in. logi poszczególnych funkcji Windows (np. PowerShell, Sysmon, Windows Defender) oraz logi aplikacji firm trzecich. W dalszej części przewodnika omówimy najciekawsze z nich, np. log WLAN czy Sysmon.

Format dziennika zdarzeń i dostęp do logów

Logi Windows są przechowywane w postaci plików .evtx (format XML) w lokalizacji %SystemRoot%\System32\winevt\Logs\. Każdy główny dziennik ma swój plik (np. Security.evtx, System.evtx itd.). Format EVTX jest binarny, ale Windows udostępnia narzędzia do wygodnego przeglądania i filtrowania zdarzeń:

  • Graficzne narzędzie Event Viewer (Podgląd zdarzeń) – pozwala na interaktywne przeglądanie logów, filtrowanie po zdarzeniach, eksport do XML/CSV itp.
  • Wiersz poleceń i PowerShell – do szybkiej analizy logów warto znać kilka poleceń:
    • wevtutil el – wypisuje listę wszystkich dzienników zdarzeń dostępnych w systemie.
    • wevtutil cl <NazwaLogu> – czyści wskazany dziennik (uwaga: operacja jest rejestrowana zdarzeniem 1102 w Security Log).
    • wevtutil qe <NazwaLogu> – wyświetla zawartość logu (query events) z różnymi opcjami filtrowania.
    • Cmdlet PowerShell Get-WinEvent – nowocześniejszy i bardziej wydajny od starszego Get-EventLog. Umożliwia filtrowanie po wielu parametrach (nazwa logu, Event ID, źródło, przedział czasowy itp.).

Przykład: Aby wyświetlić 5 najnowszych zdarzeń logowania (Event ID 4624) z dziennika Security w formie tekstowej, można użyć wevtutil z zapytaniem XML:

C:\> wevtutil qe Security "/q:*[System[EventID=4624]]" /c:5 /f:text /rd:true

Powyższe polecenie pobierze 5 ostatnich zdarzeń o ID 4624 z logu Security, sortując od najnowszego (przełącznik /rd:true). Rezultatem będzie tekstowy dump wpisów, zawierający m.in. datę, nazwę komputera, Event ID i opis zdarzenia. Oto przykład fragmentu takiego logu (zredagowany dla czytelności):

Event[0]:
  Log Name: Security
  Source: Microsoft-Windows-Security-Auditing
  Date: 2025-11-04T10:10:32.123
  Event ID: 4624
  Task: Logon
  Level: Information
  Keywords: Audit Success
  User: N/A
  Computer: HOST1.corp.local
  Description: 
    An account was successfully logged on.

    Subject:
        Security ID:        S-1-0-0
        Account Name:       -
        Account Domain:     -
        Logon ID:           0x0

    Logon Information:
        Logon Type:         3
        Restricted Admin Mode:    -
        Virtual Account:    No
        Elevated Token:     Yes

    New Logon:
        Security ID:        S-1-5-21-...-1001
        Account Name:       jan.nowak
        Account Domain:     CORP
        Logon ID:           0x3FD5E12
        Logon GUID:         {00000000-0000-0000-0000-000000000000}

    Network Information:
        Workstation Name:   HOST1
        Source Network Address: 192.168.1.5
        Source Port:        1501

    Detailed Authentication Information:
        Logon Process:      Kerberos
        Authentication Package: Kerberos
        Key Length:         0

Powyżej widać przykład zdarzenia 4624 (udane logowanie konta) z kluczowymi polami: kto się zalogował (Account Name), skąd (Source Network Address), jakim sposobem (Logon Type i Logon Process), itp. Takie szczegóły są nieocenione podczas analizy incydentu. W dalszej części omówimy znaczenie tych pól przy konkretnych zdarzeniach.

Cross-link: Jeśli nie czujesz się pewnie w pracy z wierszem poleceń Windows, polecamy nasz artykuł o przydatnych poleceniach Windows – znajdziesz tam porady jak sprawnie używać m.in. wevtutil i PowerShell w kontekście bezpieczeństwa.

Account Management Events (Zdarzenia zarządzania kontami)

Zdarzenia zarządzania kontami dotyczą tworzenia, modyfikacji i usuwania kont użytkowników oraz grup w systemie. Windows rejestruje te incydenty zarówno dla kont lokalnych, jak i domenowych – przy czym log pojawia się na maszynie, na której dokonano zmiany (np. na kontrolerze domeny w przypadku kont AD, albo na lokalnym serwerze jeśli tam utworzono konto lokalne). Te logi są bardzo istotne, bo atakujący często w trakcie ataku próbują tworzyć nowe konta (np. ukryte konto administratora) lub dodawać się do grup administratorskich.

Najważniejsze Event ID związane z zarządzaniem kontami to:

  • 4720 – Utworzono konto użytkownika (nowy użytkownik w systemie lub AD). Scenariusz bezpieczeństwa: pojawienie się tego zdarzenia na serwerze produkcyjnym poza planowanym oknem wdrożeniowym powinno wzbudzić czujność analityków – może oznaczać, że ktoś ręcznie dodał konto (potencjalnie backdoorowe konto atakującego).
  • 4722 – Włączono (odblokowano) konto użytkownika.
  • 4723 – Próba zmiany hasła na koncie użytkownika.
  • 4724 – Próba zresetowania hasła konta (przez administratora lub proces).
  • 4725 – Wyłączono (zablokowano) konto użytkownika.
  • 4726 – Usunięto konto użytkownika.
  • 4728 – Dodano użytkownika do globalnej grupy zabezpieczeń (np. dodanie do grupy domenowej).
  • 4732 – Dodano użytkownika do lokalnej grupy zabezpieczeń (np. do grupy Administratorzy na danej maszynie).
  • 4729 / 4733 – Usunięto użytkownika z globalnej / lokalnej grupy zabezpieczeń.
  • 4735 / 4737 – Zmieniono właściwości grupy lokalnej / globalnej (np. opis, uprawnienia).
  • 4738 – Zmieniono (zmodyfikowano) konto użytkownika (np. zmiana nazwy, hasła, członkostw).
  • 4740 – Zablokowano konto użytkownika (tzw. account lockout po przekroczeniu limitu błędnych logowań).
  • 4798 / 4799 – Wylistowano członkostwo użytkownika w lokalnych grupach / w grupach domenowych. Uwaga: Duża liczba zdarzeń 4798-4799 w krótkim czasie może oznaczać, że ktoś (skrypt lub intruz) próbuje wyenumerować użytkowników i grupy w systemie lub domenie – to często element rekonesansu w ataku (należy wtedy sprawdzić, kto inicjuje te zapytania).

(Powyższa lista nie jest wyczerpująca – Windows rejestruje jeszcze inne zdarzenia zarządzania kontami, np. dotyczące kont komputerów, zmian uprawnień SID History itp. Pełną listę można znaleźć w dokumentacji Microsoft (sprawdź bibliografie). Jednak w praktyce bezpieczeństwa najczęściej interesują nas operacje na kontach użytkowników i ich grupach, jak wymienione wyżej.)

Account Logon and Logon Events (Zdarzenia logowania do konta i logowania interaktywnego)

Microsoft rozróżnia dwie kategorie związane z logowaniem: Account Logon oraz Logon. Upraszczając:

  • Account Logon odnosi się do uwierzytelniania konta – np. kiedy kontroler domeny weryfikuje hasło i wydaje token TGT w Kerberos.
  • Logon odnosi się do sesji logowania na systemie – czyli założenia sesji użytkownika na konkretnym komputerze.

Oba typy zdarzeń zapisywane są w Security Log. Aby je rejestrować, wystarczy w GPO (Group Policy) włączyć odpowiednie audyty (Audit Account Logon i Audit Logon) – na większości systemów kluczowe audyty logowań są już włączone domyślnie, ale warto to potwierdzić.

Poniżej omówimy najważniejsze Event ID związane z logowaniami. Jako analityk SOC zwracaj uwagę zarówno na udane logowania (mogą wskazywać na przejęcie konta), jak i nieudane próby (mogą sygnalizować brute-force lub inne złośliwe działania). Pamiętaj też, że logi logowań pojawiają się na systemie, do którego następuje dostęp – np. udane zalogowanie na stacji roboczej wygeneruje Event 4624 właśnie na tej stacji, a nie na kontrolerze domeny, choć kontroler domeny wygeneruje oddzielne zdarzenia Kerberos/NTLM dla uwierzytelnienia konta.

Kluczowe zdarzenia logowania kont domenowych (Kerberos / NTLM)

Gdy logujemy się w środowisku domenowym, w tle działa Kerberos lub NTLM. Ważne zdarzenia to:

  • 4768 – Pomyślne wydanie TGT (Ticket Granting Ticket). Innymi słowy, kontroler domeny poprawnie uwierzytelnił konto użytkownika i wydał mu bilet Kerberos (TGT). To zazwyczaj pierwszy krok logowania domenowego. W zdarzeniu 4768 znajdziemy m.in. nazwę konta, które się uwierzytelniło oraz adres IP hosta, z którego żądanie przyszło (jeśli logowanie było zdalne). Pole “Result Code” (kod wynikowy) wskaże ewentualny powód niepowodzenia logowania Kerberos, jeśli się nie powiodło – np. kod 0x18 oznacza błędne hasło (lista częstych kodów błędów Kerberos znajduje się w RFC 4120 i dokumentacji Microsoft).
  • 4769 – Żądanie biletu usługowego (TGS) zostało złożone. Po uzyskaniu TGT, klient prosi o bilet dostępu do konkretnej usługi – to zdarzenie śledzi taki fakt, podając m.in. nazwę usługi i konto użytkownika, które próbuje uzyskać dostęp. Analiza: Zdarzenia 4769 pozwalają zobaczyć, do jakich usług w domenie użytkownik się loguje (np. dostęp do serwera plików, SQL itp.). W monitoringu anomalii warto wychwycić, jeśli zwykły użytkownik nagle próbuje uzyskać bilety do wielu różnych usług – może to sugerować ruch lateralny atakującego.
  • 4770 – Odnowienie biletu usługowego (TGS). Raczej informacyjne, pokazuje że bilet został odświeżony (zawiera nazwę usługi i konto).
  • 4771 – Nieudane uwierzytelnienie Kerberos (błąd pre-auth). Gdy logowanie Kerberos się nie powiedzie, może pojawić się zamiast 4768 właśnie 4771 (w zależności od etapu). Kod błędu wskaże przyczynę (np. ekspiracja hasła, zablokowane konto).
  • 4776 – Uwierzytelnianie NTLM (pojawia się na kontrolerze domeny lub systemie lokalnym, który weryfikuje hasło w SAM). To zdarzenie rejestruje zarówno udane, jak i nieudane logowania NTLM (np. logowanie do domeny z systemu Windows, który z jakiegoś powodu użył NTLM zamiast Kerberos). W opisie zdarzenia znajdziemy m.in. nazwę konta i kod błędu w razie nieudanej próby.

Najczęstsze kody błędów NTLM (Event ID 4776): W przypadku 4776 warto zwrócić uwagę na pole Failure Code. Typowe wartości to:

  • 0xC0000064 – Nieprawidłowa nazwa użytkownika (konto nie istnieje)
  • 0xC000006A – Nieprawidłowe hasło
  • 0xC0000072 – Próba logowania na konto, które zostało wyłączone
  • 0xC0000234 – Konto użytkownika jest zablokowane (too many failed attempts)
  • (Inne kody spotykane rzadziej to m.in. 0xC000006F – logowanie poza dozwolonymi godzinami, 0xC0000070 – z niedozwolonej stacji roboczej, 0xC0000133 – zbyt duża różnica czasu między hostem a DC, itp. Pełną listę kodów statusu NTLM znajdziesz w dokumentacji MSDN.)

Zdarzenia interaktywnego logowania na system (Logon Events)

Kiedy dochodzi do logowania na konkretnym komputerze – czy to lokalnie, przez RDP, czy do udostępnionego zasobu – Windows loguje to zdarzenie na danej maszynie. Kluczowe są:

  • 4624 – Successful Logon – Logowanie zakończone powodzeniem. To jedno z najczęstszych zdarzeń – każde poprawne zalogowanie się użytkownika (lub procesu z kontekstem użytkownika) skutkuje 4624. Najważniejszym polem jest Logon Type, bo mówi jak nastąpiło logowanie:
    • Typ 2 = interaktywne (logowanie bezpośrednio na maszynie, np. przez konsolę).Typ 3 = sieciowe (logowanie do zasobu w sieci, np. dostęp do folderu sieciowego lub poprzez protokół SMB).Typ 4 = batch (zadanie zaplanowane, Task Scheduler).Typ 5 = logowanie usługi (Service startup).Typ 7 = odblokowanie stacji roboczej (session unlock).Typ 8 = NetworkCleartext – logon przez sieć z hasłem przesłanym plaintext (rzadko, np. podstawowe uwierzytelnianie w IIS).Typ 9 = NewCredentials – użycie RunAs z opcją /netonly (użycie alternatywnych poświadczeń do dostępu sieciowego).Typ 10 = RemoteInteractive – logowanie przez RDP / Terminal Services.Typ 11 = CachedInteractive – logowanie przy użyciu buforowanych poświadczeń (np. użytkownik domenowy loguje się do laptopa off-line, używając ostatnio znanych poświadczeń).
    Każde zdarzenie 4624 zawiera też informacje o koncie (New Logon: nazwa, domena, SID), źródle logowania (Workstation Name, IP źródłowe) oraz np. Procesie inicjującym logowanie. Analiza: warto w SOC monitorować nietypowe logowania 4624, np. logowanie typu 3 z dziwnego adresu IP (może sugerować ruch spoza sieci), logowania poza godzinami pracy na konta administracyjne, czy logowania typu 9 (RunAs z innym kontem) – mogą być oznaką technik LOLBins i lateral movement.
  • 4625 – Logon Failed – Nieudana próba logowania. To zdarzenie alarmowe: wiele 4625 w krótkim czasie to klasyczny symptom ataku słownikowego lub password spraying. W logu 4625 kluczowe jest pole Failure Reason/Status, które dokładniej wyjaśnia przyczynę nieudanego logonu:
    • Np. kod 0xC000006A – złe hasło (pomyłka lub atak brute-force).
    • 0xC0000064 – konto nie istnieje (próba logowania na błędny login).
    • 0xC0000072 – konto wyłączone (atakujący próbował zalogować wyłączone konto).
    • 0xC0000234 – konto zablokowane (np. po wielu błędnych hasłach).
    • 0xC000015B – przekroczono limit czasu logowania (użytkownik nie ma prawa logować się na tym komputerze).
    • …oraz inne (kodów jest sporo – np. brak dostępnych serwerów logon 0xC000005E, czy błąd uwierzytelniania z powodu ochrony uzyskiwanej za pomocą Credential Guard 0xC0000413). Istotne jest to, że każde 4625 zawiera taki status – analityk powinien go sprawdzić, bo inaczej nie odróżni, czy przyczyną nieudanego logowania był zwykły błąd użytkownika przy wpisywaniu hasła czy np. blokada konta wynikająca z ataku.

Uwaga: Ciekawostką jest, że nieudane logowanie przez RDP czasem pojawi się jako Logon Type 3 (Network) zamiast oczekiwanego 10 (RemoteInteractive) – dzieje się tak w określonych wersjach/protokole i warto o tym wiedzieć, by nie przeoczyć prób ataku RDP w logach.

  • 4634 i 4647 – Wylogowanie użytkownika. 4634 oznacza zamknięcie sesji, a 4647 wylogowanie inicjowane przez użytkownika. Brak tych zdarzeń nie zawsze oznacza, że użytkownik wciąż jest zalogowany – Windows bywa niekonsekwentny w ich generowaniu. Jednak pojawienie się 4634/4647 po 4624 wskazuje, że sesja się zakończyła. Można korelować je po polu Logon ID – unikalnym identyfikatorze sesji, który jest taki sam w zdarzeniu logon (4624) i odpowiadającym mu wylogowaniu.
  • 4648 – Logon z jawnie podanymi poświadczeniami. Ten event pojawia się, gdy użytkownik/proces próbuje zalogować się używając innego konta niż bieżące – np. uruchomienie procesu jako inny użytkownik (RunAs), lub użycie opcji „Run as administrator” powodujące oddzielne uwierzytelnienie. Jest to cenna informacja, bo pokazuje przypadki użycia cudzych poświadczeń w systemie. Np. malware może próbować wykorzystać RunAs lub wstrzyknąć poświadczenia – co zobaczymy właśnie jako 4648.
  • 4672 – Przyznano specjalne uprawnienia przy logowaniu. Ten event pojawia się zawsze, gdy użytkownik loguje się i otrzymuje przywileje administracyjne (tj. należy do grupy Administratorzy, Domain Admins itp.). Innymi słowy, 4672 to znak, że dany logon był administracyjny (posiada token wysokich uprawnień). Blue Team powinien uważnie monitorować 4672 – nie tylko świadczy o administracyjnym logowaniu, ale pozwala odróżnić zwykłe logowania od tych z wysokimi uprawnieniami. Dla kont, które rzadko powinny się logować interaktywnie (np. w środowisku domenowym Domain Admini), pojawienie się 4672 jest warte zbadania (czy to planowe działanie, czy potencjalny intruz).
  • 4778 / 4779 – Reconnect i disconnect sesji RDP. 4778 oznacza ponowne podłączenie do istniejącej sesji (np. użytkownik wznawia sesję RDP), a 4779 – rozłączenie sesji (bez pełnego wylogowania). W połączeniu z 4624/4634 pozwalają śledzić aktywność sesji zdalnych.

Na koniec tej sekcji warto podkreślić: skuteczne monitorowanie logowań często wymaga korelacji wielu zdarzeń. Przykładowo, aby przeanalizować kompletny cykl logowania domenowego trzeba uwzględnić:

  1. Zdarzenia 4768/4771 (czy uwierzytelnienie Kerberos powiodło się na DC?),
  2. Zdarzenie 4624 na docelowej maszynie (utworzenie sesji),
  3. Ewentualne 4672 na tej maszynie (czy sesja ma uprawnienia admina),
  4. Na koniec 4634/4647 (wylogowanie).
    W praktyce narzędzia SIEM i systemy EDR potrafią te fakty łączyć, ale analityk powinien rozumieć, co każdy element oznacza.

(Powyższe informacje o zdarzeniach logowania zostały opracowane m.in. na podstawie dokumentacji Microsoft oraz doświadczeń analitycznych.)

Access to Shared Objects (Dostęp do udziałów sieciowych)

Atakujący po uzyskaniu poświadczeń często starają się dobrać do danych ofiary. Jednym ze sposobów jest dostęp do udziałów sieciowych (np. współdzielonych folderów na serwerach plików). Windows domyślnie rejestruje logowanie do udziału jako logon typu 3 (zdarzenie 4624 na serwerze plików), ale nie pokazuje szczegółów, jakie pliki otwarto. Aby monitorować aktywność na plikach, trzeba włączyć dodatkowy audyt.

Audit File Share: W GPO można włączyć Advanced Audit Policy → Object Access → Audit File Share (Success/Failure). Po aktywacji, w Security Log pojawią się zdarzenia dostępu do udziałów sieciowych, m.in.:

  • 5140 – Uzyskano dostęp do udziału (share). W zdarzeniu zobaczymy nazwę udziału i nazwę konta, które się podłączyło, wraz z IP źródłowym. Uwaga: 5140 informuje tylko, że dany udział został dostępny – nie wymienia plików w środku. Jednak dużo powtarzających się 5140 z jednego konta może sugerować skanowanie udziałów lub masowe pobieranie plików (tzw. smoka w sieci).
  • 5142 – Utworzono nowy udział sieciowy (ktoś udostępnił nowy folder).
  • 5143 – Zmieniono uprawnienia udziału.
  • 5144 – Usunięto udział sieciowy.

Te zdarzenia pozwalają wykryć np. próbę przeglądania wszystkich udziałów przez złośliwy skrypt (dużo 5140), albo nieautoryzowane stworzenie nowego share (5142) – co może być próbą wyprowadzenia danych.

Aby zejść jeszcze głębiej, tj. audytować konkretnie które pliki są otwierane, trzeba skorzystać z audytu dostępu do obiektów NTFS, o czym poniżej.

Scheduled Task Logging (Logi zadań harmonogramu)

Harmonogram zadań (Task Scheduler) bywa wykorzystywany przez atakujących do utrzymania dostępu lub eskalacji uprawnień – np. poprzez utworzenie złośliwego zadania, które uruchamia backdoor przy starcie systemu. Windows prowadzi dedykowany log zadań harmonogramu: znajduje się on w Applications and Services Logs → Microsoft → Windows → TaskScheduler → Operational (plik %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-TaskScheduler%4Operational.evtx). Domyślnie logowanie szczegółowe zadań może być wyłączone, ale można je włączyć (opcją “Enable All Tasks History” w Harmonogramie lub przez wevtutil sl Microsoft-Windows-TaskScheduler/Operational /e:true). Gdy historia zadań jest włączona, rejestrowane są m.in.:

Scheduled task activity event IDs

  • 106 – Utworzono nowe zadanie harmonogramu. Log pokazuje, kto (jakie konto) utworzył zadanie i jaką nazwę mu nadał, wraz z datą i godziną utworzenia.
  • 140 – Zmieniono (zaktualizowano) zadanie. Widać kto edytował zadanie i kiedy.
  • 141 – Usunięto zadanie. Pokazuje konto, które skasowało zadanie.
  • 200 – Wykonano zadanie (task action). Pokazuje nazwę zadania i pełną ścieżkę do pliku wykonywalnego, który został uruchomiony. To bardzo cenna informacja – np. jeśli zadanie uruchamia plik w nietypowej lokalizacji, od razu to zobaczymy.
  • 201 – Zakończono (ukończono) zadanie. Również podaje nazwę zadania i ścieżkę pliku, który został uruchomiony.

W praktyce, aby zrozumieć pełen obraz, trzeba korelować te eventy: np. event 106 (utworzenie zadania) z eventem 200 (wykonanie zadania) – po nazwie zadania. Na szczęście często nazwa zadania jest jednoznaczna lub unikalna. Scenariusz: Jeśli widzimy 106 (nowe zadanie “UpdtTask” utworzone przez użytkownika JDoe), a zaraz potem 200/201 z tym zadaniem uruchamiającym np. C:\Temp\bad.exe, to wiemy, że użytkownik JDoe mógł utworzyć złośliwe zadanie, które uruchamia malware. W logach harmonogramu mamy więc zarówno akt utworzenia backdoora, jak i jego wykonanie.

Zrób test: Na własnym komputerze utwórz testowe zadanie harmonogramu (np. za pomocą schtasks.exe). Nadaj mu nazwę i ustaw prostą akcję (np. uruchom notepad.exe). Włącz historię zadań i obserwuj log TaskScheduler/Operational – powinny pojawić się zdarzenia 106 (utworzenie) oraz 200 (wykonanie zadania w momencie wyzwolenia). To świetny sposób, by zapoznać się ze strukturą tych eventów zanim wystąpi prawdziwy incydent.

Object Access Auditing (Audyt dostępu do obiektów)

Audyt dostępu do obiektów pozwala śledzić użycie plików, folderów i innych obiektów, do których dostęp nie jest domyślnie logowany. Domyślnie Windows nie audytuje dostępu do plików (bo generowałoby to mnóstwo logów), ale na systemach przechowujących wrażliwe dane warto go włączyć. Robi się to przez GPO: Security Settings → Local Policies → Audit Policy → Audit object access (ustaw na Success, a opcjonalnie także Failure).

Włączenie tej polityki spowoduje, że Security Log zacznie rejestrować zdarzenia dostępu do monitorowanych obiektów (plików, folderów, kluczy rejestru). Kluczowe jest słowo “monitorowanych” – oprócz globalnego włączenia audytu, trzeba jeszcze wskazać które konkretnie obiekty audytować. Robi się to we właściwościach folderu/pliku (zakładka Zabezpieczenia → Zaawansowane → Audyt) dodając wpisy, które konta i jakie akcje audytować. Dopiero po takiej konfiguracji zaczną pojawiać się logi.

Jakie eventy otrzymamy? Kilka przykładów (w kontekście zadań harmonogramu, ale analogicznie dla innych obiektów):

  • 4698 – Utworzono nowy obiekt zadania harmonogramu (to alternatywne ujęcie eventu 106, lecz logowane w Security Log). Pojawia się, jeśli Audit Object Access jest włączony. Zawiera nazwę zadania i konto, które je utworzyło.
  • 4699 – Usunięto zadanie harmonogramu (analogicznie do 141).
  • 4700 / 4701 – Włączono / wyłączono zadanie.
  • 4702 – Zaktualizowano (zmodyfikowano) zadanie – pokazuje co zostało zmienione.

Te eventy 469x dają dodatkowy kontekst w Security Log – np. można je korelować z eventami 106/140 w TaskScheduler log, aby uzyskać pełny obraz (i np. mieć w jednym miejscu – Security – najważniejsze info o modyfikacji zadań). Dlaczego to istotne? Bo Security Log często jest centralnie zbierany przez SIEM, podczas gdy log TaskScheduler może nie być. Mając włączony audyt obiektów, nie przegapimy takich zdarzeń w SIEM.

Poza zadaniami, audyt dostępu do obiektów pozwala monitorować dowolne pliki i foldery (oraz obiekty rejestru) – wedle ustawionych zasad audytu. Gdy go włączymy, pojawiają się również bardziej ogólne eventy dotyczące tzw. uchwytów do obiektów:

Object handle event IDs (Uchwyty obiektów – szczegółowe monitorowanie dostępu)

Każdy proces, by otworzyć plik lub klucz rejestru, uzyskuje uchwyt (handle) do obiektu. Windows może logować operacje na uchwytach, co pozwala zorientować się, jaki proces co otworzył. Najważniejsze eventy tego typu to:

  • 4656 – Żądanie dostępu do obiektu. Generowane, gdy proces próbuje otworzyć obiekt (na który jest ustawiony audyt). W logu zobaczymy nazwę obiektu (ścieżkę pliku/klucza) i przydzielony identyfikator uchwytu.
  • 4658 – Zamknięcie uchwytu do obiektu. Pojawia się, gdy proces zamyka plik/klucz. Zawiera info, który proces i użytkownik to robił. Aby powiązać z konkretnym plikiem, trzeba zestawić z wcześniejszym 4656 o tym samym Handle ID.
  • 4663 – Próba uzyskania dostępu do obiektu. Logowane, gdy proces realnie wykona akcję na obiekcie (np. odczyt, zapis), nie tylko otworzy uchwyt. To właśnie 4663 powie nam, czy plik był czytany, modyfikowany itd., bo w nim jest informacja o typie dostępu.
  • 4660 – Usunięcie obiektu. Zawiera info o usuniętym pliku (po uchwycie, trzeba korelować z 4656).
  • 4657 – Modyfikacja wartości rejestru (analogiczny dla rejestru).

Te zdarzenia generują dużo danych, ale są niezastąpione przy szczegółowej analizie forensics (np. chcemy wiedzieć, jakie pliki malware czytał lub zaszyfrował – patrzymy na 4663 powiązane z procesem ransomware). W operacyjnej pracy SOC rzadziej monitoruje się je w czasie rzeczywistym (bo byłoby zbyt wiele szumu), ale warto je włączać na ważnych serwerach oraz zostawiać na stacjach jako bogate źródło logów na wypadek analizy powłamaniowej. Zalecenie: Przetestuj w labie – włącz audyt na jakimś folderze, otwórz kilka plików i sprawdź, ile eventów 4656/4663 to wygeneruje. Następnie zdecyduj, gdzie w produkcji ma to sens (np. na serwerach z krytycznymi danymi, a nie na każdej stacji użytkownika).

Audit Policy Changes (Zmiany polityki audytu)

Skoro mówimy o audytach, to nie można pominąć monitorowania… samego audytu. Zmiany w polityce audytu (czyli włączanie/wyłączanie logowania określonych zdarzeń) wpływają na widoczność działań w systemie. Dla bezpieczeństwa ważne jest, by wiedzieć, czy ktoś nie wyłączył nam logowania – bo to częsta sztuczka atakujących próbujących zatuszować ślady.

Na szczęście Windows loguje, gdy polityka audytu ulega zmianie. Kluczowy event to:

  • 4719 – System audit policy changed – Zmieniono ustawienia audytu systemu. W treści zdarzenia 4719 znajdziemy informacje, które kategorie audytu zostały zmienione (np. wyłączono audyt logon events). Jeśli zmianę wykonał administrator interaktywnie, event wskaże jego konto; jeśli zmiana przyszła z GPO, często jako “Subject” pojawi się po prostu nazwa komputera. W praktyce: Monitorujmy pojawienie się 4719. W normalnych warunkach może pojawiać się podczas aplikowania polityk GPO od czasu do czasu. Ale jeśli w trakcie ataku napastnik wyłączy np. audyt logowania lub czyszczenie logów, 4719 będzie dla nas sygnałem ostrzegawczym.

Inne powiązane zdarzenie:

  • 1102 – Wyczyściliśmy Security Log (Clear Auditing Log). Gdy ktoś (lub malware) skasuje zawartość dziennika zabezpieczeń, Windows (mimo skasowania) zapisze od razu nowy event 1102 w pustym logu informując, że log został wyczyszczony i przez kogo. Takie zdarzenie to czerwony alarm – w typowej pracy administrator nie powinien czyścić logu bezpieczeństwa (chyba że przy archiwizacji). Jeśli zobaczysz 1102, a obok brak innych logów z tego okresu – prawdopodobnie atakujący próbował zatrzeć ślady. (Analogiczne eventy istnieją dla czyszczenia innych logów, np. Event ID 104 dla System Log).

Auditing Windows Services (Monitorowanie usług Windows)

Usługi Windows to częsty cel atakujących: mogą posłużyć do wykonania kodu z uprawnieniami systemowymi (np. tworząc złośliwą usługę) albo do utrzymania się w systemie (backdoor uruchamiany jako usługa). Dlatego warto znać logi związane z usługami. Część zdarzeń dotyczących usług jest w System Log (bo usługi to element systemu), a część w Security Log (jeśli włączymy zaawansowany audyt).

Ciekawe eventy związane z usługami to m.in.:

  • 6005 (System) – “The Event log service was started” – uruchomiono usługę logów zdarzeń. Ten event pojawia się przy starcie systemu (bo wtedy startuje Event Log Service). Dlaczego jest ważny? Jeśli pojawi się w innym czasie niż reboot, oznacza to, że usługa logowania zdarzeń została zatrzymana i ponownie uruchomiona. A to podejrzane – atakujący mógł próbować wyłączyć logi, zrobić coś i znowu włączyć, licząc że nie zauważymy luki w logach.
  • 6006 (System) – “The Event log service was stopped” – zatrzymano usługę Event Log. Każde takie zdarzenie poza regularnym zamykaniem systemu jest alarmujące (ktoś wyłączył logi!).
  • 7034 (System) – Usługa uległa nieoczekiwanemu zakończeniu (crash usługi). Log pokazuje, która usługa padła i ile razy (jeśli wielokrotnie). Częste crashe kluczowej usługi bezpieczeństwa mogą oznaczać, że atakujący próbuje ją wyłączyć exploitami lub błędną konfiguracją.
  • 7036 (System) – Zmiana stanu usługi (uruchomienie lub zatrzymanie). Pojawia się często przy normalnej pracy (usługi startują przy boocie, zatrzymują się przy zamknięciu systemu). W kontekście bezpieczeństwa, jeśli niespodziewanie usługa ochronna (np. antywirus) zmieni stan na “Stopped” w środku dnia (7036), warto dociec czemu.
  • 7040 (System) – Zmieniono typ uruchamiania usługi (Startup type). Np. ktoś ustawił, że dana usługa już nie startuje automatycznie. Może to wskazywać, że intruz próbował wyłączyć pewne mechanizmy na stałe.
  • 7045 (System) – Zainstalowano nową usługę. To jeden z najważniejszych eventów: pojawia się, gdy dodana zostanie nowa usługa w systemie. Log zawiera nazwę usługi oraz pełną ścieżkę do pliku wykonywalnego tej usługi. Jeśli zobaczysz 7045, a nazwę usługi typu “ServiceHost77” wskazującą na coś podejrzanego i ścieżkę np. C:\Windows\Temp\evil.exe – masz prawie pewność, że to złośliwa usługa dodana przez malware lub atakującego. Wielu pentesterów i atakujących używa technik dodania usługi (np. PsExec tworzy tymczasową usługę przy zdalnym wykonaniu poleceń). Dlatego monitorowanie 7045 w SIEM jest bardzo wskazane (każde wystąpienie na serwerach powinno być przeglądnięte).

Dodatkowo, jeśli włączymy zaawansowany audyt Security System Extension (GPO -> Advanced Audit -> System -> Audit Security System Extension), to system Windows 10/2016+ będzie logował w Security Log zdarzenie 4697 – “Service was installed in the system” dla nowych usług. To dubluje informacje z 7045, ale trafia do Security Log, co bywa wygodne do centralnego monitoringu.

Wireless LAN Auditing (Audyt sieci bezprzewodowych)

Wiele stacji roboczych (np. laptopy) łączy się z sieciami Wi-Fi – zarówno firmowymi, jak i zewnętrznymi. Monitorowanie aktywności WLAN może pomóc wychwycić sytuacje, gdzie urządzenie łączy się z nieautoryzowaną siecią (co może narazić je na atak typu MITM). Windows posiada dedykowany log operacji Wi-Fi: znajduje się on w pliku %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-WLAN-AutoConfig%4Operational.evtx i jest widoczny w podkategorii WLAN AutoConfig w Event Viewer.

Warto monitorować zwłaszcza następujące eventy WLAN:

  • 8001 – Pomyślne połączenie z siecią Wi-Fi. Log zawiera nazwę sieci (SSID), tryb połączenia (automat z profilu czy ręcznie), metodę uwierzytelnienia (np. WPA2-PSK) i szyfrowania. Analiza: po tym evencie widać, do jakich sieci łączy się host. Dla bezpieczeństwa warto wiedzieć, czy firmowy laptop nie łączy się poza biurem z siecią o takiej samej nazwie jak firmowa (próba ataku Evil Twin) albo z siecią otwartą.
  • 8002 – Nieudane połączenie z siecią Wi-Fi. Również zawiera SSID i profil. Może wskazywać, że ktoś próbował łączyć się z jakąś siecią i się nie udało – np. atakujący mógł wprowadzić zły klucz, albo laptop próbował do słabego sygnału. Warto zwrócić uwagę na pole Failure Reason w opisie – np. błędne hasło, brak odpowiedzi AP itp.

Z perspektywy Blue Team, analiza logów WLAN może nie jest codzienna, ale bywa użyteczna. Np. w śledztwie incydentu, gdy laptop został prawdopodobnie zainfekowany podczas podróży, można sprawdzić w logach 8001/8002 z jakimi sieciami Wi-Fi się łączył (czy nie była to jakaś podejrzana sieć). W kontekście policy compliance niektóre organizacje wręcz logują i alarmują, jeśli firmowe urządzenie połączy się z niezatwierdzoną siecią.

Process Tracking (Śledzenie procesów)

Domyślnie Windows nie loguje uruchamiania każdego procesu – a szkoda, bo to bardzo cenna informacja przy analizie ataków. Jednak tę funkcję można włączyć. Audyt tworzenia procesów znajdziemy we wspomnianej Advanced Audit Policy: Audit Process Tracking. Po aktywowaniu, Security Log zacznie notować event 4688 za każdym razem, gdy powstanie nowy proces w systemie.

Dlaczego to ważne? Wiele ataków typu Living-off-the-land polega na użyciu wbudowanych narzędzi systemu (PowerShell, rundll32, skripty systemowe). Mając logi 4688, analityk może zobaczyć, że np. proces cmd.exe uruchomił powershell.exe z określonymi argumentami – co już daje trop do śledztwa. Wcześniej uważano, że włączanie logowania każdego procesu zbytnio obciąży system, ale obecnie przy wydajności serwerów jest to często akceptowalne na kluczowych maszynach.

Event 4688 – New Process Created: Zawiera mnóstwo informacji: identyfikator procesu, jego nazwa/ścieżka, identyfikator i nazwa procesu rodzica (co go uruchomiło) oraz linię komend procesu (o ile dodatkowo włączymy logowanie argumentów w GPO). Ta ostatnia część jest bardzo wartościowa – dzięki niej wiemy, z jakimi parametrami dany program został uruchomiony. Przykład: 4688 może pokazać, że powershell.exe został uruchomiony z argumentem -Enc <długi_base64> – co najpewniej oznacza zakodowany skrypt, często stosowany przez malware. Albo, że rundll32.exe odwołał się do dziwnej biblioteki DLL w %TEMP%.

Po włączeniu Process Tracking (4688) mogą pojawiać się także eventy z Windows Filtering Platform (WFP) dotyczące portów i połączeń sieciowych – o nich w następnym rozdziale.

Analiza SOC: Logi 4688 generują dużo danych, ale pozwalają budować świetne detekcje. Na podstawie linii komend można pisać reguły Sigma/EDR (np. wykrywanie uruchomienia cmd.exe /c net user ... co może wskazywać na tworzenie konta z linii komend, itp.). Warto zaimplementować choćby wybiórcze monitorowanie 4688 na serwerach i ważnych stacjach. Zrób test: Włącz audyt procesu na stacji testowej, uruchom kilka programów (Notatnik, wiersz poleceń, przeglądarka) i przejrzyj zdarzenia 4688 – zobaczysz, jakie procesy je spawnowały i z jakimi parametrami. To da Ci wyobrażenie, jak wygląda “normalny” ruch procesów, co ułatwi dostrzeżenie anomalii przy prawdziwym ataku.

Windows Filtering Platform (WFP) Event IDs – monitorowanie ruchu sieciowego hosta

Windows Filtering Platform to komponent odpowiedzialny za filtrowanie ruchu sieciowego w Windows (wykorzystywany m.in. przez zaporę Windows). Przy włączonym audycie procesów i/lub odpowiednich ustawieniach zapory, Security Log może rejestrować zdarzenia związane z ruchiem sieciowym na hoście (przychodzącym i wychodzącym). Najczęściej spotykane eventy WFP to:

  • 5031 – Zapora (Windows Firewall) zablokowała aplikacji możliwość nasłuchiwania na porcie.
  • 5152 – Pakiet sieciowy został zablokowany (WFP blocked a packet).
  • 5154 – Aplikacja lub usługa zaczęła nasłuchiwać na porcie (i zapora to zarejestrowała).
  • 5156 – Dozwolono połączenie (pakiet przepuszczony).
  • 5157 – Zablokowano połączenie (pakiet/dostęp zablokowany).
  • 5158 / 5159 – Dozwolono / zablokowano przydzielenie lokalnego portu (binding).

Zdarzenia WFP podają szczegóły: IP lokalny i zdalny, porty, oraz Process ID i nazwę procesu, którego dotyczy ruch. Dzięki temu, widząc np. 5157 z zablokowanym ruchem z procesu evil.exe na nietypowy adres, mamy od razu trop co do procesu inicjującego połączenie.

W praktyce jednak, monitorowanie wszystkich 515x generuje olbrzymie ilości eventów (każdy pakiet, każde połączenie). Dlatego częściej wykorzystuje się dedykowane narzędzia (IDS/NDR) do monitoringu ruchu sieci, a logi WFP włącza się incydentalnie lub filtrowane (np. tylko ruch zablokowany). Mimo to, dobrze wiedzieć, że takie logi istnieją – bo przy incident response można je włączyć, by “podsłuchać” aktywność malware na poziomie hosta, jeśli inne narzędzia zawodzą.

Additional Program Execution Logging (AppLocker, aplikacje)

W środowiskach o wysokim poziomie bezpieczeństwa często wdraża się AppLocker lub podobne mechanizmy whitelistingu aplikacji. AppLocker nie tylko blokuje/zezwala na wykonanie pliku, ale też loguje zdarzenia związane z uruchamianiem programów. Logi AppLocker znajdują się w Applications and Services Logs → Microsoft → Windows → AppLocker (są tam osobne logi dla EXE/DLL, dla MSI, dla skriptów itp., nazwy plików np. Microsoft-Windows-AppLocker/EXE and DLL.evtx).

Jeśli AppLocker jest w trybie tylko audytu, logi będą informacyjne (nic nie zablokowano, ale odnotowano uruchomienie); jeśli w trybie enforce (wymuszania), to będą też eventy blokowania wykonania. Szczegółowe eventy zależą od konfiguracji i tego, czy coś zostało zablokowane. W dokumentacji Microsoft znajdziemy listę eventów AppLocker dla różnych akcji.

Dla analityka SOC logi AppLocker mogą dostarczyć informacji jakie nowe/nietypowe programy były uruchamiane. Np. nawet jeśli nic nie zostało zablokowane (tryb audytu), a zobaczymy event, że uruchomiono plik EXE w %UserProfile%\Downloads, to może to być podejrzane (u nas polityka może przepuszcza, ale sam fakt jest ciekawy). Ogólnie – jeśli korzystacie z AppLockera, nie zapomnijcie monitorować jego logów.

Windows Defender – podejrzane zdarzenia (antywirus)

Jeśli na systemie jest wbudowany Windows Defender (Microsoft Defender Antivirus), to on również zapisuje zdarzenia do własnego logu. Dokładniej, logi te trafiają do **Applications and Services Logs → Microsoft → Windows → Windows Defender (i niektóre do Security jeśli są skonfigurowane jako audyt).

Kilka wartych uwagi eventów generowanych przez Windows Defender (lub ogólnie Microsoft Antimalware):

  • 1006 – Wykryto malware lub potencjalnie niechciane oprogramowanie. Powinien być opis co wykryto (nazwa zagrożenia).
  • 1007 – Podjęto akcję obronną (np. plik został poddany kwarantannie lub usunięty).
  • 1008 – Próbowano podjąć akcję obronną, ale nie powiodła się (np. nie udało się usunąć pliku – to ważne, bo oznacza zagrożenie nadal obecne!).
  • 1015 – Wykryto podejrzane zachowanie. To interesujące zdarzenie – oznacza, że Defender zadziałał proaktywnie (tam gdzie nie ma sygnatury, ale coś wydaje się złośliwe, np. narusza reguły AMSI, zachowanie typowe dla malware).
  • 1116 – Ponownie detekcja malware (podobne do 1006, zależnie od wersji).
  • 1117 – (jeśli występuje) może oznaczać usunięcie zagrożenia.

Z perspektywy SOC, eventy AV są często podstawą alertów (w końcu antywirus krzyczy). Natomiast warto je korelować z innymi logami: np. w momencie wykrycia malware (1006) dobrze spojrzeć na 4688 tuż przed nim – jaki proces uruchomił plik, skąd plik się wziął? Albo czy są logi 7045 instalacji usługi tuż przed detekcją ransomware? Takie korelacje dają pełniejszy obraz incydentu.

Event IDs generowane przez Sysmon

Wbudowane logi Windows mają swoje ograniczenia – np. bez włączonego audytu nie wiemy o procesach, a nawet z audytem, logi nie zawierają hashy plików, danych DNS itd. Sysmon (System Monitor by Sysinternals/Microsoft) to darmowe narzędzie, które uzupełnia tę lukę. Działa jako usługa systemowa i sterownik, rejestrując szczegółowe zdarzenia dotyczące procesów, sieci, zmian w rejestrze itp.. Sysmon po instalacji tworzy własny log Microsoft-Windows-Sysmon/Operational (plik EVTX w katalogu logów).

Sysmon trzeba osobno zainstalować i skonfigurować (np. reguły filtrujące, jakie zdarzenia zbierać). Zakładając, że jest w naszym arsenale, oto przykładowe eventy Sysmon, które są szczególnie przydatne:

  • Sysmon Event 1 – Process Creation – odpowiednik 4688, ale znacznie bogatszy. Zawiera: ścieżkę procesu, hash (SHA1/MD5) pliku EXE, pełną linię komend, użytkownika, proces rodzic (PID, nazwa, linia komend) i wiele więcej. Dla analizy malware – złoto.
  • Sysmon Event 3 – Network connection – rejestruje nawiązanie połączenia sieciowego (IP/port lokalny i zdalny, PID procesu) – nawet jeśli połączenie zostało dozwolone. Tego normalnie Windows nie loguje (chyba że pakiety w WFP), a Sysmon tak – co bywa krytyczne np. do śledzenia zewnętrznych adresów C2, z którymi malware się łączy.
  • Sysmon Event 6 – Driver Loaded – załadowano sterownik kernelowy. Pozwala wykryć rootkity i inne podejrzane sterowniki.
  • Sysmon Event 7 – Image loaded – proces załadował bibliotekę DLL do pamięci. Można wykorzystywać do detekcji ładowania dziwnych DLL (np. wstrzyknięć DLL do procesu).
  • Sysmon Event 8 – CreateRemoteThread – utworzenie zdalnego wątku w innym procesie (typowa technika iniekcji kodu).
  • Sysmon Event 11 – File Create – utworzenie lub nadpisanie pliku.
  • Sysmon Event 12-14 – operacje na kluczach rejestru (tworzenie, modyfikacja, zmiana nazwy).
  • Sysmon Event 15 – FileCreateStreamHash – utworzenie alternatywnego strumienia danych (ADS) w pliku – często używane przez malware do ukrywania danych.
  • Sysmon Event 17-18 – utworzenie i połączenie do nazwanego potoku (Named Pipe) – bywa użyteczne przy wykrywaniu komunikacji między procesami w ataku.
  • Sysmon Event 19-21 – WMI activity – wykryto utworzenie filtra zdarzeń WMI, utworzenie konsumenta zdarzeń WMI, powiązanie tych elementów – to sygnatura trwałości malware wykorzystującego WMI (tzw. WMI persistence).
  • Sysmon Event 22 – DNS Query – (Windows 8.1+ i wyżej) – loguje zapytania DNS z procesów, co pozwala np. zobaczyć, jakie domeny malware odpytuje.
  • Sysmon Event 255 – Błąd działania Sysmon (rzadko, ale jak coś nie tak z konfiguracją).

Jak widać, Sysmon rozbudowuje nasz wgląd w system. Wadą może być ilość logów – Sysmon potrafi generować ogrom zdarzeń, dlatego zazwyczaj stosuje się filtrowanie (poprzez plik konfiguracyjny XML, gdzie określamy które eventy nas interesują, ewentualnie z jakimi warunkami). W kontekście Blue Team, jeśli organizacja może wdrożyć Sysmon na hostach i centralnie zbierać logi, to daje to detekcje niemożliwe do uzyskania samymi natywnymi logami Windows.

Auditing PowerShell Use (Logowanie użycia PowerShell)

PowerShell jest ulubionym narzędziem administratorów… i atakujących. Microsoft zdaje sobie z tego sprawę, więc w ostatnich wersjach Windows mocno rozbudował możliwości logowania aktywności PowerShell. Trzy główne mechanizmy to:

  1. Module Logging – rejestruje użycie cmdletów (poleceń) PowerShell w formie zdarzeń. Dzięki temu w logu mamy informację np. że wywołano polecenie Get-Process albo Invoke-WebRequest.
  2. Script Block Logging – rejestruje treść bloków skryptowych, które są wykonywane. Innymi słowy, loguje kompletny kod skryptu/instrukcji przekazanej do PowerShell (po zdekodowaniu, jeśli było np. Base64). Nie zapisuje wyników, tylko sam kod.
  3. PowerShell Transcription – tworzy pełne transkrypty z sesji PowerShell (to nie do Event Log, tylko do plików tekstowych – generuje log rozmowy: polecenie + wynik).

Aby te logi włączyć, trzeba ustawić odpowiednie polityki GPO (Computer Configuration -> Administrative Templates -> Windows Components -> Windows PowerShell). Po włączeniu, logi pojawią się głównie w Microsoft-Windows-PowerShell/Operational oraz częściowo w starym logu Windows PowerShell (w Event Viewer w dziale Application and Services Logs).

Najważniejsze eventy PowerShell przy włączonym loggingu:

  • 4103 (Operational log) – Module Logging – loguje wykonanie poleceń w potoku PowerShell wraz z nazwą modułu/cmdletu. Wskazuje również konto użytkownika i host (Console lub zdalny).
  • 4104 (Operational log) – Script Block Logging – zawiera pełny skrypt/instrukcję, która została uruchomiona. Jeśli atakujący uruchomi zaszyfrowany skrypt, to 4104 zapisze go już w formie jawnej! Co ważne, 4104 loguje pełny unikatowy blok tylko za pierwszym wykonaniem (żeby nie powtarzać identycznych treści) – ale to zwykle wystarcza. Microsoft oznacza ten event jako Warning jeśli wykryje w skrypcie coś podejrzanego (np. wzorce typu decoding base64, Unamsi etc.).
  • 400 (Windows PowerShell log) – uruchomienie sesji/komendy PowerShell (początek). Pokazuje np. że wystartował Powershell, czy to interaktywnie (Console) czy zdalnie (Runspace).
  • 600 (Windows PowerShell log) – zakończenie sesji (choć w tekście nie widzieliśmy, ale bywa).
  • 800 (Windows PowerShell log) – szczegóły potoku poleceń. Zawiera m.in. UserID (kto uruchomił) i HostApplication – tu bywa ciekawie, bo jak polecenia są odpalane z parametrem -EncodedCommand, to właśnie w HostApplication zobaczymy ciąg base64. Microsoft sugeruje sprawdzać właśnie event 800 pod kątem wystąpienia -enc lub -EncodedCommand w polu HostApplication – bo to często oznacza wykonanie zaszyfrowanego payloadu (co samo w sobie jest podejrzane).

Dzięki włączeniu logowania PowerShell, atakujący przestaje być “niewidzialny”, gdy używa tego narzędzia. Oczywiście generuje to sporo logów, zwłaszcza w środowiskach gdzie dużo skryptów administracyjnych działa – więc ponownie, trzeba znaleźć balans i ewentualnie filtrować lub agregować te logi. Praktyczna rada: jeśli masz środowisko, gdzie nie używa się intensywnie PowerShell, włączenie pełnego logowania PowerShell może dać ogromną wartość wykrywania przy minimalnym szumie. W środowisku, gdzie PS jest używany codziennie masowo – trzeba przemyśleć zakres (np. włączyć Script Block Logging tylko dla wybranych serwerów lub monitorować “Warning” eventy 4104).

Na marginesie: zdalne użycie PowerShell (PSRemoting, WinRM) wymaga uwierzytelnienia, więc każde takie użycie powinno mieć w logach swój ślad również w postaci eventów logowania 4624/4625 oraz 4648 (bo następuje logowanie z poświadczeniami na maszynie docelowej). Warto o tym pamiętać i korelować – np. event 4103 z hosta X i w tym samym czasie 4624 typu 3 na hoście Y wskazuje, że z X ktoś wykonał zdalnie komendę na Y (co w organizacji bez takiej administracji może oznaczać atak).

Techniczna checklista analizy logów Windows

Na koniec zebrałem praktyczną checklistę – co należy zrobić lub sprawdzić konfigurując monitoring logów Windows w organizacji:

  • Sprawdź polityki audytu – Upewnij się, że krytyczne audyty są włączone w GPO: Logon/Logoff (logowania), Account Management (zmiany kont), Object Access (dostęp do kluczowych plików), Process Creation (tworzenie procesów) itp.. Domyślnie nowsze Windows mają wiele z nich włączonych, ale potwierdź i ujednolić to na wszystkich hostach.
  • Włącz logowanie PowerShell – Skonfiguruj Module Logging i Script Block Logging dla PowerShell na stacjach i serwerach administracyjnych. To nieduży wysiłek, a dostarcza ogrom informacji o ewentualnym nadużyciu PowerShell przez atakującego.
  • Rozważ wdrożenie Sysmon – Jeśli możesz pozwolić sobie na dodatkowy agent i logi, Sysmon znacząco zwiększy widoczność (hash plików, połączenia sieciowe, iniekcje). Dostosuj konfigurację Sysmon (np. gotowe configi z projektu SwiftOnSecurity lub Olaf Hartong) tak, by wyłapać podejrzane aktywności bez nadmiernego szumu.
  • Monitoruj próby logowania – Ustaw w SIEM reguły na nadmiarowe 4625 (wiele nieudanych logowań z jednego IP lub na jedno konto) – to wczesny wskaźnik ataku brute-force. Również alarmuj na logowania 4624 na konta wrażliwe (np. dawno nieużywane konta admina) lub o nietypowej porze.
  • Monitoruj tworzenie/zmiany kont i grup – Eventy 4720 (nowy użytkownik) czy 4728/4732 (dodanie do grup adminów) powinny wywoływać alert, jeśli nie dzieją się w kontrolowanym procesie (np. w ramach wdrażania nowego pracownika przez IT). To może świadczyć o eskalacji uprawnień przez intruza.
  • Włącz audyt dostępu do krytycznych plików – Zidentyfikuj newralgiczne zasoby (np. pliki konfiguracyjne, bazy danych, pliki z danymi osobowymi) i włącz dla nich audyt (4656/4663). Nawet jeśli nie będziesz ich non-stop monitorować, to w razie incydentu te logi pomogą odtworzyć, co się działo z tymi plikami.
  • Centralizuj i zabezpiecz logi – Rozważ wdrożenie mechanizmu Windows Event Forwarding (WEF) lub agenta do SIEM, aby logi z hostów trafiały na centralny serwer. To zabezpieczy je przed skasowaniem przez atakującego (bo kopia jest już w SIEM) oraz ułatwi korelację między systemami.
  • Obserwuj kluczowe eventy systemowe – np. 7045 (instalacja usługi) czy 4697 (instalacja usługi – audyt) powinny generować powiadomienie – bo są rzadkie i często wskazują na coś podejrzanego. Podobnie czyszczenie logów (1102) – nie pozwól, by przeszło niezauważone.
  • Ćwicz analizę logów – Regularnie rób próby: np. Sprawdź logi swojego systemu – czy widzisz 4624 przy logowaniu? Czy są 4672, gdy zalogujesz się kontem admina? Spróbuj błędnie wpisać hasło kilka razy – zobacz 4625 ze stosownym kodem błędu. Takie ćwiczenia na żywym organizmie nauczą Cię, czego się spodziewać w normalnych sytuacjach, aby móc wychwycić te nienormalne.

Podsumowanie

Analiza dzienników zdarzeń Windows to obszerne zagadnienie, ale – mam nadzieję – ten przewodnik pozwolił Ci uporządkować kluczowe informacje. Omówiliśmy najważniejsze Event ID od logowań (4624, 4625, 4768 itd.), poprzez zmiany kont (4720+), audyt plików, monitorowanie sieci, aż po narzędzia typu Sysmon i logowanie PowerShell. Taka wiedza przyda się zarówno początkującym analitykom SOC, jak i tym bardziej zaawansowanym podczas threat huntingu czy analiz powłamaniowych.

Pamiętaj, że same logi to nie wszystko – liczy się ich interpretacja i korelacja. Jeden event wyrwany z kontekstu może nie zdradzać całej prawdy. Dlatego dobry analityk zawsze zadaje sobie pytania: co spowodowało to zdarzenie? co nastąpiło potem? czy to część większej sekwencji?. Np. pojedyncze 4625 to normalka (ktoś wpisał złe hasło), ale sto takich w ciągu minuty to już incydent. Udane logowanie administratora może być rutynowe, ale jeśli zaraz potem widzimy dodanie użytkownika do domenowych adminów – to już podejrzane.

Na koniec zachęcam: Zrób test w swoim środowisku – nawet domowym. Włącz dodatkowe audyty, spróbuj przeprowadzić symulowany atak (np. Mimikatz pozostawi ślad 4688 z uruchomieniem niestandardowego EXE, doda konto testowe – 4720, itp.) i zobacz, jak to wygląda w logach. Taka praktyka “na sucho” sprawi, że gdy pojawi się prawdziwy incydent, będziesz wiedzieć gdzie patrzeć i czego szukać.

Logi Windows kryją w sobie mnóstwo informacji – trzeba tylko umieć je wydobyć i zrozumieć. Uzbrojony w powyższą wiedzę, śmiało możesz zagłębiać się w logi i budować własne skuteczne detekcje. Powodzenia w Twoich analizach i happy hunting!

Bibliografia