HTB Sherlock - Jinkies Writeup

Scenariusz Zadania

Jesteś zewnętrznym konsultantem ds. reagowania na incydenty, a twój menedżer właśnie przekazał ci sprawę od małego startupu o nazwie Cloud-guru-management Ltd. Obecnie budują produkt ze swoim zespołem deweloperów, ale CEO otrzymał informacje ustne, że ich własność intelektualna została skradziona i jest używana gdzie indziej. Użytkowniczka, o której mowa, twierdzi, że mogła przypadkowo udostępnić swój folder Dokumenty i uważa, że atak miał miejsce 6 października. Użytkowniczka również stwierdza, że w tym dniu była z dala od swojego komputera. Firma nie dostarczyła więcej informacji poza tymi. Rozpoczęto dochodzenie w celu ustalenia przyczyny potencjalnej kradzieży w Cloud-guru; jednak zespół nie zdołał odkryć przyczyny wycieku. Zebrali pewne wstępne dowody, które masz przejrzeć za pomocą triage KAPE. To od ciebie zależy, aby odkryć, jak doszło do tego wszystkiego. Ostrzeżenie: Ta sprawa wymaga elementu OSINT i gracze będą musieli korzystać z usług stron trzecich w internecie.

(ang. You’re a third-party IR consultant and your manager has just forwarded you a case from a small-sized startup named cloud-guru-management ltd. They’re currently building out a product with their team of developers, but the CEO has received word of mouth communications that their Intellectual Property has been stolen and is in use elsewhere. The user in question says she may have accidentally shared her Documents folder and they have stated they think the attack happened on the 6th of October. The user also states she was away from her computer on this day. There is not a great deal more information from the company besides this. An investigation was initiated into the root cause of this potential theft from Cloud-guru; however, the team has failed to discover the cause of the leak. They have gathered some preliminary evidence for you to go via a KAPE triage. It’s up to you to discover the story of how this all came to be. Warning: This sherlock requires an element of OSINT and players will need to interact with 3rd party services on internet.)

Artefakty

Po rozpakowaniu pobranego pliku zip mamy dwa katalogi: LiveResponse i TriageData, w których znajduje się łącznie 3104 plików (Rys 1).

W katalogu LiveResponse znajdują się logi, m.in. ze zrzutów procesów otwartych portów oraz kopia rejestru systemu (Rys 2).

W katalogu TriageData znajduje się kopia plików ze skompromitowanego systemu (Rys 3).

Rozwiązanie

Zadanie 1

Które foldery były udostępnione na hoście? (Proszę podać odpowiedź oddzielając foldery przecinkami, w następujący sposób: c:\program files\share1, D:\folder\share2) (ang. Which folders were shared on the host? (Please give your answer comma separated, like this: c:\program files\share1, D:\folder\share2))

Po przejrzeniu plików dostarczonych do rozwiązania zadania wiem, że system operacyjny to Windows. W systemie Windows ustawienia dotyczące udostępniania katalogów znajdują się w rejestrze pod kluczem HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares. Po wykonaniu polecenia grep -Fir "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares" w katalogu LiveResponse znalazłem kilkanaście wpisów w rejestrze oraz informację na temat wartości, których powinienem szukać (Rys. 4). Po dodaniu kolejnego polecenia grep otrzymałem listę wszystkich udostępnianych zasobów, czyli: C:\Users oraz C:\Users\Velma\Documents (Rys. 5).

Odpowiedź: C:\Users\Velma\Documents, C:\Users

Zadanie 2

Jaki plik dał atakującemu dostęp do konta użytkownika? (ang. What was the file that gave the attacker access to the users account?)

Poszukiwania za pomocą narzędzia chainsaw nie przyniosły żadnych efektów, dlatego wróciłem do przeglądania katalogów. Oczywiste dla mnie było, że atakujący pobrał plik z katalogu domowego użytkownika Velma. Interesującym katalogiem był jej projekt znajdujący się w C/users/Velma/Documents/Python Scripts + things, więc od tego rozpocząłem przeszukiwania. Najprostsze metody zawsze są najlepsze. Po wykonaniu polecenia grep -r password . moją uwagę zwrócił pierwszy plik na liście (Rys. 6). Okazało się, że jest to plik IBD, czyli tabela MySQL utworzona przez silnik bazy danych InnoDB.

Odczytanie zawartości pliku potwierdziło moje znalezisko — był to ważny plik zawierający hasła i adresy mailowe użytkowników (Rys. 7).

Odpowiedź: bk_db.ibd

Zadanie 3

Ile danych uwierzytelniających użytkowników znaleziono w pliku? (ang. How many user credentials were found in the file?)

Za pomocą polecenia strings "./web server project/testing/logon website/bk/bk_db.ibd" | grep @ | wc -l policzyłem wszystkie wystąpienia adresów e-mail, co było jednoznaczne z liczbą zawartych haseł w pliku (Rys. 8).

Odpowiedź: 216

Zadanie 4

Jaki jest hash NT hasła użytkownika? (ang. What is the NT hash of the users password?)

W dostępnych plikach zauważyłem, że mam plik SAM. Wyciągnięcie hashy haseł z bazy SAM jest możliwe za pomocą skryptu secretsdump z pakietu impacket. Korzystając z polecenia impacket-secretsdump -sam TriageData/C/Windows/system32/config/SAM -system TriageData/C/Windows/system32/config/SYSTEM LOCAL, wyświetliłem wszystkie hashe. Dla użytkownika Velma hash NT to 967452709ae89eaeef4e2c951c3882ce (Rys. 9).

Odpowiedź: 967452709ae89eaeef4e2c951c3882ce

Zadanie 5

Czy to hasło pasuje do tego znalezionego w poprzednim pliku? (Tak lub Nie) (ang. Does this password match that found in the previous file? (Yes or No))

Wróciłem do pliku bk_db.ibd i za pomocą polecenia strings "./web server project/testing/logon website/bk/bk_db.ibd" | grep -i Velma wyszukałem hasło użytkownika. Okazało się, że jest to peakTwins2023fc (Rys. 10).

Następnie za pomocą CyberChef obliczyłem skrót NT hasła (Rys. 11). Jak widać, jest to to samo hasło.

Odpowiedź: Yes

Zadanie 6

O której godzinie atakujący po raz pierwszy interaktywnie zalogował się na komputer użytkownika? (ang. What was the time the attacker first interactively logged on to our users host?)

Po zdobyciu loginu i hasła atakujący zalogował się zdalnie na maszynę za pomocą protokołu RDP. Szukam więc zdarzenia nr 4624. Typ logowania, jaki mnie interesuje, to 3 - czyli udane logowanie użytkownika poprzez sieć. Za pomocą polecenia chainsaw search -t 'Event.System.EventID: =4624' -t 'Event.EventData.LogonType: =3' ../htb/TriageData/C/Windows/system32/winevt/ --skip-errors otrzymałem 3 wyniki. Ostatni otrzymany wynik okazał się prawidłowy (Rys. 12).

Odpowiedź: 2023-10-06 17:17:23

Zadanie 7

Jakie jest pierwsze polecenie, które atakujący wydał w wierszu poleceń? (ang. What’s the first command the attacker issues into the Command Line?)

Za pomocą polecenia chainsaw search --timestamp 'Event.System.TimeCreated_attributes.SystemTime' --from "2023-10-06T17:17:23" --skip-errors "cmd.exe" ../htb/TriageData/C/Windows/system32/winevt/ wyszukałem wszystkich zdarzeń, które zawierają cmd.exe oraz wydarzyły się po poprawnym zalogowaniu atakującego. Już drugi event na liście wskazał mi polecenie, jakie zostało przez niego wykonane (Rys. 13).

Odpowiedź: whoami

Zadanie 8

Jak nazywa się plik, który ukradł atakujący? (ang. What is the name of the file that the attacker steals?)

Przeszukując listę wykonanych poleceń po 2023-10-06T17:17:23, jedynym plikiem, do którego odwołał się atakujący, jest Version-1.0.1 - TERMINAL LOGIN.py (Rys 14). Atakujący wyświetlił go w edytorze. Patrząc na treść następnego zadania, transfer pliku prawdopodobnie wykonał za pomocą przeglądarki oraz metody kopiuj-wklej.

Odpowiedź: Version-1.0.1 - TERMINAL LOGIN.py

Zadanie 9

Jaka jest nazwa domeny lokalizacji, do której atakujący wyeksfiltrował plik? (ang. What’s the domain name of the location the attacker ex-filtrated the file to?)

Atakujący do transferu danych wykorzystał przeglądarkę użytkownika. Dlatego od razu rozpocząłem przeszukiwanie historii przeglądarki. W pliku TriageData/C/Users/Velma/AppData/Local/Google/Chrome/User Data/Default/History w tabeli url zauważyłem następujące wpisy (Rys. 13). Wygląda na to, że atakujący przesłał plik na pastes.io.

Odpowiedź: pastes.io

Zadanie 10

Jakie jest pseudonim atakującego? (ang. What is the handle of the attacker?)

Z treści zadania dowiedziałem się, że atakujący musiał zostawić jakiś plik w systemie, w którym zawarł swój podpis. Wcześniej zauważyłem, że w artefaktach znajduje się zrzut MFT (ang. Master File Table). Stwierdziłem, że będzie to dobry punkt do rozpoczęcia poszukiwań. Dlatego najpierw wykonałem polecenie MFTECMD.exe -f "$MFT" --csv . --csvf mft.csv, aby przekonwertować wpis do postaci zdarzeń. Następnie otworzyłem plik mft.csv w TimeLine Explorer. Do poszukiwania pliku przyjąłem następujące założenia: plik musiał być utworzony po czasie zalogowania się atakującego na maszynę, prawdopodobnie jest to plik tekstowy .txt i musi znajdować się gdzieś w widocznym miejscu w katalogu domowym użytkownika Velma. Dodatkowo, aby możliwe było odczytanie jego zawartości, plik musi być mniejszy niż 600 bajtów. Pierwszym plikiem, który spełniał te kryteria, był learn.txt w lokalizacji C:\Users\Velma\Pictures\ (Rys. 16).

Zdecydowałem się sprawdzić jego zawartość za pomocą oprogramowania MFT Explorer. Był to strzał w dziesiątkę. Zawartość pliku lol check your drivers next time idiot, podpisana pwnmaster12, jednoznacznie wskazała, że jest to plik utworzony przez atakującego (Rys. 17).

Odpowiedź: pwnmaster12