Every Active Directory lab I've done has taught me something new. My home lab taught me how to build a domain and tear it apart. The TryHackMe Active Directory room taught me how fast it can fall apart when one service account has the wrong setting enabled.

This is a walkthrough of the full attack chain: from a blank Kali terminal to an administrator shell on a domain controller.

The Target

The room gives you a Windows domain controller running the domain spookysec.local. No credentials, no hints about what's vulnerable. Just an IP address and a place to start.

The attack path ended up being

Nmap → Kerbrute → AS-REP Roasting → Hash Cracking → SMB Enumeration → Credential Discovery → secretsdump → Pass-the-Hash → Administrator shell

Eight steps. Every one of them flows naturally into the next.

Step 1: Figure Out What You're Dealing With

The first thing I always do is run a full port scan.

sudo nmap -sV -sC -p- 10.67.183.59

The results told me everything I needed. Port 88 confirmed Kerberos. Ports 389 and 3268 confirmed LDAP. Port 445 confirmed SMB. Port 5985 (WinRM) caught my attention because that's what Evil-WinRM uses. The domain name came back as spookysec.local.

This is unmistakably a domain controller. Now I know what I'm working with.

Step 2: Find Valid Users Without a Password

This is one of my favorite techniques: Kerbrute for user enumeration. The reason it works is that Kerberos will respond differently depending on whether a username actually exists in the domain. Valid usernames get one response, invalid ones get another. No credentials are required, and it doesn't trigger account lockouts.

kerbrute userenum --dc 10.67.183.59 -d spookysec.local userlist.txt

Three accounts stood out immediately: , and administrator.

The svc-admin account is what caught my eye. Service accounts are common AS-REP roasting targets because they often have pre-authentication disabled, and that's exactly what I was going to check next.

Step 3: AS-REP Roasting

Here's the thing about Kerberos pre-authentication: it's a security feature that's on by default. When it's enabled, a user has to prove who they are before the KDC hands out a ticket. When it's disabled, the KDC will just hand over an encrypted ticket to anyone who asks: no proof required.

That encrypted ticket can be taken offline and cracked.

impacket-GetNPUsers spookysec.local/svc-admin -no-pass -dc-ip 10.67.183.59

svc-admin had pre-authentication disabled. The KDC handed me a hash. Now I just needed to crack it.

Step 4: Crack the Hash Offline

Hashcat mode 18200 handles AS-REP hashes. I threw the provided password list at it.

hashcat -m 18200 hash.txt passwordlist.txt

It cracked almost immediately:svc-admin:management2005

Now I have real credentials for a domain account. The attack just shifted gears.

Step 5: See What's Accessible Over SMB

With valid credentials, SMB share enumeration is straightforward.

smbclient -L \\\\10.67.183.59\\ -U svc-admin

Six shares came back. Most of them were standard: SYSVOL, NETLOGON, the usual. One wasn't: a share called backup. That's not a default share, and the name alone tells you it's worth investigating.

Step 6: The Backup Share Had Credentials Sitting in It

I connected to the share and found a file inside. Downloaded it, decoded it:

echo 'YmFja3VwQHNwb29reXNlYy5sb2NhbDpiYWNrdXAyNTE3ODYw' | base64 -d

Output:backup@spookysec.local:backup2517860

Credentials for the backup account. Base64-encoded and left in an accessible SMB share. That's the kind of thing that happens in real environments. Someone stored credentials somewhere "convenient" and forgot about it.

But here's what makes this really significant: the backup account has a special permission in Active Directory that allows it to sync all domain changes to itself, including password hashes. That's a DCSync-level privilege. This account can pull every NTLM hash in the domain.

Step 7: Dump Every Hash in the Domain

Impacket's secretsdump uses the DRSUAPI method to replicate domain data the same way a domain controller would. With the backup account's permissions, it worked without any issues.

impacket-secretsdump backup:backup2517860@10.67.183.59

Every NTLM hash in the domain came back. Including the Administrator hash: 0e0363213e37b94221497260b0bcb4fc

I don't need to crack this. I can use it directly.

Step 8: Pass-the-Hash to Administrator Shell

Pass-the-Hash is exactly what it sounds like. Instead of authenticating with a password, you authenticate with the hash itself. Windows doesn't actually verify a plaintext password during NTLM authentication: it verifies the hash. So if you have the hash, you can authenticate.

Evil-WinRM makes this simple:

evil-winrm -i 10.67.183.59 -u Administrator -H 0e0363213e37b94221497260b0bcb4fc

Administrator shell on the domain controller. All three flags collected.

What This Chain Actually Shows

What I found interesting about this room is how each step is a direct consequence of the previous one. None of the vulnerabilities exist in isolation.

The svc-admin account had pre-authentication disabled: that's a misconfiguration. That misconfiguration led to a cracked password. Those credentials gave SMB access. The SMB share had credentials stored in plaintext (encoded, not encrypted). Those credentials belonged to an account with DCSync privileges. DCSync gave every hash in the domain. The Administrator has allowed a shell without ever knowing the Administrator password.

One misconfigured setting on one service account. That's the entry point for a full domain compromise.

How to Prevent This

  • Enable Kerberos pre-authentication on all accounts. There is almost never a legitimate reason to disable it.
  • Audit service accounts for excessive privileges. svc-admin should not have replication rights and backup should not have DCSync privileges unless they're absolutely required.
  • Never store credentials in SMB shares, encoded or otherwise. Base64 is not encryption.
  • Monitor for DCSync activity in your SIEM. Impacket secretsdump leaves artifacts in Windows Event Logs.
  • Enable the Protected Users security group for privileged accounts: it prevents NTLM authentication entirely for those accounts.
  • Deploy LAPS so local administrator passwords are unique and rotated automatically.

Final Thoughts

The Attacktive Directory room is a great example of how AD attacks chain together in practice. You rarely get in with one exploit. You get in with a series of small misconfigurations, each one opening the next door.

If you're learning Active Directory security, this room is worth doing. Work through it manually before looking anything up. The process of figuring out what tool to use and why is where the real learning happens.

My full lab notes are on GitHub if you want to see the commands and screenshots side by side.