Tag: Windows

  • Włam do maszyny CNC

    Włam do maszyny CNC

    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.

    Zrzut ekranu: Pliki kopii zapasowej dysku maszyny stworzonej oprogramowaniem Paragonu
    Pliki kopii zapasowej dysku maszyny stworzonej oprogramowaniem Paragonu

    Zanim zacząłem odtwarzać kopię, dodałem kolejny dysk wirtualny do maszyny

    Zrzut ekranu: Dodawanie dysku do maszyny wirtualnej o rozmiarze 160 GB
    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).

    Zrzut ekranu: Wybór obrazu dysku z otrzymanej kopii .PBF
    Wybór obrazu dysku z otrzymanej kopii .PBF
    Zrzut ekranu: Wybór dysku docelowego i potwierdzenie rozpoczęcia operacji odtwarzania
    Wybór dysku docelowego i potwierdzenie rozpoczęcia operacji odtwarzania

    Po zakończeniu odtwarzania pojawiły się woluminy w przystawce „Zarządzanie dyskami”

    Zrzut ekranu: Pokazane dyski w maszynie wirtualnej. Widoczny "Dysk 1", na którym została odtworzona kopia zapasowa PBF
    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:

    Zrzut ekranu: Widoczny BSOD systemu Windows XP
    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).

    Zrzut ekranu: Początkowy etap instalatora Windowsa XP
    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.

    Zrzut ekranu: Pierwszy etap naprawy (pasek instalacyjny)
    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:

    Zrzut ekranu: Proces naprawy, widoczny monit o podanie klucza produktu
    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.

    Zrzut ekranu: Uruchamianie się naprawionego Windowsa XP
    Uruchamianie się naprawionego Windowsa XP

    Po wpisaniu klucza system uruchomił się ponownie, tym razem bez BSODa! Jednak nie jest to koniec:

    Zrzut ekranu: Ekran logowania, automatycznie uzupełniona nazwa: operator
    Ekran logowania, automatycznie uzupełniona nazwa: operator

    Odzyskiwanie haseł

    Najprościej byłoby usunąć hasła z użytkowników, ale to wiązałoby się z modyfikacją oryginalnego systemu – do którego nie miałem dostępu.

    Uruchomiłem BlackArcha na maszynie i zamontowałem partycję systemową:

    Zrzut ekranu: Zamontowanie partycji systemowej w BlackArchu
    Zamontowanie partycji systemowej w BlackArchu

    Po zamontowaniu partycji zdumpowałem hashe haseł z rejestru przy użyciu narzędzia samdump2.

    Zrzut ekranu: Dumpowanie hashy (samdump2)
    Dumpowanie hashy

    Oto lista z powyższego screenshota, w formie tekstowej :):

    Administrator:500:42008b7e0dfe8456aad3b435b51404ee:8666cdaf3d0337cbbae422f9da6f0f52:::
    Admin:1004:42008b7e0dfe8456aad3b435b51404ee:8666cdaf3d0337cbbae422f9da6f0f52:::
    Operator:1005:7c3abc11eef22af54a3b108f3fa6cb6d:e001d7577b432fe8e745deb408cc8a62:::
    Engineer:1006:5de00f0076f9b0d64a3b108f3fa6cb6d:e907f2dd1d5d1a7f6ed20a5a44a0dd11:::
    Remote:1007:b1293b46ba30174aaad3b435b51404ee:a2fb7f991c8960bdae62b6cb12b87d56:::
    DynoBend:1008:7c3abc11eef22af54a3b108f3fa6cb6d:e001d7577b432fe8e745deb408cc8a62:::

    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.

    Wpisałem hashe do CrackStation:

    Zrzut ekranu: Hashe wklejone w CrackStation
    Hashe wklejone w CrackStation

    Okazało się, że dwa hasła udało się odzyskać już na tym etapie:

    Zrzut ekranu: Kawałek zwróconej listy CrackStation. Widoczny złamany hash i jeden nie znaleziony.
    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:

    Zrzut ekranu: Widoczna lista dopasowanych hashy LM dla Remote
    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:

    Zrzut ekranu: Rezultat crackowania hasha NTLM dla "Remote". Widoczne dokładnie odwzorowanie
    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:

    Zrzut ekranu: Uruchomienie hashcata
    Uruchomienie hashcata
    hashcat --potfile-disable -m 3000 -a 3 hashe.txt -1 ?l?u ?1?1?1?1?1?1?1

    Gdzie:

    • --potfile-disable – wyłącznie pliku przechowywania rezultatów (w ramach testów i zrobienia SS)
    • -m 3000 – tryb łamania hashy LM
    • -a 3 – tryb bruteforce (kombinacje znaków)
    • -1 ?l?u – zdefiniowanie customowego zestawu znaków (małe i duże litery)
    • ?1?1?1… – maska do bruteforce-a, 7 liter

    Po jakichś dwóch sekundach hashcat znalazł dwa kolejne (niepełne) hasła:

    Zrzut ekranu: Rezultat crackowania hashcatem. Widoczne odwzorowanie DYNOBEN i DNEBONY
    Rezultat crackowania hashcatem

    Więc dwa kolejne hasła zaczynają się od wariancji ciągu „DYNOBEN” i „DNEBONY”.

    Szukanie dokładnych haseł

    Hashe LM z dumpa to tak naprawdę dwa oddzielne hashe. Przykładowo dla konta DynoBend, ciąg LM skopiowany prosto z dumpa:

    7c3abc11eef22af54a3b108f3fa6cb6d

    Powyższy ciąg znaków to dwa hashe LM:

    7c3abc11eef22af5 4a3b108f3fa6cb6d

    Pierwszy podciąg to hash pierwszych 7 liter hasła, a drugi to hash kolejnych 7 liter hasła, więc maksymalna długość hasła dla hashy LM to 14 znaków.

    DynoBend i Operator mają ten sam hash (powyższy), a co z Engineer?:

    7c3abc11eef22af5 4a3b108f3fa6cb6d # DynoBend i Operator
    5de00f0076f9b0d6 4a3b108f3fa6cb6d # Engineer

    Pierwsze podciągi są różne (ale ich odwzorowanie znalazł hashcat). Widać jednak, że drugie podciagi są takie same!

    Oznacza to, że hasła dla tych kont to przykładowo (drugie 7 liter są takie same dla kont):

    DYNOBENxxxx # DynoBend i Operator
    AAAAAAAxxxx # Engineer

    Po wklejeniu drugiego podciągu do CrackStation okazało się, że hash „4a3b108f3fa6cb6d” to najprawdopodobniej hash litery „d”:

    Zrzut ekranu: Rezultat crackowania hasha 4a3b108f3fa6cb6d
    Rezultat crackowania hasha 4a3b108f3fa6cb6d

    Czyli nasze „xxxx” to „d”, a hasła to wariancje „DNEBONYD” oraz „DYNOBEND”.

    Teraz wystarczyło zrobić słownik takich wariancji: DNEBONYD, dnebonyd, Dnebonyd itd. itd.

    Albo po prostu zgadnąć ręcznie w CyberChefie:

    Zrzut ekranu: Ręczny wpis w CyberChefie
    Ręczny wpis w CyberChefie

    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”.

    Podobnie postąpiłem dla DynoBend i Operator: ich hasła to „Dynobend”.

    Próba logowania jako operator

    Zrzut ekranu: Wpisywanie hasła "Dynobend" dla konta "operator"
    Wpisywanie hasła „Dynobend” dla konta „operator”

    Okazało się, że… działa!

    Zrzut ekranu: Ekran po zalogowaniu do systemu jako Operator. Uruchamiająca się aplikacja giętarki
    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.

  • The Game – TryHackMe (PL)

    The Game – TryHackMe (PL)

    „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 :)

    Okno kopii Tetrisa z pokoju The Game na TryHackMe
    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{.
    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 opcję, która umożliwia wyświetlenie region pamięci wokół adresu.
    Zrzut ekranu przedstawiający region pamięci i ocenzurowaną flagę.
    Zrzut ekranu przedstawiający region pamięci i ocenzurowaną flagę.
  • THM Honeynet Collapse – Zadanie 7

    THM Honeynet Collapse – Zadanie 7

    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 pobrane został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ź:

  • THM Honeynet Collapse – Zadanie 6

    THM Honeynet Collapse – Zadanie 6

    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:

    [...]
    == LogonSession ==
    authentication_id 66488374 (3f68836)
    session_id 4
    username matthew.cxxxxxxx
    domainname DECEPT
    logon_server DC-01
    [...]

    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:

  • THM Honeynet Collapse – Zadanie 5

    THM Honeynet Collapse – Zadanie 5

    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.

    Volatility 3 Framework 2.26.0
    
    PID, PPID, reszta
    
    [...]
    ** 2996 576	
    C:\Windows\PSEXESVC.exe
    
    *** 2100 2996	
    C:\Windows\system32\cmd.exe
    
    **** 2200 2100	
    C:\Windows\system32\conhost.exe 0x4
    
    **** xxxx 2100	
    C:\Windows\System32\rundll32.exe 
    rundll32.exe yyyyyy\MicrosoftUpdate.dll, RunMe
    
    ***** 2676 xxxx	
    C:\Windows\Tasks\windows-update.exe
    
    ****** 2680 2676
    C:\Windows\system32\conhost.exe 0x4
    
    ****** 1444 2676
    C:\Users\matthew.collins\Downloads\security-update.exe
    
    ******* 836 1444 
    C:\Windows\SYSTEM32\zzzzzzz.exe
    
    ******** 1652 836
    C:\Windows\system32\cmd.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:

    • Pytanie pierwsze: ścieżka do MicrosoftUpdate.dll
    • Pytanie drugie: PID procesu rundll32.exe (xxxx)
    • Pytanie trzecie: rundll32.exe yyyyyy\MicrosoftUpdate.dll, RunMe
    • Pytanie czwarte: zzzzzzz.exe

    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:

    Volatility 3 Framework 2.26.0
    
    PID	Process	Start VPN	End VPN	Tag	Protection	CommitCharge	PrivateMemory	File output	Notes	Hexdump	Disasm
    
    836	notepad.exe	0x1c8c6bd0000	0x1c8c6bd0fff	VadS	PAGE_EXECUTE_READWRITE	1	1	Disabled	N/A	
    fc 55 57 56 48 89 e7 e9 01 01 00 00 5e 48 83 ec .UWVH.......^H..
    78 e8 c8 00 00 00 41 51 41 50 52 51 56 48 31 d2 x.....AQAPRQVH1.
    65 48 8b 52 60 48 8b 52 18 48 8b 52 20 48 8b 72 eH.R`H.R.H.R H.r
    50 48 0f b7 4a 4a 4d 31 c9 48 31 c0 ac 3c 61 7c PH..JJM1.H1..<a|	
    0x1c8c6bd0000:	cld	
    0x1c8c6bd0001:	push	rbp
    0x1c8c6bd0002:	push	rdi
    0x1c8c6bd0003:	push	rsi
    0x1c8c6bd0004:	mov	rdi, rsp
    0x1c8c6bd0007:	jmp	0x1c8c6bd010d
    0x1c8c6bd000c:	pop	rsi
    0x1c8c6bd000d:	sub	rsp, 0x78
    0x1c8c6bd0011:	call	0x1c8c6bd00de
    0x1c8c6bd0016:	push	r9
    0x1c8c6bd0018:	push	r8
    0x1c8c6bd001a:	push	rdx
    0x1c8c6bd001b:	push	rcx
    0x1c8c6bd001c:	push	rsi
    0x1c8c6bd001d:	xor	rdx, rdx
    0x1c8c6bd0020:	mov	rdx, qword ptr gs:[rdx + 0x60]
    0x1c8c6bd0025:	mov	rdx, qword ptr [rdx + 0x18]
    0x1c8c6bd0029:	mov	rdx, qword ptr [rdx + 0x20]
    0x1c8c6bd002d:	mov	rsi, qword ptr [rdx + 0x50]
    0x1c8c6bd0031:	movzx	rcx, word ptr [rdx + 0x4a]
    0x1c8c6bd0036:	xor	r9, r9
    0x1c8c6bd0039:	xor	rax, rax
    0x1c8c6bd003c:	lodsb	al, byte ptr [rsi]
    0x1c8c6bd003d:	cmp	al, 0x61
    836	notepad.exe	0x1c8c6dd0000	0x1c8c6e01fff	VadS	PAGE_EXECUTE_READWRITE	50	1	Disabled	N/A	
    fc xx yy zz ee 81 ec 00 20 00 00 48 83 e4 f0 e8 .H..H... ..H....
    cc 00 00 00 41 51 41 50 52 51 56 48 31 d2 65 48 ....AQAPRQVH1.eH
    8b 52 60 48 8b 52 18 48 8b 52 20 48 0f b7 4a 4a .R`H.R.H.R H..JJ
    4d 31 c9 48 8b 72 50 48 31 c0 ac 3c 61 7c 02 2c M1.H.rPH1..<a|.,	
    0x1c8c6dd0000:	cld	
    0x1c8c6dd0001:	mov	rsi, rcx
    0x1c8c6dd0004:	sub	rsp, 0x2000
    0x1c8c6dd000b:	and	rsp, 0xfffffffffffffff0
    0x1c8c6dd000f:	call	0x1c8c6dd00e0
    0x1c8c6dd0014:	push	r9
    0x1c8c6dd0016:	push	r8
    0x1c8c6dd0018:	push	rdx
    0x1c8c6dd0019:	push	rcx
    0x1c8c6dd001a:	push	rsi
    0x1c8c6dd001b:	xor	rdx, rdx
    0x1c8c6dd001e:	mov	rdx, qword ptr gs:[rdx + 0x60]
    0x1c8c6dd0023:	mov	rdx, qword ptr [rdx + 0x18]
    0x1c8c6dd0027:	mov	rdx, qword ptr [rdx + 0x20]
    0x1c8c6dd002b:	movzx	rcx, word ptr [rdx + 0x4a]
    0x1c8c6dd0030:	xor	r9, r9
    0x1c8c6dd0033:	mov	rsi, qword ptr [rdx + 0x50]
    0x1c8c6dd0037:	xor	rax, rax
    0x1c8c6dd003a:	lodsb	al, byte ptr [rsi]
    0x1c8c6dd003b:	cmp	al, 0x61
    0x1c8c6dd003d:	jl	0x1c8c6dd0041

    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).

  • THM Honeynet Collapse – Zadanie 4

    THM Honeynet Collapse – Zadanie 4

    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.

    Znalazłem potwierdzenie poprzedniej odpowiedzi:

    Host Application: C:\Users\emily.ross\Documents\Coreinfo64.exe
    [...]
    PS>IEX ([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("DQpmdW5jdG [...]

    Transkrypt zawierał polecenia zapisane w kodowaniu Base64. Po zdekodowaniu jednego z nich (przy użyciu CyberChefa) potwierdziła się odpowiedź z pytania trzeciego:

    [...]
    return [MSF.Powershell.Meterpreter.Transport]::Add($t)
    [...]

    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:

    PECmd.exe -d C:\Windows\Prefetch --csv ..\Prefetch --csvf pe.csv

    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:

    $ pypykatz lsa minidump text.txt.dmp

    Z wyniku polecenia odczytałem hash NTLM:

    [...]
    == LogonSession ==
    authentication_id 66488374 (3f68836)
    session_id 4
    username matthew.collins
    domainname DECEPT
    logon_server DC-01
    logon_time 2025-06-30T15:28:15.619499+00:00
    sid S-1-5-21-468272475-2474632594-3298944031-1118
    luid 66488374
    	== MSV ==
    		Username: matthew.collins
    		Domain: DECEPT
    		LM: NA
    		NT: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    		SHA1: 435e619bc84181f42fd4c01f517878a4efd5fd32
    [...]

    Gdzie hash NTLM to wartość po NT:.