Follow the Operator · 15 — The Cloud Tenant: Hiding in the Legitimate

Follow the Operator — Case 15. 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 register has already treated one infrastructure case as a warning and one as a strength: the bulletproof landlord, whose whole address space is hostile and can be blocked wholesale, and the owned C2, which is the operator's own and attributes him squarely. This case is a third kind of infrastructure, and it is the trickiest, because it is the exact inverse of the bulletproof host: the legitimate mega-cloud. When the honeypot lists the autonomous systems its attackers come from, the top of the list is not obscure bulletproof providers — it is Google, DigitalOcean, Microsoft, OVH, the mainstream cloud giants. Google's AS396982 alone accounts for around 83 of the sensor's attacking IPs; DigitalOcean around 71; Microsoft around 66; OVH around 50. These are not criminal networks. They are the legitimate backbone of the internet, and the operator is hiding inside them precisely because they are legitimate.

The bulletproof host and the legitimate cloud are mirror images, and understanding the mirror is understanding this case. The bulletproof host's whole ASN is hostile, so it is safe to block wholesale — a defender loses nothing legitimate by refusing all its traffic. The legitimate cloud's ASN is overwhelmingly benign, carrying a thin criminal layer atop a vast base of real, innocent tenants — so it cannot be blocked wholesale, because blocking Google or Microsoft's cloud would break access to a huge slice of the legitimate internet that everyone depends on. The bulletproof host is hostile and blockable; the legitimate cloud is benign and un-blockable, and the operator chooses between them accordingly. The one who wants impunity from takedown rents bulletproof; the one who wants un-blockability and a clean reputation rents Google. This case is about the second choice, and why it is so much harder to attribute than the first.

Because the legitimate cloud gives the operator two things the bulletproof host cannot. First, un-blockability: his traffic comes from an ASN no one dares blanket-block, so it reaches targets that would refuse a bulletproof host's traffic outright. Second, and subtler, a clean reputation: the legitimate cloud's IPs carry the provider's good name, so traffic from them is trusted, allowlisted, and waved through by reputation systems that would flag a known-bad host. The operator rents Microsoft egress and inherits Microsoft's reputation, laundering his hostile traffic through the provider's clean address space. He is not hiding in a dark corner of the internet; he is hiding in the brightest, most trusted part of it, wearing the reputation of the giant whose infrastructure he rented by the hour. Linkage signal: SHARED INFRASTRUCTURE — but the legitimate kind, which attributes the operator not at all and hides him in the crowd of the innocent.

1. The Tenant Behind the Instance

Begin with where the operator's identity actually is, because the legitimate cloud relocates it to a place the external analyst cannot reach. When an operator uses a bulletproof host, the host is complicit and the whole ASN is his kind of people, so attribution to the provider says something (it names a criminal enabler). When an operator uses Google Cloud, the provider is not complicit, the ASN is full of innocent tenants, and attribution to the provider says almost nothing — "the operator used Google" is true of the operator and of millions of legitimate businesses. So the shared-cloud-provider edge, which was weakly meaningful for the bulletproof host (it named an enabler), is meaningless for the legitimate cloud (it names a utility everyone uses). The operator's identity is not at the provider level at all; it is one level deeper, at the tenancy.

Each disposable cloud instance the operator spins up is a tenancy: an account, a project, a billing identity, a payment method, an authentication history — a rich identity record tied to that instance. And that record exists; it is real and detailed. But it is held by the provider, visible to the provider, and invisible to the external analyst. The honeypot sees a connection from a Google Cloud IP; it does not see which Google Cloud account rented that IP, what project it belongs to, what card paid for it, what email registered it — all of which Google sees and Google keeps. So the operator's true identity, in the cloud case, is not hidden by obscurity (as with a scattered fleet) or by anonymization (as with Tor); it is hidden by the provider, sitting in the provider's account database, one subpoena or one abuse-report away from the analyst but entirely out of the analyst's direct reach.

This relocation of identity to the tenancy is what makes the legitimate cloud a distinct attribution problem. Against the bulletproof host, the analyst could attribute the enabler and pressure the whole ASN. Against the legitimate cloud, the analyst can attribute neither the operator (whose identity is behind the provider) nor the provider (who is an innocent utility) — the external attribution simply collapses to "someone used a legitimate cloud," which is no attribution at all. The identity that would resolve it exists, in full, but it exists on the other side of the provider's wall, and the whole difficulty of the cloud case is that the analyst can see the crime and not the tenant, while the provider can see the tenant and often does not see the crime. Attribution against cloud abuse is, structurally, a problem of getting the two halves — the analyst's view of the crime and the provider's view of the tenant — to meet.

2. Disposability and the Broken Address Thread

Now the second way the legitimate cloud defeats attribution, which compounds the first: disposability. Against a stable fleet, address-level linkage works — the reused-key operator's 124 IPs persisted long enough to be observed, clustered, and tied together. The cloud operator's IPs do not persist. He spins up an instance, uses it, tears it down, and spins up another, so any given IP is his for hours or days and then returns to the provider's pool to be reassigned to an innocent tenant. This churn breaks the address thread in a specific way: the IP the honeypot saw attacking is, by the time the analyst looks, no longer the operator's — it is someone else's, or no one's, a reassigned address that carries none of the operator's identity forward. The cloud gives the operator disposability the bulletproof host, with its more stable allocations, does not.

Disposability also poisons the address as evidence, which is a subtle harm worth naming. Because a cloud IP is reassigned, attributing anything to it risks attributing to whoever holds it next — the innocent tenant who rented the same address after the operator released it. An analyst who blocklists a cloud IP because it attacked yesterday may be blocking an innocent business today, because the address changed hands. This is the cloud version of the stolen-identity problem: the address is a shared, rotating resource, so tying it to an operator is tying a temporary lease to a permanent identity, and the lease expires. The honeypot's Google and DigitalOcean IPs are not stable identifiers of anyone; they are lease records, valid only for the window in which the operator held them, and worthless — even harmful — as identifiers afterward.

So the address, already weak against the scattered operator and severed against the anonymized one, is doubly defeated against the cloud operator: it points at a provider that means nothing and it expires before it can be used. This is why the case sits where it does in the register — it is the final degradation of address-based attribution, the point at which the address is not merely misleading (geography) or absent (Tor) but actively transient, a lease rather than an identity. And it forces the same conclusion the anonymization case reached, by a different road: abandon the address, and attribute on what survives the churn. The cloud operator's instances are disposable, but the operator is not, and the things he carries from instance to instance — his key, his C2, his routine — are the only threads that survive when the addresses are leases and the provider is a utility.

3. The Two Roads That Remain

Now the constructive part, because the cloud case is not hopeless — it has exactly two attribution roads, and naming them is the case's method. The first road is the provider's cooperation. The operator's true identity exists, in full, in the provider's account records — the billing, the authentication, the project history — and the provider can act on it: suspend the account, preserve the records, respond to legal process. So attribution against a cloud operator often runs not through the analyst's own analysis but through the provider's abuse process: report the specific instance and the specific abuse, and the provider, seeing which tenant that instance belongs to, can suspend the account and (under legal process) reveal the identity. This is a fundamentally different attribution mechanism than the rest of the register — it is not the analyst reading invariants but the analyst persuading the one party who can see behind the wall to look. The provider is the keeper of the identity, and the first road is getting the keeper to open the door.

The second road is the register's own: the operator's reused artifacts, surviving across his disposable instances. The cloud gives the operator disposable addresses, but it does not give him a new key, a new C2, a new routine, a new handle for each instance — those he reuses, because reusing them is the same convenience that has betrayed operators throughout the register. So even as his IPs churn, the reused-key operator on the cloud offers the same key from each disposable instance; the malware operator beacons each instance to the same C2; the scripted operator runs the same routine on each. These invariants survive the churn precisely because they are properties of the operator, not the instance, and they re-link the disposable IPs that the address thread cannot. The cloud operator who reuses a key is attributed exactly as any reused-key operator is — his disposability defeats the address but not the credential, and the register follows the credential across the churn. This is the anonymization case's lesson repeated: the operator hid his addresses (here by disposability rather than Tor) and kept his reusable artifacts, and the artifacts are the thread.

The two roads are complementary, and the case's practical teaching is to use both. The reused-artifact road (the register's own) links the operator's disposable instances into one cluster and attributes them to one hand, at whatever confidence the reused artifact supports — often HIGH, if the artifact is a bespoke key. But that cluster is still nameless, because the identity is behind the provider. The provider-cooperation road turns the nameless cluster into a named tenant — but only the provider can walk it, and only if persuaded by a well-evidenced abuse report. So the ideal attribution against a cloud operator combines them: the analyst uses reused artifacts to prove the disposable instances are one operator (making the abuse report specific and credible), and the provider uses its account records to name that operator (or suspend him). The analyst's half is the crime and the cluster; the provider's half is the tenant and the name; and the cloud operator is fully attributed only where the two halves meet.

4. SHARED INFRASTRUCTURE — The Legitimate Kind

The linkage signal is SHARED INFRASTRUCTURE, for the third time, and the register uses the same words a third time deliberately, because the legitimate cloud completes the lesson the bulletproof host and the owned C2 began: infrastructure attributes the operator only in proportion to how exclusively he controls it and how hostile the surrounding space is. The owned C2 (exclusive control, the operator's own) attributed him at MEDIUM-HIGH. The bulletproof host (shared control, hostile space) attributed the enabler at HIGH and the operator at LOW. The legitimate cloud (shared control, benign space) attributes neither the operator nor a criminal enabler — it attributes a utility, which is to say nothing, and is the weakest infrastructure signal of the three for the operator claim. The three infrastructure cases together are a gradient: the more exclusive and hostile the infrastructure, the more it attributes; the more shared and benign, the less. The legitimate cloud is the shared-and-benign extreme, and it attributes the operator at the register's floor.

But the case's real contribution is the defensive inversion, which is the mirror of the bulletproof host's chokepoint. The bulletproof host was a defensive gift: block the whole ASN, stop many operators at once, because the space is hostile. The legitimate cloud is a defensive trap: you cannot block the ASN, because the space is benign, so the wholesale block that worked against the bulletproof host would, against the legitimate cloud, cut off the innocent majority to reach the criminal minority — a self-inflicted denial of service. This is the operator's whole strategy made explicit: he has positioned himself where the defender's strongest tool (blocking) cannot be used without unacceptable collateral damage, so the defender is forced onto the slower, weaker tool (abuse-reporting) that depends on a third party's responsiveness. The operator did not defeat the defender's tools; he chose ground where the best tool self-destructs.

And this reframes the register's relationship to the provider, from the bulletproof case's adversary to the cloud case's reluctant ally. The bulletproof host was an enabler by business model — its complicity was the point, and the register named it as culpable. The legitimate cloud is an unwilling host — it does not want the operator's abuse, it loses reputation and incurs cost from it, and it can, increasingly does, act against it. So the register's posture toward the legitimate cloud is not accusation but pressure-toward-responsibility: name the abuse pattern, report the instances, and push the provider toward faster, more automated tenant-level enforcement, because the provider is the only party with the leverage that scales against cloud abuse — it can see every tenant and suspend any account, which no external analyst or defender can. The bulletproof host had to be blocked around; the legitimate cloud has to be worked with, and the difference is the difference between an enemy and an unwilling gatekeeper who holds the key the analyst needs.

5. Working the Provider (and the Reused Thread)

The register owes the analyst and the defender, and the cloud case gives both a two-part method matching its two roads. For the analyst, the method is: attribute the cluster on reused artifacts, then take the cluster to the provider. Do not waste effort on the cloud IP itself — it is a lease, expired and reassigned, attributing a utility and possibly an innocent successor. Instead, find what the operator carried across his disposable instances: the reused key offered from each, the shared C2 each beaconed to, the idiosyncratic routine each ran, the handle each presented. Cluster the instances on those surviving invariants (at the confidence the artifact supports), and use that cluster to build a specific, well-evidenced abuse report — "these N instances, tied by this bespoke key, are one operator abusing your service" — which is far more actionable to the provider than a bare IP complaint, because it shows the provider a pattern its own account records can then resolve to a tenant. The analyst's job is to make the crime specific enough that the provider's view of the tenant becomes worth invoking.

For the defender, the cloud case is a hard lesson in what not to do and a clear one in what to do instead. What not to do: block the cloud ASN. It is tempting — the attacks come from Google's cloud, so block Google's cloud — but it is self-harm, cutting off the vast legitimate services that share the ASN, and the register warns against it as firmly as it warned for blocking the bulletproof ASN. What to do instead: block the specific instance (the current IP, for as long as it is the operator's), report it to the provider's abuse process, and rely on provider enforcement for the durable fix, while using the operator's reused artifacts (his C2, his key) as the stable indicators to block regardless of which cloud IP he moves to next. The cloud operator's disposable addresses are un-blockable at the ASN and pointless at the IP; his reused artifacts are the durable thing to block, exactly as with the anonymized operator. The defense against cloud abuse is artifact-based blocking plus provider abuse-reporting, never ASN blocking.

The honest close is the structural frustration the cloud case embodies and the register must name: attribution against cloud abuse is slower, weaker, and more dependent on others than any other case, and that is by the operator's design, not the register's failure. The operator chose the legitimate cloud precisely to impose this friction — to make the address a lease, the provider a utility, and the defender dependent on an abuse process that moves at the provider's speed rather than the analyst's. The register's honest position is that this friction is real and largely unavoidable from the outside: the fully-external analyst can cluster the operator's instances by reused artifacts but cannot name him, because the name is behind the provider, and only the provider's cooperation or legal process crosses that wall. So the register attributes the cloud operator's cluster at whatever the reused artifact supports, names the abuse pattern to pressure the provider, and states plainly that the last step — from cluster to tenant to name — belongs to the provider, not the analyst. The vectors do not lie, but on the legitimate cloud they arrive wearing the provider's clean reputation and a lease that expires, and behind them the tenant sits in a record only the provider can open. We do not judge. We record. We let people judge — and we take the reused thread as far as the provider's wall, and ask the provider, who alone can see the tenant, to open it.

6. The counter-narrative, steelmanned

The strongest objection to this case is that it lets the legitimate clouds off far too easily — by casting them as "unwilling hosts" and "reluctant allies," the register excuses providers who profit from abuse they could prevent, and the real story is not the clever operator but the negligent giant whose lax signup, absent verification, and slow abuse response make the whole cloud-abuse pattern possible.

The argument runs like this. The legitimate clouds, the objection notes, are not passive victims of abuse; they are enablers-for-profit who have chosen not to prevent it. They allow anonymous or stolen-card signup, do not verify identity, do not detect obvious abuse patterns their own telemetry would reveal, and respond to abuse reports slowly if at all, because meaningful anti-abuse enforcement costs money and friction that would reduce signups. The operator's whole strategy, the objection continues, works only because the provider permits it — a cloud that verified identity, throttled new accounts, and acted on abuse within minutes would make the disposable-instance game unplayable. So the register's framing (clever operator, unwilling provider) inverts the moral weight: the provider is not an ally the analyst persuades but a culpable party the analyst should be naming, and calling Google or Microsoft a "reluctant gatekeeper" launders the negligence that is the actual root cause.

The register accepts much of the indictment and disputes the equivalence it draws to the bulletproof host. Yes — the legitimate clouds could prevent much cloud abuse with stricter signup, identity verification, abuse detection, and faster response, and their failure to do so is a real, profit-driven negligence the register does not excuse; the case's own closing call to "pressure the provider toward faster tenant-level enforcement" is an accusation of current inadequacy, not a compliment. The disagreement is only about whether that negligence makes the legitimate cloud morally equivalent to the bulletproof host, and the register holds that it does not, for a reason that matters to the attribution and the defense. The bulletproof host's business model is the abuse — it markets impunity, its whole customer base is criminal, and blocking its entire ASN harms no one legitimate, so it can be treated as wholly hostile. The legitimate cloud's business model is legitimate hosting — its abuse is a thin parasitic layer on a vast innocent base, and treating it as wholly hostile (blocking its ASN) would harm the innocent majority, which is why the defensive posture must differ regardless of how negligent the provider is. So the register's "unwilling host" framing is not moral absolution; it is a description of the defensive constraint: you cannot block the legitimate cloud the way you block the bulletproof host, not because the cloud is innocent but because its ASN is mostly innocent tenants. And the negligence the objection names is precisely why the register's closing move is pressure-toward-responsibility rather than mere reporting — the register agrees the provider should do far more, names that as the leverage that scales, and treats the provider as culpable-for-inaction while still, unavoidably, needing its cooperation to reach the tenant, because the tenant record is on its side of the wall no matter how negligent it has been. The objection sharpens the case's own call for provider accountability; it does not overturn the structural fact that a mostly-benign ASN cannot be defended against the way a wholly-hostile one can.

7. Linkage Signal — SHARED INFRASTRUCTURE

Case 15 was the inverse of the bulletproof landlord: the legitimate mega-cloud. The honeypot's top attacking ASNs are mainstream clouds — Google's AS396982 (~83 IPs), DigitalOcean (~71), Microsoft (~66), OVH (~50) — mostly benign with a thin persistent criminal layer. This is the anti-bulletproof: un-blockable, because blocking the ASN would break a huge slice of the legitimate internet, and clean in reputation, so its traffic is trusted. The operator hides in the legitimate precisely because it cannot be blocked and its good name launders his traffic — not in a dark corner of the internet but in its brightest, most trusted part, wearing the reputation of the giant he rented by the hour.

The linkage signal — the third and weakest of the register's infrastructure readings — is SHARED INFRASTRUCTURE, at LOW for the operator, because a shared legitimate cloud ties millions of innocent tenants and attributes nothing about the hand. The operator's real identity is relocated to the tenancy — the account, project, and billing record behind each disposable instance — which the provider can see and the external analyst cannot; and disposability breaks the address thread, because a cloud IP is a lease that expires and is reassigned to an innocent successor. Two roads remain: the provider's cooperation (an abuse report the provider resolves to a tenant, the only party who can see behind the wall) and the operator's own reused artifacts (a key, a C2, a routine) that survive the churn and re-link his disposable instances at whatever confidence the artifact supports. The ideal attribution combines them — the analyst proves the cluster by reused artifacts, the provider names the tenant from its records — because the cloud operator is fully attributed only where the analyst's view of the crime meets the provider's view of the tenant.

The defensive inversion is the case's core: the bulletproof host was a chokepoint to block wholesale; the legitimate cloud is a trap where wholesale blocking self-harms, so defense runs through artifact-based blocking (the reused C2/key, durable across the churn) plus abuse-reporting to the provider, never ASN blocking. The provider is not an enemy to block around but a reluctant, and genuinely negligent, gatekeeper to pressure toward faster tenant-level enforcement — the only leverage that scales, because it alone can see every tenant and suspend any account. The register attributes the cluster as far as the reused thread reaches, names the abuse pattern to press the provider, and states plainly that the last step from cluster to name belongs to the provider, not the analyst. The vectors do not lie, but on the legitimate cloud they wear a clean reputation and a lease that expires, and the tenant sits in a record only the provider can open. We do not judge. We record. We let people judge — and we take the reused thread to the provider's wall, and ask the one who can see the tenant to open it.

Follow the Operator — Case 15. Linkage signal: SHARED INFRASTRUCTURE (legitimate cloud). Confidence: LOW for the operator externally — the anti-bulletproof. The honeypot's top attacking ASNs are legitimate mega-clouds (Google AS396982 ~83 IPs, DigitalOcean ~71, Microsoft ~66, OVH ~50): mostly benign, un-blockable (blocking the ASN breaks the legitimate internet), and clean-reputation (traffic trusted), which is exactly why operators abuse them — to be un-blockable and to launder traffic through the provider's good name. The operator's identity is relocated to the tenancy (account/project/billing) visible to the provider and invisible to the analyst; disposability makes each cloud IP a lease that expires and reassigns to an innocent successor, so the shared-cloud edge attributes only a utility and the IP attributes nothing durable. Two attribution roads: provider cooperation (abuse report resolved to a tenant — only the provider can see behind the wall) and the operator's own reused artifacts (key/C2/routine surviving the churn, re-linking his disposable instances at the artifact's confidence). Defense is artifact-based blocking plus abuse-reporting, NEVER ASN blocking (which self-harms the innocent majority). Completes the infrastructure gradient (owned C2 MEDIUM-HIGH > bulletproof host enabler-HIGH/operator-LOW > legitimate cloud operator-LOW). The steelmanned objection (the clouds are culpable enablers, not victims) is accepted as to negligence and disputed as to equivalence with the wholly-hostile bulletproof host. No individual named. Classification: TLP:WHITE. Include everything — the vectors do not lie, but on the legitimate cloud they wear the provider's clean name and a lease that expires; we take the reused thread to the provider's wall and ask the one who can see the tenant to open it.