Niedawno ogłosiliśmy konkurs HackMe w ramach ECSM. Najszybciej odpowiedziały następujące osoby:

1. Mateusz Rek
2. albercik
3. Michał Celiński-Mysław
4. Piotr Kaźmierczak (opis jego rozwiązania w formacie PDF)
5. Łukasz Odzioba

Gratulujemy, niedługo powinniście otrzymać książki i gadżety! Poniżej znajduje się rozwiązanie tego zadania. O ile mogą istnieć inne, niekiedy nawet łatwiejsze, sposoby na znalezienie odpowiedzi na postawione pytania, o tyle postanowiliśmy zaprezentować rozwiązanie, które korzysta tylko z darmowego i ogólnie dostępnego oprogramowania.

Co zrobił Tomek?

Tomek zapewne padł ofiarą prostego ataku inżynierii społecznej. Jego połączenie do http://gogle.test/search?q=male+koty zostało wykonane najprawdopodobniej w wyniku takiego ataku. Ta strona miała element iframe, który prowadził do strony http://192.168.56.200:8080/kitten. Tam z kolei znajdował się element applet, który wczytywał plik o wiele mówiącej nazwie Exploit.jar i uruchamiał kod z klasy Exploit.

Jak być może niektórzy się domyślili ten plik został stworzony za pomocą pakietu Metasploit i wykorzystywał lukę CVE-2012-4681 we wtyczce do przeglądarki Java. Po osiągnięciu kontroli nad systemem operacyjnym pobrany został plik PE spod adresu http://adbe.test/flash.flv. Plik ten spakowany był za pomocą ogólnodostępnego programu UPX. Rozpakowanie jest bardzo proste, wystarczy skorzystać z polecenia upx -d file.exe i otrzymujemy rozpakowany plik binarny droppera.

Co zrobił dropper?

Spróbujmy uruchomić plik droppera na maszynie wirtualnej. Do analizy jego wykonania używać będziemy pakietu SysInternals Suite, a konkretnie narzędzia Process Monitor (ProcMon.exe). Jak zaprezentowano na zrzucie ekranu poniżej złośliwe oprogramowanie próbuje przeczytać klucz rejestru związany z lokalizacją programu MilCAD.exe. Spróbujmy podać dowolną ścieżkę do pustego katalogu (np. C:Program FilesMilCAD) jako wartość tego klucza rejestru.

Jednak niewiele to zmieniło. Wciąż dropper uruchamia się tylko na chwilę. Zobaczmy, korzystając z darmowego deasemblera IDA 5.0, co ciekawego uda nam się znaleźć w wydobytym z ruchu pliku PE. Pierwszy ciąg znaków, który zwraca naszą uwagę to Tomek. Wiemy, że tak się nazywał pracownik, który był celem ataku. Po co znajduje się taki ciąg znaków w pliku wykonywalnym? Poniżej zaprezentowane jest jego jedyne użycie. Jak widać ta część kodu sprawdza czy obecna nazwa użytkownika to Tomek oraz czy data systemowa to 8 października 2014 (tak jak data ataku, którą można wydobyć z pliku PCAP).

Jeśli te warunki są spełnione to program wstrzymuje swoje wykonanie na ponad minutę i wykonuje kolejne instrukcje. Wystarczy zatem stworzyć nowego użytkownika, nazwanego właśnie Tomek i zmienić datę systemową na 8 października 2014. Teraz dropper powinien działać trochę dłużej i nawet wykonać żądanie o plik http://micrsoft.test/windowsupdate. Jest to spójne z zapisem ruchu, w którym po mniej więcej minucie od żądania o dropper jest wysyłane żądanie GET właśnie pod ten adres.

Aby zobaczyć co się stanie po pobraniu pliku wystarczy uruchomić serwer HTTP na adresie IP widocznym z maszyny wirtualnej i dodać poniższy wpis w pliku %SystemRoot%system32driversetchosts.

Należy również pamiętać o umieszczeniu pliku windowsupdate wyekstrahowanego z danego zapisu ruchu. Po ponownym uruchomieniu droppera powinien on wykonać żądanie GET i dokonać zapisu do dwóch plików, co widać w narzędziu ProcessMonitor tak jak pokazano na zrzucie ekranu poniżej.

W przypadku, gdy system plików jest inny niż NTFS efekt będzie taki jak uwidoczniono powyżej. Wynika to z faktu, że dropper chce skorzystać z funkcji NTFS zwanej Alternate Data Stream. Jeśli nasz system plików to NTFS to możemy przejść pod pokazaną wyżej ścieżkę, ale najprawdopodobniej ujrzymy tam pusty plik nukes.dll. Aby wyświetlić zawartość ADS najprościej jest skorzystać z programu firmy NirSoft o nazwie AlternateStreamView. Po uruchomieniu należy wybrać katalog, w którym znajduje się plik nukes.dll i wybrać opcję Export Selected Streams To... i wybrać katalog, do którego program zapisze ADS.

Otrzymaliśmy w ten sposób bibliotekę odszyfrowaną bibliotekę DLL, która znalazła się na komputerze Tomka.

Co zrobiła biblioteka?

Pobrana biblioteka była ładowana do pamięci i uruchamiana z pliku droppera. Biblioteka ta była spakowana za pomocą narzędzia UPX, podobnie jak dropper. Po rozpakowaniu widać, że biblioteka eksportuje kilka funkcji, tak jak na zrzucie ekranu poniżej.

W logach Process Monitora widać próbę dostępu do pliku C:UsersTomekDocumentsACADweapon.trb i wszystko wskazuje na to, że jest to plik, który został wysłany z maszyny Tomka. Dodatkowo, złośliwe oprogramowanie próbuje zrobić tę samą sztuczkę z użyciem Alternate Data Stream, aby zaszyfrować plik przed wysłaniem.

Nazwę pliku zatem już mamy, co możemy sprawdzić tworząc pusty plik, który rzeczywiście zostanie wysłany na zdalny serwer. Pozostała jedynie metoda szyfrowania treści. Jeśli byłby to szyfr strumieniowy to zaszyfrowanie zaszyfrowanego tekstu powinno go rozszyfrować (ponieważ funkcja XOR jest samoodwrotna). Wypróbujmy zatem takie podejście. Z danego pliku PCAP zapiszmy zaszyfrowany plik pod ścieżką, pod którą jest poszukiwany plik do wysłania. Podobnie jak powyżej powinniśmy dodać domenę ftp.crt.test do pliku hosts i postawić serwer FTP, który by akceptował dane do logowania z pliku PCAP zaprezentowane poniżej.

Wtedy na serwerze FTP zobaczymy plik, którego treść powinna nam już podpowiedzieć, że rzeczywiście został użyty szyfr strumieniowy i że znamy już rozwiązanie zadania.

Rozwiązanie

Rozwiązaniem była następująca para wartości podana poniżej.

• Skrót SHA256: fc1e152ad4fce16b490009ae0bd2994f72d911e3ca7e153f162322a66a0dbe90
• Nazwa pliku: weapon.trb (wariacje ścieżki C:UsersTomekMoje DokumentyACADweapon.trb również były akceptowane)

Zwycięzcom jeszcze raz gratulujemy!