Follow the Operator · 05 — The Bulletproof Landlord: When the Address Attributes the Enabler, Not the Tenant

Follow the Operator — Case 05. This register takes a cloud of unrelated-looking attacks and follows one forensic thread back to the single hand behind them, closing each case on the signal that clinched it: SHARED KEY · SHARED MALWARE · SHARED FINGERPRINT · SHARED INFRASTRUCTURE · SHARED BEHAVIOR · NAMED IDENTITY.

The first four cases followed threads that led, when they held, to a single operator — a key, a payload, a tool that belonged to one hand. This case follows a thread that does not lead there, and the point of the case is to be honest about where it does lead. Some attackers cluster together because they share an address in the most literal sense: they rent from the same hosting provider. And not just any provider — an abuse-tolerant one, a bulletproof host whose business is renting infrastructure to people who will be complained about, and ignoring the complaints. When the honeypot sorts its attackers by who registered their address space, a few names rise with a disproportionate share of the hostility, and those names are the subject of this case: the landlords of the criminal internet.

The honeypot names two clearly. A registrant recorded as TechTies Inc. accounts for around 47 attacking IPs, at an average threat score of 78.5 — one of the highest-threat registrant concentrations the sensor holds. A registrant listed only as IP Manager accounts for around 33. These are not the largest registrants by volume — the clouds and the telecoms dwarf them — but they are among the most concentrated in hostility, address space that is disproportionately, characteristically hostile. The sensor can say this with confidence because its registrant attribution is well-grounded: RDAP and WHOIS enrichment covers 94% of its IPs, and Team Cymru's ASN data covers 99.9%, so the question "who registered this address" is answered for nearly every attacker it sees. The provider-level picture is nearly complete.

But here is the case's discipline, and it is the reason this case exists in a register about attributing operators: a shared landlord is not a shared tenant. The 47 IPs under TechTies do not belong to one operator; they belong to however many unrelated operators rented from TechTies, which is the whole point of a bulletproof host — it rents to many, indiscriminately, and asks no questions. So the shared registrant attributes the provider, strongly, and the operator, barely. This is the infrastructure version of the shared-tool trap: just as a shared SSH library ties together a tool's userbase rather than one hand, a shared bulletproof host ties together a landlord's tenants rather than one operator. Linkage signal: SHARED INFRASTRUCTURE — but the register splits its confidence in two, because the signal supports one claim strongly and a different claim weakly, and conflating them is exactly the error to avoid.

1. What a Bulletproof Host Is For

Begin with the entity, because the bulletproof host is a specific and deliberate thing, and understanding its business model is understanding why the shared-registrant signal points where it does. A bulletproof host is a hosting provider that markets, explicitly or implicitly, its tolerance of abuse. Ordinary providers respond to abuse complaints — a report that a customer is sending spam, hosting malware, or launching attacks gets the customer suspended, because the provider does not want the liability, the reputation damage, or the blocklisting that follows. A bulletproof host does the opposite: it ignores the complaints, keeps the customer online, and charges a premium for doing so. Its whole value proposition, to its customers, is that it will not take you down when people ask it to. It sells impunity as a service.

This business model has consequences that make it visible to a sensor, and they are exactly what the honeypot sees. Because a bulletproof host's customers are disproportionately the people who attract abuse complaints — spammers, malware operators, attack infrastructure — its address space is disproportionately hostile. A normal provider's addresses are mostly benign with a scattering of abuse; a bulletproof provider's addresses are concentratedly malicious, because malice is what its customers do. So when the honeypot finds a registrant whose 47 IPs average a 78.5 threat score, it is not seeing bad luck; it is seeing the statistical signature of a provider whose customer base is selected for hostility. The high concentration of threat under one registrant is the fingerprint of the business model — a landlord who rents specifically to the kind of tenant the honeypot exists to catch.

And the bulletproof host often compounds its function by obscuring its tenants, which is the second half of why the shared-registrant signal attributes the provider rather than the operator. Bulletproof and abuse-tolerant providers frequently use opaque registrant records — nominee names, shell entities, generic labels like "IP Manager," reassigned space with no downstream customer detail — precisely so that the individual tenant behind any given address cannot be identified from the record. The registrant you can see is the provider or its front; the operator you cannot see is the tenant. So the RDAP record, which the honeypot has for 94% of its attackers, reliably names the landlord and reliably hides the tenant — which is exactly the information structure that makes this a case about attributing the enabler, because the enabler is what the record actually reveals.

2. The Trap: One Landlord, Many Hands

Now the central caution, stated as plainly as the register can state it, because it is the error this whole case exists to prevent: the number of IPs under a shared bulletproof registrant tells you almost nothing about the number of operators behind them. A bulletproof host with 47 hostile IPs in the honeypot might be renting to two operators or to forty; the shared registrant is consistent with any of these, because the registrant is the landlord, and the landlord's tenant count is exactly what the shared-registrant signal does not reveal. To look at 47 IPs under one registrant and conclude "one operator with 47 machines" is to make the infrastructure version of the mistake the fingerprint case warned against — to attribute the shared thing (the provider) to a single hand, when the shared thing is precisely the thing many hands share.

This is why, on the register's shareability axis, a shared bulletproof host sits at the far shareable end — more shareable, for attribution purposes, than even a common tool. A common SSH library at least implies its users chose the same software; a shared bulletproof host implies only that its tenants chose the same impunity, which unrelated criminals do constantly, for the same reason unrelated tenants choose the same lax landlord. The bulletproof host is, in a sense, the perfect anti-attribution infrastructure: it gathers unrelated operators under one roof and one opaque record, so that sharing it is maximally uninformative about sharing a hand. An operator who wants to be hard to attribute rents bulletproof precisely because it puts him in a crowd of other operators, and the crowd is the disguise.

So the register assigns, for the claim "these IPs are one operator," a LOW confidence — and it wants to be clear that LOW here is not a hedge but a finding. It is genuinely, positively likely that the 47 IPs under a bulletproof registrant are several operators, not one, because that is what bulletproof hosting is for. The shared registrant is not weak evidence of one operator; it is, if anything, mild evidence of several. To use it as a basis for one-operator attribution would not be cautious optimism; it would be reading the signal backwards. The register states this because the temptation to cluster on shared infrastructure is strong — it is easy, the data is nearly complete (94% coverage), and it produces satisfyingly large clusters — and easy, complete, large, and wrong is the most dangerous combination in attribution. Shared bulletproof infrastructure produces exactly that temptation, and the register's answer is to name the trap and refuse the cluster.

3. The Enabler Is Real, and Worth Naming

Now the turn that makes this a case rather than a warning, because the same signal that weakly attributes the operator strongly attributes something else, and that something else is worth attributing: the enabler. The bulletproof host is a real entity. It has a name — TechTies Inc., or whatever the opaque record resolves to; it has a legal existence, a business, an ASN, upstreams that peer with it, registrars and registries that maintain its records, payment channels that fund it. Unlike the individual tenant, who is hidden by design, the provider is exposed by design — it has to exist visibly enough to sell its service. So the shared-registrant signal, which barely attributes the tenant, strongly attributes the landlord: for the claim "these IPs share one enabling provider," the confidence is HIGH, because the registrant record, which the honeypot has for 94% of its IPs, says so directly.

And attributing the enabler is not a consolation prize; it is often the more valuable attribution, because the enabler is a chokepoint. An individual operator is one of thousands, and taking him down — even successfully — removes one of thousands. The provider that hosts hundreds of operators is one entity, and pressure on it degrades all of them at once. This is the strategic logic of enabler attribution: the bulletproof host is a single accountable node through which many operations flow, so action against the node — depeering it so no network will route its traffic, sanctioning it, pressuring its registrar or registry, escalating abuse through its upstreams, cutting its payment channels — has a multiplier that no per-operator action can match. When threat intelligence names a bulletproof provider and the community acts on the name, many unrelated operators lose their impunity simultaneously, which is precisely what per-operator attribution, however accurate, cannot achieve one hand at a time.

This is why the register keeps the enabler in the six-word vocabulary under SHARED INFRASTRUCTURE rather than discarding infrastructure as merely a failure mode. Infrastructure is a failure mode for operator attribution — it is the trap of section 2 — but it is a success mode for enabler attribution, and the two are different targets served by the same signal. The discipline is simply to be explicit about which target you are attributing: a shared bulletproof host is HIGH-confidence evidence about the landlord and LOW-confidence evidence about the tenant, and an honest report says both, in those words, rather than letting the strong claim about the enabler quietly borrow credibility for a weak claim about the operator. The register names TechTies and IP Manager as high-threat enabling registrants at HIGH confidence, and declines to name any single operator behind them at more than LOW — and holding those two confidences apart, in the same case, on the same data, is the entire craft the case is teaching.

4. SHARED INFRASTRUCTURE — The Split-Confidence Signal

The linkage signal is SHARED INFRASTRUCTURE, and it is the register's first signal that carries two confidences at once, which is why it earns its own case rather than being folded into the others. Every prior signal attributed one thing at one confidence: the key attributed the operator at HIGH, the fingerprint attributed the operator at MEDIUM-HIGH. SHARED INFRASTRUCTURE attributes two different things at two different confidences — the enabler at HIGH, the operator at LOW — and the whole lesson of the case is that you must report both and never collapse them. It is the signal that forces the register to say explicitly what it always means implicitly: a linkage signal does not attribute "an actor" in the abstract; it attributes a specific role at a specific confidence, and shared infrastructure makes the roles diverge so sharply that the divergence cannot be papered over.

That divergence generalizes into a principle the rest of the register uses: shared infrastructure narrows the field but does not select the hand. A shared bulletproof host is a filter — it says "the operator you are looking for is somewhere among this provider's tenants," which is genuinely useful, because it shrinks the search space from the whole internet to one provider's customer base. But it is only a filter; selecting the actual operator from among the tenants requires a less-shareable signal — a shared key, a bespoke C2, a behavioral tic — that ties specific IPs within the provider to one hand. So infrastructure is where an operator hunt begins, not where it ends: cluster by provider to narrow, then corroborate within the cluster to select. An operator who is both under a bulletproof host and reusing a key is attributable; the key selects him, and the provider merely told you which crowd to look in.

This is the honest reason SHARED INFRASTRUCTURE sits where it does in the register's ordering — after the strong, operator-selecting signals and before the behavioral ones — because it is the signal that most tempts the analyst to over-attribute and most rewards the analyst who does not. Used naively, it produces the biggest and wrongest clusters in the whole discipline: "here are 200 IPs under one bulletproof ASN, therefore one mega-operator," a claim that is almost always false and almost always seductive. Used correctly, it produces two true things: a strong, actionable attribution of an enabling provider, and a narrowed field within which the real operator hunt can proceed. The register's split confidence is how it keeps the correct use and refuses the naive one — HIGH for the landlord, LOW for the tenant, and the search for the tenant handed off to the signals that can actually find him.

5. Acting on the Landlord, Hunting Within It

The register owes the analyst and the defender, and shared infrastructure gives each a two-part lesson matching its two-part confidence: act on the enabler, and hunt within it. For the analyst, the method is a discipline of separation. First, attribute the provider — cluster the traffic by registrant and ASN (the honeypot's 94% RDAP and 99.9% Cymru coverage make this reliable), identify the concentrations of hostility, and name the enabling landlords at the HIGH confidence the record supports. This attribution is sound, valuable, and largely immune to the trap, because it claims only what the record says: these addresses are registered to this provider. Second, and separately, hunt the operators within each provider cluster using the less-shareable signals — look for shared keys, bespoke C2s, and behavioral coherence among the IPs under one landlord, and attribute a single operator only where such a signal ties specific tenants together. Never let the provider cluster stand in for an operator cluster; the first is a starting point, the second is a conclusion, and the case's whole warning is against confusing them.

For the defender, the split maps onto two different actions, both worth taking. Against the enabler, the defender's move is blunt and effective: treat entire bulletproof ASNs and registrant ranges as hostile, and block or heavily scrutinize traffic from them wholesale. Because a bulletproof provider's address space is concentratedly malicious — the 78.5 average threat score is the evidence — blocking it at the provider level costs little legitimate traffic and stops many operators at once, exactly the chokepoint logic that makes enabler attribution valuable turned into a defensive control. Reputation and threat feeds that track bulletproof providers exist precisely so defenders can act at this level, and a defender who blocks the landlord does not need to attribute the tenant. Against the individual operator, the defender's move is the finer work — the per-host indicators (keys, C2s, hashes) from the earlier cases — but the provider-level block is the high-leverage first line, available immediately from the shared-infrastructure signal without any operator attribution at all.

The honest bound, one more time, is the one this case is built around and must not let its own enabler-attribution success obscure: do not let a correct, HIGH-confidence claim about the landlord become an incorrect, laundered claim about a tenant. The seduction of shared infrastructure is that the enabler attribution is so solid — the record really does name the provider — that its solidity tempts the analyst to extend the same confidence to "and therefore these IPs are one operator," which the same record does not support at all. The register's split confidence is the standing guard against exactly this laundering: the HIGH stays attached to the landlord, the LOW stays attached to the tenant, and the two never trade places. An operator hides in the crowd a bulletproof host gathers; the crowd is real and the host is nameable, but the crowd is not one man, and the register's refusal to call it one is the difference between attributing an enabler and libeling a tenant. Name the landlord loudly; hunt the tenant carefully; and keep the two confidences in separate hands.

6. The counter-narrative, steelmanned

The strongest objection to this case is that it concedes away its own subject — by admitting a shared bulletproof host attributes the operator only at LOW confidence, it removes infrastructure from the operator-attribution toolkit almost entirely, and a "linkage signal" that cannot link operators does not belong in a register about attributing operators.

The argument runs like this. The whole register is titled Follow the Operator, and each case is supposed to close on a signal that clinched an operator attribution. This case, the objection notes, explicitly refuses to do that: it says the shared registrant does not attribute the operator, assigns LOW confidence to the one-operator claim, and pivots to attributing the provider instead. But the provider is not the operator — it is a different target entirely, arguably the subject of a different series (Follow the Infrastructure, which the register itself floated as an alternative). So this case, the objection concludes, is either a bait-and-switch (promising operator attribution and delivering enabler attribution) or an admission that SHARED INFRASTRUCTURE is not really an operator-linkage signal at all, in which case it should be cut from the six-word vocabulary and the case replaced with a real operator thread.

The register accepts that the case pivots and argues that the pivot is the honest content, not an evasion of it. Yes — SHARED INFRASTRUCTURE is the weakest operator-linkage signal in the register, and the case says so at length, assigning LOW confidence to the one-operator claim on purpose. But three things make it belong. First, a register about attributing operators owes the reader an honest map of the signals that do NOT attribute operators well, because those are exactly the signals that produce false operator attributions in the wild — and shared infrastructure is the single most common source of over-attribution in real threat intelligence, the "200 IPs under one ASN, therefore one actor" error. A case that teaches the reader to distrust the seductive signal is doing operator-attribution work, by inoculation, even though its conclusion is a refusal. Second, the pivot to the enabler is not a change of subject but a correct reading of what the signal actually attributes: the same evidence that fails to identify the operator succeeds in identifying his landlord, and telling the reader which target a signal actually serves is precisely the register's job. Third, the case does keep the operator in view — it does not abandon operator attribution but relocates it, showing that shared infrastructure is where the operator hunt begins (narrow to the provider) and that the operator is selected within the cluster by the less-shareable signals of the other cases. So the case is not a bait-and-switch; it is the register being disciplined about a signal that most practitioners use undisciplined, delivering one solid attribution (the enabler), one honest non-attribution (the operator, at LOW), and one method (narrow-then-corroborate) that makes the weak signal useful without letting it lie. Cutting it would not strengthen the register; it would remove the case that guards the register's other clusters from the field's most common mistake.

7. Linkage Signal — SHARED INFRASTRUCTURE

Case 05 followed a thread that does not lead to one operator, and made that its subject. Some attackers cluster only because they rent from the same abuse-tolerant provider — a bulletproof host whose business is renting impunity and ignoring complaints. The honeypot surfaces the enabling landlords by their concentrations of hostility: TechTies Inc. at ~47 IPs and a 78.5 average threat score, IP Manager at ~33, grounded by RDAP coverage of 94% of the sensor's attackers and Cymru ASN data at 99.9%. The high threat concentration under one registrant is the fingerprint of the business model — a landlord who rents specifically to the tenants the honeypot exists to catch, behind records opaque enough to name the provider and hide the customer.

The linkage signal — the thread — is SHARED INFRASTRUCTURE, and it is the register's split-confidence signal: for the claim "these IPs are one operator," confidence is LOW, because a bulletproof host gathers many unrelated operators by design, so a shared landlord is if anything mild evidence of several hands, not one; for the claim "these IPs share one enabling provider," confidence is HIGH, because the registrant record says so directly. The register reports both and never collapses them, because the seduction of shared infrastructure is that the solid enabler attribution tempts the analyst to launder the same confidence onto a tenant the record does not support. Shared infrastructure narrows the field but does not select the hand: it is where an operator hunt begins, and the operator is selected within the cluster only by a less-shareable signal — a key, a bespoke C2 — from the other cases.

For the analyst, act on the enabler and hunt within it: attribute the provider at HIGH and name it, then corroborate within the provider cluster to select the operator at whatever the less-shareable signals support. For the defender, the enabler is a chokepoint — a bulletproof ASN's concentratedly-hostile space can be blocked wholesale, stopping many operators at once, without attributing any single one. The enabler is real, nameable, and accountable, and naming it has a multiplier no per-operator action can match; but the crowd it gathers is not one man, and the register's refusal to call it one is the line between attributing a landlord and libeling a tenant. The vectors do not lie, and neither does the registry: 47 addresses shared one landlord, and the landlord — not any tenant — is who the address named. We do not judge. We record. We let people judge — and we keep the two confidences in separate hands, loud about the enabler, careful about the operator, and clear about which is which.

Follow the Operator — Case 05. Linkage signal: SHARED INFRASTRUCTURE. Confidence: split — LOW for one-operator, HIGH for enabling-provider. High-threat registrant concentrations (TechTies Inc. ~47 IPs at avg threat 78.5; IP Manager ~33 IPs) are grounded by RDAP coverage of 94% of the honeypot's IPs and Cymru ASN data at 99.9%. A shared bulletproof host is the register's most shareable signal — it gathers many unrelated operators by design — so it is mild evidence of several hands rather than one, and the register assigns LOW to any single-operator claim while attributing the enabling provider at HIGH. The enabler is a real, nameable, accountable chokepoint whose attribution carries a multiplier per-operator action cannot; the operator is selected only by narrowing to the provider then corroborating with a less-shareable signal. The failure mode (a shared landlord laundered into a shared tenant — the field's most common over-attribution) is the case's explicit subject. Providers are named at the confidence the record supports; no individual operator is named, and presumption of innocence is preserved. Classification: TLP:WHITE. Include everything — the vectors do not lie, and they do not judge. The reader judges the landlord the address names, and the honest gap between the roof and the many hands beneath it.