HTB | RustyKey

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

IP - 10.129.100.71

Description - As is common in real life Windows pentests, you will start the RustyKey box with credentials for the following account: rr.parker / 8#t5HE8L!W3A

NMAP

└─$ nmap -sC -sV -p 53,88,135,139,389,445,464,3269,5985,9389,47001,49664,49666,49670,49673,49674,49677,49692,56212 10.129.100.71 -Pn -oA nmap_port_details
Starting Nmap 7.95 ( <https://nmap.org> ) at 2025-06-29 11:18 IST
Nmap scan report for 10.129.100.71
Host is up (0.82s latency).

PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-06-29 13:48:45Z)
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp   open  ldap          Microsoft Windows Active Directory LDAP (Domain: rustykey.htb0., Site: Default-First-Site-Name)
445/tcp   open  microsoft-ds?
464/tcp   open  kpasswd5?
3269/tcp  open  tcpwrapped
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
9389/tcp  open  mc-nmf        .NET Message Framing
47001/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open  msrpc         Microsoft Windows RPC
49666/tcp open  msrpc         Microsoft Windows RPC
49670/tcp open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
49673/tcp open  msrpc         Microsoft Windows RPC
49674/tcp open  msrpc         Microsoft Windows RPC
49677/tcp open  msrpc         Microsoft Windows RPC
49692/tcp open  msrpc         Microsoft Windows RPC
56212/tcp open  msrpc         Microsoft Windows RPC
Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
| smb2-time: 
|   date: 2025-06-29T13:49:44
|_  start_date: N/A
|_clock-skew: 8h00m04s

Service detection performed. Please report any incorrect results at <https://nmap.org/submit/> .
Nmap done: 1 IP address (1 host up) scanned in 87.84 seconds

SMB / LDAP

We can see that the NTLM authentication is disabled, so we switch to Kerberos and successfully authenticate:

Bloodhound

Got the list of usernames from the Bloodhound zip

We can see the members of Remote Management Users group, so we can somewhat guess which account would have user flag, and we can manually explore with Inbound Object Control to check the Bloodhound/AD path to them

Now we have three options EE.REED , GG.ANDERSON and BB.MORGAN

HELPDESK -> ForceChangePassword -> BB.MORGAN

Now we need to find the way to get to HELPDEK

Now we have two options either get the credentials for NN.MARCOS or IT-COMPUTER3

Foothold/ Shell

Shell as BB.Morgan

The path which will give us shell will look like IT-COMPUTER3 - > HELPDESK - > BB.MORGAN

Timeroasting

Timeroast is a technique that abuses the NTP service on a domain controller to leak MD5 password hashes for domain user accounts. These hashes can be cracked offline to recover plaintext passwords. The attack targets the Secure NTP (SNTP-MS) mechanism that encrypts NTP responses based on a user’s password.

There is a white paper for TimeRoasting (refer to thisarrow-up-right), and this git repoarrow-up-right

Timeroasting takes advantage of Windows' NTP authentication mechanism, allowing unauthenticated attackers to effectively request a password hash of any computer or trust account by sending an NTP request with that account's RID. This is not a problem when computer accounts are properly generated, but if a non-standard or legacy default password is set this tool allows you to brute-force those offline.

we can get the sid of IT-COMPUTER3 either from bloodhound or it’s json data

cracking hash

We need to crack the hash for RID 1125

we get the password for IT-Computer3$:Rusty88!

we can confirm the credential via netexec

AddSelf to Helpdesk

Now we can change password for bb.morgan

ForceChangePassword

When we try to validate the new credentials, we get KDC_ERR_ETYPE_NOSUPP

KDC_ERR_ETYPE_NOSUPP error indicates that the KDC does not support the encryption type our tools are using for those accounts.

Let’s look at the bloodhound result again

We can see that BB.MORGAN -> MemberOf IT -> MemberOf -> PROTECTED OBJECTS -> MemberOf -> PROTECTED USERS

The key issue is likely the PROTECTED USERS group. Users in this group have restrictions that:

  1. Disallow the use of NTLM, Digest, and CredSSP.

  2. Only allow Kerberos with AES encryption.

  3. Disallow delegation, including unconstrained delegation.

This explains the KDC_ERR_ETYPE_NOSUPP error when using Kerberos with weak encryption or incompatible settings.

Since HELPDESK -> AddMember -> PROTECTED OBJECTS -> MemberOf -> PROTECTED USERS

We can remove IT from it and then we can change the password of BB.MORGAN and able to authenticate

GetTgt for bb.morgan

evil-wirm is not working so we need to get the tgt for bb.morgan

found user.txt

Privilege Escalation

Shell as EE.Reed

We can see there is a pdf internal.pdf let’s copy to our machine and open it

This memo mentions an archiving tool having unrestricted access for testing purposes. It notes that some context menus may not function correctly, and registry-level adjustments might be needed, indicating that the tool’s registry entries may have excessive permissions.

HELPDESK can change passwords for DD.ALI , EE.REED AND GG.ANDERSON as well

Since the memo was sent to SUPPORT And we know that EE.REED is a member of SUPPORT and HELPDEK can change the password, but before that before, we need to remove SUPPORT from PROTECTED OBJECT

not able to auth via ldap but smb we get

This error occurs because the domain join user account lacks the Access this computer from the network user right at the domain controller (DC) servicing the domain join operation.

Reverse shell

I tried PSsession but it gives error

we can use RunasC

Shell as mm.turner

Writable Registry

We can use the below script to check for writable registry keys under HKLM:\\SOFTWARE

This gives us many registry for 7-zip

We see that the InprocServer32 registry has a COM server DLL pointing to C:\\Program Files\\7-Zip\\7-zip.dll that gets loaded into the client process when this CLSID is used.

Checking the ACLs for this registry, we see that members of the Support domain group have full control over it:

COM Hijacking

Feature

DLL Hijacking

COM Hijacking

Target

Executables and DLL loading

Registry-based COM class loading

Vector

Search order abuse

Registry redirection of CLSID or ProgID

Persistence?

No (unless abused in autostart apps)

Yes — hijacked COM objects persist

PrivEsc?

Yes, if hijacked process runs as SYSTEM

Yes, if hijacked COM object runs as SYSTEM

Ease of detection

Medium (DLL file on disk)

Harder — resides in the registry

Trigger Method

App must load the DLL

COM object must be instantiated

We first generate a reverse shell payload in .dll format using msfvenom:

We then transfer the payload to the target host and point the InprocServer32 registry at the full path of the .dll file

After few seconds, we get a reverse shell as the mm.turner user on our listener

Shell as Administrator

Looking at the bloodhound we know that MM.TURNER -> MemberOf DELEGATIONMANAGER -> AddAllowedToAct -> DC.RUSTYKEY

The members of the group DELEGATIONMANAGER@RUSTYKEY.HTB have can modify the msds-AllowedToActOnBehalfOfOtherIdentity attribute on the computer DC.RUSTYKEY.HTB.

The ability to modify the msDS-AllowedToActOnBehalfOfOtherIdentity property allows an attacker to abuse resource-based constrained delegation (RBCD) to compromise the remote computer system.

We can either use a controlled user account that we can set an SPN for (dd.ali) or a controlled machine account (IT-Computer3$) for this attack. We also require the Rubeus.exe tool, since we're performing it from a Windows host:

RBCD Attack (Machine Account)

We first retreive the security identifier (SID) of the IT-Computer3$ machine account:

We then build a generic ACE with the SID as the principal(new DACL with IT-Computer3$’s SID that grants it GenericAll rights), and get the binary bytes for the new DACL/ACE, which will be needed for setting the msDS-AllowedToActOnBehalfOfOtherIdentity attribute.

Next, we set this security descriptor in the msDS-AllowedToActOnBehalfOfOtherIdentity field of the domain controller

This step effectively allows IT-Computer3$ to impersonate any user when accessing the DC.

We then use Rubeus to hash the plaintext password of IT-Computer3$ into its RC4_HMAC form:

Finally, we use the s4u module of Rubeus to get a service ticket for the backupadmin user, which is a member of Domain Admins:

System Shell

We copy and paste the Base64-encoded ticket, decode it and redirect the output to a file:

We then use the ticketConverter.py from the Impacket suite to convert the ticket into .ccache format:

We export the ticket and use the psexec.py from the Impacket suite to get a SYSTEM shell on the domain controller:

and we have root.txt

Last updated