Machine Submission Checklist
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:
1) Multiple exploitation Vulnerability
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.
2) Vulnerability does not have to crash a service or the system
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.
3) Realistic scenarios, please
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.
4) No heavy bruteforcing/fuzzing/directory discovery
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.
5) CTF ONLY within the HackTheBox VPN
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
6) Users Passwords
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.
7) Test your CTF before submitting it
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.
8) Write a Writeup
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
9) Hint where is {user,root}.txt
We would prefer the standard locations for the flags:
Windows
- user.txt: C:\Users\USERNAME\Desktop\user.txt
- root.txt: C:\Users\Administrator\Desktop\user.txt
*nix
- 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.
10) Changes after release
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.
11) Machine Size
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.
Windows
- Install Windows without the desktop experience (Windows Core).
*nix
- 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 protected]
Quick Links
Categories
- 1.7K All Categories
- 243 Support
- 23 Billing
- 139 VPN Connection
- 73 Website
- 1K Discussion
- 518 Machines
- 255 Challenges
- 12 RastaLabs
- 41 Exploits
- 8 Programming
- 209 Off-topic
- 410 Tutorials
- 247 Writeups
- 48 Video Tutorials
- 58 Tools
- 55 Other
- 8 Links
- 8 News
Comments
Great list!
As you mention the expiring users' passwords: What about also requiring SSL certificates (or other certs absolutely required for connections) to be valid for several years?
I did the Fulcrum box when it was already retired and I worked around the expired cert by changing the attack machine' system time ... which of course has other unpleasant consequences.
Often you can skip certificate validation all together but in this case it was not an option as far as know, at least it had to be time valid!
Love it! User.txt does NOT go in /dev/null
do we have stats about the level of people ? imagine we have a majority of script kiddies, is it really interesting to have very insane boxes for 12 persons ?
Just submitted my first CTF, would have been nice to have a link to this post on the submissions page, as I would have changed a few minor things. I now appreciate the amount of effort it takes to create a CTF and thank the people at HTB who test these machines.
If someone wants to create a Windows based CTF how does the licensing work?
That's right. I am new to pen testing and learning the stuff and learned a lot from the HTB. But mostly I won't touch the insane/hard boxes as of now, just reading writeups/ippsec videos. May be in future I may go for it.
Type your comment> @Derezzed said:
In my opinion , You send them the unactivated copy of windows and they activate it and host it in the labs
Would it be possible to get rough guidelines as to what is "too big"? Also, any recommendations as to where I can find an iso for Server 2019 (or Server 2016) to install without desktop? The only kind I was able to find for free was the eval copies, which I understand HTB can't use (correct me if that's wrong).
I've noticed a lot of windows boxes being released recently, is there a push to increase or maintain a certain proportion of windows boxes?