Hipoteza, że ktoś skopiował plik SAM

https://chacker.pl/

W tym laboratorium będziemy szukać (polować) w oparciu o hipotezę, że ktoś skopiował plik SAM w naszej domenie. Aby przyspieszyć cykl uczenia się, użyjemy funkcji automatycznego testowania narzędzi AtomicRedTeam, zwanej Invoke-AtomicTest, aby przeprowadzić test w spójny sposób i oszczędzić nam pisania związanego z atakami. W administracyjnym oknie programu PowerShell na hoście z systemem Windows 10 skonfiguruj środowisko za pomocą następującego polecenia (skopiuj/wklej z https://detectionlab.network/usage/atomicredteam/).

Następnie wywołaj test, używając pojedynczego testu, wielu testów lub pełnej sekwencji testowej dla T1003.002, jak pokazano w poniższym kodzie. Argument – ShowDetailsBrief pokaże akcje testowe, ale ich nie wykona, więc warto to zrobić w pierwszej kolejności.

Poniższy obraz przedstawia całą sekwencję testową dla ostatniego polecenia:

Świetnie! Teraz uruchom pierwsze polecenie (test 1), bez – ShowDetailsBrief, aby wykonać atak, jak pokazano poniżej:

Ponieważ już wiemy, że istnieją trzy sposoby kopiowania pliku SAM – polecenie, plik i rejestr -— możemy wykorzystać te informacje, aby rozpocząć polowanie. Przypominamy, że identyfikatory zdarzeń 4688 i 4103 są wskaźnikami wykonania polecenia. Ponieważ już sprawdziliśmy 4688, wyszukajmy tym razem 4103. Otwórz konsolę Kibana i wyszukaj „HKLM\sam” i event_id:4103, a powinieneś zobaczyć kilka trafień, jak pokazano poniżej:

Poświęć chwilę na zapoznanie się z wynikami dziennika; w szczególności spójrz na pole Ładunek. Rozwiń dziennik i przewiń w dół, aby zobaczyć szczegóły, jak pokazano tutaj:

Teraz wiesz, jak wygląda ładunek programu PowerShell w formacie dziennika. Jeśli spróbujesz tego w swojej sieci produkcyjnej, wyszukasz te same dzienniki, ale bez ograniczeń dat.

Emulacja atakującego AtomicRedTeam

https://chacker.pl/

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

https://chacker.pl/

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

https://chacker.pl/

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.

OSSEM na ratunek

https://chacker.pl/

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

https://chacker.pl/

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

https://chacker.pl/

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ń

https://chacker.pl/

Podstawowy przebieg wyszukiwania zagrożeń jest następujący:

  1. Wykonaj inwentaryzację źródeł danych, ocenę luk i podjęcie działań naprawczych.
  2. Określ rodzaj polowania i kryteria wyszukiwania.
  3. Upewnij się, że posiadasz dane wymagane do spełnienia kryteriów wyszukiwania.
  4. 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.

  1. Sprawdź wyniki. Jeśli zostanie wykryte zachowanie atakującego, kontynuuj dochodzenie i powiadom zespół reagowania na incydenty (IR).
  2. 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.