Threat Inteliigence / OSINT / NETSEC / NATSEC

Sigma (grindset?) rules – znajdujemy podejrzane zdarzenia z Sigma

W poprzednim poście przyglądaliśmy tworzeniu i funkcjonalności reguł YARA, które są nieocenioną pomocą dla analityków w wykrywaniu i klasyfikacji plików. Niektórzy mogliby jednak powiedzieć, że dzisiaj to za mało. W końcu coraz popularniejsze są ataki typu living off the land, gdzie atakujący nie korzystają z dodatkowego oprogramowania, a wystarczają im narzędzia już obecne w systemie. Jak więc tworzyć detekcje i katalogować wskaźniki aktywności jeżeli chcemy skupić się na zachowaniach, a nie plikach? Tutaj właśnie z pomocą przyjdą nam reguły Sigma, które niejako są dla logów zdarzeń systemowych czym reguły YARA dla plików. Z ich pomocą będziemy mogli opisywać zdarzenia, dzielić się detekcjami i wprowadzać nasze pomysły na wykrywanie złośliwej aktywności w życie przez przekładania reguł Sigma na składnię systemów takich jak Splunk czy Elastic.

Reguły korzystają z formatu YAML i ich struktura będzie bardziej złożona niż ta wykorzystywana w YARA, nie tracąc czasu przyjrzymy się jak działa Sigma. Szkielet reguły zgodnie z oficjalną specyfikacją wygląda następująco:

Jak widzimy jest tego całkiem sporo, co wynika z mnogości potencjalnych źródeł logów, a więc konieczności uwzględnienia pól które umożliwią szczegółowe określenie czego i gdzie szukamy. Zapoznajmy się teraz po kolei z poszczególnymi dostępnymi funkcjami i tym jak możemy je wykorzystać.

Pierwsza część służy określeniu nazwy reguły i dodaniu informacji pomagającymi zrozumieć kontekst i działanie detekcji. Jest to sekcja analogiczna to części „meta” z reguł YARA. Oprócz nazwy pola nie są obowiązkowe jednak zdecydowanie warto je dodać aby ułatwić korzystanie z naszego dzieła. Przybliżając po krótce pola w tej części:

  1. Title – obowiązkowa nazwa naszej reguły.
  2. id – możemy tutaj umieścić unikalny identyfikator UUID który pozwoli na jednoznaczną identyfikację detekcji.
  3. related – w tej podsekcji możemy wskazać odwołania do innych reguł np.: poprzednich wersji obecnej reguły.
  4. status – umieszczamy tutaj informacje odnośnie statusu, jak np.: czy reguła jest w fazie testów czy już gotowa do produkcji.
  5. description – opis funkcjonalności i zastosowania naszego dzieła.
  6. autor – informacja o autorze i danych kontaktowych.
  7. references – i w końcu możemy umieścić źródła z których korzystaliśmy tworząc regułę.

Kolejna sekcja będzie już stanowić ścisły trzon detekcji. W logsource określimy typ logów do jakiego powinna zostać zastosowana nasza reguła. Mamy tutaj do dyspozycji trzy główne pola:

  1. category – typ urządzenia z którego logów korzystamy jak firewall czy antywirus.
  2. product – jak wskazuje nazwa, określamy tutaj już konkretny product taki jak Windows lub Apache.
  3. service – i w końcu możemy oznaczyć kategorie logów z danego produktu, np.: w przypadku systemu Windows możemy zawęzić logi do zdarzeń z dziennika Security.

Dodatkowo aby zawęzić źródła danych możemy użyć pola Definition. Nie jest ono automatycznie przekształcane na instrukcje dla np.: Splunka, jednak może ułatwić analitykom odpowiednią konfigurację źródeł danych.

Dalej umieszczamy sekcje Detection w której określimy to co chcemy odnaleźć w logach i kiedy nasza reguła powinna wywołać alert. Tutaj kluczową rolę odgrywać będą dwie zmienne:

  1. selection – w której umieścimy definicje tego co chcemy znaleźć jak np.: nazwy i ścieżki plików, komendy w terminalu.
  2. condition – podobnie jak w YARA, warunki do spełnienia żeby reguła zareagowała, np.: jeden z dwóch warunków określonych polami selection.

Selection to właśnie część w której mamy największe pole do popisu i to tutaj będziemy definiować zmienne, identyfikatory wydarzeń i inne wartości które mogą pomóc w wykrywaniu złośliwej aktywności. Oprócz zwykłego „tekstowego” wyszukiwania możemy korzystać z list i słowników, jak i modyfikatorów wyszukiwania treści. Spójrzmy na przykłady z samej dokumentacji Sigmy:

Tutaj widzimy najprostszy przykład, kiedy wskazujemy ciągi tekstowe do wykrycia, w takim formacie jest między nimi operator OR, a więc wystarczy wykrycie jedno do wywołania detekcji.

Teraz z kolei korzystamy ze słownika, aby wywołać detekcję musi wystąpić log Security z identyfikatorem zdarzania 517 albo 1102.

W przypadku nazw plików czy konkretnych zdarzeń, taka składnia może być dla nas wystarczająca. Jeżeli jednak chcemy wyszukiwać poleceń w terminalu bądź plików w konkretnych ścieżkach bardzo będą przydatne modyfikatory, które uwzględnia Sigma. Dodajemy je po symbolu „|” i tym samym zmieniamy zakres wyszukiwania. Przykładowo, jeżeli chcemy wyszukiwać ciąg znaków który występuje gdziekolwiek w poleceniu wykonanym w terminalu skorzystamy z modyfikatora „contains”, który otacza podane przez nas dane symbolami „*” czyli po i przed może wystąpić dowolny ciąg znaków. W praktyce wygląda to tak:

Wybraliśmy więc tutaj kategorię logów – tworzenie procesów, jak i produkt – system Windows. Nasz ciąg danych do wyszukania to tutaj „oursecretstring”, którego reguła będzie szukać w linii poleceń – zgodnie z modyfikatorem nie ważne gdzie wystąpi. W końcu jako warunek wskazaliśmy po prostu selection czyli tutaj wystąpienie w konkretnym logu naszego wskazanego tekstu. Jeżeli chodzi o inne modyfikatory to warto też wskazać:

  • all – zmienia warunek w listach z OR na AND, co oznacza, że muszą być znalezione wyszystkie podane wartości.
  • startwith / endswith – podobne do contains określenie miejsca występowania wskazanych danych. Możemy więc ignorować to jest po (startwith) lub przed (endswith) wskazaną wartością.
  • base64 – kodowanie wartości w base64.

Pole condition działa w Sigma podobnie jak miało to miejsce w regułach YARA. Możemy więc zarówno wskazywać kryteria wprost, jak np.: „selection_1 AND selection_2” jak i korzystać z wyrażeń „all of them”, „2 of them”, „any of selection_*” i podobnych.

Na koniec spójrzmy jeszcze na dwa nieobowiązkowe lecz warte uwagi pola.

W „falsepositives” możemy wskazać użytkownikom naszych reguł na co zwracać uwagę aby odsiewać podobną lecz nieszkodliwą aktywność. Szczególnie w przypadku prób wykrycia stosowania technik living off the land, pomoc w odróżnianiu działań administracyjnych od złośliwej aktywności.

W końcu „level” pozwala nam określić priorytet alertu wynikającego ze znalezienia określonych w regule indykatorów. Sigma zakłada tutaj pięć poziomów:

  • informational – dla reguł stosowanych raczej do oznaczania zdarzeń niż wyszukiwania zagrożeń.
  • low – zdarzenia mogące świadczyć o złośliwej aktywności w określonym kontekście jak duża liczba takich zdarzeń.
  • medium – znaczące wydarzenia, które powinny być regularnie sprawdzane przez analityków.
  • high – zdarzenia świadczące o złośliwej aktywności, które powinny wywołać alert i zostać niezwłocznie sprawdzone.
  • critical – szczególnie niebezpieczne zachowania, które powinny wywołać natychmiastową reakcję.

Łącząc falsepositives i level możemy zdecydowanie ułatwić pracę analityków. Nawet najlepsza detekcja jest bowiem trudna do zastosowania jeżeli musimy regularnie konfrontować się fałszywie pozytywnymi alertami i trudno ocenić jest znaczenie znaleziska. Tworząc detekcję myślmy nie tylko o technicznych szczegółach, ale też implementacji reguł w warunkach pracy zespołu SOC i reagowania na incydenty.

Zbierzmy więc wszystkie te informacje i spróbujmy stworzyć już konkretną regułę, która będzie wykrywała tworzenie procesów o nazwach wykorzystywanych przez interesujące nas grupy aktywności wraz z hasłem podawanym jako argument (o których wiemy od niezastąpionego zespołu threat intelligence 🙂 ).

Jeżeli chcemy teraz przekształcić naszą regułę Sigma do formatu zapytania w systemie obsługi logów z którego korzystamy jak np.: Splunk możemy skorzystać z narzędzia sigmac bądź konwertera online. Spójrzmy na rezultat skorzystania z tego ostatniego:

W ten oto sposób poznaliśmy podstawy tworzenia reguł Sigma i możemy ruszać na poszukiwania interesujących nas zdarzeń w logach które mamy do dyspozycji.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

pl_PLPolish