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”
