HTB Sherlock - OpTinselTrace-5 Writeup

HTB Sherlock - OpTinselTrace-5 Writeup

Scenariusz Zadania

Zauważysz, że wiele z naszej kluczowej infrastruktury serwerowej zostało niedawno przeniesione z domeny naszego dostawcy usług zarządzanych (MSSP) - Forela.local do Northpole.local. Udało nam się zakupić kilka używanych serwerów od MSSP, który potwierdził, że są one tak bezpieczne, jak Święta Bożego Narodzenia! Wydaje się jednak, że nie, ponieważ wierzymy, że Święta są zagrożone, a atakujący wykazali się przebiegłością dzwonka sań, albo wcale nie chcieli się ukrywać!!!!!! Znaleźliśmy złośliwe notatki od Grincha na wszystkich naszych stacjach roboczych i serwerach TinkerTech! Święta wydają się być zagrożone. Proszę pomóż nam odzyskać się po tym niegrzecznym ataku! Uwaga - te zadania Sherlocka są skonstruowane do wykonywania w kolejności i po kolei!

(ang. You’ll notice a lot of our critical server infrastructure was recently transferred from the domain of our MSSP - Forela.local over to Northpole.local. We actually managed to purchase some second-hand servers from the MSSP who have confirmed they are as secure as Christmas is! It seems not as we believe Christmas is doomed and the attackers seemed to have the stealth of a clattering sleigh bell, or they didn’t want to hide at all!!!!!! We have found nasty notes from the Grinch on all of our TinkerTech workstations and servers! Christmas seems doomed. Please help us recover from whoever committed this naughty attack! Please note - these Sherlocks are built to be completed sequentially and in order!.)

Artefakty

Do rozwiązania zadania otrzymujemy następujące pliki:

  • DANGER.txt - zawiera ostrzeżenie oraz hasło do rozpakowania archiwum encrypted_files_suspicious_file.zip,
  • encrypted_files_suspicious_file.zip - zawiera pliki zaszyfrowane przez ransomware oraz samo oprogramowanie ransomware,
  • DC01.northpole.local-KAPE.zip - zawiera artefakty zebrane ze skompromitowanego serwera przy użyciu oprogramowania KAPE.

Łącznie do rozwiązania zadania mamy do dyspozycji 762 pliki.

Rys. 1. Pobrane artefakty.
Rys. 1. Pobrane artefakty.

Rozwiązanie

Zadanie 1

Który CVE wykorzystał początkowo atakujący (TA), aby uzyskać dostęp do DC01?

(ang. Which CVE did the Threat Actor (TA) initially exploit to gain access to DC01?)

Na początku szukałem jakiegoś punktu zaczepienia. Po przejrzeniu wszystkich artefaktów uznałem, że dobrym miejscem na rozpoczęcie analizy będą logi. Ponieważ nie miałem jeszcze jasno określonego celu, postanowiłem skorzystać z opcji “hunt” w narzędziu Chainsaw. Pobrałem reguły Sigma z tego repozytorium i rozpocząłem poszukiwania.

Pierwsze wyniki zawierały ogromną ilość zdarzeń, w których trudno było się zorientować. Postanowiłem więc ograniczyć ilość informacji i za pomocą polecenia ./target/release/chainsaw hunt --skip-errors ../htb/Logs -s ../sigma/ --mapping mappings/sigma-event-logs-all.yml --log >logs.txt stworzyłem plik tekstowy ze zdarzeniami. Plik zawierał 58,650 linii, więc ręczne jego przeglądanie nie wchodziło w grę. W związku z tym zacząłem filtrować wyniki za pomocą narzędzia grep, usuwając wpisy, które nie miały większego znaczenia. Używając polecenia cat logs.txt| grep -vE "User Logoff Event|Uncommon New Firewall Rule Added In Windows Firewall Exception List|Firewall Rule Modified In The Windows Firewall Exception List", udało mi się znacząco zmniejszyć listę wyników. Podczas przeglądania listy, moją uwagę przykuł wpis Possible DC Shadow Attack (Rys. 2).

Rys. 2. Wykryta podejrzana aktywność.
Rys. 2. Wykryta podejrzana aktywność.
Uznałem, że może to być informacja, której szukam. Następnie postanowiłem dowiedzieć się więcej na temat tej reguły i poszukałem dodatkowych informacji w Google. Po wpisaniu frazy Possible DC Shadow Attack cve od razu zauważyłem informację o CVE związanym z tym atakiem (Rys. 3).
Rys. 3. Znalezione CVE powiązane z podejrzaną aktywnością  <code>Possible DC Shadow Attack</code>.
Rys. 3. Znalezione CVE powiązane z podejrzaną aktywnością Possible DC Shadow Attack.

Odpowiedź: CVE-2020-1472

Zadanie 2

O której godzinie TA początkowo wykorzystał CVE? (UTC)

(ang. What time did the TA initially exploit the CVE? (UTC))

Analizując działanie podatności CVE-2020-1472, rozpocząłem poszukiwania od nietypowej aktywności, która mogła mieć miejsce. O godzinie 2023-12-13T09:25:22.529195+00:00 wykryto pierwsze uruchomienie Mimikatz, co sugeruje, że atakujący już miał dostęp do serwera. Kilka linii wcześniej znalazłem informacje o instalacji nowego oprogramowania. Jeszcze wyżej, w tym samym czasie, pojawiła się informacja o logowaniu, które zgodnie z informacjami zawartymi w opisie CVE jest ostatnią fazą wykorzystania exploita (Rys. 4).

Rys. 4. Podejrzana aktywność powiązana z wykrytym CVE.
Rys. 4. Podejrzana aktywność powiązana z wykrytym CVE.

Odpowiedź: 2023-12-13 09:24:23

Zadanie 3

Jaka jest nazwa pliku wykonywalnego związanego z nietypową usługą zainstalowaną w systemie około czasu wykorzystania CVE?

(ang. What is the name of the executable related to the unusual service installed on the system around the time of the CVE exploitation?)

Gdy miałem już punkt zaczepienia, czyli moment, od którego atakujący rozpoczął swoje działania na skompromitowanym serwerze, mogłem uwzględnić go w dalszych poszukiwaniach. Aby znaleźć nazwę pliku nowej usługi, zacząłem od analizy zdarzenia nr 7045, które informuje o instalacji nowego oprogramowania. W wyniku polecenia ./target/release/chainsaw search -t 'Event.System.EventID: =7045' --skip-errors ../htb/Logs --timestamp 'Event.System.TimeCreated_attributes.SystemTime' --from "2023-12-13T09:24:23" otrzymałem tylko jeden wynik, który okazał się odpowiedzią (Rys. 5).

Rys. 5. Nazwa pliku wykonywalnego związanego z nietypową usługą zainstalowaną w systemie około czasu wykorzystania CVE.
Rys. 5. Nazwa pliku wykonywalnego związanego z nietypową usługą zainstalowaną w systemie około czasu wykorzystania CVE.

Odpowiedź: hAvbdksT.exe

Zadanie 4

Jaka była data i godzina uruchomienia nietypowej usługi?

(ang. What date & time was the unusual service start?)

W poprzednim zadaniu nie tylko uzyskałem nazwę pliku, który został uruchomiony, ale także nazwę usługi. Dostosowałem swoją frazę wyszukiwania na ./target/release/chainsaw search 'vulnerable_to_zerologon' --skip-errors ../htb/Logs --timestamp 'Event.System.TimeCreated_attributes.SystemTime' --from "2023-12-13T09:24:23" i otrzymałem trzy wyniki. Pierwszy wynik dotyczył żądania rozpoczęcia działania, drugi związany był z uruchomieniem, a trzeci z zatrzymaniem. Prawidłową odpowiedzią była druga znaleziona wartość, czyli uruchomienie (Rys. 6).

Rys. 6. Czas uruchomienia nietypowej usługi.
Rys. 6. Czas uruchomienia nietypowej usługi.

Odpowiedź: 2023-12-13 09:24:24

Zadanie 5

Jaki był adres IP TA w naszej wewnętrznej sieci?

(ang. What was the TA’s IP address within our internal network?)

Ponownie wykorzystałem czas, aby ograniczyć wyniki, a następnie przeszukałem wszystkie zdarzenia 4624 dotyczące poprawnego logowania użytkowników, używając polecenia ./target/release/chainsaw search -t 'Event.System.EventID: =4624' --skip-errors ../htb/Logs --timestamp 'Event.System.TimeCreated_attributes.SystemTime' --from "2023-12-13T09:24:23". Już w drugim wyniku znalazłem adres IP atakującego (Rys. 7).

Rys. 7. Adres IP TA.
Rys. 7. Adres IP TA.

Odpowiedź: 192.168.68.200

Zadanie 6

Proszę wymienić wszystkie konta użytkowników, z których TA korzystał podczas swojego dostępu. (W kolejności rosnącej)

(ang. Please list all user accounts the TA utilised during their access. (Ascending order))

Znając adres IP atakującego, wykorzystałem go do ponownego przeszukania logów. Za pomocą polecenia ./target/release/chainsaw search '192.168.68.200' --skip-errors ../htb/Logs --timestamp 'Event.System.TimeCreated_attributes.SystemTime' --from "2023-12-13T09:24:23" | grep TargetUserName | sort | uniq wylistowałem listę użytkowników, z których korzystał atakujący. Odrzuciłem nazwy użytkowników ANONYMOUS LOGON oraz DC01, ponieważ atakującemu nie udało się na nich zalogować. Pozostały tylko dwa unikalne konta: Administrator i Bytesparkle (Rys. 8).

Rys. 8. Konta użytkowników wykorzystane przez atakującego.
Rys. 8 .Konta użytkowników wykorzystane przez atakującego.

Odpowiedź: Administrator, Bytesparkle

Zadanie 7

Jaka była nazwa zadania zaplanowanego, utworzonego przez TA?

(ang. What was the name of the scheduled task created by the TA?)

Na początku próbowałem znaleźć w logach zdarzenia dotyczące utworzenia nowego zadania, lecz moje poszukiwania nie przyniosły rezultatów. Dlatego zdecydowałem się spróbować poszukać w katalogu DC01.northpole.local-KAPE/uploads/auto/C%3A/Windows/System32/Tasks. Ponieważ pliki konfiguracyjne zadań są plikami binarnymi, wczytałem ich zawartość do jednego pliku tekstowego za pomocą polecenia find . -exec cat {} \; > ../tasks.txt. Następnie, w edytorze tekstu, poszukałem zadań utworzonych po czasie, gdy atakujący uzyskał dostęp. Okazało się, że istnieje tylko jedno takie zadanie (Rys. 9).

Rys. 9. Nazwa zadania utworzonego przez TA.
Rys. 9. Nazwa zadania utworzonego przez TA.

Odpowiedź: svc_vnc

Zadanie 8

Pamięć Świętego Mikołaja ostatnio trochę szwankuje! Ma tendencję do zapisywania wielu rzeczy, ale wszystkie nasze kluczowe pliki zostały zaszyfrowane! Jakie stworzenie planuje użyć w nowym projekcie sań Świętego Mikołaja?

(ang. Santa’s memory is a little bad recently! He tends to write a lot of stuff down, but all our critical files have been encrypted! Which creature is Santa’s new sleigh design planning to use?)

Do rozwiązania zadania otrzymaliśmy również kilka plików, które zostały zaszyfrowane, oraz podejrzaną bibliotekę DLL. W pierwszym kroku postanowiłem podejrzeć zawartość biblioteki za pomocą polecenia strings. Przeglądając wynik, tuż po treści notatki zauważyłem łańcuch znaków EncryptingC4Fun!, który uznałem za potencjalne hasło potrzebne do odszyfrowania plików. Nieco niżej, po liście rozszerzeń, dostrzegłem kolejny interesujący łańcuch informujący o tym, że operacja XOR się nie powiodła (Rys. 10).

Rys. 10. Analiza zawartości złośliwego pliku za pomocą polecenia <code>strings</code>.
Rys. 10. Analiza zawartości złośliwego pliku za pomocą polecenia strings.
Stwierdziłem, że zanim przejdę do dalszej analizy i poszukiwań sposobu działania złośliwego oprogramowania Not Petya, spróbuję najprostszej metody. Wybrałem do testu plik topsecret.png.xmax. Zenkodowałem jego zawartość do base64, a następnie wkleiłem do CyberChef. Użyłem filtrów do dekodowania z base64 i zastosowałem operację XOR z wcześniej wykrytym hasłem. Na końcu zaznaczyłem opcję, aby CyberChef wykrył typ pliku. Ku mojemu zaskoczeniu, narzędzie poprawnie rozpoznało plik jako obraz PNG (Rys. 11).
Rys. 11. Poprawna &lsquo;deszyfracja&rsquo; pliku.
Rys. 11. Poprawna ‘deszyfracja’ pliku
Pobrałem z CyberChef “odszyfrowany plik”, a po jego otwarciu zobaczyłem obrazek przedstawiający nowy projekt sań mikołaja z jednorożcem (Unicorn) (Rys. 12).
Rys. 12. Zawawrtość pliku topsecret.png.
Rys. 12. Zawawrtość pliku topsecret.png.

Odpowiedź: Unicorn

Zadanie 9

Proszę potwierdzić identyfikator procesu, który zaszyfrował nasze pliki.

(ang. Please confirm the process ID of the process that encrypted our files.)

Przyznam szczerze, że znalezienie odpowiedzi na to pytanie zajęło mi sporo czasu. Na początku próbowałem szukać listy procesów w plikach dostarczonych do zadania. Przeszukiwałem również logi Windows Defendera, ale tam również nie znalazłem niczego przydatnego. W końcu wpadłem na pomysł, aby spróbować najprostszego rozwiązania i przeszukać logi pod kątem frazy xmax, która pojawiała się w nazwach zaszyfrowanych plików. Za pomocą polecenia ./target/release/chainsaw search 'xmax' --skip-errors ../htb/Logs --timestamp 'Event.System.TimeCreated_attributes.SystemTime' --from "2023-12-13T09:24:23" znalazłem listę plików, które zostały zaszyfrowane, oraz identyfikator procesu odpowiedzialnego za szyfrowanie (Rys. 13).

Rys. 13. Identyfikator procesu, który zaszyfrował pliki.
Rys. 13. Identyfikator procesu, który zaszyfrował pliki.

Odpowiedź: 5828