How to Create a Vulnerable Machine for Hack The Box

Hackers like you are making vulnerable machines for us. Here's how you can get into it!

0xdf & ippsec, Sep 29, 2021

Hack The Box is most famous for the weekly vulnerable machines that anyone in the world can play for free. Most of these boxes are created by our community, then vetted by the Hack The Box team so that our members get a wide variety of interesting machines and challenges to learn on. There are many competitors to Hack The Box, but none put as much effort into testing and verifying that all machines are enjoyable and teach something valuable for all skill levels. The weekly machines have always been about community submissions and in 2021 we started paying machine creators for their submissions. The amount earned per box is based upon difficulty, easy machines earn $200-$250 and insane between $800-1,000.

When a machine is submitted it goes to a team called the "Release Committee", where the members will evaluate the write-up, looking for new and interesting exploitation techniques, as well as the realism of the box. The Release Committee has over a century of work experience, and is composed of people from Infrastructure, Content Development, Innovation, and Academy teams at Hack The Box. When the committee approves the box, it moves onto the next phase where our content team tests the box to make sure it lives up to the write-up, functions as expected on our platform, and is fun to play. If the machine is not accepted at either of these steps, we’ll let you know why. It’s very common for machines to go through multiple iterations with the author to get the highest quality content onto Hack The Box.

What makes a good machine

The goal of machines is to teach people real-life applicable skills and for our players to have fun. When you're designing a machine, you should think through the skills you are trying to teach. It is often helpful to create a list of goals prior to doing any work on the machine, and then finding a way to have a single story tie in all the goals. It can be useful to think about who the fictional user of the box is. Then you can make sure that all the components that you are putting there to be exploited fit in the world of this fictional user. Our players get so much more out of a box when it isn’t just two or three unrelated vulnerable services stuck together.

Of course it’s impossible to have the box be completely realistic. There are often times when creating a vulnerable service has to stray away from the realism of the box. For example, both Sink and Bucket use "LocalStack" to simulate AWS. Interacting with LocalStack has some slight differences to native AWS. For example, you have to provide the --endpoint-url configuration option to the AWS command line tool. Still, LocalStack does a good job teaching Cloud Skills, and each of these boxes had a cloud centric theme which gave the impression of performing a penetration test on a cloud service.

Examples

Here’s an example. One of our VMs, RE by 0xdf looks at hacking the machine of a malware reverse engineer. There was a blog with information from the RE shop (as well as hints about how to “Hack The Box”), an SMB share that was made to collect malware samples from users across the fictional enterprise. The malware reverse engineer fed those samples into an automated pipeline of powershell scripts which processed the samples, ran Yara against them, and stored them for later analysis. It turns out that that pipeline was exploitable multiple times by design. But that pipeline also fits the story. When you make a box, we want to see elements that aren't just there in order to be exploited. They have to be something a user would actually do.

Another example is Delivery, an easy box by IppSec that was built to demonstrate the attack in this blog post. The concept is that this box is that HelpDesk system gives a user access to a valid email address for the company. The intent of this email address is to allow them to email the help desk, but it can also be used if companies let anyone with a @company.com email address access their cloud services (ex: Slack, Confluence, etc). The main issue with this box was taking all the dependencies that utilize cloud services and tieing them into a self contained box. Open source solutions to the popular cloud base services were installed such as OSTicket for the help desk and uses Mattermost to simulate Slack. The difficult part about creating this box was to tie OSTicket and Mattermost together. A Python script using SimpleSMTPServer was utilized to receive emails from OSTicket and manually make the changes in the Mattermost database to facilitate account activation.

Things to avoid

There are things that can ruin a box, even if there is a great story. We generally recommend avoiding:

Excessive brute forcing - You'll rarely need to brute force a login to a site, and if so, there will be lots of hints. Similarly, you may need to do some web directory/file brute forcing, but we don't want people to spend hours doing that, so limit it to very common wordlists like directory-list-lowercase-2.3-medium.txt and to extensions that the user can deduce are in use.

Unrealistic artifacts on websites - Admins don't really leave their credentials in comments on HTML pages, or todo.txt files sitting on their web servers.

"sudo" for no real reason - Abusing "sudo" is a really common path on Linux machines, and while it can be done in interesting and clever ways, it should make sense to the theme of the box. Just finding a user with the ability to run sudo /opt/pwnme isn't realistic. Make sure there's some reason that that user would have the right to run that command as root.

Extremely old software and techniques - If the box depends on old software or libraries, expect to get pushback from our release committee. One example of this is PHP LFI Vulnerabilities that still use the null byte (%00) to truncate a string.

Benefits

Creating a vulnerable virtual machine is a great way to go even deeper into a technology, and you will learn way more than solving a box. Beyond that, you’ll see how other people approach the challenge. Machine creators can make some decent side income, our top earner has submitted seven boxes earning around $4000. If that wasn’t enough, many businesses recruit from Hack The Box, just having your name on the website as a machine creator can make sure to make your resume stand out or create that social connection with someone that refers you to their company.

Tips for getting published faster

Hack The Box currently releases one machine each week, and typically rotates through the different difficulties (Easy, Medium, Hard, and Insane). Many factors come into play when selecting the next box to release. How long it’s been in the queue is one of those, but we also want to get a diversity of attack vectors and host OSes, among other factors. It can often feel like a really long time from when you submit to when your box actually goes live on the platform. One tip is to look at what’s currently been submitted, and look for something that isn’t as common. For example, at the time of this blog post, we have a ton of Medium difficulty Linux hosts. If you’ve got an idea for another Medium Linux, go ahead and make it, but it may be a while before it is published. On the other hand, if you submit an awesome Hard Windows box, it’s likely to publish much faster.

Create an outline

Start with a few goals of what you want the box to teach or demonstrate. Then build a story around those goals. Having a good story will guide the player through each part of the box. Additionally, forcing yourself to stay within the constraints of what is in your outline will help minimize adding challenges that don’t contribute to teaching or the difficulty. When creating machines, it’s really easy to think “getting this password from the configuration file” is too simple and place the password in an encrypted backup. Without a good story or reason for doing this, it feels like it is there just to waste time. However, if the entire theme was attacking a backup server and the goal was to download an encrypted backup of a VM, in order to steal the NTLM Hash of that machine for re-use. Then the player would be left with how to exploit backups, instead of just passing an encrypted file to john/hashcat.

Choose something you are familiar with

Attacking is all about knowing something the defender does not. If you build a box on technology you are not familiar with, then it is likely an unintended vulnerability will be introduced to your machine. For example, if you read a cool blog post on a MSSQL Technique but don’t know how to properly harden it. Then users may find ways to re-enable xp_cmdshell and get RCE as a user that can escalate via Rogue/Juicy Potato. Additionally, it is hard to make a box realistic if your knowledge about the attack is from reading about it.

Put work into the design

While the look and feel of the website does not always contribute to what people will learn doing your box. It will help with the immersion to make it feel like the player is hacking into something real and does show how much work went into creating the box. If the goal is to show a wordpress/drupal/joomla/etc vulnerability, go a step beyond just a vanilla install of the software and lorem ipsum for the blog posts. Create the owner of the box and give them a reason to use it. This increases the realism and the experience people have playing the box.