HTB - Resolute
Zweilosec's write-up of the medium-difficulty Windows machine Resolute from https://hackthebox.eu
Overview

A medium-difficulty Windows box that was fairly straightforward. Privilege escalation required going through two different users and taking advantage of Windows domain group permissions. It ended with a privilege escalation route that required a simple dll injection, and a bit of quick reaction.
Useful Skills and Tools
Connect to a Windows computer through Windows Remote Management (WinRM)
evil-winrm -i <ip> -u <username> -p '<password>'
Using ldapsearch to enumerate a Windows domain
ldapsearch -H ldap://<ip>:<port> -x -LLL -s sub -b "DC=<domain>,DC=local"
Enumerating users on a Windows domain with rpcclient (without credentials)
rpcclient -U "" -N <ip>
rpcclient $> enumdomusers
rpcclient $> queryuser <user_RID>
Useful Windows groups
Remote Management Users
DnsAdmins
Creating an SMB share from linux
sudo python3 /usr/share/doc/python3-impacket/examples/smbserver.py -debug SHARE ~/
Enumeration
Nmap scan
First, I started my enumeration with an nmap scan of 10.10.10.169. The options I regularly use are: -p-, which is a shortcut which tells nmap to scan all TCP ports, -sC is the equivalent to --script=default and runs a collection of nmap enumeration scripts against the target, -sV does a service scan, -oA <name> saves all types of output (.nmap,.gnmap, and .xml) with filenames of <name>.
From these results we can see there are a lot of ports open! Since ports 88 - kerberos, 135 & 139 - Remote Procedure Call, 389 - LDAP, and 445 - SMB are all open it is safe to assume that this box is running Active Directory on a Windows machine. The host script also validates this by reporting to us that this is running Windows Server 2016 Standard 14393.
ldapsearch
Since I had so many options, I decided to start by enumerating Active Directory through LDAP using ldapsearch. This command is built into many linux distros and returned a wealth of information. I snipped out huge chunks of the output in order to reduce information overload as most of it was not particularly interesting in this case.
The Remote Management Users group contains the user named Melanie Purkis and the group Contractors. We should keep an eye out for more information about those, as Windows Remote Management is an easy way to access a shell on a Windows machine remotely.
This host named RESOLUTE looks important. It contains the DNS server, Kerberos server, and is running LDAP and RPC. It is also in the Domain Controllers OU! Looks like a good target.
The DnsAdmins group contains the Contractors group. If there are any members of the Contractors group they have the permissions for administration of the DNS servers.
So there is a SYSVOL share. We should try to connect to it and see if we can retrieve any useful information.
The Contractors group is a member of both the DnsAdmins and Remote Management Users groups. If there are any users in this group we should target them.
A potential hostname for a Kerberos server? MS02.megabank.local
The user ryan is a member of the Contractors group. This may be very useful.
The next user had some interesting information in the description field:
So it seems we have a potential username and password! marko:Welcome123!.
Hmmm...the user melanie is a member of the Remote Management Users group. This looks like another good target for gaining access.
Interesting users/groups found
There was no interesting information in the other users, but I made a list of their usernames, just in case. So far the interesting users were:
marko: has a potential password in his description field
Welcome123!.melanie: a member of the
Remote Management Usersgroup.ryan: a member of the
Contractorsgroup, which is also a member of both theRemote Management Usersand theDnsAdminsgroup.
rpcclient
Next I used rpcclient to validate the information I found through LDAP using the enumdomusers and queryuser <rid> RPC commands.
Hmm...so the user marko has no home drive or profile path, and has never logged on. Maybe the user was only created on the domain but has no local account?
Initial Foothold
I tried using the creds for marko to enumerate SMB but got nothing back. I then tested his password with the users ryan and melanie and was able to get a share listing with melanie:Welcome123!Thank you password reuse!
Next, I tried connecting to each of the shares. We only see the standard Windows domain shares, nothing out of the ordinary. Only NETLOGON and SYSVOL allowed melanie to log in, but neither contained anything useful. SYSVOL had more folders to browse through, but still nothing useful.
Road to User
Since melanie is a member of the Remote Management Users group, I tried to log in through Windows Remote Management using the Evil-WinRM tool, which can be found at https://github.com/Hackplayers/evil-winrm.
I'm in!
user.txt
whoami /all didn't reveal any information that we didn't already know, so we will have to continue searching for useful things. I did find the user flag on melanie's \Desktop though!
Path to Power (Gaining Administrator Access)
Enumeration as User - melanie
Since we noticed the user ryan earlier had access to the DnsAdmin group, I figured that it would be good to search for any files with his name in it. Since we are in a Powershell environment, Get-ChildItem is the command we want. ls is a common alias to that command which is why the below command works. -R Makes the search recursive, -Hidden includes hidden files in the search, -EA SilentlyContinue is shorthand for -ErrorAction Silently Continue and specifies that we do not want to see any errors that result (such as files or directories that we don't have access to). Select-String is similar to the Linux grep command.
It seems as if the user ryan used the net use command to connect to an external share, leaving his credentials ryan:Serv3r4Admin4cc123! in the Powershell transcripts! We can now try to login as ryan using Evil-WinRM since he is also a member of the Remote Management Users group.
User #2 - ryan
Privilege escalation - DnsAdmins
Next I did a little research to see if the DnsAdmins group had any known privilege escalation routes, and found this interesting article describing how to escalate privileges by doing dll injection: https://www.abhizer.com/windows-privilege-escalation-dnsadmin-to-domaincontroller/. The author lists the steps to accomplish this as:
Making a dll payload that sends a reverse shell back to our machine with msfvenom.
Serving it using SMB Server to make it available to the Windows machine.
Importing that dll in the DNS Server.
Restarting the DNS Server so that it loads the dll file.
In my case, I was not able to get the dll injection to provide a reverse shell, so I came up with another route. I did use msfvenom to craft my dll to inject, but since the reverse shell payload failed, I decided to simply promote my current user account to Domain Admin.
Since we need to run a command to grant our user Domain Admin privileges we need to use the windows/x64/exec module. (Making sure to choose the right architecture. This machine is x64.) The command net group "domain admins" ryan /add /domain will add the user ryan to the domain admins group.
Creating an SMB share from linux
I then hosted my dll on an SMB share so I could access it from the Windows machine without transferring it fand storing it on the remote disk. This is useful for loading executables directly into memory to bypass AV. The Impacket python module library has an example smbserver that is ready-made to this. I created a share named SHARE from my local user's home directory with sudo python3 /usr/share/doc/python3-impacket/examples/smbserver.py -debug SHARE ~/
After logging back in as ryan with Evil-WinRM,
I used the dnscmd.exe program to interact with the DNS service and telling it to load my crafted dll from the remote share.
According to the article, you next have to stop and restart the DNS service. You can do this using sc.exe(Don't just type sc as this is an alias for Set-Content in Powershell and will not work.)
Back at my SMB server, I saw the incoming connection from the RESOLUTE machine. The dll was only retrieved when the DNS service was restarted, so don't worry if you don't see the request for the file when you run the earlier command.
In order for the new permissions to take effect I had to log out of the user and log back in.
Domain Admin
After logging out and back in, I verified that the user ryan was indeed a member of the Domain Admins group and had the right privileges.
root.txt
After escalating to Domain Admin it was simple to find the root flag on the Administrator's Desktop\. I did continue to run into one problem...other HTB users kept either resetting the box, or running the exploit themselves and in the process killing my shell. It helps to know where the flag is and to grab it as quickly as possible!
Thanks to egre55 for a fun and easy Windows box. I did still learn some new things while going though this one.
If you like this content and would like to see more, please consider buying me a coffee!
Last updated
Was this helpful?