KING OF THE HILL

What it is

King of the Hill is attack-and-defend. Points accrue for the time you hold a hill (a periodic tick) plus captured flags and first bloods. The entry vulnerability and the privilege-escalation path are restored on a schedule, so a box can never be permanently patched shut. Defense has to be active: monitor, kick other teams' sessions, and overwrite their beacon.

The twenty hills

Each hill is a self-contained vulnerable box: a foothold vulnerability, then a local privilege escalation to root. Hills 5-20 (LOTR, Tron, Avatar, and Harry Potter themed) are new and ship as an alpha: validated by the smoke test, but not yet battle-tested in a live event. All are verified end to end by the smoke test except hill-15, whose escalation is a host escape (see its note) and is build-verified only.

The full 20-challenge design roadmap is now built (LOTR, Tron, Avatar, and Harry Potter sets), including the repair-to-capture pattern and bonus ideas for going further.

Quick start

One host with Docker. Bring up the hills, then run the scoreboard against the sample config.

# bring up the four vulnerable hills
for d in deploy/hills/*/; do (cd "$d" && docker compose up -d --build); done

# run the scoreboard (hills reachable on 8081-8084)
cd scoreboard
KOTH_CONFIG_DIR=../config KOTH_FLAGS=../flags/flags.json \
KOTH_BIND=0.0.0.0:8000 KOTH_ADMIN_KEY=change-me KOTH_TEAM_PASS=change-me \
python3 scoreboard.py

# open the scoreboard, team portal, and green-team panel
http://localhost:8000/        # scoreboard + team login
http://localhost:8000/team    # reveal your beacon by access code
http://localhost:8000/admin   # green-team control (pause, rotate, revert, adjust)

Want a scripted demo without deploying anything? python3 poc/simulate.py runs the scoring scenarios end to end. To verify the challenges, bash deploy/smoke-test.sh.

Add a hill, or bring in an existing project

A hill is nothing more than a docker-compose project under deploy/hills/ that honours a small contract, plus two config entries. Because it is just a compose project, an existing dockerized target slots in with almost no glue. This section shows both: the contract for a hill from scratch, then onboarding an existing project using the real HackWars web CTF as the example.

The contract

Building one from scratch means following any of the four shipped hills: a Dockerfile, an entrypoint.sh that plants the flags and an empty king.txt, a vulnerable server.py, a sudoers.golden privesc, and a reset.sh that revives the vuln without touching king.txt.

Bring in an existing project: HackWars

HackWars: The Vulnerabilities Strike Back is a real, already-dockerized Flask web CTF (a Star Wars themed jeopardy game: view-source, XSS, SQL injection, broken access control). It is a good example because you change almost nothing to run it on KOTH.

1. Reuse its container as-is. KOTH hills are compose projects, so you point KOTH at the project's own docker-compose.yml (one Flask service on :8000). No rewrite, no fork.
2. Register it. Add one entry to config/hills.json so the scoreboard and SLA prober know it exists, and drop its flags into flags/flags.json. HackWars already ships every flag in flags.txt and ctfd/challenges.yml, so this is a copy.
3. Pick how it scores (below).
4. Bring it up next to the scoreboard and verify.

# config/hills.json: one entry points KOTH at the existing service
{"id":"hackwars","name":"HackWars","service_host":"127.0.0.1","service_port":8000,"hmac_key":"changeme-hackwars","url":"http://localhost:8000"}

# run the existing project unchanged, then the scoreboard alongside it
cd path/to/CS50-Hackwars/project && docker compose up -d --build
cd scoreboard && KOTH_CONFIG_DIR=../config KOTH_FLAGS=../flags/flags.json python3 scoreboard.py

Two ways an existing project scores

How the integration works

Two layers plug together. Inside KOTH, agents and the scoreboard decide who holds each hill. Outside, an optional bridge feeds that into the RedutaCTF platform so a King of the Hill game can score alongside jeopardy challenges on one scoreboard.

Layer 1: KOTH's own scoring loop

Because the signing key lives on the host and the token is validated by exact match, rooting a hill does not let a team forge ownership. Keys rotate from the green-team panel on suspicion of a leak.

Layer 2: bridge into the RedutaCTF platform

RedutaCTF treats King of the Hill as an out-of-process plugin: a small HTTP service that the core talks to over signed webhooks and a token-scoped awards API. The reference koth-plugin that ships with RedutaCTF is the bridge.

1. The core sends the plugin a signed webhook on every minute tick. The plugin verifies it: an HMAC-SHA256 over timestamp + "." + body in X-Reduta-Signature, with X-Reduta-Delivery for idempotency.
2. On tick.minute the plugin looks up who currently holds each target (from KOTH's scoreboard state) and posts an award to the core.
3. The award is idempotent by ref_id, so a redelivered tick never double counts.

# the plugin awards the current holder, once per tick per target
POST http://core:8080/api/v1/plugin/v1/awards
Authorization: Bearer plg_...
{"event_id":"...","team_id":"<current holder>","points":5,
 "ref_id":"tick:2026-09-02T10:00:00Z:hill-1","reason":"KotH tick hill-1"}

The bridge is configured with environment variables, and the only KOTH-specific part is mapping a KOTH team to a RedutaCTF team and reading the current holder from the KOTH scoreboard:

KOTH_WEBHOOK_SECRET   # shared secret for verifying core webhooks
KOTH_CORE_URL         # RedutaCTF core, e.g. http://server:8080
KOTH_PLUGIN_TOKEN     # plg_... token issued when the plugin is registered
KOTH_EVENT_ID         # the RedutaCTF event this game scores into
KOTH_TARGET           # which hill/target this bridge scores

Verify a bridge before an event with reduta plugin verify, which checks it accepts signed webhooks, is idempotent on redelivery, and rejects bad signatures. The platform side of this contract is documented in the RedutaCTF wiki.

Documentation

Before you run it