Artykuł ten jest pierwszą częścią serii dotyczącej analizy zagrożeń Sysmon. Pozostałe części serii to:
Część 1. Wprowadzenie do analizy logów Sysmon (jesteśmy tutaj)
Część 2. Wykorzystanie danych z wydarzeń Sysmon do identyfikacji zagrożeń
Część 3. Zaawansowana analiza zagrożeń Sysmon przy użyciu grafów
Jeśli zajmujesz się bezpieczeństwem informacji, z pewnością często musisz zbadać występujące ataki. Jeśli masz już wprawne oko, możesz poszukać nietypowej aktywności w "surowych" nieprzetworzonych logach — na przykład skryptu PowerShell z uruchomioną lub skryptem VBS udającym plik Word — przeglądając ostatnią aktywność w dzienniku zdarzeń 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 kryjące się za wyświetlanymi w logu Sysmon zagrożeniami? Pobierz nasz przewodnik i zrozumiesz, jak insiderzy mogą dyskretnie obserwować innych pracowników. Głównym problemem pracy z dziennikiem zdarzeń Windows jest brak informacji o procesach macierzystych, to znaczy nie można zrozumieć hierarchii procesów. W zapisach logu Sysmon z kolei znajdują się identyfikator procesu macierzystego, jego nazwa i uruchamiana linia poleceń. Dziękujemy, Microsoft.
W pierwszej części naszej serii przyjrzymy się, co można zrobić z podstawowymi informacjami z Sysmon. W drugiej części w pełni skorzystamy z informacji o procesach macierzystych, aby stworzyć bardziej złożone struktury zgodności, znane jako grafy zagrożeń. W trzeciej części zaprezentujemy prosty algorytm, który skanuje graf zagrożeń w poszukiwaniu nietypowej aktywności poprzez analizę "wagi" grafu. A na koniec jako nagrodę czeka na Ciebie zgrabna (i zrozumiała) probabilistyczna metoda wykrywania zagrożeń.
Część 1: Wprowadzenie do analizy logów Sysmon
Co pomoże zrozumieć złożoności dziennika zdarzeń? Ostatecznie – SIEM. Normalizuje zdarzenia i upraszcza ich późniejszą analizę. Ale nie musimy od razu iść tak daleko, przynajmniej na początku. Na początek dla zrozumienia zasad SIEM wystarczy spróbować wspaniałego, darmowego narzędzia Sysmon. Zaskakująco łatwo się z nim pracuje. Tak trzymaj, Microsoft!
Jakie możliwości ma Sysmon?
Krótko mówiąc – przydatne i czytelne informacje o procesach (zobacz zdjęcia poniżej). Odkryjesz mnóstwo przydatnych szczegółów, których brakuje w dzienniku zdarzeń systemu Windows, ale najważniejsze to następujące pola:
- ID procesu (w postaci dziesiętnej, a nie hex!)
- ID procesu macierzystego
- Linia poleceń procesu
- Linia poleceń procesu macierzystego
- Hash obrazu pliku
- Nazwy obrazów plików
Sysmon jest instalowany jednocześnie jako sterownik urządzenia i jako usługa – więcej informacji Jego kluczową zaletą jest możliwość analizy logów z kilku źródeł, korelacja informacji i wydobycie wynikowych wartości do jednego folderu dziennika zdarzeń, znajdującego się pod ścieżką Microsoft -> Windows -> Sysmon -> Operacyjny. W moich własnych dochodzeniach w logach Windows, które przyprawiały mnie o dreszcze, nieustannie musiałem przełączać się między na przykład folderem z logami PowerShell a folderem „Bezpieczeństwo”, przeglądając dzienniki zdarzeń w heroicznej próbie dopasowania wartości między nimi. To zadanie wcale nie jest łatwe, a jak potem zrozumiałem, najlepiej było od razu zaopatrzyć się w aspirynę.
Sysmon dokonuje jakościowego skoku naprzód, dostarczając przydatne (lub jak wolą mówić dostawcy – efektywne) informacje, które pomagają w zrozumieniu podstawowych procesów. Na przykład uruchomiłem ukrytą sesję , symulującą ruch przebiegłego insajdera w sieci. Oto co zobaczysz w dzienniku zdarzeń systemu Windows:
W dzienniku Windows widoczna jest jakaś informacja o procesie, ale jest ona mało przydatna. Plus identyfikatory procesów w formie szesnastkowej???
U profesjonalnego specjalisty IT zrozumienie podstaw hakowania powinno budzić podejrzenia wobec linii poleceń. Użycie cmd.exe do uruchomienia innej komendy z przekierowaniem wyjścia do pliku o dziwnej nazwie – zdecydowanie przypomina działania oprogramowania do kontroli i zarządzania. : w ten sposób tworzony jest pseudosh shell za pomocą usług WMI.
Teraz przyjrzyjmy się odpowiednikowi zapisu z Sysmon, zwracając uwagę na to, ile dodatkowych informacji daje nam on:
Możliwości Sysmon w jednym zrzucie ekranu: szczegółowe informacje o procesie w czytelnej formie
Nie tylko widzisz polecenie, ale także nazwę pliku, ścieżkę do uruchamialnej aplikacji, co Windows o tym wie („procesor poleceń systemu Windows”), identyfikator procesu nadrzędnego polecenie nadrzędnego, który uruchomił powłokę cmd, a także rzeczywistą nazwę pliku procesu nadrzędnego. Wszystko w jednym miejscu, w końcu!
Z logu Sysmon możemy wywnioskować, że z wysokim prawdopodobieństwem ten podejrzany wiersz polecenia, który widzieliśmy w "surowych" logach, nie jest wynikiem normalnej pracy pracownika. Przeciwnie, został wygenerowany przez proces podobny do C2 — wmiexec, jak wspomniałem wcześniej — i był bezpośrednio wygenerowany przez proces usługi WMI (WmiPrvSe). Teraz mamy wskaźnik, że zdalny atakujący lub insider sprawdza infrastrukturę firmy.
Przedstawiamy Get-Sysmonlogs
Oczywiście świetnie, gdy Sysmon posiada logi w jednym miejscu. Ale byłoby jeszcze lepiej, gdybyśmy mogli uzyskać dostęp do poszczególnych pól logu w sposób programowy – na przykład przez polecenia PowerShell. W takim przypadku można by napisać mały skrypt PowerShell, który zautomatyzowałby poszukiwanie potencjalnych zagrożeń!
Nie tylko ja miałem taki pomysł. I dobrze, że w niektórych postach na forach i projektach GitHub Pierwszym ważnym punktem jest możliwość komendy
Get-WinEvent $events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
Jeśli chcesz samodzielnie sprawdzić działanie zespołu, możesz uzyskać serię tekstowych ciągów w bardzo prostym formacie, korzystając z wyświetlenia zawartości w pierwszym elemencie tablicy $events, $events[0].Message: nazwa pola Sysmon, dwukropek, a następnie sama wartość.
Hurra! Wyjście logu Sysmon w gotowym formacie JSON
Myślisz o tym samym, co ja? Przy odrobinie wysiłku można przekonwertować wyjście na sformatowany ciąg JSON, a następnie załadować go bezpośrednio do obiektu PS z użyciem potężnej komendy .
Pokażę kod PowerShell do konwersji – jest bardzo prosty – w następnej części. A tymczasem przyjrzyjmy się, co potrafi mój nowy zespół o nazwie get-sysmonlogs, który zainstalowałem jako moduł PS.
Zamiast wgłębiać się w analizę logów Sysmon poprzez niewygodny interfejs dziennika zdarzeń, możemy bez problemu przeszukiwać inkrementalną aktywność bezpośrednio z sesji PowerShell oraz korzystać z polecenia PS (alias – „?”) dla skrócenia wyników:
Lista cmd-shelów uruchomionych przez WMI. Analiza zagrożeń tanio za pomocą naszego własnego polecenia Get-Sysmonlogs
Niesamowite! Stworzyłem narzędzie do badania logów Sysmon, jak gdyby było bazą danych. W naszym artykule o wspomniano, że tę funkcję wykona opisane w nim świetne narzędzie, chociaż formalnie korzysta z rzeczywistego interfejsu podobnego do SQL. Tak, EQL jest eleganckie, ale do tematu wrócimy w trzeciej części.
Sysmon i analiza grafów
Zastanówmy się na chwilę, co właśnie stworzyliśmy. W zasadzie mamy teraz bazę danych zdarzeń Windows dostępną przez PowerShell. Jak wcześniej zauważyłem, między wpisami istnieją połączenia lub relacje — przez ParentProcessId — dlatego możemy uzyskać pełną hierarchię procesów.
Jeśli czytałeś serię to wiesz, że hakerzy uwielbiają tworzyć złożone ataki wieloetapowe, w których każdy proces odgrywa swoją małą rolę i przygotowuje grunt pod następny krok. Tego rodzaju rzeczy są niezwykle trudne do wychwycenia tylko z „surowego” logu.
Jednak z moim poleceniem Get-Sysmonlogs i dodatkowymi strukturami danych, które omówimy później (oczywiście, jest to graf), będziemy mieć praktyczny sposób na wykrywanie zagrożeń – wystarczy wykonać odpowiednie wyszukiwanie w węzłach.
Jak zawsze w naszych projektach blogowych DYI, im więcej pracy wkładacie w analizę szczegółów zagrożeń w małej skali, tym lepiej rozumiecie, jak złożone jest wykrywanie zagrożeń na poziomie organizacyjnym. I ta świadomość jest niezwykle ważnym aspektem.
Natrafimy na pierwsze interesujące trudności w drugiej części artykułu, gdzie zaczniemy łączyć ze sobą wydarzenia Sysmon w znacznie bardziej złożone struktury.
Źródło: habr.com
