Attacktive Directory— TryHackMe
In today’s IT industry, Active Directory serves as a backbone of a lot of the Corporate networks. Having this many users across the corporate world means that pentesting of Active Directory networks has become an essential practice in cybersecurity.
WHAT IS ACTIVE DIRECTORY?
Active Directory is Microsoft’s system for managing users, computers, and access to resources in a company network. It acts as a centralized database and security system for organization’s computers.
ACTIVE DIRECTORY ARCHITECHTURE
In an Active Directory network, the Domain Controller holds the highest authority of the domain. It handles users, computers, devices and groups within the network domain and provides Authentication and Authorization services.
WHAT IS A DOMAIN?
A domain in Active Directory network is a logical boundary that contains computers, users, groups and other AD objects.
A company’s domain can be corp.company.com, organization.com, ad.company.com or company.local.
If a domain within a bank is named thisbank.local, then a user’s login could be thisbank\johnny or johnny@thisbank.local.
This was the introduction to Active Directory that will help us in this TryHackMe Room. Let’s learn more while solving the room!
Room: Attacktive Directory [TryHackMe]
REQUIREMENTS:
For Active Directory pentesting, we will be using Impacket. To install it on kali linux, run the following command.
/> sudo apt update && sudo apt install python3-impacket
Once that is done, we can move on to the room tasks.
TASK 3: ENUMERATION
We will start with performing an nmap scan on target host. It
/> nmap -sC -sV 10.49.177.197 -T4
- -sC: Runs a script scan with the set of default scripts.
- -sV: Enables service and version detection.
- -T4: Aggressive timing template that enables high speed scan
From this scan, we can find out the Net-BIOS Domain name of the system as well as the Domain name of the whole Active Directory network.
This scan result is interesting because we can see that there are 5 services running on the system:
- DNS (port 53)
- Kerberos (port 88)
- LDAP (port 389, 3268)
- SMB (port 139, 445)
- RPC (port 135)
Which means that this host is a Domain Controller!
We can see that netbios-ssn service is running on port 139, which means SMB protocol is being utilized. We will use enum4linux tool to enumerate these ports.
/> enum4linux spookysec.local
We have retrieved the domain name of the machine and some known usernames that might come in handy later.
TASK 4: ENUMEARTION VIA KERBEROS
Now that we know that Kerberos is running on the target host, we can attempt to brute force discovery of usernames and passwords.
Let me clear something:
It is NOT RECOMMENDED to brute force credentials for discovery due to account lockout policies in an actual network.
The room instructions explicitly tells us to perform brute force discovery on the target system. Which is why, we are doing it right now.
We will use a tool called kerbrute to brute force the credentials. For wordlists, the room has provided us 2 wordlists containing usernames and passwords.
/>./kerbrute userenum -d spookysec.local /tmp/users.txt — dc 10.49.177.197
Now that is an interesting result. Out of all these users, two stick out the most:
- svc-admin
- backup
Notice that pre-authentication is disabled for svc-admin user. There is also a hash that has been dumped by kerbrute, which means that the account is vulnerable to AS-REP Roasting attack!
TASK 5: ABUSING KERBEROS (EXPLOITATION)
Now that we know about the disabled pre-auth on svc-admin, we will use AS-REP Roasting to retrieve and crack the authentication hash to find put the password.
But before that, let’s answer the big question:
What is AS-REP Roasting?
Get Darsh Mohile’s stories in your inbox
Join Medium for free to get updates from this writer.
AS — REP stands for Authentication Service Reply.
By default, pre-authentication is required on Active Directory accounts. This is how user authentication works:
- When a user enters the password to login, the timestamp of login attempt is encrypted using the hash of the entered password. This authentication request is called
AS-REQ. - This encrypted timestamp is then sent to the Domain Controller.
- The server decrypts it using it’s own saved copy of user’s password.
- If the decrypted timestamp is correct, server knows that user actually knows the password. Only then it proceeds with handing over login tickets. This response is called
AS-REP(Reply).
What happens if pre-authentication is disabled?
If pre-auth is disabled, anyone on the network can send an AS-REQ to server, saying “Hi, I am user X, please log me in”. Because the security check is disabled, the server sends back a login ticket as response (AS-REP). The thing is, a part of this login ticket contains the hash of user’s password. This hash can be cracked offline to find out the password if it is weak enough!
This action of cracking the requested hash is called “Roasting”. We are fetching AS-REP (the login ticket response) and cracking it. Thus, AS-REP Roasting!
Now, let’s continue with the room, shall we?
We already know that pre-auth is disabled on svc-admin. Only thing that is left is to request the login ticket as AS-REP. We will do that using one of the scripts in Impacket, GetNPUsers.py.
/> GetNPUsers.py spookysec.local/svc-admin -dc-ip 10.49.177.197
We have successfully retrieved the TGT (login ticket). Now we can crack it using Hashcat. I am using my windows system as it has more resources for faster cracking than on Kali Linux virtual machine.
/> .\hashcat.exe -a 0 -m 18200 D:\hash.txt D:\rockyou.txt
TASK 6: ENUMERATION (AGAIN!)
Now that we have the password to svc_admin, we can use smbclient to see if there are any interesting shares listed on target system.
/> smbclient -L //10.49.177.197 -U svc-admin
One interesting share is backup. It may contain some data that might help us.
/> smbclient //10.49.177.197/backup -U svc-admin
Backup Credentials!! There we go. Now we can copy the file to our attacker system by using get <filename> command. Once it is downloaded, we can simply cat it and read the contents.
/> cat ./backup_credentials.txt
The text file reveals a hash. Presumably, the credentials to ‘backup’ user on the target system. By the looks of it, it can be a base64 encoded text. To decrypt this, we can go to hashes.com and paste hash there to reveal the plain text.
TASK 7: ELEVATING THE PRIVILEGES
We now have:
- Username
- Password
- Domain name
- IP address of target system
- IP address of domain controller (same as target system)
This calls for a perfect opportunity to use secretsdump, which is an impacket script that literally dumps all the secrets on the target system including SAM Hive of the system, Windows Service credentials and Kerberos keys needed for lateral movement.
Syntax: secretsdump.py <domain.name>/<username>:<password>@<target_system_ip> -dc-ip <domain_controller_ip>
The masked part in command given below is the password found by decrypting the hash from backup_credentials.txt.
/> secretsdump.py spookysec.local/backup:*************@10.49.177.197 -dc-ip 10.49.177.197
There are the credentials including Administrator’s NTLM hash. Now the final step in capturing the flags is getting the remote shell of target system. For that, we will use evil-winrm. We can pass the NT hash of Administrator and directly get the shell of target system.
The common format of NTLM hash is:
<uid>:<rid>:<LM hash>:<NT hash>:::
From the output of secretsdump, we retrieved an NTLM hash of Admin, which looks like this (Hash is partially masked here):
Administrator:500:aad3b4**************************:0e0363**************************:::
If we match this hash with the format, 0e0363************************** is out NT hash. Let’s start up evil-winrm and access the shell!
/> evil-winrm -i 10.49.177.197 -H 0e0363************************** -u Administrator
The user flag is always stored on the Desktop of a user in windows systems. So we navigate to C:\Users\svc-admin\Desktop and ls.
there it is! The user flag! Only thing left is to cat it and submit the flag!
Now we move on to root flag. Navigate to C:\Users\backup\Desktop and ls.
We found the root flag! Cat it, submit the flag and the room is solved!
And that’s a wrap on Attacktive Directory! Diving into Active Directory can feel overwhelming and confusing when you’re first starting out, but breaking down how things like Kerberos auth and AS-REP Roasting actually work under the hood makes a massive difference.
Spotting that disabled pre-authentication is a classic quick win that leads straight to a foothold, and taking it all the way to the root flag proves just how fast a small AD misconfiguration can cause a snowball effect.
Keep grinding, keep roasting those hashes, and I’ll see you in the next lab!
