Wstęp

W poprzednim wpisie postawiłem domowy SOC: Raspberry Pi 5 z Wazuhem, segment labowy na MikroTiku i izolowany VLAN. Teraz dokładam do tego drugą połowę — środowisko ofensywne, czyli range Active Directory, na którym będę przerabiał moduły Active Directory z kursu TCM Practical Ethical Hacking.

Poprzednia wersja labu AD stała na Hyper-V. Tym razem przenoszę ją na VMware Workstation i stawiam od zera. Cel jest prosty: jeden kontroler domeny, dwie stacje robocze w domenie, a na każdej maszynie agent Wazuha — żeby każdy atak z Kali było widać od razu po stronie blue teamu.

To nie jest wygładzony tutorial. To dziennik budowy razem z pułapkami, na które się nadziałem — bo akurat te rzeczy rzadko opisują poradniki oparte na starszym Windows Server.

💡 Sieć (MikroTik, VLAN, Raspberry Pi + Wazuh) opisałem w osobnym wpisie — Budowa domowego SOC od zera. Tutaj traktuję ją jako gotowy fundament.

---

Założenia i architektura

Cały lab siedzi w jednym segmencie labowym (VLAN 33, 192.168.33.0/24), odizolowanym od sieci domowej. Plan maszyn:

• DC01 — kontroler domeny, Windows Server 2025, 192.168.33.10
• WS01 — stacja Windows 11, w domenie
• WS02 — druga stacja Windows 11, w domenie
• Raspberry Pi — serwer Wazuh (SIEM), 192.168.33.241
• Kali — maszyna atakująca, podpinana do VLAN 33 na czas ćwiczeń

Domena:

• Nazwa pełna: pentagon.lab
• Nazwa NetBIOS: PENTAGON

Świadomie zostałem przy Server 2025, mimo że kurs TCM bazuje na starszym serwerze. Dzięki temu po drodze wychodzą różnice, które same w sobie są materiałem na wpis (podpisywanie SMB, wymuszona unikalność SID). Ustawienia, które blokują część ataków, będę luzował dopiero wtedy, gdy dojdę do konkretnej techniki.

---

Sieć w VMware — jedna pułapka na start

Host wirtualizacji (laptop) łączy się z segmentem labowym po dedykowanym Wi-Fi z MikroTika, a maszyny wirtualne wpinam w ten sam VLAN przez tryb Bridged.

Tu wpadłem w pierwszą pułapkę przy migracji z Hyper-V. Po starej konfiguracji na laptopie został wirtualny switch Hyper-V (External), który trzymał kartę Wi-Fi dla siebie. Efekt: VMware w ogóle nie widział karty bezprzewodowej na liście do mostkowania, a świeży DC01 nie dostawał adresu z DHCP (lądował na 169.254.x.x).

Rozwiązanie — usunięcie starego switcha i wymuszenie mostka VMware na karcie Wi-Fi:

# na hoście, PowerShell jako administrator
Remove-VMSwitch -Name "NAZWA_STAREGO_SWITCHA" -Force

Potem w Virtual Network Editor ustawiłem VMnet0 jako Bridged i wskazałem konkretną kartę Wi-Fi (nie „Automatic”). Dopiero wtedy maszyny zaczęły dostawać adresy z VLAN 33.

---

Krok 1: Kontroler domeny (DC01)

Adresacja i nazwa

Kontroler musi mieć stały adres, zanim zrobię z niego DC. Statyczne IP w segmencie labowym, DNS wskazujący na razie na siebie (po promocji będzie to kontroler):

Nazwę komputera ustawiam przed promocją — zmiana nazwy działającego kontrolera domeny to proszenie się o kłopoty:

Rename-Computer -NewName "DC01" -Restart

Promocja do kontrolera domeny

Rolę AD DS dokładam przez Server Manager → Manage → Add Roles and Features:

dodanie roli Active Directory Domain Services

Po instalacji roli pojawia się link do promocji serwera:

W kreatorze wybieram Add a new forest i wpisuję nazwę domeny:

Nazwa NetBIOS uzupełnia się automatycznie jako PENTAGON — zostawiam:

Ustawiam hasło DSRM (zapisuję w menedżerze haseł), ścieżki NTDS/SYSVOL zostawiam domyślne. Kontrola wymagań wstępnych przechodzi — ostrzeżenie o delegacji DNS jest normalne w labie i można je zignorować:

Serwer sam się restartuje i wstaje już jako kontroler domeny:

Active Directory Certificate Services

Na koniec dokładam urząd certyfikacji (przyda się później). Znów przez Add Roles and Features, rola Active Directory Certificate Services:

Z usług roli zaznaczam tylko Certification Authority:

Konfiguracja CA: Enterprise CA, Root CA, nowy klucz prywatny. Nazwę urzędu zostawiam domyślną:

Parametry kryptografii — RSA, SHA256, długość klucza 2048:

⚠️ Jeśli kreator konfiguracji CA wywali błąd w stylu Get-_InternalAdcsConfigurationState is not recognized, nie panikuj — rola jest poprawnie zainstalowana, tylko konsola nie załadowała modułu w tej samej sesji. Wystarczy restart serwera i ponowne uruchomienie konfiguracji z żółtej flagi.

---

Krok 2: Stacje robocze (WS01, WS02)

Pierwszą stację (WS01) instaluję normalnie z ISO Windows 11. Drugą (WS02) klonuję, żeby nie przechodzić instalacji drugi raz.

Klon + Sysprep — pułapka duplikatu SID

Tu uwaga, która potrafi wywrócić cały lab: od aktualizacji z końca sierpnia 2025 Windows 11 (24H2/25H2) i Windows Server 2025 wymuszają unikalność identyfikatora SID. Dwie maszyny z tym samym SID-em dostają błędy uwierzytelniania Kerberos i NTLM — czyli pada dokładnie to, na czym stoi domena.

Dlatego klon musi przejść przez Sysprep, który generuje nowy SID:

C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /reboot

Po tym WS02 przechodzi od nowa konfigurację pierwszego uruchomienia i zmieniam jej nazwę na WS02.

Dołączenie do domeny

Na obu stacjach DNS musi wskazywać na kontroler domeny — bez tego dołączenie się nie uda:

Dołączenie do domeny przez właściwości systemu:

Po restarcie obie maszyny są widoczne w kontenerze Computers w AD:

---

Krok 3: Użytkownicy, grupy, udziały, GPO

Konta

Zostawiam wbudowane Administrator i Guest, resztę kont tworzę ręcznie. Konta „wysokie” (domain admin, konto serwisowe) robię przez Copy z Administratora, zwykłych użytkowników przez New → User.

Konto serwisowe SQLService to celowa dziura pod Kerberoasting — słabe hasło wpisane wprost w opisie konta:

Żeby konto serwisowe dało się zaatakować przez Kerberoasting, musi mieć zarejestrowany SPN:

setspn -a DC01/SQLService.pentagon.lab:60111 PENTAGON\SQLService

Na stacjach włączam wbudowane konto Administrator z tym samym hasłem na obu maszynach (pod atak pass-the-hash / lateral movement) i dodaję użytkowników domenowych do lokalnej grupy Administrators:

Udział sieciowy

Na kontrolerze tworzę udział TopSecret (przez File and Storage Services → Shares → New Share), żeby było co enumerować z Kali:

Na jednej ze stacji mapuję go jako dysk sieciowy z poświadczeniami domenowymi:

GPO — wyłączenie Windows Defender

Żeby ćwiczyć same techniki ataku bez walki z antywirusem, wyłączam Defendera przez politykę domenową. Nowy GPO na poziomie domeny:

W edytorze: Computer Configuration → Policies → Administrative Templates → Windows Components → Microsoft Defender Antivirus → Turn off Microsoft Defender Antivirus → Enabled:

---

Krok 4: Agenty Wazuh

Teraz część blue team — na każdej maszynie instaluję agenta Wazuha wskazującego na managera na Raspberry Pi. Wersja agenta musi być taka sama jak managera (u mnie 4.14.5) — nowszy agent nie połączy się ze starszym managerem.

# PowerShell jako administrator, na DC01 / WS01 / WS02
Invoke-WebRequest -Uri "https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.5-1.msi" -OutFile "$env:tmp\wazuh-agent.msi"
msiexec.exe /i "$env:tmp\wazuh-agent.msi" /q WAZUH_MANAGER="192.168.33.241" WAZUH_REGISTRATION_SERVER="192.168.33.241" WAZUH_AGENT_NAME="DC01"
Start-Sleep -Seconds 15
Start-Service WazuhSvc

Dla każdej maszyny zmieniam tylko WAZUH_AGENT_NAME (DC01 / WS01 / WS02). Usługa WazuhSvc rejestruje się jako automatyczna, więc wstaje przy każdym starcie systemu.

Efekt — trzy agenty w statusie Active:

💡 Jeśli któraś maszyna nie jest widoczna w podglądzie „Sieć” u sąsiada, to kwestia rozgłaszania, nie domeny. Wykrywanie sieci włącza się po stronie maszyny, którą chcesz widzieć: powershell foreach ($s in "fdPHost","FDResPub","SSDPSRV","upnphost") { Set-Service $s -StartupType Automatic; Start-Service $s } Enable-NetFirewallRule -DisplayGroup "Network Discovery" 

---

Pułapki i wnioski

Najwięcej czasu zjadły rzeczy, których nie było w poradnikach:

• Złe ISO serwera. Pierwszy obraz, który pobrałem, miał etykietę SERVER_FOD_LP — to paczka języków i funkcji opcjonalnych, a nie płyta instalacyjna. Nie da się z niej bootować („No Media” w VMware). Właściwy obraz to pozycja ISO, 64-bit edition z Microsoft Evaluation Center.
• Smart App Control. Na Windows 11 potrafi blokować pliki pobrane z internetu — jeśli coś „znika” albo nie chce się uruchomić, to pierwszy podejrzany.
• Switch Hyper-V trzymający kartę Wi-Fi. Po migracji z Hyper-V na VMware trzeba usunąć stary wirtualny switch, inaczej VMware nie widzi karty do mostkowania.
• Wymuszona unikalność SID na Server 2025 / Win11 24H2. Klon bez Sysprepa = sypiące się logowanie domenowe. To nowość, której starsze tutoriale nie uwzględniają.
• Server 2025 vs kurs. Nowe Windowsy domyślnie wymuszają podpisywanie SMB, co zablokuje część ataków z kursu (np. SMB relay). Te ustawienia będę luzował świadomie przy konkretnych technikach — i to też opiszę.

Po stronie SOC (Raspberry Pi) też było kilka lekcji: zbyt krótki domyślny limit startu usługi Wazuh managera (podniosłem TimeoutStartSec), oraz za słaby zasilacz Pi 5 — przy dysku NVMe i obciążeniu OpenSearchem potrafi się wieszać, trzeba oficjalnego 27 W.

---

Co dalej ?

Fundament stoi: kontroler domeny, dwie stacje w domenie, celowo podatne konta i udziały, a nad tym Wazuh zbierający zdarzenia ze wszystkich trzech maszyn. Przed każdą sesją robię snapshot wszystkich VM-ek, żeby po ataku wrócić do czystego stanu.

W poprzednim wpisie zapowiedziałem „Roadmapę v3.0″ — walkę offense vs defense. Teraz ją realizuję, warstwa po warstwie:

• Pierwsze wektory ataku (najbliższa część). Moduł Active Directory z kursu: LLMNR poisoning i Responder, przechwytywanie oraz łamanie hashy, SMB relay. Do testów podpinam fizycznego Kali do VLAN 33 — zgodnie z planem z v3.0 nie stawiam kolejnej wirtualki, tylko osobny laptop jako attack box. Przy każdym ataku sprawdzam, co z tego widzi Wazuh.
• Sysmon na końcówkach. Instalacja System Monitora i wgranie sensownej polityki audytu, żeby SIEM widział tworzenie procesów, wywołania z wiersza poleceń i podejrzane zmiany w rejestrze. Bez tego domyślne logi Windows są za ubogie, żeby cokolwiek złapać.
• Strojenie detekcji (blue team). Kiedy Kali zacznie generować szum, weryfikuję, co łapią domyślne reguły Wazuha, a potem piszę własne reguły pod konkretne ataki.
• Porządki w samym Wazuhu. Pogrupowanie agentów w osobną grupę pentagon zamiast domyślnej default i złożenie własnego dashboardu — żeby to wyglądało jak panel SOC, a nie goła lista endpointów.
• Side-quest: logi z MikroTika do Wazuha. Na razie SIEM widzi tylko stacje Windows, a router można wpiąć agentless i zbierać jego logi. Dobry materiał na start: webinar SekurakTV „Integracja Wazuha z MikroTikiem” (Tomek Turba) — https://www.youtube.com/watch?v=Q36vKFdQRfo. Przed zabawą z konfiguracją routera najpierw backup (/system backup save), bo jedną złą regułą łatwo odciąć sobie dostęp — przerabiałem to na własnej skórze.

Red kontra blue na jednym stole. W kolejnej części zaczynam od pierwszego wektora — i od razu patrzę, co ląduje w Wazuhu.