Windows Event Log Analysis – Kompletny Przewodnik

securitybeztabu.pl 1 rok temu

Kompletny przewodnik po dzienniku zadarzeń w MS Windows

Każdy system operacyjny Windows nieustannie rejestruje różnorodne zdarzenia zachodzące w jego środowisku. Te zdarzenia, zapisywane w dziennikach zdarzeń systemu Windows, mogą dostarczyć cenne informacje dotyczące bezpieczeństwa, błędów systemowych, działalności aplikacji i wielu innych kluczowych aspektów systemu.

Analiza tych dzienników, znana jako Windows Event Log Analysis, stała się nieodzowną umiejętnością dla administratorów systemów, specjalistów ds. bezpieczeństwa i ekspertów ds. IT. Pozwala ona nie tylko na monitorowanie i diagnozowanie problemów, ale także na skuteczne reagowanie na potencjalne zagrożenia i zrozumienie działalności w obrębie infrastruktury IT.

W niniejszym przewodniku przeprowadzimy Cię przez kompleksowe podejście do analizy dzienników zdarzeń systemu Windows. Przede wszystkim wskarzemy Event ID warte uwagi podczas analizy.

Rodzaje dzienników w systemie MS Windows

W przypadku systemu Windows istnieją trzy rodzaje dzienników: systemowe, zabezpieczeń i aplikacji.

  • Application Log (Dziennik aplikacji) – Każda aplikacja będzie miała swoje dzienniki, które zostaną uruchomione, gdy wystąpią błędy lub zostanie wysłane ostrzeżenie w celu przeglądu przez SOC.
  • Security Log (Dziennik zabezpieczeń) – Rejestrowane są podejrzane działania użytkowników dotyczące udanych i nieudanych logowań kont oraz tworzenia i zamykania procesów dla wszystkich pliku, do którego dostęp uzyskuje konto użytkownika.
  • System Log (Dziennik systemowy) – Do dziennika systemowego są rejestrowane informacje o procesie uruchamiania jądra, aktualizacjach sterowników, niepowodzeniach, aktualizacjach systemu Windows i innych ciekawych zdarzeniach.

Format dziennika zdarzeń

Nowoczesne systemy Windows domyślnie przechowują logi w katalogu %SystemRoot%\System32\winevt\logs w formacie binarnego XML do rejestrowania zdarzeń w systemie Windows. Logi są oznaczone rozszerzeniem .evtx. Możliwe jest również przechowywanie logów zdalnie przy użyciu subskrypcji logów.

Zdarzenia można rejestrować w dziennikach zdarzeń Bezpieczeństwo, System i Aplikacja. W nowoczesnych systemach Windows, zdarzenia mogą również pojawiać się w kilku innych plikach dziennika. Dziennik zdarzeń Instalacji rejestruje działania, które miały miejsce podczas instalacji systemu Windows.

Dziennik zdarzeń “The Forwarded Logs” to domyślne miejsce do rejestrowania zdarzeń otrzymanych z innych systemów. Istnieje również wiele dodatkowych dzienników, wymienionych w Dziennikach aplikacji i usług w Podglądzie zdarzeń, które rejestrują szczegóły związane z konkretnymi rodzajami działań.

  • Log Name: Nazwa dziennika zdarzeń, w którym zapisane jest zdarzenie. Przydatne przy przetwarzaniu licznych dzienników pobranych z tego samego systemu.
  • Source: Usługa, składnik firmy Microsoft lub aplikacja, która wygenerowała zdarzenie.
  • Event ID: Kod przypisany do każdego typu audytowanej aktywności.
  • Level: Stopień powagi przypisany do danego zdarzenia.
  • User: Konto użytkownika zaangażowane w wywołanie czynności lub kontekst użytkownika, w którym źródło działało podczas rejestrowania zdarzenia. Należy zauważyć, iż to pole często wskazuje “System” lub użytkownika, który nie jest przyczyną rejestrowanego zdarzenia.
  • OpCode: Przypisane przez źródło generujące dziennik. Jego znaczenie zależy od źródła.
  • Logged: Data i czas systemowe lokalnego systemu, kiedy zdarzenie zostało zarejestrowane.
  • Task Category: Przypisane przez źródło generujące dziennik. Jego znaczenie zależy od źródła.
  • Keywords: Przypisane przez źródło i używane do grupowania lub sortowania zdarzeń.
  • Computer: Komputer, na którym zdarzenie zostało zarejestrowane. Jest to przydatne przy badaniu logów zebranych z wielu systemów, ale nie należy uważać go za urządzenie, które spowodowało zdarzenie (na przykład, gdy inicjowany jest zdalny logon, pole Komputer przez cały czas pokaże nazwę systemu rejestrującego zdarzenie, a nie źródło połączenia).
  • Description: Blok tekstu, w którym rejestrowane są dodatkowe informacje specyficzne dla rejestrowanego zdarzenia. Jest to często najważniejsze pole dla analityka.

Account Management Events

Poniższe zdarzenia zostaną zarejestrowane na systemie, na którym konto zostało utworzone lub zmodyfikowane. Będzie to lokalny system dla konta lokalnego lub kontroler domeny dla konta domenowego.

Event IDOpis
4720Utworzono konto użytkownika.
4722Włączono konto użytkownika.
4723Użytkownik próbował zmienić hasło konta.
4724Podjęto próbę zresetowania hasła konta.
4725Wyłączono konto użytkownika.
4726Usunięto konto użytkownika.
4727Utworzono grupę globalną z włączonym zabezpieczeniem.
4728Dodano członka do grupy globalnej z włączonym zabezpieczeniem.
4729Usunięto członka z grupy globalnej z włączonym zabezpieczeniem.
4730Usunięto grupę globalną z włączonym zabezpieczeniem.
4731Utworzono grupę lokalną z włączonym zabezpieczeniem.
4732Dodano członka do grupy lokalnej z włączonym zabezpieczeniem.
4733Usunięto członka z grupy lokalnej z włączonym zabezpieczeniem.
4734Usunięto grupę lokalną z włączonym zabezpieczeniem.
4735Zmieniono grupę lokalną z włączonym zabezpieczeniem.
4737Zmieniono grupę globalną z włączonym zabezpieczeniem.
4738Zmieniono konto użytkownika.
4741Utworzono konto komputera.
4742Zmieniono konto komputera.
4743Usunięto konto komputera.
4754Utworzono grupę uniwersalną z włączonym zabezpieczeniem.
4755Zmieniono grupę uniwersalną z włączonym zabezpieczeniem.
4756Dodano członka do grupy uniwersalnej z włączonym zabezpieczeniem.
4757Usunięto członka z grupy uniwersalnej z włączonym zabezpieczeniem.
4758Usunięto grupę uniwersalną z włączonym zabezpieczeniem.
4798Wylistowano przynależność lokalnych grup użytkownika. Duża liczba tych zdarzeń może wskazywać na próbę wyliczenia kont przez atakującego.
4799Wylistowano przynależność lokalnych grup z włączonym zabezpieczeniem. Duża liczba tych zdarzeń może wskazywać na próbę wyliczenia grup przez atakującego.

Account Logon and Logon Events

Account Logon to termin używany przez Microsoft do autentykacji. Odnosi się do procesu uzyskiwania dostępu do zasobów dzięki konta. Zarówno logowanie konta, jak i zdarzenia logowania są rejestrowane w dzienniku zdarzeń zabezpieczeń.

Autentykacja kont domenowych odbywa się za pośrednictwem kontrolera domeny w sieci Windows. Natomiast lokalne konta, które istnieją w lokalnym pliku SAM, a nie są częścią Active Directory, są uwierzytelniane przez lokalny system, w którym się znajdują.

System, który dokonuje autentykacji, rejestruje zdarzenia logowania konta. Audytowanie zdarzeń logowania konta i logowania jest łatwe do skonfigurowania dzięki Group Policy.

Mimo iż Microsoft wraz z wydaniem nowych wersji systemu Windows coraz częściej domyślnie włącza logi, administratorzy powinni regularnie przeglądać swoje polityki audytu, aby upewnić się, iż wszystkie systemy generują odpowiednie logi.

Możliwość przechowywania dzienników zdarzeń na zdalnych systemach, zarówno dzięki wbudowanych funkcji zdalnego logowania firmy Microsoft, jak i narzędzi SIEM stron trzecich lub innych narzędzi, pomaga chronić dzienniki przed zmianami lub usunięciem.

Zdarzenia o szczególnym znaczeniu na kontrolerach domeny, które uwierzytelniają użytkowników domenowych, obejmują:

Event ID 4768

Event IDOpis
4768Pomyślne wydanie TGT oznacza, iż konto użytkownika zostało uwierzytelnione przez kontroler domeny. Sekcja Informacje o sieci w opisie zdarzenia zawiera dodatkowe informacje o zdalnym hoście w przypadku próby zdalnego logowania. Pole Słowa najważniejsze wskazuje, czy próba uwierzytelnienia była udana czy nieudana. W przypadku nieudanej próby uwierzytelnienia, kod wynikowy w opisie zdarzenia dostarcza dodatkowych informacji na temat przyczyny niepowodzenia, zgodnie z RFC 4120.

Niektóre z bardziej powszechnie spotykanych kodów to:

DecimalHexZnaczenie
60x6Nieprawidłowa nazwa użytkownika.
120xCOgraniczenie zasad zabraniające tego logowania (takie jak ograniczenie stacji roboczej lub ograniczenie na podstawie godzin).
180x12Konto jest zablokowane, wyłączone lub wygasło.
230x17Hasło konta wygasło.
240x18Hasło jest nieprawidłowe.
320x20Ticket wygasł (częste w przypadku kont komputerowych).
370x25Odstęp czasu jest zbyt duży.

Ciąg dalszy Account Logon and Logon Events:

Event IDOpis
4769Żądanie biletu usługi zostało złożone przez konto użytkownika dla określonego zasobu. Opis tego zdarzenia zawiera adres IP źródła systemu, używane konto użytkownika i usługę, do której ma być uzyskany dostęp. Te zdarzenia stanowią użyteczne źródło dowodów, ponieważ śledzą uwierzytelniony dostęp użytkownika w sieci.
4770Bilet usługi został odnowiony. Zarejestrowane zostały nazwa konta, nazwa usługi, adres IP klienta i typ szyfrowania.
4771W zależności od przyczyny nieudanego logowania Kerberos, tworzone jest zdarzenie ID 4768 lub ID 4771. W obu przypadkach kod wynikowy w opisie zdarzenia dostarcza dodatkowych informacji na temat przyczyny niepowodzenia.
4776Ten identyfikator zdarzenia jest rejestrowany dla prób uwierzytelnienia NTLM. Sekcja Informacje o sieci w opisie zdarzenia zawiera dodatkowe informacje o zdalnym hoście w przypadku próby zdalnego logowania. Pole Słowa najważniejsze wskazuje, czy próba uwierzytelnienia była udana czy nieudana.

Opisy kodów najczęstszych błędów dla Event ID 4776:

Error CodeZnaczenie
0xC0000064Nieprawidłowa nazwa użytkownika.
0xC000006ANieprawidłowe hasło.
0xC000006DOgólne niepowodzenie logowania. Możliwe, iż wprowadzono nieprawidłową nazwę użytkownika lub hasło, lub występuje niezgodność w poziomie uwierzytelniania LAN Manager Authentication Level między komputerem źródłowym i docelowym.
0xC000006FLogowanie konta poza autoryzowanymi godzinami.
0xC0000070Logowanie konta z nieautoryzowanej stacji roboczej.
0xC0000071Logowanie konta z wygasłym hasłem.
0xC0000072Logowanie konta do wyłączonego przez administratora konta.
0xC0000193Logowanie konta z wygasłym kontem.
0xC0000224Logowanie konta z oznaczonym flagą “Change Password At Next Logon”.
0xC0000234Użytkownik jest zablokowany
0xc0000371Lokalny magazyn konta nie zawiera tajnych materiałów dla określonego konta.

Event ID 4624, czyli kiedy udało nam się zalogować

Event IDOpis
4624Nastąpiło logowanie na system. Typ 2 oznacza interaktywne (zwykle lokalne) logowanie, podczas gdy Typ 3 oznacza zdalne lub sieciowe logowanie. Opis zdarzenia zawiera informacje o hostu i nazwie konta zaangażowanego. W przypadku zdalnych logowań skup się na sekcji Informacje o sieci w opisie zdarzenia, aby uzyskać informacje o zdalnym hoście.

Opisy kodów typów zdarzeń logowania:

Typ LogowaniaOpis
2Interaktywne metody logowania, takie jak logowanie przy użyciu klawiatury i ekranu systemu, lub zdalne logowanie dzięki narzędzi zdalnego dostępu firm trzecich, takich jak VNC lub psexec z przełącznikiem -u, będą przechowywać dane uwierzytelniające użytkownika w pamięci RAM przez całą sesję, a także mogą przechowywać dane uwierzytelniające użytkownika na dysku.
3Sieciowe, takie jak dostęp do udostępnionego folderu na tym komputerze z innej lokalizacji w sieci, oznaczają logowanie bez interakcji. Ten rodzaj logowania nie przechowuje danych uwierzytelniających użytkownika w pamięci RAM ani na dysku.
4Pakiet (wskazujący na zaplanowane zadanie). Typ logowania pakietowego jest używany przez serwery pakietowe, gdzie procesy mogą być wykonywane w imieniu użytkownika bez jego bezpośredniego zaangażowania.
5Usługa wskazuje, iż została uruchomiona przez Service Control Manager.
7Odblokowanie oznacza, iż nieobsługiwane stanowisko robocze z chronionym hasłem jest teraz odblokowane.
8NetworkCleartext wskazuje, iż użytkownik zalogował się na ten komputer z sieci, a hasło użytkownika zostało przekazane do pakietu uwierzytelniania w formie niezaszyfrowanej. Wbudowane pakiety uwierzytelniania haszują dane uwierzytelniające przed wysłaniem ich przez sieć. Dane uwierzytelniające nie są przesyłane przez sieć w postaci tekstowej (nazywanej również tekstem jawnym). Najczęściej wskazuje na logowanie do Internet Information Services (IIS) za pomocą uwierzytelniania podstawowego.
9NewCredentials wskazuje, iż użytkownik zalogował się dzięki alternatywnych danych uwierzytelniających, aby wykonać czynności, takie jak RunAs lub mapowanie dysku sieciowego. jeżeli chcesz śledzić próby logowania użytkowników dzięki alternatywnych danych uwierzytelniających, warto również sprawdzić Event ID 4648.
10RemoteInteractive odnosi się do interaktywnego logowania w usługach Terminal Services, zdalnym pulpicie lub zdalnej pomocy. Aby uzyskać więcej szczegółów, zobacz notatkę na temat RDP na końcu tej sekcji.
11CachedInteractive (logowanie dzięki buforowanych poświadczeń domeny, na przykład podczas logowania na laptopie poza siecią). Kontroler domeny nie został skonsultowany w celu zweryfikowania poświadczenia, dlatego nie jest generowany wpis logowania konta.

Event ID 4625, czyli kiedy nie udało nam się zalogować

Event IDOpis
4625Nieudana próba logowania. Wielka liczba takich zdarzeń w całej sieci może wskazywać na ataki polegające na zgadywaniu haseł lub ataki dzięki rozpylania haseł. Ponownie, sekcja “Informacje o sieci” w opisie zdarzenia może dostarczyć cennych informacji na temat zdalnego hosta, który próbuje zalogować się do systemu. Należy zauważyć, iż nieudane logowania dzięki RDP mogą być rejestrowane jako typ 3, a nie typ 10, w zależności od zaangażowanych systemów. Więcej informacji na temat przyczyny niepowodzenia można uzyskać, konsultując sekcję “Informacje o niepowodzeniu” w opisie zdarzenia.

Kod statusu znajdujący się w zdarzeniu ID 4625 dostarcza dodatkowe szczegóły na temat zdarzenia:

Status codeOpis
0XC000005EAktualnie nie ma dostępnych serwerów logowania do obsługi żądania logowania.
0xC0000064Logowanie użytkownika z błędnie wpisanym lub nieprawidłowym kontem użytkownika.
0xC000006ALogowanie użytkownika z błędnie wpisanym lub nieprawidłowym hasłem.
0XC000006DJest to spowodowane albo nieprawidłową nazwą użytkownika, albo nieprawidłowymi danymi uwierzytelniającymi.
0XC000006ENieznana nazwa użytkownika lub złe hasło.
0xC000006FLogowanie użytkownika poza upoważnionymi godzinami.
0xC0000070Logowanie użytkownika z nieupoważnionej stacji roboczej.
0xC0000071Logowanie użytkownika z wygasłym hasłem.
0xC0000072Logowanie użytkownika do wyłączonego przez administratora konta.
0XC00000DCWskazuje, iż serwer był w niewłaściwym stanie do wykonania żądanej operacji.
0XC0000133Zegary między kontrolerem domeny a innym komputerem są zbyt daleko rozbieżne.
0XC000015BUżytkownik nie otrzymał żądanego typu logowania (znany również jako prawo logowania) na tym komputerze.
0XC000018CNiepowodzenie żądania logowania, ponieważ relacja zaufania między domeną podstawową a zaufaną domeną nie powiodła się.
0XC0000192Podejmowana była próba logowania, ale usługa Netlogon nie została uruchomiona.
0xC0000193Logowanie użytkownika z wygasłym kontem.
0XC0000224Użytkownik musi zmienić hasło przy następnym logowaniu.
0XC0000225Widać błąd w systemie Windows, a nie ryzyko.
0xC0000234Logowanie do zablokowanego konta.
0XC00002EEPowód niepowodzenia: Wystąpił błąd podczas logowania.
0XC0000413Niepowodzenie logowania: Maszyna, do której się logujesz, jest chroniona przez zapór uwierzytelniania. Określone konto nie ma uprawnień do uwierzytelniania na tej maszynie.

Jeszcze dalszy ciąg Account Logon and Logon Events:

Event IDOpis
4634/4647Wylogowanie użytkownika jest rejestrowane dzięki zdarzenia ID 4634 lub zdarzenia ID 4647. Brak zdarzenia pokazującego wylogowanie nie powinien być uważany za nadmiernie podejrzane, ponieważ system Windows jest niespójny w rejestrowaniu zdarzenia ID 4634 w wielu przypadkach. Pole ID logowania można użyć do powiązania zdarzenia logowania ID 4624 z powiązanym zdarzeniem wylogowania (ID logowania jest unikalne między ponownymi uruchomieniami na tym samym komputerze).
4648Próba logowania przy użyciu jawnie określonych poświadczeń. Gdy użytkownik próbuje użyć poświadczeń innych niż te używane w bieżącej sesji logowania (w tym omijanie User Account Control (UAC) aby otworzyć proces z uprawnieniami administratora), to zdarzenie jest rejestrowane.
4672To zdarzenie ID jest rejestrowane, gdy określone uprawnienia związane z podwyższonym lub administratorem dostępem są udzielane logowaniu. Jak we wszystkich zdarzeniach logowania, dziennik zdarzeń będzie generowany przez system, do którego uzyskano dostęp.
4778To zdarzenie jest rejestrowane, gdy sesja jest ponownie podłączana do stacji roboczej systemu Windows. Może to wystąpić lokalnie, gdy kontekst użytkownika jest przełączany dzięki szybkiego przełączania użytkowników.
4779To zdarzenie jest rejestrowane, gdy sesja zostaje rozłączona. Może to wystąpić lokalnie, gdy kontekst użytkownika jest przełączany dzięki szybkiego przełączania użytkowników. Może również wystąpić, gdy sesja jest ponownie podłączana za pośrednictwem RDP. Pełne wylogowanie z sesji RDP jest rejestrowane jako zdarzenie ID 4637 lub 4647, o których wcześniej wspomniano.

Access to Shared Objects

Atakujący często wykorzystują ważne poświadczenia, aby zdalnie uzyskać dostęp do danych poprzez udostępnione foldery użytkownika lub administratora. Taka działalność powoduje generowanie zdarzeń logowania konta oraz zdarzeń logowania, o których wspomniano powyżej. Dodatkowe logowanie można również włączyć w Group Policy Management Console, przechodząc do Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Object Access -> Audit File Share. Po włączeniu będą rejestrowane następujące identyfikatory zdarzeń w Security Log:

Event IDOpis
5140Dokonano dostępu do obiektu udziału sieciowego. Wpis zdarzenia zawiera nazwę konta i adres źródłowy konta, które uzyskało dostęp do obiektu. Należy zauważyć, iż ten wpis pokaże, iż udział sieciowy został użyty, ale nie pokaże, jakie pliki w udziale sieciowym zostały użyte. Duża liczba tych zdarzeń z jednego konta może wskazywać na próbę pozyskiwania lub mapowania danych w sieci.
5142Dodano obiekt udziału sieciowego.
5143Zmodyfikowano obiekt udziału sieciowego.
5144Usunięto obiekt udziału sieciowego.
5145Sprawdzono, czy dla obiektu udziału sieciowego można udzielić żądanego dostępu. Błąd jest rejestrowany tylko wtedy, gdy uprawnienie jest odmawiane na poziomie udziału pliku. jeżeli uprawnienie jest odmawiane na poziomie NTFS, nie jest rejestrowany żaden wpis.

Jeśli włączono szczegółowe audytowanie plików udziałów w Group Policy Management Console to każdy plik w każdym udziale, do którego uzyskano dostęp, spowoduje generowanie wpisu dziennika zdarzeń o identyfikatorze 5145. Ten poziom logowania może generować dużą liczbę wyników.

System, który inicjuje dostęp, może również pokazywać dowody na połączenia w kluczu rejestru

NTUSER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Scheduled Task Logging

Jeśli historia jest włączona w aplikacji Harmonogram zadań, dzięki Podglądu zdarzeń lub dzięki polecenia wevtutil (więcej szczegółów tutaj), dziennik %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-TaskScheduler%4Operational zarejestruje aktywność związana z zaplanowanymi zadaniami na lokalnym systemie w następujący sposób:

Scheduled task activity event IDs

Event IDOpis
106Utworzono zaplanowane zadanie. Wpis pokazuje konto użytkownika, które zaplanowało zadanie, oraz nazwę przypisaną przez użytkownika do zadania. Data i godzina zalogowania pokazują, kiedy zadanie zostało zaplanowane. Sprawdź powiązane ID zdarzenia 200 i 201, aby uzyskać dodatkowe informacje.
140Zaktualizowano zaplanowane zadanie. Wpis pokazuje konto użytkownika, które zaktualizowało zadanie, oraz nazwę zadania. Data i godzina zalogowania pokazują, kiedy zadanie zostało zaktualizowane. Sprawdź powiązane ID zdarzenia 200 i 201, aby uzyskać dodatkowe informacje.
141Usunięto zaplanowane zadanie. Wpis pokazuje konto użytkownika, które usunęło zadanie, oraz nazwę zadania.
200Wykonano zaplanowane zadanie. Pokazuje nazwę zadania i pełną ścieżkę do pliku wykonywalnego na dysku, który został uruchomiony (wymieniony jako Akcja). Skojarz to z powiązanym ID zdarzenia 106, aby ustalić konto użytkownika, które zaplanowało zadanie.
201Zakończono zaplanowane zadanie. Pokazuje nazwę zadania i pełną ścieżkę do pliku wykonywalnego na dysku, który został uruchomiony (wymieniony jako Akcja). Skojarz to z powiązanym ID zdarzenia 106, aby ustalić konto użytkownika, które zaplanowało zadanie. Ponadto, zobacz sekcję Audyt dostępu do obiektów, aby uzyskać informacje o dodatkowych ID zdarzeń, które mogą być rejestrowane w odniesieniu do zaplanowanych zadań.

Object Access Auditing

Audyt dostępu do obiektów nie jest domyślnie włączony, ale powinien być aktywowany na systemach, gdzie przechowywane są wrażliwe dane. Aby to zrobić, należy skonfigurować Local Security Policy i uatawić Security Settings -> Local Policies -> Audit Policy -> Audit object access to Enabled for Success and Failure.

Zdarzenia audytu dostępu do obiektów są rejestrowane w dzienniku zdarzeń zabezpieczeń. Gdy audyt dostępu do obiektów jest włączony, zaplanowane zadania będą miały dodatkowe logowanie. Identyfikatory zdarzeń związanych z zaplanowanymi zadaniami to:

Event IDOpis
4698Zaplanowane zadanie zostało utworzone. W sekcji Podmiot znajduje się konto użytkownika, które utworzyło to zadanie. Szczegóły XML zaplanowanego zadania są również rejestrowane w sekcji Opis zadania i obejmują Task Name.
4699Zaplanowane zadanie zostało usunięte. Sekcja Podmiotu opisu zdarzenia zawiera Account Name, które usunęło to zadanie, oraz Task Name.
4700Zaplanowane zadanie zostało włączone. Zobacz Identyfikator zdarzenia 4698, aby uzyskać dodatkowe szczegóły.
4701Zaplanowane zadanie zostało wyłączone. Zobacz Identyfikator zdarzenia 4698, aby uzyskać dodatkowe szczegóły.
4702Zaplanowane zadanie zostało zaktualizowane. Użytkownik, który rozpoczął aktualizację, pojawia się w sekcji Podmiotu opisu zdarzenia. Szczegóły zadania po jego zmodyfikowaniu są wymienione w XML w opisie zdarzenia. Porównaj z poprzednimi wpisami Identyfikatora zdarzenia 4702 lub 4698 dla tego zadania, aby dowiedzieć się, jakie zmiany zostały wprowadzone. Zobacz Identyfikator zdarzenia 4698, aby uzyskać dodatkowe szczegóły.

Poza zaplanowanymi zadaniami, poszczególne obiekty plików często podlegają audytowi dostępu. Oprócz włączenia opcji Success i/lub Failure dla Audit Object Access, jak wcześniej wspomniano, aby przeprowadzić audyt dostępu do poszczególnych plików lub folderów, należy również jawnie ustawić reguły audytu w oknie dialogowym adekwatności pliku lub folderu. Aby to zrobić, należy wybrać kartę Zabezpieczenia, kliknąć przycisk Zaawansowane, wybrać kartę Audyt, a następnie ustawić rodzaj audytu oraz konta użytkowników, dla których ma być ustawiony audyt. Szczegółowe instrukcje można znaleźć TUTAJ.

Object handle event IDs

Aby proces mógł korzystać z obiektu systemowego, takiego jak plik, musi uzyskać do niego uchwyt (handle). Po włączeniu audytu, identyfikatory zdarzeń opisane poniżej można wykorzystać do wyświetlania dostępu do ważnych plików i folderów, śledząc wydawanie i wykorzystanie uchwytów do tych obiektów.

Event IDopis
4656Żądano uchwytu do obiektu. Gdy proces próbuje uzyskać uchwyt do obiektu poddanego audytowi, tworzone jest to zdarzenie. Szczegóły obiektu, do którego żądano uchwytu, oraz przydzielonego identyfikatora uchwytu są wymienione w sekcji Opisu obiektu zdarzenia.
4657Zmodyfikowano wartość rejestru. Konto użytkownika i proces odpowiedzialny za otwarcie uchwytu są wymienione w opisie zdarzenia.
4658Zamknięto uchwyt do obiektu. Konto użytkownika i proces odpowiedzialny za otwarcie uchwytu są wymienione w opisie zdarzenia. Aby określić sam obiekt, należy odwołać się do wcześniejszego zdarzenia ID 4656 z tym samym identyfikatorem uchwytu.
4660Obiekt został usunięty. Konto użytkownika i proces odpowiedzialny za otwarcie uchwytu są wymienione w opisie zdarzenia. Aby określić sam obiekt, należy odwołać się do wcześniejszego Event ID 4656 z tym samym Handle ID.
4663Podjęto próbę dostępu do obiektu. To zdarzenie jest rejestrowane, gdy proces próbuje oddziaływać na obiekt, a nie tylko uzyskać do niego uchwyt. Może to pomóc określić, jakie rodzaje działań mogły zostać podjęte wobec obiektu (na przykład tylko odczyt lub modyfikacja danych). Aby uzyskać dodatkowe szczegóły, zobacz zdarzenie ID 4656.

Z systemu Windows 8/Server 2012 można również włączyć dodatkowe rejestrowanie w Group Policy Management Console wchodząc w Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Object Access -> Audit Removeable Storage. Po włączeniu, system Windows będzie tworzył dodatkowe wpisy o identyfikatorze zdarzenia 4663 (patrz powyżej), gdy konto uzyskuje dostęp do obiektu systemu plików znajdującego się na nośniku wymiennym. Dzięki temu można zidentyfikować, kiedy użytkownicy kopiują dane do lub z zewnętrznych nośników.

Audit Policy Changes

Zmiany w polityce audytu mają wpływ na dostępne dowody dla śledczych i osób zajmujących się incydentami, niezależnie od tego, czy zmiana została dokonana złośliwie przez atakującego, czy zgodnie z zamierzeniem przez administratora. Na szczęście nowoczesne systemy Windows dobrze rejestrują te zmiany, gdy tylko się pojawią. Identyfikator zdarzenia używany do tego audytu to 4719:

Event IDOpis
4719Zmieniono politykę audytu systemu. W sekcji “Zmiana polityki audytu” zostaną wymienione konkretne zmiany, które zostały wprowadzone do polityki audytu. Sekcja “Podmiotu opisu zdarzenia” może pokazywać konto, które dokonało zmiany, ale często (np. w przypadku, gdy zmiana jest dokonywana dzięki zasad grupy) ta sekcja po prostu podaje nazwę lokalnego systemu.
1102Niezależnie od ustawień w polityce audytu, jeżeli dziennik zdarzeń zabezpieczeń zostanie wyczyszczony, zarejestrowane zostanie zdarzenie ID 1102 jako pierwszy wpis w nowym, pustym dzienniku. W szczegółach wpisu można zobaczyć nazwę konta użytkownika, które wyczyściło dziennik. Podobne zdarzenie o identyfikatorze 104 jest generowane w dzienniku System, jeżeli zostanie on wyczyszczony.

Auditing Windows Services

Wiele ataków polega na wykorzystywaniu usług systemowych systemu Windows do zdalnego wykonywania poleceń lub utrzymywania trwałości na systemach. Większość omawianych dotychczas zdarzeń znajduje się w dzienniku zdarzeń związanych z bezpieczeństwem, jednak system Windows rejestruje również zdarzenia związane z uruchamianiem i zatrzymywaniem usług w dzienniku zdarzeń systemowych. Poniższe zdarzenia są często warte uwagi:

Event IDOpis
6005Usługa dziennika zdarzeń została uruchomiona. Zdarzenie to występuje podczas uruchamiania systemu oraz za każdym razem, gdy system jest uruchamiany manualnie. Ponieważ usługa dziennika zdarzeń jest kluczowa dla bezpieczeństwa, posiada własny identyfikator zdarzenia.
6006Usługa dziennika zdarzeń została zatrzymana. Chociaż zdarzenie to oczywiście występuje podczas wyłączania lub ponownego uruchamiania systemu, jego wystąpienie w innych momentach może wskazywać na złośliwe próby uniknięcia rejestrowania działań lub modyfikacji dzienników.
7034Usługa została nieoczekiwanie zakończona. Opis zdarzenia wyświetla nazwę usługi i może wyświetlać liczbę razy, jakie ta usługa uległa awarii.
7036Usługa została zatrzymana lub uruchomiona. Podczas gdy usługa dziennika zdarzeń posiada własny identyfikator zdarzenia, inne usługi są rejestrowane pod tym samym identyfikatorem zdarzenia.
7040Zmieniono typ uruchamiania usługi. Opis zdarzenia wyświetla nazwę zmienionej usługi i opisuje dokonaną zmianę.
7045Usługa została zainstalowana przez system. Nazwa usługi znajduje się w polu Nazwa usługi opisu zdarzenia, a pełna ścieżka do powiązanego pliku wykonywalnego znajduje się w polu Nazwa pliku usługi. Może to być szczególnie ważne zdarzenie, ponieważ wiele narzędzi, takich jak psexec, tworzy usługę na zdalnym systemie w celu wykonania poleceń.

jeżeli włączono Advanced Audit Policy Configuration > System Audit Policies > System > Audit Security System Extension w GPO, systemy Windows 10 oraz Server 2016/2019 będą również rejestrować zdarzenie o identyfikatorze 4697 w dzienniku zdarzeń zabezpieczeń.

Wireless LAN Auditing

System Windows utrzymuje dedykowany dziennik zdarzeń dla działalności sieci lokalnej bezprzewodowej (WLAN). Biorąc pod uwagę, iż podsłuchy punktów dostępu są powszechnym wektorem ataku dla ataków typu man-in-the-middle i malware, warto zwrócić uwagę na nietypowe połączenia na urządzeniach wyposażonych w możliwość Wi-Fi, zwłaszcza tych, które mają pozwolenie na opuszczenie środowiska. Dziennik znajduje się w lokalizacji.

%SystemRoot%\System32\winevt\Logs\Microsoft-Windows-WLAN-AutoConfig%4Operational.evtx

Interesujące identyfikatory zdarzeń to:

Event IDOpis
8001Usluga WLAN pomyślnie połączyła się z siecią bezprzewodową. Opis zdarzenia zawiera tryb połączenia, który wskazuje, czy było to automatyczne połączenie na podstawie skonfigurowanego profilu (oraz powiązanej nazwy profilu), lub manualne połączenie. Rejestrowane są również SSID punktu dostępu, jego mechanizm uwierzytelniania i szyfrowania.
8002Usluga WLAN nie powiodła się w połączeniu z siecią bezprzewodową. Ponownie, opis zdarzenia zawiera tryb połączenia, powiązaną nazwę profilu oraz SSID wraz z polem Failure Reason field.

Process Tracking

W przeciwieństwie do wielu powłok Linuksa (takich jak bash), powłoka cmd.exe w systemie Windows nie przechowuje historii poleceń wykonywanych przez użytkowników. Spowodowało to zauważalną lukę w umiejętności zrozumienia działań podejmowanych przez atakującego na skompromitowanym hoście. Wzrost ataków typu “Living off the Land”, które nie polegają na złośliwym oprogramowaniu, ale zamiast tego wykorzystują wbudowane polecenia systemu Windows, tylko pogłębia ten martwy punkt. Wcześniej audytowanie tworzenia procesów w systemie Windows było uważane za zbyt obciążające.

Choć nie zawsze jest to wymagane na każdym systemie, włączanie tej funkcji na kluczowych systemach staje się coraz bardziej powszechną praktyką w środowiskach dbających o bezpieczeństwo. Aby to zrobić, należy ustawić dwa oddzielne ustawienia w zasadach grupy. Pierwsze z nich to oczywiście Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy -> Audit process tracking. Po włączeniu tej opcji, zdarzenie o identyfikatorze 4688 w dzienniku zdarzeń zabezpieczeń dostarcza wiele informacji na temat uruchomionych procesów w systemie:

Event IDOpis
4688Utworzono nowy proces. Opis zdarzenia zawiera ID procesu, nazwę procesu, ID procesu tworzącego, nazwę procesu tworzącego oraz linię komend procesu (jeśli jest to osobno włączone, jak opisano wcześniej w tej sekcji).

Oprócz zdarzenia o identyfikatorze 4688, aktywacja śledzenia procesów może również spowodować dodatkowe wpisy w dzienniku zdarzeń zabezpieczeń związane z Windows Filtering Platform dotyczące połączeń sieciowych i otwartych portów nasłuchu, jak przedstawiono poniżej:

Windows Filtering Platform (WFP) Event IDs

Event IDOpis
5031Windows Firewall Service zablokował aplikację przed akceptacją przychodzących połączeń w sieci.
5152WFP zablokował pakiet.
5154WFP zezwolił aplikacji lub usłudze na nasłuchiwanie na porcie dla przychodzących połączeń.
5156WFP zezwolił na połączenie.
5157WFP zablokował połączenie.
5158WFP zezwolił na przypisanie lokalnego portu.
5159WFP zablokował przypisanie lokalnego portu.

Opisy zdarzeń programu Windows Filtering Platform (WFP) są samoopisujące i szczegółowe. Zawierają informacje dotyczące lokalnych i zdalnych adresów IP oraz numerów portów, a także identyfikatora procesu i nazwy zaangażowanego procesu.

Jak widać, informacje rejestrowane przy włączonym audycie śledzenia procesów mogą być niezwykle wartościowe, ale mogą również generować dużą ilość danych. Przetestuj swoje środowisko testowe, aby znaleźć odpowiedni balans, który odpowiednio zwiększy audyt bezpieczeństwa w środowisku produkcyjnym.

Additional Program Execution Logging

Jeśli w Twoim środowisku skonfigurowano AppLocker (krok, który może utrudnić działanie przeciwnikowi i powinien być rozważany), będą generowane dedykowane dzienniki zdarzeń AppLocker. Te dzienniki są przechowywane wraz z innymi dziennikami zdarzeń w

C:\Windows\System32\winevt\Logs i mają nazwy takie jak Microsoft-Windows-AppLocker%4EXE i DLL.evtx

Istnieją osobne dzienniki dla plików wykonywalnych i bibliotek dynamicznych (DLL), instalatorów Microsoft (MSI) i skryptów, wdrożenia aplikacji pakietowych oraz wykonywania aplikacji pakietowych. Generowane dzienniki zdarzeń będą się różnić w zależności od tego, czy AppLocker jest ustawiony w trybie tylko audytu czy trybie blokowania. Szczegóły dotyczące konkretnych identyfikatorów zdarzeń, które mogą mieć zastosowanie w Twojej sytuacji, można znaleźć TUTAJ.

Windows Defender suspicious event IDs

Event IDOpis
1006Silnik antywirusowy wykrył złośliwe oprogramowanie lub inne potencjalnie niechciane oprogramowanie.
1007Platforma antywirusowa podjęła działanie w celu ochrony systemu przed złośliwym oprogramowaniem lub innym potencjalnie niechcianym oprogramowaniem.
1008Platforma antywirusowa próbowała podjąć działanie w celu ochrony systemu przed złośliwym oprogramowaniem lub innym potencjalnie niechcianym oprogramowaniem, ale działanie nie powiodło się.
1013Platforma antywirusowa usunęła historię złośliwego systemu i innego potencjalnie niechcianego oprogramowania.
1015Platforma antywirusowa wykryła podejrzane zachowanie.
1116Platforma antywirusowa wykryła złośliwe oprogramowanie lub inne potencjalnie niechciane oprogramowanie.
1117Platforma antywirusowa podjęła działanie w celu ochrony systemu przed złośliwym oprogramowaniem lub innym potencjalnie niechcianym oprogramowaniem.
1118Platforma antywirusowa próbowała podjąć działanie w celu ochrony systemu przed złośliwym oprogramowaniem lub innym potencjalnie niechcianym oprogramowaniem, ale działanie nie powiodło się.
1119Platforma antywirusowa napotkała błąd krytyczny podczas podejmowania działań wobec złośliwego systemu lub innego potencjalnie niechcianego oprogramowania.
5001Ochrona w czasie rzeczywistym jest wyłączona.
5004Zmieniono konfigurację ochrony w czasie rzeczywistym.
5007Zmieniono konfigurację platformy antywirusowej.
5010Skanowanie w poszukiwaniu złośliwego systemu i innego potencjalnie niechcianego systemu jest wyłączone.
5012Skanowanie w poszukiwaniu wirusów jest wyłączone.

Szczegółowe informacje na temat rejestrów zdarzeń programu Windows Defender można znaleźć TUTAJ.

Windows exploit protection to funkcja systemu Windows 10, która może zapewnić doskonałą ochronę przed różnymi technikami wykorzystywanymi przez przeciwnika. Ta funkcja chroni zarówno system operacyjny, jak i poszczególne aplikacje przed powszechnymi wektorami ataku, blokując eksploatację, która w przeciwnym razie mogłaby doprowadzić do skompromitowania systemu. Chociaż niektóre funkcje ochrony przed eksploitacją są domyślnie włączone, wiele z nich jest wyłączonych ze względu na potencjalne zakłócenie działania legalnego oprogramowania. Po włączeniu tej funkcji loguje swoje działania w plikach dziennika

C:\Windows\System32\winevt\Logs\Microsoft-Windows-Security-Mitigations%4KernelMode.evtx i C:\Windows\System32\winevt\Logs\Microsoft-Windows-Security-Mitigations%4UserMode.evtx.

Więcej szczegółów można znaleźć TUTAJ.

Event IDs generowane przez Sysmon

Inną opcją, która zwiększy widoczność procesów uruchamianych na systemach w Twoim środowisku, jest wdrożenie narzędzia Sysmon, darmowego narzędzia firmy Sysinternals, które w tej chwili jest częścią firmy Microsoft. Sysmon można bezpłatnie pobrać tutaj.

Po zainstalowaniu na systemie, Sysmon instaluje się jako usługa systemowa i sterownik urządzenia w celu generowania dzienników zdarzeń związanych z procesami, połączeniami sieciowymi i modyfikacjami czasów tworzenia plików. Tworzy nową kategorię dzienników, które są prezentowane w Podglądzie zdarzeń w sekcji Aplikacje i usługi\Logi systemowe\Microsoft\Windows\Sysmon\Operational, oraz są przechowywane w

C:\Windows\System32\winevt\Logs\Microsoft-Windows-Sysmon%4Operational.evtx

Przykładami przydatnych identyfikatorów zdarzeń generowanych przez Sysmon są:

Event IDOpis
1Tworzenie procesu (zawiera wiele szczegółów, takich jak identyfikator procesu, ścieżka do pliku wykonywalnego, skrót pliku wykonywalnego, linia komend użyta do uruchomienia, konto użytkownika użyte do uruchomienia, identyfikator procesu nadrzędnego, ścieżka i linia komend dla pliku wykonywalnego nadrzędnego i wiele innych)
2Proces zmienił czas utworzenia pliku.
3Połączenie sieciowe.
4Zmieniono stan usługi Sysmon.
5Proces zakończony.
6Wczytano sterownik.
7Wczytano obraz (zapisuje, kiedy moduł jest wczytywany w określonym procesie).
8CreateRemoteThread (tworzenie wątku w innym procesie).
9RawAccessRead (surowy dostęp do danych dyskowych dzięki notacji \\.\).
10ProcessAccess (otwieranie dostępu do przestrzeni pamięci innego procesu).
11FileCreate (tworzenie lub nadpisywanie pliku).
12Utworzono lub usunięto klucz rejestru lub wartość rejestru.
13Modyfikacja wartości rejestru.
14Zmieniono nazwę klucza rejestru lub wartości rejestru.
15FileCreateStreamHash (tworzenie alternatywnego strumienia danych).
16Zmiana konfiguracji Sysmon.
17Utworzono nazwany potok.
18Nawiązano połączenie z nazwanym potokiem.
19Wykryto aktywność filtra zdarzeń WMI.
20Wykryto aktywność konsumenta zdarzeń WMI.
21Wykryto aktywność konsumenta wobec filtra zdarzeń WMI.
22Zdarzenie zapytania DNS (Windows 8 i nowsze).
255Błąd Sysmon.

Auditing PowerShell Use

Microsoft stale zwiększa dostępność rejestrów dotyczących PowerShell, aby pomóc w zwalczaniu jego nieuczciwego użycia. Ponownie, te funkcje rejestrowania muszą być włączone dzięki zasad grupy, konkretnie w Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Windows PowerShell. Istnieją trzy podstawowe kategorie rejestrowania, które mogą być dostępne w zależności od wersji systemu Windows.

  1. Module Logging
    • Rejestruje zdarzenia wykonania potoku;
    • Rejestruje w dzienniku zdarzeń.
  2. Script Block Logging
    • Przechwytuje odszyfrowane polecenia wysyłane do PowerShell;
    • Przechwytuje tylko polecenia, a nie wynikowe dane;
  3. Transcription
    • Przechwytuje dane wejściowe i wyjściowe z PowerShell;
    • Nie przechwytuje wyników zewnętrznych programów, które są uruchamiane, tylko samego PowerShell;
    • Rejestruje w plikach tekstowych w określonym przez użytkownika miejscu.

Po włączeniu tych rejestrów będą one dostarczać wielu informacji dotyczących używania PowerShell w Twoim systemie. jeżeli regularnie uruchamiasz wiele skryptów PowerShell, może to generować dużą ilość danych. Dlatego upewnij się, iż testujesz i dostosowujesz funkcje audytu, aby znaleźć odpowiedni balans między widocznością a obciążeniem przed wdrożeniem takich zmian w środowisku produkcyjnym.

Wpisy w dzienniku zdarzeń PowerShell pojawiają się w różnych dziennikach zdarzeń. Wewnątrz

%SystemRoot%\System32\winevt\Logs\Microsoft-Windows-PowerShell%4Operational.evtx

znajdują się dwa szczególnie istotne zdarzenia:

4103Pokazuje wykonanie potoku z użyciem funkcji rejestrowania modułów. Zawiera kontekst użytkownika użytego do uruchomienia poleceń. Pole Hostname zawiera Console, jeżeli uruchomiono lokalnie, lub pokaże, jeżeli uruchomiono z systemu zdalnego.
4104Pokazuje wpisy rejestrowania bloków skryptów. Przechwytuje polecenia wysłane do PowerShell, ale nie dane wynikowe. Rejestruje pełne szczegóły każdego bloku tylko przy pierwszym użyciu, aby zaoszczędzić miejsce. jeżeli Microsoft uzna działanie za podejrzane, wydarzenie zostanie wyświetlone jako o poziomie ostrzeżenia.

Dodatkowe wpisy można znaleźć w dzienniku zdarzeń %SystemRoot%\System32\winevt\Logs\Windows PowerShell.evtx:

Event IDOpis
400Wskazuje rozpoczęcie wykonania polecenia lub sesji. Pole Hostname pokazuje, czy jest to (lokalne) Console, czy sesja zdalna, która spowodowała wykonanie.
800Pokazuje szczegóły wykonania potoku. Pole UserID pokazuje użyte konto. Pole Hostname pokazuje, czy jest to (lokalne) Console, czy sesja zdalna, która spowodowała wykonanie. Ponieważ wiele złośliwych skryptów koduje opcje dzięki Base64, należy sprawdzić pole HostApplication pod kątem opcji zakodowanych dzięki parametru -enc lub -EncodedCommand.

Należy pamiętać, iż zdalne wywoływanie PowerShell wymaga uwierzytelnionego dostępu, dlatego należy szukać powiązanych zdarzeń logowania konta (Account Logon) i logowania (Logon).

Podsumowanie

Analiza dzienników zdarzeń systemu Windows jest kluczowym elementem zarządzania i monitorowania infrastruktury IT w organizacjach. Dzięki precyzyjnej analizie tych dzienników, specjaliści mogą gwałtownie identyfikować i reagować na potencjalne zagrożenia, optymalizować działanie systemu oraz usprawniać procedury bezpieczeństwa.

W tym przewodniku przedstawiamy szeroki zakres narzędzi, technik i najlepszych praktyk związanych z analizą Windows Event Log. Mam nadzieję, iż dzięki tej publikacji czytelnicy będą bardziej świadomi znaczenia tych dzienników w codziennej pracy i będą potrafili wykorzystać je w najbardziej efektywny sposób.

Pamiętajmy, iż w dynamicznie zmieniającym się świecie technologii informacyjnej, stałe monitorowanie i analiza są kluczem do utrzymania systemów w najlepszym stanie oraz zapewnienia ich nieprzerwanego i bezpiecznego funkcjonowania.

Opracowano na podstawie materiałów od firmy Forward Defence oraz dokumentacji firmy Microsoft.

Idź do oryginalnego materiału