HTB Sherlock - Lockpick3.0 Writeup

HTB Sherlock - Lockpick3.0 Writeup

Scenariusz Zadania

Atakujący, stojący za wariantem ransomware Lockpick, wydają się zwiększać swoje umiejętności. Na szczęście tym razem uderzyli jedynie w serwer deweloperski, a nie produkcyjny. Potrzebujemy Twojej pomocy przy inżynierii wstecznej ładunku oraz analizie powiązanych artefaktów. Co ciekawe, nie znaleźliśmy dowodów na dostęp zdalny, więc prawdopodobnie mamy do czynienia z zagrożeniem wewnętrznym… Powodzenia!.

(ang. The threat actors of the Lockpick variant of Ransomware seem to have increased their skillset. Thankfully on this occasion they only hit a development, non production server. We require your assistance performing some reverse engineering of the payload in addition to some analysis of some relevant artifacts. Interestingly we can’t find evidence of remote access so there is likely an insider threat…. Good luck!)

Artefakty

Po rozpakowaniu pliku ZIP znajdujemy trzy pliki (Rys 1):

  • ubuntu-client - malware
  • ubuntu-client-Snapshot2.vmem - zrzut pamięci serwera deweloperskiego.
  • ubuntu-client-Snapshot2.vmsn - zrzut stanu serwera deweloperskiego (link)
    Rys. 1. Zawartość pobranego pliku zip po rozpakowaniu.
    Rys. 1. Zawartość pobranego pliku zip po rozpakowaniu.

Rozwiązanie

Zadanie 1

Proszę potwierdzić hash pliku malware? (MD5)

(ang. Please confirm the file hash of the malware? (MD5))

Po wykonaniu polecenia md5 ubuntu-client, uzyskałem hash MD5, który okazał się poprawny (Rys. 2).

Rys. 2. Hash MD5 dostarczonego malware.
Rys. 2. Hash MD5 dostarczonego malware.

Odpowiedź: a2444b61b65be96fc2e65924dee8febd

Zadanie 2

Proszę potwierdzić ciąg XOR użyty przez atakującego do zaciemnienia?

(ang. Please confirm the XOR string utilised by the attacker for obfuscation?)

Zanim przystąpiłem do analizy zrzutu pamięci za pomocą Volatility3, postanowiłem najpierw użyć polecenia strings. Dzięki użyciu strings ubuntu-client-Snapshot2.vmem | grep ubuntu-client udało mi się zidentyfikować polecenie wykonane przez atakującego w celu uruchomienia złośliwego oprogramowania. Wystąpienia tego polecenia były jednolite i niezbyt liczne (Rys 3).

Rys. 3. Polecenie wykonane przez atakującego w celu uruchomienia malware.
Rys. 3. Polecenie wykonane przez atakującego w celu uruchomienia malware.

Odpowiedź: xGonnaGiveIt2Ya

Zadanie 3

Jaki jest punkt końcowy API używany do pobrania klucza?

(ang. What is the API endpoint utilised to retrieve the key?)

Zanim przystąpiłem do analizy dynamicznej, najpierw sprawdziłem, co na temat tej binarki może podpowiedzieć mi VirusTotal. Niestety, nie znalazłem tam nic ciekawego, co mogłoby mnie naprowadzić na rozwiązanie. Następnie, używając polecenia strings, próbowałem znaleźć coś, co mogłoby wskazać cały ciąg znaków, wystarczający do wykonania operacji XOR. Nie udało mi się wykryć nic odpowiedniego, ale zauważyłem dwa endpointy: /connect oraz /upload/ (Rys 4).

Rys. 4. Wynik polecenia <code>strings ubuntu-client</code>.
Rys. 4. Wynik polecenia strings ubuntu-client.
Z otrzymanych wyników zrozumiałem, że atakujący najpierw wykorzystuje operację XOR do pozyskania adresu, a następnie łączy go ze znalezionym przeze mnie endpointem. Wtedy postanowiłem uruchomić ubuntu-client w gdb. Pierwsza próba zakończyła się fiaskiem z powodu brakującej biblioteki libcrypto.so.1.1 (Rys 5).
Rys. 5. Pierwsza próba uruchomienia <code>gdb ubuntu-client</code>.
Rys. 5. Pierwsza próba uruchomienia gdb ubuntu-client.
W menedżerze pakietów apt nie udało mi się znaleźć odpowiednika, więc poszukiwałem sposobu na zbudowanie wymaganej biblioteki. W tym celu skorzystałem z artykułu. Dzięki poniższym poleceniom udało mi się pobrać i skompilować brakującą bibliotekę.

wget -c https://www.openssl.org/source/openssl-1.1.1s.tar.gz && \
tar xf openssl-1.1.1s.tar.gz && \
cd openssl-1.1.1s/ && \
./config --prefix="/usr/local/openssl" && \
make

Następnie, za pomocą zmiennej środowiskowej LD_LIBRARY_PATH, wskazałem gdb, gdzie powinien szukać brakujących zależności. Wykonując LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/michal/openssl-1.1.1s gdb ubuntu-client, udało mi się uruchomić program. Do analizy malware użyłem dodatku do gdb o nazwie peda, który znacząco ułatwia analizę oprogramowania. Następnie w gdb, za pomocą polecenia info functions, wylistowałem funkcje wykorzystywane przez złośliwe oprogramowanie. Moją uwagę przyciągnęło curl_easy_setopt@plt. plt oznacza, że jest to funkcja ładowana z zewnętrznej biblioteki, a curl_easy_setopt, zgodnie z dokumentacją, to funkcja używana do nawiązania połączenia curl. Dlatego też, za pomocą polecenia b curl_easy_setopt ustawiłem breakpoint na wywołaniu tej metody, a następnie uruchomiłem debugowanie za pomocą run xGonnaGiveIt2Ya (Rys 6).

Rys. 6. Druga próba uruchomienia <code>gdb ubuntu-client</code>.
Rys. 6. Druga próba uruchomienia gdb ubuntu-client.
Już przy pierwszym złapaniu programu na breakpoint odczytałem adres URL wykorzystywany do otrzymywania kluczy (Rys 7), co potwierdziło moje przypuszczenia z pierwszego etapu, że atakujący łączył endpoint z adresem poddanym operacji XOR.
Rys. 7. Wykryty adres API wykorzystywany do pobierania klucza.
Rys. 7. Wykryty adres API wykorzystywany do pobierania klucza.

Odpowiedź: https://plankton-app-3qigq.ondigitalocean.app/connect

Zadanie 4

Jaki jest punkt końcowy API używany do przesyłania plików?

(ang. What is the API endpoint utilised for upload of files?)

Podczas analizy oprogramowania za pomocą polecenia strings odkryłem dwa endpointy: /connect oraz /uploads/. Po ustaleniu pełnego adresu służącego do pobierania klucza w zadaniu 3, zastąpiłem wartość /connect na /uploads/.

Odpowiedź: https://plankton-app-3qigq.ondigitalocean.app/upload/

Zadanie 5

Jaka jest nazwa usługi utworzonej przez malware?

(ang. What is the name of the service created by the malware?)

Muszę przyznać, że to zadanie zajęło mi najwięcej czasu. Początkowo nie rozumiałem, dlaczego dostarczone zrzuty pamięci nie były prawidłowo obsługiwane przez narzędzia Volatility3 i Volatility. Dopiero po pewnym czasie odkryłem, że muszę skorzystać z dodatkowych symboli, które nie są domyślnie dołączone do Volatility3. Na początku natknąłem się na wątek, który sugerował, aby najpierw zidentyfikować, jaki kernel był używany przez maszynę, z której pochodzi zrzut. Używając polecenia python3 vol.py -f ../ubuntu-client-Snapshot2.vmem banners, ustaliłem, że Ubuntu korzystało z kernela 5.4.0-163-generic (Rys 8).

Rys. 8. Wersja kernela wykorzystywana przez maszynę deweloperską.
Rys. 8. Wersja kernela wykorzystywana przez maszynę deweloperską.
Następnie skorzystałem z tego repozytorium i skopiowałem jego zawartość do katalogu volatility3/symbols/linux, co pozwoliło mi na przeprowadzenie analizy. Po chwili bezskutecznego przeszukiwania plików, wpadłem na pomysł, aby poszukać pliku .service odpowiadającego czasowi wykonania polecenia ubuntu-client xGonnaGiveIt2Ya (Rys 9).
Rys. 9. Czas wykonania polecenia przez atakującego.
Rys. 9. Czas wykonania polecenia przez atakującego.
Po zawężeniu wyników wyszukiwania szybko znalazłem serwis, który został stworzony zaraz po uruchomieniu malware przez atakującego (Rys 10).
Rys. 10. Nazwa serwisu stworzonego przez malware.
Rys. 10. Nazwa serwisu stworzonego przez malware.

Odpowiedź: ubuntu_running.service

Zadanie 6

Jakie jest ID techniki używanej przez atakującego do utrzymania persystencji?

(ang. What is the technique ID utilised by the attacker for persistence?)

To było najprostsze zadanie – wpisując słowa kluczowe i klikając pierwszy link, uzyskałem odpowiedź (Rys. 11).

Rys. 11. Wyszukana fraza w google.
Rys. 11.Wyszukana fraza w google.

Odpowiedź: T1543.002