16 CTFs later: how we run events at INSA

Most of our team learned security by playing CTFs. At some point we started running them too, and it turned out to be a very different job. Playing is about finding the one bug. Organizing is about making sure hundreds of people can find it, fairly, at the same time, without the platform falling over.

This post is about that second job.

Two years in numbers

In 2025 we ran four INSA Summer Camp CTFs. In 2026 we ran twelve more events, including the CTC Summer CTF for the 5th cyber batch. Our largest single event, in Addis Ababa, had 241 participants.

Across both years, our systems record 16 CTF events and 2,200 completed challenges. The 2025 archive shows 348 learners with challenge activity, and the 2026 events had 559 unique players.

Alongside the competitions we have also run awareness trainings. A CTF works best when people already know why any of this matters, so a lot of our events start with a session on the basics before anyone touches a challenge.

Writing challenges people actually want to solve

Every event gets a fresh set of challenges, usually ten, across web, crypto, reverse engineering, forensics, and the occasional stego or misc puzzle. We try to theme them around things players recognize. Our challenge library has names like Aksum Scroll, Gondar Cipher, Lalibela Pages, Merkato Ledger, and Buna Ceremony. It sounds small, but a challenge set in a familiar place gets people curious faster than another generic login page.

Each event starts with a short spec that every author follows:

• One flag format, matched as an exact string, so there are no arguments about case or trailing spaces.
• Players get a handout with no flag, no solve script, and no leftover .git folder inside it.
• Every challenge ships with an intended solution, hints, and a solver that must print the exact flag when run against the handout. If the solver does not work, the challenge does not ship.
• A clear difficulty target. Medium should take 20 to 40 minutes for someone who took the class. Hard should need real technique and take closer to an hour or more.

That last solver rule has saved us more than once. A broken challenge in the middle of an event is the fastest way to lose a room.

The cluster

Web challenges are easy to host. Giving every player a full hacking environment is harder, and it is the part we are proudest of.

Each player can launch their own Kali desktop that runs in the browser. Behind it is a Kubernetes cluster built on k3s, and every desktop is its own sandbox with its own deployment, service, and password.

A few decisions made it work:

MicroVMs, not just containers. Players are literally there to break things, so a normal container boundary did not feel like enough. Sandboxes run with Kata Containers on Firecracker, which gives each one a lightweight VM of its own. If someone escapes their desktop, they land in a tiny VM, not on our node.

Locked down by default. Sandboxes run as a non-root user with the default seccomp profile, and no Kubernetes service account token is mounted inside. Cilium handles networking and UFW guards the nodes. Kyverno applies runtime defaults so nobody has to remember them on every deploy.

Fixed resources. Each desktop gets a set CPU and memory budget, and sandboxes are spread across nodes so one busy machine does not slow down a whole team.

Our own registry. Challenge and sandbox images live in a private Harbor registry inside the cluster. When 200 people click “start” in the same minute, nothing waits on an internet download.

We also keep runbooks for every part of the setup: cluster install, networking, the registry, and the Firecracker runtime. Each one has the steps, a way to verify, and a way to roll back. They are not exciting, but a live event is much calmer when the fix is already written down.

What we learned

Test with real load before the event. Things that work for five people on a laptop break in surprising ways at a few hundred.

Plan for the network you will actually have. Some of our events run in places with slow or unreliable connectivity. Keeping images cached locally and handouts small made a bigger difference than any fancy feature.

Be in the room. The scoreboard is not the event. Walking around, nudging stuck players, and fixing problems fast is what people remember.

We are not done. We want more learning paths, more defensive challenges, and more of the community writing challenges with us. If you want to play, start at ctf.tibeb.org. If you want to help run the next one, get in touch.