czwartek, 19 stycznia 2017

Monitorowanie zdarzeń związanych z bezpieczeństwem



SYSMON (Sysinternals System Monitor) to bezpłatne narzędzie do monitorowania systemu operacyjnego pod kątem identyfikacji działań intruza bądź aktywności złośliwego oprogramowania. Narzędzie bezproblemowo integruje się z systemem operacyjnym Microsoft Windows co oznacza szybką instalację i konfiguracje oraz wykorzystanie natywnych mechanizmów rejestrowania, monitorowania i analizy zdarzeń. Co istotne konfiguracją możemy też zarządzać z poziomu narzędzi Group Policy. Sysmon w odróżnieniu do inspekcji dostępnej natywnie w systemie operacyjnym rejestruje wyłącznie zdarzenia, które umożliwiają nam wykrycie ataków oraz ułatwiają analizę po włamaniu. To wszystko powoduje że zdarzenia te są świetnym źródłem informacji dla systemu SIEM.

Poniżej przedstawimy kilka przykładów konfiguracji i wyników działań, które pozwalają wykryć złośliwe oprogramowanie lub podejrzaną aktywność na stacji roboczej lub serwerze. Wszystkie testy opisane poniżej były wykonywanie na systemie Windows 10 Enterprise.

Sysmon składa się z dwóch elementów. Usługi Sysmon oraz sterownika, który musi być zainstalowany i uruchomiony przy starcie systemu (boot-start driver).


Sysmon umożliwia monitorowanie następujących aktywności: tworzenie i zamykanie procesów, informacje o połączeniach sieciowych, zmiana czasu utworzenia pliku, ładowanie sterowników i plików z kodem wykonywalnym (ImageLoad), tworzenie zdalnych wątków, dostęp do dysku z pominięciem niektórych API (RawAccessRead), dostęp do pamięci procesu (ProcessAccess), tworzenie plików (FileCreate), tworzenie strumieni w NTFS (FileCreateStreamHash) oraz aktywności dotyczące tworzenie/usuwania rejestrów. 

Poniżej przykład załadowanej konfiguracji. Za pomocą polecenia sysmon -c możemy sprawdzać aktualne aktywne reguły.


Sysmon zapisuje zdarzenia do dziennika zdarzeń Application and Services Logs/Microsoft/Windows/Sysmon/Operational. Zalecamy aby zdarzenia były w czasie rzeczywistym przesyłane na zdalny serwer.

W celu wykorzystania pełnej funkcjonalności należy przygotować plik konfiguracyjny w formacie XML. Opisywana konfiguracja znajduje się na naszej stronie GITHUB – aktualny schemat pliku to 3.20.

Głównym elementem pliku konfiguracyjnego są filtry <EventFiltering> z wymaganym atrybutem onmatch. Dla przykładu jeśli nie chcemy rejestrować zamykanych procesów wystarczy przy odpowiednim tagu (ProcessTerminate) w wartości atrybutu onmatch wpisać include:

<ProcessTerminate onmatch=”include” />

Jeśli chcemy monitorować wyłącznie tworzenie procesów, których obrazy znajdują się w katalogach domowych użytkowników (co może być traktowane jako podejrzana aktywność) reguła powinna wyglądać następująco:

<ProcessCreate onmatch="include">
<Image condition="contains">Users</Image>
</ProcessCreate>

Kolejnym podejrzanym typem zdarzeń jest uruchamianie plików wykonywalnych które nie są podpisane cyfrowo. Poniżej reguła informująca o załadowaniu plików nie posiadających podpisu cyfrowego firmy Microsoft.

<ImageLoad onmatch="exclude">
<Signature condition="is">Microsoft Windows</Signature>
<Signature condition="is">Microsoft Corporation</Signature>
</ImageLoad>

Przydatną funkcją jest parametr ProcessAccess który rejestruje dostęp do innych procesów. Tutaj należy przede wszystkim ograniczyć rejestrowanie niektórych zdarzeń. Dla przykładu mogą to być procesy związane z task manager czy proces explorer-em.

<ProcessAccess onmatch="exclude">
<SourceImage condition="contains">procexp64.exe</SourceImage>
<SourceImage condition="is">C:\WINDOWS\System32\Taskmgr.exe</SourceImage>
</ProcessAccess>

Takie wykluczenia są wystarczające na stacji roboczej, która służy do analizy złośliwego oprogramowania. Jeśli natomiast sysmon uruchomiony jest na „zwykłej” stacji roboczej można ograniczyć rejestrowanie do istotnych procesów źródłowych. Z naszego doświadczenia, najczęściej atakowanym procesami są te zawarte poniżej.

<ProcessAccess onmatch="include">
<TargetImage condition="is">C:\Windows\system32\lsass.exe</TargetImage>
<TargetImage condition="is">C:\Windows\system32\winlogon.exe</TargetImage>
<TargetImage condition="is">C:\Windows\system32\explorer.exe</TargetImage>
</ProcessAccess>

Powyższe ograniczenia pozwolą nam wykryć np. próbę odczytu danych uwierzytelniających czy tokenów z procesu LSASS (gdy na systemie nie jest włączony Credential Guard) za pomocą narzędzia np. mimikatz. 

Poniżej przykład zdarzeń które wykryją tego typu narzędzie.


  • Proces może być uruchomiony gdzieś z katalogu domowego użytkownika, np. katalogu temp (Kategoria ProcessCreate)
  • Obraz mimikatz.exe nie jest podpisany cyfrowo (Kategoria ImageLoad)

Image loaded:
UtcTime: 2017-01-18 13:00:12.329
ProcessGuid: {634ab69a-66dc-587f-0000-0010255c4a00}
ProcessId: 3940
Image: C:\Users\IEUser\Documents\mimikatz_trunk\x64\mimikatz.exe
ImageLoaded: C:\Users\IEUser\Documents\mimikatz_trunk\x64\mimikatz.exe
Hashes: SHA256=A483FF2FD55C3774B48D1186AA02DE1D03063909206599F6DA6D897F8A3643AA,IMPHASH=3ED0D1F8A6FB0E255E1ED340B1A3EAAB
Signed: false
Signature:

  • Dostęp do procesu LSASS (kategoria ProcessAccess)

Process accessed:
UtcTime: 2017-01-18 13:00:36.971
SourceProcessGUID: {634ab69a-66dc-587f-0000-0010255c4a00}
SourceProcessId: 3940
SourceThreadId: 700
SourceImage: C:\Users\IEUser\Documents\mimikatz_trunk\x64\mimikatz.exe
TargetProcessGUID: {634ab69a-3e4d-587f-0000-00108a410000}
TargetProcessId: 520
TargetImage: C:\Windows\system32\lsass.exe
GrantedAccess: 0x1410

Najczęstszą metodą instalacji złośliwego oprogramowania jest klucz rejestru RUN z gałęzi HKLM (gdy malware ma uprawnienia administracyjne) lub HKCU (w przypadku uprawnień zalogowanego użytkownika). Reguła wykrywająca zapis do tego klucza jest następująca:

<RegistryEvent onmatch="include">
<TargetObject condition="contains">\SOFTWARE\Microsoft\Windows\CurrentVersion\Run</TargetObject>
</RegistryEvent>

Oto przykład zarejestrowanego zdarzenia:

Registry value set:
UtcTime: 2017-01-18 13:11:29.680
ProcessGuid: {634ab69a-62fc-587f-0000-0010abc24000}
ProcessId: 1440
Image: C:\Users\IEUser\Desktop\malware.exe
EventType: SetValue
TargetObject: \REGISTRY\MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\Test
Details: c:\ProgramData\malware.exe

Kolejnym typem zdarzeń, które w większości przypadków świadczą o kompromitacji systemu jest monitorowanie funkcji CreateRemoteThread. Tutaj zalecamy (mimo wielu fałszywych alarmów na Windows 10) nie włączania żadnych ograniczeń, więc regułą powinna wyglądać następująco:

<CreateRemoteThread onmatch="exclude"/>

Poniżej przykład zarejestrowanego zdarzenia dla pliku malware – dllinject.exe. Plik ten „wstrzykuje” do procesu docelowego bibliotekę za pomocą funkcji LoadLibraryA. 

Fragment kodu malware to:

HANDLE threadID = CreateRemoteThread(process2, NULL, 0, (LPTHREAD_START_ROUTINE)addr, arg, NULL, NULL);

Wywoływana jest funkcja LoadLibraryA() co jest zarejestrowane w dzienniku zdarzeń.

CreateRemoteThread detected:
UtcTime: 2017-01-18 13:42:57.418
SourceProcessGuid: {634ab69a-70e1-587f-0000-0010e76c6a00}
SourceProcessId: 2656
SourceImage: C:\Users\IEUser\Documents\DLLInject.exe
TargetProcessGuid: {634ab69a-70d3-587f-0000-00106e106a00}
TargetProcessId: 2280
TargetImage: C:\Windows\explorer.exe
NewThreadId: 4280
StartAddress: 0x0000000077A88500
StartModule: C:\Windows\System32\KERNEL32.DLL
StartFunction: LoadLibraryA

Trzeba pamiętać, że sysmon ma też ograniczenia i nie będziemy w stanie z jego pomocą wykryć wszystkich typów modyfikacji procesów. Na przykład stosowana często technika process hollowing nie będzie wykrywana bezpośrednio przez sysmon (będziemy mogli wykryć złośliwy kod korzystając z powyżej opisanych reguł dotyczących niepodpisanego kodu czy rozszerzając reguły ProcessAccess).

W przypadku połączeń sieciowych interesująca dla nas może być rejestracja połączeń z przeglądarek internetowych, procesu explorer.exe oraz połączeń na określone porty TCP: 443/80/8080. Nasze reguły mogą wtedy wyglądać następująco:

<NetworkConnect onmatch="include">
<Image condition="contains">chrome.exe</Image>
<Image condition="contains">iexplore.exe</Image>
<Image condition="contains">firefox.exe</Image>
<Image condition="contains">MicrosoftEdgeCP.exe</Image>
<Image condition="contains">MicrosoftEdge.exe</Image>
<Image condition="contains">explorer.exe</Image>
<DestinationPort condition="is">80</DestinationPort>
<DestinationPort condition="is">443</DestinationPort>
<DestinationPort condition="is">8080</DestinationPort>
</NetworkConnect>

Możemy też ograniczyć się do monitorowania połączeń na porty 80/443/8080 ale właśnie z procesów innych niż przeglądarki internetowe.

<NetworkConnect onmatch="include">
<DestinationPort condition="is">80</DestinationPort>
<DestinationPort condition="is">443</DestinationPort>
<DestinationPort condition="is">8080</DestinationPort>
</NetworkConnect>
<NetworkConnect onmatch="exclude">
<Image condition="contains">chrome.exe</Image>
<Image condition="contains">iexplore.exe</Image>
<Image condition="contains">firefox.exe</Image>
<Image condition="contains">MicrosoftEdgeCP.exe</Image>
<Image condition="contains">MicrosoftEdge.exe</Image>
</NetworkConnect>

Jeśli natomiast chcielibyśmy monitorować tworzenie plików wykonywalnych o rozszerzeniu exe to można zastosować regułę FileCreate. Następnie należy utworzyć wykluczenia jak jedno z nich podane poniżej (ignorowanie tworzonych plików w C:\Windows).

<FileCreate onmatch="include">
<TargetFilename condition="end with">exe</TargetFilename>
</FileCreate>
<FileCreate onmatch="exclude">
<TargetFilename condition="begin with">C:\Windows</TargetFilename>
</FileCreate>

Obecnie nie jest możliwe tworzenie bardzie zaawansowanych reguł (zawierających sekwencję warunków logicznych). Problem ten możemy rozwiązań przesyłając zdarzenia do systemu SIEM i tam tworzyć reguły korelujące. Generowane zdarzenia mają wspólne cechy – np. wartość ProcessId gdy chcemy filtrować pliki exe tworzone wyłącznie w katalogu domowym konkretnego użytkownika lub GUID umożliwiający identyfikację sesji użytkownika dla tworzonych procesów.

Możemy też zastosować narzędzie PowerShell.

Poniżej przykłady filtrowania zdarzeń z wykorzystaniem filtrów -FilterXPath oraz -FilterHashTable.

Wyświetlamy listę tworzonych plików exe za pomocą komendy:

PS C:\Windows\system32> get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -FilterXPath "*[System[Task=11]]" | %{$_.Properties[4].Value} 

C:\Users\IEUser\AppData\Local\Temp\nc.exe
C:\$Recycle.Bin\S-1-5-21-299372222-3270937618-803293567-1000\$I2FW3N2.exe
C:\ProgramData\nc.exe
C:\Tools\sdelete.exe
C:\Users\IEUser\Downloads\test\ie.exe

Wyświetlamy zdarzenia dotyczące plików exe tworzonych w katalogu AppData za pomocą komendy:

PS C:\Windows\system32> get-WinEvent -filterhashtable @{logname="Microsoft-Windows-Sysmon/Operational";id=11} | Where-Object {$_.message -like "*AppData*"} | fl

TimeCreated  : 1/18/2017 1:25:19 PM
ProviderName : Microsoft-Windows-Sysmon
Id           : 11
Message      : File created:
               UtcTime: 2017-01-18 21:25:18.961
               ProcessGuid: {634AB69A-3E5F-587F-0000-00102D220300}
               ProcessId: 2840
               Image: C:\Windows\Explorer.EXE
               TargetFilename: C:\Users\IEUser\AppData\Local\Temp\nc.exe
               CreationUtcTime: 2017-01-16 21:09:18.059

Jak widać na powyższych przykładach sysmon jest w stanie ułatwić pracę osobom odpowiedzialnym za monitorowanie bezpieczeństwa czy reagowanie na incydenty bezpieczeństwa. Zalecamy wykorzystywanie tego rozwiązania w organizacjach zarówno do monitorowania stacji roboczych jak i serwerów.

Źródła:
[1] Książka: „Troubleshooting with the Sysinternals Tools”

Brak komentarzy:

Prześlij komentarz