piątek, 14 kwietnia 2017

Szczegóły techniczne ataku na banki w Polsce z użyciem serwera KNF



Dzisiaj chcemy podzielić się z Wami raportem, który powstał w wyniku prac, jakie realizowaliśmy dla instytucji finansowych w ramach świadczenia usług wsparcia w obsłudze incydentów. Prace opisane w raporcie były związane z obsługą incydentu ataku na sektor finansowy z udziałem serwera Komisji Nadzoru Finansowego na przełomie roku 2016 i 2017. To w wyniku przedstawionych analiz, został wyłączony serwer KNF.

Atak był opisywany już kilka razy, nie tylko przez media w Polsce ale również za granicą. Dotychczas podawane informacje dot. ataku były niepełne a czasami wręcz nieprawdziwe, z pogranicza hipotez i spekulacji.

Niniejszy raport skupia się na technicznych szczegółach ataku i przedstawia sposób działania oprogramowania złośliwego użytego w ataku. Naszym nadrzędnym celem jest ujawnienie tych informacji, które mogą pozwolić specjalistom bezpieczeństwa na lepsze przygotowanie, przeciwdziałanie i wcześniejsze wykrycie podobnych typów ataków w przyszłości oraz pozwolą na ograniczenie skutków tego typu ataków.

W raporcie opisaliśmy najistotniejsze sekwencje zdarzeń, jakie miały miejsce w analizowanych przez nas przypadkach.

Link do raportu: "Analiza ataku na banki w Polsce".

Miłej lektury.


piątek, 24 marca 2017

Exploit Kit dla ransomware

Już wszyscy jesteśmy przyzwyczajeni do tego, że ransomware jest głównie dystrybuowany z użyciem załączników do wiadomości email. Drugą, alternatywną metodą jest wykorzystanie podatności. Poniżej opiszemy tą metodę. W tym konkretnym przypadku atak wykorzystuje podatność w Adobe Flash.
Użytkownik po wejściu na zainfekowaną stronę jest przekierowywany na właściwą serwer z exploit-em. Na początku zwracanych jest kilka zaciemnionych java skryptów, które pobierają obiekt flash wykorzystujący podatność a następnie tworzą szablon wywołujący obiekt flash. Skrypty mogą też sprawdzać zainstalowaną wersję flash aby przesłać „właściwy” obiekt flash.




Analizując pobierany obiekt z użyciem JPEXS Free Flash Decompiler możemy zauważyć długi ciąg znaków.  Jest to shellcode uruchamiany po udanym wykorzystaniu podatności.


Po wczytaniu do narzędzia IDA widzimy, że na samym początku są instrukcje odkodowujące dalszą część shellcode. Kluczem dla XOR jest wartość 0x84.


Spróbujmy odkodować ten fragment za pomocą skryptu w Python:

b = bytearray(open('payload, 'rb').read())
for i in range(len(b)-0x14):
    b[i+0x14] ^=0x84   
open('rezultat,'wb').write(b)


Poniżej wynik:


Jest to komenda, która do pliku o32.tmp zapisuje plik javascript który następnie jest wywoływany za pomocą komendy wscript. Jego celem jest pobranie i uruchomienie właściwego pliku z ransomware (w tym przypadku o nazwie Cerber).

czwartek, 9 marca 2017

Ćwiczenie: Skuteczny atak socjotechniczny



Wstęp

Ataki socjotechniczne są ciągle jedną z najskuteczniejszych metod wykorzystywaną przez intruzów. Aby zrozumieć metody stosowane przez intruzów od czasu do czasu musimy zasymulować taki atak. W tym artykule krok po kroku pokażemy jak wygląda przykładowa faza przygotowania scenariusza ataku socjotechnicznego z użyciem złośliwego oprogramowania.
Opisane przykłady mogą być stosowane wyłącznie w celach edukacyjnych.

Veil-Evasion

Veil-Evasion jest aplikacją z zestawu narzędzi Veil-Framework, który służy do generowania złośliwego oprogramowania (obecnie 51 modułów) oraz obfuskacji już wcześniej wygenerowanego złośliwego kodu. Veil-Evasion pozwala nam na generowanie payload-ów w różnych językach programowania.
Poniżej fragment dostępnych modułów:


Nie wszystkie modułu tego generatora są jednakowo skutecznie. Co ciekawe zastosowanie niektórych z nich powoduje większą wykrywalność niż w przypadku zastosowania natywnych modułów metasploit. Przyjrzyjmy się bliżej jak działa jeden z dostępnych modułów. Użyjemy modułu ruby/shellcode_inject/base64, który możemy zaliczyć do tych bardziej skutecznych (czyli mających małą wykrywalność).
Poniżej przykład konfiguracji:


W ustawieniach samego payloadu, zostawiamy opcje COMPILE_TO_EXE na wartość Y oraz domyślną metodę iniekcji czyli INJECT_METHOD na Virtual. Następnym krokiem będzie wybranie opcji generate oraz dostarczenie potrzebnego shellcode’u poprzez oprogramowanie msfvenom.


Veil-Evasion w tym wypadku da nam możliwość wybrania i wygenerowania shellcode używając bazy msfvenom. Wspominaliśmy wcześniej że payloady wygenerowane w msfvenom są wykrywalne, jednakże w połączeniu z metodą obfuskacji jaką dostarcza Veil-Evasion możemy spokojnie skorzystać z już gotowych modułów msfvenom, oczywiście jeżeli chodzi o sam shellcode.
Wybieramy payload: windows/meterpreter/reverse_https, następnie podajemy adres serwera C&C. Dlaczego https? Nie wszystkie organizacje analizują ruch https. Oczywiście możemy też użyć np. komunikacji DNS ale tak jak już kiedyś pisaliśmy testy socjotechniczne mają też na celu przetestowanie infrastruktury zamawiającego pod katem różnych ustawień bezpieczeństwa.
Na koniec zostaniemy poproszeni o nazwę naszego payload-u, np. ruby_payload.
Poniżej znajduję się kod malware przed przekształceniem do formy pliku wykonywalnego exe:


Możemy zauważyć że zawarte tam są:

  • Wymagane moduły,
  • Wywołania API dzięki którym załadowany i uruchomiony zostanie shellcode,
  • Zakodowany ciąg kodu malware (shellcode) w postaci base64.

Wiadomość email

Często powtarzającym się scenariuszem (ze względu na skuteczność) jest przygotowanie wiadomości z załącznikiem. Treść wiadomości to zazwyczaj informacja o nieopłaconej fakturze albo „ważne dokumenty” dla odbiorcy. Jest to jeden z ważniejszych elementów ataku – a treść i forma jest bardzo istotna i ma kluczowy wpływ na skuteczność całego przedsięwzięcia.

Załącznik

Czasami atakujący załącza bezpośrednio złośliwy plik do wiadomości – np. javascript dodatkowo kompresuje go i zabezpiecza hasłem. Czasami jest to link do dokumentu pdf znajdujący się na zewnętrznym serwerze. Innym mechanizmem jest implementacja złośliwego makra w dokumencie Office. O ile makro jest dosyć skutecznym sposobem osadzenia malware to okazuje się że organizacje coraz częściej blokują ich obsługę.
W opisywanym scenariuszu zastosujemy inną ciekawą opcję umieszczenia złośliwego oprogramowania w dokumencie. Jest nim umieszczenie obiektu OLE (Object Linking and Embedding) w wcześniej stworzonym dokumencie. Z naszego doświadczenia wynika że jest to często zapomniany element, który nie jest poddawany weryfikacji pod kątem obecności malware (niektóre rozwiązania bezpieczeństwa mają możliwość blokowania „aktywnej zawartości” w dokumentach).
Sposób osadzania obiektu w dokumencie pozwala nam ma utworzenie bardzo przekonującego scenariusza, który zwiększa szanse na przeprowadzenie udanego ataku.
Załóżmy, że naszym celem będzie dział reklamacji firmy X. Z informacji z strony www wiemy że na adres mailowy firmy X czyli reklamacje@firma_x.pl można zgłaszać reklamacje jako klient indywidualny.
Stwórzmy najpierw prosty dokument Microsoft Word, który po uruchomieniu będzie wyglądał jakby jego czcionka nie została poprawnie wyświetlona. Robimy tak pisząc na przykład w mniej używanej czcionce np. MT Extra. Inną metodą jest po prostu utworzeniu ciągu znaków [] co będzie przypominało ciąg znaków z źle wyświetloną czcionką.



Dodajemy do dokumentu również informacje o tym, iż jeżeli dokument nie został wyświetlony poprawnie to prosimy o uruchomienie/instalację czcionek. Dodajemy więc informacje, tak jak zostało to przedstawione poniżej:


Teraz zostaje nam jedynie osadzenie obiektu OLE, który jest plikiem ze złośliwym oprogramowaniem, a dla osoby która otrzyma ten dokument, jedynie „przyciskiem” do „aktywacji czcionek”. Przed wstawieniem zmieniamy jeszcze nazwę wygenerowanego złośliwego pliku na „Microsoft Word.exe”.
Samo umieszczenie obiektu OLE z pliku nie jest zbyt zachęcające nawet dla przeciętnego użytkownika, dlatego też zaznaczamy opcje „Wyświetl jako ikonę”. W tym przypadku nazwiemy nasz plik „Aktywuj czcionki” a ikonę wybierzemy z znanej biblioteki shell32.dll. Po spreparowaniu odpowiednio naszego obiektu oraz wprowadzeniu go do dokumentu, całość powinna przedstawiać się tak:


Nasz dokument jest prawie gotowy, teraz jedynie należy mu nadać odpowiednią nazwę.
Każda próba „aktywacji czcionek” powodowała nawiązywanie sesji do serwera C&C na którym znajdował się skrypt wykonujący kilka podstawowych komend na komputerze ofiary. 

Podsumowanie

Pomimo faktu, że technologia osadzania obiektów OLE w plikach z pakietu MS Office była już w przeszłości używana do przenoszenia złośliwego oprogramowania, to z wykorzystaniem odpowiednich sztuczek socjotechnicznych oraz braku odpowiednich mechanizmów ochrony jest duża szansa udanego ataku. Ataku, który jest prosty i skuteczny.

Źródła

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”