A guide to creating challenging, educational, and enjoyable vulnerable virtual machines.
Picture this, you've just completed another machine on TryHackMe, Vulnhub, or HackTheBox and you're left thinking to yourself "well I'd quite like to build one of those for myself" but then you realize that you don't have any idea of where to start. Fear no more! In the following post, we'll break down the core ideas behind creating an excellent box.
Drawing up the Treasure Map
As we get started, let's first think about what exactly we're looking to accomplish. Are we aiming for an educational box or a challenge (CTF) box? This is important to know ahead of time as it will dramatically influence the course of creating your box and the amount of 'acceptable flaws' which it can have. Difficulty is also to be kept in mind at this point, however, this is to a somewhat lesser extent.
Decided on the purpose of the box? Great! Let's move into creating the base structure of the box: the kill chain. While this does vary slightly between educational and ctf boxes, the overall goal is the same: create a map of how accomplish the main goal of the machine. In pentesting and challenge boxes, this is typically a map of the boot to root process in which you go from being an unprivileged outsider to fully controlling the machine in question. Within the scope of educational boxes/rooms, this is a general overview of the topics you wish to teach and a rough path of how you will teach them either through associated questions/worksheets provided with the box or through various steps necessary in completing the box. Let's take a look at how this might be accomplished through a viewpoint of both a CTF box and an education box.
Disclaimer: This section will have spoilers for my Blue and Ignite boxes. One additional item of note, the box 'Blue' was created independent of any knowledge of the HTB box Blue as it was originally part of the curriculum I taught for a Cyber Defense club.
Ignite (CTF)
Goal: Boot to root
Enumeration: Discovery of a webserver running on the target system, further searching reveals this to be FuelCMS.
User: Through researching FuelCMS, default credentials can be discovered as admin:admin. While these do work, they will lead the user down a rabbit hole. The front page of the CMS reveals it's version number which, when researched on Exploit DB, is found to be susceptible to remote command execution (RCE). Through exploitation the user flag can be obtained.
Root: Enumeration of the CMS web app from within the system reveals a configuration file with the root database user password. Through testing this password against the system root user it is found to be the same, thus allowing the user to login through ssh as root and claim the root flag. The main goal here is to emphasize the consequences of password reuse.
Through reduction of the above kill chain into it's individual steps we can begin to see the core structure. The astute reader may have noticed this is nearly identical to that of a penetration test with the only real difference being the missing establishing persistence phase. Without the persistence stage, we are left with the following path:
Enumeration/Discovery -> Foothold/User -> Local enumeration -> Privilege Escalation (this may have multiple steps) -> Root
I recommend utilization of this path to create a skeleton outline of sorts when writing your kill chain. It's significantly easier to connect dots when you know what the dots/stages are that you want to connect. Let's now take a look at an educational box: Blue
Blue (Educational)
Goal: Introduction to real-life exploitation with an overall gentle learning curve
Recon: Discovery of open ports and the associated services running on them
Gain Access: Exploitation of the Eternal Blue exploit (ms17_010) granting NT System Authority permissions (effectively root)
Escalate: Unnecessary in this case, however, this serves to demonstrate migration and the process in which you can upgrade a shell to a meterpreter session.
Cracking: Relatively self-explanatory with the primary goal of this step to be an introduction to john the ripper/hashcat. Sections wherein bruteforcing or cracking is required should never be particularly lengthy and in this case the cracking, once setup properly with the right wordlist (rockyou.txt usually) takes very little time (~5 minutes max).
Find flags!: As the name would otherwise imply, this step entirely consists of searching for the three flags which have been planted on the system. These flags have been placed in standard areas which would be searched when 'looting' the system throughout a normal pentest. The main idea here is to introduce the idea of looting to an audience which may not be familiar to that part of the hacking mindset as it can be a slight shift in mannerisms/how to think about computers you've gained unauthorized access to.
In stark contrast to the CTF/Challenge box, we can immediately notice the level of details which we might find ourselves presented with when crafting an educational box. This is most due to the less-forgiving environment the creator can experience upon the release of educational content in any form wherein a non-sequitur might lead to complete abandonment of the material entirely by the target audience. Simply put, a little bit of a challenge is ok within a CTF, not so much in education where a beginner might be looking to you for guidance.
Putting it All Together
Now that we've defined the goals of box we are creating through the kill chain documentation, let's move onto the tools of the trade. While these can vary widely depending on the box maker, typically I use either Virtual Box (free), VMware Workstation Pro (paid), or VMware ESXi vSphere (free tier present). If possible for the box being developed, I will stick with vSphere simply to offload the resource usage to a separate server from my primary workstation, thus allowing me to work on it from my laptop as well. That being said, this is very much personal preference but this should give you a general idea of what you can use. Once you've got your hypervisor setup, let's continue on to actually building our box and the 'gotchas' I've encountered therein.
Building your box starts like a normal OS installation might. Sometimes this might include selection of a specific operating system version, however, it's worth keeping in mind the idea of unintended escalation paths. For example, certain operating systems might have services installed and enabled by default (i.e. SSH, CUPS) which can lead to unintentional ways in which the system may be accessed. Additionally, you may occasionally run into a situation where a version of an operating system may have a flaw which you have not accounted for. At the time of writing, a common instance of this is Linux kernel exploit allowing for privilege escalation. While awareness of these items comes commonly with practice in building boxes, it's worthwhile to do some research into the operating system you are picking to avoid any common pitfalls.
Following making sure you're not introducing any surprises for yourself in your operating system selection, the rest of the box creation process can be made into a simple list of check boxes with a varying degree of difficulty depending on the goal of the box. As alluded to previously, education boxes can be slightly more forgiving in how well they are constructed. This is due to the guided nature typically included alongside these systems. The narrow path introduced reduces chances of users getting lost and finding things you may have missed.
On the other hand, CTFs are very rarely guided. Introduction of what is semi-unpredictable force means an almost altogether predictable outcome: if there's an easier route to own the box you've created you can be sure that someone is going to find and use it. While the following steps are by no means comprehensive, here are a few things to consider when creating your box:
- Link command execution history to /dev/null or it's equivalent. This will prevent users from finding actions others have taken on the system and/or discovering how you built the system.
- Remove any unnecessary packages. This can both serve to reduce any escalation paths you may not be aware of and to reduce distractions on the machine. Sometimes it can be hard for a user to see the forest through the trees and having excess packages installed can be confusing, especially if you didn't want there to be many rabbit holes on the box.
- Update everything you can. Generally speaking, this is going to make escalation clearer for the user and it's going to reduce again any unintended exploits.
- If you don't want users to crack your password, don't make it crack-able. You also shouldn't reuse any of your own personal passwords for obvious reasons.
- Have fun with it. Adding a particularly hard to find secret can be incredibly rewarding to discover.
Last but not least, work to connect the dots through either installing your vulnerable software or modifying the system to make it susceptible to exploitation. Your kill chain is going to make this easier. Once this is done be sure to test your box. After all, if you can't get everything working then no one else will. Following performing basic quality control, convert the box to an OVA file and release it on your platform of choice. Congrats on building your new box!