Forward THM

Forward THM The objective of the Forward room was to move through the compromised Active Directory environment and retrieve the Administrator flag. Screenshot 2026-08-05 at 00-12-45 The room already provided an initial set of domain credentials: Unlike a normal machine, we did not need to find the initial foothold. We were already inside the domain as j.smith, and the challenge was to find a path from this low-privileged account to full control of the environment. After starting the machine and connecting to the TryHackMe VPN, the target IP address was: Nmap Scanning I started with an Nmap scan to understand what services were exposed by the target. Analysing the Nmap Scan The combination of DNS, Kerberos, LDAP, SMB, and Global Catalog services immediately suggested that the target was an Active Directory Domain Controller. The scan also revealed the main details of the environment: RDP was exposed on port 3389, and WinRM was available on port 5985, giving us two possible options for remote access if the supplied account had the required permissions. SMB signing was enabled and required, so SMB relay attacks were not a useful direction here. Since we already had valid domain credentials, I focused instead on authenticated enumeration. Adding the Domain to the Hosts File I added the domain name to /etc/hosts so that the tools on my attack machine could resolve it correctly. Validating the Provided Credentials Before continuing, I confirmed that the credentials supplied by the room were valid. The successful authentication confirmed that j.smith was a valid domain user. SMB Share Enumeration I checked the available SMB shares to see whether the account could access any files containing credentials, scripts, backups, or configuration data. The only custom share that stood out was: I connected to it using smbclient. The share was empty, so there was nothing useful to retrieve from it. Enumerating Domain Users Next, I listed the domain users to understand what accounts existed in the environment. Apart from the default domain accounts, the main users were: The descriptions suggested that the accounts belonged to different levels of the IT and Help Desk teams. At this point, I did not have credentials for the other users, but the account names would be useful later. Testing RDP Access Since RDP was open, I checked whether j.smith was allowed to log in remotely. The credentials worked over RDP, so I connected to the system using xfreerdp3. Screenshot 2026-08-05 at 00-35-39 Discovering a KeePass Database While looking through the j.smith profile, I found a file named: The file was located in the Documents folder and was clearly a KeePass database. Since password managers often contain credentials for other users or services, this became the next thing to investigate. I wanted a local copy of the file, so I reconnected through RDP with one of my Linux directories mounted as a shared drive. The shared drive appeared inside the Windows session, allowing me to copy the KeePass database directly to my attack machine. Screenshot 2026-08-05 at 00-38-02 Opening the KeePass Database I first tried opening the database locally. Screenshot 2026-08-05 at 00-39-13 The database asked for authentication, and I did not have the master password. I briefly looked into cracking it, but that approach did not work with the tools available in my setup. Instead of spending more time on that path, I checked whether KeePass was installed on the Windows system. Screenshot 2026-08-05 at 00-43-23 KeePass was already installed, so I opened it directly from the j.smith desktop. Screenshot 2026-08-05 at 00-44-34 The database was already loaded and gave three authentication options: I selected the Windows user account option. Because the database had been tied to the Windows profile, the current j.smith session was able to unlock it without knowing the master password. Screenshot 2026-08-05 at 00-46-30 Inside the database, I found credentials for another domain user: This gave us a new account to test and provided the next step in the lateral movement path. Validating the t.jones Credentials Before connecting through RDP, I validated the recovered credentials using NetExec. The credentials worked successfully, so I connected to the target as t.jones. Connecting as t.jones Screenshot 2026-08-05 at 00-50-41 After logging in, I checked the desktop, documents, running applications, and other accessible locations, but I could not find anything useful. Screenshot 2026-08-05 at 00-52-16 At this point, I was stuck with the t.jones account, so I decided to enumerate the Active Directory environment using BloodHound. Collecting BloodHound Data I used NetExec to collect the BloodHound data through LDAP. The collection completed successfully and generated a ZIP file containing the Active Directory data. I started BloodHound, uploaded the ZIP file, and marked t.jones as owned. After checking the outbound permissions of t.jones, I could not find any useful privilege-escalation path from that account. However, while checking the other users, I noticed that r.williams had interesting permissions. The next objective was to compromise the r.williams account. Enumerating Domain Users I listed the domain users again using the t.jones credentials. The two accounts that were still worth testing were: I added them to a file named users.txt. Testing for Password Reuse Since t.jones and r.williams were both Help Desk users, I tested whether the same password had been reused across their accounts. The password did not work for svc.helpdesk, but it worked for r.williams. The recovered credentials were: I marked r.williams as owned in BloodHound and continued checking the permissions available from this account. Password Reuse Leads to Further Privilege Escalation After compromising multiple user accounts, we discovered that r.williams was also using the same password. Password reuse is one of the most common weaknesses in Active Directory environments because compromising one account often leads to the compromise of additional users. Since we now have valid credentials for r.williams, we can mark the account as Owned in BloodHound to visualize the newly available attack paths. Screenshot 2026-08-05 at 01-04-42 After recalculating the graph, BloodHound reveals a very interesting relationship. The r.williams user has the AddAllowedToAct permission over the DC01$ computer account. This permission allows us to modify the Resource-Based Constrained Delegation (RBCD) configuration of the Domain Controller, which is a well-known privilege escalation technique in Active Directory. Understanding Resource-Based Constrained Delegation (RBCD) Before abusing this permission, it is important to understand what Resource-Based Constrained Delegation actually is. Traditional Kerberos delegation is configured on the account that performs the delegation. Resource-Based Constrained Delegation works differently. Instead of configuring the delegating account, the target computer itself specifies which computers are allowed to impersonate users when connecting to it. This trust relationship is stored inside the Active Directory attribute: If an attacker can modify this attribute on a computer object, they can authorize another computer account under their control to impersonate any domain user, including Domain Administrators, when authenticating to that computer. For this attack we have: | Object | Purpose | |---------|---------| | DC01$ | Target computer we want to compromise | | r.williams | User that has permission to modify DC01