Routing Security and IP Hijacking

If you acquire or vet IP address space for an email service provider (ESP), the history of that space matters as much as its current reputation. Email reputation is usually discussed at the level of IP addresses and domains. The layer beneath it, which decides who may announce an IP range into the global routing table, is also used for abuse.

Spammers, bulletproof hosting providers 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 addresses exhausted, three ways of getting fresh space have become channels for abuse:

• BGP or IP hijacking: announcing address space you do not own;
• the IPv4 transfer market: buying blocks, including blocks with a hidden history of abuse;
• the IPv4 leasing market: renting blocks month by month, which hides the real user from WHOIS.

The mitigation is RPKI and Route Origin Authorizations (ROAs), which let a legitimate sender prove, and a receiver verify, that the routing of a range is authorized.

For the checklist of what to inspect before you assign a leased or purchased block to customers, see IP-Acquisition Diligence. For how the resulting listings appear and are removed, see Blocklists and Spamhaus and Spamhaus Listings Deep Dive.

Why hijacking is an email problem

Spammers rotate IP addresses the way they rotate domains. An IP address that sends spam soon earns a poor reputation and gets listed, so the operator needs fresh, clean IP addresses all the time. Announcing IP space that legitimately belongs to someone else, or that has been abandoned, meets that need without any registry paperwork that links the abuse back to the operator. The stolen space is used for a burst of spam or for hosting malware, then released before or while it gets listed, and the cycle starts again.

This is the network-level equivalent of snowshoe spamming, which spreads the load thinly across many IP addresses to stay under the thresholds applied to each one. The difference is that the IP addresses themselves are taken without permission.

Spamhaus's DROP, EDROP and 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 lists four ways to acquire ranges. Two are legitimate on paper and two are abusive:

Legacy space is the favourite target

Ranges issued before ARIN was created in 1997 ("legacy" allocations) are prime targets for hijacking. They make up roughly 35.9% of the entire IPv4 address space. They were issued before modern registration practices, they often have no owner who pays for them or pays attention to them, and they cannot be revoked for non-payment. A block can therefore lie dormant and forgotten for years, until an attacker brings it back into use.

The Chemstress case (147.50.0.0/16): how a hijack works

Spamhaus documents a typical takeover of a dormant /16. It shows that a hijack is a social engineering operation against the registry, not only a technical trick with BGP:

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

Fighting abuse at the edge

Spamhaus argues for blocking malicious traffic at the routing layer, on edge routers (through BGP), rather than waiting for detection at the application layer (SMTP or HTTP). It names these patterns of abuse:

• Rogue autonomous systems. Bad actors run their own autonomous system (AS) and announce routes through BGP. Chains of compromised autonomous systems are common, and criminals exploit "customer-of-a-customer" relationships so that no single upstream provider feels accountable.
• Accepting routes without checking. Upstream providers often pass on rogue routes for months, because of weak 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 and keep their networks off the global routing table, so that route monitors do not detect them.

Mitigations Spamhaus recommends for network operators:

• Deploy the DROP, EDROP and ASN-DROP lists on edge routers to deny connectivity to networks known to be criminal.
• Verify the routes your BGP customers announce. Look into a customer's history of abuse and routing before you accept their routes, and watch for route rotation: announce, send spam, withdraw.
• Adopt BGP Flowspec (RFC 5575 / RFC 7674) to push dynamic access control lists (ACLs) to edge devices in real time. For example, feed data from the BCL (Botnet Controller List) through Flowspec to blackhole botnet command and control servers, one IP address at a time.
• Get the networking and anti-abuse teams to work together, since they usually sit in separate silos.

For scale, Spamhaus reports that its DNSBLs protect ~2.7 billion mailboxes, that it was founded in 1998, and that it has ~30 investigators across 9 countries. The BCL list stays small but is growing.

The IPv4 transfer market as an abuse channel

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

The timing shows deliberate evasion of filters. Blocklist reports peak within one year after the transfer date, for every type of malicious activity (spam, phishing, malware, botnet command and control, prefix hijacking, unsolicited scans, illegal content). The abuse appears after the transfer even when the address space was in use and visible to scans at least a month before it.

The imbalance remains after removing legitimate space belonging to cloud providers and very large networks (AWS, Google Cloud), whose infrastructure services are abused for short-lived malware virtual machines. Repeat BGP hijackers and bulletproof hosting providers are over-represented among market participants. The authors describe the numbers as a lower bound, because transactions that are not reported never appear in RIR databases.

The IPv4 leasing market: a newer channel that WHOIS cannot see

Leasing means renting a block for as little as one month, while the prefix stays registered to the lessor. It is less transparent than buying. Because the RIR processes no transfer, the lessee's identity is never recorded in WHOIS. The real user of the address block is hidden, and abuse complaints and vulnerability notifications do not reach them. Malicious actors use this to rotate "clean" blocks quickly and discard used ones, getting around IP blocklisting.

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

Listings of leased prefixes were stable before the lease started, and then rose steadily through the measurement period. That is the pattern of a block that stays clean until a lessee starts abusing it. The Level 1 figure (2.89×) is a conservative minimum, and the figure from the broad set of lists is an upper limit.

The size of the market (TMA 2025). More than >6,184 transfers covering 30.2M addresses took place in 2024. One broker alone reported 757 transfers worth US$60.7M. IPv4 addresses are now used as collateral for loans: one company issued US$206M in notes secured by its IPv4 assets. Waiting times at the RIRs as of Feb 2025 were 498 days at RIPE NCC, 615 days at ARIN and 1,417 days at LACNIC. This scarcity is what pushes 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 extras. These are legitimate uses of the same tools that abusers exploit.

What this means for operators. A leased or transferred block is statistically more likely to be dirty than routed space chosen at random, and its history is harder to see. Checking reputation before you acquire a block is not optional: look at its blocklist history, its earlier SWIP and WHOIS records, and SenderScore and Talos (see IP-Acquisition Diligence).

RPKI and ROAs: the mitigation

RPKI (Resource Public Key Infrastructure) uses cryptography to bind IP prefixes to the AS numbers authorized to originate them, so networks can reject false 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 holder of the resource, that contains three fields (RFC 6482):

For example, a ROA for 192.0.1.0/24 with a maxLength of /25 authorizes announcing that /24 or its two adjacent /25s, but nothing more specific. Limiting maxLength blocks the classic hijack, in which the attacker announces a more specific sub-prefix (which BGP always prefers) to divert traffic.

Route Origin Validation (ROV) states

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

Space without a ROA ends up NotFound, not Invalid, so RPKI protects only the prefixes whose legitimate holder has published a ROA. That is the direct action for a sender who wants clean space: publish ROAs for your sending ranges. A hijacker's announcement of your space that is more specific or has the wrong origin is then marked Invalid and dropped by networks that enforce ROV, and a receiver's routing infrastructure treats your own announcements as authorized.

It also protects you as a buyer. The PAM 2020 finding that 6% of transferred prefixes covered by a ROA had an inconsistent origin ASN is exactly the kind of mismatch ROV brings to light.

The RPKI documentation notes that the vast majority of route hijacks are unintentional, caused by typing mistakes in the origin or by route leaks. Broad ROA coverage makes both accidental and malicious wrong origins easy to identify and reject.

Beyond origin validation

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

Bottom line for an ESP

1. Fresh IP space is a commodity for spammers. Hijacking, buying and leasing are all ways to get it, and all three leave measurable traces on blocklists.
2. Leased blocks are 1.84–2.89× and transferred blocks 4–25× more likely to be dirty than routed space chosen at random, and leasing deliberately hides the operator from WHOIS. Vet a block before you assign it (see IP-Acquisition Diligence).
3. Publish ROAs for your sending prefixes. A hijack of your space then becomes Invalid at networks that enforce ROV, and it shows that the operation is well run. Before you acquire a block, check that its ROA and origin are consistent.
4. Spamhaus DROP, EDROP and ASN-DROP, and the BCL (optionally through BGP Flowspec), let you refuse traffic from networks known to be criminal at your own edge.