The Cloud Recidivists: The Fleet That Scatters to Survive

The Recidivists — Part 5

Part 4 ended on a clean division of labour. The subnet ban is a surgical instrument for dedicated hosting: it fires only where three hostile addresses concentrate in one /24, which only ever happens inside a rented attack block, so it convicts whole ranges without touching a bystander. It was, read correctly, the machine at its most elegant.

This letter is about everything that instrument cannot see — and it is the larger half of the problem. Go back to the tier-3 roster of Part 2, the twenty-three hosts that earned a one-year individual ban, and sort them by where they live. Thirteen of the twenty-three are on hyperscale cloud — eight on Microsoft Azure, five on DigitalOcean. They are the plurality of the roster. And not one of them could ever trip the subnet mechanism that so cleanly handled the dedicated fleets. The most-punished single category of recidivist on this perimeter is precisely the category the block-ban is blind to.

That is not an accident of this dataset. It is why the recidivists are on the cloud in the first place. Hyperscale is not merely a convenient place to attack from; it is structurally engineered, by three independent properties, to protect the persistent attacker from exactly the defences that work everywhere else. This is the anatomy of that fortress, and of the one weapon that still reaches inside it.

Thirteen recidivists, thirteen blocks

Here are the cloud hosts from the tier-3 roster, each with the /24 it occupies.

Read the third column. Thirteen hosts, thirteen different /24 blocks — no two share one. The DigitalOcean five span four distinct /16s (138.68, 207.154, 138.197, 164.90); the Azure eight are scattered across 20.x, 4.x, and 52.x. There is no concentration anywhere. Every one of these hosts is the sole flagged address in its block, and that is the first and most important fact about cloud recidivism: on hyperscale, the attacker is always alone in the /24, because the other 255 addresses belong to unrelated strangers.

The first wall: one tenant, one address, no block to ban

The subnet mechanism of Part 4 requires three hostile IPs in one /24. On a dedicated hosting block that is trivial — one operator rents a contiguous run of the range, and three of their boxes light up together. On hyperscale it is structurally impossible for a single operator to arrange. Azure and DigitalOcean slice each /24 across hundreds of unrelated tenants; a customer is handed one address out of it, drawn from a vast pool, with no control over adjacency. To place three attacking IPs in one cloud /24, an operator would need the provider to happen to assign them three neighbouring addresses by pure chance out of millions — and even then, a subnet ban would be indefensible, because the other 253 tenants are genuinely innocent.

So the block-ban is off the table entirely. Not by policy — the escalator would fire it if the condition were met — but because the condition cannot be met on shared infrastructure by one actor, and the query in the ledger confirms it: across the escalator's whole history, not one Azure or DigitalOcean /24 has ever reached the subnet threshold. The single most effective tool against dedicated fleets does not, and cannot, exist in the cloud's domain. That absence is the first brick of the fortress.

The scattered fleet: a coordination the block-ban can never see

Now the sharpest consequence, and it is the Jira fleet. Four of the five DigitalOcean recidivists — 207.154.197.113, 138.197.191.87, 164.90.208.56, 207.154.212.47 — do the identical thing: each fires crowdsecurity/jira_cve-2021-26086, an Atlassian Jira template-injection exploit, against the perimeter, across the same months. By behaviour they are unmistakably one operation — a single operator's four-host fleet running one CVE.

On dedicated hosting, a four-host fleet is a subnet ban waiting to happen: four boxes, one /24, threshold tripped, block gone. This fleet earns none of that, because its four hosts sit in four different /24s across two different /16s. The coordination that would betray them instantly on a rented block is completely invisible to the subnet mechanism on the cloud, because there is no block to look at. The only thing that ties these four together is that they run the same exploit — a correlation of method, not of address space. Absent an analyst noticing four separate DigitalOcean droplets firing the identical years-old Jira CVE, the fleet reads as four unrelated individual scanners.

This is the cloud's structural gift to the fleet operator, stated exactly: hyperscale lets you run a coordinated fleet with none of the coordination being visible in the address space. Rent four droplets, get four scattered addresses in four unrelated /24s, and the block-detection that surgically dismantles a NextGenWebs /22 sees nothing at all. The fleet is real; its footprint is atomised on purpose, or by the simple default of how cloud hands out addresses. Either way, only per-host method-correlation catches it — and only a defender actually looking.

Two archetypes in the shared range

The thirteen do not attack alike, and the split is worth drawing because it maps the same two-ended spectrum the whole series has traced — now inside the cloud's protected space.

At one end is 138.68.86.32, the adaptive stayer. Six bans across a hundred and twenty-one days, and — uniquely on the roster — a changing method: the escalator's record shows it evolving from generic http-probing to a targeted mix of credential_harvest, api_enum, and admin_hunt. This is not a scanner spraying one payload; it is an operator who keeps returning to this perimeter, learns from what the last visit found, and comes back with a sharper tool. It is the only cloud recidivist still active as of this writing — every other host on the table went dark months ago. The adaptive stayer treats the target as a project, and the cloud's disposability is irrelevant to it precisely because it has no intention of leaving: it wants this door, and it is willing to keep knocking on the same address for four months to get it.

At the other end is the sweep — the Jira fleet and the Azure probers, eight-to-twelve hosts running fixed, generic payloads (jira_cve-2021-26086, http-probing, http-wordpress-scan) against not this perimeter but the entire internet, of which this apartment is one address in a list of millions. These operators never adapt because they never look; the target is undifferentiated, the payload is constant, and the only reason they reach a year-ban is the sheer mechanical repetition of re-covering the same address space week after week. Where the stayer is a campaign, the sweep is a weather system — indifferent, vast, and caught here only because it happens to blow across this door often enough to climb the ladder.

Both archetypes get the same three walls of cloud protection, and both are beaten by the same one ladder. But they fail it differently: the stayer because it wants this specific target enough to keep paying the rising cost of return, the sweep because it is too automated to notice it has been banned at all. The ladder does not care which; a year is a year. But the distinction matters for a defender reading the logs, because the adaptive stayer is the one worth watching after the ban — it is the only one of the thirteen that might come back on a new address specifically to finish what it started.

The second wall: the reputation discount

Part 3 documented the cloud's second structural protection, and it belongs here in full because it compounds the first. When the tier-3 roster was cross-checked against AbuseIPDB, the Azure hosts produced a contradiction: reported thousands of times each — 20.220.232.240 with 6,859 reports, 52.178.176.146 with 6,704, 20.151.11.236 with 5,578 — and yet scoring only 19, 25, 33 on AbuseIPDB's confidence scale, several of them reported as recently as today. These are not decayed scores. They are structurally suppressed ones.

The reason is the same shared-range property that defeats the subnet ban. AbuseIPDB down-weights complaints against large cloud allocations, because those ranges are enormous, recycled between tenants, and full of legitimate traffic; a model that scored every Azure complaint at face value would condemn half the cloud. So it discounts them — and the practical effect is that a genuinely hostile Azure droplet, firing WordPress scans until it earned a one-year ban here, presents to any casual reputation check as a medium-confidence, probably-fine address in the twenties. The six thousand reports are in the record; the headline number buries them.

So the cloud recidivist gets a second layer of cover for free: not only can it not be block-banned, it also cannot be reliably scored. A defender who leans on reputation feeds — as most do — sees a low number and waves the host through. The two walls reinforce: the mechanism that would ban the range structurally cannot fire, and the feed that would flag the host structurally under-rates it. Hyperscale is, from the recidivist's side of the glass, the address space where the two most common defences both fail by design.

The third wall — and the paradox it creates

The cloud's third gift is the most obvious and the most interesting: disposability. A droplet costs cents. If an address gets banned, the rational move is to destroy it and spin up a fresh one — a new IP, a clean reputation, a reset of the per-host ladder to zero. Cloud makes the attacker's own address fungible in a way a rented dedicated block never is; the whole economic logic of hyperscale abuse is that individual IPs are cheap and interchangeable.

Which makes the actual behaviour of these thirteen hosts a genuine puzzle. They do not rotate. They sit on the same address across months and multiple bans. 138.68.86.32 was banned six times over a hundred and twenty-one days and is still on the same IP today. The Jira fleet ran its four fixed addresses from March into May. Every host on the table reached a one-year ban by the simple, avoidable method of coming back to an address it already knew was banned, when abandoning it would have cost almost nothing. The disposability that should have made these attackers untrackable is a card they conspicuously decline to play.

Why? Because rotation is cheap in dollars but not free in effort. A fresh droplet is a fresh droplet — un-provisioned, un-tooled, its prior reconnaissance of the target lost, its established foothold (if any) gone. For an operator running an automated, fire-and-forget scan against millions of targets, the per-target payoff of rotating is negative: it is cheaper to keep firing from the burned address at the small fraction of targets that haven't closed the door than to re-tool for each ban. The cloud's disposability is real, but the operator's calculus is that staying is cheaper than moving — right up until the target makes staying expensive. And that is the opening the last weapon exploits.

Burned bright, then dark

There is a temporal signature to cloud recidivism that the dedicated blocks of Part 4 do not share, and it is visible in the first-seen and last-seen dates of the thirteen. Almost all of them appeared in a tight window — the first days of March 2026 — and almost all of them went silent by April or May. 20.151.11.236: first seen 10 March, last seen 29 March, gone. 52.178.176.146: 10 March to 4 April. 20.48.232.178: active a bare eleven days. The Jira fleet ran from March into May and stopped. Of the thirteen, exactly one — the adaptive stayer — is still firing in July.

This is the disposability paradox resolved in the timeline. These operators did not rotate address-by-address, but they did eventually abandon — not by swapping IPs mid-campaign, but by ending the campaign entirely and, presumably, moving the whole operation elsewhere. A cloud recidivist's life against a single perimeter is short and hot: a few weeks of intense, repeated probing that drives the address up the ladder to a year-ban, and then nothing, because the operator's automated sweep has rolled on to fresh target lists and simply never points back at this door. The year-ban that the ladder imposed is, for most of them, a sentence served on an address its owner has already walked away from — which is exactly the score-zero-with-thousands-of-reports pattern Part 3 found from the outside. 52.169.5.4, an Azure host on this table, was one of those: heavily reported in spring, its AbuseIPDB score decayed to zero by summer, and still sitting behind this perimeter's year-ban long after it stopped attacking anyone.

The lesson compounds the one about laziness. The cloud recidivist is not only too indifferent to rotate its address; it is, in aggregate, a transient — burning through a perimeter in a few weeks and gone, its persistence real but brief. The ladder catches it precisely in that hot window, when the repeated returns stack up faster than the campaign ends. A perimeter that only banned on a long, slow-burn threshold would miss these entirely; it is the ladder's fast early tiers — three hours, then a week — that convert a three-week cloud campaign into an accumulating record before the operator loses interest and drifts away.

The one wall that holds: the per-host ladder

Strip away the two defences that fail on the cloud — no block-ban, no reliable reputation score — and one instrument remains, the per-host escalation ladder of Part 1. It is, in the cloud's domain, the entire defence. And it is well-matched to it in a way that is easy to miss.

Against a dedicated fleet, the per-host ladder is the slow option — chasing a NextGenWebs /22 one address at a time across twenty-two exhausting ladders is exactly the labour the subnet ban was invented to avoid. That same slowness, that same one-address-at-a-time precision, is a virtue against the cloud. Because the cloud attacker is always alone in a shared /24, the only fair and accurate unit of judgement is the single address — ban the hostile droplet, touch none of its innocent neighbours. What is a liability against a rented block is the correct tool against a shared one. The ladder and the subnet ban are not two attempts at the same job; they are two instruments each precise in exactly the domain where the other would be reckless.

And the ladder works here, on its own terms. Every one of the thirteen cloud recidivists reached tier 3 — a full year behind the wall — by the per-host mechanism alone, no block-ban required. The escalation is what turns the operator's "staying is cheaper than moving" calculus against them: the first ban is three hours, trivially outwaited; but the ladder's whole design is that persistence raises the cost of staying, three hours to a week to a month to a year, until the address the operator declined to abandon becomes a dead weight — a burned, permanently-blocked host still costing its cents while reaching nothing. The ladder cannot stop the attacker from renting a new droplet. What it can do, and does, is make the specific choice these operators keep making — to stay on a known-banned address — progressively, finally, unaffordable.

The honest limit

Intellectual honesty requires naming what the ladder cannot do, because it is the mirror of Part 4's caveat. The subnet ban's weakness was that it might, someday, catch an innocent re-leased tenant. The per-host ladder's weakness is the opposite: it cannot pre-empt a guilty new one. An operator who actually used the cloud's disposability — burn the banned droplet, provision a fresh IP, resume — would reset the ladder to zero every time and never accumulate toward a year-ban. Against a disciplined rotator, the per-host mechanism is a treadmill.

The reason it works anyway is not that the defence is complete. It is that these particular attackers are not disciplined rotators. The thirteen cloud recidivists earned their year-bans by declining, over and over, to do the one thing that would have defeated the only weapon that reaches them. The ladder does not beat the cloud's structure; it beats the operator's laziness within that structure — and against the volume of automated, indifferent, fire-and-forget scanning that fills this roster, laziness is what most of them have. A more careful adversary would slip it. Most of the ones who reach tier 3 are, precisely, the ones not careful enough to rotate — which is another way of saying the ladder catches exactly the recidivists it is named for.

Two domains, one design

Set Parts 4 and 5 together and the whole defensive architecture resolves into a single coherent shape, drawn not by configuration but by the physics of how attackers hold address space.

On dedicated and bulletproof hosting, the operator rents the block, three hostiles concentrate in a /24, and the subnet ban convicts the range whole — cheap, surgical, no collateral, because the block is the operator. On hyperscale cloud, the operator is one tenant among hundreds, scattered one-address-per-block, reputation-discounted and disposable — and the per-host ladder judges each hostile droplet alone, the only fair unit in a shared range, escalating until the attacker's refusal to move becomes its own punishment. Neither instrument could survive being pointed at the other's domain: a subnet ban on Azure would sever the innocent; a per-host chase of a rented /22 would never end. The boundary between them is the boundary between owning address space and renting a slice of it — and the escalator, without ever being told which is which, applies each weapon exactly where it is just.

The recidivists chose the cloud because two of the three walls protect them there. What this series has been, end to end, is the record of the one wall that still holds — and the proof that against an adversary too indifferent to rotate, one well-built wall, patiently raised, is enough.