# TryHackMe Operation Endgame—Writeup Welcome back to my CTF writeup! In this post, I’ll take you through a detailed, step-by-step walkthrough of how I successfully pwned **Operation Endgame**, one of TryHackMe’s latest machines for March 2026. This challenge is all about **Active Directory (AD)**, so we’ll explore every angle—from enumeration and privilege escalation to domain exploitation. I’ll share every tool, technique, and thought process I used to go from initial access to full domain control. Whether you’re new to AD hacking or sharpening your pentesting skills, this writeup will guide you through the entire journey. Let’s dive in and take down this AD environment!

#### Intended Solution We start by using **Nmap** to discover open ports and potential entry points. `nmap -sV -sC 10.67.132.244`

From the port scan results, it’s evident that the target is operating as a Domain Controller (DC). This conclusion is supported by the presence of several key Active Directory services: * **88** – Kerberos * **389 / 636 / 3268 / 3269** – LDAP (including LDAPS and Global Catalog) * **445** – SMB * **53** – DNS The combination of these services strongly indicates that we are dealing with an Active Directory environment. We also identified the hostname as **AD** and the domain name as **thm.local**. To ensure proper name resolution, we added the following entry to our `/etc/hosts` file:

The next step is to verify whether the Guest account has access to the domain.\\ `nxc smb AD.thm.local -u 'guest' -p '' --shares`

Using `nxc smb`, we confirmed that authentication with the Guest account is successful. Additionally, the Guest account is able to bind to the LDAP service. `nxc ldap AD.thm.local -u 'guest' -p ''`

Since the Guest account has access to LDAP, we can leverage it to enumerate domain users, particularly those with Service Principal Names (SPNs) configured. Accounts with SPNs are considered **Kerberoastable**, meaning we can request service tickets (TGS) for them from the Key Distribution Center (KDC). These tickets are encrypted using the target account’s password hash, allowing us to extract them and perform offline password cracking. This works because, in Active Directory environments, any authenticated domain user—including low-privileged accounts like Guest (if permitted)—can request service tickets for service accounts. The Kerberos protocol does not restrict who can request these tickets; it only verifies that the requester is authenticated. As a result, if weak passwords are used for service accounts, we may be able to crack the ticket offline and recover plaintext credentials, potentially leading to privilege escalation within the domain. `nxc ldap AD.thm.local -u 'guest' -p '' --kerberoasting kerbs.txt`

Using `nxc`, we identified a Kerberoastable account and successfully retrieved the TGS hash for the **cody\_roy** account. Now we can crack it using `john` `john kerbs.txt --wordlist=/usr/share/wordlists/rockyou.txt`

Let's try login to RDP using `cody_roy's` credentials While exploring the system, I found a `C:\Scripts` directory; however, `cody_roy` seems to have restricted access rights.

To explore more further, with `cody_roy’s` credentials obtained, we can proceed to enumerate the Active Directory environment using `BloodHound`. `bloodhound-python -u 'cody_roy@thm.local' -p 'REDACTED' -dc AD.thm.local -d thm.local -ns 10.65.190.173 --dns-timeout 10 --zip --dns-tcp -c All`

(The target IP address changed because I restarted the machine instance due to connectivity issues.) Now let's start using `BloodHound`!

The `cody_roy` account possesses some notable permissions. As a member of the **EVERYONE** group, the user has **GenericWrite** rights over multiple domain users. This level of access enables us to potentially carry out attacks such as a **Shadow Credentials** abuse or a **targeted Kerberoasting** attack against those accounts. However, upon initial inspection, the affected users do not appear to hold any privileged roles or significant group memberships that would immediately lead to escalation.

Since `cody_roy` is not a member of any elevated groups, further privilege escalation from this account appears limited. However, since we have recovered a valid password, we can perform a password spraying attack hoping whether other accounts are reusing the same credentials. We will use `nxc` again to enumerate all the users: `nxc ldap AD.thm.local -u 'cody_roy' -p 'REDACTED' --users`

After that, I dumped everything into a `.txt` file and filtered it down to just the usernames. `awk '{print $5}' usernames.txt > clean_usernames.txt` The command `awk '{print $5}' usernames.txt > clean_usernames.txt` uses **AWK**, a text-processing utility, to extract the fifth column from each line of the file `usernames.txt`. In AWK, `$5` refers to the fifth whitespace-separated field in every line. The command processes the input file line by line, prints only the fifth field, and then redirects (`>`) the output into a new file called `clean_usernames.txt`. As a result, the new file will contain only the values from the fifth column—which are the usernames—listed line by line.

We then used `nxc` once more, leveraging the compiled user list and the recovered password to conduct a password spraying attack. `nxc smb AD.thm.local -u clean_usernames.txt -p 'REDACTED' --continue-on-success`

We discovered that the `zachary_hunt` account is using the same password. Let's check the permission of `zachary_hunt` in BloodHound:

From further enumeration, we observed that this account has **GenericWrite** privileges over the **jerri\_lancaster** user. This permission can be abused to conduct a targeted Kerberoasting attack. By leveraging our write access, we can temporarily assign a malicious SPN to the target account and then request a service ticket for it. Once the ticket is obtained, we can extract the hash and proceed with offline password cracking, following the standard Kerberoasting process. We leveraged `targetedKerberoast` to request a service ticket and extract the hash for `jerri_lancaster`. `./targetedKerberoast.py -v -d 'thm.local' -u 'ZACHARY_HUNT' -p 'REDACTED' --dc-host AD.thm.local --request-user JERRI_LANCASTER`

Now let's crack it using `john` :

Now let's analyze `jerri_lancaster` in BloodHound:

Analyzing the account in BloodHound reveals that `jerri_lancaster` belongs to the **Remote Desktop Users** group. At this stage, we can leverage the compromised `jerri_lancaster` account to log in through RDP with `xfreerdp3`. `xfreerdp3 /v:AD.thm.local /u:'JERRI_LANCASTER' /p:'REDACTED' /dynamic-resolution /clipboard /cert:ignore`

Now we sucessfully access the windows server:

We’ve successfully accessed the `C:\Scripts` directory. Inside, we found a PowerShell script—let’s examine its contents. `more syncer.ps1`

Upon reviewing the script, we discovered that it contains credentials for the `sanford_daugherty` user.

That's it! Now we can use `impacket-smbexec` to spawn a shell as `SYSTEM` .

With `SYSTEM` privileges acquired, we can now locate and read the flag.

#### Unintended Solution By analyzing the BloodHound data collected earlier, we observed that the **Guest** account has several assigned permissions. Most notably, it possesses **GenericWrite** rights over the Domain Controller, which is particularly significant.

With **GenericWrite** access over the Domain Controller object, we can abuse this privilege by modifying the `msDS-AllowedToActOnBehalfOfOtherIdentity` attribute. This attribute controls **Resource-Based Constrained Delegation (RBCD)**, a feature in Active Directory that allows one account to impersonate users when accessing a specific resource. By altering this attribute, we can configure the Domain Controller to trust an account we control, effectively allowing us to impersonate privileged users—such as a Domain Admin—when authenticating to the DC. To successfully perform this attack, we need an account that has a **Service Principal Name (SPN)** set and that we fully control. Typically, attackers create a new computer account for this purpose because computer accounts automatically have SPNs configured by default. However, in our case, this extra step is unnecessary. From our earlier Kerberoasting phase, we already identified that the **cody\_roy** account has an SPN configured, and we successfully recovered its password. Since we control this account and it already satisfies the SPN requirement, we can directly use it to carry out the RBCD attack without creating a new machine account. This significantly simplifies the exploitation process and moves us one step closer to full domain compromise. `impacket-rbcd THM.LOCAL/guest -no-pass -dc-ip 10.66.129.137 -delegate-to AD$ -delegate-from CODY_ROY -action write -hashes :31D6CFE0D16AE931B73C59D7E0C089C0`

We executed a Resource-Based Constrained Delegation attack within the **THM.LOCAL** domain. We authenticated as the **Guest** account using the well-known empty NTLM hash `31D6CFE0D16AE931B73C59D7E0C089C0`. This allowed us to modify the **AD$** computer object, configuring it to trust the `cody_roy` account for delegation. As a result, the `cody_roy` account is now permitted to impersonate users when accessing the Domain Controller via Kerberos delegation mechanisms. This misconfiguration opens the door to privilege escalation, as we can potentially impersonate a highly privileged user—such as a Domain Administrator—and obtain elevated access within the domain. Next, we utilized `impacket-getST` to authenticate as the `cody_roy` account using its recovered password. Through this tool, we requested a Kerberos service ticket for the SPN `cifs/AD.THM.LOCAL` while leveraging delegation to impersonate the **Administrator** account. `impacket-getST -spn "cifs/AD.thm.local" -k -no-pass "THM.LOCAL/CODY_ROY:MK0)mko0" -impersonate "Administrator"`

As a result, we obtained a service ticket that grants us access to the CIFS service on `AD.THM.LOCAL` with the privileges of the **Administrator** user, effectively allowing us to operate with elevated domain-level access. We configured the `KRB5CCNAME` environment variable to point to the Kerberos ticket cache file `Administrator@cifs_AD.THM.LOCAL@THM.LOCAL.ccache` that we previously obtained. `export KRB5CCNAME=Administrator@cifs_AD.THM.LOCAL@THM.LOCAL.ccache` Using the acquired ticket alongside `impacket-smbexec`, we successfully spawned a shell running as SYSTEM on the Domain Controller.

From an initial low-privileged **Guest** account, we systematically enumerated the Active Directory environment and uncovered multiple misconfigurations. We leveraged LDAP access to identify Kerberoastable accounts, cracked weak credentials through offline password attacks, and abused password reuse via spraying. From there, we escalated by exploiting **GenericWrite** permissions to perform a targeted Kerberoasting attack, pivoted through RDP access, and extracted additional credentials from a poorly secured PowerShell script. But the real breakthrough came when we identified **GenericWrite** permissions over the Domain Controller itself. By abusing **Resource-Based Constrained Delegation (RBCD)**, we modified the `msDS-AllowedToActOnBehalfOfOtherIdentity` attribute, leveraged Kerberos delegation (S4U), impersonated the **Administrator**, and ultimately obtained a SYSTEM shell on the Domain Controller. This machine was a perfect demonstration of how small misconfigurations in Active Directory — such as weak passwords, excessive write permissions, and improper delegation settings — can chain together into full domain compromise. Operation Endgame truly lived up to its name. From Guest to Domain Controller — complete takeover. Until the next machine.