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)
Make sure you are using Ubuntu Server. If you need Ubuntu Desktop for the exploit path, please reach out to [email protected].
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

Machine Submission Process

Dedicated Lab Users Guide

Challenge Submission Requirements

January Updates - New Exclusive & Training Machines

Sherlocks Submission Requirements