A structured lesson workspace with readable content, hands-on examples, and a clean path to completion.
I've watched too many junior pentesters burn three hours debugging a broken lab setup when they should've been learning attack chains. The difference between a productive study session and a frustrating one almost always comes down to whether your environment was configured correctly from the start.
This course assumes you're attacking a Windows Server 2019 domain controller running the INLANEFREIGHT.LOCAL domain, with a child domain LOGISTICS.INLANEFREIGHT.LOCAL and an external forest trust to FREIGHTLOGISTICS.LOCAL. You'll need both a Linux attack host (Parrot or Kali) and a Windows attack host joined to the domain.
You need 32GB RAM minimum. I'm not exaggerating. Running a Domain Controller, a member server, a Windows attack box, and a Linux attack VM simultaneously will choke a 16GB machine. Allocate 8GB to the DC, 4GB to each attack host, and 4GB to the member server. Use VMware Workstation Pro or VirtualBox with a host-only network adapter on the 172.16.5.0/23 subnet.
If any of those return empty, install them now. Impacket gets updated frequently, so pull from the GitHub repo rather than relying on your distro's package manager. The version in apt is often six months behind and missing critical modules like noPac support.
Your Windows box needs the ActiveDirectory PowerShell module loaded, PowerView in C:\Tools, SharpHound.exe, Rubeus.exe, Mimikatz, and the DomainPasswordSpray.ps1 script. Disable Windows Defender real-time protection for the C:\Tools directory only. Don't disable it globally unless you enjoy explaining to your lab partner why their VM got infected with a coin miner from a sketchy GitHub download.
Add-MpPreference -ExclusionPath "C:\Tools"Import-Module ActiveDirectorySet-ExecutionPolicy Bypass -Scope Process -Force
Network configuration matters. Both attack hosts must resolve INLANEFREIGHT.LOCAL via the DC's DNS (172.16.5.5). On your Linux host, edit /etc/resolv.conf to point nameserver at 172.16.5.5. On Windows, set the DNS server in adapter properties. If Kerberos authentication fails later, 90% of the time it's a DNS resolution issue.
If that resolves, you're golden. If it times out, fix your virtual network adapter before proceeding. Every single Kerberos-based attack in this course depends on proper name resolution to the Domain Controller.
Get your lab running now. Spawn the VMs, verify connectivity, and confirm you can ping 172.16.5.5 from both hosts. The next module hits the ground running with external recon, and you don't want to be fumbling with network adapters while everyone else is already enumerating the domain.
Finish the lesson once you have worked through the material. This awards ★ 20 XP.