„The Game” na TryHackMe to proste zadanie polegające na zhakowaniu kopii Tetrisa zrobionej na silniku Godot. Niestety, dostępna jest jedynie wersja na Windowsa.
Jeżeli nigdy wcześniej nie miałeś styczności z cheatowaniem, czy też hakowaniem gier, to jest to świetny pokój na początek :)
Zrzut ekranu przedstawiający okno gry
Znalazłem dwa banalne rozwiązania.
Rozwiązanie klasyczne
Pierwsze co rzuciło mi się w oczy to cel gry: Score more than 999 999 – „Zdobądź więcej niż 999 999 punktów”. Używając (chyba) najbardziej znanego edytora pamięci, jakim jest Cheat Engine, przyznałem sobie adekwatną ilość punktów.
Wybacz moje okropne umiejętności grania w Tetrisa :(
Na początku przeskanowałem pamięć procesu, żeby znaleźć wszystkie 32-bitowe (4-bajtowe – rozmiar zgadywałem) wartości równe 0.
Po zdobyciu 100 punktów, ponownie przeszukałem pamięć. Na tym etapie Cheat Engine nie przeszukuje całej pamięci, tylko sprawdza, które znalezione wcześniej adresy mają wartość, którą wskazaliśmy.
Na końcu został mi jeden adres, mający wartość 200, którą zmieniłem na 999 999. Kolejne 100 punktów przeniosło mnie nad próg wymagany przez grę, dzięki czemu dostałem flagę.
Rozwiązanie „meta”
Znaczna większość flag w pokojach na TryHackMe (pewnie jakieś 99,99%) jest w następującym formacie:
THM{....................}
Zakładając, że autor gry nie zaszyfrował flagi, możemy przeskanować pamięć aplikacji właśnie pod kątem ciągu znaków. Na szczęście Cheat Engine to obsługuje:
Zrzut ekranu przedstawiający okno gry i programu Cheat Engine. Wyszukany string THM{.
Po ustawieniu kodowania na UTF-16, Cheat Engine znalazł dwa miejsca, w których znajduje się ciąg znaków o przedrostku THM{.
Wyświetlając region pamięci, w którym znajduje się którykolwiek z adresów, możemy odczytać całą flagę – bez grania w Tetrisa:
Zrzut ekranu przedstawiający opcję, która umożliwia wyświetlenie region pamięci wokół adresu.Zrzut ekranu przedstawiający region pamięci i ocenzurowaną flagę.
Zadanie 7 w CTFie Honeynet Collapse to trudniejsza wersja zadania 6. Było ono bardziej skupione na analizie systemu plików, a nie artefaktów samego Windowsa.
Tutaj również mieliśmy obraz dysku, tylko że niekompletny. Dostępne były jedynie pliki systemowe NTFS (tablica MFT, pliki dziennika USNJournal itd.).
Otrzymany obraz to obraz dysku kontrolera domeny po ataku ransomware.
Pytania 1., 2. i 4. — pobranie ransomware-u
Poziom trudności: łatwy 🟢, łatwy 🟢 i średni 🟡
Liczba punktów: 30, 30 i 60
Treść (1): Jaki jest pełny adres URL, z którego pobranezostało oprogramowanie ransomware?
Treść (2): Jaka była oryginalna nazwa pliku wykonywalnego oprogramowania ransomware pobranego na host?
Treść (4): Jakie rozszerzenie pliku zostało dodane do zaszyfrowanych plików?
Szczerze mówiąc nie byłem pewien jak do tego podejść, ale na szczęście nie miałem zbyt wielu opcji. Wyeksportowałem plik $MFT, który jest tablicą wszystkich plików w systemie NTFS:
Następnie użyłem narzędzia MFTECmd autorstwa Erica Zimmermana do sparsowania tablicy MFT:
C:\Users\bonk\Desktop\net9>MFTECmd.exe -f $MFT --csv dc --csvf mft.csv
MFTECmd version 1.3.0.0
Author: Eric Zimmerman (saericzimmerman@gmail.com)
https://github.com/EricZimmerman/MFTECmd
Command line: -f $MFT --csv dc --csvf mft.csv
Warning: Administrator privileges not found!
File type: Mft
Processed $MFT in 10,4956 seconds
$MFT: FILE records found: 500 382 (Free records: 235 248) File size: 718,5MB
Path to dc doesn't exist. Creating...
CSV output will be saved to dc\mft.csv
Otworzyłem plik w TimelineExplorerze (również autorstwa Zimmermana) i zacząłem plików mających Downloads w nazwie ścieżki.
Bardzo szybko znalazłem kilka podejrzanych plików, które miały przypisane metadane dotyczące pochodzenia pliku — a w nim szukany adres URL (odpowiedź na pierwsze pytanie):
W pobliżu pobranego HiddenFile.zip znajdował się również plik wykonywalny (odpowiedź na drugie pytanie):
Na tym samym zrzucie ekranu widać również dodawane do zaszyfrowanych plików przez program pięcioliterowe rozszerzenie (złożone z samych liter) — odpowiedź na czwarte pytanie.
Pytanie 3. — plik szyfrujący
Poziom trudności: średni 🟡
Liczba punktów: 60
Treść: Który plik wykonywalny zainicjował proces szyfrowania w systemie?
Znaleziony przeze mnie dwuliterowy plik nie był tym, który zaszyfrował wszystkie pliki. Był jedynie stubem, który pobierał prawdziwe oprogramowanie ransomware.
Zanotowałem datę i czas ostatniego dostępu do stuba (2025-07-04 11:35:36), usunąłem filtr i posortowałem wszystkie pliki po dacie utworzenia.
Szukałem utworzonych plików po tym czasie i bardzo szybko znalazłem plik w podejrzanej ścieżce C:\DeceptiFiles\Deployment\Agents, który został utworzony około dziewięć minut po uruchomieniu stuba:
Nazwa tego pliku była odpowiedzią na pytanie trzecie!
Pytanie 5. — nazwa grupy ransomware-owej
Poziom trudności: trudny 🔴
Liczba punktów: 120
Treść: Wyjdź poza oczywiste wnioski – która grupa ransomware zaatakowała organizację?
Zadanie piąte jako jedyne w całym CTFie opierało się na OSINT-cie. Miałem znaleźć nazwę grupy odpowiedzialnej za atak ransomware przeprowadzony na analizowanym kontrolerze domen.
Nie miałem dostępu do plików na dysku, ale pamiętałem, że w opisie zadania autorzy zamieścili ocenzurowaną wersję wiadomości od grupy:
Postanowiłem, że dalsze przeszukiwanie pliku $MFT nie ma sensu i wklepałem w Google (DuckDuckGo nie zwróciło żadnych wyników) widoczny dopisek do URLa pierwszej strony (f8cef2c0f8fd):
Jedynym wynikiem był wpis ze strony tria.ge, na której była dostępna nieocenzurowana wersja wiadomości:
Po wklejeniu adresu bloga w przeglądarkę TOR, otrzymałem odpowiedź na pytanie piąte:
Pytanie 6. — dodatkowe instrukcje
Poziom trudności: bonus 🌟
Liczba punktów: 25
Treść: Jaka jest nazwa pliku zawierającego dodatkowe instrukcje dotyczące okupu dla ofiary?
Okazało się, że na dysku znajdował się jeszcze jeden plik z instrukcjami. Na szczęście nie zamknąłem jeszcze wtedy okna TimelineExplorera i po zjechaniu w dół listy o centymetr, znalazłem odpowiedź:
Po analizie zrzutu pamięci RAM Honeynet Collapse miało dla mnie zadanie 6. Polegało ono na analizie obrazu dysku serwera Windows. W trakcie ataku logi zdarzeń zostały usunięte, więc musiałem polegać wyłącznie na narzędziach EZ-Tools.
Pytanie 1. — konto ofiary
Poziom trudności: łatwy 🟢
Liczba punktów: 30
Treść: Które konto domenowe zostało użyte do zainicjowania zdalnej sesji na hoście?
W tym zadaniu miałem znaleźć konto, którego użył atakujący do początkowego połączenia do badanego serwera.
Nie będę ściemniał, to zadanie rozwiązałem w pięć sekund. Z opisu zadania wynika, że atakujący użył poświadczeń niejakiego Matthewsa: „[… ] the attacker had already slipped into the server with Matthew’s stolen credentials […]”.
A kogo hash NTLM skradliśmy w zadaniu czwartym? Właśnie jego! Oto wynik pypykatza z pytania bonusowego:
Odpowiedzią jest nazwa użytkownika (wartość po username).
Pytanie 2. — długość sesji PowerShell
Poziom trudności: średni 🟡
Liczba punktów: 60
Treść: Przez ile sekund atakujący utrzymywał aktywną sesję PowerShell?
Od najprostszego pytania w całym CTFie przechodzimy do (najwyraźniej) najtrudniejszego. Na Discordzie THM (hosta CTFa) dużo ludzi zgłaszało, że nie potrafiło znaleźć odpowiedzi.
Na myśl przyszedł mi klucz UserAssist w rejestrze, który przechowuje dane o uruchomionych programach oraz czasie focusowania okna. Wyeksportowałem plik NTUSER.DAT (UserAssist znajduje się w HKEY_CURRENT_USER) z katalogu Matthewsa. Dodatkowo wyeksportowałem logi transakcyjne, w razie gdyby NTUSER.DAT był oznaczony jako dirty:
Następnie otworzyłem plik NTUSER.DAT w programie Registry Explorer (również autorstwa Zimmermana). Logi okazały się niepotrzebne. Po otwarciu pliku wybrałem zakładkę UserAssist:
W wyświetlonej tabeli wybrałem sortowanie po nazwie programu i znalazłem PowerShella. Odczytałem wartość z kolumny Focus Time i zamieniłem wartość na całe sekundy:
Poniżej wpisu z PowerShellem widać również bardzo interesującą ścieżkę: C:\ProgramData\sync\7zz.exe.
Pytania 3., 4. i 5. — eksfiltracja danych
Poziom trudności: łatwy 🟢, średni 🟡 i trudny 🔴
Liczba punktów: 30, 60 i 120
Treść (1): Jaki był adres IP C2 używany przez atakującego do przygotowania ataku i eksfiltracji danych?
Treść (2): Jakiego znanego narzędzia użył atakujący do eksfiltracji danych?
Treść (3): Jakie jest „ukryte” hasło do kontrolowanego przez atakującego konta na serwisie Mega?
Po uporaniu się z najcięższym zadaniem z całego CTFa, musiałem znaleźć adres serwera C2 (Command and Control) użytego podczas ataku i eksfiltracji danych.
Oprócz wpisu PowerShella w UserAssist znalazłem również ścieżkę do folderu C:\ProgramData\sync. Znajdowały się w nim pliki potrzebne do odpowiedzi na trzy kolejne pytania:
W crmhttp.conf znajdował się adres serwera C2:
[crmremote]
type = webdav
url = http://xxx.yyy.zzz.ttt:8080
W mega.conf znajdowało się ukryte hasło do konta na Mega (swoją drogą w trakcie CTFa udało mi się znaleźć nieukryte hasło, gdzieś w logach poleceń):
[crmremote]
type = mega
user = harmlessuser98 <małpa> proton.me
pass = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Zostało jeszcze „trudne” pytanie dotyczące samego narzędzia. Ono również znajdowało się w katalogu sync, co prawda ze zmienioną nazwą (backup_win.exe) i pozornie usuniętą ikoną.
Pozornie, bo wystarczyło wyeksportować plik na pulpit: pojawiła się ikonka, a w szczegółach pliku było widać faktyczną nazwę programu (i to w kilku miejscach):
Pytanie 6. — email Lucasa
Poziom trudności: bonus 🌟
Liczba punktów: 25
Treść: Jaki jest adres email Lucasa znaleziony w eksfiltrowanych danych?
To było pierwsze pytanie, na które znalazłem odpowiedź. Po otworzeniu obrazu dysku od razu zauważyłem folder o wymownej nazwie Exfil_Temp, w którym znajdowały się dwa pliki CSV. W pliku Users_export.csv znajdował się email Lucasa:
Po analizie systemów na żywo w CTFie Honeynet Collapse czekało na mnie zadanie 5. Polegało na analizie zrzutu pamięci RAM serwera. Autorzy zadania użyli kilkunastu modułów frameworku Volatility i zapisali ich wyniki w plikach tekstowych.
Pytania 1., 2., 3. i 4. — złowrogi plik
Poziom trudności: łatwy 🟢, łatwy 🟢, średni 🟡 i średni 🟡
Liczba punktów: 30, 30, 60 i 60
Treść (1): Jaka jest bezwzględna ścieżka do początkowego złośliwego pliku uruchomionego na analizowanym hoście?
Treść (2): Który identyfikator procesu (PID) został przypisany do procesu użytego do wykonania początkowego ładunku?
Treść (3): Jakie było pełne polecenie użyte przez atakującego do uruchomienia początkowego wykonania na tym hoście?
Treść (4): Atak uruchomił różne procesy. Jak nazywa się ostatni proces w łańcuchu?
Zacząłem od analizowania wyjścia modułu windows.pstree, który wyświetla drzewko uruchomionych procesów w systemie.
Skróciłem wyjście niektórych modułów, żeby były bardziej czytelne.
Szybko rzucił mi się w oczy ciąg rozpoczynający się od PSEXESVC.exe.
Ktoś zdalnie uruchomił plik nazywający się… MicrosoftUpdate.dll, który znajdował się w katalogu… „Tasks„? Wygląda na to, że znaleźliśmy nasz złowrogi plik. Poza tym, zaczynając od modułu windows.pstree, znaleźliśmy odpowiedzi na cztery pozostałe pytania:
Tylko czemu proces zzzzzzz.exe jest tym ostatnim, skoro w drewku widać jeszcze cmd.exe? Z prostego powodu: proces 'z’ to bardzo popularne i proste narzędzie znajdujące się na każdym Windowsie. Z uwagi na to, że nie jest ono w stanie uruchamiać żadnych procesów samodzielnie, wywnioskowałem, że coś zmusiło ten proces do uruchomienia (i dlatego wybrałem z jako ostatni proces w pierwszej fazie ataku).
Pytanie 5. — shellcode
Poziom trudności: trudny 🔴
Liczba punktów: 120
Treść: Jakie jest pierwsze pięć bajtów (w systemie szesnastkowym, np. 4d5a9000) shellcodu Meterpreter wstrzykniętego do niego (procesu zzzzzzz.exe)?
W piątym pytaniu miałem znaleźć pierwsze pięć bajtu shellcodu Meterpretera wstrzykniętego w proces z. To wyjaśniałoby, jakim cudem proste narzędzie zaczęło uruchamiać inne programy. Meterpreter potrafi migrować do innych procesów — i tak najwyraźniej stało się w tym przypadku.
Do znalezenia shellcodu w z użyłem modułu windows.malware.malfind, który szuka podejrzanych segmentów w pamięci procesów.
W zapisanym wyjściu modułu znajdowały się dwa interesujące wyniki:
Pierwszy znaleziony fragment to malutki stub, ładujący większy kod. Ten większy kod również został wykryty przez moduł i to jest właśnie nasz drugi fragment. Zawiera on prawdziwy payload Meterpreter. Wystarczyło przekopiować pierwsze pięć bajtów: fc xx yy zz ee i… gotowe!
Pytanie 6. — ruch lateralny
Poziom trudności: bonus 🌟
Liczba punktów: 25
Treść: Który adres IP jest używany przez hosta do przeprowadzania ruchu lateralnego przy użyciu portu 3389?
W pytaniu bonusowym miałem znaleźć adres hosta, do którego atakujący podłączył się przez protokół RDP (port 3389).
W tym celu chciałem użyć modułu windows.netstat, ale nic w nim nie było (oprócz połączeń do portu 445). Z tego powodu rzuciłem okiem na windows.netscan, w którym było już o wiele więcej, w tym nasze szukane połączenie:
Volatility 3 Framework 2.26.0
Proto LocalAddr LocalPort ForeignAddr ForeignPort State PID Owner
Created
[...]
TCPv4 172.16.8.15 49750 xxx.yyy.zzz.ttt
3389 ESTABLISHED 464 powershell.exe
2025-07-02 01:08:25.000000 UTC
[...]
Wartość w kolumnie ForeignPort to 3389, więc nasz szukany adres to xxx.yyy.zzz.ttt (wartość kolumny ForeignAddr).
Następnym zadaniem w CTFie Honeynet Collapse było zadanie 4. Polegało ono na analizie śladów włamania na Windowsie.
Pytanie 1. — data dostępu przez RDP
Poziom trudności: łatwy 🟢
Liczba punktów: 30
Treść: Kiedy atakujący zalogował się do serwera za pomocą protokołu RDP?
Pierwsze pytanie polegało na znalezieniu daty i czasu logowania atakującego przez protokół RDP. Zacząłem od przeszukiwania logów zdarzeń z kategorii odpowiadającej RDP, korzystając z opisu zadania, który mówił, że połączenie przychodziło z adresu 172.16.8.239.
Zacząłem od przeszukiwania logów z TerminalServices-RemoteConnectionManager, wybierając jedynie zdarzenia o ID 1149 (pomyślne uwierzytelnienie w usłudze Zdalnego Pulpitu), znalazłem połączenie przychodzące z wcześniej wspomnianego adresu IP:
Odpowiedzią na pytanie była data i czas zdarzenia.
Pytanie 2. — podmieniony plik
Poziom trudności: łatwy 🟢
Liczba punktów: 30
Treść: Jaka jest pełna ścieżka do pliku binarnego zastąpionego w celu eskalacji uprawnień?
Z opisu zadania można było się dowiedzieć, że administratorka serwera zautomatyzowała okresowe sprawdzanie statusu systemu. Pierwsze co przyszło mi na myśl to sprawdzenie, czy atakujący nie podmienił plików służących temu zadaniu. Domyśliłem się, że stworzyła ona zadanie w harmonogramie zadań (taskschd.msc) — i tak właśnie było:
Wyświetlając szczegóły pliku od razu widać, że coś jest nie tak. Opis programu nie zgadza się z oczekiwanym. Czemu Coreinfo jest opisany jako serwer Apache? Tyle mi wystarczyło żeby wiedzieć, że to jest plik, który podmienił atakujący.
Pytanie 3. — co to za plik?
Poziom trudności: średni 🟡
Liczba punktów: 60
Treść: Jakiego rodzaju złośliwe oprogramowanie zawiera zastąpiony plik binarny?
Znaleźliśmy który to plik, ale pozostaje jeszcze się dowiedzieć, co on tak właściwie robi. To pytanie, rozwiązałem za pomocą VirusTotala. Wrzuciłem plik i od razu rzuciła mi się w oczy nazwa Meterpreter. Jest to wyjątkowo znany payload który daje szerokie możliwości interakcji z zainfekowanym systemem i pochodzi z frameworku Metasploit .
Odpowiedzią na pytanie była nazwa tego payloadu.
Odpowiedź dało się również znaleźć w logach PowerShella, znajdujących się w katalogu konta Administrator, ale do nich jeszcze przejdziemy.
Pytanie 4. — kradzież poświadczeń
Poziom trudności: średni 🟡
Liczba punktów: 60
Treść: Jakie pełne polecenie zostało użyte do zrzutu poświadczeń z systemu operacyjnego?
Po eskalacji uprawnień atakujący skradł poświadczenia dostępne w pamięci systemu operacyjnego. Musiałem znaleźć polecenie za pomocą którego wykonano zrzut.
W katalogu Dokumenty użytkownika Administrator został transkrypt PowerShella z dnia, w którym przeprowadzono atak na serwer.
Transkrypt zawierał polecenia zapisane w kodowaniu Base64. Po zdekodowaniu jednego z nich (przy użyciu CyberChefa) potwierdziła się odpowiedź z pytania trzeciego:
Pomijając długi bootstrap Meterpretera, na końcu transkryptu znajdują się znacznie krótsze logi. Pierwszy z nich wygląda interesująco:
*****.exe /accepteula -ma lsass.exe text.txt
Po samej obecności nazwy lsass.exe od razu wiedziałem, że znalazłem odpowiedź. LSASS odpowiada za lokalne uwierzytelnianie użytkowników i zawiera hashe NTLM zalogowanych użytkowników (nawet domenowych).
Z otrzymanego zrzutu pamięci atakujący był w stanie wyeksportować hashe i za ich pomocą przeprowadzić atak Pass—the—Hash, którego ślady szukałem w następnym pytaniu.
Pytanie 5. — Pass-The-Hash
Poziom trudności: trudny 🔴
Liczba punktów: 120
Treść: Kiedy atakujący wykonał ruch lateralny przy użyciu skradzionych poświadczeń?
W tym pytaniu musimy znaleźć kiedy atakujący użył skradzionych poświadczeń. Jednym z narzędzi umożliwiających ich wykorzystanie jest alternatywna wersja PsExec z pakietu impacket (oficjalny PsExec z Sysinternals nie wspiera Pass-the-Hash).
Podczas wykonywania poleceń na zdalnym komputerze przy użyciu PsExec na komputerze ofiary uruchamia się plik PsExeSVC.exe. Postanowiłem, że poszukam dowodów wskazujących na jego aktywację.
Wykorzystałem fakt, że Windows zapisuje listę ostatnio uruchomionych plików w celu poprawienia wydajności. Ta funkcjonalność nazywa się systemem Prefetch, a jej pliki znajdują się w katalogu C:\Windows\Prefetch.
Użyłem programu PECmd autorstwa Erica Zimmermana do sparsowania plików Prefetch:
Następnie użyłem TimelineExplorera (również autorstwa Erica) do analizy wygenerowanych plików CSV. W pliku z dopiskiem Timeline znajduje się lista uruchamianych programów, możliwa do chronologicznego posortowania.
Okazuje się, że PsExeSVC.exe został uruchomiony w dniu ataku, kilka godzin po początkowym zalogowaniu:
Odpowiedzią był dzień i czas uruchomienia PsExeSVC.exe.
Pytanie 6. — kradniemy hash NTLM
Poziom trudności: bonus 🌟
Liczba punktów: 25
Treść: Jaki jest hash NTLM hasła użytkownika domenowego matthew.collins?
W tym pytaniu musiałem na chwilę wcielić się w rolę atakującego i znaleźć hash NTLM użytkownika matthew.collins. Jest jeden problem: zrzut pamięci lsass.exe nic mi nie da, ponieważ użytkownik ten od dawna nie jest zalogowany na serwerze. Być może atakujący nie usunął swojego zrzutu?
W transkrypcie z pytania czwartego było widać komunikaty z dumpera pcd.exe użytego do wykonania zrzutu procesu LSASS:
ProcDump v11.0 - Sysinternals process dump utility
Copyright (C) 2009-2022 Mark Russinovich and Andrew Richards
Sysinternals - www.sysinternals.com
[18:28:30] Dump 1 initiated: C:\Windows\system32\text.txt.dmp
[18:28:31] Dump 1 writing: Estimated dump file size is 51 MB.
[18:28:33] Dump 1 complete: 51 MB written in 2.9 seconds
[18:28:34] Dump count reached.
Okazuje się, że atakujący pozostawił ten plik nietknięty. Do odczytania hasha NTLM mogłem użyć mimikatza, albo pobrać plik na swoją maszynę i użyć pypykatza (implementacja mimikatza w Pythonie) — wybrałem tą drugą opcję.
Po pobraniu pliku text.txt.dmp na swoją maszynę, wykonałem następujące polecenie:
