A Hack the Box Walkthrough — Resolute
Spoilers ahead!
This blog will cover the general methodology I use when solving Hack The Box challenges. Today, we have the “Resolute” box which I have recently solved and is now retired.
First, we’ll start with a TCP scan, and if no interesting services are found, we can switch to a UDP scan to uncover more potential attack surface. I use a standard nmap command that enumerates all ports & services on a target machine. You can see example output from running the command below:
Sign up to get our latest blogs.
The -sS flag informs nmap to run a TCP SYN scan, otherwise known as a stealth scan. However, that name is misleading because most modern firewalls and loggers will catch TCP SYN scans. SYN scans stop short of completing the 3-way TCP handshake. While the scan is running it will initiate a TCP connection on every port specified by the -p flag. The ‘-p-’ flag instructs nmap to scan all 65355 ports. Due to the -sS directive, nmap will initiate a connection with the target server by sending a TCP SYN request to the ports designated by the -p flag. If the server receives a TCP SYN packet on an open port, the server will respond by sending a TCP SYN ACK response packet back to the client. When nmap receives a response packet, it will send a reset packet back to the specified port on the server, terminating the connection. Nmap then marks this port as open and continues the scan. Historically, firewalls only logged connections that have completed the TCP handshake, however, this is no longer the case. A stealthier version of a scan would involve performing some reconnaissance and making educated guesses as to what ports may be open.
The -sC directive instructs nmap to run all the default scripts against the ports it identifies as open on the target machine. For example, if nmap identifies port 445 Server Message Block (SMB) as open, then nmap may run a script to identify if we have the capability of connecting to the SMB server anonymously, in addition to enumerating any open shares.
The -sV flag instructs nmap to run it’s versioning scripts against the services identified as open. This means that nmap will attempt to enumerate versions of services running on the target server. This is particularly useful for identifying vulnerable and easily exploitable services during the reconnaissance phase.
Finally, the -oA resolute flag instructs nmap to save the results of the scan in all possible supported formats in the current directory starting with the name resolute.nmap, resolute.gnmap, and etc.
The last option is the name or hostname of the our target.
Based on the results of the scan, we can tell this machine is running Windows because of a few results in the scan. The first is a few ports that are open usually belong to Windows Active Directory servers. These being 88/tcp Kerberos, 389/tcp LDAP, and 3268/tcp LDAP. We also see a number of other Windows services such as SMB, Microsoft RPC (Remote Procedure Call), and Windows RM (Remote Management). Finally, we also see that due to our -sC directive, our scan identified the OS through the SMB service (Windows Server 2016 Standard 6.3).
The first step after scanning is identifying the services that are usually misconfigured and may result in disclosing more information. In this case, the services most likely to meet this criteria are SMB, LDAP, and Kerberos. However, for this machine we only needed SMB.
In order to extract information from SMB, we can use a tool that comes pre-installed in Kali Linux called smbclient. In order to list all the shares, we need to specify the -L flag, as shown below:
When running the command we are prompted to enter a user’s password. If we do not specify a user, it defaults to our current user, which in this case is root. Generally speaking, there is no ‘root’ user on Windows machines, thus smblcient will attempt to login anonymously and we can enter anything into the prompt. We are then presented with an ‘Anonymous login successful’ message; however, notice that there are no shares listed in the Sharename column. This indicates the anonymous user lacks sufficient permissions to access any shares that might reside on the server.
Now that we know we can connect anonymously, our next step is to enumerate the SMB service using a tool called enum4linux. Enum4linux is a great tool because it will perform share enumeration, password policy retrieval, identification of the remote OS, etc. Running enum4linux looks like the following, for brevity the output will be trimmed:
The -a directive informs enum4linux to run all checks against the target specified. We have trimmed the output to only the important sections. The groups and Users on this machine are the key to getting a shell on the machine. Looking at the user information we see an account named ‘Marko Novac’. This account has a description of ‘Account created. Password set to Welcome123!’. Additionally, the local group membership section has the message “Group ‘Remote Management Users’ (RID: 580) has member: Couldn’t lookup SIDs”. This message indicates that the group ‘Remote Management Users’ has members and can use the service on port 5985! However, in this particular case, the members couldn’t be found by looking up their Security Identifiers. Now we have a list of users and a potential password. When finding potential credentials it’s good to test them against a list of potential users to see if you can own multiple accounts.
The resolute box has many services to test our list of users and potential password against. These services include the SMB service, Kerberos, RPC, WinRM, etc. The service users will most likely have access to is SMB, so we attack that service first. Metasploit has a great module for this purpose. After you create wordlist of usernames, start up the metasploit framework by typing msfconsole. Next, type in ‘use auxiliary/scanner/smb/smb_login’. Then to show the options the module supports, type ‘show options’. Finally, to set the remaining options, type ‘set <option name> <value>’. For example, set RHOSTS resolute sets the RHOSTS option to the resolute server. For our purposes, we need to set USER_FILE, SMBPass, and the RHOSTS options. With those three set type ‘run’ to launch the attack. Output from running the command is shown below:
The attack succeeds against the melaine user.
The next step at this point is to re-enumerate with our valid credentials. However, further enumeration doesn’t return any successful results.
At this stage it’s safe to use our credentials to attempt remote login. I mentioned earlier the ‘Remote Management Users’ group, however, I didn’t find out which users belonged to that group. Thus, we will test group membership by attempting to access the WinRM service on port 5985. Evil-winrm is a tool that is written in ruby and gives us the ability to remotely manage Windows machines from the command line. Evil-winrm can do many useful things like loading malicious powershell scripts into memory on the target server. I highly recommend adding it your arsenal: https://github.com/Hackplayers/evil-winrm
Using this tool to get a shell is simple:
The syntax is as follows:
- -u directive specifies the user name
- -p specifies the password
- -i identifies the target IP address
- -s flag specifies the location of powershell scripts we want loaded into memory
After getting a shell, congratulate yourself by extracting the user flag.
Next step is to enumerate any information we can about the current user account we have access to on the target machine. However, we realize that our current user account does not have the permissions necessary to execute scripts & executables. This hinders the enumeration process enough to force us out of the standard upload & execute enumeration script cycle. So, we run a whoami /all command to gather some basic information regarding our current user.
Running this command doesn’t give us much useful information besides what we already know. Additionally, we can’t execute scripts or executables to do further enumeration. This indicates that there must be another way to escalate privileges. At this point, we should be performing manual directory enumeration to see if there’s any folders or files that could help escalate privileges.
In this part of the process, you want to look for .ini or config files that may contain credentials. Sometimes you can also find vulnerable services running on the machine. However, for brevity we’ll move to the next step since there’s nothing in these folders that helps us. However, doing some research indicates a way to list HIDDEN files and folders on Windows by specifying the -force flag. Again we enumerated the C:/ folder using the dir command with the -force flag.
Immediately a folder that sticks out is the PSTranscripts folder. Enumerating that folder is a good idea since it’s hidden and a non-standard windows folder.
The the files and folders are hidden in the PSTranscripts folder, therefore we won’t see anything unless we specify the -force option.
The previous command identifies another directory 20191203. We can repeat this process recursively until all files and folders are identified.
At the end we find an interesting text file. Let’s output the contents to the terminal.
The text file appears to be a log. The log indicates a user attempting to mount a network drive with credentials. The the user account name is ‘ryan’ with a password of ‘Serv3r4Admin4cc123!’
With our new credentials, repeat the credential testing process as done previously.
The testing process returns a match for the ‘ryan’ account with a password of ‘Serv3r4Admin4cc123!’. Although this was specified in the log file, you never want to skip the credential testing step. Passwords are often reused by administrators, as well as users. This gives us opportunities to kill two birds with one stone. Now that we’ve verified our credentials, we need to use evil-winrm to log back in as the ‘ryan’ user. Normally, you’d want to repeat the enumeration process whenever you find new credentials; however, it’s not necessary for this machine.
We have successfully escalated privileges to the ryan user! Next I will show you what it looks like to have powershell modules loaded into memory using evil-winrm’s -s directive.
When you’ve specified a directory to load modules with, you then want to invoke the script that was loaded by using the name of the script. Once that is completed, run the menu command to get a list of all the new modules loaded.
All this takes place without ever storing files one the server. The next step is to repeat the enumeration process by executing the Invoke-AllChecks module and seeing what is returned.
However, we can see that very little or no information is returned to us after running this module. I ran other scripts at this point as well, which all returned no data. This situation is very similar to before when we were the melanie user, thus manual enumeration is necessary.
The whoami /all command returned some interesting artifacts. The first is the domain groups we belong to contractors, and DNSAdmins. It took a small amount of research to identify the DNSAdmins group as being exploitable to escalate privileges through dll injection. This attack works by injecting a malicious dll that will be run the next time the DNS service is restarted. Since we are a part of the DNSAdmins group, we should have sufficient privileges for this attack. First create a malicious dll file using the Metasploit Framework’s Msfvenom tool. The command looks like the following:
- -a directive specifies the architecture of the machine that will be running the payload
- -p directive specifies the payload itself, in this case a Windows 64-bit reverse tcp shell
- LHOST and LPORT flags are the IP address and port that we want our shell to connect back to
- -f directive specifies the format we want our shellcode to be created in
- ‘> privesc.dll’ informs our bash shell to take the output from the command and save it to a file named privesc.dll
In this case, and in most other real-life cases, you’d want to serve a payload like this remotely to prevent the antivirus from detecting the payload.
Once the payload is created, configure the DNS service to connect back to your machine and load the malicious dll when the DNS service restarts.
The command above instructs the resolute DNS server to load a DLL from a network share located at 10.10.14.20 (our machine). We verify that our settings saved correctly by typing the following command:
In order to serve the malicious dll, start an SMB server on your local machine using Impacket’s smbserver. The syntax for the command is as follows:
Start by ensuring the current folder contains the privesc.dll file, and then invoke the smbserver.py command. The word ‘resolute’ is an argument that specifies the network share name. The ‘.’ is a special character in bash that represents the current directory. Thus, the command reads ‘smbserver.py, resolute, current directory’. Next start a netcat listener that will receive our reverse shell when DNS service restarts.
We specify port 443 because that is what we specified when we created our reverse shell using msfvenom. Additionally, it’s important to try and use the ports of commonly used services like HTTPS in a small attempt to trick fire walls, or maybe threat hunters, into allowing or ignoring the traffic.
Finally, we are ready restart the DNS service. If all goes well, we should get a connection to our SMB server from the resolute machine. The resolute machine will load the dll file and execute, which forces resolute to connect back to our netcat listener.
The attack in full form looks like the following:
Then back on our SMB server we should receive a connection:
Then finally, we should receive a shell back on our netcat listener:
Finally, all that’s left to do is acquire persistent access to the machine and clean up your tracks. However, since this is a CTF we don’t need to do either of those. All we need to do is output the contents of the root.txt flag.
Leave a comment if you enjoyed or have some constructive criticisms, thanks! Also, feel free to drop a respect on my hackthebox page.
Brendan Ortiz is an Associate Security Analyst at Independent Security Evaluators, a firm of security specialists that provide a wide range of services including custom security assessments and software development. ISE also runs IoT Village, which hosts talks by expert security researchers who dissect real-world exploits and hacking contests consisting of off-the-shelf IoT devices.
Twitter: @ISESecurity
