How to play

1. Register your team with the captain's account details.
2. Verify the captain's email address and wait for organizer approval. The portal marks the team active when it is approved.
3. Invite the rest of the team from Team → Members.
4. Each member downloads a personal WireGuard config from Team → Infrastructure and the shared vulnbox SSH key from Team → Secrets.
5. Bring up WireGuard, use the ready-to-copy SSH command on Team → Infrastructure, and confirm you can reach your vulnbox.

Complete these steps before the opening tick. If the tunnel or SSH connection fails, fix it before making service changes. The connectivity checklist and common VPN problems are explained below.

Jump to: game loop, team workflow, flag submission, scoring, or rules.

AD-CTF is an attack/defense capture-the-flag competition. Every team runs the same vulnerable services on an isolated vulnbox. You must protect your copies while exploiting the same services on other teams' boxes.

Unlike a jeopardy-style CTF, there is no list of challenges that stay solved. The checker plants new flags throughout the event, so successful teams repeat their attacks, keep their patches working, and react quickly when a service breaks.

The game advances in fixed 3-minute rounds called ticks. The same cycle runs for every service and every team:

1. The checker uses the service like a normal user and stores a fresh flag.
2. It retrieves current and still-valid earlier flags. This verifies availability, expected behavior, and data integrity.
3. Teams exploit opponents, extract those flags, and submit them before the validity window closes.
4. The scoreboard adds offense and SLA points, then subtracts defense penalties.

Example: a flag planted in tick 40 may be submitted during ticks 40 through 45. It becomes OLD in tick 46. Finding a vulnerability once is only the start; your exploit must collect each new generation of flags.

1. Inventory first. Identify each service, port, process, data store, and normal user flow before changing anything.
2. Patch narrowly. Fix the vulnerability without changing the protocol or deleting data that the checker expects. Keep a quick rollback path for every change.
3. Test continuously. Watch your service status after each patch. Use the NOP team to validate exploits against an unmodified target.
4. Automate offense. Read the published targets and attack information, run the exploit against every opponent, and submit new flags on every tick.
5. Learn from traffic. Review your delayed PCAPs and logs to see how other teams reach your services, then close the weakness without breaking legitimate behavior.

Split ownership inside the team: keep one person watching health and rollbacks while others reverse, exploit, and automate. Reassign people as new attack paths appear.

The game network is reachable only over WireGuard. Every active team member downloads their own config. There is no shared team VPN file and no client key to upload.

1. Sign in and open Team → Infrastructure.
2. Select "Download my VPN config". This file is personal; do not share it.
3. Bring the tunnel up with your platform's WireGuard client (wg-quick up <file> on Linux, or the official WireGuard app on macOS/Windows/mobile).
4. Confirm the tunnel has a recent handshake, then test the connection to your assigned vulnbox.

Only run one game VPN tunnel at a time per machine. Another VPN may install a conflicting route even when WireGuard reports that the tunnel is up. You can safely download a fresh copy of your config from Team → Infrastructure at any time.

Vulnboxes are centrally hosted. You don't download, import, or run a VM/OVA image yourself. Each team is assigned its own box on the game network; once your WireGuard tunnel is up, you reach it over SSH using your team's shared SSH key from Team → Secrets. Any approved, active team member can download the current key. Captains also manage secret generation and rotation.

You are working on the live service host. A saved file, restart, firewall rule, or database change can immediately affect the checker and every attacker. Preserve expected functionality and stored data; blocking access or deleting flags may stop an exploit, but it also costs SLA.

Your team's address, connection details, and downloads live on Team → Infrastructure once you're signed in.

Service names and connection details become visible before play begins. Once the game starts, teams.json publishes opponent addresses and current attack information in a machine-readable format. Use it to drive your automation and watch the scoreboard for results.

Flags look like FLAG{...}. Submit them over the line-based TCP service: it sends a welcome banner, then accepts one flag per line and returns one result per line in the same order. A manual session follows this sequence: nc <submission-host> <port>, welcome banner, captured flag, result. Replace the placeholders with the endpoint shown on Team → Infrastructure.

The service credits the team associated with your source game-network IP. Keep WireGuard up; there is no separate submission login. Scripts may keep a connection open and send several flags, provided each flag is on its own line and rate limits are respected.

Results are OK (accepted), DUPLICATE (already submitted by your team), OLD (expired), OWN (from your own service), INVALID (malformed or unknown), SPAM (a limit was reached), INVALID_SENDER (the source does not map to an active team), or ERROR (an internal failure that is safe to retry).

Offense increases for each valid flag captured from a scoring team. Every capture has a base value plus a rarity bonus. With the default formula, a flag captured only by your team is worth 2 offense points; if two teams capture it, each receives 1.5.

Defense starts at zero and becomes negative when other teams steal your flags. The penalty grows with the number of captures. Keeping a flag safe causes no defense penalty.

SLA rewards correct service operation on each checker visit. UP receives full credit, RECOVERING receives half credit, and failed checks receive no SLA credit. The field size scales the SLA value so shutting down a vulnerable service is not a winning strategy.

Your total is Offense + Defense + SLA. Scores are calculated per service, then combined on the scoreboard.

These are the public status labels shown on the scoreboard:

• UP: the last checker visit succeeded. The service responded correctly and the planted flag was retrievable. Full SLA credit.
• RECOVERING: the service is available, but a recovery rule applies after a recent failure or an organizer-approved restart. Partial SLA credit.
• FAULTY: the service is reachable but behaves incorrectly, such as returning an unexpected response. No SLA credit.
• FLAG NOT FOUND: the service answered, but a flag stored earlier is missing or changed. Check persistence, cleanup jobs, and patch side effects. No SLA credit.
• DOWN or TIMEOUT: the checker could not establish a working connection or the service answered too slowly. No SLA credit.

NOT CHECKED means no result exists for that service and tick yet. If several teams change status at once, wait for organizer guidance before assuming your patch caused it.

1. Registration open: Registration continues. Services stay hidden from teams.
2. Services public: Service metadata is visible. Checks and submissions stay idle.
3. Game running: Checks dispatch and submissions are accepted unless checks are cancelled.
4. Game over: Scores are final and new scoring activity is stopped.
5. Scoreboard freeze: organizers may freeze the public scoreboard near the end of the game so final standings are revealed all at once instead of trickling in. Scoring, checks, and submissions keep running underneath; only the public standings are paused until organizers unfreeze them.

This is the full set of rules that you accept on the registration form:

• Attack only through the game network and only against services in scope for the event.
• Do not attack the checker, scoreboard, submission service, or other organizer systems.
• Do not share WireGuard configs, SSH keys, or account passwords outside your team.
• Report a suspected vulnerability in event infrastructure privately to organizers rather than exploiting or disclosing it publicly.

Stuck, or think something's wrong with scoring or the game network? Find an organizer at the event help desk rather than posting details of a vulnerability publicly.