Skuteczne wykrywanie incydentów i nadużyć w domenie wymaga precyzyjnej konfiguracji audytu. Jest to kluczowe w kontekście bezpieczeństwa każdego systemu Windows/Active Directory, by umożliwiść wczesne wykrycie potencjalnego rekonesansu i późniejszgo ataku na infrastrukturę opartą o Windows Server. Poniżej przedstawiam wytyczne oparte na zaleceniach Microsoftu
Dlaczego audyt i przegląd logów jest taki ważny
Według Microsoftu administratorzy powinni traktować audyt jako część strategii obrony. Bez przemyślanej konfiguracji niektóre zdarzenia (np. 4618 – wzorzec zdarzenia bezpieczeństwa lub 4649 – wykrycie ataku replay) nie będą rejestrowane; dopiero konfiguracja zaawansowanej polityki umożliwi pełne logowanie. W dokumentacji wskazano, że należy dostosować ustawienia do poziomu ryzyka i regularnie je testować
Ustawienia polityki audytu
Microsoft udostępnia tabele z wyjściowymi, zalecanymi i silniejszymi ustawieniami dla poszczególnych kategorii audytu. Kilka kluczowych zaleceń:
| Kategoria/podkategoria | Zalecenie podstawowe | Opis |
|---|---|---|
| Account Logon → Audit Credential Validation | Tak dla Success | Rejestruj pomyślne uwierzytelnienia w usługach domenowych, co umożliwi śledzenie logowań Kerberos |
| Account Management → Audit Security Group Management | Tak dla Success | Loguje tworzenie i modyfikowanie grup bezpieczeństwa; wzmocniona konfiguracja zaleca również rejestrowanie nieudanych prób |
| Detailed Tracking → Audit Process Creation | Tak dla Success, w konfiguracji silniejszej również Failure | Zapisywanie tworzenia procesów pomaga analizować aktywność malware i skrypty |
| Logon and Logoff → Audit Logon | Tak dla Success i Failure | Domyślnie w nowszych systemach zarówno sukces, jak i niepowodzenie logowania są rejestrowane; pozwala to monitorować nieudane próby logowania |
| Policy Change → Audit Audit Policy Change | Tak dla Success i Failure | Loguje każdą zmianę konfiguracji audytu; jest to kluczowe do wykrywania manipulacji logowaniem |
| System → Audit System Integrity | Tak dla Success i Failure | Monitoruje ładowanie sterowników i modyfikacje jądra – pozwala wykryć rootkity |
Od czego zacząć?
Administratorzy powinni zaczynać od zalecanej konfiguracji podstawowej i modyfikować ją zgodnie z wymaganiami (np. w środowiskach wysokiego ryzyka włączyć rejestrowanie zarówno sukcesów, jak i porażek we wszystkich kategoriach).
Podsumowanie
Krytyczne identyfikatory zdarzeń do monitorowania
Microsoft w "Appendix L – Events to Monitor" wyszczególnia zdarzenia, którym nadano wysoką lub średnią krytyczność. Poniżej lista najistotniejszych zdarzeń z opisem – jedno wystąpienie zdarzeń o wysokiej krytyczności powinno być natychmiast analizowane
| Priorytet | Identyfikator zdarzenia | Opis zdarzenia i działanie |
|---|---|---|
| Wysoki | 4618 | A monitored security event pattern has occurred – sygnalizuje wykrycie wzorca zagrożenia. Sprawdź, jakie zdarzenia wywołały alarm (np. powtarzające się błędy logowania). |
| Wysoki | 4649 | Wykryto atak replay; może to być fałszywy alarm wynikający z błędnej konfiguracji, ale wymaga analizy konfiguracji SPN i czasu systemowego. |
| Wysoki | 4719 (legacy 612) | System audit policy was changed – informuje o zmianie polityki audytu; natychmiast sprawdź kto zmienił ustawienia. |
| Wysoki | 4765 / 4766 | Dodano (lub próbowano dodać) atrybut SID History do konta – może wskazywać na eskalację uprawnień w trakcie migracji domen. |
| Wysoki | 4794 | Podjęto próbę ustawienia trybu Directory Services Restore – potencjalny znak przygotowywania ataku lub odzyskiwania AD. |
| Wysoki | 4897 (legacy 801) | Włączono role separation; sprawdź, czy nie jest to próba ograniczenia uprawnień innych administratorów. |
| Wysoki | 4964 | Special groups have been assigned to a new logon – logowanie otrzymało grupy specjalne (np. Administratorzy); zbadaj, czy nie jest to nadużycie uprawnień. |
| Wysoki | 5124 | Zaktualizowano ustawienia podpisywania na serwerze OCSP; w środowiskach korzystających z PKI wymaga weryfikacji. |
| Średni – wysoki | 1102 (legacy 517) | Audit log was cleared – ktoś skasował logi bezpieczeństwa; zbadaj, czy nie ukryto śladów ataku. |
| Średni | 4621 | Administrator odzyskał system po CrashOnAuditFail – część zdarzeń mogła nie zostać zapisana. |
| Średni | 4706, 4713, 4714, 4715, 4716 | Tworzenie zaufania między domenami, zmiana polityk Kerberos, polityki szyfrowania i SACL – wszystkie te zmiany mogą wpływać na bezpieczeństwo domeny. |
| Średni | 4724 | Próba zresetowania hasła konta – jeżeli dotyczy kont uprzywilejowanych, wymaga szybkiej weryfikacji. |
| Średni | 4727, 4735, 4737, 4739, 4754, 4755 | Tworzenie i modyfikacja grup globalnych/uniwersalnych, zmiany w polityce domeny – mogą wskazywać na eskalację uprawnień. |
| Średni | 4764 | Usunięto grupę zabezpieczeń lub zmieniono jej typ. |
| Średni | 4907–4912 | Zmiany ustawień audytu na obiektach, modyfikacja tabeli logowań specjalnych, zmiany w politykach „Per User Audit” – warto odnotować podczas przeglądu konfiguracji. |
Jak skonfigurować i analizować
- Konfiguracja audytu – w konsoli „Group Policy Management” utwórz nową GPO przypisaną do kontrolerów domeny lub serwerów. W drzewie Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration włącz wskazane podkategorie zgodnie z tabelą. Zalecane jest również włączenie zasady Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings.
- Ustawianie SACL na obiektach – w przypadku krytycznych zasobów (np. OU zawierających konta administratorów) dodaj systemowe ACL (System Access Control Lists), aby rejestrować dostęp do tych obiektów.
- Analiza zdarzeń – w Event Viewer filtruj log „Security” według ID zdarzeń z tabeli powyżej. W systemach z dużą liczbą zdarzeń zaleca się skorzystanie z narzędzi SIEM (np. Microsoft Sentinel) i utworzenie alertów, które zareagują na pojedyncze wystąpienie zdarzeń o wysokiej krytyczności lub wzrost liczby zdarzeń o średniej krytyczności.
- Testowanie i dokumentacja – przed wprowadzeniem nowych ustawień w produkcji przetestuj je w środowisku testowym. Monitoruj, czy liczba logowanych zdarzeń nie powoduje przeciążenia systemów. Dokumentuj zmiany w politykach audytu i regularnie sprawdzaj, czy zasady są przestrzegane.
