Jakie zdarzenia z logu Windows Security warto monitorować i analizować?

Zarządzanie logami Windows

Od czasów Windows Server 2008, który był systemem przełomowym pod wieloma względami, zarządzanie audytem Microsoftowym w organizacji stało się o wiele prostsze. Wprowadzona opcja Advanced Audit Policy (Zaawansowana Polityka Audytu) pozwoliła na granularne dobieranie ustawień logowania i wybierania konkretnych kategorii zdarzeń, które chce się monitorować. To, jakie ustawienia powinno się zastosować można wyczytać między innymi w poradach Microsoft baseline security templates, o którym pisaliśmy tutaj. Wzór polityki audytu można przekonwertować na Group Policy Object (GPO) i w prosty sposób zaaplikować na systemy Windows.

Ważnym aspektem zarządzania logami jest ich centralizacja i efektywne przeszukiwanie. Microsoft wychodzi tutaj naprzeciw i udostępnia wbudowany w każdy system Windows mechanizm Windows Event Forwarding. Jego wdrożenie jest bardzo proste, gdyż korzysta z wbudowanych narzędzi, subskrypcji i protokołu Windows Remote Management (WinRM) i nie wymaga trudnej konfiguracji środowiska. Dzięki agregowaniu logów w jedno repozytorium uzyskujemy wiele korzyści:

• Możemy w prosty sposób przeglądać zdarzenia bez konieczności logowania się na każdy z systemów osobno
• W razie utraty dzienników zdarzeń na stacji lub serwerze, np. z powodu ataku hakerskiego lub awarii, mamy niezbędny backup wszystkich zdarzeń
• Z jednego repozytorium logi możemy następnie przesłać do innych systemów, na przykład SIEM

Monitorowanie kluczowych pod kątem bezpieczeństwa zdarzeń

Zapisywanie i przechowywanie dużej ilości logów jest ważne, jeśli chodzi o analizę wsteczną ataków, nieprawidłowości, błędów czy kontroli użytkowników. Jednak nie jesteśmy w stanie monitorować wszystkich logów ze stacji roboczych czy serwerów Windows. Wybranie zdarzeń kluczowych dla zapewniania monitoringu bezpieczeństwa w organizacji może być trudne, dlatego postawiliśmy wybrać najciekawsze naszym zdaniem zdarzenia z logu Windows Security i opisać ich użyteczność. Nie będziemy się tutaj skupiać na logu Sysmon (MS Sysinternals), ponieważ zamierzamy opisać go w oddzielnym artykule.

1. Windows Firewall Wszystkie zdarzenia związane ze zmianą konfiguracji lokalnej zapory są warte analizy lub chociaż powiadamiania w czasie rzeczywistym. Każda ingerencja w firewalla może świadczyć o złośliwej aktywności na stacji lub serwerze. Ważne zdarzenia z Event Log w tym przypadku to:

• 4946 – Dodanie nowej reguły.
• 4947 – Modyfikacja istniejącej reguły.
• 4948 – Usunięcie reguły.
• 4954 – Zmiana w polityce dotycząca Windows Firewall. Nowe ustawienia zostaną zastosowane.
• 5025 – Usługa Windows Firewall została zatrzymana.

2. Group Policy Jeśli ustawienia krytyczne dla bezpieczeństwa wprowadzane są na hosty poprzez GPO (a jest tak najczęściej) to warto upewnić się czy polityka została poprawnie przyjęta i zaaplikowana na systemie docelowym. W tym przypadku ważne będą zdarzenia:

• 6144 – Polityka bezpieczeństwa w GPO została zaaplikowana poprawnie.
• 6145 – Jeden lub więcej błędów zostało wykrytych podczas przetwarzania polityki bezpieczeństwa w GPO.

<p3. Czyszczenie dziennika zdarzeń W artykule o zaciemnianiu aktywności hackerskich pisaliśmy o złośliwych działaniach, które prowadzą do wyczyszczenie logów na stacji lub serwerze. Warto monitorować takie identyfikatory zdarzeń jak:

• 104 – Event Log został wyczyszczony.
• 1102 – Audit Log został wyczyszczony.
• 4719 – Polityka audytu na tym systemie została zmieniona.

Szczególnie ostatnie zdarzenie może być efektem działań sprytnego hackera, który próbuje zaciemnić część swoich operacji modyfikując rodzaj audytowanych operacji.

4. Blokady kont Zablokowanie konta może świadczyć o ataku brute-force lub próbach Pass-the-Hash. Warto monitorować zdarzenia o identyfikatorze 4740. Dowiemy się z nich o koncie, które zostało zablokowane oraz hoście, z którego wykonywane były próby zalogowania.

5. Udane i nieudane logowania Logowania oraz próby logowań lokalnych to podstawowy symptom wielu technik hackerskich takich jak Pass-the-Hash, DCSync, Kerberoasting i innych z Cyber Killchain. Warto monitorować i rozumieć zdarzenia o identyfikatorach:

• 4624 – Udane logowanie konta.
• 4625 – Nieudane logowanie konta.

Zdarzenia zalogowania zawierają wiele cennych szczegółów, które mogą pomóc w analizie i wykrywaniu złośliwych działań. Na przykład rozróżnienie typu logowania w polu Logon Type, gdzie odpowiednie wartości to:

• 2 – logowanie interakcyjne z klawiatury
• 3 – dostęp sieciowy, najczęściej do udostępnionego folderu
• 4 – logowanie jako zadanie wykonywane w systemie, najczęściej scheduled tasks
• 5 – logowania jako usługa przy jej starcie w systemie
• 7 – odblokowanie ekranu na stacji roboczej lub serwerze
• 8 – logowanie poświadczeniami w postaci czystego tekstu, najczęściej w IIS przy wybranej opcji „basic authentication”.
• 10 – logowanie zdalne, np. przez Remote Desktop Services
• 11 – logowanie poświadczeniami zapamiętanymi w cache, najczęściej w stacji przenośnej, która utraciła połączenie z domeną

W zdarzeniu warto również zwrócić uwagę na pole Source Network Address, które zawiera informację o stacji źródłowej, która inicjowała proces logowania. Jeśli adres ten nie jest znany i pochodzi z innej sieci, to należy podjąć dodatkowe kroki w celu wyjaśnienia zdarzenia.

6. Dodanie członków i modyfikacja grup Grupy o typie security są w systemach Windows medium do nadawania uprawnień. Każda zmiana ich członkostwa wiążę się ze zmianą uprawnień posiadanych przez dodane do grupy konto. Są to zdarzenia niezbędne do pełnego monitorowania bezpieczeństwa.

• 4728 – Dodanie członka do grupy domenowej.
• 4732 – Dodanie członka do grupy lokalnej.
• 4756 – Dodanie członka do grupy uniwersalnej.
• 4735 – Modyfikacja grupy lokalnej (nazwy, SID, uprawnień).

Przy wszystkich z powyższych logów otrzymujemy informacje o sprawcy zdarzenia, co może być kluczowe w przeprowadzaniu dochodzenia.

7. Inne ciekawe zdarzenia

• 4648 – To zdarzenie występuje w sytuacji, gdy użyte zostaną poświadczenia konta innego niż aktualnie zalogowane na systemie. Jest to szczególnie ważne do wychwycenia technik typu Horizontal i Lateral Movement, gdy atakujący dokonuje prób logowania na różne konta i różne hosty z jednej stacji lub serwera. Wszystkie udane wywołania komendy „RunAs” również zostaną tutaj odłożone. Niestety zdarzenie to zawiera również dużo szumu, jak uruchomienie zaplanowanych zadań na innych poświadczeniach czy zalogowanie się do aplikacji podając inne poświadczenia.
• 4674 – To zdarzenie występuje, gdy konto wykorzysta posiadane lokalne uprawnienia w systemie do wykonania określonej akcji. Niestety ten event nie jest dobrze udokumentowany przez Microsoft i zawiera sporo niewiadomych, także szumów. Nie mniej jednak, można wychwycić z niego zalogowania się konta z uprawnieniami administratora lokalnego na stacji, instalację nowego oprogramowania czy uruchomienie programu jak administrator, co czyni ten log wartym obserwacji.

Podsumowanie

Monitorowanie niektórych zdarzeń z Windows Event Log w czasie rzeczywistym może być nie lada wyzwaniem w rozległej organizacji o dużej liczbie końcówek. Logi Microsoftowe zawierają jednak cenne informacje, których nie możemy uzyskać bez posiadania drogich narzędzi i instalacji agentów na stacjach roboczych i serwerach. Warto czerpać z nich jak najwięcej danych, odsiać niepotrzebne szumy i stworzyć korelację ze zdarzeniami z innych systemów bezpieczeństwa. W ten sposób możemy zapewnić kompleksowy monitoring i analizę incydentów.