When stuff breaks, how do you respond? This box taught me a lot about how I respond when otherwise reliable tools fail me, and taught me a number of helpful skills along the way. The machine is called Optimum, and this is how I solved it.
As always, I started with a staged nmap scan:
This machine is basically a web server and nothing more. This means that it’s time to go into web app testing.
I fired up gobuster and Nessus, as I always do.
In the meantime, I did a bit of research on what nmap believes to be Rejetto HttpFileServer 2.3, which yielded interesting results:
Given that Nessus and Gobuster revealed nothing, we’re gonna follow this exploit path.
Fortunately, there is a Metasploit module for the HFS exploit. Running it grants us a user shell.
Good start, let’s try to escalate privilege by using “getsystem”:
The error message hints that I should check the sysinfo, which shows that I have an x86 meterpreter session running on an x64 machine. I need to rerun the original exploit using an x64 payload:
Much better. “getsystem” still didn’t work though, and neither did the local_exploit_suggester module within Metasploit. I can still use the Windows Exploit Suggester tool, I just need to grab the system info from a command prompt:
Looks like we’ve found a reliable privilege escalation exploit. That should get us where we need to be.
There is a Metasploit module for MS16–032, which I tried running several times using the following configurations:
It was relatively frustrating, as I read online that many people have used this module with success. Apparently, more recently it has not worked as well for many though. What I was going to have to do was manually upload and execute it on the remote server.
Upon uploading and executing it on the server, all I could seem to get was a normal, user-level command prompt. Since this wasn’t working, I decided to inspect the source-code of the exploit and noticed that I could point it to run any executable I wished. My thought process from here was that I would create and upload a custom executable to the server, modify the exploit to point to it, and then try to run it. This is what that ended up looking like:
Last thing I have to do before running is open up netcat for the port I pointed my payload to:
This is the point where I managed to learn something new about Metasploit. I tried dropping from Meterpreter into a shell and running PowerShell from there, but it simply wouldn’t work. The explanation for this is that you can’t get an interactive shell from within meterpreter without importing a PowerShell module using the “load powershell” command. This was a source of mild frustration, but once I learned this it ended up being quite a nice experience. Here’s what that looked like:
Note the syntax for the first “powershell_execute” command is “. .\ms16–032.ps1”. Without the leading period, you will only import the file, and not all of the functions within it, which still doesn’t make that much sense to me but was 100% necessary to get it to work.
Anyways, if you see the output of the powershell script, it says we should have a system shell. Let’s confirm that on our netcat listener…
That’s that! Simple enough.
I certainly learned a lot from this one, and hopefully the knowledge gained will help me in the future.
These are kind of becoming redundant at this point, but I have to keep doing this for consistency.
- Patch management is kinda important.
- When in doubt, google the software’s version number followed by the word “exploit”. If you see something, you should probably take note.
Happy new year y’all!