Telling a hijacked prefix from a legitimate transfer

Why the snapshot is silent

A BGP announcement carries a prefix, an AS path, and the origin AS at the end of it. It carries no claim about authorisation, because the protocol has nowhere to put one. A router that accepts a route has not checked whether the announcing network holds the space; it has checked whether the route survived its filters, which is a different and usually easier question.

So the end state has the same shape either way: prefix P, origin AS B, where last month it was origin AS A. Every tool reporting current state reports the same thing about both, and it is not being unhelpful. There is nothing else in the snapshot.

What differs is the sequence. Whether A stopped, and when. When B started. Whether a ROA appeared before the change, after it, or never. Whether the registry moved, and how long afterwards. Whether B held the prefix for two hours or two years. None of those are properties of the present, and a tool keeping only the latest value overwrote each one at its last refresh. Keeping the dated sequence instead is the reason subnethistory exists.

The signals, and what each is worth

Seven observations do most of the work. They are not equally strong, and totalling them up like a checklist produces confident wrong answers. Weight them.

Overlap in time

The strongest single signal, and the one a snapshot destroys most completely. In an authorised handover the old origin withdraws and the new one announces. There may be a gap of minutes or a coordinated cutover with a brief planned overlap, but the old holder participates. In a hijack the legitimate origin never stops, because the attacker has no way to make it stop. Both are announced at once from different origins: a multiple origin AS conflict, or MOAS. A clean withdraw-then-announce sequence is strong evidence of cooperation. A persistent MOAS is not automatically the reverse, for reasons covered below, but it is what should make you keep reading.

RPKI validity

Three states, and the asymmetry between them is where most misreadings start.

• Valid is strong evidence of authorisation. A ROA is signed under the RIR's certificate hierarchy by whoever controls the holder's account, so a valid new origin means somebody with that control named it. That is what permission looks like written down.
• Invalid is worth noting and is not conclusive. A ROA covers the prefix and the announcement contradicts it, on origin or on length. That describes hijacks. It equally describes a rightful holder who changed something and did not update the ROA.
• Not-found says nothing at all. No ROA covers the prefix. It remains common in older IPv4 space and it is not a mild form of invalid.

When the ROA appeared matters more than the state it produces. One published for the new origin before the origin changed is the signature of a planned migration: somebody prepared. One published a fortnight after, or never, proves nothing either way, but it removes the best exculpatory signal available.

Registry movement

If the RDAP record changes holder in the same window and the RIR's transfer listing includes the prefix, a transfer is close to established. RIPE NCC, ARIN and APNIC all publish transfer records, and the delegated statistics files show blocks moving between organisations and regions.

The caveat is large. Registration lags routing, routinely by weeks, and a transfer inside one corporate group may change no visible name. Leases never appear in a transfer log at all, because nothing was transferred: the holder stays put and only the announcing network changes. That is a large legal market producing origin changes against a completely static registry, and it is the biggest source of false positives here.

A more specific of space the origin does not hold

Longest-prefix match means a /24 announced out of somebody else's /16 wins for those 256 addresses everywhere the route is accepted, whatever the AS path looks like. Since /24 is also the longest IPv4 prefix most of the default-free zone will carry, a great many events land on exactly that boundary.

The shape to look for is a new origin announcing one more specific and nothing else nearby, while the covering block keeps being announced by its long-standing holder. The benign version is a customer assigned that /24 and multihoming it, or the holder splitting their own block. In those cases the new origin usually has some other visible relationship to the covering holder. In the hostile case it has none.

How long it lasted

Hijacks are frequently brief, many lasting minutes to hours, because the point is to hold the space long enough to finish something and because the real holder tends to notice. Transfers persist. A change still in place six months later is very unlikely to be a hijack: somebody would have complained. Brevity proves nothing in the other direction, since failed configuration changes, testing and DDoS mitigation are all short-lived too.

Contact records and handles

In a real change of holder the org handle, abuse-c, tech-c and often the netname move too, within weeks of each other. In a hijack the registry is untouched, because the attacker never had access to it. Useful corroboration, weak alone: plenty of legitimate changes leave contacts deliberately unchanged.

IRR route objects

The weakest signal here. Several routing registries accept objects with little proof that the submitter holds the space, and objects in non-authoritative databases have been used to get announcements past upstream filters. An object in the RIR's own authoritative registry is worth much more.

Reading the evidence end to end

The readings below use documentation address space and AS numbers, from RFC 5737 and RFC 5398. Building a hijack narrative around a real network would be an accusation, and an accusation assembled from inference is what this site exists not to make.

What an authorised change looks like

• 4 November. A ROA appears for 198.51.100.0/24, origin AS64500, maximum length 24. The prefix is still announced by AS64496, as it has been since 2019.
• 18 November, 02:10 UTC. AS64496 withdraws. The prefix is unannounced for roughly forty minutes.
• 18 November, 02:52 UTC. AS64500 announces it, RPKI valid from the first update because the ROA was already there.
• 27 November. The RDAP record changes: new org handle, new abuse-c, new netname.
• January. The RIR transfer listing shows the block, recipient matching the new org handle.
• Today. Still announced by AS64500.

Read as a sequence, it is not ambiguous. The ROA precedes the announcement. Nothing overlapped. The registry followed, in the order a transfer produces. Three of those steps required control of the holder's RIR account, which an attacker does not have. This was a transfer, and it would have been one even if the transfer log had never appeared.

What an unauthorised one looks like

• 2 March, 09:14 UTC. 192.0.2.128/25 appears from AS64502. It is a more specific of 192.0.2.0/24, announced by AS64497 since 2017 and still announced without interruption throughout.
• The /24 has a ROA: origin AS64497, maximum length 24. The /25 is invalid on both counts, wrong origin and too long.
• AS64502 announces nothing else inside that /24 and holds no adjacent space in any registry.
• Six collector peers see it, out of several hundred, all six through one transit provider.
• 11:40 UTC. Withdrawn. Total lifetime, 2 hours 26 minutes.
• No RDAP record changed. No transfer listing. No contact object touched.

Overlap, invalid against an existing ROA, a more specific of space the origin does not hold, no registry movement anywhere, a short life and narrow propagation. Six observations pointing the same way, none of which a transfer would produce.

The correct conclusion is still narrower than it feels. This is consistent with an unauthorised announcement and inconsistent with an authorised one, and it identifies neither motive nor culprit. An operator mistyping an AS number in a redistribution statement produces this exact shape, and so does a route leak a filter should have caught. The evidence separates authorised from unauthorised, not malice from error.

The false positives

This is where the reading goes wrong in practice. Every item below produces an origin change that looks alarming in isolation and is entirely legitimate.

Leases

The most common by a wide margin. A holder leases a block to an operator, who announces it from their own AS. The registry does not move, because nothing was sold, and no transfer log entry ever appears. If the holder is diligent a ROA names the lessee's AS; if not, it reads not-found or invalid and looks worse than it is.

A customer changing upstream

A network with address space but no AS number of its own is announced from its provider's AS. Change provider and the origin changes completely, from one reputable network to another, with no registry movement because the holder never changed. The announcement is often invalid for weeks afterwards, the ROA still naming the old provider. This one trips automated flagging constantly.

Multihoming and getting an ASN

That same network, having acquired its own AS number, starts announcing its space itself: the origin moves from the provider's AS to the customer's. Add a second upstream and both providers may announce it alongside the customer for a while. A permanent MOAS, and a customer growing up rather than an attack.

Anycast

One prefix announced from many locations at once is the normal design for DNS and CDN infrastructure. 1.1.1.0/24 from AS13335 and 8.8.8.0/24 from AS15169 are announced worldwide, and paths that look wildly inconsistent between collectors are the point. Most anycast keeps one origin AS, but operators that have absorbed other networks sometimes announce from several, giving a stable MOAS years old. Where every origin is covered by a ROA from the same holder, that is design, not conflict.

DDoS mitigation

Under attack, a network redirects traffic to a scrubbing provider, which announces the prefix, frequently a more specific, from its own AS until the attack ends. Sudden appearance, unfamiliar origin, more specific, short life, invalid if the ROA was not provisioned in advance. That is the hijack shape almost exactly. What separates it is the pattern of the new origin: mitigation providers do this visibly and repeatedly for many unrelated prefixes.

Deaggregation for traffic engineering

A holder splits a /20 into /24s to steer inbound traffic and announces some from a different AS in the same group. Origins change on the more specifics only, the registry stays still, and if the ROA has a maximum length of 20 the holder has just made their own announcements invalid. A meaningful share of all RPKI-invalid announcements are maximum-length mistakes by the rightful holder.

What the data cannot tell you

BGP data is a view from collectors, not ground truth. Public route collectors see the internet through a few hundred peering sessions with networks that agreed to participate. Anything that never propagates to one of those peers never enters the record. A hijack confined to one transit provider's customer cone, or accepted only in one region, can be invisible to every public dataset, including this one.

That cuts against the way these questions are usually asked. Absence of a MOAS event is not evidence that a prefix was never hijacked. It is evidence that no collector peer saw one, which is a much weaker statement and often not the one an analyst reports.

Sampling interval matters as much. Routing state reconstructed from the update stream catches an event lasting twenty minutes; state snapshotted every few hours does not, and nothing in the resulting timeline shows anything was missed. Any dataset should tell you which of the two it does, because a gap and a quiet period render identically. Collector timestamps have the same character: they record when the collector saw an update, not when the announcement began, so every first-seen time is an upper bound.