Can IPv4 addresses be stolen?

Yes. The usual methods are taking over a dormant registry account, reviving or impersonating a defunct holder company to claim its legacy space, forging authorisation documents, and insider manipulation of registry records. Registries can and do reverse transfers obtained by fraud, which leaves the buyer without the block.

What happens if I buy a stolen block?

The registry can return the block to the legitimate holder once the fraud is established, and your claim for the money is against the seller, who may be unreachable. Verification before signing and escrow released only on the registry update are the protection.

Which blocks are most at risk?

Legacy space registered to companies that no longer exist, blocks unannounced for years with outdated contacts, and blocks whose registry record changed recently with no matching transfer record. These are attractive because nobody is watching them.

How do I protect my own block from being stolen?

Keep registry contacts and maintainer credentials current, enable two-factor authentication on the registry portal, sign ROAs (an AS0 ROA for space you do not announce), monitor for unexpected announcements, and in the RIPE region consider a Voluntary Transfer Lock.

Stolen IPv4 Addresses and Other Transfer Risks

Reviewed by Lukas Brandt, Head of IPv4 brokerage

Most IPv4 transfers complete without incident. The ones that fail tend to fail in a small number of ways, and almost all of them show warning signs before money moves. This page describes each pattern, what it looks like from the buyer’s side, and the check that catches it.

Risk patterns at a glance

Risk	How it works	Warning sign	Check that catches it
Revived dormant holder	Fraudster re-registers or impersonates a defunct company that holds legacy space	Holder dissolved for years, then suddenly “active” with new contacts	Company registry history; chain of title
Registry account takeover	Credentials or contact email of a neglected account are taken over	Contacts changed shortly before the sale	`last-modified:` dates on org and role objects
Forged authority	Fake board resolutions, powers of attorney, or LOAs	Signer not in the company extract; documents only as scans	Signatory check against a fresh extract
Unauthorised insider	Employee sells the employer’s block without approval	Seller contact uses a personal email; reluctance to involve the company’s management	Direct confirmation from a company officer
Payment diversion	Bank details “updated” by email from a spoofed address	Change of account details close to funding	Phone confirmation on a known number
Hijacked routing	Unused block announced by an unrelated ASN, sometimes for spam	Short-lived announcements from unknown origins	BGP history; RPKI state
Encumbered block	Block subject to litigation, a pledge, or insolvency proceedings	Seller vague about the company’s financial state	Court and insolvency records; seller warranties
Policy failure	Transfer refused because of a restriction window or failed needs test	Block received recently; recipient with no usage plan	Restriction check; registry pre-approval

The checks in the right-hand column are all on the block verification checklist.

Stolen blocks

Address space is valuable, often unwatched, and registered in public databases. That combination produces theft.

Dormant legacy space is the main target. Blocks issued before the RIR system to companies that later merged, failed, or forgot about them may still sit in the registry under a company that no longer exists. A fraudster who revives the company name in a jurisdiction with lax incorporation rules, or forges documents of succession, can try to take over the record.

Registry account takeover follows the same logic. If the registered contact email is on a domain that has expired, anyone who re-registers the domain can receive password resets.

Insider abuse has happened at registry level too. AFRINIC disclosed in 2019 that millions of addresses had been misappropriated from its records with the involvement of a staff member. ARIN’s case against Micfo, a company that obtained hundreds of thousands of addresses through shell companies and false documentation, ended in revocation of the space and a criminal plea in the US. For the buyer-side view of why verification matters, see IPv4 due diligence: verifying ownership on the blog.

The consequence for a buyer is the same in every variant: once the fraud is established, the registry can return the block to its legitimate holder. The buyer’s claim is against a seller who may have disappeared.

Forged and missing authority

The holder of record is real, but the person selling is not entitled to sell. Signs:

The signer does not appear in the company registry extract and offers no power of attorney from someone who does.
Documents arrive only as scans, with signatures that cannot be verified, and a request for an original is resisted.
Communication runs through a personal email address or a domain that differs from the company’s.
The seller asks to keep the deal away from the company’s management or legal team.

The fix is simple and occasionally awkward: confirm the sale directly with an officer of the holder, using contact details from the company registry or the company’s own website, not from the seller.

Payment diversion

The most frequent cause of lost money in these deals has nothing to do with the registry. An attacker who has access to one party’s mailbox, or who registers a lookalike domain, sends “updated” bank details shortly before funding. The buyer pays the attacker; the registry transfer never happens because the seller was never paid.

Confirm every change of payment details by phone on a number you held before the change. Use escrow released only on the registry update, as described in escrow and payment.

Routing and reputation inherited with the block

A block can be legitimately sold and still bring problems:

Hijack history. Unannounced blocks are sometimes announced briefly by unrelated networks to send spam. The legitimate holder may not even know. The block arrives with listings and with route objects in third-party IRRs.
Undisclosed leases. The holder leased the block to a third party who is still using it, so completion means cutting someone off or inheriting their abuse record.
Stale ROAs and route objects. These authorise an origin other than yours and make your announcement invalid or filtered until removed.

None of these blocks the transfer, but each delays production use. Make removal the seller’s obligation in the contract, and follow the post-transfer checklist after completion.

Protecting a block you hold

Holders who plan to sell later, or simply keep spare space, reduce their exposure with routine hygiene:

Keep registry contacts on domains you control and will renew, and enable two-factor authentication on the registry portal.
Sign an AS0 ROA for space you do not announce, so validating networks drop hijack attempts.
Monitor for announcements of your prefixes from any ASN.
In the RIPE region, consider a Voluntary Transfer Lock for 6, 12, or 24 months. It is irrevocable once approved and the lock list is public, which deters anyone trying to sell space they do not control.
Check the record from outside periodically with WHOIS and RDAP.

If you are preparing a block for sale and want the checks done before you approach buyers, see selling IPv4 safely.

Last updated on October 3, 2026

Post-transfer checklist