blog bonka

Tag: Windows

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