Stacja robocza użytkownika to najbardziej narażone miejsce w infrastrukturze w kontekście bezpieczeństwa informacji. Użytkownicy mogą otrzymać e-mail na swoją służbową skrzynkę, który wydaje się pochodzić z bezpiecznego źródła, ale zawiera link do zainfekowanej strony. Możliwe, że ktoś pobierze przydatne narzędzie z nieznanego źródła. Można wymyślić wiele przypadków, w jaki sposób złośliwe oprogramowanie może dostać się do zasobów wewnętrznych firmy przez użytkowników. Dlatego stacje robocze wymagają szczególnej uwagi, a w artykule opowiemy, skąd i jakie zdarzenia można brać pod uwagę w monitorowaniu ataków.
Aby wykryć atak na najwcześniejszym etapie, w systemie Windows dostępne są trzy przydatne źródła zdarzeń: dziennik zdarzeń bezpieczeństwa, dziennik monitorowania systemu oraz dzienniki PowerShell.
Dziennik zdarzeń bezpieczeństwa (Security Log)
To główne miejsce przechowywania systemowych logów bezpieczeństwa. Znajdują się tutaj zdarzenia logowania/wylogowania użytkowników, dostęp do obiektów, zmiany polityk i inne aktywności związane z bezpieczeństwem. Oczywiście, jeśli odpowiednia polityka jest skonfigurowana.
Próby przejęcia użytkowników i grup (zdarzenia 4798 i 4799). Złośliwe oprogramowanie na samym początku ataku często próbuje przeszukać lokalne konta użytkowników i lokalne grupy na stacji roboczej, aby znaleźć dane logowania do niecnych celów. Te zdarzenia mogą pomóc wykryć złośliwy kod wcześniej, zanim posunie się dalej i, korzystając z zebranych danych, rozpowszechni się na inne systemy.
Tworzenie lokalnego konta użytkownika oraz zmiany w lokalnych grupach (zdarzenia 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 i 5377). Atak może także rozpocząć się na przykład od dodania nowego użytkownika do grupy lokalnych administratorów.
Próby logowania z lokalnym kontem użytkownika (zdarzenie 4624). Użytkownicy korzystający z konta domenowego logują się, a wykrycie logowania z lokalnym kontem użytkownika może oznaczać początek ataku. Zdarzenie 4624 obejmuje również logowania z konta domenowego, dlatego w przypadku przetwarzania zdarzeń należy odfiltrować te, w których domena różni się od nazwy stacji roboczej.
Próba logowania z określonym kontem użytkownika (zdarzenie 4648). To zdarza się, gdy proces jest uruchamiany w trybie „Uruchom jako” (run as). W normalnym trybie pracy systemu nie powinno to mieć miejsca, dlatego takie zdarzenia powinny być kontrolowane.
Blokada/odblokowanie stacji roboczej (zdarzenia 4800-4803). Do kategorii podejrzanych zdarzeń można zaliczyć wszelkie działania, które miały miejsce na zablokowanej stacji roboczej.
Zmiany konfiguracji zapory sieciowej (zdarzenia 4944-4958). Jasne jest, że podczas instalacji nowego oprogramowania ustawienia konfiguracji zapory mogą się zmieniać, co spowoduje fałszywe alarmy. Kontrolowanie takich zmian zazwyczaj nie jest konieczne, ale wiedza o nich z pewnością się przyda.
Podłączenie urządzeń Plug’n’play (zdarzenie 6416 i tylko dla Windows 10). Warto to monitorować, jeśli użytkownicy zazwyczaj nie podłączają nowych urządzeń do stacji roboczej, a nagle podłączyli nowe.
Windows zawiera 9 kategorii audytu i 50 podkategorii do dokładnej konfiguracji. Minimalny zestaw podkategorii, które warto włączyć w ustawieniach:
Logon/Logoff
- Logon;
- Logoff;
- Zablokowanie konta;
- Inne zdarzenia logowania/wylogowania.
Zarządzanie kontami
- Zarządzanie kontami użytkowników;
- Zarządzanie grupami bezpieczeństwa.
Zmiana polityki
- Zmiana polityki audytu;
- Zmiana polityki uwierzytelniania;
- Zmiana polityki autoryzacji.
Monitor systemowy (Sysmon)
Sysmon to wbudowane w Windows narzędzie, które potrafi rejestrować zdarzenia w dzienniku systemowym. Zazwyczaj wymaga oddzielnej instalacji.
Te same zdarzenia można zasadniczo znaleźć w dzienniku bezpieczeństwa (włączając odpowiednią politykę audytu), ale Sysmon daje więcej szczegółów. Jakie zdarzenia można pobrać z Sysmon?
Tworzenie procesu (ID zdarzenia 1). Systemowy dziennik zdarzeń bezpieczeństwa może również powiedzieć, kiedy wystartował jakiś *.exe, a nawet pokaże jego nazwę i ścieżkę uruchomienia. Jednak w przeciwieństwie do Sysmon nie może pokazać hasha aplikacji. Złośliwe oprogramowanie może być nazywane nawet niewinnym notepad.exe, ale to właśnie hash ujawnia jego prawdziwe oblicze.
Połączenia sieciowe (ID zdarzenia 3). Oczywiste jest, że istnieje wiele połączeń sieciowych i nie można ich wszystkich monitorować. Jednak istotne jest, że Sysmon w przeciwieństwie do dziennika bezpieczeństwa potrafi powiązać połączenie sieciowe z polami ProcessID i ProcessGUID, pokazuje port oraz adresy IP adres źródłowy i odbiorczy.
Zmiany w rejestrze systemowym (ID zdarzenia 12-14). Najłatwiejszym sposobem na dodanie siebie do autostartu jest zapisanie się w rejestrze. Security Log to potrafi, ale Sysmon pokazuje, kto wprowadził zmiany, kiedy, skąd, ID procesu oraz poprzednią wartość klucza.
Tworzenie pliku (ID zdarzenia 11). Sysmon, w przeciwieństwie do Security Log, pokaże nie tylko lokalizację pliku, ale także jego nazwę. Oczywiście, nie można wszystkiego kontrolować, ale można przeprowadzać audyt określonych katalogów.
A teraz to, czego w politykach Security Log nie ma, a jest w Sysmon:
Zmiana czasu utworzenia pliku (ID zdarzenia 2). Niektóre złośliwe oprogramowanie może zmieniać datę utworzenia pliku, aby ukryć go z raportów dotyczących recently created files.
Ładowanie sterowników i bibliotek dynamicznych (ID zdarzeń 6-7). Monitorowanie ładowania do pamięci DLL i sterowników urządzeń, sprawdzanie podpisu cyfrowego i jego ważności.
Tworzenie wątku w wykonywanym procesie (ID zdarzenia 8). Jeden z typów ataków, na który również trzeba zwracać uwagę.
Zdarzenia RawAccessRead (ID zdarzenia 9). Operacje odczytu z dysku za pomocą ".". W absolutnej większości przypadków taka aktywność powinna być uważana za nieprawidłową.
Tworzenie nazwanych strumieni plikowych (ID zdarzenia 15). Zdarzenie rejestrowane jest, gdy tworzony jest nazwany strumień plikowy, który generuje zdarzenia z hashem zawartości pliku.
Tworzenie named pipe i połączenia (ID zdarzenia 17-18). Monitorowanie złośliwego kodu, który komunikuje się z innymi komponentami poprzez named pipe.
Aktywność WMI (ID zdarzenia 19). Rejestrowanie zdarzeń, które są generowane przy dostępie do systemu za pomocą protokołu WMI.
Aby chronić sam Sysmon, należy monitorować zdarzenia o ID 4 (zatrzymanie i uruchomienie Sysmon) oraz ID 16 (zmiana konfiguracji Sysmon).
Dzienniki Power Shell
Power Shell to potężne narzędzie do zarządzania infrastrukturą Windows, więc istnieje duże prawdopodobieństwo, że atakujący wybierze właśnie je. W celu uzyskania danych o zdarzeniach Power Shell można korzystać z dwóch źródeł: dziennika Windows PowerShell i dziennika Microsoft-WindowsPowerShell / Operational log.
Dziennik Windows PowerShell
Załadowano dostawcę danych (ID zdarzenia 600). Dostawcy PowerShell to programy, które służą jako źródło danych dla PowerShell do ich przeglądania i zarządzania nimi. Przykładowymi wbudowanymi dostawcami mogą być zmienne środowiskowe systemu Windows lub rejestr systemowy. Konieczne jest monitorowanie pojawiających się dostawców, aby na czas wykryć złośliwą aktywność. Na przykład, jeśli zauważysz, że wśród dostawców pojawił się WSMan, oznacza to, że rozpoczęto zdalną sesję PowerShell.
Dziennik Microsoft-WindowsPowerShell / Operational (lub MicrosoftWindows-PowerShellCore / Operational w PowerShell 6)
Rejestrowanie modułów (ID zdarzenia 4103). W zdarzeniach przechowywane są informacje o każdym wykonanym poleceniu oraz jego parametrach.
Rejestrowanie blokady skryptów (ID zdarzenia 4104). Rejestrowanie blokady skryptów pokazuje każdy wykonany blok kodu PowerShell. Nawet jeśli napastnik spróbuje ukryć polecenie, ten typ zdarzenia pokaże faktycznie wykonane polecenie PowerShell. W tym typie zdarzenia mogą być również rejestrowane niektóre wywołania API na niskim poziomie, te zdarzenia zazwyczaj zapisywane są jako Verbose, ale jeśli w bloku kodu używane jest podejrzane polecenie lub skrypt, zostanie zarejestrowane z krytycznością Warning.
Zauważ, że po skonfigurowaniu narzędzia do zbierania i analizy tych zdarzeń będzie potrzebny dodatkowy czas na debugowanie, aby zmniejszyć liczbę fałszywych alarmów.
Podziel się w komentarzach, jakie logi zbierasz w celu audytu bezpieczeństwa informacji i jakich narzędzi do tego używasz. Jednym z naszych kierunków są rozwiązania do audytu zdarzeń bezpieczeństwa informacji. W rozwiązaniu problemu zbierania i analizy logów możemy zaproponować przyjrzenie się , który potrafi kompresować przechowywane dane w stosunku 20:1, a jeden z jego zainstalowanych egzemplarzy jest w stanie obsługiwać do 60000 zdarzeń na sekundę z 10000 źródeł.
Źródło: habr.com
