search

HTB | TombWatcher

Machine - https://app.hackthebox.com/machines/TombWatcherarrow-up-right

IP - 10.129.13.255

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!

hashtag
NMAP

└─$ nmap -sT -p- --min-rate 10000 10.129.13.255 -Pn -oA nmap_ports                                                        
Starting Nmap 7.95 ( <https://nmap.org> ) at 2025-06-08 11:59 IST
Nmap scan report for 10.129.13.255
Host is up (0.61s latency).
Not shown: 65514 filtered tcp ports (no-response)
PORT      STATE SERVICE
53/tcp    open  domain
80/tcp    open  http
88/tcp    open  kerberos-sec
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
389/tcp   open  ldap
445/tcp   open  microsoft-ds
464/tcp   open  kpasswd5
593/tcp   open  http-rpc-epmap
636/tcp   open  ldapssl
3268/tcp  open  globalcatLDAP
3269/tcp  open  globalcatLDAPssl
5985/tcp  open  wsman
9389/tcp  open  adws
49666/tcp open  unknown
49677/tcp open  unknown
49678/tcp open  unknown
49679/tcp open  unknown
49695/tcp open  unknown
49701/tcp open  unknown
49739/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 257.02 seconds

hashtag
Port 53

hashtag
Port 80

We can run auxiliary/scanner/http/iis_shortname_scanner to check for shortname in IIS

on running dirsearch

We saw similar /aspnet_client/ on our is scanner let’s add this to the path and run again

Let’s fuzz for system*~1, and for that let’s make the wordlist

Let’s fuzz

add this to the path and run the is scanner

hashtag
BloodHound

Since we have the credentials, let’s use Bloodhound

hashtag
Foothold/shell

hashtag
Shell as John

hashtag
WriteSPN

We found that henry@tombwatcher.htb -> WriteSPN -> Alfred@tombwatcher.htb

The user HENRY@TOMBWATCHER.HTB has the ability to write to the "serviceprincipalname" attribute to the user ALFRED@TOMBWATCHER.HTB.

So let’s set the SPN for Alfred

Now we can perform kerberoasting

Let’s use hashcat for cracking

Now we have Alfred’s password

Looking back on Bloodhound, we get Alfred@tombwatcher.htb -> AddSelf -> Infrastructure@tombwatcher.htb

The user ALFRED@TOMBWATCHER.HTB has the ability to add itself, to the group INFRASTRUCTURE@TOMBWATCHER.HTB. Because of security group delegation, the members of a security group have the same privileges as that group.

By adding itself to the group, ALFRED@TOMBWATCHER.HTB will gain the same privileges that INFRASTRUCTURE@TOMBWATCHER.HTB already has.

hashtag
ReadGMSAPassword

Infrastructure@tombwather.htb -> ReadGMSAPassword -> Ansible_dev@tombwatcher.htb

ANSIBLE_DEV$@TOMBWATCHER.HTB is a Group Managed Service Account. The group INFRASTRUCTURE@TOMBWATCHER.HTB can retrieve the password for the GMSA ANSIBLE_DEV$@TOMBWATCHER.HTB.

Group Managed Service Accounts are a special type of Active Directory object, where the password for that object is mananaged by and automatically changed by Domain Controllers on a set interval (check the MSDS-ManagedPasswordInterval attribute).

The intended use of a GMSA is to allow certain computer accounts to retrieve the password for the GMSA, then run local services as the GMSA. An attacker with control of an authorized principal may abuse that privilege to impersonate the GMSA.

Since we are the member of the group Infrastructure we should be able to read ansible_dev$'s GMSA Managed Password

there are two ways from which we can get the password

  • to use bloodyad

Now we have NTLM hash of ansible_dev

hashtag
ForceChangePassword

Ansible_DEV$@rombwatcher.htb -> ForceChangePassword -> Sam@tombwatcher.htb

The user ANSIBLE_DEV$@TOMBWATCHER.HTB has the capability to change the user SAM@TOMBWATCHER.HTB's password without knowing that user's current password.

Let’s change the password

hashtag
WriteOwner

Sam@tombwatcher.htb -> WriteOwner -> John@tombwatcher.htb

The user SAM@TOMBWATCHER.HTB has the ability to modify the owner of the user JOHN@TOMBWATCHER.HTB.

Object owners retain the ability to modify object security descriptors, regardless of permissions on the object's DACL.

Let’s set the owner to SAM

hashtag
Shadow Credential

Next, let's give ourselves genericAll permissions on John

Now we can perform shadow credential to get john’s cred

Now we can winrm via hash

and get the user.txt

hashtag
Privilege Escalation

John@tombwatcher.htb -> GenericAll -> ADCS@tombwatcher.htb

The user JOHN@TOMBWATCHER.HTB has GenericAll privileges to the OU ADCS@TOMBWATCHER.HTB.

This is also known as full control. This privilege allows the trustee to manipulate the target object however they wish.

I will check this later (might be able to get us somewhere)

hashtag
Tombstone

What are Tombstones in Active Directory?

When you delete an object from the Active Directory (AD) database, it’s marked as a tombstone object instead of being fully removed. By default, each tombstone object remains in the database for 180 days. Once this tombstone’s lifetime value is exceeded, the tombstone object is automatically deleted by the garbage collection process. Administrators can change the default tombstone lifetime value by using the ADSI Edit tool.

refers to this articlearrow-up-right

Remember to find the LASTEST deleted object as the other objects will have had their permissions revoked.

We can find the object cert_admin let's bring it back to life!

hashtag
GenericAll

Let’s check what permissions we have on cert_admin

We have genericAll on cert_admin

Let’s use shadow credentail to get the hash

hashtag
Shadow Credential

Now we have hash for cert_admin

hashtag
ESC 15

Now we can check for a vulnerable template

We can see ESC15arrow-up-right, let’s exploit

ESC15, also known by the community name "EKUwu" (research by Justin Bollinger from TrustedSec) and tracked as CVE-2024-49019, describes a vulnerability affecting unpatched CAs. It allows an attacker to inject arbitrary Application Policies into a certificate issued from a Version 1 (Schema V1) certificate template. If the CA has not been updated with the relevant security patches (Nov 2024), it will incorrectly include these attacker-supplied Application Policies in the issued certificate. This occurs even if these policies are not defined in, or are inconsistent with, the template's intended Extended Key Usages (EKUs), thereby granting the certificate unintended capabilities.

Step 1: Request a certificate, injecting "Client Authentication" Application Policy and target UPN.

Step 2: Authenticate via Schannel (LDAPS) using the obtained certificate.

Let’s change the password

and we are in as administrator and got root.txt

PreviousHTB | CertificateNextHTB | Vintage

Last updated