Bulletproof hosting

Bulletproof hosting is not a technology. There is no bulletproof server, no bulletproof stack, nothing you could identify by fingerprinting the machine. What is being sold is a promise about behaviour: that your abuse complaints will go unanswered, your legal requests will go unread, and the box will still be there next month. Everything else about the service can be ordinary, and usually is.

That matters for the first practical reason: you cannot detect bulletproof hosting by looking at a host. You detect it by watching what happens after somebody reports it.

What the premium actually buys

These providers charge well above the market rate for equivalent hardware, and the gap is the entire product. A customer is not paying for uptime in the engineering sense. They are paying for a specific kind of silence:

• Abuse mail that reaches a mailbox nobody reads, or an address that bounces
• Registration that asks for no verifiable identity and accepts payment in a form that does not carry one either
• A jurisdiction chosen so that the law enforcement request has to cross a border, and preferably several
• Tolerance for content or activity that any commercial host would terminate within hours
• Fast reissue: when a range does finally get burned, a replacement is available the same day

The last item is the one defenders underestimate. The individual address is disposable by design. The provider is not.

How it survives being known

Almost none of these operations own the metal. The usual shape is a chain: a legitimate datacentre or transit provider at the top, one or more resellers in the middle, and the abuse-tolerant service at the bottom selling to the actual customer. Each layer gives the one above it deniability and the one below it a supply.

That structure is why pressure applied to the visible end so rarely works. Terminating a customer removes a customer. Terminating a reseller removes a reseller, and the operation reappears behind a different one within days, frequently on the same upstream network. The thing with continuity is the network relationship, and it sits a layer or two above where the complaint was aimed.

A second pattern follows from the same structure: the ranges outlive the campaigns running on them. Unrelated operations, with different tooling and different targets, share address space for months because they are all customers of the same tolerant supplier. Two intrusions that appear connected because they resolved to neighbouring addresses may share nothing but a landlord.

Blocking the right object

The operational consequence is that a host is the wrong unit of defence here. Block a single address and the campaign moves before your change control ticket closes. Block and track at the level that actually persists.

• Work at prefix and autonomous system level rather than per host, and expect the useful lifetime of that decision to be months rather than hours
• Keep a record of which ranges answered an abuse report and which did not. That answer, or its absence, is the only reliable signal of what you are dealing with
• Watch for the reissue: a burned range being replaced from the same upstream tells you where the relationship really lives
• Resist inferring a shared actor from shared address space. Co-tenancy at an abuse-tolerant provider is weak evidence of anything except a shared supplier

There is a fair objection to range-level blocking, which is that it catches innocents. It does. The honest position is that a provider whose business model is not answering abuse reports has chosen which side of that trade it sits on, and the cost of the ambiguity belongs to it rather than to you.

The defender's version of this in one line: track the landlord, not the tenant. Tenants move out constantly. The building stays where it is.

Connected terms

Read elsewhere

• MITRE ATT&CK T1584: Compromise Infrastructure
• MITRE ATT&CK T1583.003: Virtual Private Server