Przewodnik po analizie zagrożeń Sysmon, część 1

Ten artykuł jest pierwszą częścią serii poświęconej analizie zagrożeń Sysmon. Wszystkie pozostałe części serii:

Część 1: Wprowadzenie do analizy logów Sysmon (jesteśmy tutaj)
Część 2: Wykorzystanie danych o zdarzeniach Sysmon do identyfikacji zagrożeń
Część 3. Dogłębna analiza zagrożeń Sysmon za pomocą wykresów

Jeśli pracujesz w dziale bezpieczeństwa informacji, prawdopodobnie często musisz zrozumieć trwające ataki. Jeśli masz już wprawne oko, możesz szukać niestandardowej aktywności w „surowych” nieprzetworzonych logach – powiedzmy, uruchomionym skrypcie PowerShell za pomocą polecenia PobierzString lub skrypt VBS udający plik Worda - po prostu przewijając ostatnią aktywność w dzienniku zdarzeń systemu Windows. Ale to naprawdę duży ból głowy. Na szczęście Microsoft stworzył Sysmon, który znacznie ułatwia analizę ataków.

Chcesz zrozumieć podstawowe idee zagrożeń wyświetlanych w dzienniku Sysmon? Pobierz nasz przewodnik Zdarzenia WMI jako sposób na szpiegostwo i zdajesz sobie sprawę, jak osoby z wewnątrz mogą potajemnie obserwować innych pracowników. Głównym problemem w pracy z dziennikiem zdarzeń Windows jest brak informacji o procesach nadrzędnych, czyli o procesach nadrzędnych. nie da się z tego zrozumieć hierarchii procesów. Z kolei wpisy dziennika Sysmon zawierają identyfikator procesu nadrzędnego, jego nazwę i wiersz poleceń, który ma zostać uruchomiony. Dziękuję, Microsoftie.

W pierwszej części naszej serii przyjrzymy się, co możesz zrobić, korzystając z podstawowych informacji z Sysmon. W części XNUMX w pełni wykorzystamy informacje o procesie nadrzędnym do stworzenia bardziej złożonych struktur zgodności, znanych jako wykresy zagrożeń. W trzeciej części przyjrzymy się prostemu algorytmowi, który skanuje wykres zagrożeń w poszukiwaniu nietypowej aktywności poprzez analizę „wagi” wykresu. Na koniec zostaniesz nagrodzony schludną (i zrozumiałą) probabilistyczną metodą wykrywania zagrożeń.

Część 1: Wprowadzenie do analizy logów Sysmon

Co może pomóc Ci zrozumieć złożoność dziennika zdarzeń? Ostatecznie – SIEM. Normalizuje zdarzenia i upraszcza ich późniejszą analizę. Ale nie musimy posuwać się tak daleko, przynajmniej nie na początku. Na początek, aby zrozumieć zasady SIEM, wystarczy wypróbować wspaniałe, darmowe narzędzie Sysmon. I zaskakująco łatwo się z nią pracuje. Tak trzymaj, Microsofcie!

Jakie funkcje posiada Sysmon?

W skrócie - przydatne i czytelne informacje o procesach (patrz zdjęcia poniżej). Znajdziesz wiele przydatnych szczegółów, których nie ma w dzienniku zdarzeń systemu Windows, ale najważniejsze są następujące pola:

• Identyfikator procesu (w postaci dziesiętnej, nie szesnastkowej!)
• Identyfikator procesu nadrzędnego
• Linia poleceń procesu
• Wiersz poleceń procesu nadrzędnego
• Hash obrazu pliku
• Nazwy obrazów plików

Sysmon jest instalowany zarówno jako sterownik urządzenia, jak i jako usługa - więcej szczegółów tutaj. Jego kluczową zaletą jest możliwość analizy logów z kilka źródła, korelacja informacji i wyprowadzanie uzyskanych wartości do jednego folderu dziennika zdarzeń zlokalizowanego wzdłuż ścieżki Microsoft -> Windows -> Sysmon -> Operacyjny. Podczas moich własnych, mrożących krew w żyłach dochodzeń w dziennikach systemu Windows, musiałem ciągle przełączać się między, powiedzmy, folderem dzienników programu PowerShell a folderem Security, przeglądając dzienniki zdarzeń w odważnej próbie jakoś skorelować wartości między nimi . To nigdy nie jest łatwe zadanie i jak się później przekonałem, lepiej było od razu zaopatrzyć się w aspirynę.

Sysmon dokonuje milowego kroku naprzód, dostarczając przydatne (lub, jak lubią mawiać dostawcy, przydatne) informacje, które pomagają zrozumieć podstawowe procesy. Na przykład rozpocząłem tajną sesję wmiexec, symulując ruch inteligentnego insidera w sieci. Oto, co zobaczysz w dzienniku zdarzeń systemu Windows:

Dziennik systemu Windows zawiera pewne informacje o procesie, ale jest on mało przydatny. Plus identyfikatory procesów w formacie szesnastkowym???

Dla profesjonalnego informatyka znającego podstawy hakowania wiersz poleceń powinien być podejrzany. Użycie cmd.exe do następnie uruchomienia innego polecenia i przekierowania danych wyjściowych do pliku o dziwnej nazwie jest wyraźnie podobne do działań oprogramowania monitorującego i sterującego dowodzenie i kontrola (C2): W ten sposób tworzona jest pseudopowłoka przy użyciu usług WMI.
Przyjrzyjmy się teraz odpowiednikowi wpisu Sysmon, zwracając uwagę, ile dodatkowych informacji nam dostarcza:

Funkcje Sysmon na jednym zrzucie ekranu: szczegółowe informacje o procesie w czytelnej formie

Widzisz nie tylko wiersz poleceń, ale także nazwę pliku, ścieżkę do aplikacji wykonywalnej, co wie o niej system Windows („procesor poleceń systemu Windows”), identyfikator rodzicielski proces, wiersz poleceń rodzic, który uruchomił powłokę cmd, a także rzeczywistą nazwę pliku procesu nadrzędnego. Wreszcie wszystko w jednym miejscu!
Z loga Sysmona możemy wywnioskować, że z dużym prawdopodobieństwem ta podejrzana linia poleceń, którą widzieliśmy w „surowych” logach, nie jest efektem normalnej pracy pracownika. Wręcz przeciwnie, został wygenerowany przez proces podobny do C2 - wmiexec, jak wspomniałem wcześniej - i został bezpośrednio zrodzony przez proces usługi WMI (WmiPrvSe). Mamy teraz sygnał, że osoba atakująca zdalnie lub osoba posiadająca dostęp do poufnych informacji testuje infrastrukturę korporacyjną.

Przedstawiamy Get-Sysmonlogs

Oczywiście świetnie jest, gdy Sysmon umieszcza kłody w jednym miejscu. Ale prawdopodobnie byłoby jeszcze lepiej, gdybyśmy mogli programowo uzyskać dostęp do poszczególnych pól dziennika - na przykład za pomocą poleceń PowerShell. W takim przypadku możesz napisać mały skrypt PowerShell, który zautomatyzuje wyszukiwanie potencjalnych zagrożeń!
Nie byłem pierwszym, który wpadł na taki pomysł. I dobrze, że w niektórych postach na forach i GitHubie projektowanie Wyjaśniono już, jak używać programu PowerShell do analizowania dziennika Sysmon. W moim przypadku chciałem uniknąć konieczności pisania oddzielnych wierszy skryptu analizującego dla każdego pola Sysmon. Zastosowałem więc zasadę leniwego człowieka i myślę, że w rezultacie wymyśliłem coś interesującego.
Pierwszą ważną kwestią są umiejętności zespołu Zdarzenie Get-Win czytaj logi Sysmon, filtruj niezbędne zdarzenia i wypisz wynik do zmiennej PS, jak tutaj:

$events = Get-WinEvent  -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}

Jeśli chcesz samodzielnie przetestować polecenie, wyświetlając zawartość pierwszego elementu tablicy $events, $events[0].Message, wynikiem może być seria ciągów tekstowych o bardzo prostym formacie: nazwa Pole Sysmon, dwukropek, a następnie sama wartość.

Brawo! Wysyłanie dziennika Sysmon do formatu gotowego do JSON

Czy myślisz o tym samym co ja? Przy odrobinie większym wysiłku możesz przekonwertować dane wyjściowe na ciąg w formacie JSON, a następnie załadować go bezpośrednio do obiektu PS za pomocą potężnego polecenia Konwertuj z-Json .
Kod PowerShell do konwersji – to bardzo proste – pokażę w następnej części. Na razie zobaczmy, co potrafi moje nowe polecenie o nazwie get-sysmonlogs, które zainstalowałem jako moduł PS.
Zamiast zagłębiać się w analizę dziennika Sysmon poprzez niewygodny interfejs dziennika zdarzeń, możemy bez wysiłku wyszukiwać przyrostową aktywność bezpośrednio z sesji PowerShell, a także używać polecenia PS gdzie (alias – „?”), aby skrócić wyniki wyszukiwania:

Lista powłok cmd uruchomionych przez WMI. Tania analiza zagrożeń dzięki naszemu własnemu zespołowi Get-Sysmonlogs

Cudowny! Stworzyłem narzędzie do odpytywania dziennika Sysmon tak, jakby był bazą danych. W naszym artykule o EQL zauważono, że tę funkcję będzie realizowało opisane w nim fajne narzędzie, choć formalnie jeszcze poprzez prawdziwy interfejs przypominający SQL. Tak, EQL elegancki, ale poruszymy ten temat w trzeciej części.

Analiza sysmona i grafów

Cofnijmy się i pomyślmy o tym, co właśnie stworzyliśmy. Zasadniczo mamy teraz bazę danych zdarzeń systemu Windows dostępną za pośrednictwem programu PowerShell. Jak zauważyłem wcześniej, istnieją połączenia lub relacje między rekordami - poprzez ParentProcessId - dzięki czemu można uzyskać pełną hierarchię procesów.

Jeśli czytałeś serię „Przygody nieuchwytnego złośliwego oprogramowania” wiesz, że hakerzy uwielbiają tworzyć złożone, wieloetapowe ataki, w których każdy proces odgrywa swoją małą rolę i przygotowuje odskocznię do następnego kroku. Niezwykle trudno jest wyłapać takie rzeczy po prostu z „surowego” kłody.
Ale dzięki mojemu poleceniu Get-Sysmonlogs i dodatkowej strukturze danych, której przyjrzymy się w dalszej części tekstu (oczywiście wykresowi), mamy praktyczny sposób wykrywania zagrożeń - który wymaga jedynie przeprowadzenia odpowiedniego wyszukiwania wierzchołków.
Jak zawsze w przypadku naszych projektów blogowych DIY, im więcej będziesz pracować nad analizą szczegółów zagrożeń na małą skalę, tym bardziej zdasz sobie sprawę, jak złożone jest wykrywanie zagrożeń na poziomie przedsiębiorstwa. I ta świadomość jest niezwykle ważny punkt.

Z pierwszymi ciekawymi komplikacjami spotkamy się w drugiej części artykułu, gdzie zaczniemy łączyć ze sobą zdarzenia Sysmon w znacznie bardziej złożone struktury.

Źródło: www.habr.com