I'm looking for resources and information from people who have experience running hacking capture-the-flag challenges.

To sum it all up in a simple one-sentence question: How do you set up a server such that you can allow it to be hacked through a very specific vulnerability while (a) not exposing yourself and others to undue risk, and (b) preventing one participant from spoiling the experience for others.

This shares a lot in common with running a honeypot, but a major difference is a focus on maintaining a consistent experience for all visitors so that one visitor doesn't "ruin" it for the others.

As a bit of background, this is not set up as a competition, but rather as a way of teaching programmers the danger and nature of bad coding practices by showing them how they are exploited. The servers will therefore remain accessible indefinitely rather than simply during a competition.

As a starter: Our existing design consists of stripped-down minimalist Linux machines running as VMs under KVM, all persistent storage mounted read-only, and all FS changes persisted only to RAM. The servers periodically restart, wiping out any possible changes and starting over fresh again. No network connections are allowed in or out unless necessary for the exploit in question.


I have no experience running or setting up such a thing but here are my thoughts on avoiding undue risk:

  • You will want some external monitoring on the critical services on the VM. An exploit that causes a crash would certainly ruin it for everyone else. It would be OK if someone defaces the website running on the box as long as all the necessary links to other pages remain intact but if they deface it so badly that the rest of the website becomes unreachable or starts throwing 500 Internal Error codes back at visitors or even crashes the HTTP daemon altogether, that should be detected and remedied quickly.

  • The attacker's machine may be exposed to some threat if you aren't supervising them. The first exploit kit found by a Google search for the product they are aiming at is just as likely to contain malware as an actual exploit tool.

  • Political/legal risk. Sign waiver forms for them to hold on to, explicitly allowing them to attempt to exploit this particular machine. Explain the consequences of performing these same actions without the signed form.

And some general thoughts about running this thing:

  • Many exploits show no obvious signs of success. Of course, this is part of the learning experience, to show the developers that simply switching off the displaying of errors does not completely stymie competent attackers. But it might be nice to have a separate interface to show the current contents of the users table in the database or the contents of a particular directory or the list of running processes on the machine. This might be something you switch off later on as the developer get better at detecting their own successes themselves.

  • Keep score. For people who aren't naturally interested in security, making it fun is the key to keeping their attention, and a little bit of friendly competition will help that. If you're only looking at allowing a single vulnerability, it won't be a score so much as a checklist of who has done it and who hasn't, but if a developer actually finds an extra vulnerability to the one you expected to be there, they should be publicly praised in some way.

  • Since you're aiming this at developers rather than pen-testers, their day job is going to be the not-so-glamorous defense role. Once they have exploited the code, a followup task might be to see if they can protect the code themselves before seeing the best solution your team has collectively come up with.

  • lots of good insight. The exploiter's interface is certainly the most difficult part of this; gently pushing them along while at the same time letting them figure it out themselves. Part of our design is to increase the "difficulty" iteratively by throwing in common (but incomplete/ineffective) countermeasures. Love the idea of providing a legal waiver to emphasize that fact that they DON'T have such a thing for everyone else's servers.
    – tylerl
    Jan 17 '13 at 0:14

I don't have any great experience with CTF challenges. But I have participated a few and I am not an expert. But I can tell about my experiences.

  • First of all when running a CTF challenge we can warn the users about dos and don'ts. But this won't make sure that the wont do that. Simply we can tell them don't do DoS but it won't make sure they won't use DoS against your CTF game server
  • When we are giving a service or website to exploit we should make sure that only that kind of attack is possible here and rest of all security is tight. This was happened when me with my friends conducted a simple hacking competition in my college. We gave a application to hack. We tested that application to make sure only one loophole is there. But the competitors used other complex methods to exploit and they done that.
  • Security is all about bad coding. So make sure your services or applications are not having loopholes.
  • I remember my friend was participating in a CTF competition. He told that it will be 6 hr competition, but the competition ended after 30 minutes because one of the competitor exploited a vulnerability in the CTF server and everything collapsed. So dos and don'ts are not a matter.

Simply you will create only one vulnerability in your application to exploit. But exploiters will do all kind of tests to break it because they don't know what is the exact vulnerability here. May be a tiny loophole which you missed will compromise your server.


I believe stripe.com has run 2 CTF contests.

They discuss the design in the following blog post. You may find it useful:


  • 1
    obscure - While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes.
    – Rory Alsop
    Mar 19 '15 at 7:25

For Linux and Unix systems, I suggest creating some sort of regurgitated state every 24 hours via a platform such as -- https://fogproject.org -- which works via PXE boot (probably would help to understand scripting and cronjobs). Basically, set up a bunch of machines (virtual or not) and have them kick off a new baseline image once a day.

For a scoring system, check out this codebase https://github.com/TowerofHanoi/CTFsubmitter -- or maybe this one -- https://github.com/JGillam/openflagserver

If you like Ubuntu and Vagrant, check out Facebook's CTF Server -- https://github.com/facebook/fbctf

Probably the best platform base is -- https://ctfd.io -- and you can read this section -- https://ctfd.io/about/ -- which includes papers that cover the pitfalls of running a CTF without proper preparation and planning.

The DEF CON CTF and HackUCF teams have also provided their codebases on GitHub -- https://github.com/vito-lbs?tab=repositories -- https://github.com/HackUCF

One of my colleagues also open-sourced his scoreboard and CTF server here -- https://github.com/moloch--/RootTheBox

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.