HackTheBox: Devel Walkthrough

Matt Johnson
6 min readDec 21, 2019

So lately I’ve been getting more into HackTheBox, and decided that I would give a walkthrough on a relatively simple (but still insightful) machine: Devel.

But first, I should introduce myself, seeing as this is my first post. My name is Matt Johnson. I recently graduated from Texas A&M with a degree in Management Information Systems and I love infosec. In addition to that, I’m bilingual (English and Portuguese), have played guitar for about 10 years, like to lift weights, and also like the occasional long walk through the forest.

That’s enough about me. You can find more at https://mattejohnson.com, if you really want.

Now, onto Devel.

Reconnaissance

Knowing only the IP address of the machine we are targeting, we need to see what kind of services are running in order to determine what we can do. I like to do a staged nmap scan, which looks like this:

This first phase scans all ports (-p-) over TCP at a speed of -T4 for the IP address 10.10.10.5.

We see from this scan that FTP and HTTP are open. From here, we can do a more intense scan of these services:

The principle difference between this scan and the previous is that we are only looking at ports 21 and 80 (-p21,80), and on these ports we are determining versions, gathering intel on configurations, and determining the system OS (-A).

We see from this that the machine is an IIS 7.5 web server, likely running on Windows Server 2008. We also see that FTP allows anonymous login, which can pose a security hazard. Let’s explore that further.

FTP

In the event on anonymous login being enabled, I always like to check to see what kinds of files and directories are publicly accessible. Here’s what I found:

There’s not much. However, it is interesting that there’s an .htm file. This may imply that files uploaded to the FTP server are accessible by the web.

I wanted to confirm this suspicion, so I went to Firefox and visited 10.10.10.5/iisstart.htm — here’s what showed up:

This is the IIS7 default web page, but more notably, this was the same file found in the ftp server. Given this, I wanted to see if it was possible to edit this. If I were able to, that means that I would easily have the ability to upload malicious files to the system to gain access.

Here’s what I did: downloaded the .htm file, edited the background color, uploaded it back to the server, and visited the web page.

The result? It worked. Now that means it’s time to exploit.

Exploitation

So the process for gaining access is relatively straightforward from here. I need to generate a payload that will give me a reverse shell, upload it to the FTP server, set up my machine to listen for the shell, and cause the server to run the malicious code.

To create the payload, I used msfvenom, a standalone application for creating payloads that grant remote access:

Within msfvenom, I used a reverse TCP meterpreter shell as the payload (-p windows/meterpreter/reverse_tcp), pointed the payload towards my local IP (LHOST=10.10.14.105), set the port to 1225 (LPORT=1225), and set the file type to .aspx (-f aspx).

I then uploaded the payload via FTP:

In order to exploit the machine, I needed to make sure that port 1225 was open and listening for traffic. Since I was using a meterpreter shell, I used the exploit/multi/handler module within msfconsole.

Moment of truth…

I now have access to the machine, albeit not NT AUTHORITY\SYSTEM. This means it’s time to escalate privileges.

Privilege Escalation

Right off the bat, if you are using meterpreter, you should know about getsystem. This will automatically try to escalate your privileges for you and sometimes works. In my case, no luck.

So, the next step for me within a Windows environment is to use the local exploit suggester.

This returned a neat list of exploits for me to try. Worth noting that not all of them work, and it takes a bit of trial and error to find one that works well. This machine was particularly tricky, and I got a lot of messages to the tune of “Exploit completed, but no session was created.”

Finally, I found one that worked well, which was exploit/windows/local/ms13_053_schlamperei. All I had to do for this module was tell it the session I wanted to run on and point it to my IP. I also changed the port, as I always do. Many firewalls block port 4444, as it is the well-known default port for Metasploit. While changing the port doesn’t necessarily guarantee that the exploit will slip through the cracks, it never hurts.

Game over

Once you get to NT AUTHORITY\SYSTEM, you have the highest privileges available on a Windows system. Less relevant for this challenge, but in an actual penetration testing environment you would be wise to run a few commands:

  1. arp -a: this will dump the arp cache.
  2. route: this will show the routing table, which could lead you to find other systems or subnets within the network.
  3. hashdump: this will give a list of local users and their hashed passwords. You could crack these passwords to escalate privileges or impersonate other users. In the event that a company is configuring employee computers by cloning drives, the local administrator account can be used to access not just one, but many employee computers.
  4. netstat: this will display a list of open network connections. This allows you to further enumerate a network.

For the purpose of this challenge, you might be interested in knowing that

  1. The user flag for HackTheBox machines is always on the user’s desktop, and the root flag is on root’s (or on Windows, the local admin’s) desktop.
  2. You can search for a file within meterpreter by using the command “search -f [filename].[extension]”.

Lessons

So while the exploitation of this machine is relatively straightforward, there are some notable lessons for the blue team in this walkthrough:

  1. Disable anonymous login over FTP. It’s really not secure, and in most cases not necessary.
  2. Keep your systems up to date.
  3. Disable unnecessary services.

You can’t always protect yourself from 0-days, but you can very easily protect yourself from known exploits. While this may seem like obvious advice, many systems are still vulnerable to serious exploits months or even years after their public disclosure.

Stay secure and merry Christmas!

--

--

Matt Johnson

Freelance cybersecurity consultant based in Düsseldorf, Germany.