Skip to main content
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 3 months ago

Machine Requirements

General Requirements

  • The Machine 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)

  • Unless your exploitation path requires it, use an operating system without a GUI desktop environment. For example, Ubuntu Server rather than Ubuntu Desktop.

  • 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 Machine features a website, make sure that those are presented in a realistic way (Website makes sense, and has a specific purpose). Do not use lorem ipsum to fill the pages.

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

  • Please make sure the keyboard layout is set to English US.

  • Please don't use the following characters in the administrator password: @ { } ' "

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 worry about activating Windows, as HTB will take care of that.


Flags

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

Linux

  • 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.

Windows

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


Documentation

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

Please:

  • 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 nplan.io.

  • 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 Machine)

  • 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.)


Difficulty

Select a difficulty based on the following criteria:

Easy

  • 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

Medium

  • Typically around 3 steps

  • Custom exploitation, but straight forward

  • Path clear from context / hints, no rabbit holes

  • Generating simple scripts

Hard

  • 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.

Insane

  • 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 Machine.

  • Pivot from one user to another

Did this answer your question?