Sequence of work

This plan covers the creation and submission of CTF challenges for Root-Me using OT/ICS protocols such as Modbus, DNP3, and IEC-104. The environment is based on two complementary simulation approaches:

  • A dynamic, multi-component ICS environment

  • A deterministic, single-system simulator

No external hosting is required. Execution occurs within Root-Me infrastructure using Docker-based setups or standalone artefacts such as PCAP files.

Phase 1: define the core mechanic

  1. Select challenge concept

  2. Identify the single technique being tested

  3. If the flag is vague, the challenge is vague. Define flag location and retrieval method

Phase 2: choose the environment

  1. Decide between dynamic (ics-simlab) and deterministic (power-and-light-sim)

  2. Justify the choice based on:

    • Interaction needs

    • Reproducibility

    • Complexity budget

This decision prevents over-engineering later.

Phase 3: build the minimal scenario

  1. Implement only the components required for the mechanic

  2. Remove or disable unrelated services

  3. Stabilise behaviour:

    • Fix values where randomness adds no value

    • Keep dynamic effects only if they are part of the lesson

Phase 4: validate the attack path

  1. Execute the full attack from scratch

  2. Record commands and outputs

  3. Check for unintended alternative solutions

If a shortcut exists, it becomes the solution.

Phase 5: generate artefacts

  1. For Network challenges:

    • Capture traffic during exploitation

    • Verify completeness and clarity

  2. For Realist challenges:

    • Verify service exposure

    • Confirm consistent startup behaviour

Phase 6: write documentation

  1. README:

    • Objective

    • Minimal setup

    • Target description

  2. Solution:

    • Exact steps

    • Expected outputs

    • Explanation of impact

  3. This is where the challenge stops being a trick and becomes useful. Add context:

    • What would break the attack in reality

    • Detection opportunities

    • Incorrect assumptions

Phase 7: package and verify

Documentation that is not tested is fiction.

  1. Create .zip

  2. Extract on clean system

  3. Follow README exactly

  4. Confirm solution still works

Phase 8: submit and iterate

Patterns in reviewer feedback are more valuable than initial design assumptions.

  1. Submit small batch

  2. Incorporate feedback

  3. Refine subsequent challenges