HTB Sherlock - Lockpick2.0 Writeup

Scenariusz Zadania

Zostaliśmy ponownie zaatakowani przez oprogramowanie ransomware, ale tym razem sprawca wydaje się być bardziej zaawansowany. Ponownie udało im się zaszyfrować dużą liczbę naszych plików. Zgodnie z naszą polityką, NIE negocjujemy z przestępcami. Proszę odzyskać pliki, które zostały zaszyfrowane - nie mamy innej opcji! Niestety, nasz dyrektor generalny jest na urlopie i nie można się z nim skontaktować.

Ostrzeżenie: To ostrzeżenie, że Sherlock zawiera oprogramowanie, które będzie wchodzić w interakcje z Twoim komputerem i plikami. To oprogramowanie zostało celowo dołączone w celach edukacyjnych i NIE jest przeznaczone do uruchamiania ani innego wykorzystania. Zawsze obsługuj takie pliki w izolowanych, kontrolowanych i bezpiecznych środowiskach. Po rozpakowaniu archiwum Sherlock.zip znajdziesz plik DANGER.txt. Proszę go przeczytać, aby kontynuować.

(ang. We’ve been hit by Ransomware again, but this time the threat actor seems to have upped their skillset. Once again a they’ve managed to encrypt a large set of our files. It is our policy NOT to negotiate with criminals. Please recover the files they have encrypted - we have no other option! Unfortunately our CEO is on a no-tech retreat so can’t be reached.

Warning This is a warning that this Sherlock includes software that is going to interact with your computer and files. This software has been intentionally included for educational purposes and is NOT intended to be executed or used otherwise. Always handle such files in isolated, controlled, and secure environments. Once the Sherlock zip has been unzipped, you will find a DANGER.txt file. Please read this to proceed.)

Artefakty

Do rozwiązania zadania otrzymujemy następujące pliki (Rys 1):

• DANGER.txt - zawiera ostrzeżenie oraz hasło do rozpakowania archiwum malware.zip,
• share - katalog z plikami zaszyfrowanymi przez ransomware oraz notatkę zostawioną przez atakujących,
• malware.zip - malware, które mamy przenalizować w celu rozwiązania zadania.

W katalogu share znajdują się trzy pliki. Plik countdown.txt zawiera informacje pozostawione przez atakującego, w tym notatkę dotyczącą okupu. Znajduje się tam adres portfela Bitcoin oraz wysokość kwoty, którą należy zapłacić za odszyfrowanie plików. Pozostałe dwa pliki z rozszerzeniem .24bes są zaszyfrowane przez złośliwe oprogramowanie i będą musiały zostać odszyfrowane w dalszej części zadania (Rys. 2).

Po rozpakowaniu katalogu malware.zip otrzymujemy plik update. Po sprawdzeniu poleceniem file okazuje się, że jest to plik ELF, czyli plik wykonywalny dla systemów Linux (Rys. 3).

Pierwszym krokiem, który wykonałem w celu analizy malware, było sprawdzenie, co podpowie mi VirusTotal. Niestety, nie znalazłem w nim za wielu informacji poza tym, że jest to złośliwe oprogramowanie. Jednak moją uwagę zwróciło to, że VirusTotal wskazał, iż oprogramowanie jest spakowane za pomocą UPX (Rys. 4).

Dla pewności użyłem polecenia strings, aby sprawdzić, jakie łańcuchy znaków znajdują się w pliku. Uzyskałem jednoznaczne potwierdzenie, że plik został spakowany za pomocą UPX (Rys. 5). Tym samym otrzymałem odpowiedź na pytanie 8 ale też rozpocząłem poszukiwania dotyczące sposobów na jego rozpakowanie.

Okazało się, że plik można rozpakować tym samym narzędziem, którym został spakowany. Z repozytorium pobrałem upx, a następnie za pomocą polecenia ./upx -d ../update rozpakowałem plik. Po sprawdzeniu typu pliku za pomocą polecenia file, okazało się, że plik nie jest stripped, co oznacza, że wszystkie informacje debugowe są dostępne w binarce. Dzięki temu analiza pliku będzie prostsza (Rys 6).

Od tego momentu mogłem uruchomić dekompilator IDA i przejść do dalszej analizy.

Pierwszym pytaniem na liście było ustalenie, jaki rodzaj szyfrowania jest wykorzystywany przez złośliwe oprogramowanie. Po załadowaniu pliku do IDA skupiłem się na znalezieniu odpowiedzi na to pytanie. Dzięki temu, że oprogramowanie nie było stripped, mogłem łatwo przeglądać funkcje napisane przez atakującego. Podczas analizy zauważyłem funkcję encrypt_file, a po uzyskaniu pseudokodu w linii 23 natrafiłem na wywołanie funkcji EVP_aes_256_cbc. Oznacza to, że oprogramowanie szyfruje pliki za pomocą symetrycznego szyfru blokowego (AES 256 w trybie CBC). Po odnalezieniu klucza używanego przez atakującego do szyfrowania, będzie można bez problemu odszyfrować pliki (Rys. 7).

Trzeba było tylko znaleźć klucz. Aby dowiedzieć się, skąd atakujący go pozyskuje, wróciłem do funkcji main. Tam w linii 16 zauważyłem funkcję get_key_from_url (Rys. 8).

Podczas analizy tej funkcji odkryłem, że zanim ustawiony zostanie adres, z którego ma zostać pobrany klucz (linia 22), najpierw wykonywana jest operacja XOR (linia 20) (Rys. 9).

Stwierdziłem, że szybciej będzie pozyskać klucz za pomocą analizy dynamicznej (tak, wiem, że XOR jest bardzo prosty, ale nie jestem zbyt biegły w korzystaniu z narzędzia IDA). Dlatego uruchomiłem update za pomocą gdb-peda. Następnie ustawiłem breakpoint na wywołanie funkcji curl_easy_setopt (b curl_easy_setopt), która według mojej analizy jest wywoływana jako pierwsza po uruchomieniu programu i wykonaniu operacji XOR. Po wykonaniu polecenia run od razu uzyskałem adres, z którego pobierany jest klucz do szyfrowania plików (Rys. 10).

Plik pobrany z tego adresu miał nazwę updater, co pozwoliło mi odpowiedzieć na zadanie nr 4, a po wykonaniu polecenia md5 updater uzyskałem odpowiedź na zadanie nr 5 (Rys. 11). W tym momencie myślałem, że mam już prawie wszystko. Pozostało tylko zdobyć iv.

Klucz użyty do szyfrowania był w formacie binarnym, dlatego zakodowałem go do postaci Base64 za pomocą polecenia cat updater | base64. Następnie przygotowałem konfigurację w CyberChef w celu odszyfrowania plików. Po skonfigurowaniu CyberChef zauważyłem, że zgłasza on błąd dotyczący długości klucza. Klucz, który otrzymałem na początku, miał długość 48 bajtów, podczas gdy, zgodnie z wcześniejszymi informacjami, szyfrowanie wykorzystuje AES-256, co oznacza, że klucz powinien mieć długość 32 bajtów (Rys. 12).

Ponownie przeanalizowałem funkcję get_key_from_url i zauważyłem, że klucz kopiowany jest do parametru wyjściowego za pomocą funkcji memcpy, której długość jest ustawiona w hex na 0x20, co odpowiada 32 bajtom. Oznacza to, że funkcja memcpy kopiuje tylko początkowe 32 bajty klucza (Rys. 13).

Wróciłem do CyberChef i usunąłem niepotrzebne bajty, aby uzyskać klucz o oczekiwanej długości. W teorii miałem już prawidłowy klucz. Wybrałem pierwszy plik, który chciałem odszyfrować, zamieniłem jego postać na Base64, a następnie wkleiłem do CyberChef. Pozostało mi tylko pozyskać IV. IV w AES jest wartością opcjonalną, dlatego zanim wróciłem do kodu, aby go znaleźć, ustawiłem wartość IV na same zera. Okazało się, że jest to oczekiwana wartość IV i udało mi się odszyfrować plik. W ten sposób miałem już mechanizm umożliwiający odszyfrowanie pozostałych plików (Rys. 14).

W tym momencie miałem już wszystkie potrzebne informacje i mogłem przystąpić do odpowiadania na pytania.

Rozwiązanie

Zadanie 1

Jakiego rodzaju szyfrowania użyto do zaszyfrowania dostarczonych plików?

(ang. What type of encryption has been utilised to encrypt the files provided?)

Odpowiedź na to pytanie znalazłem podczas wstępnej analizy pliku. W funkcji encrypt_file, w linii 22 (Rys. 15).

Odpowiedź: AES

Zadanie 2

Na jaki rynek nasz dyrektor generalny planuje ekspansję? (Proszę odpowiedzieć sformułowaniem użytym w PDF)

(ang. Which market is our CEO planning on expanding into? (Please answer with the wording utilised in the PDF))

Po zdekodowaniu plików za pomocą opisanej powyżej metody, najpierw spróbowałem otworzyć zdeszyfrowany plik za pomocą domyślnej przeglądarki PDF dostępnej w systemie. Ku mojemu zdziwieniu otrzymałem komunikat o błędzie (Rys. 16).

Deszyfrowanie przebiegło pomyślnie, a po sprawdzeniu nagłówka pliku wszystko wyglądało w porządku. Dlatego postanowiłem spróbować otworzyć plik za pomocą innego narzędzia. Wybór padł na przeglądarkę Firefox, która poprawnie wyświetliła plik i umożliwiła mi uzyskanie odpowiedzi na pytanie (Rys. 17).

Odpowiedź: Australian Market

Zadanie 3

Proszę potwierdzić nazwę banku, który nasz dyrektor generalny chciałby przejąć?

(ang. Please confirm the name of the bank our CEO would like to takeover?)

Po zdeszyfrowaniu pliku DOCX, otworzył się on bez żadnych problemów. Już w pierwszych liniach listu odnalazłem odpowiedź na pytanie (Rys. 18).

Odpowiedź: Notionwide

Zadanie 4

Jaka jest nazwa pliku z kluczem użytym przez napastnika?

(ang. What is the file name of the key utlised by the attacker?)

Odpowiedź na pytanie uzyskałem podczas analizy złośliwego oprogramowania (Rys. 19).

Odpowiedź: updater

Zadanie 5

Jaki jest skrót pliku klucza używanego przez napastnika?

(ang. What is the file hash of the key utilised by the attacker?)

Odpowiedź na pytanie uzyskałem podczas analizy złośliwego oprogramowania (Rys. 19).

Odpowiedź: 950efb05238d9893366a816e6609500f

Zadanie 6

Jaki jest adres portfela BTC, na który TA prosi o dokonanie płatności?

(ang. What is the BTC wallet address the TA is asking for payment to?)

W katalogu share, oprócz zaszyfrowanych plików, znajduje się plik countdown.txt, który jest notatką pozostawioną przez atakującego. Po jej przeczytaniu odnalazłem informacje na temat adresu portfela BTC, na który powinien zostać przelany okup (Rys. 20).

Odpowiedź: 1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2

Zadanie 7

Jaką kwotę TA żąda?

(ang. How much is the TA asking for?)

W tej samej notatce znajduje się również informacja na temat wysokości okupu (Rys. 21).

Odpowiedź: £1000000

Zadanie 8

Co zostało użyte do spakowania złośliwego oprogramowania?

(ang. What was used to pack the malware?)

Na samym początku analizy złośliwego oprogramowania znalazłem odpowiedź na to pytanie (Rys. 22).

Odpowiedź: upx