Niniejszy artykuł stanowi pierwszą część serii poświęconej analizie zagrożeń Sysmon. Wszystkie pozostałe części serii:
Część 1. Wprowadzenie do analizy dziennika Sysmon (jesteśmy tutaj)
Część 2. Wykorzystanie danych zdarzeń Sysmon do identyfikacji zagrożeń
Część 3: Głębsza analiza zagrożeń Sysmon przy użyciu grafów
Jeśli pracujesz w branży bezpieczeństwa informacji, prawdopodobnie często musisz stawiać czoła ciągłym atakom. Jeśli masz bystre oko, możesz poszukać nietypowej aktywności w surowych logach, np. skryptu programu PowerShell uruchomionego lub skrypt VBS zamaskowany jako plik Word – wystarczy przewinąć ostatnią aktywność w dzienniku zdarzeń WindowsAle to prawdziwy ból głowy. Na szczęście Microsoft stworzył Sysmon, który znacznie ułatwia analizę ataków.
Chcesz zrozumieć podstawowe założenia zagrożeń wyświetlanych w dzienniku Sysmon? Pobierz nasz przewodnik I zdajesz sobie sprawę, jak osoby z wewnątrz mogą potajemnie monitorować innych pracowników. Główny problem z pracą z dziennikiem zdarzeń Windows Problemem jest brak informacji o procesach nadrzędnych, co uniemożliwia zrozumienie ich hierarchii. Z kolei wpisy w dzienniku Sysmon zawierają identyfikator procesu nadrzędnego, jego nazwę oraz uruchamiany wiersz poleceń. Dziękujemy, Microsoft.
W pierwszej części naszego cyklu przyjrzymy się temu, co można zrobić, korzystając z podstawowych informacji Sysmon. W części 2 w pełni wykorzystamy informacje o procesach nadrzędnych, aby utworzyć bardziej złożone struktury zgodności znane jako grafy zagrożeń. W części 3 przyjrzymy się prostemu algorytmowi, który skanuje wykres zagrożeń w celu wykrycia nietypowej aktywności poprzez analizę „wagi” wykresu. A na koniec, jako nagrodę, otrzymasz schludną (i zrozumiałą) probabilistyczną metodę wykrywania zagrożeń.
Część 1: Wprowadzenie do analizy dziennika 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ę aż tak daleko, przynajmniej na początku. Na początek, aby zrozumieć zasady działania SIEM, wystarczy wypróbować wspaniałe, darmowe narzędzie Sysmon. I zaskakująco łatwo się z nią współpracuje. Dobra robota, Microsoft!
Jakie są możliwości Sysmona?
Krótko mówiąc, dostarcza użytecznych i czytelnych informacji o procesach (zobacz ilustracje poniżej). Znajdziesz tam mnóstwo przydatnych szczegółów, których nie znajdziesz w dzienniku zdarzeń. Windows, ale najważniejsze są następujące pola:
- Identyfikator procesu (w systemie dziesiętnym, nie szesnastkowym!)
- Identyfikator procesu nadrzędnego
- Wiersz poleceń procesu
- Wiersz poleceń procesu nadrzędnego
- Skrót obrazu pliku
- Nazwy plików obrazów
Sysmon jest instalowany zarówno jako sterownik urządzenia, jak i usługa – więcej szczegółów Jego główną zaletą jest możliwość analizowania logów z kilka źródła, korelację informacji i wyprowadzanie wartości wynikowych do jednego folderu dziennika zdarzeń zlokalizowanego wzdłuż ścieżki Microsoft -> Windows -> Sysmon -> OperacyjnyW moich własnych badaniach dziennika WindowsTakie przerażające błędy sprawiały, że musiałem nieustannie przełączać się między, powiedzmy, folderem dzienników programu PowerShell a folderem zabezpieczeń, przeglądając dzienniki zdarzeń w heroicznej próbie skorelowania wartości między nimi. To nigdy nie jest łatwe zadanie i, jak później zrozumiałem, lepiej byłoby od razu zaopatrzyć się w aspirynę.
Sysmon wykonuje ogromny krok naprzód, udostępniając użyteczne (lub jak lubią mówić dostawcy, wykonalne) informacje pomagające zrozumieć podstawowe procesy. Na przykład uruchomiłem ukrytą sesję , symulując ruch inteligentnego insidera w sieci. To właśnie zobaczysz w dzienniku zdarzeń. Windows:
w dzienniku Windows Niektóre informacje o procesach są widoczne, ale nie są zbyt przydatne. A identyfikatory procesów w formacie szesnastkowym?
Profesjonalny specjalista IT, który zna się na podstawach hakowania, powinien podchodzić z podejrzliwością do wiersza poleceń. Użycie cmd.exe do uruchomienia innego polecenia i przekierowania danych wyjściowych do pliku o dziwnej nazwie jest ewidentnie działaniem oprogramowania do kontroli i zarządzania :Oto w jaki sposób tworzy się pseudo-powłokę za pomocą usług WMI.
Przyjrzyjmy się teraz odpowiadającemu wpisowi w Sysmon i zwróćmy uwagę, ile dodatkowych informacji nam on dostarcza:
Możliwości Sysmon na jednym zrzucie ekranu: szczegółowe informacje o procesie w czytelnej formie
Widzisz nie tylko wiersz poleceń, ale także nazwę pliku i ścieżkę do wykonywalnej aplikacji, która Windows wie o tym (“Windows „Procesor poleceń”, identyfikator rodzicielski proces, wiersz poleceń rodzic, który uruchomił powłokę cmd, a także prawdziwą nazwę pliku procesu nadrzędnego. Wszystko w jednym miejscu, wreszcie!
Na podstawie logu Sysmon możemy wywnioskować, że z dużym prawdopodobieństwem podejrzany wiersz poleceń, który widzieliśmy w surowych logach, nie jest wynikiem normalnej pracy pracownika. Zamiast tego został on wygenerowany przez proces podobny do C2 - wmiexec, o czym wspomniałem wcześniej - i został bezpośrednio uruchomiony przez proces usługi WMI (WmiPrvSe). Teraz mamy sygnał, że zdalny atakujący lub osoba z wewnątrz testuje infrastrukturę korporacyjną.
Przedstawiamy Get-Sysmonlogs
Oczywiście, że świetnie, gdy Sysmon przechowuje logi w jednym miejscu. Ale prawdopodobnie byłoby jeszcze lepiej, gdybyśmy mogli uzyskać dostęp do poszczególnych pól dziennika programowo – na przykład za pomocą poleceń programu PowerShell. W takim przypadku można by napisać krótki skrypt PowerShell, który zautomatyzowałby wyszukiwanie potencjalnych zagrożeń!
Nie jestem pierwszy, który wpadł na ten pomysł. I dobrze, że w niektórych postach na forum i GitHub Wyjaśniono już, jak używać programu PowerShell do analizowania dziennika Sysmon. W moim przypadku chciałem uniknąć konieczności pisania oddzielnych wierszy skryptu parsującego dla każdego pola Sysmon. Więc zastosowałem zasadę leniwej osoby i myślę, że udało mi się wymyślić coś interesującego.
Pierwszą ważną kwestią jest umiejętność zespołu odczytaj logi Sysmon, przefiltruj wymagane zdarzenia i wyprowadź 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 przetestować polecenie samodzielnie, wyświetlając zawartość pierwszego elementu tablicy $events, $events[0].Message, możesz uzyskać serię wierszy tekstu o bardzo prostym formacie: nazwa pola Sysmon, dwukropek, a następnie sama wartość.
Hurra! Wyjście dziennika Sysmon w gotowym do użycia formacie JSON
Czy myślisz o tym samym co ja? Przy odrobinie wysiłku możesz przekonwertować dane wyjściowe na ciąg w formacie JSON, a następnie załadować je bezpośrednio do obiektu PS, korzystając z potężnego polecenia .
W następnej części pokażę kod PowerShell umożliwiający konwersję – jest on bardzo prosty. Tymczasem zobaczmy, co potrafi moje nowe polecenie o nazwie get-sysmonlogs, które zainstalowałem jako moduł PS.
Zamiast przeszukiwać dzienniki Sysmon za pomocą niezgrabnego interfejsu dziennika zdarzeń, możemy bez wysiłku wyszukiwać przyrostowe aktywności bezpośrednio z sesji programu PowerShell, a także używać polecenia PS (alias - "?") w celu skrócenia wyników wyszukiwania:
Lista powłok cmd uruchomionych za pośrednictwem WMI. Analiza zagrożeń tanio dzięki naszemu własnemu zespołowi Get-Sysmonlogs
Cudowny! Stworzyłem narzędzie umożliwiające przeszukiwanie dziennika Sysmon tak, jakby był bazą danych. W naszym artykule o Zauważono, że funkcja ta będzie realizowana przez opisywane w nim fajne narzędzie, choć formalnie wciąż poprzez prawdziwy interfejs podobny do SQL. Tak, EQL wdzięczny, ale o tym porozmawiamy w części trzeciej.
Analiza Sysmon i wykresów
Cofnijmy się o krok i pomyślmy o tym, co właśnie stworzyliśmy. W zasadzie mamy teraz bazę danych zdarzeń. Windows, dostępne za pośrednictwem programu PowerShell. Jak zauważyłem wcześniej, istnieją powiązania lub relacje między rekordami – za pośrednictwem ParentProcessId – dzięki czemu można pobrać pełną hierarchię procesów.
Jeśli przeczytałeś serię to wiesz, że hakerzy lubią tworzyć złożone, wieloetapowe ataki, w których każdy proces odgrywa swoją małą rolę i przygotowuje trampolinę do następnego kroku. Wyłapanie takich rzeczy po prostu z „surowego” dziennika jest niezwykle trudne.
Jednak dzięki poleceniu Get-Sysmonlogs oraz dodatkowej strukturze danych, którą omówimy później (oczywiście graf), zyskujemy praktyczny sposób wykrywania zagrożeń — wystarczy odpowiednie przeszukanie wierzchołków.
Jak zawsze w przypadku naszych projektów blogowych typu „zrób to sam”, im więcej pracujesz nad analizą szczegółów zagrożeń na małą skalę, tym bardziej zdajesz sobie sprawę, jak trudne jest wykrywanie zagrożeń na poziomie organizacyjnym. I ta świadomość jest niezwykle ważny punkt.
Na pierwsze ciekawe komplikacje natrafimy w drugiej części artykułu, gdzie zaczniemy łączyć zdarzenia Sysmon w o wiele bardziej złożone struktury.
Źródło: www.habr.com
