Stacja robocza użytkownika jest najbardziej wrażliwym punktem infrastruktury z punktu widzenia bezpieczeństwa informacji. Użytkownicy mogą otrzymać na swój służbowy adres e-mail list, który wydaje się pochodzić z bezpiecznego źródła, ale zawiera łącze do zainfekowanej witryny. Być może ktoś pobierze narzędzie przydatne do pracy z nieznanej lokalizacji. Tak, możesz wymyślić dziesiątki przypadków, w których złośliwe oprogramowanie może przedostać się do wewnętrznych zasobów firmy za pośrednictwem użytkowników. Dlatego stacje robocze wymagają większej uwagi, a w tym artykule podpowiemy, gdzie i jakie zdarzenia należy podjąć, aby monitorować ataki.
Aby wykryć atak na możliwie najwcześniejszym etapie, system Windows ma trzy przydatne źródła zdarzeń: dziennik zdarzeń zabezpieczeń, dziennik monitorowania systemu i dzienniki powłoki Power Shell.
Dziennik zdarzeń bezpieczeństwa
Jest to główne miejsce przechowywania dzienników zabezpieczeń systemu. Obejmuje to zdarzenia związane z logowaniem/wylogowaniem użytkownika, dostępem do obiektów, zmianami polityk i innymi działaniami związanymi z bezpieczeństwem. Oczywiście jeśli zostanie skonfigurowana odpowiednia polityka.
Wyliczanie użytkowników i grup (zdarzenia 4798 i 4799). Na samym początku ataku złośliwe oprogramowanie często przeszukuje lokalne konta użytkowników i lokalne grupy na stacji roboczej w celu znalezienia danych uwierzytelniających do jego podejrzanych poczynań. Zdarzenia te pomogą wykryć szkodliwy kod, zanim ten się rozprzestrzeni i wykorzystując zebrane dane rozprzestrzeni się na inne systemy.
Utworzenie konta lokalnego i zmiany w grupach lokalnych (zdarzenia 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 i 5377). Atak może także rozpocząć się np. od dodania nowego użytkownika do grupy administratorów lokalnych.
Próby logowania przy użyciu konta lokalnego (zdarzenie 4624). Szanowani użytkownicy logują się za pomocą konta domeny, a zidentyfikowanie loginu w ramach konta lokalnego może oznaczać początek ataku. Zdarzenie 4624 obejmuje także logowania w ramach konta domeny, więc podczas przetwarzania zdarzeń należy odfiltrować zdarzenia, w których domena różni się od nazwy stacji roboczej.
Próba zalogowania się na podane konto (zdarzenie 4648). Dzieje się tak, gdy proces działa w trybie „uruchom jako”. Nie powinno to mieć miejsca podczas normalnej pracy systemów, dlatego takie zdarzenia należy kontrolować.
Blokowanie/odblokowywanie stacji roboczej (zdarzenia 4800-4803). Kategoria podejrzanych zdarzeń obejmuje wszelkie działania, które miały miejsce na zablokowanej stacji roboczej.
Zmiany konfiguracji zapory ogniowej (zdarzenia 4944-4958). Oczywiście podczas instalowania nowego oprogramowania ustawienia konfiguracyjne zapory sieciowej mogą ulec zmianie, co będzie powodować fałszywe alarmy. W większości przypadków nie ma potrzeby kontrolowania takich zmian, ale na pewno nie zaszkodzi się o nich dowiedzieć.
Podłączanie urządzeń typu Plug'n'play (zdarzenie 6416 i tylko dla systemu Windows 10). Warto na to zwrócić uwagę, jeśli użytkownicy zwykle nie podłączają nowych urządzeń do stacji roboczej, ale nagle to robią.
Windows zawiera 9 kategorii audytu i 50 podkategorii do dostrajania. Minimalny zestaw podkategorii, które należy włączyć w ustawieniach:
Logowanie / wylogowanie
- Zalogować się;
- Wyloguj;
- Blokada konta;
- Inne zdarzenia logowania/wylogowania.
Zarządzanie kontem
- Zarządzanie kontem użytkownika;
- Zarządzanie grupą zabezpieczeń.
Zmiana zasad
- Zmiana polityki audytu;
- Zmiana zasad uwierzytelniania;
- Zmiana zasad autoryzacji.
Monitor systemu (Sysmon)
Sysmon to narzędzie wbudowane w system Windows, które może rejestrować zdarzenia w dzienniku systemowym. Zwykle trzeba go zainstalować osobno.
Te same zdarzenia można w zasadzie znaleźć w dzienniku bezpieczeństwa (po włączeniu żądanej polityki audytu), ale Sysmon podaje więcej szczegółów. Jakie zdarzenia można pobrać z Sysmon?
Tworzenie procesu (identyfikator zdarzenia 1). Dziennik zdarzeń związanych z bezpieczeństwem systemu może również poinformować Cię o uruchomieniu pliku *.exe, a nawet podać jego nazwę i ścieżkę uruchomienia. Ale w przeciwieństwie do Sysmon nie będzie mógł wyświetlić skrótu aplikacji. Złośliwe oprogramowanie można nawet nazwać nieszkodliwym programem notepad.exe, ale dopiero skrót wydobędzie je na światło dzienne.
Połączenia sieciowe (identyfikator zdarzenia 3). Oczywiście połączeń sieciowych jest wiele i nie da się ich wszystkich śledzić. Należy jednak wziąć pod uwagę, że Sysmon, w przeciwieństwie do dziennika zabezpieczeń, może powiązać połączenie sieciowe z polami ProcessID i ProcessGUID oraz wyświetla port i adresy IP źródła i miejsca docelowego.
Zmiany w rejestrze systemowym (identyfikator zdarzenia 12-14). Najłatwiejszym sposobem na dodanie się do autorun jest zarejestrowanie się w rejestrze. Dziennik bezpieczeństwa może to zrobić, ale Sysmon pokazuje, kto dokonał zmian, kiedy, skąd, identyfikator procesu i poprzednią wartość klucza.
Tworzenie pliku (identyfikator zdarzenia 11). Sysmon w przeciwieństwie do Security Log pokaże nie tylko lokalizację pliku, ale także jego nazwę. Oczywiste jest, że nie możesz śledzić wszystkiego, ale możesz kontrolować niektóre katalogi.
A teraz czego nie ma w zasadach dziennika bezpieczeństwa, ale jest w Sysmon:
Zmiana czasu utworzenia pliku (identyfikator zdarzenia 2). Niektóre złośliwe oprogramowanie może sfałszować datę utworzenia pliku, aby ukryć ją przed raportami dotyczącymi ostatnio utworzonych plików.
Ładowanie sterowników i bibliotek dynamicznych (identyfikatory zdarzeń 6-7). Monitorowanie ładowania bibliotek DLL i sterowników urządzeń do pamięci, sprawdzanie podpisu cyfrowego i jego ważności.
Utwórz wątek w działającym procesie (identyfikator zdarzenia 8). Jeden rodzaj ataku, który również należy monitorować.
Zdarzenia RawAccessRead (identyfikator zdarzenia 9). Operacje odczytu dysku za pomocą „.”. W zdecydowanej większości przypadków taką aktywność należy uznać za nienormalną.
Utwórz nazwany strumień plików (identyfikator zdarzenia 15). Zdarzenie jest rejestrowane, gdy tworzony jest nazwany strumień pliku, który emituje zdarzenia ze skrótem zawartości pliku.
Tworzenie nazwanego potoku i połączenia (identyfikator zdarzenia 17-18). Śledzenie złośliwego kodu, który komunikuje się z innymi komponentami za pośrednictwem nazwanego potoku.
Aktywność WMI (identyfikator zdarzenia 19). Rejestracja zdarzeń, które powstają podczas dostępu do systemu poprzez protokół WMI.
Aby chronić samego Sysmona, musisz monitorować zdarzenia o ID 4 (zatrzymywanie i uruchamianie Sysmon) i ID 16 (zmiany konfiguracji Sysmon).
Dzienniki powłoki Power Shell
Power Shell to potężne narzędzie do zarządzania infrastrukturą Windows, więc istnieje duże prawdopodobieństwo, że atakujący go wybierze. Dane zdarzeń programu Power Shell można uzyskać z dwóch źródeł: dziennika programu Windows PowerShell i dziennika programu Microsoft-WindowsPowerShell/operacyjnego.
Dziennik programu Windows PowerShell
Załadowano dostawcę danych (identyfikator zdarzenia 600). Dostawcy programu PowerShell to programy zapewniające źródło danych do przeglądania i zarządzania programem PowerShell. Na przykład wbudowanymi dostawcami mogą być zmienne środowiskowe systemu Windows lub rejestr systemowy. Należy monitorować pojawianie się nowych dostawców, aby w porę wykryć szkodliwe działania. Na przykład, jeśli wśród dostawców pojawi się WSMan, oznacza to, że została uruchomiona zdalna sesja PowerShell.
Dziennik Microsoft-WindowsPowerShell/operacyjny (lub MicrosoftWindows-PowerShellCore/Operational w PowerShell 6)
Rejestrowanie modułu (identyfikator zdarzenia 4103). Zdarzenia przechowują informacje o każdym wykonanym poleceniu i parametrach, z jakimi zostało ono wywołane.
Rejestrowanie blokowania skryptów (identyfikator zdarzenia 4104). Rejestrowanie blokowania skryptów pokazuje każdy wykonany blok kodu programu PowerShell. Nawet jeśli osoba atakująca spróbuje ukryć polecenie, ten typ zdarzenia pokaże faktycznie wykonane polecenie PowerShell. Ten typ zdarzenia może również rejestrować niektóre wywołania interfejsu API niskiego poziomu. Zdarzenia te są zwykle rejestrowane jako szczegółowe, ale jeśli w bloku kodu zostanie użyte podejrzane polecenie lub skrypt, zostanie to zarejestrowane jako ważność ostrzeżenia.
Należy pamiętać, że po skonfigurowaniu narzędzia do zbierania i analizowania tych zdarzeń wymagany będzie dodatkowy czas debugowania, aby zmniejszyć liczbę fałszywych alarmów.
Powiedz nam w komentarzach, jakie logi zbierasz na potrzeby audytów bezpieczeństwa informacji i jakich narzędzi w tym celu używasz. Jednym z obszarów naszej działalności są rozwiązania umożliwiające audyt zdarzeń związanych z bezpieczeństwem informacji. Aby rozwiązać problem gromadzenia i analizowania logów, sugerujemy przyjrzeć się bliżej , który potrafi kompresować przechowywane dane w stosunku 20:1, a jedna jego zainstalowana instancja jest w stanie przetworzyć do 60000 10000 zdarzeń na sekundę z XNUMX XNUMX źródeł.
Źródło: www.habr.com