Machine Submission Requirements

You must submit the Machine in either VMWare Workstation or VirtualBox format. Please avoid using Hyper-V if possible.

You must use only domains with the .htb top-level domain, such as somebox.htb.

You must use recent operating systems for your Machine, such as Windows 10/11, Windows Server 2025, Ubuntu 24/26, or Debian 13.

You must make sure the operating systems are fully updated, unless a specific outdated version is required for an exploit.

You must not include any commercial software that requires licensing, including trial versions.

You must ensure that the usernames match the home directory names for each user. For example, if the user is named bob, make sure the home directory for this user is located at /home/bob or C:\Users\bob.

You must use the English US locale for the keyboard and system language settings.

If the Machine features a website, you must ensure the website is presented in a realistic way with a specific purpose. Do not use placeholder text like "lorem ipsum" to fill the pages.

You must make sure that the Machine host name matches the box name exactly.

You must not use automated AI tools to help generate content or writeups. Doing so will lead to the immediate rejection of your submission.

You must ensure the hard disk drive (HDD) size is no more than 15 GB. If you need a larger size, please contact HackTheBox staff to request an exception at [email protected].

You must redirect any history files to /dev/null (for example, .bash_history, .mysql_history, or .viminfo) unless they are specifically needed by the exploitation vector. You must also change the ownership of these files to the root user using the chown command.

You must ensure the hard disk drive (HDD) size is no more than 30 GB. If you need a larger size, please contact HackTheBox staff to request an exception at [email protected].

You must disable the PowerShell command history unless it is specifically needed by the exploitation vector.

You must not use an evaluation copy of Windows. Instead, you must use Professional or Home editions.

You do not need to activate Windows, as HackTheBox will handle the activation process for you.

You must locate the flags in /home/[user]/user.txt and /root/root.txt.

You must ensure the user flag is owned by root and the relevant user group. You can set this with the command chown root:user user.txt.

You must ensure the root flag is owned by the root user. You can set this with the command chown root:root root.txt.

You should set the user flag permissions to 644 using the command chmod 644 user.txt. Note that this can change depending on the intended exploitation.

You should set the root flag permissions to 640 using the command chmod 640 root.txt.

You must locate the flags in C:\users\[username]\desktop\user.txt and C:\administrator\desktop\root.txt.

A full walkthrough showing the intended path to own the Machine. You must provide an editable format of the walkthrough, such as a Markdown or Word document.

The credentials for all users, or at least the root user and the user associated with user.txt.

A description of important processes running on the Machine. For example, explicitly mention if an HTTP server is using Flask and is started by a service named flask.service.

A description of all automation occurring on the Machine, including copies of any scripts running, such as cron jobs or scheduled tasks.

The details of any specific firewall rules configured on the Machine.

If you are using Docker, you must include the Dockerfiles and any other configuration files used for the containers.

The source code for any custom binaries used on the Machine.

Any details about how future software patches might impact the exploit path. For example, clearly instruct us not to update sudo if the exploit path relies on a vulnerability specific to the installed version.

Limit the RAM and CPU to 2 GB and 2 CPUs for Linux machines, and 4 GB and 4 CPUs for Windows machines. You may contact HackTheBox staff to request an exception.

Configure networking through /etc/network/interfaces and remove netplan from the system using the command apt purge netplan nplan.io.

Keep the Machine scenarios realistic wherever possible.

Ensure that the exploited code exists on the Machine for a valid, logical reason.

Do not include unrealistic files like todo.txt on a web server.

Do not include "rabbit holes" (false leads) without a valid educational reason.

Ensure that any password hashes intended to be cracked will successfully crack in under 5 minutes using hashcat and the rockyou.txt wordlist. If a hash is intended to be cracked using a different method, you must include hints in the documentation to indicate the required method.

When picking passwords that are not intended to be cracked, pick a strong passphrase that is solid but not overly difficult to type.

Ensure that web directories are easily found using directory busting tools and common word lists, such as directory-list-2.3-medium.txt or small.txt.

Do not include any inappropriate, trolling, offensive, political, or insulting content.

Do not require brute-forcing other than the methods mentioned above without discussing it with HackTheBox staff first.

Make command history immutable by redirecting it to /dev/null, provided this does not negatively affect the intended exploit path of the Machine.

Run script tools like linuxprivchecker, linenum, LinPEAS, or their equivalents to confirm that there are no unintentional vulnerabilities or unintended exploit paths.

Do not use unstable elements that may degrade the user experience in a shared environment. Examples include a web app where a key page can be deleted, a service exploit that crashes the web server, allowing RDP access, or highly volatile exploits.

Typically requires 2 to 3 steps to complete.

Involves using a CVE with an existing script or Metasploit without requiring modifications.

The path must be clear from context or hints, with absolutely no rabbit holes.

Must not include binary exploitation or reverse engineering.

Requires only the most basic scripting skills.

Typically requires around 3 steps to complete.

Involves custom exploitation, but the overall process remains straightforward.

The path must be clear from context or hints, with no rabbit holes.

Requires generating simple scripts.

Typically requires 3 to 5 steps, but can occasionally be more.

Involves custom exploitation, chaining together different vulnerabilities, and understanding complex concepts.

More enumeration is allowed, but you must avoid creating pointless rabbit holes.

Typically requires 5 or more steps, but can be as short as 3 exceptionally difficult steps.

Anything goes regarding exploitation methods.

Rabbit holes are allowed, but they should ideally serve a learning purpose. Do not make things hard just for the sake of being hard.