A vulnbox (short for "vulnerable box") is the machine each team receives in an attack-defense CTF. Every team gets an identical copy running the same deliberately vulnerable services. Teams keep the services on their own vulnbox patched and working while attacking the same services on rival vulnboxes, where the game server plants fresh flags every tick.
Vulnbox meaning
The term comes from the attack-defense (A/D) format, where teams play offense and defense at once. You will also see "vuln box," "team box" or "the image." All mean a server, usually a virtual machine, that organizers built for your team.
It is different from a jeopardy challenge server, which players only attack, and from a King of the Hill "hill," which all teams share. On the vulnbox, your team has administrator access to your own copy and nobody else's. For the full format, see how attack-defense works or the attack-defense vs jeopardy comparison.
What lives on a vulnbox
A typical vulnbox runs three to six services. Each one is a small, working application with intentional weaknesses: a notes web app, a file vault, an API or a custom network protocol. Good services feel like real software, so reading the code beats guessing.
| Component | What it is | Who touches it |
|---|---|---|
| Services | The vulnerable applications, often written in different languages | Your team patches them; rivals attack them |
| Service data | Stored records, including the flags the game server plants each tick | Checkers write and read it like normal users |
| Runtime stack | Databases, language runtimes and process managers the services need | Your team, carefully |
| Team access | The account and keys your team uses to log in | Your team only |
What is not on the vulnbox matters too. The game server, the checkers, the flag submission endpoint and the scoreboard all run on organizer infrastructure. Flags arrive through the services themselves, which is why every flag has to be defended through the service and not by hiding files.
How teams get access
Most events follow the same pattern:
- A VPN profile per team connects players to an isolated game network that is walled off from the internet.
- Predictable addresses. Each vulnbox sits at an address derived from the team number, so every team knows where its rivals are.
- Credentials at kickoff. Teams receive login details for their own box only, usually just before the start.
- A setup window. For 30 to 60 minutes, teams can reach their own box but not each other's. Use it to read code, take backups and ship first patches.
Some online competitions let teams run the vulnbox image on their own hardware or cloud account, while others host every box centrally. Either way, event rules typically treat attacks on the game infrastructure, or on anything outside the game network, as grounds for disqualification.
Patching vs keeping SLA
Every tick, a checker uses each of your services the way a legitimate user would: it stores a new flag, reads back older ones and exercises normal features. If the service passes, it is UP and earns SLA points. If it fails, you lose those points, even if nobody stole a flag.
So the safest-looking defense is often the worst. Common ways teams hurt their own SLA:
- Removing a feature instead of fixing the bug inside it. The checker notices the missing feature.
- Blocking traffic broadly. Most game networks route checker traffic so it looks like any other team's, so a blanket block hits the checker too.
- Restarting services carelessly, which can drop a tick or lose stored flags.
- Breaking stored data during a patch, so older flags can no longer be read back.
Rule of thumb: fix the root cause, keep every legitimate feature working, test the patch against normal use and keep a backup so a bad change costs one tick, not ten.
Team roles for this work, such as service owners and an infrastructure keeper, are covered on the attack-defense CTF page. For the wider offense-defense picture, see red team vs blue team.
How organizers provision identical vulnboxes
An unfair vulnbox ruins an A/D game, so organizers spend real effort here:
Build one golden image
Install every service, runtime and starting data into one reference image built from source, so it can be rebuilt on demand.
Playtest and freeze
Exploit and patch every service internally, tune the checkers against patched versions, then freeze the image before game day.
Clone one per team
Create a copy per team, changing only network settings and credentials. No flags are baked in; the game server plants them once play begins.
Verify parity
Compare each copy against the reference and run the checkers against every box before the start, so no team begins with a broken service.
Plan resets
Keep a tested restore process for teams that break their box, and publish in the rules what a reset costs, if anything.
That means one box per team, a VPN, a game server and checkers for every service. Open-source A/D game servers exist, but you build and operate the vulnbox and checker infrastructure yourself. The CTF cost calculator shows how per-team boxes affect a budget.
Run attack-defense without building a vulnbox fleet. On CTF7, attack-defense runs as a managed event, so the per-team boxes, VPN, game server and checkers are handled for you. If you need services written, the challenge development team can build and test them. Ask us which plan fits your event.
Vulnbox vs KotH hill vs jeopardy challenge
| Aspect | A/D vulnbox | KotH hill | Jeopardy challenge |
|---|---|---|---|
| Copies | One per team | One or a few, shared | One per challenge, or per player |
| Player access | Admin on own box | Earned by capturing it | Attack only |
| Defense | Patch while keeping SLA | Hold control once captured | None |
| Flags | Planted every tick | Ownership polled on an interval | Fixed or per-team |
For shared-target play, see King of the Hill.
Related terms
- Tick: one scoring round, typically 60 to 180 seconds.
- Checker and SLA: the bot that tests your services and the points it awards for uptime.
- Flag format: the pattern every flag follows, such as
CTF7{This_is_an_example_flag}. - Dynamic flag: a flag unique to one team or player.
