Simulator scenario 3: Prefix hijacking with RPKI validation cover

High‑level objective

Playbook 3 models the execution of a validated prefix hijack where control‑plane poisoning from earlier phases allows the hijack to appear legitimate to RPKI validators.

The goals are:

  1. Announce a sub‑prefix that validates as RPKI VALID

  2. Verify traffic interception and differential regional impact

  3. Maintain service continuity through transparent forwarding

  4. Monitor operational stability to avoid detection

  5. Execute a controlled withdrawal and assess forensic evidence

Why this matters:

  • Unlike an invalid hijack, this attack does not trigger RPKI invalid alerts because validation has been poisoned. :contentReferenceoaicite:0

  • Network defenders relying on RPKI may see compliant states while traffic is diverted.

  • Service continuity and subtle monitoring make detection harder.

Key narrative:

“Control‑plane poisoning makes hijacks look like valid business routing. This scenario demonstrates the payoff of earlier phases.” :contentReferenceoaicite:1

Simulator scenario definition

Playbook 3 scenario.yaml and telemetry.py model the full lifecycle of a validated hijack, from announcement through monitoring and controlled withdrawal.

The timeline includes regional traffic interception tests, forwarding establishment, victim traffic analysis, periodic monitoring checks, and controlled withdrawal phases.

Telemetry for this scenario is defined in telemetry.py. It maps each timeline action to specific observable signals that a telemetry pipeline will emit when running the simulation.

For example:

  • phase2_complete → internal phase transition telemetry

  • hijack_announcement → BMP route monitoring and realistic BGP syslog

  • announcement_propagation → bgp.propagation events

  • rpki_validation_check → both RPKI validation events and syslog

  • traffic_interception_test → simulated traceroute (network.traceroute)

  • interception_summary → internal analysis events

  • service_continuity_verified → service check telemetry

  • monitoring_check → internal monitoring status

  • withdrawal_announcement → BMP withdrawal + syslog

  • traffic_reconvergence → bgp.reconvergence attribute events

  • Post‑operation actions (hijack_evidence_assessment, cleanup_decision) → internal analysis events summarising forensic evidence

In contrast to Playbook 1 (which establishes legitimacy) and Playbook 2 (which expands scope), Playbook 3 executes an attack that is validated as normal by RPKI.

  • Defensive systems that rely on RPKI state may fail to raise alarms

  • BGP syslogs and propagation look typical

  • Only correlation across multiple telemetry sources reveals the true state

This scenario is ideal for testing SIEM pipelines where signal correlation is essential, not just single‑source detection rules.