I ran/helped run Square's Capture-The-Flag events from 2015-2019.
Moving forward, I'm happy to have found a group of very talented engineers
at Square to host our future events. This document contains my notes for
anyone interested to host their own internal or external events.
What is a Capture-The-Flag?
A Capture-The-Flag (CTF) is a computer security competition where
participants practice their security attack and defense skills to solve
challenges to gain points.
One of the motivations for running a CTF is to try and make security and
hacking more approachable.
Organizing such events usually takes 4-5 volunteers, a small amount
of money, and a ton of time.
My Typical Timeline
12 months prior
- Get approval from management. Usually the main issue is budget and we
typically request $1,000-$2,000 (pro-tip: request 2x what you think you'll need).
- List event on CTFtime. It's the main calendar everyone uses to find
out about CTFs.
4 months prior
- Reach out to co-workers for volunteers. In the past, some people
incorrectly felt they couldn't volunteer without some prior specific
security knowledge. Make it clear that anyone can help out!
We usually look for: 1 person for story writing, 2 people
for making puzzles, 2 or more people for testing puzzles, and 1 person for
If I can't find a volunteer for a given role, I end up doing it
- Start discussing puzzle ideas, how easy or hard we want to make each
one, etc. This is one of the hardest part of the entire process. Lots of
interesting ideas end up unsuitable for puzzles. Real world security
issues are great sources of inspiration.
- The following tips are useful when making puzzles:
- Try to make puzzles which are educational. Unless your puzzle boils
down to a sudoku or a maze, it is probably going to inherently require
learning or applying some knowledge.
- A puzzle which requires some thinking / can be solved without sitting
in front of a computer the whole time is great.
- A bit of mystery / not making the next step too obvious is nice. The
risk is having a puzzle which requires some guess work, which can be
frustrating. One option is to make puzzles with one obvious but hard
solution and another less obvious but easier. Overall, a hard balance to
- Each puzzle should have one or more flags. Ensure the flag fits the
agreed upon format. Make sure each possible solution maps to a flag.
- Puzzles can run client side or server side. For server side puzzles,
make it run inside Docker. In the past, we tried to give each team a
container but orchestration became challenging. As a result, we make
containers immutable and shared (e.g. if your puzzle requires exploiting
a SQLi, make sure the flag can't be deleted once found).
- Once your puzzle is ready, have one or more people test it (to ensure
it is solvable). Ask the person testing your puzzle to track roughly how
long it took to solve. If you tweak anything based on feedback from
people testing your puzzle, make sure you get someone to retest the
- As a tradition, we have had a puzzle which requires programming or
understanding obscure/unexpected languages. In 2017, I made a
Google Sheet puzzle. In 2018, it was
PostScript. In 2019, it was a
purpose of these esoteric puzzles is to level the playing field since it's
unlikely for people to have a knowledge or tooling edge.
- The following list is used to classify puzzles into categories. We try
to ensure we have a variety of puzzles:
- Pure coding. Solving requires writing some code and doing little of
anything else. E.g. given an encoder, write the decoder (or
- Crackme. Given a piece of code, find the input which displays the flag.
Requires understanding what the code is doing without having to find an
exploit. Derive the flag from the input/partially from the
input (be careful about having multiple solutions) so that you can’t
simply modify branches in the code.
- Exploit: typically stack, buffer overflow. Similar to crackme, but
requires going one step further.
- Web security: typically SQLi or manipulating cookies. Or other
- Cryptography: homemade crypto gone wrong. Or known weaknesses.
2 weeks prior
Test, test, test. Our infrastructure (and costs) boils down to:
- Github pages for static pages ($0).
- Slack for discussion / coordination ($0).
- Cloudflare for caching ($0).
- Custom piece of Go code running on Heroku (~$100). The code is similar
to CTFd but tries to achieve a
much higher cache hit-rate.
- Amazon AWS ECS for running containers (~$100).
My main concern is to keep our servers up while minimizing costs.
Every year, we bring the infrastructure up for a couple days and then
everything off. Since we are dealing with ephemeral systems and devops isn't
our forte, we make mistakes and run into surprising issues ¯\_(ツ)_/¯.
Start spamming posting
on social media. One year, we did three
which was fun.
- Turn infrastructure off.
- Use the remaining budget (usually ~$800) to buy (or craft) prizes and mail them.
- Archive puzzles on this site (yes, you can go back and play every previous puzzle!).
- Hold a post-mortem session with all volunteers to document what went
well and what can be improved in subsequent years.
* * *
That's it. I would like to thank everyone who helped out along the way as
well as everyone who participated in our events! I hope you'll find this
information useful. Keep in mind that the first year is the most work,
subsequent events require less work and run smoother.
-- Alok Menghrajani