Poniżej lista przełączników, które kiedyś mi się przydały:
/TargetTrustServerCertificate:[True|False]-pomijanieweryfikacjicertyfikatuserweradocelowego (np. przyimporcie)/SourceTrustServerCertificate:[True|False]-pomijanieweryfikacjicertyfikatuserweraźródłowego (np. przyeksporcie)/Diagnostics:[True|False]-włączenieszczegółowychlogów/DiagnosticsFile:<ścieżka>-włączenieszczegółowychlogów,dopliku/OutputPath:ściezka-definiuje,gdziemająbyćwyplutepliki (domyślnie dokataloguroboczego)
Instalacja
Instrukcje instalacji na różnych systemach/dystro:
Kilka miesięcy temu dostałem obraz dysku giętarki Dynobend z prośbą o uruchomienie go i/lub odzyskanie haseł. Wiedziałem tylko tyle, że zainstalowany na maszynie system to Windows XP.
Odtwarzanie obrazu
Początkowym wyzwaniem było samo odtworzenie obrazu dysku. Nie wiedziałem jakim narzędziem była robiona kopia, ale po krótkim researchu doszedłem do wniosku, że było to oprogramowanie Paragonu.
Pliki kopii zapasowej dysku maszyny stworzonej oprogramowaniem Paragonu
Zanim zacząłem odtwarzać kopię, dodałem kolejny dysk wirtualny do maszyny
Dodawanie dysku do maszyny wirtualnej o rozmiarze 160 GB
Po uzyskaniu dostępu do programu, odtworzyłem kopię jako kopię całego dysku (można też jako kopie poszczególnych woluminów, ale to utrudniłoby uruchomienie systemu).
Wybór obrazu dysku z otrzymanej kopii .PBFWybór dysku docelowego i potwierdzenie rozpoczęcia operacji odtwarzania
Po zakończeniu odtwarzania pojawiły się woluminy w przystawce „Zarządzanie dyskami”
Pokazane dyski w maszynie wirtualnej. Widoczny „Dysk 1”, na którym została odtworzona kopia zapasowa PBF
Zostało mi tylko stworzyć nową maszynę wirtualną, spróbować uruchomić odtworzony system i trzymać kciuki.
Walka z bluescreenem
Windows XP jest zdecydowanie mniej przenośny, niż nowsze wersje systemu od Microsoftu. Oto jak zakończyła się moja pierwsza próba odpalenia systemu:
Widoczny BSOD systemu Windows XP
Trzymanie kciuków mało co mi dało, jak widać. Na powyższym zrzucie ekranu tego nie widać, ale kod błędu to był sławny
☠️ 0x0000007B(INACCESSIBLE BOOT DEVICE) ☠️
Co oznacza problem z zamontowaniem woluminu systemowego. Streszczę tutaj mój długi proces walki z tym błędem – próbowałem wyłączać różne sterowniki, modyfikować różne wartości w rejestrze, ale nic nie działało.
Sukces
W końcu wpadłem na pomysł spróbowania trybu naprawy z angielskiego instalatora Windowsa XP (w polskiej wersji tego nie ma z jakiegoś powodu).
Początkowy etap instalatora Windowsa XP
Na tym etapie można wybrać albo czystą instalację (klawisz ESC), albo naprawę. Wskazałem mój odtworzony system i nacisnąłem klawisz R.
Pierwszy etap naprawy
Naprawa wygląda praktycznie tak samo jak instalacja świeżego systemu, przy czym wiele rzeczy jest zachowane. Pliki, użytkownicy i inne rzeczy zostają nietknięte.
Po uruchomieniu ponownym system się uruchomił i rozpoczął się kolejny etap naprawy:
Proces naprawy, widoczny monit o podanie klucza produktu
Jakoś tak wyszło, że nie miałem klucza Windowsa XP SP3. Na szczęście w sieci dostępne są klucze, które można tutaj wpisać, żeby popchnąć instalację (naprawę) dalej: link do listy na GH.
Uruchamianie się naprawionego Windowsa XP
Po wpisaniu klucza system uruchomił się ponownie, tym razem bez BSODa! Jednak nie jest to koniec:
Wyciąłem wyłączone konta Guest, Support oraz HelpAssistant. Widać, że Guest i Support mają puste hasła (ich hashe odpowiadają pustym ciągom) a hasła HelpAssistant nigdy nie odzyskałem.
Widać również, że niektóre konta używają tych samych haseł:
Administrator i Admin
Operator i DynoBend
Po czym to widać? Te konta mają te same hashe!
Łamanie hashy przy użyciu CrackStation
Pierwsze co spróbowałem to wklejenie hashy LM (prostszych do złamania) do online-owych crackerów. Mają one duże bazy danych, które posiadają obliczone hashe różnego typu dla różnych ciągów znaków. Jeżeli hasła były krótkie, to taka baza prawdopodobnie zawiera nasz hash.
Okazało się, że dwa hasła udało się odzyskać już na tym etapie:
Kawałek zwróconej listy CrackStation. Widoczny złamany hash i jeden nie znaleziony.
Pierwszym hasłem było dla kont Admin i Administrator :P. Hasło składało się wyłącznie z cyfr: „8507730„.
Drugim hasłem było dla konta „Remote”, które miało unikalne hasło:
Widoczna lista dopasowanych hashy LM dla Remote
Kolor zielony oznacza dokładnie odwzorowanie. Ale czemu jest ich kilka? Hashe LM są takie same dla różnych kombinacji wielkości liter. Przykładowo, hash dla „abc” jest taki sam jak dla „ABC”.
Za to, hashe NTLM (które również są w dumpie) już takie nie są. Okazało się, że dla konta Remote nawet odwzorowanie NTLM znajduje się w CrackStation:
Rezultat crackowania hasha NTLM dla „Remote”. Widoczne dokładnie odwzorowanie
Okazało się, że hasło dla „Remote” to… „Remote”.
Łamanie hashcatem
W bazie CrackStation nie było hashy dla kont „DynoBend” i „Operator”. Użyłem hashcata do szybkiego sprawdzenia hashy LM dla pozostałych kont:
Po dodaniu „NT Hash” do receptury i wpisaniu „dnebonyd” (małymi literami), CyberChef wypluł dokładnie taki sam hash NTLM, jaki był w dumpie. Oznacza to, że znalazłem hasło dla użytkownika „Engineer”.
Ekran po zalogowaniu do systemu jako Operator. Uruchamiająca się aplikacja giętarki
Podsumowanie
No i nawet się udało!!
Po naprawie systemu za pomocą instalatora Windowsa XP, zdumpowałem hashe za pomocą BlackArcha (samdump2) i zcrackowałem je przy użyciu CrackStation oraz hashcata.
QMC5883L to układ mierzący natężenie pola magnetycznego w 3 osiach, który umożliwia określenie orientacji (np. względem magnetycznej północy).
Kupiłem go na Allegro, myśląc że dostanę HMC5883L (taki napis widniał na płytce). Okazało się, że dostałem odrobinę inny układ: QMC5883L. Jest on niekompatybilnym zamiennikiem, ze względu na małe różnice w rejestrach I2C.
Podłączenie do STM32
Jednym z wyzwań było samo podłączenie układu do mikrokontrolera.
Wybrałem I2C1, pin SCL podłączyłem do PB8, a pin SDA do PB7 a prędkość GPIO ustawiłem na Bardzo szybką.
Połączenie I2C wymaga rezystorów pull-up, których płytka z układem nie posiadała. Spróbowałem użyć wbudowanych pull-upów w mój STM32U083MC, ale niestety połączenie często się rozrywało. Zdecydowałem się zbudować podłączyć własne pull-upy.
Pod ręką miałem rezystory 2,2 kΩ (choć słyszałem, że lepsze byłyby 4,7 kΩ), dlatego takich użyłem. Próbowałem podłączyć moduł z kontrolerem przez płytkę stykową, ale najwyraźniej rezystory słabo łączyły. Ulepiłem połączenie z kabli, podłączając pull-upy w środku przewodów do VCC (3.3V).
Zdjęcie przedstawiające połączenie I2C
Po ulepieniu czegoś takiego, połączenie działało zadowalająco, nawet z I2C w trybie szybkim (400 kHz).
Azymut, kalibracja i deklinacja
QMC5883L nie daje nam gotowego azymutu, a wartość natężenia pola magnetycznego w trzech osiach. Azymut możemy obliczyć używając funkcji arcus tangens:
Gdzie podziała się oś Z? Powyższa implementacja zakłada, że układ jest położony idealnie płasko. Nie miałem zamontowanego akcelerometru, którym mógłbym dodatkowo zmierzyć odchylenie układu. Z tego powodu nie stworzyłem implementacji, która uwzględniałaby oś Z (może jak zamontuję, to zaktualizuję post).
Niestety, bez kalibracji i korekcji wynikającej z deklinacji obliczony azymut będzie w najlepszym wypadku niedokładny – w moim kompletnie mijał się z prawdą.
Po całej tej kalibracji i obliczeniach skierowałem oś X modułu QMC5883L na północ, wtedy mój azymut powinien wynosić 0 stopni. Ku mojemu zdziwieniu odczyt był całkiem dokładny (wahał się o 2, 3 stopnie). Obracając moduł, dalej dawał zadowalające wyniki.
Zatem czemu „niezbyt” idealny wynik? Gdy przymocowałem magnetometr do mojego samochodzika, który był blisko podłogi, odczyt nagle stał się niedokładny. Rozbiegał się o blisko 15, czasami 20 stopni. Okazało się, że coś w podłodze zakłóca pole magnetyczne Ziemi, przez co odczyt jest błędny.
Dodatkowo, na odczyt wpływa również temperatura, którą pominąłem w obliczeniach azymutu (moduł ma funkcję pomiaru temperatury).
Problemy z komunikacją
Oprócz niedokładnego pomiaru wystąpiły również problemy z samym modułem QMC5883L.
Gdy odczytywałem moduł zbyt często (biorąc pod uwagę stan pinu gotowości danych), przestawał on odczytywać natężenie. Ciągle zwracał te same wartości (sama komunikacja przez magistralę I2C działała poprawnie).
W związku z tym, odczytywałem dane z QMC5883L co 50 milisekund:
// [...]while (1){if (HAL_GetTick() >= next_read_tick && g_qmc_drdy) { next_read_tick =HAL_GetTick() +50;if (QMC5883L_AppReadData()) {// Jeśli QMC nadal utrzymuje wysoki poziom pinu lub operacja ponownego odczytu była zbyt szybka, aby EXTI mogło się uruchomić,// to po prostu ponownie odczytaj rejestry QMC (w przeciwnym razie g_qmc_drdy pozostanie fałszywe, podczas gdy pin będzie miał wysoki poziom). g_qmc_drdy =HAL_GPIO_ReadPin(QMC_DRDY_GPIO_Port, QMC_DRDY_Pin); }else {printf("i2c error\r\n");uint32_t err =HAL_I2C_GetError(&hi2c1);printf("error code: %lu\r\n", err); } }}// [...]
Tak czy inaczej, spróbuję ulepić lepsze pull-upy i dam update, czy to pomogło.
Podsumowanie
Wdrożenie magnetometru QMC5883L okazało się ciekawym wyzwaniem, obfitującym w szereg praktycznych problemów i naukę. Pomimo początkowych trudności, udało mi się osiągnąć w miarę działający system.
Moje wnioski:
Zamienniki: Kupiony moduł, oznaczony jako HMC5883L, w rzeczywistości zawierał układ QMC5883L, który jest niekompatybilny na poziomie rejestrów, co wymusiło samodzielną implementację sterownika.
Fizyczne podłączenie: Stabilna praca I2C jest niemożliwa bez odpowiednich rezystorów pull-up. Wbudowane w STM32 okazały się niewystarczające, a dopiero dodanie zewnętrznych rezystorów 2,2 kΩ zapewniło względnie stabilną komunikację nawet przy 400 kHz.
Kalibracja jest niezbędna: Samo odczytanie surowych wartości z osi X, Y i Z jest niewystarczające. Aby uzyskać wiarygodny azymut, konieczne było przeprowadzenie kalibracji (usuwającej zakłócenia hard-iron i soft-iron) oraz uwzględnienie lokalnej deklinacji magnetycznej.
Środowisko ma ogromne znaczenie: Nawet doskonała kalibracja może zostać unieważniona przez zewnętrzne zakłócenia magnetyczne (np. zbrojenie w podłodze), które znacząco wpływają na dokładność odczytu.
Opóźnienie odczytu: Układ wymagał ostrożnego zarządzania czasem odczytu. Zbyt częste pollowanie prowadziło do „zawieszenia” się czujnika, dlatego konieczne było wprowadzenie opóźnień i ręczny odczyt pinu DRDY w połączeniu z obsługą przerwania EXTI.
„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ę.
W środowisku Javy zawsze irytowała mnie jedna rzecz: brak dopracowanych narzędzi do rewersingu. Na przykład, jedyny debugger oferujący kontrolę na poziomie pojedynczych instrukcji to JDB, który nie potrafi wyświetlić wykonywanych instrukcji.
Z tego powodu postanowiłem napisać swój własny debugger, a do tego potrzebny mi był parser plików .class, czyli skompilowanych plików Javy.
Czym jest ten cały plik .class?
Najprościej: plik .class to pojedyncza, skompilowana klasa Javy. Zawiera on:
🔤 użyte stringi
1️⃣ zmienne klasowe: ich nazwy, typ zmiennej
⚙️ funkcje: nazwy, skompilowany kod
ℹ️ metadane: przykładowo nazwa pliku źródłowego
Poniżej znajdziesz strukturę tego pliku.
Struktura pliku .class
Edytor ImHex (świetne narzędzie swoją drogą) ma gotowy wzór do plików .class. Oto kawałek klasy hello/HelloWorld otwarty w edytorze:
Surowe bajty w pliku .class z zaznaczonymi danymiOdczytane dane z pliku .class
A oto mój fragment mojego debuggera (który piszę w języku Rust), określający strukturę pliku .class:
constant_pool: pula stałych – wszystkie liczby, stringi, odniesienia do innych klas
access_flags: czy klasa jest publiczna, finalna itd.
this_class: indeks w puli stałych wskazujący na nazwę klasy
super_class: indeks w puli stałych wskazujący na nazwę dziedziczonej klasy
interfaces: interfejsy przypisane do klasy
fields: zmienne
methods: funkcje
attributes: atrybuty, takie jak: oryginalna nazwa pliku źródłowego
Plik .class przestrzega porządku big-endian, co oznacza, że każda liczba jest zapisywana od lewej do prawej. Przykładowo:
liczba 16-bitowa 0xFFEE zostanie zapisana: FF EE
w porządku little-endian byłoby to: EE FF (od tyłu)
Każda kolekcja (funkcji, zmiennych itd.) jest poprzedzona ich długością. Jest ona potrzebna, aby program przetwarzający wiedział ile funkcji, zmiennych czy atrybutów ma odczytać.
Do zrozumienia wszystkich innych elementów .class, potrzebna jest znajomość puli stałych, która przechowuje wartości wykorzystywane w całym pliku – nawet w kodzie funkcji.
Pula stałych (constant pool)
Każda wartość w puli jest poprzedzona identyfikatorem (bajtem):
Program przetwarzający .class przetwarza dane na podstawie nazwy odczytanej z puli stałych.
Przykładowo, jeżeli name_index wskazuje na string SourceFile, parser będzie wiedział, że data zawiera string UTF-8, który jest nazwą oryginalnego pliku źródłowego (np. HelloWorld.java).
Ważnym atrybutem jest Code, który zawiera skompilowany bytecode funkcji:
Code_attribute { u2 attribute_name_index; u4 attribute_length; u2 max_stack; u2 max_locals; u4 code_length; u1 code[code_length]; u2 exception_table_length;{ u2 start_pc; u2 end_pc; u2 handler_pc; u2 catch_type;} exception_table[exception_table_length]; u2 attributes_count; attribute_info attributes[attributes_count];}
Dlaczego to ważne?
Zrozumienie struktury plików .class ma praktyczne zastosowania:
Reverse engineering i debugging – pozwala analizować, jak dokładnie działa kod Javy po kompilacji, a także pisać własne narzędzia do debugowania czy analizy
Bezpieczeństwo – analiza plików .class pomaga w badaniu malware pisanego w Javie albo w szukaniu luk w kodzie
Narzędzia deweloperskie – wiele popularnych narzędzi (np. dekompilatory, frameworki testowe czy biblioteki do instrumentacji kodu) bazuje na parsowaniu plików .class. Wiedząc, jak one są zbudowane, łatwiej jest pisać własne rozszerzenia
Głębsze zrozumienie JVM – dzięki znajomości szczegółów formatu .class programista lepiej rozumie, jak Java „od środka” reprezentuje klasy, metody i typy
Podsumowanie
Pliki .class to skompilowane pliki Javy
Wszystkie literały (liczby, stringi) i odniesienia do klas są w jednej, indeksowanej puli
Funkcje i pola są zdefiniowane w listach
Klasy, funkcje oraz pola posiadają atrybuty, które definiują np. kod funkcji, albo to, czy dana zmienna jest przestarzała
Cała specyfikacji pliku .class jest dostępna tutaj
Dnia 26 lipca 2025 na TryHackMe odbywał się blue-teamowy konkurs Capture The Flag o nazwie Honeynet Collapse CTF. Był ściśle związany z tematyką infromatyki śledczej. Zająłem w nim piąte miejsce!
Writeupy do wszystkich zadań znajdują się na dole strony.
CTF zawierał w sumie sześć zadań, w każdym było po sześć pytań:
dwa łatwe 🟢🟢 (30 punktów każde)
dwa średnie 🟡🟡 (60 punktów każde)
jedno trudne 🔴 (120 punktów każde)
jedno bonusowe 🌟 (25 punktów każde)
Zadania były różne:
niektóre opierały się na analizie systemu „na żywo” (wprost analizowałem zainfekowany system)
analizie obrazów dysku (NTFS: jeden pełny obraz i jeden częściowy)
oraz analizie obrazu dysku komputera Mac.
Postanowiłem opisać każde zadanie krok po kroku (pomijając dwa pierwsze: zasady i wprowadzenie tematyczne):
Ostatnim zadaniem w CTFie Honeynet Collapse było zadanie ósme. Polegało ono na analizie obrazu dysku urządzenia Mac. Użytkownik pobrał i zainstalował pewnego wirusa, a ja musiałem znaleźć informacje na jego temat.
Pytanie 1. — strona pobierania
Poziom trudności: łatwy 🟢
Liczba punktów: 30
Treść: Z jakiej strony internetowej użytkownik pobrał instalator złośliwej aplikacji?
Pierwsze co przyszło mi na myśl to przejrzenie historii przeglądania Safarii. Pliki tej przeglądarki znajdują się w katalogu ~/Library/Safari (~ oznacza katalog domowy użytkownika). Plik History.db odpowiada za przechowywanie historii przeglądania:
Po zamontowaniu obrazu dysku przy użyciu apfs-fuse, otworzyłem plik History.db w aplikacji DB Browser for SQLite. W tabeli history_items znalazłem URL z domeną .thm, który był odpowiedzią na pytanie pierwsze:
Treść: Jak nazywa się instalator złośliwej aplikacji?
Najbardziej oczywistym miejscem do sprawdzenia był katalog Downloads, ale tam nie było szukanego instalatora (był za toDocker.dmg, ale to nie ten plik).
Będąc jeszcze w katalogu z plikami Safarii, przejrzałem zawartość pliku Downloads.plist:
Liczba „-07” przy czasie oznacza, że komputer był w strefie czasowej odsuniętej od UTC o siedem godzin. Z tego powodu odpowiedzią na pytanie był data i czas przesunięty o siedem godzin w przyszłość.
Pytanie 4. — uprawnienia TCC
Poziom trudności: średni 🟡
Liczba punktów: 60
Treść: Które uprawnienie TCC zostało najpierw zażądane przez aplikację?
Uprawnienia TCC (Transparency, Consent and Control)pozwalają użytkownikowi na wyraźne przyznawanie aplikacjom dostępu do wrażliwych usług i danych (np. do kamerki, mikrofonu itd.).
Informacje na temat przydzielonych uprawnień znajdują się w katalogu ~/Library/Application Support/com.apple.TCC/TCC.db (dostępny jest również plik dla całego systemu). Po otwarciu pliku TCC.db w przeglądarce baz danych szybko znalazłem pierwsze żądane uprawnienie:
Pytanie 5. — pełny adres URL do serwera C2
Poziom trudności: trudny 🔴
Liczba punktów: 120
Treść: Jaki jest pełny adres URL C2, do którego aplikacja przesłała dane?
We wcześniej analizowanym pliku install.log był widoczny wpis wskazujący ścieżkę instalacji:
W ostatnim zadaniu w całym CTFie trzeba było znaleźć mechanizm, za pomocą którego aplikacja utrzymywała działanie w systemie.
Pierwszy mechanizm, który przyszedł mi na myśl to LaunchAgent. Na początek sprawdziłem katalog systemowy /System/Library/LaunchAgents, ale w nim był jedynie plik związany z agentem Spice.
Drugim katalogiem jakim sprawdziłem był katalog ~/Library/LaunchAgents, w którym już jasno było widać plik autostartu złośliwej aplikacji:
┌──(bonk㉿bonx)-[~/mac/root]
└─$ cd Users/lucasrivera/Library/LaunchAgents
┌──(bonk㉿bonx)-[~/.../Users/lucasrivera/Library/LaunchAgents]
└─$ ls
com.developai.agent.plist DevelopAI.sh
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).
