Threat Inteliigence / OSINT / NETSEC / NATSEC

Zbierając diamentowe łańcuchy – narzędzia analizy threat intelligence

Po podróżach dookoła globu przechodzimy do rozległego świata operacji w cyberprzestrzeni – a konkretnie tego jak się je analizuje i jak pomaga to w obronie. Jedną z inspiracji dla nazwy tego bloga – counterintelligence.pl – było to, że aktywność znana jako Cyber Threat Intelligence (CTI) to w mojej ocenie działalność dużo bardziej kontrwywiadowcza niż wywiadowcza. Analitycy skupiają się bowiem na rozkładaniu na czynniki pierwsze i badaniu śladów pozostawionych przez podmioty starające się uzyskać nieuprawniony dostęp do systemów (którzy czasem są wprost funkcjonariuszami agencji wywiadowczych) i stworzyć metody wykrywania i unieszkodliwiania takich działań. Kiedy więc spojrzymy na definicje kontrwywiadu zawartą w rozporządzeniu wykonawczym 1233 które reguluje działalność wywiadowczą w Stanach Zjednoczonych to znajdziemy tam:

„Counterintelligence means information gathered and activities conducted to protect against espionage, other intelligence activities, sabotage, or assassinations conducted for or on behalf of foreign powers, organizations or persons, or international terrorist activities, but not including personnel, physical, document or communications security programs.”

To pokrywa się ona z istotą pracy zespołów CTI które zbierają informacje o wrogiej aktywności i pomagają innym zespołom w skuteczniejszym przeciwdziałaniu jej. Cyber Threat Intelligence jednak już przyjęło w środowisku na tyle, że raczej nie mamy już szansy na przejście na dużo fajniejsze według mnie Cyber Counterintelligence.

Tyle jednak jeżeli chodzi o wstęp. Przechodząc do rzeczy chciałbym w tym poście przedstawić narzędzia z jakich korzysta się w analizie CTI i jak pomagają one w zrozumieniu wrogiej aktywności. Nie będą to jednak narzędzia softwareowe czy hardwareowe jak systemy do analizy malwareu, zapisu ruchu sieciowego czy informatyki śledczej, a struktury analityczne które pomagają w kategoryzowaniu poszczególnych elementów aktywności i składaniu ich w całość. Instrumentami tymi będą Cyber Kill-chain, Diamond model of intrusion analysis i Mitre ATT&CK. Przyjrzymy się więc pokrótce każdemu z nich, a następnie zobaczmy jak pomagają one obrońcom sieci w utrudnianiu życia napastnikom.

Pierwszy z nich, Cyber kill-chain to dzieło pracowników Lockheed Martin, którzy rozłożyli proces wrogiej aktywności na siedem następujących po sobie etapów:

  1. Rekonesans – napastnik zbiera informacje o ofierze. Może to przybrać formę listowania pracowników, mapowania infrastruktury sieciowej, analizy publicznie dostępnych materiałów celu określenia zasobów o największej wartości lub krytycznych dla działania organizacji.
  2. Uzbrojenie (weaponization) – przygotowanie narzędzi koniecznych do przeprowadzania włamania takich jak załączniki do maili phishingowych, implantów umożliwiających wykorzystanie podatności i ustanowienie dostępu do docelowego systemu.
  3. Dostarczenie – wykorzystanie sieciowych (maile, usługi dostępne z Internetu, komunikatory) lub fizycznych (pamięć USB) kanałów komunikacji do wprowadzenia przygotowanych narzędzi do środowiska ofiary.
  4. Wykorzystanie podatności (exploitation) – uzyskanie możliwości wykonywania poleceń w środowisku ofiary poprzez wykorzystanie wcześniej wykrytych podatności.
  5. Instalacja – zapewnienie ciągłości dostępu do środowiska poprzez instalacje implantów na maszynach ofiary np.: dodanie zaplanowanego zadania które uruchamia malware za każdym razem gdy komputer jest włączany.
  6. Komunikacja z infrastrukturą Command and Control – atakujący przekazują polecenia narzędziom które udało im się zainstalować i odbierać informacje zwrotne na temat aktywności w środowisku.
  7. Realizacja celów (Actions on Objective) – w końcu napastnik wypełnia cele które zakładał planując atak np.: kradnąc danę lub szyfrując zawartość dysków.

Założenia jakie stoją za takim ujęciem ataku jest to, że każdy poprzedzający etap jest niezbędny do wykonania następnego i że etapy następują po sobie. W ten sposób broniący sieci mają siedem etapów „do dyspozycji” – przerwanie działania napastników na choćby jednym z nich pozwala na uniknięcie lub ograniczenie (jeżeli mówimy o ostatnim etapie) skutków włamania.

Drugie z narzędzi to Diamond Model of Intrusion Analysis, opracowane przez Sergio Caltagirone, Andrew Pendergasta, and Christophera Betz. Według autorów sam pomysł zrodził się w 2006 roku, jednak stworzenie i dopracowanie modelu zajęło łącznie 7 lat. W końcu, w 2013 roku opublikowany został artykuł opisujący model. Zachęcam do jego lektury, jednak założenia modelu najprościej wytłumaczyć poprzez jego graficzną reprezentacje:

Podstawową „jednostką” modelu jest więc zdarzenie opisane czterema głównymi atrybutami:

  1. Napastnik – podmiot odpowiedzialny za wrogie działania.
  2. Infrastruktura – środki dostarczenia zdolności do ofiary takie jak serwery C2, pliki dołączone do maili phishingowych czy domeny watering hole.
  3. Zdolności – środki techniczne umożliwiające uzyskanie dostępu do zasobów ofiary – exploity, implanty, umiejętności takiej jak inżynieria społeczna.
  4. Ofiara – cel działań napastnika.

Autorzy opisują też dodatkowe atrybuty które mogą zostać wykorzystane do bardziej szczegółowego opisu elementu jak czas, wynik (czy napastnikowi udało się osiągnąć zamierzone cele) czy faza (np.: faza Cyber Kill-chain czy Mitre ATT&CK). I właśnie te dwa ostatnie atrybuty będą kluczem do łączenia modeli które tutaj opisujemy i wykorzystania ich do analizy aktywności. Warto również zwrócić uwagę na to jak osie modelu opisują charakterystykę zdarzenia na dwóch płaszczyznach. Pozioma oś techniczna pomiędzy infrastrukturą i możliwościami to typowy techniczny opis ataku w kontekście czynników takich jak działanie malware’u, protokoły komunikacji z serwerami C2, metody socjotechniczne wykorzystane do skłonienia ofiary do określonych działań czy sposoby uniknięcia wykrycia. Z mojej perspektywy niemniej ważna wydaje się jednak oś pozioma – socjo-polityczna – określająca relacje pomiędzy napastnikiem a ofiarą. Dyskusja o tym jak istotna (i czy potrzebna) jest atrybucja cyber operacji przypisująca aktywności do konkretnych napastników to temat na osobny post, jednak w moim odczuciu nie sposób jest pominąć motywacji atakujących i wiktymologii operacji. Zdarzenia takie nie dzieją się w próżni i dociekliwy analityk powinien zawsze mieć na uwadze to czemu operacja została przeprowadzona i dlaczego przeciwko konkretnej organizacji. Odkładając już te dywagacje i przechodząc do praktyki, osobiście najczęściej korzystam z DM w dwóch formatach. Po pierwsze, małych diamentów opisujących poszczególne zdarzenia w ramach incydentu które można przyporządkować następnie do kolejnych faz aktywności, jak na przykład:

Widzimy tutaj jak faza kill chain dostarczenia (delivery) została rozłożona na wierzchołki diamentu co ładnie prezentuje jak niejaki John Doe starał się wysłać maila phshingowego z rzekomą fakturą do działu księgowości naszej ofiary. Zwrot „starał się” jest tutaj również kluczowy gdyż jak wspomnieliśmy, opis zdarzenia może również uwzględniać to czy dane działanie osiągnęło zamierzony przez napastnika skutek.

Druga forma diamentu to duży diamenty opisujące ramowo całe grupy aktywności śledzone w ramach praktyki threat intelligence, przykładowo:

Przedstawiona tutaj została więc całość (oczywiście w ogólnym zarysie) aktywności danej grupy co pozwala analitykom na katalogowanie technik wykorzystywanych przez dane grupy i szukania powiązań pomiędzy poszczególnymi incydentami. Wraca tutaj poniekąd temat atrybucji i tego jak podchodzimy do przypisywania działań aktorom, można wskazać na dwie szkoły podejścia do tematu:

Użycie zwrotu „threat actor” najczęściej jest stosowane przez zespoły które starają przypisywać operacje konkretnym osobom siedzącym za klawiaturą – najlepszym przykładem są firmy takiej jak CrowdStrike czy Mandiant które często w swoich raportach wskazują na konkretne jednostki wojskowe czy agencje wywiadowcze odpowiedzialne za włamania.

Drugim podejściem jest „activity group” spopularyzowane przez Dragos. W tym modelu nie interesuje nas to kto konkretnie stoi za operacją, czy są to zorganizowane grupy czy pojedyncze osoby, przestępcy czy funkcjonariusze służb. Co jest istotne to czy elementy aktywności pokrywają się w toku kolejnych analizowanych przypadków.

Opierając się przedstawionym przykładzie, w podejściu „threat actor” nasza grupa Wicked Emu reprezentowałaby by konkretną grupę osób prowadzącą operacje które mogą być scharakteryzowane przez opis przedstawiony na wierzchołkach diamentu. Jeżeli natomiast decydujemy się na „activity group” to nie interesuje nas czy Wicked Emu to w istocie jedna osoba, kilka osób czy nawet kilka organizacji które nie wiedzą o sobie nawzajem. Tak długo jak łączy je sposób działania będziemy obserwować je jako jedną grupę. Nie będę tutaj oceniać które podejście jest lepsze, ale moim zdaniem dla większości zespołów – a szczególnie tych które zajmują się threat intelligence dla celów ochrony infrastruktury organizacji – bardziej metodologicznie poprawne będzie „activity group”. Opiera się bowiem na bezpośrednio obserwowanych elementach działalności grup, bez potrzeby przeprowadzania, często pracochłonnego i nie zawsze możliwego, procesu atrybucji. A propos stosowania Diamond Model w analizie incydentów odsyłam również do prezentacji którą miałem przyjemność przedstawić na konferencji SECURE 2019.

Ostatnim, i najnowszym, narzędziem jest Mitre ATT&CK czyli katalog Taktyk, Technik i Procedur (TTP) stosowanych przez atakujących. Założeniem jest zbudowanie wspólnego słownika pojęć co ułatwi obrońcom analizę aktywności i wprowadzanie zabezpieczeń adresujących Tutaj widzimy więc np.: taktykę (Reconnaissance), technikę (Active Scanning) i dwie procedury (Scanning IP Blocks i Vulnerability).

W tym miejscu należy jednak zaznaczyć, że autorzy ATT&CK zdecydowali się jednak na nieco inne spojrzenie na definicję TTP niż ta szeroko rozumiana w threat intelligence. Powszechnie taktyki to sposoby w jakie napastnicy osiągają swoje cele, techniki to uszczegółowione opisy metod, a procedury to konkretne implementacje. W ATT&CK natomiast taktyki to same w sobie cele (jak tutaj rekonesans), a dopiero pod-techniki (sub-techniques) w Mitre to to czym nazwalibyśmy zazwyczaj techniki. Nie jest to krytyka tego modelu, jednak trzeba ten szczegół mieć na uwadze aby uniknąć nieporozumień.

Przechodząc to zastosowania modelu, korzystając z katalogu ułatwiamy wykorzystanie produktów threat intelligence przez inne zespoły i dostajemy kolejne narzędzie do katalogowania aktywności w środowisku. Po pierwsze katalog obserwowanych aktywności może służyć zespołom zajmującym się threat huntingiem i tworzeniem detekcji jako wskazówkę co do kierunku działań. A po drugie, możemy przypisać konkretne wpisy z ATT&CK do działań które obserwujemy, to w dłuższej perspektywie umożliwia to nam tworzenie histogramów pokazujących które aktywności najczęściej występują w naszym środowisku. Co zależnie od interpretacji może świadczyć, że powinniśmy skupić się na wdrażaniu zabezpieczeń przed nimi, bądź że należy rozwinąć możliwości detekcji bo innych technik nie widzimy 🙂 Wróćmy do naszego przykładu i zobaczmy jak możemy rozwinąć analizę:

Dodaliśmy więc następujące identyfikatory:

T1102 – Web Service – kiedy atakujący korzystają z powszechnie używanych serwisów jak Dropbox, Google Drive czy właśni GitHub do komunikacji C2.

T1204.002 – User Execution: Malicious File – tutaj widzimy przykład pod-techniki w ujęciu Mitre. T1204 to identyfikator techniki skłonienia użytkownika do uruchomienia złośliwego elementu, a 002 to oznaczanie wykorzystania złośliwego pliku (inne możliwości tutaj to złośliwy link lub złośliwy obrazek).

S0363 i S0154 – oprócz samych metod w katalogu ATT&CK znajdziemy również narzędzi stosowanych przez napastników i wpisy oznaczone literką S to właśnie wpisy dotyczące oprogramowania.

Techniki które znaleźliśmy możemy oznaczyć w katalogu korzystając z ATT&CK Navigator które umożliwia prace z katalogiem poprzez przypisanie wartości konkretnym wpisom, używanie kolorów do oznaczenia interesujących nas technik czy eksportu tabelki do arkusza kalkulacyjnego. Tak wygląda więc Navigator gdzie przypisałem aktywnością które zaobserwowaliśmy wartość „1” (możemy przykładowo zwiększać wartość z każdym kolejnym wykryciem techniki):

W końcu, spójrzmy na wszystkie narzędzia jako całość i zobaczmy jak możemy je razem wykorzystać do kompleksowego śledzenia kampanii. Po pierwsze śledząc kill-chainy kolejnych prób włamań możemy odnajdywać wspólne elementy i tworzyć grupy aktywności (activity groups) w rezultacie zdobywając wiedzę o tym jakie grupy są zainteresowane naszym środowiskiem. Graficzna reprezentacja takiej analizy wygląda tak:

Każda kolumna diamentów reprezentuje tutaj pojedynczy incydent, a strzałki wierzchołek diamentu dla danej fazy który był elementem wspólnym, widzimy więc np.: podobną aktywność na etapie uzbrojenia, dostarczenia, instalacji i realizacji celów dla incydentów drugiego i trzeciego. Dalej, analizując bliżej konkretny incydent możemy po pierwsze sklasyfikować aktywność jaką zaobserwowaliśmy, a po drugie łatwo ocenić to gdzie mamy braki widoczności:

Z takiego przedstawienia analizy zaobserwowanych aktywności jasno widzimy np.: że całkiem nieźle mamy zmapowane możliwości które wykorzystał napastnik, a mniej wiemy o jego infrastrukturze, i w szczególności musimy popracować jeszcze nad analizą fazy wykorzystania podatności.

Na zakończenie chciałbym dodać, że z mojej perspektywy, narzędzia które omówiłem bardzo pomogły mi kiedy stawiałem pierwsze kroki w threat intelligence, ponieważ pomagają rozłożyć nawet bardzo skomplikowane próby włamań na proste do opisu podstawowe elementy. Zmierzenie się z ogromem danych będących wynikiem analizy incydentu przez zespół DFIR i wzbogacenia indykatorów o informacje z zewnętrznych źródeł może być przytłaczające. Jeżeli jednak zaczniemy powoli przypisywać poszczególne znaleziska do faz aktywności, wierzchołków diamentu i identyfikatorów ATT&CK to z pewnością będzie dużo łatwiej odnaleźć się w tym co zaszło w atakowanej infrastrukturze.

Jedna myśl na temat „

Dodaj komentarz

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

pl_PLPolish