Playbook 1: Registry reconnaissance and initial ROA creation¶

Why this chain was selected¶

This is a true control-plane attack, not data-plane abuse.

Most BGP incidents are forged letters carried by an overly trusting postal service. Someone announces a prefix they shouldn’t. The network believes them because BGP is fundamentally trusting. Those are data-plane attacks, like putting up a misleading street sign.

This playbook attacks the Guild Registry itself.

RPKI ROAs are the authoritative source that answers “who is allowed to announce this prefix?” They are meant to be the truth that routers check announcements against. If we can manipulate ROAs, we don’t just send false announcements: we redefine what “valid” means.

From the BGP hijacking attack tree, we’re implementing a variant of node 1.3.3 Advanced persistence combined with node 1.1.2.3 Exploiting lack of route validation. But we’re not just exploiting the absence of validation. We’re poisoning the validation system itself.

This is the first playbook in a three-part chain:

1. Reconnaissance and ROA creation (this playbook) - establish baseline, create legitimate-looking ROAs

2. ROA expansion and validation testing (playbook 2) - gradually expand authorisation scope

3. Prefix hijacking with operational cover (playbook 3) - exploit poisoned ROAs to hijack traffic whilst appearing valid

The chain works because each phase provides cover for the next. By the time we actually hijack traffic, the validation system is already compromised and will mark our hijack as legitimate.

Attack chain overview¶

Phase 1 (This playbook):
Registry reconnaissance → Legitimate ROA creation → Baseline establishment

Phase 2 (Playbook 2):  
ROA scope expansion → Validation deployment timing → Multi-region testing

Phase 3 (Playbook 3):
Prefix announcement → Traffic interception → Sustained hijack with "valid" status

This differs from data-plane hijacks because:

• Data-plane hijack: “I claim to originate 203.0.113.0/24” (forged announcement)

• Control-plane poisoning: “The Registry now says I’m authorised to originate 203.0.113.0/24” (rewritten truth)

When validators check our announcement in phase 3, they will consult the poisoned ROAs we created in phases 1-2 and return VALID. We’re not bypassing validation. We’re corrupting it.

Attack tree path¶

From the BGP hijacking tree:

Primary path: 1 → 1.1 Prefix hijacking → 1.1.2 Exact-prefix hijacking → 1.1.2.3 Exploiting lack of route validation

But with a critical modification: we’re not exploiting the absence of validation. We’re implementing node 1.3.3.1 Long-term hijacking for espionage by first corrupting the validation infrastructure itself.

Phase 1 Actions¶

Action 1.1: RPKI infrastructure reconnaissance¶

Intent Map the RPKI trust infrastructure for target prefix 203.0.113.0/24 to identify whether ROAs exist, who controls them, and which Regional Internet Registry manages the allocation.

Preconditions

• Target prefix 203.0.113.0/24 is allocated to victim AS65001

• We have obtained AS number AS64513 through legitimate RIR allocation process (required for creating ROAs)

• We do not yet have legitimate authority over 203.0.113.0/24

Execution method

Use RIPE Stat RPKI Validation and Routinator to check current ROA status:

# Check if ROAs exist for target prefix
curl "https://stat.ripe.net/data/rpki-validation/data.json?resource=203.0.113.0/24"

# Check via Routinator
routinator vrps --output json | jq '.roas[] | select(.prefix == "203.0.113.0/24")'

# Identify RIR managing this allocation
whois -h whois.arin.net 203.0.113.0/24

Query results should show:

• Whether victim AS65001 has created ROAs

• Maximum prefix length authorised (typically /24)

• Trust anchor (which RIR’s RPKI system manages this)

• Last update timestamp

Expected technical effect

Within 5 minutes of queries:

• We have documented current ROA state for 203.0.113.0/24

• We know whether RPKI validation is protecting this prefix

• We understand update frequency (used in phase 2 for timing)

• We’ve identified gaps: if maxLength is /24, they haven’t authorised more-specifics

Common findings (budget reality):

• ~60% chance no ROA exists at all (organisations haven’t deployed RPKI)

• ~30% chance ROA exists but maxLength is /24 only (leaves /25 attacks viable)

• ~10% chance ROA has maxLength /25 or smaller (defensive, harder to attack)

Expected observational footprint

Reconnaissance footprint:

• HTTPS queries to stat.ripe.net visible in their logs (shared public infrastructure, not notable)

• Routinator queries to local validator leave no external footprint

• WHOIS queries to RIR visible in query logs (extremely common, not suspicious)

Detection likelihood: Effectively zero. These are normal network operator queries that happen thousands of times daily.

Manual steps

• Review WHOIS output to confirm RIR jurisdiction (ARIN, RIPE, APNIC, etc.)

• Check whether victim organisation has published RPKI information in their public documentation

• Verify that our AS64513 is properly registered and has no existing ROAs that might conflict

Timing uncertainty Queries complete in 2-10 seconds typically. If RIR WHOIS is slow or Routinator’s cached data is stale, allow up to 60 seconds.

Budget reality check Many organisations don’t monitor RPKI query patterns. Even those with RPKI deployed rarely log who’s checking their ROA status. This reconnaissance is effectively invisible.

Action 1.2: Create legitimate ROA for our own prefix¶

Intent Establish ourselves as a normal RPKI participant by creating valid ROAs for a prefix we legitimately control, building trust with the RPKI ecosystem before attempting manipulation.

Preconditions

• We control a legitimate IP allocation (e.g., 198.51.100.0/24 allocated to our AS64513)

• We have account access to RIR’s hosted RPKI service or run our own RPKI Certificate Authority

• RIR allows us to create ROAs for our own resources (standard capability)

Execution method

Via RIPE NCC’s hosted RPKI service:

1. Log into RIR portal with credentials

2. Navigate to RPKI management interface

3. Create ROA for our legitimate prefix:

   • Prefix: 198.51.100.0/24

   • Origin AS: AS64513

   • Max length: /25 (slightly defensive, appears security-conscious)

ROA configuration:
{
  "asn": "AS64513",
  "prefix": "198.51.100.0/24",
  "maxLength": 25,
  "ta": "ripe"
}

4. Submit ROA creation request

5. Wait for publication (15-45 minutes typical)

Expected technical effect

Within 60 minutes:

• ROA appears in RIPE’s RPKI repository

• Validators polling RIPE (Routinator, FORT, rpki-client) will fetch updated repository

• Global validators should show our 198.51.100.0/24 as having valid ROA

• Any announcements of 198.51.100.0/24 from AS64513 will validate as VALID

• Announcements from other ASes will validate as INVALID

This establishes our presence as a “normal RPKI-aware operator” in the ecosystem.

Expected observational footprint

ROA creation footprint:

• RIR audit logs show ROA creation request from our account

• RPKI repository publication logs show new ROA added

• Validators see new ROA during next poll cycle (usually 10-30 minute intervals)

• No alerts expected because we’re creating ROAs for resources we legitimately own

Detection likelihood: Zero. This is completely legitimate RPKI usage.

Manual steps

• Verify RIR portal authentication still works (accounts can expire)

• Check that our IP allocation is properly documented as ours in RIR database

• Wait for email confirmation from RIR (some send notifications)

• Manually verify publication: routinator vrps --output json | jq '.roas[] | select(.prefix == "198.51.100.0/24")'

Timing uncertainty

ROA publication timing is notoriously variable:

• RIR acceptance: 0-5 minutes (usually instant, occasionally queued)

• Repository publication: 15-30 minutes (RIPE publishes every ~20 minutes)

• Validator polling: 10-30 minutes (depends on validator’s refresh interval)

• Router refresh: 30-60 minutes (routers poll validators less frequently)

Total time until globally visible: 30-90 minutes typically. Budget 2 hours to be safe.

On Fridays after 15:00: add 24-72 hours because nobody will investigate “why hasn’t this published” until Monday.

Budget reality check

This action costs nothing but time. Most RIRs provide hosted RPKI services at no additional charge to resource holders. The only barrier is having obtained legitimate AS and IP allocations first, which we’ve assumed as precondition.

Action 1.3: Baseline documentation¶

Intent Document the current legitimate RPKI state before manipulation, so we can measure the impact of future changes and maintain cover story if questioned.

Preconditions

• Action 1.1 (reconnaissance) has completed

• Action 1.2 (our own ROA) has been published and verified

• We have secure storage for documentation (not in version control, not in emails)

Execution method

Create timestamped baseline document (stored offline, encrypted):

# RPKI Baseline - [DATE]

## Target: AS65001 / 203.0.113.0/24

Current ROA status:
- ROA exists: [YES/NO]
- Origin AS authorised: [AS NUMBER or "none"]
- Max prefix length: [/24, /25, etc. or "none"]
- Last updated: [TIMESTAMP from RPKI repository]
- Trust anchor: [ARIN/RIPE/APNIC/etc.]

Validation deployment status:
- RPKI validation deployed globally: ~40% (industry baseline)
- Validators observed: Routinator, FORT, rpki-client, RIPE, Cloudflare
- Enforcement mode common: "log only" (not "drop invalid")

## Our position: AS64513 / 198.51.100.0/24

Our ROA status:
- ROA created: [TIMESTAMP]
- Visible in validators: [TIMESTAMP of first appearance]
- Validation result: VALID
- Publication lag observed: [X minutes]

## Cover story

If questioned about our RPKI activity:
"We're implementing RPKI ROAs for our allocated resources as part of routine security hardening. We follow MANRS best practices and are systematically creating ROAs for all our announcements."

This is completely true and requires no deception.

Expected technical effect

No direct technical effect. This is documentation only. However, having baseline enables:

• Measuring success/failure of future ROA manipulation

• Detecting if victim modifies their ROAs (requires re-planning)

• Maintaining timeline for attribution analysis if incident response occurs

Expected observational footprint

None. This is local documentation.

Manual steps

• Verify documentation is stored securely (not on network-accessible systems)

• Cross-reference our observations with public BGP monitoring services to ensure we’re seeing the same data as defenders would

• Document which validators we’re monitoring (need to check multiple, as they can disagree)

Timing uncertainty

Documentation should take 15-30 minutes to complete thoroughly. Do not rush this. Incomplete baseline documentation means you won’t know what changed when phase 2 begins.

Budget reality check

Most organisations don’t monitor who’s researching their RPKI status. Even sophisticated defenders don’t have alerting on “someone looked up our ROAs”. This is intelligence gathering, not attack execution, and leaves no actionable footprint.

Recording the mess honestly¶

Manual verification requirements¶

Action 1.2 requires manual verification that the ROA actually published. Automated tools can tell you a ROA should have published. They cannot reliably tell you that all validators have seen it, that repositories synchronised correctly, or that there wasn’t a publication error.

Someone has to:

1. Check multiple independent validators (Routinator, FORT, Cloudflare’s)

2. Verify the ROA details match what was submitted

3. Confirm the trust anchor chain is intact

4. Check that no conflicting ROAs exist

This takes 10-20 minutes of careful checking. It’s tedious. It’s necessary. Skipping it means you might proceed to phase 2 thinking you have valid RPKI presence when you actually don’t.

Timing dependencies on RIR processes¶

RIR RPKI publication schedules are not published and not consistent. RIPE publishes roughly every 20 minutes. ARIN’s timing varies. APNIC is different again. You cannot automate around this. You must wait and check.

If your ROA submission lands just after a publication cycle, you wait 20+ minutes for the next one. If it lands during a maintenance window (unannounced), you might wait hours. If it’s Friday afternoon, you might wait until Monday.

Budget 2-4 hours for Action 1.2 completion, not because the action takes that long, but because waiting for publication does.

Third-party dependencies¶

We depend on:

• RIR publication infrastructure working correctly (it usually does, but not always)

• Validators polling on their normal schedule (they usually do, but can be delayed)

• Repository rsync/RRDP not having connectivity issues (rare but happens)

• No conflicting ROA submissions from other parties

The first three are out of our control. The fourth is unlikely but possible: if the legitimate holder of 203.0.113.0/24 creates their first ROA during our operation, our entire plan changes.

Where best practice lost to budget reality¶

Best practice says: organisations should monitor RPKI query patterns, log ROA creation attempts, audit RPKI access regularly, and have alerting on new ROAs appearing for their address space.

Budget reality says: most organisations have none of these. RPKI is deployed by security-conscious network operators, but monitoring and auditing of the RPKI system itself is rare. Logging exists but is not actively reviewed. Alerts are aspirational.

The gap between best practice and reality is what makes phase 1 viable. If every organisation had sophisticated RPKI monitoring, Action 1.1 reconnaissance would trigger alerts. They don’t, so it doesn’t.

Success criteria for phase 1¶

Phase 1 succeeds when:

• We have documented baseline for target prefix 203.0.113.0/24

• We have established our own legitimate ROA presence for 198.51.100.0/24

• We have verified our ROA appears in multiple independent validators

• We have confirmed publication timing (used for phase 2 planning)

• We have clean operational security (no premature queries that might alert target)

Phase 1 fails if:

• Target creates new ROAs before we begin phase 2 (requires re-planning)

• Our ROA fails to publish (indicates RIR process problem, must resolve before continuing)

• We trigger attribution warnings (unlikely, but if we do, abort entire operation)

Transition to phase 2¶

Do not proceed to phase 2 until:

1. Our legitimate ROA has been published and verified in at least 3 different validators

2. Baseline documentation is complete and stored securely

3. At least 7 days have passed since our ROA creation (establishes us as normal long-term participant)

4. Target’s RPKI status has not changed (if it has, reassess entire attack chain)

Phase 2 (ROA expansion) will be detected if executed too quickly after establishing presence. The 7-day waiting period provides operational cover by making our later actions appear part of routine RPKI maintenance rather than coordinated attack preparation.