Analiza Malware dla każdego #3 - Analiza pamięci za pomocą programu Redline firmy Mandiant

Enterprise Malware Management - Kryminalistyka Informatyczna

Dzial kryminalistyki informatycznej W departamentach IT bardzo czesto zajmuje sie badaniem i obsluga incydentów, które powstaja z powodu niedbalstwa lub przeoczenia administratorów, a nastepnie prowadza do ataków takich jak drive-by-downloads czy APT, w skutek niewiedzy uzytkownika koncowego. Celem zarzadzania incydentami bezpieczenstwa informacji jest zapewnienie ciaglosci dzialania systemu, a caly proces sklada sie z 6 etapów.

1. Planowanie i przygotowanie
2. Identyfikacja
3. Powstrzymywanie
4. Likwidowanie
5. Odzyskiwanie
6. Kontrola

Dzialania kryminalistyki informatycznej polega na etapie numer 6, czyli na przeprowadzeniu kontroli, która jest jedną z najbardziej istotnych czynnosci podczas procedury odpowiedzi na incydent. Celem kontroli po incydencie jest przeprowadzenie czynnosci zwiazanych z oskarzeniem i osądzeniem osób, które zlamaly prawo. Bardzo czesto powoduje to koniecznosc przejrzenia polityk organizacji w celu zwiekszenia jej restrykcyjnosci lub jej calkowitej zmiany. Etap ten ma równiez na celu przeprowadzenie oceny ryzyka i analizy zmian, które nalezy koniecznie wprowadzic do wszelkich szkolen i technologii. W przypadku wykrycia nowego rodzaju malware, kryminalistyka informatyczna moze takze brac udzial w etapie 3,4,5.

Indicator of Compromise (Wskaznik kompromisu)

Informacje o zagrozeniach istnieja od wielu lat, ale  dopiero od niedawna sa uzywane przez srodowisko bezpieczenstwa w sposób bardziej strukturalny i konsekwentny. Organizacje odchodza juz od tradycyjnego sposobu obslugi incydentu bezpieczenstwa typu czekanie na powiadomienie o incydencie i odpowiedz na niego. Nowatorskie podejscie zaleca do podjecia aktywnych dzialan do zwalczania malware w celu zabezpieczenia calej infrastruktury informatycznej i w tej nowej strategii IOC odgrywa kluczowa role. Gdy ktos skompromituje system, pozostawia slady po sobie, które moga byc wykorzystane do identyfikacji zagrozen lub hakera.

OpenIOC jest to open source framework, który zostal opracowany przez firme Mandiant w celu udostepnienia informacji o zagrozeniach. Moze byc stosowany w celu poprawy niezawodnosci i powtarzalnosci procesu dochodzenia poprzez wprowadzenie standardu dokumentacji, który moze zostac uzyty w raporcie dochodzenia. Jako ze raport jest zapisany w formacie XML moze zostac wykorzystany w przeprowadzeniu kontroli czyli etapie 6 (tabela1). Inne rodzje podobnych projektów to stworzony przez  IETF Working Group, który definiuje dwa standardy. Pierwszy opisuje obserwacje incydentów bezpieczenstwa w IODEF (Incident Object Description Exchange Format) opisany w RFC570. Drugi jest to Real-Time Inter Network Defence (RID) opisany w RFC6545, który jest uzyty do wymiany IODEF informacji. Kolejnymi projektami sa CyboX, STIX i TAXII firmy Mitre.

Mandiant Redline – analiza pamieci

Narzędzie Redline firmy Mandiant pozwala na analizę pamięci operacyjnej, potencjalnie zainfekowanego systemu operacyjnego Windows, w celu znalezienia śladów działania złośliwego oprogramowania. Redline pozwala na:

• Zbieranie informacji o procesach, danych z rejestru oraz zrzutów pamięci.
• Przeglądanie zaimportowanych danych.
• Identyfikacje procesów, które są podejrzane i warte poddania próbie analizy opartej o Malware Risk Index (MRI).
• Wykonania analizy Indicators of Compromise (IOC).
• Używania whitelist w celu odfiltrowania false/positive w oparciu o hasze MD5.

Analiza Malware dla każdego #2 - REMnux i Mobisec dynamiczna analiza malware na androidzie

Do analizy malware na systemie Android potrzebne będą nam dwa systemy: REMnux i Mobisec. REMnux to narzędzie do analizy malware, ale nie jest przeznaczone do wykonywania analizy systemów mobilnych takich jak Android, z drugiej strony mamy możliwość  użycia emulatora urządzeń mobilnych Mobisec. Oba systemy działają pod linuxem i w dalszej częsci przedstawię jak je skonfigurować, żeby wykonać analizę malware na systemie Android.

REMnux można pobrać w formacie OVF/OVA, który następnie może importować do VMWare lub VirtualBox, albo jako ISO. MobiSec jest dostępne jedynie w ISO. Ponieważ będziemy mieli doczynienia z malware, bardzo ważne jest żeby sieć naszego laboratorium była odizolowana i bez dostępu do Internetu, czyli w trybie Host only.

Konfiguracja MobiSec

MobiSec trzeba skonfigurować żeby przekierować ruch sieciowy do REMnux. W tym celu trzeba ustawić DNS i Gateway Mobisec na adress IP REMnux. DNS ustawiamy edytując plik /etc/resolv.conf w moim przypadku wpisuje 192.168.11.130 - adres IP REMnuxa.

Następnie edytujemy plik /etc/network/interfaces w celu przekierowania całego ruchu sieciowego z MobiSec do REMnuxa.

W pliku tym możemy ustawić statyczne IP dla MobiSec, ale najważniejsze żeby gateway = IP REMnuxa. Zapisujemy plik i restartujemy interfejs sieciowy i sprawdzamy adres IP.

Następnie komendą route –n sprawdzamy czy gateway została zapisana poprawnie.

Konfiguracja REMnuxa

Konfiguracja REMnuxa jest prosta, wystarczy ustawić stały adres IP w pliku /etc/network/interfaces a następnie restartujemy interfejs sieciowy.

MobiSec i REMnux są już skonfigurowane w ten sposób, że cały ruch sieciowy będzie wysyłany z MobiSec do REMnux.

Infekcja Androida malware Android.Exprespam

MobiSec posiada kilka wersji emulatora Android, ja użyje emulatora Android 4.0.3 i zainfekuje go złośliwym kodem, którego działanie będzie widoczne na REMnuxie.

Próbki malware można ściągnąć ze strony http://contagiominidump.blogspot.ie jest to jedno z najlepszych źródeł próbek malware, które znam. Wszystkie próbki są spakowane i zabezpieczone hasłem. Hasło składa się z dwóch członów, pierwszy to jest słowo infected666 i drugie to ostatnia litera nazwy pliku. Ja wybrałem malware Android.Exprespam które można pobrać z http://contagiominidump.blogspot.ie/2013/01/androidexprespam.html plik nazywa się AndroidExprespam.zip więc hasło jest infected666m

Po rozpakowaniu kopiuje plik do MobiSec poprzez SCP i instaluje poprzez komendę adb install

Po zainstalowaniu malware należy je uruchomić. Klikamy w ikonę która wygląda dosyć podejrzanie ;)

Interakcja malware z REMnuxem

Kolejnym krokiem będzie przygotowanie REMnuxa do interakcji z malware. REMnux pozwala na uruchomianie serwisów, które działają jak honeypot i pozwalają sprawdzić jak działa malware. Na przykład możemy uruchomić serwery DNS, IRC, SMTP lub HTTP.

Następnie uruchamiamy fakedns który zamieni wszystkie domeny na adres IP REMnuxa.

W tym przypadku widzimy, że malware próbuje kontaktować się z domeną ftukguhilcom.globat.com, a REMnux odpowiada własnym adresem IP! W celu zbadania zachowania malware uruchamiamy Wireshark na REMnuxie poprzez komendę sudo wireshark. Teraz możemy zaobserwować jak zachowuje się malware. Widać że malware próbuje nawiązać połączenie HTTPS, które jest RST przez REMnuxa ponieważ taki serwis nie jest uruchomiony na porcie 443.

Kolejnym krokiem w celu zbadania, co tak dokładnie robi malware, będzie uruchomienie serwera HTTPS. REMnux posiada serwer HTTP oraz stunnel, które pozwolą na skonfigurowanie serwera HTTPS. 

Konfiguracja HTTPS na REMnuxie

Stunnel używa pliku konfiguracyjego stunnel.conf, który domyślnie znajduje się w /etc/stunnel

Tworzymy plik stunnel.conf w katalogu /etc/stunnel, w którym definiujemy ścieżkę do certyfikatu, który później stworzymy.

Tworzymy certyfikat SSL stunnel.pem (samopodpisany) w katalogu /etc/ssl/certs

Następnie edytujemy plik /etc/default/stullen4 i zmieniamy wartość ENABLED z 0 na 1

Restartujemy stunnel komendą sudo /etc/init.d/stunnel4 restart

Startujemy serwer HTTP komendą httpd start

Uruchamiamy przeglądarkę w celu sprawdzenia czy SSL działa.

Wracamy do Wiresharka i teraz widzimy pełen handshake.

Sprawdzając log serwera HTTP dowiadujemy się, że niestety nie występują żadne żądania HTTP. Prawdopodobnie, dlatego że konieczne jest zaakceptowanie samopodpisanego certyfikatu podczas połączenia HTTPS. Możliwe, że malware sprawdza certyfikat, jako dodatkową kontrolę, lub malware używa przeglądarki Androida, gdzie nasz certyfikat nie jest zaimportowany do repozytorium. Prawdopodobnie można zaimportować certyfikat do repozytorium Androida, ale niestety nie udało mi się tego zrobić, więc w następnym przykładnie pokaże jak malware wykonuje żądania HTTP.

Infekcja Androida malware Chuli.A

Następną próbką malware, którą będę analizował jest Chuli.A. Można ją pobrać ze strony http://contagiominidump.blogspot.ie/2013/04/chulia-targeted-attack-android-trojan.html

Zanim zacznę analizę wracam do poprzedniego wyjściowego zapisanego stanu. Robię to dla REMnuxa i Mobisec.

Następnie kopiuje malware na MobiSec i instaluje jak poprzednio poprzez komendę adb install a następnie uruchamiam malware poprzez kliknięcie w Conference. Dobrze jest przeczytać, w jaki sposób malware wykorzystywane jest w celu ataku i w jaki sposób działa, żeby wiedzieć jak je uruchomić na emulatorze. Malware Chuli.A. zostało wykorzystane w celu wykonania ukierunkowanych ataków, poprzez włamanie się na konto email wysokiego rangą aktywisty Tybetańskiego i użyte do wysłania spear phishing z załączonym plikiem WUC’s Conference.apk. Po uruchomieniu pliku na Androidzie pojawia się nowa ikona Conference. W momencie, gdy ofiara uruchomi aplikacje pojawi się krótka informacja o nadchodzących wydarzeniach. Podczas gdy ofiara czyta wiadomość, malware potajemnie zgłasza infekcję do serwera C&C, a następnie wysyła dane. Teraz dowiemy się w jaki sposób malware to robi.

Uruchamiam plik Conference na MobiSec

Interakcja malware z REMnuxem

Następnie na REMnuxie uruchamiamy Wiresharka i sprawdzamy co robi malware.

W tym przypadku malware kontaktuje się bezpośrednio z adresem IP 64.78.161.133 więc nie potrzebne jest fakedns, użyje natomiast serwera HTTP i uruchamiamy go komendą httpd start

Po uruchomieniu serwera HTTP widzimy, że REMnux odpowiada na żądania HTTP automatycznie. Na podświetlonej linii widzimy żądanie HTTP POST odwołujące się do pliku android.php który nie istnieje na serwerze. Sprawdzamy log serwera w celu potwierdzenia

Następnie tworzymy plik android.php i sprawdzimy co malware zrobi w momencie gdy odnajdzie plik.

Teraz widzimy, że gdy istnieje plik android.php dostajemy kod odpowiedzi 200 od serwera, co widzimy w logu serwera HTTP i Wiresharku.

Prawdopodobnie malware wysyłając żądanie POST do C&C, poinformowało, że nowe urządzenie zostało skompromitowane i wysyła informacje o tym urządzeniu. Prawdopodobnie ciąg ‘phone1398894657817’ wysłany w POST jest unikalnym ID.

Następnie malware ponownie wysyła żądanie HTTP POST i odwołuje się do pliku /data/phone1398894657817/process.php

Tworzymy plik i sprawdzamy log serwera HTTP. Widzimy że malware wykonuje kilka żądań POST.

Sprawdzamy w Wiresharku wszystkie żądania POST.

Tutaj widzimy, że sms został wysłany

Tutaj z kolei, nasze Kontakty

A tutaj informacje GPS

A na koniec jeszcze jakieś dodatkowe informacje

W tym momencie kończy się rozdział analizy dynamicznej, która pozwoliła nam dowiedzieć się, w jaki sposób działa malware. Dzięki narzędziom takim jak MobiSec i REMnux można dynamicznie oddziaływać na malware poprzez tworzenie podrobionych odpowiedzi DNS, serwisów HTTP, co pozwoli nam wykonać analizę malware.

Następny rozdział będzie pościęcony Enterprise Malware Management, Indicatior of Compromise oraz przedstawię jak wykonać analizę pamięci w programie Redline firmy Madiant.