Hack The Box: Fuse
What will you learn? This is a medium rated Windows retired machine. There is a print job monitoring application that allows for the harvesting of usernames, and creation of a potential password list against the target. Three domain accounts are identified with the same password set and we’re able to reset those passwords via a Windows API. With valid credentials the enumeration of shared printers leads to credentials for a service account. This account allows for a remote connection to be established that leads to privilege escalation through the SeLoadDriver privilege.
Let’s begin enumerating the box: 80 webserver, 88 Kerberos, 135 RPC, 389 LDAP, 445 SMB, 5985 WINRM
Unless we get credentials to test against the target then enumerating shares with smbclient is a dead end.
Enumerating with the enum4linx-ng tool does not reveal anything out of the ordinary, we confirm there is a domain naming context of fabricorp.local
Visiting the web page will ask us to add fuse.fabricorp.local to our /etc/hosts file. We notice this is called ‘Papercut Print Logger’. It is running a Microsoft IIS server on the backend as we can see through Wappalyzer (alternative to whatweb).
I viewed the source code of the initial page, nothing interesting. Clicking on the posts we have we can actually begin obtaining usernames though.
Create a userlist of the following usernames: pmerton, tlavel, sthompson, bhult, administrator. We should save this for later and continue searching. In the background I also was searching for subdomains and other directories- to no avail.
In the CSV/Excel data files and on the website there are words relevant to the scenario. We can use cewl against the website and create a list of potential passwords (wordlist) for us to use. This was actually the first time I’ve used cewl too, so this was very ‘cool’ for me :)
We can attempt to verify a valid user by password spraying with netexec or hydra, in this case- hydra identifies two user accounts sharing the same password and mentions they’re expired. So we cannot login with these user account passwords.
We are able to change the password of these user accounts remotely using the previous password and the tool smbpasswd. We will need to add one that meets the password policy of the domain though, which maybe- enum4linux reveals or it tells us in response to not providing an adequate one.
This password will actually change every minute, so keep this in mind as we try to work forward. It will expire and remember too, so you’ll need to change your password for the next attempt.
After changing my password I fired off a connection with rpcclient and started to enumerate the domain that way, we are able to acquire a lot more usernames.
We can start looking at the users, performing queries to see if there is any information.
We are also able to enumerate printers attached to the domain and it gives us sensitive details, including a clear-text password for us to test against the accounts.
Testing this password against the svc-print user with netexec (crackmapexec), allows us to see we have a valid password, windows remote management will work, and we can indeed connect using evil-winrm to the target and get a session and acquire the user.txt flag.
When we begin with enumerating the user privileges with whoami /priv we can see SeLoadDriverPrivilege. This is a possible vector for escalation we can explore.
Our path forward: If we can upload a vulnerable driver- we can exploit it. We are going to need to compile some of these components in a secondary Windows virtual machine.
We need to download this to our Windows machine and open as a project in Visual Studio: https://github.com/TarlogicSecurity/EoPLoadDriver/. Build a new project and name it loaddriverpriv.cpp. Then we will remove the highlighted line below and compile it as a release (x64). Then we can transport this to our Linux machine.
Download the vulnerable driver we are going to be loading and upload it to the target using evil-winrm’s functionality syntax of upload payload: https://github.com/FuzzySecurity/Capcom-Rootkit/blob/master/Driver/Capcom.sys
We need to open the ExploitCapcom.cpp file in MS Visual Studio Community edition to locate where this spawns a CMD session, and replace it with our own binary:
This will call a file that we will create in the directory specified that will return a reverse shell to us to a netcat listener.
We are going to need to take the ExploitCapcom.cpp file and configure the project to a x64 Release, and select build -> build solution -> and the output it creates will tell us where the file is. We can transport that file between machines using netcat, or whatever method you’d prefer.
Then we will create a stageless shell executable that will be able to reach our netcat listener.
Upload everything through winrm to the C:\programdata\ directory. Then we can start executing our payload. Start a netcat listener on port 4444 in another window, and this is what you should have in your programdata directory.
Now we can load the vulnerable Capcom.sys driver using our LoadDriverPriv executable.
Then all we need to do is execute the ExploitCapcom.exe file that is specified to run our reverse shell executable.
Then we’re able to catch a connection as the NT AUTHORITY \ SYSTEM user, and we’ve rooted fuse.
