As we are always happy to receive a new machine, but sometimes the quality of the machine is not ideal for a weekly release, due to “puzzly” CTFs, unrealistic scenarios or, even worse, machines not working due to poor testing before submitting it on HackTheBox. Since testing a machine requires time and effort, and since we regret to reject a machine, we have collected a series of points of the most common issues of rejected machines and made a checklist, which could be helpful for people who are interested on submitting a machine for a weekly challenge:
Bear in mind that multiple people are playing the CTF. Make sure that the vulnerability is intended to be exploited by multiple people. Machines with a “one shot” exploitation will be rejected.
Some vulnerabilities are exploited in order to crash a service or the entire system. These vulnerabilities are not allowed, as this would limit the exploitation from other users.
Puzzles are fun and challenging, but are not realistic. The purpose of the CTF is to learn something from a realistic scenario, such as misconfiguration, improper sanitization, etc.
We understand that sometimes default credentials make a CTF too easy, however some bruteforcing is accepted as long as the common wordlists are in use (e.g. rockyou, darkc0de, dirb/dirbuster wordlists, SecLists wordlists). Blind fuzzing of parameters is not accepted at all (e.g. fuzzing a parameter for a page and then the value of a page). Also please bear in mind of account lockouts on authentication pages. CTFs with account lockouts activated will be rejected due to denial of service.
When making a machine, please bear in mind that a user can play the CTF with only 1 VPN connection. In some cases it could be fun to jump from one OS to another (e.g. first part Linux, second part Windows), however a user can’t have the same VPN running on two or more OS at the same time. Bear in mind that CTF which require multiple VPN connections for exploitation will be rejected
Please make sure that the passwords of users are not set to expire to a certain date. CTFs found to have users with a password expiration date set will be rejected.
Is your responsibility to make sure that the submitted CTF has to work. There are cases when a small change is needed on a CTF, we would be happy to do that for you, but if the change is radical it needs to be done by you prior the release. Based on the changes needes, is at the CTF Tester discretion to reject the machine and wait for a new submission or not.
Please write a proper writeup in order to ensure the intended solution of the CTF. This would make our job (and life) way easier. The following are needed in order to make a proper writeup:
- Screenshots of the intended output
- Examples (not images) of snippets, code and commands
- Intended flags for user.txt and root.txt
- Credentials of users (administrators and non-administrators)
- URLs of exploits/blogs for the vulnerability and exploitation example
An optional bonus would be:
- Reference of Metasploit modules needed
- Date of when the machine was created
We would prefer the standard locations for the flags:
- user.txt: C:\Users\USERNAME\Desktop\user.txt
- root.txt: C:\Users\Administrator\Desktop\user.txt
- user.txt: /home/USERNAME/user.txt
- root.txt: /root/root.txt
However we appreciate if machine creators want to be a bit more creative, but please, please, PLEASE, give a hint to the user where to look in order to find the flag (I hope you have the common sense of not storing the flag in /dev/null :P). CTFs which does not have flags in the standard locations and do not have any hint or very unrealistic/cryptic hint on how to find the flags will be rejected.
It’s a great pleasure when you (and we) see your machine being released, and that the way to hack it is only with the intended solution. However, sometimes can happen that people might find an unintended solution (I mean, we are hackers after all, right?). It can be frustrating seeing that the hack didn’t go as planned, however we are not responsible to patch and redistribute ulterior changes on the machine once released. The only case we would temporarily retire a machine due to an unintended way would be only in case a new 0day comes out and makes the exploitation of a machine very trivial.
The size of some machines could be huge, which could be a factor towards the rejection of the machine. We would recommend to keep the size of the machine very small.
- Install Windows without the desktop experience (Windows Core).
- Install minimalist distributions and remove programs which are not needed, in order to make the machine stable and small. E.g. Linux Ubuntu Server is a good example
Should you have any comments, concerns or feedback on this, please feel free to contact us at email@example.com.