HTB - Fuse
Zweilosec's write-up on the medium-difficulty Windows machine from https://hackthebox.eu.
Overview
This medium-difficulty Windows machine gave me a chance to exploit a vulnerable service that we hear of often in training as being an overlooked problem for many Enterprises: printer management. While this challenge did not involve exploiting an actual print spooler service, it drew attention to the problems that misconfigurations can cause especially when dealing with credentialed service accounts.
You may see me using Metasploit more starting from this machine. I recently went through a class where we used it quite a bit, so I learned that it isn't as bad as I thought and can even help workflow in some cases. I am probably still going to avoid easy-button exploits unless crunched for time (always depending on what is available!). It's about the learning journey, not the end result of capturing the flags.
Useful Skills and Tools
For this machine I tried using the Three Ms (tm) a bit more than usual, to somewhat mixed success.
Metasploit
msfvenom
meterpreter
Enumeration
Nmap scan
I started my enumeration with an nmap scan of 10.10.10.193. The options I regularly use are: -p-, which is a shortcut which tells nmap to scan all ports, -sC is the equivalent to --script=default and runs a collection of nmap enumeration scripts against the target, -sV does a service scan, and -oA <name> saves the output with a filename of <name>.
This machine had many ports open. From the ports and services that were open this appeared to be a domain controller running Windows Server 2016.
Navigating to port 80 redirected me to http://fuse.fabricorp.local/papercut/logs/html/index.htm. I had to add fuse.fabricorp.local to my local hosts file to proceed. I was greeted by a PaperCut print logger site, without any authentication protecting it. I clicked on view HTML for each of the print history pages to see what kind of documents had been printed recently.
Each of the three pages contained potential usernames and client computer names in the print history and a number of interesting sounding document titles.
I found six potential usernames (including bnielson in one of the document titles. The document title Fabricorp01.docx also stuck out to me as looking like the perfect type of thing that corporate users would likely use as a password.
Unfortunately these users all had Kerberos pre-authentication enabled, but I was able to confirm that all of them were valid usernames.
At first I started chasing the little white rabbit while doing research about this PaperCut service.
I managed to find some interesting results that looked like a potential way to retrieve printed documents through backups, but either I did not have the proper privileges, or these options were not active on this site.
[app-path]\server\data\backups
After exhausting those possibilities, I went back and tried to do a good ol' brute force enumeration using the valid usernames I had found and the potential password I had spotted.
After running the smb_login scanner I found that not only had one person used this as their password, but three people had!
However, I got an interesting error back when trying to enumerate open shares for these three users: NT_STATUS_PASSWORD_MUST_CHANGE. I looked this up and found out that this meant that the user's passwords had expired and would have to be changed before they could log in. Next, I did some research on changing SMB login passwords remotely from a Linux command line.
How does one go about changing the windows password from a unix machine with no physical access to the windows machine sharing things?
SWAT provides the password change facility you are looking for. If you prefer a command line tool, smbpasswd has the same functionality - check the -U and -r options. The smbpasswd man page documents the password change options.
I checked the man page for smbpasswd to see what the -r and -U options did, and found out that that these flags let me specify a remote host (-r) and username (U).
I used this to try to change the password for bnielson, but it seemed as if there were some sort of password complexity rules in place.
After choosing a more complex password, I was able to change it successfully.
Next I used my new password for bnielson to enumerate open SMB shares. Besides the standard default shares, there were also a HP-MFT01 and a $print share.
After enumerating the machine through RPC with rpcclient for awhile and finding a bunch of useful information, I hit the jackpot when checking for printers. In the description field someone had left a helpful note telling users where the printer was located, and also what the password was!
Next I ran a brute force login attack against SMB after adding the new usernames and passwords to my lists. I noticed that again there was more than one user sharing a password. Both svc-print and svc-scan service accounts used the same password.
Initial Foothold
Further enumeration
I tried using the winrm enumeration module in metasploit, but for some reason it returned no valid logins. After playing around with different things for awhile trying to get something to work, the colored text in ZSH saved me. I noticed that the $ in the password were being interpreted as a special character by the terminal. Once I wrapped the password in single quotes I was able to login using evil-winrm.
SeMachineAccountPrivilege and SeLoadDriverPrivilege sounded like very interesting privileges.
User.txt
tree gave some odd looking output, but showed me that the user.txt proof was right there in my service account user's Desktop! (Why a service account has a Desktop I am not sure...)
Path to Power (Gaining Administrator Access)
Enumeration as svc-print
svc-printI checked running processes and didn't see anything too exciting.
Same with running services. I did notice that there was the print service for Papercut running, however.
Exploiting SeLoadDriverPrivilege
I decided that since the service account had the SeLoadDriverPrivilege privilege I would see if there were any published privilege escalation methods using it. I quickly found one at https://www.tarlogic.com/en/blog/abusing-seloaddriverprivilege-for-privilege-escalation/
First I tried to see if I could get a meterpreter shell by uploading a reverse shell I created using msfvenom. I uploaded my malicious print.exe, ran it, and was given a meterpreter shell. I backgrounded my shell to try to use the exploit windows/local/capcom_sys_exec which was related to the exploit in the article.
Unfortunately no matter how I configured the options, metasploit did not seem to think this machine was vulnerable. Some reading lead me to https://github.com/rapid7/metasploit-framework/pull/7363 which explained why this didn't work:
This module achieves local privilege escalation on a Windows target by exploiting a "feature" provided by the CAPCOM.SYS driver for Windows x64. The "feature" is the driver allows for user-land functions to be executed in the context of the kernel. Currently this module has only been tested with Windows 7, but should work on earlier Windows versions or any other version that doesn't have SMAP support.
I decided to run the exploits in a more manual way, following the article I found earlier.
Using meterpreter's sysinfo command I was able to verify that this version of Windows was x64-based.
Getting a shell
Going back to the article I found earlier, I found a few links to files needed for exploiting the SeLoadDriverPrivilege privilege.
Following the instructions, I had to compile the two files on Windows (with a matching x64 architecture). I customized the exploit a bit to have it call a simple .bat script I wrote to send me a netcat reverse shell. The four files needed for this to work were:
Capcom.sys
EOPLOADDRIVER.exe
ExploitCapcom.exe
My .bat script reverse shell
I uploaded the four files required to C:\temp and tried to exploit the system, but for some reason I was not able to get back a shell. It took me a bit of troubleshooting, but I managed to track down the (very simple) reason why.
I realized after compiling my exploits that I had accidentally written C:\temp in one file, and C:\test in the other. Luckily my user had permission to create these folders on the machine so it didn't turn out to be too much of an issue. Next, I ran EOPLOADDRIVER.exe to create the registry key pointing to the malicious capcom.sys driver, then ran ExploitCapcom.exe to exploit this malicious driver to grant me a System shell.
Root.txt
After getting a System shell over netcat I once again uploaded my print.exe meterpreter reverse shell, and created a handler to catch it. For some reason meterpreter failed to load despite the handler getting a call back, so I recompiled my exploit to use the standard Windows TCP reverse shell windows/x64/shell_reverse_tcpinstead.
Thanks to egre55 for creating this fairly easy but interesting machine. It is always nice to encounter challenges that introduce new privileges to take advantage of!
If you like this content and would like to see more, please consider buying me a coffee!
Last updated
Was this helpful?