C2Games Metadata File

Each Challenge Submission must contain a c2games.yml file describing the challenge. A template c2games.yml file is included in the template directory, and full examples can be found within each example role.

There are several fields in the c2games.yml metadata file:

Field Type Required Description Example
Title string yes Title of the Challenge "Netcat Bind Shell"
Version string yes Version of the Challenge (usually 1.0) "1.0"
Author string no Person or Persons that created the challenge "Brodie Davis, Bryer Esengard"
Organization string no Organization to attribute challenge too "C2 Games"
Type string yes Type of challenge. Typically, one of "Exploit" or "Misconfiguration" "Exploit"
Difficulty integer yes Expected Difficulty to resolve challenge, on a scale 1 (easy) – 10 (impossible) 4
Description string yes Description of the challenge. This will be used internally, and not displayed to participants. "Create a malicious Netcat listener that creates a shell session when connected to."
OSCompatibility List yes Operating Systems this challenge is compatible with. Note that only the least specific relevant field is required – for example, if a challenge works on any Ubuntu system, you only need to specifiy "Family: Linux" and "Id: ubuntu", not the version number.
OSCompatibility.Family string yes Operating System Family – One of "Linux or "Windows" "Linux"
OSCompatibility.Name string no Operating System Name, as retrieved by the variables in /etc/os-release. "Ubuntu"
OSCompatibility.Version string no Operating System Version, as retrieved by the variables in /etc/os-release. "20.04"
OSCompatibility.Id string no Operating System ID, as retrieved by the variables in /etc/os-release. "ubuntu"
OSCompatibility.IdLike string no Operating System ID LIKE field, as retrieved by the variables in /etc/os-release. "debian"
Exploitation List yes Examples of how to exploit the challenge. An Exploitation entry is required, but can be either a description or an example command (both fields are not required)
Exploitation.Example string no Example command to exploit the challenge "nc 4444"
Exploitation.Description string no Description of how to use the example command, or general description for exploiting the challenge. "Connect to a shell using a basic netcat connection to the port"
Mitigation string yes Description how the challenge can be Mitigated "Stop the netcat and shell processes, and remove the persistence method (ex, delete the cron job starting the listener)."
Training string yes This is a short description of how students might be trained on the skills required for this Challenge. This is a short description of how students might be trained on the skills required for this Challenge. This shouldn’t give away the exact challenge but should incorporate the skills required to hunt for the vulnerability. "Use Netstat or a similar tool to check for applications with an open port on the system"
Justification string yes The justification this challenge should be included as an Infrastructure Challenge. This documents the key educational elements or topics that are covered or reinforced by the challenge. It may also include specific skills that are required to be able to solve the challenge. This will be used to evaluate student competencies. "This challenge requires participants to search out suspicious processes and common persistence methods. When searching for the source of the netcat listeners, it is reasonable for a participant to find additional exploits, and encourages exploration of the system."

Submission File Structure

Each C2Games Infrastructure Challenge Submission will be in the form of an Ansible Role, with a c2games.yml Metadata File in the root of the role. The Ansible role should be packaged into a zip file to be uploaded as a single package.

For example, to submit a role named ssh_authorized_keys:

└── ssh_authorized_keys/
    ├── c2games.yml
    ├── defaults
    │   └── main.yaml
    ├── handlers
    │   └── main.yml
    └── tasks
        └── main.yaml

Only the c2games.yml and tasks/main.yml files are required, but any file supported by an Ansible role is supported within a submission.


All challenges should be tested against at least one Debian/Ubuntu-based system, and one CentOS based system.

Ansible files should also be able to pass Ansible Lint.