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”

piątek, 6 stycznia 2017

Ataki na instytucje rządowe - grudzień 2016

Kilka dni temu od zespołu reagowania na incydenty komputerowe Ministerstwa Spraw Zagranicznych otrzymaliśmy informacje o wykryciu i zablokowaniu kolejnej próby ataku przeprowadzonego przez grupę APT28. Zarówno tym razem jak i poprzednio atak został przeprowadzony przeciw zaledwie kilku użytkownikom ministerstwa, co dodatkowo utrudniało wykrycie ataku.

Wektor ataku (opisany poniżej przez zespół reagowania MSZ i Prevenity), wykorzystana podatność, dobór grupy docelowej oraz konta z którego wysłano wiadomość potwierdza, że polska administracja rządowa regularnie narażana jest na szczególnie wyrafinowane ataki.

W maju 2016 roku ale i wcześniej opisywaliśmy ataki na polskie instytucje rządowe [1]. Później ataki te były opisywane między innymi przez firmę Palo Alto [2]. Grupa stojąca za tymi atakami nazywana jest  ATP28/Sofacy/Fancy Bear i jeszcze kilka innych. Ostatnio znowu jest o niej głośno za sprawą wyborów w Stanach Zjednoczonych [3]. Ciekawym skutkiem ataków są ostatnie decyzje administracji amerykańskiej [4] i [5] polegające na wydaleniu rosyjskich dyplomatów.

Kilka dni temu grupa ta rozsyłała z serwerów jednej z zagranicznych instytucji rządowych wiadomość z załącznikiem – dokumentem o nazwie „NATO Secretary meeting.doc” [6]. Celem ataku była oczywiście kradzież poufnych dokumentów z zainfekowanych komputerów pracowników instytucji rządowych.
Poniżej fragment infekującego dokumentu:


Dokument zawierał obiekt flash, który wykorzystuje błąd w wirtualnej maszynie Adobe Flash Player. Poniżej zawartość po dekompresji.
 

Gdy użytkownik otworzył załącznik jego komputer nawiązywał połączenia między innymi z tymi serwerami C&C:
  • miropc.org
  • gtranm.com
  • zpfgr.com
Połączenie do pierwszego serwera miało na celu zarejestrowanie zainfekowanego komputera. Poniżej przykłady zapytań:

GET /nato?A=t&SA=t&SV=t&EV=t&MP3=t&AE=t&VE=t&ACC=t&PR=t&SP=f&SB=f&DEB=f&V=WIN%2011%2C7%2C700%2C269&M=Adobe%20Windows&R=1366x768&COL=color&AR=1.0&OS=Windows%207&ARCH=x86&L=pl&IME=t&PR32=t&PR64=t&PT=ActiveX&AVD=f&LFD=f&WD=f&TLS=t&ML=5.1&DP=72 HTTP/1.1

GET /nato?A=t&SA=t&SV=t&EV=t&MP3=t&AE=t&VE=t&ACC=t&PR=t&SP=f&SB=f&DEB=f&V=WIN%2011%2C7%2C700%2C269&M=Adobe%20Windows&R=1024x768&COL=color&AR=1.0&OS=Windows%207&ARCH=x86&L=en&IME=t&PR32=t&PR64=f&PT=ActiveX&AVD=f&LFD=f&WD=f&TLS=t&ML=5.1&DP=72 HTTP/1.1

Następnie do kolejnych serwerów przesyłane są zaszyfrowane komunikaty zawierające szczegółowe informacje o zainfekowanym hoście. Podobnie jak w poprzednich kampaniach intruzi na początku sprawdzali czy przypadkiem zainfekowany komputer nie jest wykorzystywany wyłącznie do analizy ich załącznika. Poniżej przykład przesyłanego komunikatu:


Bez wątpienia cechą charakterystyczną tej grupy jest nietypowy sposób „instalacji” złośliwego oprogramowania. Tworzone są klucze rejestru Office test, Special i Pref. Domyślna wartość dla Perf to ścieżka do pliku DLL – pliku ze złośliwym oprogramowaniem [7].


 

Grupa wprowadziła pewne usprawnienie w porównaniu do poprzednich prób. Nie potrzebują już dwóch bibliotek (celem pierwszej było załadowanie do pamięci procesu aplikacji z pakietu Microsoft Office drugiej biblioteki) a jednej dodatkowo zabezpieczonej przed analizą statyczną i dynamiczną.
Biblioteka eksportuje wyłącznie standardowy punkt wejścia DllEntryPoint. Większość nazw bibliotek i wywoływanych funkcji jest szyfrowana lub nazwy przechowywane są w postaci wartości hash.

Poniżej fragment kodu wywołującego funkcję odczytującą z PEB nazwę biblioteki. Podświetlony jest jej hash – kernel32.dll. Tą technikę opisywaliśmy na naszym blogu.









Wartości hash wyliczane są w podobny sposób do opisywanego przez nas. Jedyną różnicą jest wykorzystanie XOR do dodatkowego kodowania znaków. Poniżej fragment kodu:


Część z danych jest szyfrowana za pomocą algorytmu RC4. W zależności do wywoływanej funkcji wykorzystywane są różne klucze. Przykłady wykorzystywanych kluczy.



Poniżej fragment funkcji, która decyduje o tym, który z kluczy szyfrujących/deszyfrujących ma być użyty do odszyfrowania danych.

Złośliwe oprogramowanie między innymi wysyła do serwera C&C informacje o uruchomionych aplikacjach. Jest to realizowane poprzez wywołanie funkcji ZwQuerySystemInformation z System Information Class 5. Poniżej przykład danych, które po zaszyfrowaniu będą wysyłane do serwerów C&C.

Wersja odszyfrowana:


Źródła:

[1] http://malware.prevenity.com/2016/05/analiza-ataku-z-maja-2016-na-instytucje.html
[2] http://researchcenter.paloaltonetworks.com/2016/06/unit42-new-sofacy-attacks-against-us-government-agency/
[3] https://www.theguardian.com/technology/2016/oct/07/us-russia-dnc-hack-interfering-presidential-election
[4] http://www.rp.pl/Polityka/161229028-USA-poinformowaly-o-wydaleniu-35-rosyjskich-dyplomatow.html
[5] https://www.us-cert.gov/sites/default/files/publications/JAR_16-20296A_GRIZZLY%20STEPPE-2016-1229.pdf
[6] File: NATO Secretary meeting.doc
MD5: 9FE3A0FB3304D749AEED2C3E2E5787EB
[7] File: prtray.dll
MD5: 58D7585CC7DECEC9CF046AA0D8FFCC4D

Ostatnia modyfikacja: 30 grudzień 2016