Analiza zdarzeń oraz emulacja ataku - WAZUH

Analiza zdarzeń oraz emulacja ataku – WAZUH

Emulacja złośliwego ataku odgrywa ważną rolę w identyfikowaniu technik używanych podczas włamania. Daje również szerokie możliwości testowania reakcji stosowanych zabezpieczeń. W tym artykule opiszę, jak emulować ataki na stacje z systemem Linux i Microsoft Windows, a także jak je wykrywać z systemem WAZUH. Do emulacji ataku wykorzystam oprogramowanie CALDERA. CALDERA to framework cyberbezpieczeństwa opracowany przez MITRE, który pozwala zespołom ds. cyberbezpieczeństwa na testowanie obrony. Do analizy zdarzeń będzie wykorzystywany system WAZUH. Poniższy wpis jest tylko wstępem do tematu jakim jest analiza zdarzeń oraz emulacja ataku. Musimy mieć na uwadze przede wszystkim to, że pracujemy w żywym środowisku. Środowisku, które cały czas się rozwija, w środowisku, gdzie przestępcy cały czas rozwijają metody ataku, starając się przede wszystkim jak najdłużej pozostać w ukryciu.

 

Ruszyły zapisy na kurs "Architekt Zabbix - Monitorowanie Sieci i Sewerów"

Promocja na zaktualizowany kurs Zabbix trwa. Dostęp roczny, dostęp na zawsze i pakiet VIP dostępne w atrakcyjnej cenie do 17 kwietnia do godziny 23:59!

Chcesz wziąć udział w kursie? Kliknij w link: https://asdevops.pl/kurs-zabbix/

 

 

 

 

Cel – Analiza zdarzeń oraz emulacja ataku

Celem ćwiczenia emulacji ataku jest pokazanie gotowych możliwości wykrycia ataku przez system WAZUH, jak i również poszerzenie niestandardowych reguł identyfikacji zdarzeń. Musimy pamiętać, że wszelkie próby emulacji ataku powinniśmy wykonywać na środowisku testowym. Każde uruchomienie złośliwego oprogramowania może doprowadzić do niestabilności systemu, na którym go uruchamiamy, a także propagacji złośliwego oprogramowania na inne stanowiska w tej samej podsieci. Laboratorium do emulacji ataków ma dodatkowy plus, nie mamy szumu związanego z pracą użytkowników.

Przystępując do zbierania zdarzeń systemowych, a następnie do ich korelacji, musimy pamiętać o znacznikach czasowych, które są zawarte w logach. Wszystkie nasze systemy muszą mieć synchronizację z serwerem czasu. Serwer czasu możemy uruchomić w naszej infrastrukturze lub także skorzystać z zewnętrznego dostawcy. Niespełnienie tego warunku może w przyszłości utrudnić nam analizę czasową zderzeń.

Jakie oprogramowanie?

Jako laboratorium posłużmy mi instancja Microsoft Windows Serwer 2012r2, a także Linux Debian. Jako serwer dla oprogramowanie CALDERA wykorzystam aktualną dystrybucją Kali Linux.

Oprogramowanie CALDERA jest zbudowane na platformie MITER ATT&C i jest aktywnym projektem badawczym w MITRE. Składa się on z dwóch komponentów:

  • Podstawowy system: jest to framework, w którym znajduje się asynchroniczny serwer dowodzenia i kontroli (C2) z REST API i interfejsem webowym.
  • Wtyczki: repozytoria rozszerzają podstawowe możliwości frameworka i zapewniają dodatkowe funkcje. Przykłady obejmują agentów, raportowanie, kolekcje TTP i inne.

Projekt jest dostępny na platformie GitHub pod adresem:

https://github.com/mitre/caldera

Instalacja polega na sklonowaniu repozytorium oraz dofinasowaniu niezbędnych bibliotek do Python3.

git clone https://github.com/mitre/caldera.git --recursive
cd caldera
pip3 install -r requirements.txt
python3 server.py --insecure

Krok po kroku

Po uruchomieniu serwisu w przeglądarce przechodzimy pod adres http://localhost:8888 oraz logujemy się przy użyciu domyślnych poświadczeń red/admin.

Oficjalna dokumentacja projektu znajduje się na stronie: https://caldera.readthedocs.io/en/latest/

Oprogramowanie CALDERA do komunikacji wykorzystuje architekturę klient-serwer. Pierwszym krokiem, który musimy wykonać jest konfiguracja agentów. Przechodzimy do sekcji agents i wybieramy „deploy an agent”.

Wybieramy wersję agenta. Domyślnie dostępne są trzy opcje oraz docelowy system operacyjny.

Pole app.contact.http musimy uzupełnić o adres naszego serwera CALDERA, pole agents.implant_name to nazwa pliku z agentem

Na systemie docelowym wykonujemy polecenie.

Następnie na docelowym systemie klienckim po wykonaniu polecenia mamy informację o prawidłowym połączeniu z serwerem.

Na serwerze CALDERA mamy informację o prawidłowym podłączeniu agenta.

Analiza zdarzeń oraz emulacja ataku

Na systemie linux będziemy emulować trzy techniki:

  • T1136.001 Utworzenie lokalnego konta – ta emulacja ataku tworzy nowego użytkownika lokalnego w systemie ofiary.
  • T1531 Usunięcie lokalnego konta – ten atak usuwa konto lokalne z systemu Linux. Przeciwnicy mogą zakłócać dostępność zasobów systemowych i sieciowych, usuwając uprawnionych użytkowników.
  • T1053.003 Zaplanowane zadanie: Cron – atak ten zastępuje zawartość crontab złośliwymi poleceniami. Przeciwnicy mogą nadużywać narzędzia cron, w celu zachowania persystencji w systemie ofiary.

Przechodzimy do sekcji adversaries, gdzie tworzymy nowy profil atakującego oraz z dostępnych technik wybieramy techniki wcześniej opisane.

Zapisujemy profil i przechodzimy do sekcji operations, skąd uruchamiamy zdefiniowany we wcześniejszym kroku profil emulacji ataku. Klikamy start, aby rozpocząć atak. Po wykonaniu zdefiniowanych kroków klikamy stop, by rozpocząć proces czyszczenia systemy po ataku.

Na systemie klienta możemy zaobserwować komunikację z serwerem Command and Control.

Analiza zdarzeń oraz emulacja ataku

Emulacja ataku wyzwoliła alerty na pulpicie nawigacyjnym systemu WAZUH.

Przechodząc do modułu MITRE ATT&CK możemy przefiltrować skorelowane logi systemowe z rozpoznanymi technikami ataku.

Możemy również wyświetlić szczegóły poszczególnych technik i zebranych alertów.

Analiza zdarzeń oraz emulacja ataku

Uruchomienie usługi sysmon na serwerze Microsoft Windows 2012r2.

Potrzebujemy z naszego testowego systemu Microsoft Windows uzyskać lepszą widoczność zdarzeń niż ta, którą gwarantują nam standardowe dzienniki logowania. Do tego celu użyję pakietu sysmon dostępnego w narzędziach Microsoft Sysinternals. Sysmon jest usługą systemową, której zadaniem jest szczegółowe rejestrowanie, a także monitorowanie zdarzeń systemu Windows. Konfiguracja usługi odbywa się przez plik xml. Jako wzorzec konfiguracji posłuży mi plik dostępny w repozytorium SwiftOnSecurity na GitHub. Zawiera on szczegółową konfigurację pakietu sysmon, wraz z obszernymi komentarzami. Znajdziemy go pod adresem: https://github.com/SwiftOnSecurity/sysmon-config

Możemy wykorzystać gotową konfigurację pakietu sysmon, dostarczoną przez projektantów systemu WAZUH. Znajduje się ona pod adresem: https://wazuh.com/resources/blog/emulation-of-attack-techniques-and-detection-with-wazuh/sysmonconfig.xml

Samo uruchomienie usługi wykonujemy poniższą komendą w wierszu poleceń, uruchomioną na uprawieniach administracyjnych.

system.exe -accepteula -i sysmonconfig.xml

Następnie należy edytować konfigurację agenta WAZUH na systemie Microsoft Windows, celem zbierania logów z usługi sysmon. Edytujmy następujący plik konfiguracyjny „C:\Program Files (x86)\ossec-agent\ossec.conf”, umieszczając w nim następujący wpis:

<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

Restartujemy agenta z poziomu PowerShell.

Restart-Service -Name wazuh

Przechodźmy do edycji pliku dekodowania reguł na serwerze WAZUH. Edytujemy plik: /var/ossec/etc/rules/local_rules.xml . A następnie umieszczamy w nim następujący wpis:

<group name="windows,sysmon,">
 <rule id="115001" level="3">
    <if_group>sysmon</if_group>
    <description>Windows Sysmon event. Event ID: $(win.system.eventID)</description>
    <options>no_full_log</options>
  </rule>
</group>

Restartujemy moduł managera systemu WAZUH.

systemctl restart wazuh-manager

W zakładce security events powinny się pojawić logi z usługi sysmon. W poniższym przykładzie widać zdarzenie polegające na uruchomieniu notatnika w monitorowanym systemie.

Dodawanie nowych reguł dekodowania

Prowadzenie emulacji ataku w kontrolowanym przez nas środowisku daje nam dodatkowe profity. Z jednej strony testujemy zestaw reguł i mamy możliwość ich modyfikacji, jeżeli nie otrzymamy prawidłowych wyników lub wyników nie będzie. Z drugiej strony pozbywamy się całego szumu, który daje praca w środowisku produkcyjnym.

Należy pamiętać, że system WAZUH jest dostarczany predefiniowanymi regułami dotyczącymi alertów, wykrywania ataków, jednak może się okazać, że w wyniku prowadzonych testów zabraknie nam reguł do parsowania logów lub naszym zadaniem będzie zbieranie danych z niestandardowych źródeł. Należy wówczas dodać własne reguły dostosowane do potrzeb naszego środowiska.

Zestaw dekoderów znajduje się w katalogu /var/ossec/etc/decoders/, zestaw reguł znajduje się w /var/ossec/etc/rules/.

Cały proces jest opisany w dokumentacji produktu: https://documentation.wazuh.com/current/user-manual/ruleset/custom.html

Możemy również dostosować informacje jakie generuje system WAZUH związane z modułem MITRE ATT&CK. Cała procedura i przykłady są również opisane w dokumentacji: https://documentation.wazuh.com/current/user-manual/ruleset/mitre.html

Instalacja Agenta Caldera w systemie Microsoft Windows.

Podobnie jak dla systemu linuxowego, potrzebujemy na docelowym systemie zainstalować agenta oprogramowania Caldera. Przechodzimy w tym celu do zakładki agent, wybieramy opcję „Deploy an agent”, następnie wersję agenta i docelowy system operacyjny. Podajemy adres, na którym działa serwis oprogramowania Caldera.

W efekcie otrzymujemy skrypt PowerShell do wykonania na docelowy systemie.

Analiza zdarzeń oraz emulacja ataku

Oprogramowanie zostanie uruchomione jako proces systemowy.

Po poprawnej instalacji na serwerze C2 będzie widoczny nowy agent dla platformy Microsoft Windows.

Przechodzimy w tej chwili to konfiguracji technik ataku. Podobnie jak dla systemu linux, skonfigurujemy ataki polegające na utworzeniu lokalnego zadania w harmonogramie zadań systemu Windows (technika numer T1053.005), utworzeniu nowego konta użytkownika, oraz konta z uprawieniami administracyjnymi (technika numer T1136.002).

Analiza zdarzeń oraz emulacja ataku

Po zdefiniowaniu technik, w zakładce operations, przechodzimy do wykonania symulacji ataku.

Zdarzenia zarejestrowane w systemie WAZUH dla systemu Microsoft Windows.

Celem emulacji jest wygenerowanie alertu zgodnie z zastosowaną techniką MITRE ATT&CK. W tym celu musimy dodać dodatkowe reguły w pliku konfiguracyjnym.

Przechodzimy do edycji pliku /var/ossec/etc/rules/local_rules.xml na serwerze WAZUH.

A potem uzupełniamy go o następujące wpisy:

<rule id="115001" level="10">
  <if_group>windows</if_group>
  <field name="win.eventdata.ruleName" type="pcre2" >technique_id=T1053,technique_name=Scheduled Task</field>
  <description>A Newly Scheduled Task has been Detected on $(win.system.computer)</description>
  <mitre>
    <id>T1053</id>
  </mitre>
</rule>
<rule id="115009" level="3">
  <if_group>windows</if_group>
  <field name="win.system.EventID">^4720$</field>
  <description>LOGON Local Account Created $(win.eventdata.targetUserName)</description>
  <mitre>
    <id>T1136</id>
  </mitre>
  <options>no_full_log</options>
</rule>

Restartujemy moduł managera systemu WAZUH.

systemctl restart wazuh-manager

W systemie WAZUH otrzymujemy następujące, przykładowe zdarzenia dla macierzy MITRE ATT&CK z przeprowadzonych testów.  Utworzenie nowego wpisu w harmonogramie zadań systemu Microsoft Windows.

Utworzenie nowych kont użytkowników.

Analiza zdarzeń oraz emulacja ataku

Komunikacja z serwerem C2 przez protokół DNS.

Celem uniknięcia wykrycia, atakujący mogą się komunikować ze zdalną infrastrukturą z wykorzystaniem protokołu DNS. Zdarza się, że komunikacja DNS, w szczególności w mniejszych organizacjach, nie jest monitorowana ani także blokowana. Spróbujemy za pomocą systemu WAZUH oraz tym razem za pomocą pakietu Atomic Red Team zasymulować taki atak.

Skorzystamy z gotowych skryptów PowerShell umieszczonych na stronie projektu. https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1071.004/T1071.004.md

Zgodnie z macierzą MITRE ATT&CK będziemy symulowali technikę T1071.004. Przechodzimy do edycji pliku /var/ossec/etc/rules/local_rules.xml na serwerze WAZUH. A potem uzupełniamy go o następujący wpisy:

<rule id="115008" level="3">
  <if_group>windows</if_group>
  <field name="win.system.eventID">^22$</field>
  <description>Sysmon - Event 22: DNS Request by $(win.eventdata.image)</description>
  <mitre>
    <id>T1071</id>
  </mitre>
  <options>no_full_log</options>
</rule>

Restartujemy moduł managera systemu WAZUH.

systemctl restart wazuh-manager

Na testowej maszynie z Microsoft Windows uruchamiamy skrypt w PowerShell, symulujący komunikację po protokole DNS z serwerem C2. Zdarzenia na serwerze WAZUH alert wyglądają następująco:

W systemie WAZUH z poziomu panelu konfiguracyjnego możemy zaimportować do poszczególnych modułów przykładowe dane ze zdarzeniami.

Analiza zdarzeń oraz emulacja ataku – podsumowanie

Na koniec należy wspomnieć o tym, że oprogramowanie CALDERA, służące do emulacji ataku, nie jest jednym takim rozwiązaniem. Wśród rozwiązań komercyjnych można wymienić także: Cobalt Strike, Cymulate, Attack-IQ, Immunity Adversary Simulation, SimSpace. Wśród narzędzi open source można wymienić również: Atomic Red Team, Mordor, czy Infection Monkey, jak i wiele innych.

Poniższy wpis miał za zadanie zwrócić uwagę na możliwości analizy zdarzeń, a także na możliwości testowania środowiska, które mamy w swoich lokalnych sieciach.

Budowanie odpornego systemu do monitoringu, a także korelacji zdarzeń, wymaga ciągłego dostrajania go do nowych form ataku i możliwości ich identyfikacji. Emulacja ataku jest jednym z elementów jego optymalizacji. Mam nadzieję, że teraz analiza zdarzeń oraz emulacja ataku są dla Ciebie zdecydowanie jaśniejsze, a także sam spróbujesz przeprowadzić taką akcję w swoim środowisku.

 

 

 

Ruszyły zapisy na kurs "Architekt Zabbix - Monitorowanie Sieci i Sewerów"

Promocja na zaktualizowany kurs Zabbix trwa. Dostęp roczny, dostęp na zawsze i pakiet VIP dostępne w atrakcyjnej cenie do 17 kwietnia do godziny 23:59!

Chcesz wziąć udział w kursie? Kliknij w link: https://asdevops.pl/kurs-zabbix/

 
 
 

Ruszyły zapisy na Kurs "Architekt Zabbix - Monitorowanie Sieci i Serwerów"

X