Routing Security and IP Hijacking

Email reputation is usually discussed at the IP and domain layer, but the layer beneath it — who is allowed to announce an IP range into the global routing table — is itself an abuse vector. Spammers, bulletproof hosters, and botnet operators need a constant supply of IPv4 space that has not yet been "burned" (listed on blocklists), because their sending burns reputation fast. With IPv4 exhausted, three ways to get fresh space have become abuse channels: BGP/IP hijacking (announcing address space you don't own), the IPv4 transfer market (buying blocks, including ones with a hidden abuse history), and the IPv4 leasing market (renting blocks month-to-month, which hides the real user from WHOIS). This article covers those vectors and the mitigation, RPKI/ROA, that lets a legitimate sender prove — and a receiver verify — that a range's routing is authorized.

This is background for anyone acquiring or vetting IP space for an ESP. For the operational checklist of what to inspect before assigning a leased/purchased block to customers, see IP-Acquisition Diligence. For how the resulting listings appear and clear, see Blocklists and Spamhaus and Spamhaus Listings Deep Dive.

Why hijacking is an email problem

Spammers cycle IPs the way they cycle domains. A source IP that sends spam quickly earns a poor reputation and gets listed, so the operator needs fresh, clean IPs continuously. Announcing IP space that legitimately belongs to someone else — or that has been abandoned — supplies that need without any registry paperwork tying the abuse back to the operator. The stolen space is used for a burst of spam or malware hosting, then released before (or as) it gets listed, and the cycle repeats. This is the network-layer equivalent of snowshoe spamming: spreading load thinly across many IPs to stay under per-IP thresholds, except the IPs themselves are misappropriated.

Spamhaus's DROP/EDROP/ASN-DROP datasets and the SBL DROP return code (127.0.0.9, "hijacked/leased-to-spammers netblocks; never route") exist specifically to flag this — see Blocklists and Spamhaus.

How criminals acquire IP ranges

Spamhaus enumerates four acquisition paths, two legitimate-on-paper and two abusive:

Path	Mechanism	Abuse angle
Direct assignment from an RIR	Become an RIR member, get allocated space	Legitimate, but slow and increasingly scarce
Assignment from an ISP	Downstream allocation from an upstream provider	Legitimate; bulletproof hosters exploit lax upstreams
Hijacking abandoned ranges	Impersonate the original owner of dormant space	Route space nobody is watching
Temporarily stealing allocated ranges	Announce a slice of someone's live space, then release it	"Route rotation" — spam, then vanish

Legacy space is the favourite target

Ranges issued before ARIN's inception in 1997 ("legacy" allocations) are prime hijacking targets. They are roughly 35.9% of the entire IPv4 address space, they predate modern registration discipline, they often lack a paying/attentive owner, and they cannot be revoked for non-payment — so a block can lie dormant and forgotten for years. An attacker resurrects it.

The Chemstress case (147.50.0.0/16) — the anatomy of a hijack

Spamhaus documents a canonical takeover of a dormant /16, showing the hijack is a social-engineering operation against the registry, not a purely technical BGP trick:

Date	Step
2011-08-19	Register a look-alike domain using the original ARIN contact's name
2011-12-12	Social-engineer ARIN into updating the block's contact information to the attacker
2011-12-16	Begin unauthorized BGP route announcements for the /16
2012-06-10	Update the company address to a mail-forwarding drop

Once the registry record is falsified, the fraudulent route announcement looks authorized to any network that only checks WHOIS.

Fighting abuse at the edge

Spamhaus's "edge" framing: block malicious traffic at the routing layer on edge routers (via BGP) rather than waiting for application-layer (SMTP/HTTP) detection. The abuse patterns it names:

• Rogue autonomous systems — bad actors run their own AS and announce routes via BGP. Chains of compromised ASes are common; criminals exploit "customer-of-a-customer" relationships so no single upstream feels accountable.
• Blind route acceptance — upstreams often propagate rogue routes for months because of insufficient vetting and "automated processes set up to accept, almost blindly, whatever customers announce."
• Direct peering to stay invisible — criminal groups peer directly with a target provider, keeping their networks off the global routing table to avoid detection by route monitors.

Operator mitigations Spamhaus recommends:

• Deploy DROP / EDROP / ASN-DROP lists at edge routers to deny connectivity to known-criminal networks.
• Verify BGP customer route announcements — investigate a customer's abuse and routing history before accepting routes; watch for route-rotation patterns (announce, spam, withdraw).
• Adopt BGP Flowspec (RFC 5575 / RFC 7674) to push real-time dynamic ACLs to edge devices — e.g. feed BCL (Botnet Controller List) data via Flowspec to blackhole C&C at single-IP granularity.
• Coordinate networking and anti-abuse teams (the two usually sit in separate silos).

Scale context from Spamhaus: its DNSBLs protect ~2.7 billion mailboxes; founded 1998; ~30 investigators across 9 countries; the BCL list stays small but trends upward.

The IPv4 transfer market as an abuse channel

When you buy a block on the secondary market, you may be buying a hidden abuse history — or the seller may be a serial abuser offloading burned space. Giotsas, Livadariu & Gigis (PAM 2020, "A first look at the misuse and abuse of the IPv4 Transfer Market") quantified this across a decade of transfers (2009-10-12 → 2019-08-24), synthesizing IP blocklists, honeypot data, prefix-hijacking detection, and AS-reputation lists:

Finding	Value
Transferred routed prefixes with ≥1 blocklist report	~40%
Non-transferred routed prefixes with ≥1 blocklist report	6%
Transferred /24 sub-prefixes vs non-transferred: blocklisting likelihood	6× more likely
Transferred space overall, depending on abuse type	4× to 25× more likely to be blocklisted
Transfers whose reported date/recipient org disagreed with WHOIS + BGP routing	>65%
ROA-covered transferred prefixes with an inconsistent origin ASN	6%
ASes acting as both buyer and seller vs single-role: blocklisted-space rate	2× higher

Timing is the tell of deliberate filter evasion: blocklist reports peak within one year after the transfer date, across all malicious-activity types (spam, phishing, malware, botnet C&C, prefix hijacking, unsolicited scans, illegal content) — and the abuse appears after transfer even when the address space was deployed and visible to scans at least a month before the transfer. The disproportion persists after filtering out legitimate cloud/hypergiant space (AWS, Google Cloud) whose IaaS gets abused for short-lived malware VMs. Serial BGP hijackers and bulletproof hosters are over-represented among market participants. The authors call the numbers a lower bound — unreported transactions escape RIR databases entirely.

The IPv4 leasing market — a newer, WHOIS-blind channel

Leasing (renting a block for as little as one month, the prefix staying registered to the lessor) is worse for transparency than buying: because no transfer is processed at the RIR, the lessee's identity is never recorded in WHOIS, obscuring the actual user of an address block and defeating abuse-complaint and vulnerability-notification workflows. Malicious actors exploit this to rapidly cycle "clean" blocks and discard used ones, circumventing IP blocklisting.

Degen et al. (TMA 2025, University of Twente / CAIDA, "From Scarcity to Opportunity: Examining Abuse of the IPv4 Leasing Market") measured leased vs non-leased prefixes over 82 days (Dec 2024 – Mar 2025) using FireHOL blocklists:

Finding	Value
Leased prefixes blocklisted (FireHOL Level 1) vs non-leased, Feb 2025 snapshot	2.89× more likely (0.518% vs 0.179% mean)
Same comparison on the broader full aggregated 253-blocklist set	1.84× more likely (32.0% vs 17.4%)
Anonymizer (VPN/proxy) prevalence in leased vs non-leased space	2.59× more prevalent
Increase in abuse-category blocklisting 30 days after lease start	+60.2%
Increase in abuse-category blocklisting 150 days after lease start	up to +269%
Increase in malware-category blocklisting 150 days after lease start	+37.9%

Reputation of leased prefixes was stable before the lease started, then rose steadily through the measurement window — the signature of a block being clean until a lessee starts abusing it. The Level 1 number (2.89×) is a conservative floor; the broad-list number an upper ceiling.

Market scale context (TMA 2025): >6,184 transfers covering 30.2M addresses were traded in 2024; one broker alone reported 757 transfers worth US$60.7M; IPv4 is now used as loan collateral (one firm issued US$206M in notes secured by its IPv4 assets). RIR waiting-list times as of Feb 2025: RIPE NCC 498 days, ARIN 615 days, LACNIC 1,417 days — scarcity is what drives operators to the secondary and leasing markets in the first place. Notably, some brokers now offer RPKI management, prefix "parking" (announcing a prefix from the broker's own AS), IP-reputation services, and delisting-as-a-service as value-adds — legitimate uses of the same tooling abusers exploit.

Operator takeaway: a leased or transferred block is statistically dirtier than randomly-routed space and its history is harder to see. Pre-acquisition reputation checks (blocklist history, prior SWIP/WHOIS, SenderScore/Talos) are not optional — see IP-Acquisition Diligence.

RPKI and ROAs — the mitigation

RPKI (Resource Public Key Infrastructure) cryptographically binds IP prefixes to the AS numbers authorized to originate them, letting networks reject bogus route announcements. Origin validation is currently the only RPKI function in operational use.

Route Origin Authorization (ROA)

A ROA is a signed object, published by the legitimate resource holder, containing three fields (RFC 6482):

Field	Meaning
Prefix	The IP address block being authorized
Origin AS number	The single AS permitted to originate that prefix in BGP
maxLength	The most-specific prefix length the AS may advertise

Example: a ROA for 192.0.1.0/24 with maxLength /25 authorizes announcement of that /24 or its two adjacent /25s — but nothing more specific. Constraining maxLength blocks the classic hijack of announcing a more-specific sub-prefix (which BGP always prefers) to siphon traffic.

Route Origin Validation (ROV) states

A router compares each BGP announcement against the set of Validated ROA Payloads (VRPs) and assigns one of three states:

State	Condition	Typical action
Valid	Prefix + origin AS covered by ≥1 VRP, within maxLength	Accept
Invalid	Wrong origin AS, or more specific than maxLength allows	Reject / de-preference
NotFound (Unknown)	No VRP covers the prefix (no ROA published)	Accept (fail-open)

Because unsigned space falls to NotFound (not Invalid), RPKI only protects prefixes whose legitimate holder has published a ROA. That is the direct action item for a sender establishing clean space: publish ROAs for your sending ranges so that a hijacker's more-specific or wrong-origin announcement of your space is scored Invalid and dropped by ROV-enforcing networks — and so a receiver's routing infrastructure treats your announcements as authorized. It also protects you: the PAM 2020 finding that 6% of ROA-covered transferred prefixes had an inconsistent origin ASN is exactly the discrepancy ROV surfaces.

The RPKI documentation notes the vast majority of route hijacks are unintentional (fat-finger origin/leak errors); widespread ROA coverage makes both accidental and malicious mis-origination easy to pinpoint and reject.

Beyond origin validation

• BGPsec (RFC 8205) validates the entire AS path, not just the origin — but real-world deployment "may prove limited."
• ASPA (Autonomous System Provider Authorization) — draft work for path validation, an emerging middle ground between origin-only ROV and full BGPsec.

Bottom line for an ESP

1. Fresh IP space is a spammer commodity; hijacking, buying, and leasing are all ways to get it, and all three leave measurable fingerprints on blocklists.
2. Leased and transferred blocks are 2–6× (up to 25×) likelier to be dirty than random routed space, and leasing deliberately hides the operator from WHOIS. Vet before you assign — see IP-Acquisition Diligence.
3. Publish ROAs for your sending prefixes: it makes hijacks of your space Invalid at ROV-enforcing networks and signals a well-run operation. Verify a candidate block's ROA/origin consistency before acquiring it.
4. Spamhaus DROP/EDROP/ASN-DROP and BCL (optionally via BGP Flowspec) let you refuse traffic from known-criminal networks at your own edge.