Machine Submission Requirements
Read more below about what we require for each submitted machine to improve your chances in getting accepted!
Ryan Gordon avatar
Written by Ryan Gordon
Updated over a week ago

Machine Requirements

General Requirements

  • The box format needs to be VMWare Workstation or VirtualBox. Please avoid Hyper-V if possible.

  • Use only domains with the .htb top level domain, for instance somebox.htb.

  • Make sure to use recent operating systems (Windows 10/11, Ubuntu 20/22, Debian 11)

  • Make sure the operating systems are fully updated unless a specific version is needed for an exploit.

  • Don’t include any commercial software that requires licensing (including trials).

  • The usernames need to match the home directory names for each user. For instance if the user is called bob make sure the home directory for this user is in /home/bob or C:\Users\bob.

  • Use English US locale for the keyboard and system language.

  • If the boxes feature a website, make sure that those are presented in a realistic way (Website makes sense, has a specific purpose). Do not use lorem ipsum to fill the pages.

  • Make sure that the box name matches the host name.

Linux Specific Requirements

  • Make sure the HDD is no more than 10 GB, or contact HTB staff to request an exception.

  • Redirect any history files to /dev/null (e.g. .bash_history, .mysql_history, .viminfo) unless needed by the exploitation vector and chown the files to the root user.

Windows Specific Requirements

  • Make sure the HDD is no more than 20 GB, or contact HTB staff to request an exception.

  • Disable the PowerShell command history unless needed by the exploitation vector.

  • Do not use an evaluation copy of Windows. Instead use Pro/Home editions.

  • Do not worry about activating Windows, as HTB will take care of that.


Flags need to be in MD5 format (32 characters in Hexadecimal)


  • Flags need to be located in /home/[user]/user.txt and /root/root.txt

  • The user flag typically needs to be owned by root and the relevant user group with chown root:user user.txt

  • The root flag needs to be owned by the root user with chown root:root root.txt

  • The user flag permissions are typically set to 644 with chmod 644 user.txt. This can change depending on the exploitation.

  • The root flag permissions are typically set to 640 with chmod 640 root.txt.


  • Flags need to be located in C:\users\[username]\desktop\user.txt and C:\administrator\desktop\root.txt


Please include:

  • Full walkthrough showing the intended path to own the machine. A template is provided here. Please include an editable format of the walkthrough (markdown, word).

  • Credentials for all users (or at least root and user with user.txt).

  • Description of important processes running on the machine (ie, HTTP server using Flask, which is started by the service named flask.service).

  • Description of all automation, including copies of any scripts running on the machine (crons, scheduled tasks, etc)

  • Details of any firewall rules.

  • If using Docker, please include Dockerfiles and other configuration files for containers.

  • Source code for any custom binaries.

  • Any details about how future patches might impact the exploit path (ie, don’t update sudo, as the exploit path requires this version’s vulnerability).

Best Practices


  • Limit the RAM and CPU to 2GB and 2 CPU’s for Linux and 4GB and 4 CPU’s for Windows, or contact HTB staff to request an exception.

  • Configure networking through /etc/network/interfaces and remove netplan from the system using apt purge netplan

  • Try to keep the Machines realistic where possible.

    • Try to have the exploited code exist for a valid reason.

    • Don’t include things like todo.txt on a web server.

  • Don’t include rabbit holes without a good reason.

  • Make sure that any hashes crack in under 5 minutes with hashcat and rockyou.txt, if they are intended to be cracked. If they are intended to be cracked with some other method (not straight rockyou), include hints to indicate the method.

  • When picking passwords that are not intended to be cracked, please pick a strong passphrase (something solid but also not that hard to type).

  • Make sure web directories are easily found with directory busting tools and common word lists like directory-list-2.3-medium.txt or small.txt

  • Do not include anything inappropriate, trolly, offensive, political, or insulting.

  • Don’t require brute-forcing other than above without talking to HTB staff.

  • Make history immutable (redirect to /dev/null if this does not affect the path of the box)

  • Run linuxprivchecker, linenum, LinPEAS or equivalent to confirm that there isn't any unintentional vulnerability/exploit.

  • Don’t use potential unstable elements that may degrade user experience in a shared environment (i.e. a web app where a key page can be removed, a service exploit that will crash the web server, RDP access, a volatile exploit, etc.)


Select a difficulty based on the following criteria:


  • Typically 2-3 steps

  • CVE with script or Metasploit without modification

  • Path clear from context / hints, no rabbit holes

  • No binary exploitation / RE

  • Only the most basic scripting require


  • Typically around 3 steps

  • Custom exploitation, but straight forward

  • Path clear from context / hints, no rabbit holes

  • Generating simple scripts


  • Typically 3-5 steps, but can be more

  • Custom exploitation, chaining together different vulnerabilities, 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 allowed, but hopefully for a purpose. Don’t just make things hard for the sake of being hard.

Examples of a step:

  • Gain access to login-protected website.

  • Gain access to SMB / FTP / etc.

  • Get shell on the box.

  • Pivot from one user to another

Did this answer your question?