How to Build Hands-On Cybersecurity Training Exercises

Most security training tells people about attacks. Very little of it lets them carry one out, safely, and see exactly why it worked.

That gap matters: people who have exploited a weakness themselves spot it faster, fix it properly and explain it better. The good news is that a realistic, hands-on exercise is no longer a large project. With a clear structure and a few free tools, a trainer or team lead can build one in a day and reuse it for years.

Why slides and quizzes don’t stick

A slide that says “never pass user input to a shell command” is easy to agree with and easy to forget. A learner who has just exploited a deliberately vulnerable web form, and watched the server hand over a secret file, does not forget.

They now understand the bug from the attacker’s side, which is the side that matters.

This is the idea behind Capture the Flag (CTF) challenges. A CTF challenge is a small, deliberately vulnerable program or service with a secret string, the “flag”, hidden inside. Learners get the flag by finding and exploiting the weakness.

Getting it is proof they solved the problem, and it can be checked automatically. In our experience, a well-built challenge does three jobs at once: it teaches, it lets learners test themselves, and it lets the trainer see who is stuck and where.

What a good challenge looks like

A good training challenge is focused. It teaches one idea, such as a command injection in a web form, a stack buffer overflow or a key hidden inside a binary. If learners have to fight unrelated obstacles first, they learn frustration instead.

It is also realistic enough to transfer. The vulnerable code should look like something a developer might genuinely write: a small Node.js or PHP app that builds a shell command from a form field, not an artificial puzzle.

And it has a clear difficulty level. We usually pair a guided tutorial with a slightly harder follow-up task on the same topic, so learners first see the technique and then apply it on their own.

The difference is that learners do not simply recognise a vulnerability in theory. They experience how it works, understand its consequences and gain practical knowledge they can apply elsewhere.

Package it so it works every time

The biggest practical problem with hands-on exercises is not designing them. It is keeping them working. A challenge that runs on the trainer’s laptop and breaks on the learner’s machine, or on the training server six months later, wastes everyone’s time.

The fix is to treat each challenge like a small software project. What we propose, and what we have used in the past, is for a challenge to have four parts:

Every step runs inside Docker containers, so the only tool anyone needs is Docker itself. The automated solver is the part people skip, and it is the part that matters most.

Before every session, you run it. If it captures the flag, the challenge works. If it doesn’t, you find out before twenty learners do.

From one challenge to a full exercise

Once you have a handful of reliable challenges, you can run a full contest. Free platforms such as CTFd give you registration, a scoreboard, hints and timing out of the box. You choose the challenges, set a time window, and let teams compete.

A contest also gives you data a quiz never will: which challenges were solved, how long they took, and where people needed hints.

A challenge nobody solves is probably too hard or badly explained. One everyone solves in two minutes can be worth fewer points next time. Over a few rounds, your exercise tunes itself to your learners.

For more advanced groups, the same approach scales up to “vulnerable boxes”: whole virtual machines with several connected weaknesses, much closer to a real network. Learners have to chain findings together, as a real attacker would.

The contest doesn’t end with the scoreboard, either. The most valuable half hour is often the debrief afterwards, when solvers walk the group through their approach.

Learners hear three different ways to reach the same flag, and the trainer hears which parts of the material didn’t land. Write those walkthroughs down and keep them with the challenge. Next time, they become your hints, and the time after that, your teaching notes.

Where to start

You don’t need a cyber range or a big budget. Pick one weakness your team should understand better, perhaps something that came up in your last penetration test or code review.

Write the smallest program that contains it. Package it with a build, a deploy step and an automated solver, and try it on two colleagues. Watch where they get stuck, adjust, and run it again.

A single well-built challenge, used regularly, will teach your team more than another round of slides. And once you have one, the second takes half the time.

With advances in artificial intelligence, creating, deploying and validating cybersecurity exercises is also becoming easier. AI tools can support educators in developing practical training content and refining challenges more efficiently.