Building your first HTB Machine: A beginner's guide

"Hey, I want to build a Machine for Hack The Box, but I don't know where to start. Do you have any advice?”

This is a question I get asked frequently and, to be honest, is one that I have trouble answering - even after having built 10+ Machine both as a community member and now as a Content Engineer for HTB. In this blog post, I'll try and provide some guidance on that exact question, what the process looks like, how you can start, as well as some of the things I've learned along the way. 

Creating good content that will be well received by the community is not something that typically happens in a few hours of deciding you want to submit something, but if you put in an honest effort to make something great, players will realize that just by playing.

The motivation for wanting to make content will vary from person to person, but for me personally, I wanted to make content as my way to give back to the platform that I've come to love. 

Having grown up in a time when the internet was just becoming a normal thing for any household; this playground is truly something I wish I had at my disposal back then. With that said...I would argue that it's important to know why you're building a Machine because, in my opinion, it absolutely has an effect on the final product.

Hopefully, this helps fill in some blanks because making content is incredibly rewarding. And if you choose topics that aren't necessarily in your wheelhouse to use in your content, the rate at which you learn goes up exponentially because you'll see how they're put together and what makes them vulnerable.

Recommended read: How to submit a Machine to HTB

It all starts with an idea

Coming up with a collection of what vulnerabilities will be exploited is the most challenging aspect of the entire process. This is because your idea needs to be both fresh and unique with a goal of setting it apart from everything else on the platform. 

Simply building a box that demonstrates three of the OWASP top 10 with techniques that can be exploited by common toolsets is probably not the best way to go about it. 

Now this doesn't mean that the techniques and/or approaches have to be unique to everything that's out there already. Some eventual overlap with previously published Machines is expected—as there's a wealth of content on the platform already.

Take time to look at existing Machines  HTB offers. Then craft your ideas to try and stand out from the rest. If your submission is more of the same, it likely won’t be released on HTB. 

While you probably will have learned a lot in the process, a rejection is still disappointing since getting your box published is the goal! The point is to have a fresh take. Be creative.

Building the storyline for a "good" box

It's important to remember that it's not just about the exploitation, but also about providing a good storyline. A good storyline enhances the experience and provides context for the exploitation path. 

Simply slapping a few vulnerable applications together with no real narrative or reason for their existence and calling it a day comes across as "CTF-y" and can just be an overall bad experience for the player.

Now when I say “storyline” I don't mean that in a literal sense. You don't need character development with a story arc (although if you can manage to pull that off, it won’t hurt!) 

Sometimes the storyline can be the overall theme of the box just by the types of challenges and applications you're using in your path. Having each phase of the Machine be logically connected in some capacity makes for a smooth playthrough and gives the player a perspective on why certain services or applications are in the path. 

Think of it this way, if you were to sit down to use this Machine as a normal end user, not knowing that Machine was meant to be hacked:

• Would it make sense? 

• Is it usable? 

• Does it serve a functionality that would assist in normal day-to-day activity?

These aspects all help boost a Machine's realism.

Judging your difficulty

This is a tough one. Everyone has a different skill set. You as the creator may have a deep understanding of a particular topic and consider it a piece of cake. Whereas the player being forced to deal with the madness you've created may have a different opinion. 

This needs to be kept in mind during the development stages since the ratings of your content depend on it as well as your quality bonus. 

If you're submitting content as Easy, but your Machine actually leans on the upper end of Medium to Hard, then you're putting yourself at risk of receiving reviews that may be unfavorable. 

Hack The Box does a great job at helping box creators navigate this piece, but that doesn't mean it's going to be accurately rated all the time. To reiterate...everyone has a different skill set. What is most important is that the overall difficulty be relatively constant across the box. 

As an example, Easy Machines using off-the-shelf proof-of-concept (PoC) exploits are often sufficient, as they allow players to learn the basics of exploitation and also provide an opportunity to debug and revise the PoC if necessary. 

However, for harder Machines, relying solely on public PoCs may not be enough, as they require more advanced skills and a deeper understanding of the underlying vulnerabilities. 

Although there may be exceptions to this depending on the specific objectives, the key is to carefully consider your target difficulty level and design the content accordingly to ensure that players are appropriately challenged and engaged.

As a reference, below is what Hack The Box outlines for recommended difficulty according to the steps required:

Easy	Medium	Hard	Insane
Typically 2-3 steps. CVE with script or Metasploit without modification. No binary exploitation. Only the most basic scripting is required	Typically around 3 steps. Custom exploitation, but straightforward.  Path clear from context/hints, no rabbit holes. Generating simple scripts	Typically 3-5 steps.  Custom exploitation, chaining together different vulnerabilities, and complex concepts.  More enumeration is allowed, though don't include pointless rabbit holes.	Typically many steps (5+), but can be as short as 3 really hard steps.  Anything goes as far as exploitation.  Rabbit holes are allowed, but hopefully for a purpose. Don't just make things hard for the sake of being hard.

Slipping into madness

So you've got an idea. You've got a narrative. Now comes the fun part where you bang your head against the wall piecing it all together! 

Try and use realistic scenarios that simulate real-world attacks and vulnerabilities. Understandably, not everyone has what could be considered "real-world experience", but that doesn't mean it can't be done. 

Researching attacks that have taken place and building your own lab based on enterprise network best practices can help fill that gap. This will help players develop practical skills that they can apply in real-world situations and as a bonus, you now possess that experience as well!

So here's how the process mostly works. This workflow will vary from person to person, so I'll just tell you my process.

Design

• Whiteboard whiteboard whiteboard. Pen and paper are fine too, but the point is to diagram the path. If it makes sense in a diagram it will more often than not make sense from a terminal.

• Plan out the environment and what the end result could look like. What level of access does the foothold yield? If it's “www-data” for example, what could be a logical lateral movement?

• Using multiple applications? How can we logically separate them so it feels more like a realistic environment? While it does happen in the real world, generally, a single server isn't hosting multiple applications that serve very different purposes.

Development

• Base images before anything. Pick an OS and get a base install. Remove any bloat or unnecessary packages. Get the system fully updated (if possible). Apply some tweaks to optimize the build and snapshot it.

• Stand up a secondary VM if possible to act as a development instance. Once the steps of the path are tested and verified, those changes are merged into the primary instance. At the very least, document those changes, revert snapshots, merge those changes, and make another snapshot as a checkpoint.

• Be descriptive with snapshots so you can easily identify when a particular change was made in case something breaks further down the line and needs to be modified. The next bullet point can be really useful in this scenario.

• Automation is helpful. If the machine is mostly custom applications that are being developed, then tools like Ansible can help produce a cleaner build. To be completely honest, automating a build is the preferred choice, but in some cases, it takes less time to build out manually than writing and debugging configurations for an orchestration tool. This really comes down to workflow preferences.

Testing

• Test early and test often. Every box I've ever built has had design changes at some point throughout the process because either something doesn't make sense or I've had a change of heart. The more you test your path the more things you'll pick up on that sounded like a great idea at the beginning, but turned out to be the wrong choice.

• If a stage doesn't seem to have the desired effect you thought it would, don’t force it. Avoid making something intentionally vulnerable just for the sake of having a vulnerability. While realism is the goal, a complete guessing game is not.

• Try to test for unintended paths along the way. It's very easy to get tunnel vision during a build and start overlooking things, but at this point, you have the keys to the kingdom and can look under the hood. Try and imagine various ways a player could break something.

• To touch on the previous point, error handling is key. Accounting for as many scenarios as possible will only add to the stability of the box when it releases. Try to break it as much as you possibly can, even if it's not an actual attack, throw as much as you can at it so you can build safeguards.

Housekeeping

• During testing it's important to look for artifacts that could get left behind during exploitation and lead to spoilers. It's important to assume that players are not going to clean up after themselves, and having cleanup jobs to assist with this just makes for a better experience for everyone. You won't be able to account for every situation, but common areas where you expect things will be stored should be cleaned up.

• To touch on the previous point, let's talk about concurrency. When the Machine goes live, the requirements to complete the box will need to be repeatable and consistent. There are going to be multiple people attacking the same thing, and if the vulnerability is a “one shot” (as in once it’s exploited, others won’t be able to exploit it) it will lead to numerous resets and be an overall inconvenience. Keeping this in mind, there should also be jobs running in the background that help keep the vulnerable service(s) stable. If you paid close attention during the Testing phase then this should really be a non-issue.

Let me give you some practical examples…

• Outdated: This Machine demonstrated exploitation of MSDT which will cause that process to error out - a “one shot”. The only way to ensure stability was to have a scheduled task on a loop to forcefully close the process, if running, so that the exploitation is repeatable.

• Blackfield: This Machine root flag is encrypted. With the new HTB flag rotation model in place, the encrypted root flag would be replaced with an unencrypted flag. So a scheduled task to re-apply that encryption would be required.

• Forest: This bullet point really applies to any Machine that will demonstrate Active Directory exploitation, but this Machine was very AD heavy, which meant leveraging Bloodhound quite a bit to get an overview for permission abuse. Because of this, it's necessary to have scheduled tasks to reverse those changes so spoilers are not introduced for long periods of time.

• Miscellaneous things such as symlinking transcript files like .bash_history to /dev/null for Linux or disabling PSReadline for Windows is helpful as well—and required in most cases.

Finalizing

• The final image should be as airtight as it can possibly be. This is the time to check for unintended paths to the best of your ability. While they are inevitable at times, this is your opportunity to ensure everything checks out the way you expect it to.

• Once the finishing touches are in place, it's time to set those user and root flags. HTB implemented a flag rotation strategy some time ago, so the values for the flags aren't really important. A md5sum of “user” and “root” will suffice for submission.

• If updates aren't expected to break the path, fully update the image again. Snapshot it and do one final playthrough to make sure everything checks out. If all is well, it's time to export that image and submit it!

The benefits of building your first box

This is tough to quantify because what you take away can be different for everyone. But if you end up with new skills or a newfound interest in content creation, then that's a win!  Creating content isn't a science and I would go as far as to say it's an art. You improve over time as you learn from past mistakes...believe me, I've made plenty. 

Shifting gears from being a player to a creator is challenging and incredibly frustrating at times, but also a very rewarding experience. 

Getting feedback from the community that they love what you've created and learned new skills is just as much an adrenaline rush as getting root after hours (or even days) of grinding.

Ultimately, it's a continuous process of refinement, and the key is to always be willing to learn and improve.

Author bio: Cody Wright (ctrlzero), Sr. Content Engineer, Hack The Box Cody Wright is a seasoned IT professional with 15 years of experience spanning systems, network, and cloud engineering positions and a passion for information security. Cody holds certifications from Cisco (CCNP), Offensive Security (OSCP), RedHat (RHCE), and AWS (Solutions Architect) just to name a few.