Simulator scenario 1: Registry reconnaissance and initial ROA creation

High‑level objective

Before attempting any prefix hijack, understand and establish legitimacy in the RPKI system. That means:

  1. Discover existing RPKI ROAs for the target prefix

  2. Create a legitimate ROA for a prefix you control

  3. Document the baseline so defenders (and your SIEM) see this as “normal” activity

Why this matters:

  • Later stages exploit weaknesses in RPKI validation

  • But without first establishing legitimacy, later hijacks look suspicious

  • So playbook 1 is about laying the groundwork without triggering alerts or suspicion This is a control‑plane attack strategy — not merely announcing forged prefixes, but shaping the validation infrastructure that tells routers what is “valid.” ([purple.tymyrddin.dev][1])

Key narrative:

“RPKI ROAs are meant to be the truth that routers check announcements against. If we can manipulate ROAs, we redefine what ‘valid’ means.”

This is different from a normal BGP hijack. It is a control‑plane preparation that makes later hijacks look valid.

Turning playbook 1 into a simulator scenario

Control-plane attack preparation showing:

  • RPKI infrastructure reconnaissance (Action 1.1)

  • Legitimate ROA creation and publication (Action 1.2)

  • Baseline documentation (Action 1.3)

The scenario.yaml and telemetry.py code is based on the essence of Playbook 1, boiled down to what matters for the simulator.

These map to the three phase‑1 actions described in the playbook. The telemetry.py mapping script decides what telemetry to emit for each type of event in scenario.yaml and mirrors Phase 1 actions without making anything malicious.