Wazuh – jak go wykorzystać do wykrycia ataków na Microsoft Active Directory

Czym jest Wazuh

Wazuh jest darmową, a także otwartą platformą bezpieczeństwa, która integruje możliwości XDR (Extended detection and response) oraz SIEM (Security Information and Event Management).  

SIEM ma za zadanie zapewniać monitorowanie, wykrywanie, a także alarmowanie o zdarzeniach i incydentach bezpieczeństwa.  

Wazuh to narzędzie służące do zbierania, agregowania, indeksowania, a także analizowania danych bezpieczeństwa. Pomaga   organizacjom wykrywać włamania, zagrożenia i anomalie behawioralne jak również oferuje ocenę konfiguracji oraz możliwość zarządzania podatnościami. 

 

 

 

 

Czym jest Microsoft AD

Microsoft Active Directory (AD) jest bazą danych zawierającą informacje o użytkownikach, grupach, komputerach, uprawnieniach, a także konfiguracji. Dotyczy ona sieci opartych na rozwiązaniach Microsoft i jest też sercem organizacji, ponieważ pozwala z poziomu jednego komponentu administrować całym środowiskiem informatycznym. Z tego powodu, w momencie, kiedy napastnik uzyska dostęp do infrastruktury wewnętrznej organizacji np. w formie phishingu – usługa Microsoft Active Directory staje się jego naturalnym celem.

Jakie zdarzenia postaramy się zasymulować i zidentyfikować

W poniższym wpisie zajmiemy się kilkoma najbardziej popularnymi atakami na usługę Microsoft Active Directory.

• DCSync attacks: atak wykorzystuje mechanizmy replikacji danych kontrolera domeny, który daje dostęp między innymi do haszy haseł użytkowników. Do jego przeprowadzenia jest wymagane przejęcie konta użytkownika z uprawieniami do replikacji domeny, a także posiadanie uprawnień “Replicating Directory Changes” oraz “Replicating Directory Changes All”.
• Golden ticket attacks: polega na pobraniu informacji z domeny dotyczącej konta krbtgt. Konto służy do podpisywania i szyfrowania wszystkich biletów Kerberos, czyli protokołu uwierzytelniania i autoryzacji. Następnie jest tworzony bilet, który nie ulega przedawnieniu, dla dowolnego konta, nawet nieistniejącego w systemie. Wykorzystując bilet możemy uzyskać dostęp do danych, a także dowolnych usług połączonych z domeną.
• Kerberoasting attacks: atak polega na zdobyciu skrótów haseł dla kont serwisowych, a następnie na próbie ich złamania w trybie offline. Jest to metoda często wykorzystywana do eskalacji uprawień, ze względu na to, iż niejednokrotnie konta serwisowe posiadają większe uprawienia niż zwykły użytkownik.
• Pass the hash (PtH) attacks: polega na wykorzystaniu przez atakującego wykradzionego hasła użytkownika w procesie utworzenia nowej sesji. W tym typie ataku nie wymagamy od osoby atakującej znajomości ani złamania hasła użytkownika w celu dostępu do systemu.
• Ntds.dit password extraction: polega na kradzieży pliku ntds.dit z kontrolera domeny, w którym są przechowywane wszystkie hasła, a także uprawienia kont w usłudze Microsoft Active Directory.

Infrastruktura

Jako infrastrukturę serwerową wykorzystam instalację Microsoft Windows 2012r2 z uruchomioną usługą Active Directory, a także Microsoft Windows 10 jako stację kliencką. Jako system pod serwis WAZUH używam Ubuntu. Dodatkowo Kali Linux pod jako serwer C2.

Sysmon integracja

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 dostarczony przez projektantów systemu WAZUH. Znajduje się ona pod adresem:

https://wazuh.com/resources/blog/detecting-process-injection-with-wazuh/sysmonconfig.xml

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

sysmon64.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. Edytujemy 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

Wazuh konfiguracja serwera

Do identyfikacji ataku użyjemy następujących reguł:

<group name="security_event, windows,sysmon,">
    <if_sid>60103</if_sid>
    <field name="win.system.eventID">^4662$</field>
    <field name="win.eventdata.properties" type="pcre2">{1131f6aa-9c07-11d1-f79f-00c04fc2dcd2}|{19195a5b-6da0-11d0-afd3-00c04fd930c9}</field>
    <options>no_full_log</options>
    <description>Directory Service Access. Possible DCSync attack</description>
  </rule>
<rule id="115001" level="0">
    <if_sid>60103</if_sid>
    <field name="win.system.eventID">^4662$</field>
    <field name="win.eventdata.properties" type="pcre2">{1131f6aa-9c07-11d1-f79f-00c04fc2dcd2}|{19195a5b-6da0-11d0-afd3-00c04fd930c9}</field>
    <field name="win.eventdata.SubjectUserName" type="pcre2">$$</field>
    <options>no_full_log</options>
    <description>Ignore all Directory Service Access that is originated from a machine account containing $</description>
  </rule>
  <rule id="115002" level="12">
    <if_sid>60103</if_sid>
    <field name="win.system.eventID">^4769$</field>
    <field name="win.eventdata.TicketOptions" type="pcre2">0x40810000</field>
    <field name="win.eventdata.TicketEncryptionType" type="pcre2">0x12</field>
    <options>no_full_log</options>
    <description>Possible Keberoasting attack</description>
  </rule>
  <rule id="115003" level="12">
    <if_sid>60103</if_sid>
    <field name="win.system.eventID">^4624$</field>
    <field name="win.eventdata.LogonGuid" type="pcre2">{00000000-0000-0000-0000-000000000000}</field>
    <field name="win.eventdata.logonType" type="pcre2">3</field>
    <options>no_full_log</options>
    <description>Possible Golden Ticket attack</description>
  </rule>
   <rule id="115004" level="12">
    <if_sid>61600</if_sid>
    <field name="win.system.eventID" type="pcre2">17|18</field>
    <field name="win.eventdata.PipeName" type="pcre2">\\PSEXESVC</field>
    <options>no_full_log</options>
    <description>PsExec service launched for possible lateral movement within the domain</description>
  </rule>
  <rule id="115005" level="12">
    <if_group>sysmon_event1</if_group>
    <field name="win.eventdata.commandLine" type="pcre2">NTDSUTIL</field>
    <description>Possible NTDS.dit file extraction using ntdsutil.exe</description>
  </rule>
  <rule id="115006" level="12">
    <if_sid>60103</if_sid>
    <field name="win.system.eventID">^4624$</field>
    <field name="win.eventdata.LogonProcessName" type="pcre2">seclogo</field>
    <field name="win.eventdata.LogonType" type="pcre2">9</field>
    <field name="win.eventdata.AuthenticationPackageName" type="pcre2">Negotiate</field>
    <field name="win.eventdata.LogonGuid" type="pcre2">{00000000-0000-0000-0000-000000000000}</field>
    <options>no_full_log</options>
    <description>Possible Pass the hash attack</description>
  </rule>
  <rule id="115007" level="12">
    <if_sid>61612</if_sid>
    <field name="win.eventdata.TargetImage" type="pcre2">(?i)\\\\system32\\\\lsass.exe</field>
    <field name="win.eventdata.GrantedAccess" type="pcre2">(?i)0x1010</field>
    <description>Possible credential dumping using mimikatz</description>
  </rule>
  </group>

Reguły umieszczamy na serwerze WAZUH. Edytujemy plik:

/var/ossec/etc/rules/local_rules.xml .

Restartujemy moduł managera systemu WAZUH poleceniem:

systemctl restart wazuh-manager

Symulacja ataku na proces lssas

Symulując atak na infrastrukturę AD wychodzę z założenia, że na systemie klienckim posiadamy już konto z uprawieniami lokalnego administratora. Uogólniając: proces lssas odpowiada za uwierzytelnienia użytkowników. W naszej symulacji posłużymy się dobrze znanym narzędziem Mimikatz, aby z pamięci procesu lssas na naszym testowym systemie pozyskać hashe haseł użytkowników.

Na systemie Windows 10 uruchamiamy oprogramowanie Mimikatz, które jest narzędziem do zbierania, a także wykorzystywania poświadczeń w systemach Windows.

Poświadczenia dla użytkownika lukasz, które będziemy wykorzystywać do przeprowadzenia kolejnych ataków wyglądają następująco:

W związku z uruchomieniem oprogramowania Mimikatz, a także zbieraniem poświadczeń z procesu lssas, system Wazuh zarejestrował następujące zdarzenie.

Symulacja ataku Pass the hash

Jak już wspominaliśmy na początku niniejszego artykułu, atak polega na wykorzystaniu protokołu NTLM do uwierzytelnienia użytkownika za pomocą przechwyconego skrótu hasła.

Uruchamiam wiersz poleceń z poziomu Mimikatz z użyciem skradzionych poświadczeń użytkownika lukasz.  

sekurlsa::pth /user:lukasz /domain:testad.local /ntlm:57a42f7e4af489b4c6a96587a4693b7a

Następnie wykonujemy zdalne połączenie z kontrolerem domeny wykorzystując poświadczenia z uruchomionego wcześniej procesu wiersza poleceń.

Używam programu psexec umożliwiającego zdalne połączenie do kontrolera AD. Psexec jest jednym z elementów całego pakietu narzędzi PSTools. Do pobrania ze stron Microsoft:

https://learn.microsoft.com/en-us/sysinternals/downloads/pstools

Udało się zrealizować połączenie do kontrolera domeny na skradzionych poświadczeniach. System Wazuh zarejestrował następujące zdarzenie w związku z atakiem Pass the hash:

Od strony serwera logi wyglądają następująco:

Symulacja ataku DCSync

Tym razem wykorzystamy zebranie poświadczenia użytkownika do przeprowadzenia ataku na mechanizmy replikacji domeny. Użytkownik, którego wykorzystamy do przeprowadzenia tego typu ataku, ma w domenie włączone dwa uprawnienia: „Replicating Directory Changes” oraz “Replicating Directory Changes All”.

Listę użytkowników z wymienionymi powyżej, włączonymi uprawnieniami, możemy wyszukać następującym skryptem powershell:

(Get-Acl "ad:\dc=testad,dc=local").Access | where-object {$_.ObjectType -eq "1131f6aa-9c07-11d1-f79f00c04fc2dcd2" -or $_.objectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"} | Select-Object IdentityReference, objectType

Ponownie uruchamiamy wiersz poleceń na skradzionych poświadczeniach, jednak tym razem nie wykonujemy już podłączenia zdalnego do kontenera domeny, a uruchamiamy w nim oprogramowanie Mimikatz.

Poniższym poleceniem replikujemy referencje KRBTGT z domeny testowej:

lsadump::dcsync /domain:testad.local /user:krbtgt

Od strony serwera widzimy następujące logi w systemie Wazuh:

Symulacja ataku Golden ticket

Konto KRBTGT jest automatycznie tworzone podczas instalacji usługi Microsoft Active Directory. Jego głównym celem jest uwierzytelnianie biletów Kerberos jako konta Key Distribution Center (KDC). W przypadku uwierzytelniania NTLM hasz hasła użytkownika jest przechowywane na kliencie, stąd możliwość pobrania skrótu hasła w narzędziu Mimikatz. Golden ticket jest sfałszowanym biletem uwierzytelniającym, który nie podlega przedawnieniu pozwalającym nam poruszać się po wszystkich zasobach podłączonych do naszej domeny. Do utworzenia klucza potrzebny nam jest hash NTLM konta krbtgt. Hash został pozyskany w ataku DCSync, inaczej musielibyśmy hash wykraść bezpośrednio z domeny a nie przez atak na mechanizm replikacji.

Jedną z metod ataku Golden ticket, jest utworzenie biletu za pośrednictwem oprogramowania Mimikatz następującym poleceniem:

kerberos::golden /domain:testad.local /sid:S-1-5-21-3244048523-965338627-2871988786 /rc4:0aa41b61932f76d671b4538f962b366c /user:Golden /id:500 /ticket:golden.testad.local

Ładujemy plik z zapisanym kluczem do pamięci Mimikatz i z tego poziomu uruchamiamy wiersz poleceń na uprawieniach z zapisanego ticket’u:

Wiersz poleceń uruchomiony na uprawieniach z Golden ticket’u:

Symulacja ataku na kontroler domeny z wykorzystaniem serwera C2

Powyższe ataki spróbujemy ponownie wykonać z wykorzystaniem oprogramowania Empire będącego chyba już klasycznym przykładem serwera Command and Control (C2). Serwery C2 umożliwiają atakującemu między innymi zdalną kontrolę systemu ofiary, uruchomienie zdalnych poleceń, eksfiltrację danych oraz najważniejsze – przeprowadzenia ataków i ich kontrolę na większą skalę niż pojedyncza stacja. Serwer Empire jest domyślnie dostępny w dystrybucji Kali Linux. Agenta Empire uruchamiamy na systemie ofiary na uprawieniach administracyjnych. W naszej symulacji omijamy wstępne fazy ataku procesu cyber kill chain (proces opisuje następujące po sobie fazy ataku, zbaczając od rekonesansu a kończąc na eksfiltracji danych).

W momencie, kiedy mamy już uruchomione oprogramowania na serwerze C2 i stacji ofiary uruchamiamy moduł Mimikatz, znany już nam z poprzednich ataków:

Wykradamy poświadczenia użytkownika z systemu ofiary:

Serwer Wazuh po analizie zdarzeń informuje o wykryciu ataku:

Symulacja ataku DCSync z poziomu serwera C2:

Używamy moduł Mimikatz z serwera C2:

Komunikat po stornie systemu Wazuh informujący użytkownika o wykryciu zagrożenia:

Serwer C2 Empire automatycznie zbiera w swojej bazie wykradzione dane użytkowników:

Z poziomu systemu Kali Linux z pomocą wykradzionych danych możemy wygenerować Golden ticket, wykorzystując do tego oprogramowanie impacket:

Symulacja ataku Kerberoasting

Atak polega na żądaniu od użytkownika z kontrolera domeny biletu usługi TGS. Bilet zostanie zaszyfrowany, stąd próba odszyfrowania go w trybie offline. Do wykonania ataku będzie nam potrzebne oprogramowanie kerberoast, możliwe jest jego pobranie z Github na poniżej stronie:

https://github.com/nidem/kerberoast

Na początku uruchamiamy skrypt powershell GetUserSPNs.ps1. Na skutek tego powinniśmy otrzymać listę kont usług.

Następne dwa polecenia, to ustawienie szyfrowania RC4 oraz żądanie biletu dla naszej http/win10-64:

Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "http/Windows10"

Eksportujemy token lokalnej usługi poniższym poleceniem z oprogramowania Mimikatz:

kerberos::list /export

Lista wyeksportowanych biletów:

Pozostaje nam już tylko próba lokalnego złamania hasła do wyeksportowanego biletu.

Możemy to zrobić za pomocą skryptu tgsrepcrack.py, zawartego w pakiecie kerberoast następującym poleceniem:

tgsrepcrack.py wordlist.txt 1 -40a10000-lukasz@http~win10-64-TESTAD.LOCAL.kirbi

Szybszą metodą jest jednak wykorzystanie Hashcata:

Zarejestrowane zdarzenie na serwerze Wazuh:

Jeżeli dziennik zdarzeń usługi Microsoft Windows nie będzie zawierał zdarzeń odpowiadających za wygenerowanie biletu, konieczne będzie włączenie inspekcji usługi Kerberos w GPO na serwerze AD:

Ntds.dit password extraction

Plik ntds.dit na kontrolerze domeny przechowuje wszystkie dane z usługi AD. Atakujący w trybie offline, mając już lokalną kopię pliku, może wyodrębnić skróty haseł użytkowników.

Na kontrolerze domeny uruchamiamy poniższe polecenie celem przygotowania kopii offline pliku ntds.dit wraz z kluczami rejestru HKEY_LOCAL_MACHINE\SYSTEM, oraz HKEY_LOCAL_MACHINE\SECURITY , umożliwiającymi jego odszyfrowanie:

NTDSUTIL "Activate Instance NTDS" "IFM" "Create Full C:\AD" "q" "q"

Poniżej wynik wykrycia ataku i analizy logów na systemie Wazuh:

Do pozyskania hashy użytkowników będzie nam potrzebny moduł powershell DSInternals, który można pobrać z poniższej strony na serwisie Github:https://github.com/MichaelGrafnetter/DSInternals

Wskazujemy ścieżkę do kluczy oraz lokalnej kopii pliku ntds.dit.

$Key = Get-BootKey -SystemHiveFilePath :\Users\lukaszm\Desktop\wazuh_ad\AD2\registry\SYSTEM
Get-ADDBAccount -All -Bootkey $key -DBPath 'C:\Users\lukaszm\Desktop\wazuh_ad\AD2\Active Directory\ntds.dit'

Poniżej przykładowe hashe dla użytkownika Administrator:

Konkluzja

Poniższy wpis ma za zadnie pokazać możliwość monitorowania infrastruktury Microsoft Active Directory za pomocą systemu WAZUH, a także wskazać sposoby symulacji popularnych ataków oraz przykłady konfiguracji SIEM oraz generowanych alertów.

Czytelnik musi mieć świadomość tego, że pokazane we wpisie przykładowe ścieżki ataku można zrealizować na wiele sposobów. Skarbnicą wiedzy w zakresie sposobu prowadzenia ataków jest macierz MITRE ATT&CK (https://attack.mitre.org/). Zawiera ona wytyczne dotyczące samej klasyfikacji, opisywania, a także wykrywania włamań. Należy wspomnieć, że Wazuh jest z nią zgodny i także zawiera moduł umożliwiający klasyfikacje logów z macierzą MITRE ATT&CK.

Wdrażając systemy informatyczne powinniśmy być świadomi ich słabości oraz potrafić je sklasyfikować pod kontem wagi danego zasobu dla naszej organizacji. Powinniśmy potrafić właściwie monitorować podatności pomoże nam w tym wchodzący w skład Wazuh osobny moduł, wspomagający proces zarządzania podatnościami.

Tam, gdzie jest to możliwe, powinniśmy korzystać z narzędzi klasy Privileged Acces Management (PAM), a to dlatego, że ułatwiają one administratorom nadzór nad kontami uprzywilejowanymi oraz ich monitorowanie.  Systemy te pełnią funkcję zarówno sejfu haseł, jak i automatycznie resetują hasła, tym samym uniemożliwiając atakującemu wykorzystanie skradzionych poświadczeń.

Materiały źródłowe:

https://wazuh.com/blog/how-to-detect-active-directory-attacks-with-wazuh-part-1-of-2/

https://wazuh.com/blog/how-to-detect-active-directory-attacks-with-wazuh-part-2/