Tag: Rejestr

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

  • 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: