Teraz, gdy zaobserwowaliśmy polowanie na zagrożenia w oparciu o dane, przyjrzyjmy się polowaniu na zagrożenia w oparciu o hipotezy.
Emulacja atakującego AtomicRedTeam
Skupmy się na skryptach AtomicRedTeam emulujących ataki MITRE ATT&CK T1003.002 (SAM). Korzystając z tej samej konfiguracji laboratoryjnej, co w rozdziale 8, wpisz „cd” do folderu c\Tools\AtomicRedTeam\atomics\T1003.002 na hoście z systemem Windows 10.
UWAGA Jeśli nie widzisz folderu c:\Tools, prawdopodobnie wystąpił problem podczas instalacji; w takim przypadku przejdź do systemu hosta i w oknie PowerShell administratora uruchom vagrant require win10. To samo dotyczy serwerów DC i WEF. Co więcej, jeśli laboratorium opisane w tym rozdziale zawiesza się, może być konieczne ponowne uruchomienie poprzez vagrant halt system name, a następnie vagrant up system name. Jeśli zdarza się to często, rozważ dodanie większej ilości pamięci RAM lub uruchomienie z chmury (z większą ilością pamięci RAM). Laboratoria działały zgodnie z oczekiwaniami na hostach z systemem Windows 10, ale przebieg może się różnić w przypadku innych systemów operacyjnych. W przeglądarce internetowej otwórz także następujący adres URL:
https://github.com/redcanaryco/atomic-redteam/blob/master/atomics/T1003.002/T1003.002.md
Przewiń w dół, aby zobaczyć, jak narzędzie AtomicRedTeam będzie emulować atak, lub możesz wpisać te polecenia ręcznie. Czy wyglądają znajomo? Powinny, ponieważ są to te same polecenia, które widzieliśmy na stronie frameworka MITRE ATT&CK.
Teraz w wierszu poleceń administratora (na hoście z systemem Windows 10) wpisz polecenia pokazane na poprzedniej ilustracji, aby ręcznie zasymulować osobę atakującą.
Teraz otwórz pulpit Kibana (z poprzedniego rozdziału). Następnie dodajmy kolumnę do naszej listy wyników Kibana, znajdując #event_id w polu wyszukiwania w panelu po lewej stronie i klikając przycisk Dodaj.
Odtąd na górze listy wyników wyszukiwania będziesz mieć event_id jako nagłówek. Odśwież stronę, aby ją zobaczyć.
Następnie wyszukaj polecenie „reg save HKLM\sam”. Pamiętaj, że aby uniknąć ukośnika odwrotnego, musisz użyć cudzysłowów. Upewnij się, że kliknąłeś kalendarz, a następnie wybrałeś Dzisiaj:
Powinieneś zobaczyć następujące wyniki wyszukiwania:
W wynikach wyszukiwania widzimy identyfikator zdarzenia jako 4688 (pomiń przecinek). Przypomnijmy sobie z pokazanego wcześniej diagramu OSSEM, że jest to jeden z oczekiwanych identyfikatorów zdarzeń dla wykonania polecenia. To kluczowa lekcja: tym razem znaleźliśmy „event_id”, szukając bardzo specyficznej techniki atakującego. Idąc dalej, będziemy pracować w innym kierunku. Rozwijając ten dziennik i przewijając nieco wyniki dziennika, widzimy rzeczywistą linię poleceń wpisaną przez osobę atakującą, zgodnie z oczekiwaniami:
Oczywiście jest to podstawowy przykład w czystym środowisku testowym, ale nie martw się. Następnie będziemy to zwiększać.
Wizualizacja źródeł danych za pomocą OSSEM
Zacznij od odwiedzenia :
https://ossemproject.com/dm/mitre_attack/attack_techniques_to_events.html.
Następnie najedź kursorem na ikonę statku rakietowego (wystrzelenia) w prawym górnym rogu strony i kliknij Binder, aby bezpłatnie uruchomić notatnik Jupyter na stronie Binder.
Ten notatnik Jupyter umożliwia interaktywne przetwarzanie języka Python i wszystkich powiązanych bibliotek na żywo, wygodnie i bezpiecznie w przeglądarce. Załadowanie zajmie chwilę (w końcu jest bezpłatne dzięki hojnym darowiznom osób wymienionych na górze strony witryny). Po załadowaniu zobaczysz następujący ekran. Kliknij szary blok kodu, a następnie kliknij przycisk Uruchom u góry lub naciśnij SHIFT-ENTER, aby przetworzyć ten blok kodu.
Ten notatnik Jupyter umożliwia interaktywne przetwarzanie języka Python i wszystkich powiązanych bibliotek na żywo, wygodnie i bezpiecznie w przeglądarce. Załadowanie zajmie chwilę (w końcu jest bezpłatne dzięki hojnym darowiznom osób wymienionych na górze strony witryny). Po załadowaniu zobaczysz następujący ekran. Kliknij szary blok kodu, a następnie kliknij przycisk Uruchom u góry lub naciśnij SHIFT-ENTER, aby przetworzyć ten blok kodu.
Po krótkim oczekiwaniu możesz kontynuować wykonywanie kolejnych bloków kodu (każdy wyjaśniony nagłówkiem i tekstem poprzedzającym blok), który wykorzystuje OSSEM do pokazania źródeł danych i komponentów podtechniki T1003.002. Dostosuj kod, aby przetestować T1003.002, jak pokazano poniżej. Na tym polega piękno notatników Jupyter: są dynamiczne i można z nimi eksperymentować, aby się uczyć.
Tutaj widzimy, że źródła danych poleceń, rejestru i plików są przydatne odpowiednio do wykrywania wykonania poleceń, dostępu do klucza rejestru systemu Windows i dostępu do plików. Teraz zmodyfikuj następny blok kodu, aby ponownie reprezentował podtechnikę T1003.002.
Teraz widzimy identyfikatory zdarzeń użyte do znalezienia aktywności powiązanej z podtechniką T1003.002. Jest to przydatne, ponieważ możesz teraz rozpocząć polowanie z tymi danymi, nie martwiąc się o inne identyfikatory zdarzeń. Istnieją trzy ścieżki wyszukiwania tego działania: pliki, rejestr systemu Windows i dzienniki wiersza poleceń. Wykonaj następne polecenie i przewiń w prawo okna danych, aby zobaczyć szczegóły danych graficznych. Będziesz musiał zmodyfikować kod w bloku, jak pokazano poniżej, dla T1003.002:
Po prawej stronie tej listy znajdują się kanały dziennika i powiązani z nimi dostawcy dzienników (źródła). Widzimy więc na przykład, że szukając trasy wykonania polecenia tego ataku, możemy wyszukać identyfikatory zdarzeń 4688 i 4103, odpowiednio dla wykonania wiersza poleceń i wykonania programu PowerShell. Te identyfikatory zdarzeń są uruchamiane, gdy użytkownik lub proces wykonuje polecenie, więc jesteśmy zabezpieczeni, gdy osoba atakująca pisze w wierszu poleceń lub wykonuje skrypty uruchamiające procesy w celu wykonania poleceń – co jest dobre. Zauważamy również, że dzienniki Sysmon zawierają identyfikator zdarzenia równy 1 dla tego działania. Okazuje się, że identyfikator zdarzenia 1 jest powiązany z całym tworzeniem procesów i jest w tym przypadku mniej szczegółowy, dlatego pozostaniemy przy dwóch pozostałych identyfikatorach zdarzeń. Przewijając nieco w dół, widzimy podobne dane dla technik, które uzyskują bezpośredni dostęp do SAM z rejestru:
Jeszcze niżej widzimy dane z technik związanych z bezpośrednim dostępem do pliku obiektu SAM:
Teraz nauczmy się innej techniki emulacji zachowania atakującego, aby poćwiczyć odnajdywanie go w dziennikach. Emulacja zagrożeń cybernetycznych (CTE) zwiększa siłę i naprawdę przyspiesza naukę.
Odświeżacz ramowy MITER ATT&CK: T1003.002
Przypomnisz sobie framework MITRE ATT&CK. Tutaj zastosujemy go do polowania na zachowania wrogie. Na początek przyjrzymy się podtechnice T1003.002, Zrzucanie poświadczeń systemu operacyjnego. Ta podtechnika opisuje, w jaki sposób przeciwnik może wyodrębnić informacje poświadczeń z Menedżera konta zabezpieczeń systemu Windows (SAM), albo z pamięci, albo z Rejestr systemu Windows, w którym jest przechowywany. SAM jest dużym celem dla atakujących z oczywistych powodów: zawiera lokalne dane uwierzytelniające hosta. Jak wyjaśniono w ramach, do pobrania SAM można użyć wielu zautomatyzowanych narzędzi lub wystarczy proste polecenie z okna wiersza poleceń administratora:
reg save HKLM\sam sam
reg save HKLM\system system
Przyjrzyjmy się, co OSSEM mówi nam o tej podtechnice.
Polowania oparte na danych za pomocą OSSEM
Najpierw użyjemy OSSEM do przeprowadzenia wyszukiwania opartego na danych. Zaczniemy od odświeżenia frameworka MITRE ATT&CK, wizualizacji danych za pomocą OSSEM, a następnie zagłębimy się w szczegóły i zabrudzimy sobie ręce w poszukiwaniu.
OSSEM na ratunek
Z pomocą przychodzi projekt Open Source Security Event Metadata (OSSEM). Bracia Roberto i Jose Rodriguez stworzyli projekt OSSEM, aby pomóc naukowcom w udostępnianiu danych i analiz w standardowym formacie, dzięki czemu dziedzina mogła rozwijać się szybciej, bez straty czasu na tłumaczenie formatów dzienników istotnych dla bezpieczeństwa. Jak kilkakrotnie wspominaliśmy w tym rozdziale, jesteśmy winni braciom Rodriguez dług wdzięczności za wszystko, czego udzielili nam na tym polu. Projekt OSSEM jest podzielony na trzy części:
- Common Data Model (CDM) Zapewnia wspólny schemat danych, wykorzystując encje schematu i tabele schematu, aby umożliwić abstrakcję logów (na przykład podczas omawiania dzienników sieciowych zdefiniowano encje HTTP, Port i User-Agent ).
- Słowniki danych (DD) Kolekcje jednostek CDM i tabel, które definiują konkretny dziennik zdarzeń. Zdefiniowano wiele popularnych formatów dzienników, a Ty możesz dowolnie definiować własne.
- Model danych wykrywania (DDM) Zbiór obiektów danych i relacji wymaganych do zdefiniowania zachowania atakującego, np. mapowania struktury MITRE ATT&CK na dzienniki. Włożono tutaj wiele pracy, aby ukończyć znaczną część ram (pamiętaj, że Twój udział i wkład są mile widziane).
Razem komponenty OSSEM umożliwiają nasze oparte na danych i polowanie na zagrożenia w oparciu o hipotezy. Jak zobaczysz za chwilę, możemy polegać na tym narzędziu, aby przyspieszyć naszą analizę i nie grzęznąć w formatach dzienników, nazwach pól i tak dalej. Korzystanie z OSSEM to prawdziwa oszczędność czasu.
Źródła danych
Problem z danymi polega na tym, że każde urządzenie, system operacyjny i aplikacja (źródło) generuje logi w innym formacie. Co gorsza, niektórzy dostawcy, tacy jak Microsoft, oferują kilka form rejestrowania; dlatego też, w zależności od tego, czego szukasz, dane mogą równie dobrze mieć format inny niż pozostałe dzienniki tego dostawcy. Na przykład firma Microsoft przechowuje dzienniki w Podglądzie zdarzeń (EVT), udostępnia dostęp na poziomie interfejsu API do dzienników na poziomie jądra za pośrednictwem śledzenia zdarzeń dla systemu Windows (ETW) i może przekazywać dzienniki za pośrednictwem serwerów przekazywania zdarzeń systemu Windows (WEF). Ponadto firma Microsoft udostępnia narzędzie Sysmon, które w prosty sposób udostępnia dzienniki procesów, plików i działań sieciowych na poziomie systemu. Każda z tych metod rejestrowania, żeby wymienić tylko kilka, zapewnia inny format. Jak więc znormalizować te źródła dzienników i setki innych źródeł w formacie umożliwiającym przeszukiwanie i skalowalny?
Normalizowanie źródeł danych za pomocą OSSEM
Zaczniemy od omówienia źródeł danych, potrzeby normalizacji logów z różnych źródeł danych oraz projektu Open Source Security Event Metadata (OSSEM) i narzędzi wspomagających ten proces. Jak wspomniano wcześniej, pierwszym krokiem w poszukiwaniu zagrożeń jest zrozumienie źródeł danych, a następnie wykonanie analizy luk i projektu zaradczego w przypadku brakujących danych. Prawdopodobnie w miarę postępów odkryjesz, że brakuje Ci kluczowych danych i będziesz mógł dalej je dostosowywać.
Przebieg pracy podczas poszukiwania zagrożeń
Podstawowy przebieg wyszukiwania zagrożeń jest następujący:
- Wykonaj inwentaryzację źródeł danych, ocenę luk i podjęcie działań naprawczych.
- Określ rodzaj polowania i kryteria wyszukiwania.
- Upewnij się, że posiadasz dane wymagane do spełnienia kryteriów wyszukiwania.
- Przeprowadź wyszukiwanie.
WSKAZÓWKA Zanim zaczniesz bardziej ogólnie polegać na wynikach wyszukiwania, naśladuj zagrożenie i upewnij się, że wyszukiwanie i dane są zgodne z oczekiwaniami.
- Sprawdź wyniki. Jeśli zostanie wykryte zachowanie atakującego, kontynuuj dochodzenie i powiadom zespół reagowania na incydenty (IR).
- Jeśli nie zostanie znalezione zachowanie atakującego, wróć na górę. Następnie spłucz i powtórz.
Otóż to. Jasne, podczas tego procesu będziesz musiał się wiele nauczyć o tym, jak działają systemy operacyjne w Twoim środowisku, w jaki sposób generowane są, przesyłane i przechowywane dane dziennika oraz w jaki sposób przeciwnik porusza się po sieci, szczególnie gdy wygląda jak zwykły użytkownik , ale to wszystko jest częścią tego. Minie trochę czasu, a może nawet lat, zanim staniesz się biegły w polowaniu na zagrożenia. Zacznijmy więc teraz!
UWAGA: Ważne jest, aby zdać sobie sprawę, że bycie łowcą zagrożeń to podróż, która zajmie lata, zanim będziesz mógł uważać się za eksperta. Postaramy się pokazać Ci podstawy i wyposażyć Cię w narzędzia, dzięki którym z czasem udoskonalisz swoje rzemiosło. Nic jednak nie zastąpi poświęcenia 10 000 godzin, co dotyczy również tematów poruszanych w pozostałej części . Zatem ta część nie ma być wyczerpującym źródłem ani wyjaśnieniem polowania na zagrożenia. Do tego potrzeba by całej książki. Mamy nadzieję, że znajdziesz kilka nowych wskazówek dla tych, którzy mają doświadczenie w polowaniu na zagrożenia, ale tak naprawdę jest on skierowany do osób, które nie mają doświadczenia w tym temacie.
Polowania oparte na hipotezach
Jak pamiętasz, na szczycie piramidy bólu znajduje się TTP przeciwnika. Zachowanie przeciwnika jest najtrudniejszą rzeczą do odkrycia. Dobra wiadomość jest taka, że przeciwnicy często powtarzają to, co działa, i to właśnie powtarzanie daje nam wskazówkę, czego szukać w przypadku danej grupy przeciwników. Struktura MITRE ATT&CK to zbiór wielu znanych (publicznych) TTP i została nawet wykorzystana do wskazania działań niektórych grup zaawansowanych trwałych zagrożeń (APT). Wykorzystując ten framework jako źródło, możemy użyć naszej wyobraźni i zbudować hipotezę dotyczącą działań przeciwnika w sieci. Następnie można przetestować wszelkie hipotezy; najpierw upewniając się, że mamy odpowiednie źródła danych, aby zobaczyć docelowe zachowanie, a następnie budując analitykę w celu wyszukania tego zachowania w danym środowisku sieciowym. Wreszcie możemy zbudować alerty, które poinformują nas, kiedy takie zachowanie wystąpi w przyszłości. W ten sposób możemy metodycznie poruszać się po frameworku MITRE ATT&CK, budując mapę zasięgu w miarę upływu czasu. Jedną z kluczowych koncepcji w tym momencie jest uznanie, że często będziemy zaczynać od środka frameworku, ponieważ na początku zakładamy kompromis. Następnie, jeśli odkryjemy oznaki prawdziwości hipotezy, możemy pracować w obu kierunkach w całym modelu: (1) iść do przodu i znaleźć ostateczną głębokość penetracji i ryzyka dla środowiska oraz (2) cofnąć się do znaleźć źródło naruszenia i zamknąć tę dziurę w przyszłości.