HTB Sherlock - Lockpick4.0 Writeup

Scenariusz Zadania

Dział wsparcia IT firmy Forela.org otrzymał zgłoszenia od pracowników, którzy doświadczali nietypowego zachowania na swoich systemach Windows. W ciągu 30 minut liczba dotkniętych systemów wzrosła drastycznie, a pracownicy nie mogli uzyskać dostępu do swoich plików ani uruchomić kluczowych aplikacji biznesowych. Na wielu ekranach pojawiła się złowroga notatka z żądaniem okupu, wzywająca użytkowników do kontaktu z działem obsługi klienta grupy ransomware. Stało się jasne, że Forela.org była pod dużym atakiem ransomware. Jako członek zespołu reagowania na incydenty (IR) Forela.org, otrzymałeś krytyczne zadanie. Utworzono dla Ciebie zgłoszenie, aby przeanalizować ransomware, które skompromitowało systemy Windows Forela.org. Twoim celem jest pełne zrozumienie możliwości ransomware i wyodrębnienie wszelkich wskaźników kompromitacji (IOCs), które można wprowadzić do narzędzi detekcyjnych organizacji, aby zapobiec dalszym infekcjom.

(ang. Forela.org’s IT Helpdesk has been receiving reports from employees experiencing unusual behaviour on their Windows systems. Within 30 minutes, the number of affected systems increased drastically, with employees unable to access their files or run essential business applications. An ominous ransom note appeared on many screens, asking the users to communicate with the ransomware group’s customer service department. It became apparent that Forela.org was under a significant ransomware attack. As a member of Forela.org’s Incident Response (IR) team, you have been assigned a critical task. A ticket has been created for you to reverse engineer the ransomware that has compromised Forela.org’s Windows systems. Your objective is to fully understand the ransomware’s capabilities and extract any Indicators of Compromise (IOCs) to feed into the organisation’s detection tools, preventing further infection.)

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,
• malware.zip - archiwum zawierające malware, które mamy przeanalizować w celu rozwiązania zadania.

  

  Po rozpakowaniu archiwum malware.zip otrzymujemy tylko jeden plik defenderscan.vhdx. Pliki z rozszerzeniem vhdx są obrazami wirtualnych dysków twardych wykorzystywanych przez technologię Hyper-V (Rys. 2).

  

  Za pomocą oprogramowania SysTools VHDX Viewer w pierwszej kolejności podejrzałem zawartość pliku. Dzięki temu udało mi się uzyskać również podpowiedź do zadania nr 1, czyli który plik został stworzony jako pierwszy po wykonaniu złośliwego skryptu defenderscan.js (Rys. 3).

  

  W dalszej kolejności musiałem wyodrębnić wszystkie pliki w celu ich dalszej analizy. Za pomocą polecenia qemu-img convert -f vhdx -O raw defenderscan.vhdx defenderscan.raw przekonwertowałem plik, a następnie za pomocą FTK Imager wyeksportowałem pliki (Rys. 4 i 5).

  

  

Od tej pory mogłem rozpocząć analizę złośliwego oprogramowania i zacząć odpowiadać na przygotowane pytania.

Rozwiązanie

Zadanie 1

Jaki jest skrót MD5 pierwszego pliku, który ransomware zapisuje na dysku?

(ang. What is the MD5 hash of the first file the ransomware writes to disk?)

Dzięki temu, że w pierwszej kolejności podejrzałem zawartość pliku defenderscan.vhdx za pomocą SysTools VHDX Viewer, otrzymałem informacje o czasie utworzenia plików w systemie. Pierwszym utworzonym plikiem był defenderscan.js, który po uruchomieniu stworzył plik redbadger.webp, a następnie pozostałe pliki (Rys. 6).

Po wykonaniu polecenia md5sum redbadger.webp otrzymałem poszukiwaną sumę kontrolną MD5 (Rys. 7).

Odpowiedź: 2c92c3905a8b978787e83632739f7071

Zadanie 2

Jaki ciąg znaków ransomware używa do sprawdzenia uprawnień lokalnego administratora?

(ang. What is the string that the ransomware uses to check for local administrator privileges?)

Plik defenderscan.js (Rys. 8) zawiera kod JavaScript, który wykorzystuje ActiveXObject do operacji na plikach i uruchamiania złośliwego skryptu PowerShell. W pierwszej kolejności tworzony jest plik redbadger.webp, zakodowany w zmiennej b64img, który jest zwykłym obrazkiem i który otrzymałem już we wcześniejszym kroku analizy. Znacznie ważniejsza jest zmienna b64s, która zawiera zakodowany skrypt PowerShell. Skrypt dekoduje tę zawartość, a następnie zapisuje ją do tymczasowego pliku wraz z informacjami o aktualnej ścieżce i nazwie pliku. Kod ten uruchamia PowerShell z opcją -ExecutionPolicy Bypass, co pozwala obejść zabezpieczenia systemu i wykonać złośliwy skrypt. Po zakończeniu, tymczasowy plik jest usuwany.

Jak już wcześniej wspomniałem, po zdekodowaniu zmiennej b64s otrzymujemy skrypt PowerShell, który okazuje się nie być obfuskowany. Co więcej, jest napisany z humorem – zmienne i opisy wybrane przez atakującego pochodzą ze świata Tolkiena, a skrypt zawiera nawet komentarze. Jego analiza nie sprawia trudności, a po chwili zauważam komentarz: „Sprawdź, czy użytkownik znajduje się w grupie lokalnych Administratorów, szukając dobrze znanego SID dla grupy Administratorów (S-1-5-32-544)” (ang. Check if the user is in the local Administrators group by looking for the well-known SID for the Administrators group (S-1-5-32-544)), który jasno informuje mnie, w jaki sposób skrypt sprawdza uprawnienia lokalne administratora (Rys. 9).

Odpowiedź: S-1-5-32-544

Zadanie 3

Jaki jest identyfikator MITRE ATT&CK dla techniki używanej przez atakującego do podniesienia uprawnień?

(ang. What is the MITRE ATT&CK ID for the technique used by the threat actor to elevate their privileges?)

Na samym końcu skryptu znajduje się interesująca nas część, która przedstawia kolejność wywołań. Na początku sprawdzany jest warunek wywołujący funkcję Test-HobbitInCouncil, która weryfikuje, czy użytkownik ma uprawnienia administratora lokalnego. Jeśli nie, uruchamiana jest funkcja Bypass-GondorGate, odpowiedzialna za podniesienie uprawnień (Rys. 10).

Funkcja Bypass-GondorGate (Rys. 11) wykorzystuje narzędzie cmstp.exe do obejścia zabezpieczeń systemowych w celu uruchomienia złośliwego procesu. Najpierw tworzy plik konfiguracyjny o nazwie ScrollOfEru.inf w katalogu tymczasowym i przypisuje do niego lokalizację. Następnie, za pomocą obiektu System.Diagnostics.ProcessStartInfo, konfiguruje i uruchamia cmstp.exe z odpowiednimi argumentami, które korzystają z tego pliku konfiguracyjnego. Funkcja czeka na zakończenie procesu i wysyła naciśnięcie klawisza ENTER za pomocą SendKeys, aby zakończyć interakcję z wywołanym oknem.

Odnalezienie techniki MITRE ATT&CK dla wyżej opisanego skryptu było bardzo proste. Wystarczyło wpisać frazę MITRE ATT&CK cmstp.exe, aby natychmiast uzyskać odpowiedź (Rys. 12).

Odpowiedź: T1218.003

Zadanie 4

Ransomware uruchamia proces przy użyciu podpisanego binarnego pliku. Jakie jest pełna nazwa podpisującego?

(ang. The ransomware starts a process using a signed binary, what is the full name of the signer?)

Wracając do części głównej skryptu (Rys. 10), jeśli użytkownik posiada uprawnienia lokalnego administratora, skrypt próbuje przejść do kolejnej fazy, wykorzystując procesy i pliki związane z usługami systemowymi, aby ukryć swoje działanie. W liniach 138-141 znajdują się nazwy plików zakodowane w Base64, które odnoszą się do komponentów związanych z oprogramowaniem antywirusowym. Następnie skrypt dodaje wyjątki do ustawień antywirusa i próbuje uruchomić złośliwe oprogramowanie za pomocą msmpeng.exe i biblioteki mpsvc.dll (Rys. 13).

Oba te pliki udało mi się pozyskać na początku procesu, dlatego wystarczyło podejrzeć właściwości pliku msmpeng.exe, aby zidentyfikować nazwę podmiotu podpisującego plik (Rys. 14).

Odpowiedź: Microsoft Corporation

Zadanie 5

Jaki jest punkt wejścia dla końcowego ładunku ransomware?

(ang. What is the final payloads’ entry point function?)

Aby zbadać dalsze fazy uruchamiania złośliwego oprogramowania, skorzystałem z Ghidra. Z poprzedniego zadania wiem, że biblioteka jest uruchamiana poprzez plik msmpeng.exe. Dlatego w pierwszej kolejności podejrzałem jego zawartość. Plik wykonywalny wywołuje tylko jedną funkcję, ServiceCrtMain, która jest importowana z biblioteki mpsvc.dll (Rys. 15).

Odpowiedź: ServiceCrtMain

Zadanie 6

Ile technik antydebugowania implementuje ransomware i jaka funkcja API Windows jest używana przez końcową technikę?

(ang. How many Anti-Debugging techniques does the ransomware implement and what is the Windows API function that the final technique leverages?)

Przyszedł czas na analizę statyczną pliku mpsvc.dll. Za pomocą Ghidra wczytałem plik i odszukałem funkcję ServiceCrtMain. Na początku tej funkcji zainicjowanych jest wiele zmiennych. Pierwszą metodą wykorzystywaną przez oprogramowanie jest IsDebuggerPresent (Rys. 16), która sprawdza, czy program jest uruchamiany w debugerze. W przypadku wykrycia debugera program przerywa swoje działanie. Następnie, przy pomocy funkcji CreateToolhelp32Snapshot, Process32FirstW i Process32NextW, analizowane są procesy uruchomione w systemie. Aplikacja sprawdza, czy w systemie działa proces o tej samej nazwie co aktualny proces, oraz czy istnieje proces powershell.exe. Jeśli proces powershell.exe nie zostanie znaleziony, program również kończy działanie. Ostatni mechanizm obronny znajduje się w wywołaniu funkcji FUN_180001ebd0.

Funkcja FUN_180001ebd0 rejestruje niestandardowy filtr wyjątków za pomocą SetUnhandledExceptionFilter, a następnie wywołuje instrukcję swi(3), która sygnalizuje przerwanie w przypadku wystąpienia błędu (Rys. 17).

Odpowiedź: 3, SetUnhandledExceptionFilter

Zadanie 7

Ransomware celuje w pliki o określonych rozszerzeniach. Jaka jest lista rozszerzeń, w kolejności, w jakiej są przechowywane w konfiguracji ransomware?

(ang. The ransomware targets files with specific extensions, what is the list of extensions targeted in the exact order as the ransomware configuration stores them?)

Z analizy statycznej nie udało mi się uzyskać więcej informacji, dlatego w kolejnym kroku zdecydowałem się na analizę dynamiczną. W tym celu przygotowałem maszynę w VirtualBox z systemem Windows 10, skonfigurowaną z FlareVM.

Warto podkreślić, że wszystkie dalsze kroki wykonywałem na odizolowanej maszynie, na której wyłączyłem funkcje takie jak kopiowanie schowków czy udostępnianie plików. Jest to niezwykle istotne na tym etapie, ponieważ analizowane oprogramowanie to prawdziwy ransomware. Dzięki temu, że prowadziłem analizę na maszynie wirtualnej i miałem przygotowane kopie zapasowe, uniknąłem przypadkowego zaszyfrowania dysku. Co ciekawe, to właśnie przypadkowe zaszyfrowanie dostarczyło mi odpowiedzi na ostatnie pytania :)

Do dalszej analizy złośliwego oprogramowania wykorzystałem x64dbg. Na podstawie wcześniejszych ustaleń z mojej analizy, najpierw wczytałem rundll32.exe, a następnie skonfigurowałem automatyczne breakpointy, tak aby debuger zatrzymywał się w momencie ładowania pliku mpsvc.dll (Rys. 18).

Następnie zmodyfikowałem linię poleceń odpowiedzialną za uruchomienie programu, ustawiając ją na C:\Windows\System32\rundll32.exe C:\Users\michal\Desktop\mpsvc.dll,ServiceCrtMain (Rys. 19).

Gdy debuger zatrzymał się na breakpoincie podczas ładowania złośliwej biblioteki, mogłem przejść do zakładki symboli i wyszukać główną funkcję ServiceCrtMain, aby ustawić na niej kolejny breakpoint (Rys. 20).

Kiedy znalazłem się w odpowiednim miejscu kodu, ustawiłem kolejny breakpoint, tym razem na wywołaniu funkcji IsDebuggerPresent (Rys. 21).

Kiedy dotarłem do wywołania funkcji IsDebuggerPresent, wybrałem w debugerze opcję “step over”, czyli wykonanie instrukcji bez śledzenia jej działania. Kolejną instrukcją była test eax, eax, która porównuje wartość rejestru eax z samym sobą, wykonując operację logiczną AND, i na podstawie wyniku ustawia odpowiednie flagi procesora. Następnie instrukcja JNE sprawdza wartość flagi ZF (Zero Flag) i wykonuje skok, jeśli ZF jest równe 0. x64dbg oferuje przydatną funkcję pokazującą, gdzie nastąpi skok. Zmieniając wartość ZF z 0 na 1, zmieniłem przebieg programu, omijając instrukcję skoku, co pozwoliło pominąć pierwsze zabezpieczenie programu (Rys. 22).

Czas na kolejne zabezpieczenie. Zaraz po wywołaniu funkcji CreateToolhelp32Snapshot wywoływana jest instrukcja asemblera CMP, która porównuje wartość rejestru rax z oczekiwaną wartością -1. Choć CreateToolhelp32Snapshot zwraca uchwyt do listy procesów, to zmiana flagi ZF dla instrukcji JE ponownie pozwoliła mi zmienić przebieg programu i pominąć drugie zabezpieczenie. Instrukcja JE wykonuje skok, jeśli flaga ZF jest ustawiona na 1. W tym przypadku zmieniłem wartość ZF z 0 na 1, co umożliwiło pominięcie kolejnego zabezpieczenia (Rys. 23).

Ku mojemu zaskoczeniu, nie musiałem omijać trzeciego zabezpieczenia. Po kilkukrotnym naciśnięciu opcji “step over” w debugerze, w oknie stosu pojawiło się pierwsze rozszerzenie plików, które były celem ransomware (strzałka nr 1 na rysunku 23). Następnie, po wybraniu opcji “Follow QWORD in Current Dump” (strzałka nr 2), w oknie zrzutu pamięci (strzałka nr 3) wyświetliła się cała lista rozszerzeń plików, które ransomware zamierza zaszyfrować.

Odpowiedź: .doc, .docx, .xls, .xlsx, .ppt, .pptx, .pdf, .txt, .csv, .rtf

Zadanie 8

Jaki jest FQDN serwera ransomware, z którym łączy się malware?

(ang. What is the FQDN of the ransomware server the malware connects to?)

Aby znaleźć FQDN, z którym łączy się złośliwe oprogramowanie, musiałem najpierw zidentyfikować miejsce, w którym nawiązywane jest połączenie lub konfigurowane są ustawienia. Dzięki temu, że spędziłem dużo czasu na poszukiwaniu odpowiedzi podczas analizy statycznej, miałem już dobrą orientację w kodzie. W trakcie tej analizy zauważyłem wykorzystanie biblioteki WINHTTP.dll oraz funkcji takich jak WinHttpConnect (Rys. 25).

Zanim przystąpiłem do analizy dynamicznej, musiałem zlokalizować, gdzie dokładnie wywoływana jest ta funkcja i jakie są odpowiednie opkody. Po przeszukaniu kodu okazało się, że funkcja WinHttpConnect jest wywoływana tylko raz, w głównej funkcji ServiceCrtMain (Rys. 26).

Od tego momentu było już znacznie łatwiej. Manipulując instrukcjami skoku, jak opisałem wcześniej, kontrolowałem przebieg programu, aby dotrzeć do wywołania funkcji WinHttpConnect. Pomijając fakt, że kilka razy przypadkowo zaszyfrowałem dysk, co dostarczyło mi odpowiedzi na dwa ostatnie pytania, w końcu udało mi się dotrzeć do właściwego miejsca w pamięci i uzyskać adres FQDN, z którym łączy się ransomware (Rys. 27).

Odpowiedź: api.ltchealthcare.co

Zadanie 9

Jaki jest identyfikator MITRE ATT&CK, który ransomware wykorzystuje do uruchomienia końcowego ładunku?

(ang. What is the MITRE ATT&CK ID the ransomware uses to run its final payload?)

Znając już sposób, w jaki plik msmpeng.exe wczytuje bibliotekę mpsvc.dll, tylko jedna technika MITRE ATT&CK nasuwa się na myśl (Rys. 28).

Odpowiedź: T1574.002

Zadanie 10

Jaki jest pełny adres URL, łącznie z numerem portu, portalu obsługi klienta grupy ransomware?

(ang. What is the full URL including port number of the ransomware groups customer service portal?)

Tak jak wspomniałem wcześniej, ponieważ mam do czynienia z rzeczywistym oprogramowaniem ransomware, nieodpowiednie sterowanie w pewnym momencie doprowadziło do zaszyfrowania plików na maszynie wirtualnej. Jednak dzięki temu przypadkowemu incydentowi udało mi się uzyskać odpowiedź na dwa ostatnie pytania (Rys. 29).

Odpowiedź: yrwm7tdvrtejpx7ogfhax2xuxkqejp2qjb634qwwyoyabkt2eydssrad.onion:9001

Zadanie 11

Jaki jest rozszerzenie pliku używane do przechowywania nowo zaszyfrowanych plików?

(ang. What is the file extension used to store the newly encrypted files?)

Z poprzedniego zadania.

Odpowiedź: .evil