In this lab, I started with nothing .No credentials, no access and ended up with full Domain Admin privileges.
This is not just a walkthrough. I'll explain why each step works, not just what to type.
1. Recon & Initial Enumeration
Before touching any exploit, I focused on understanding the target.
In Active Directory environments, enumeration is not optional It is the attack.
🔎 Initial Scan
I started with an Nmap scan:
nmap -sC -sV TARGET
Key findings:
- 88 (Kerberos) → Active Directory authentication
- 389 (LDAP) → Domain information
- 445 (SMB) → File shares & user enumeration
- 5985 (WinRM) → Remote command execution
This already tells me one thing: 👉 This is a Domain Controller.
At this stage, I didn't try random attacks.
Instead, I mapped possible attack paths:
- SMB → Enumeration
- Kerberos → User discovery & roasting
- LDAP → Domain data
Since SMB was restricted, Kerberos became my primary attack surface.
enum4linux -a TARGET
SMB enumeration failed due to access restrictions.
SMB wasn't giving me anything, so I moved on. Kerberos looked like the better option.
It's easy to get stuck here and keep trying the same thing.
When one path fails, don't brute force it.Pivot.
I shifted from SMB to Kerberos-based attacks.
🧭 Attack Surface Map
Recon → Nmap → SMB (fail) → Kerberos (target) → Kerbrute2. Finding Valid Users (Kerberos Enumeration)
Since Kerberos was exposed, the next logical step was user enumeration.
I used Kerbrute to identify valid usernames:
kerbrute userenum --dc TARGET -d ************** userlist.txtKerberos behaves differently when a username exists versus when it doesn't, which makes this technique very reliable.
From the output, several valid users appeared, but two stood out immediately:
- svc-admin
- backup
Service accounts and backup accounts are almost always interesting in AD environments, so I focused on those.
3. Breaking Kerberos
The next step was to check if any of these users were vulnerable to AS-REP Roasting.
GetNPUsers.py spookysec.local/ -no-pass -usersfile userlist.txt -dc-ip TARGETNormally, Kerberos requires pre-authentication. But if that setting is disabled, you can request a ticket without knowing the password.
And that's exactly what happened.
The account svc-admin returned a hash:
$krb5asrep$23$svc-admin@…
That was the first real foothold.
4. Cracking the Hash
Now that I had the hash, it was just a matter of cracking it offline:
hashcat -m 18200 hash.txt rockyou.txtAS-REP hashes are encrypted using the user's password, so once cracked, you get the credentials directly.
Eventually, the password was recovered.
At this point, I had valid domain credentials.
5. Initial Access
Since WinRM was open, getting a shell was straightforward:
evil-winrm -i TARGET -u svc-admin -p <password>And just like that, I had an interactive session on the machine.
6. Lateral Movement via SMB
With credentials, I went back to SMB — this time authenticated.
smbclient -L //TARGET -U svc-adminOne share immediately caught my attention: backup.
After connecting to it, I found a text file containing a Base64 string.
Decoding it revealed another set of credentials:
backup@spookysec.local : backup2517860
Now I had a second account and likely a more privileged one.
7. Dumping Domain Secrets 💀
The name "backup" wasn't random.
This account had replication privileges, which means it could be used to dump domain secrets.
secretsdump.py spookysec.local/backup:backup2517860@TARGETUsing the DRSUAPI method, I was able to retrieve NTDS data including password hashes for all users.
That includes the Administrator account.
8. Full Domain Compromise
With the Administrator hash obtained from secretsdump, the final step was straightforward.
At this point, I didn't need the Administrator password.
The NTLM hash was enough.
evil-winrm -i TARGET -u Administrator -H <NTLM_HASH>Windows accepts authentication via hash, which is known as Pass-the-Hash.
This gave me full Domain Admin access.
What This Lab Really Shows
At the start, I had nothing.
No creds, no access — just a target.
I didn't look for exploits. I just followed what the system gave me.
Kerberos → users One user → a hash The hash → a password The password → access Access → more credentials And then… everything
Step by step, it just opened up.
No single big mistake. Just small ones, connected together.
And that was enough to go from zero to Domain Admin.
That's how it really happens.
This entire chain started from a single misconfiguration.