Hello
and welcome to another Hack the Box walkthrough. In this blog post, I am
going to show you how to pwn the TombWatcher machine on hack the box. If you are
new to this channel, please don’t forget to like, comment, and subscribe to my
YouTube channel for more awesome content. Also, don’t forget to follow me on
LinkedIn and X for more HTB walkthrough and cybersecurity related contents.
About the Machine
TombWatcher is a medium-difficulty Windows Active Directory machine that challenges players to exploit misconfigurations in Active Directory Certificate Services (AD CS). The initial foothold is gained through enumeration of vulnerable certificate templates, specifically one that allows low-privileged users to enroll certificates with the Certificate Request Agent application policy. This enables an ESC1-style attack, where a user (cert_admin) can request a certificate on behalf of a high-privileged account like Administrator, ultimately leading to domain compromise. Additionally, players must explore deleted AD objects, leveraging PowerShell to enumerate tombstoned users via Get-ADObject, restore accounts with Restore-ADObject, and regain access by resetting passwords using Set-ADAccountPassword. TombWatcher combines certificate abuse, account recovery, and AD enumeration to simulate realistic attack paths often encountered in enterprise environments.
The first step in solving this machine is to connect my Kali Linux terminal with Hack the Box server. To set up this connection, I ran the following command in my terminal:
After the connection has been set up, I started the target machine, and I was assigned an IP address of 10.10.11.72. Then I performed reconnaissance using Nmap to find all the open port and services associated with the target machine. Using the following command, I found all the services and port running at 10.10.11.72:
After the nmap scan was completed, it displayed all the open ports associated with the target machine.
I noticed an error “Clock skew too great” in the nmap scan. This error is caused due to the time difference between the target machine (10.10.11.72) and our machine. To rectified this, I ran the following command in my terminal:
This command will manually synchronizes your system clock with the time server at IP address 10.10.11.72.
ntpdate queries the specified NTP server (10.10.11.72) for the current time. If successful, it sets your system time to match that server. sudo is required because changing system time needs root privileges.
Then, I saw that the "Clock: time stepped by 14399.848111". Since many Kerberos-based operations depend on accurate time synchronization, I synced my machine’s clock with the Domain Controller using "sudo ntpdate 10.10.11.72". This adjusted my system time by four hours to match the DC's clock, resolving any potential time skew issues that could prevent Kerberos authentication or ticket validation during certificate-based exploitation.
This command opens the nano text editor and I added 10.10.11.72 which I then mapped to tombwatcher.htb DC01.tombwatcher.htb. It is important to map hostnames to IP addresses on your local machine (via /etc/hosts) for several reasons, especially in development, troubleshooting, and networking scenarios. Here's why it matters:
- Local Name Resolution Without DNS: The /etc/hosts file allows your system to resolve hostnames without querying a DNS server. It is useful when DNS is unavailable or misconfigured and when you're in an isolated or internal network.
- Testing and Development: You can point a domain (like myapp.local) to a local or test server (e.g., 127.0.0.1 or a staging IP). For example: 127.0.0.1 myapp.local This allows testing websites or apps locally using human-readable names.
- Security and Control: It can prevent connections to known malicious domains by redirecting them: 127.0.0.1 malicious-site.com
You control name resolution without relying on external DNS, reducing attack vectors.
Previously in the Nmap scan, I found port 80/tcp which has the http server associated with it. It clearly is a website, and I tried to find out what is at this port by typing 10.10.11.72 in my browser. This redirected me to the Internet Information Service page on the official Microsoft Window Server webpage. I inspected the html code and tried to check the robots.txt path but I found nothing.
I noticed on the TombWatcher machine page that there were two credentials that are likely to be a username and password (henry / H3nry_987TGV!) I tried evil-winrm with the credentials in the machine information (As is common in real life Windows pentests, you will start the TombWatcher box with credentials for the following account: henry / H3nry_987TGV!) and tried subdomain blasting but I didn’t find or get anything useful.
After trying few other methods, then I remembered that the TombWatcher is a Windows machine and I immediately thought of using bloodhound. Bloodhound is primarily used in Active Directory (AD) environments to analyze and visualize relationships and permissions for identifying privilege escalation paths and attack vectors. It is widely used by red teamers and penetration testers to gain a foothold inside a Windows network (e.g., via phishing or exploitation). It is also used to escalate privileges, move laterally, or eventually gain Domain Admin rights. To use bloodhound, I ran the following command in my terminal:
This was the output I got:
After downloading the Kerberoast Python file, I moved into the directory I am currently working in (in my case, I moved the file to Desktop > TombWatcherHTB) afterwards I ran the following command in my terminal:
This started the kerberoast attack by fetching usernames from active directory with LDAP. I got a hash for Alfred and attempted cracking it with john the ripper/hashcat.
I copied the hash and created a file called hash.txt and pasted the hash.
After cracking the hash and obtaining the plaintext basketball, I used bloodyAD to check if the account had the ability to modify AD objects. I discovered that I could add users to the INFRASTRUCTURE group:
After adding alfred to the Infrastructure group, I used gMSADumper.py to check for group-managed service accounts (gMSAs) with readable credentials:
The script revealed that ansible_dev$ was a gMSA account whose password could be read by members of the Infrastructure group. Since I was already part of this group, I was able to retrieve the AES keys and NT hash for the account. These credentials could now be used to authenticate as ansible_dev$ — potentially granting me further access to the domain.
Hurray, I got the root flag!!!
After identifying valid credentials for the john account (Test1234.), I used Evil-WinRM to establish an interactive shell on the target:
This gave me PowerShell access as the john user, which I then used to enumerate Active Directory, search for misconfigurations, and perform privilege escalation techniques. After successfully connecting to the target using Evil-WinRM as john, I navigated to the user’s desktop and retrieved the user flag: type ../desktop/user.txt.
Hurray!!! I got the User Flag. This confirmed I had user-level access on the machine. With this initial foothold, I proceeded to enumerate local privileges and look for misconfigurations that could be leveraged for privilege escalation.
Now, it's time to get the root flag.
To investigate the domain history and potential tampering, I queried deleted objects in Active Directory using:
This revealed multiple deleted instances of a user account named cert_admin, all residing in the Deleted Objects container. Each deletion instance had a unique objectSid, indicating the user was deleted and recreated multiple times, possibly as part of a privilege escalation or account abuse chain.
These results helped confirm that cert_admin was central to the compromise, and the LastKnownParent (OU=ADCS) suggested it was related to certificate services exploitation.
After discovering several deleted instances of the cert_admin account using Get-ADObject, I restored the most recent one using:
This brought the account back to its original location under OU=ADCS. Since AD preserves key attributes like objectSid, sAMAccountName, and group memberships during deletion (within tombstone lifetime), I was able to reuse this account to escalate privileges via ADCS certificate template abuse.
After restoring the deleted cert_admin user using Restore-ADObject, I reset its password to a known value using:
Using certipy-ad find -vulnerable, I enumerated vulnerable certificate templates and found that WebServer was both enrollable by my user (cert_admin) and vulnerable to ESC15:
- It allows EnrolleeSuppliesSubject
- It uses Schema Version 1
This means I could request a certificate impersonating any domain user, including Administrator, and use it to obtain a Kerberos TGT and gain full domain access.
To understand more about the ESC15 vulnerability, click here.
After gaining access as cert_admin, I leveraged a misconfigured certificate template (WebServer) that allowed low-privileged users to enroll certificates with the Certificate Request Agent OID. This made it possible for cert_admin to later request certificates on behalf of other users, including Administrator.
I issued a certificate to cert_admin with CRA permissions:
Although the certificate had no identity of its own, it could now be used to impersonate users via a vulnerable template, completing an ESC15 attack chain.
After compromising the cert_admin account, I enumerated the AD CS environment and found that the User certificate template was vulnerable to ESC15 (allows ENROLLEE_SUPPLIES_SUBJECT, and cert_admin had Certificate Request Agent permissions).
I leveraged this misconfiguration to request a certificate on behalf of the domain administrator using:
This gave me a certificate and private key (administrator.pfx) that I used to authenticate as the Administrator:
At this point, I had full domain admin access via PKINIT certificate authentication. After I got the hash "f61db423bebe3328d33af26741afe5fc" for administrator@tombwatcher.htb', I attempted to authenticate to the Windows host at 10.10.11.72 using the Administrator account and an NTLM hash (f61db423bebe3328d33af26741afe5fc) instead of the real password by running the following in my terminal:
After obtaining the evil-winrm shell, I ran the following script to obtain the root flag (Explanation: type was used to display the contents of the file named root.txt located in the Desktop directory one level above the current working directory, which is similar to cat in Linux):
If you enjoy reading my walkthrough, do not forget to like, comment, and subscribe to my YouTube channel and also connect with me on LinkedIn. Also, don't forget to turn on post notification on my YouTube channel and medium to get notification as soon as I write.
Subscribe to my YouTube channel: https://www.youtube.com/@BoltechTechnologies1
Follow me on LinkedIn: https://www.linkedin.com/in/isiaq-ibrahim-468588156/
Follow me on Medium: https://medium.com/@ibrahimbolaji50.ib
Follow me on Twitter: https://x.com/Isiaq_Ibrahim99
Follow me on Twitter: https://x.com/BoltechNG
Buy me a coffee: https://buymeacoffee.com/boltechtechnologies
0 Comments