The Subnet Verdict: When One Block Answers for All of It

The Recidivists — Part 4

Everything in this series so far has judged hosts one at a time. The ladder of Part 1 escalates an individual IP; the rap sheets of Part 2 are per-address; the corroboration of Part 3 checked each host against the crowd on its own merits. This letter is about the one place in the machine that abandons that individualism and does something that ought to make any careful analyst uneasy: it convicts two hundred and fifty-six addresses on the evidence of three.

That is the subnet ban. When three or more distinct addresses inside a single /24 — a block of 256 consecutive IPs — have each independently earned a tier-1 ban, the escalator stops banning them one by one and bans the whole block. Every address in the range, the guilty and the as-yet-silent alike, goes behind the same wall. It is collective punishment encoded in a systemd timer, and the honest question is the one a defender should never flinch from: is that just, or is it just convenient?

The answer, from the data, is more interesting than either a comfortable yes or a righteous no. The subnet verdict is a blunt instrument — and the thing that makes it defensible is not restraint in how it is applied, but a structural property of which blocks can ever trigger it in the first place. The trigger turns out to be its own filter.

The mechanism, stated plainly

The rule is deliberately simple. The escalator maintains, per /24, a rolling set of the addresses inside it that have been banned. The moment that set reaches three, the subnet itself is banned, and thereafter the subnet climbs the same tier ladder as an individual host: three IPs holds it at tier 1, and as more members of the block reoffend, the subnet escalates to tier 2 (one month) and tier 3 (one year), exactly as a single recidivist would.

There is no subtlety in the blast radius. A /24 ban is a single firewall entry — x.y.z.0/24 — that rejects all 256 addresses. The escalator does not check which of those addresses were actually hostile; it does not spare the 253 it never saw. Three convictions, and the block is condemned entire.

[DOCUMENTED] Across the escalator's entire operating history, that threshold has fired ten times. Ten /24 blocks have been banned. Between them they contain, at last count, fifty-nine distinct addresses the escalator actually observed attacking — and, by the arithmetic of the /24, roughly 2,560 addresses placed behind a block on the strength of those fifty-nine. On its face, that ratio is exactly the tyranny the opening paragraph warned about: forty-odd-to-one collateral, punishment vastly exceeding the observed crime.

Then you look at which ten blocks, and the tyranny evaporates.

The ten blocks — and the one thing they all are

Here is every subnet the escalator has ever banned, with the provider that owns it (resolved via Team Cymru), the number of attacking addresses actually seen inside it, and what those addresses were doing.

The timing is its own small story. The bans are not evenly spread: Bucklog fell first and alone in March; then a dense cluster arrived in early May — the entire NextGenWebs /22 and the Advin 208.84.100 block within a single week — followed by a second wave in the last days of July as 31.56.58.0/24 (Zkillu) and 130.12.182.0/24 (VPS Dedicated) tripped the wire on the same day. Subnet bans arrive in bursts because rented attack fleets arrive in bursts: an operator provisions a block, runs a campaign for weeks, and moves on, so the concentration that trips the threshold appears and vanishes with the campaign. The ledger of banned blocks is, read by date, a calendar of when hosting-based scanning operations were most active against this perimeter.

Read the owner column top to bottom. Advin Services. NextGenWebs. Zkillu. VPS Dedicated LLC — a provider that put the word dedicated in its own name. Bucklog. Data Campus. PIO-Hosting. Every single banned block belongs to a hosting, VPS, or dedicated-server provider. Not one is a residential ISP. Not one is a mobile carrier. Not one is a hyperscale cloud — no AWS, no Azure, no Google, no DigitalOcean range appears anywhere in the list. The blunt instrument has, across ten firings, never once landed on the kind of block where "collateral" would mean a household, a phone, or an unrelated tenant.

That is not luck, and it is not a policy anyone wrote. It is the trigger filtering itself.

Why only hosting blocks can trip the wire

The subnet rule requires three independent attackers in the same 256-address range. Ask what kind of network can actually produce that, and the whole result falls out.

A residential or mobile ISP cannot. Its abusive traffic comes from compromised home routers and phones scattered across an enormous, dynamically-assigned pool; the chance of three separate infected subscribers landing in the same /24 at the same time is negligible. Residential abuse is broad and thin — one hostile IP here, one there, never three neighbours.

A hyperscale cloud cannot either, for the opposite reason. An Azure or DigitalOcean /24 is sliced across hundreds of unrelated tenants; a single malicious customer holds one address in it, not three. To get three attacking IPs into one cloud /24 you would need three separate malicious tenants to be assigned adjacent addresses by chance — which is why, across this entire series, the cloud recidivists that dominate the per-host tier-3 roster of Part 2 never appear here. They can't. One tenant, one IP, no concentration.

Only one kind of network reliably puts three or more hostile addresses inside a single /24: a hosting provider whose block is rented, in bulk, to an operator running a fleet. When an attacker leases twenty VPSs from Advin or fifteen from NextGenWebs, they arrive as a contiguous run of addresses in the provider's allocation — and when that operator points the fleet at a target, three, four, eighteen of them light up in the same /24 at once. The concentration that trips the subnet wire is the signature of a rented attack block. The trigger condition and the thing worth banning are the same condition.

So the forty-to-one collateral ratio is an illusion of counting. The 253 addresses "punished" alongside the three that were seen are not bystanders. They are the rest of the same operator's rented range — the VPSs not yet activated, or activated against someone else's perimeter. Banning the block does not over-reach past the attacker; it completes the picture of the attacker, pre-empting the members of the fleet this perimeter hadn't been hit by yet.

The proof is in the homogeneity

If the banned blocks were coincidental co-locations — genuinely unrelated tenants who happened to share a range — their behaviour would be mixed. It is not. Look at the dominant-behaviour column again, block by block:

• 208.84.100.0/24 (Advin, 18 IPs): eighteen addresses, and near-uniformly a single scenario — http-sensitive-files, the hunt for exposed .env, .git, backup, and config files. Eighteen tenants do not spontaneously agree to run the identical scan. One operator with eighteen rented boxes does.
• 88.151.33.0/24 (NextGenWebs, 15 IPs): the same signature, fifteen-fold — a sensitive-file fleet, and the block that contains 88.151.33.10, a tier-3 individual recidivist from Part 2. The host that earned its own year-ban was simply the most persistent member of a whole hostile block.
• 31.56.58.0/24 (Zkillu, 5 IPs): all five firing credential_harvest — a coordinated credential-stuffing fleet, every member doing the one thing.
• 130.12.182.0/24 (VPS Dedicated LLC, 4 IPs): all four cowrie-ssh-bruteforce — an SSH brute-force fleet, of which more below.
• 185.177.72.0/24 (Bucklog, 4 IPs): the Bucklog cluster of Part 2, whole block on http-sensitive-files.

A block whose every active member runs the same campaign is not a neighbourhood. It is a single operation wearing consecutive addresses. The homogeneity is the fingerprint, and it is what turns the subnet ban from collective punishment into what it actually is: the correct unit of judgement for an adversary who was never really a set of individual hosts to begin with.

Block-level recidivism: the fleets that reoffended after the wall went up

A subnet does not climb the tier ladder for free. To move from the initial ban (tier 1) to a month (tier 2) to a year (tier 3), more members of the block must keep reoffending after it was already banned. Three of the ten blocks reached tier 3, and what that means is worth sitting with.

[DOCUMENTED] 185.177.72.0/24 (Bucklog) escalated across all three tiers on a single day — 2026-03-25 — going ban → tier 2 → tier 3 in hours. The block arrived already saturated: four members had accumulated enough individual bans that the moment the subnet threshold tripped, the escalator immediately recognised a heavily-reoffending range and jumped it straight to a year. 88.151.33.0/24 (NextGenWebs) did the same on 2026-05-04, leaping ban → tier 3 in one step on the strength of sixteen flagged members. 62.164.177.0/24 (Data Campus) took the slow road — banned in May, tier 2 a week later, and only reaching tier 3 on 2026-07-22, as its members kept probing across two months.

The behaviour these escalations describe is an operator attacking from a range they can see is already blocked. Every packet from 185.177.72.0/24 after 25 March hit a closed door, and the fleet kept knocking — which tells you the operator either never checks whether the target is reachable before firing (fully automated, fire-and-forget scanning) or does not care about the cost of wasted probes because the VPSs are cheap and the target list is enormous. Both readings point the same way: this is industrial-scale, indifferent scanning, and the block-level year-ban is the correct response to a range whose owner will keep it pointed at you until the lease runs out.

The densest block: eighteen boxes, one campaign

208.84.100.0/24 (Advin Services LLC) is the heaviest concentration the escalator has ever recorded — eighteen distinct attacking addresses inside a single /24, from .11 to .247, scattered across the whole range rather than clustered in a corner of it. That scattering matters: an operator issued a contiguous handful of addresses would show up as .100–.104; eighteen addresses spread evenly across .11, .28, .42, .97, .113, .145, .165, .188, .201, .238, .247 and more is an operator who has been allocated, or has rented up, a large fraction of the entire block over time. Advin's /24 is not hosting an attacker as one tenant among many; a substantial share of the block is the attacker.

And nearly every one of the eighteen fires the same scenario — http-sensitive-files — the patient, low-and-slow hunt for exposed credentials and configuration that recurs throughout this series as the signature of the credential-harvesting economy. Eighteen addresses, one campaign, one provider, one /24. When the escalator banned the block it did not silence eighteen independent nuisances; it cut a single eighteen-headed operation off at the root with one rule. This is the strongest single vindication of the subnet approach on the entire list: chasing 208.84.100.0/24 one address at a time would have meant eighteen separate escalation ladders, each running for months. The block ban ended all of it at once, and the fourteen-to-one "collateral" was, to the last address, more of the same hunter.

The blocks map the operators — two of them own more than one

Because the mechanism keys on the provider's /24, its ledger quietly does attribution the per-host view cannot. Two owners appear on the list more than once.

NextGenWebs S.L. (AS41608) owns three of the ten banned blocks — 88.151.32.0/24, .33.0/24, and .34.0/24 — three consecutive /24s, together a contiguous 88.151.32.0/22 running twenty-two observed sensitive-file hunters. This is not three coincidences at one provider; it is one operator's /22 of rented attack infrastructure, discovered a block at a time by a mechanism that was only ever looking at one apartment's inbound logs. The escalator banned all three within a single week of May 2026, in the order the attacks arrived.

Advin Services LLC (AS22295) owns two — 208.84.100.0/24 (eighteen IPs) and 142.248.80.0/24 — both sensitive-file fleets, banned six weeks apart. One operator, two blocks, the same campaign.

The lesson mirrors Part 3's, from the inside this time: the interesting unit of a persistent adversary is rarely the address and often the allocation. A per-host defender chasing individual IPs at NextGenWebs would have banned twenty-two addresses across three exhausting waves. The subnet mechanism banned the operator's real estate in three firewall lines and was done.

The honeypot's back door into the subnet ledger

One block on the list is not like the others, and it closes a loop opened in Part 2. 130.12.182.0/24 (VPS Dedicated LLC) is banned not for web attacks but for cowrie-ssh-bruteforce — its four flagged members were caught by the honeypot, hammering SSH.

Part 2 noted that SSH brute-force actors almost never reach the individual tier-3 ban, because they rotate through enormous botnet address pools and no single IP reoffends often enough to climb the ladder. That remains true at the per-host level. But at the subnet level a different door opens: when an SSH operator runs their brute-force from a rented hosting block rather than a scattered botnet — four VPSs at VPS Dedicated LLC — the concentration that individual rotation defeats reappears, and the subnet threshold catches what the per-host ladder could not. The honeypot feeds the subnet ledger exactly when the SSH attacker makes the mistake of using dedicated infrastructure instead of disposable bots. 130.12.182.0/24 is that mistake, banned.

Two instruments, two domains

Set Part 3 and Part 4 side by side and the whole defensive design resolves into something coherent. There are two escalation mechanisms, and they divide the adversary space cleanly:

• The per-host ladder governs the recidivists on hyperscale cloud — the Azure and DigitalOcean hosts that dominate Part 2's tier-3 roster. There, and only there, subnet banning would be genuinely reckless: a /24 ban on an Azure range would sever hundreds of innocent tenants. So the mechanism correctly never fires there — not by rule, but because those attackers can never concentrate three-to-a-block. Cloud attackers are judged one address at a time, which is the only fair way to judge a shared range.
• The subnet ban governs the fleets on dedicated and bulletproof hosting — Advin, NextGenWebs, Bucklog, Zkillu, and their kind. There the whole /24 is one operator's rented range, collateral is nil, and banning the block is both surgically accurate and vastly cheaper than chasing its members one at a time.

Neither mechanism could safely do the other's job. Their boundary is drawn not by configuration but by the physics of how each kind of attacker holds address space — and the escalator, without being told, applies each in exactly the domain where it is fair.

The one honest caveat

A blunt instrument that lands accurately is still a blunt instrument, and intellectual honesty requires naming the residual risk. A hosting provider's block is single-operator today; addresses are re-leased. A /24 banned in March for one tenant's fleet could, a year into its tier-3 sentence, contain a new and innocent customer at one of those addresses — who would find themselves silently blocked by a perimeter that has never seen them do anything wrong, punished for the reputation of the box's previous renter. This is real, and the subnet mechanism does not detect it.

Two things bound the harm. First, it is this perimeter only — a private blocklist on one apartment's edge, not a global denylist; the collateral tenant is refused by exactly one destination they were very unlikely to be legitimately reaching. Second, the providers on the list are not neutral ground. A range that concentrated fifteen sensitive-file hunters or eighteen scanners is a range whose owner rents, repeatedly, to the people who run those campaigns. Distrusting the block after the operator moves out is not a bug of the mechanism so much as an accurate prior about the landlord. The ban outlives the tenant because the address's record, like the recidivists' in Part 3, is longer than any single lease.

Still — it is the one place in this series where the machine can be wrong about a specific stranger, and it belongs in the ledger stated plainly, not buried. The subnet verdict is fair in aggregate and blunt in the particular, and both halves of that sentence are true at once.

What the block teaches

The subnet ban looked, at the top of this letter, like the machine's one lapse into injustice — 256 condemned for the sins of 3. It ends as something closer to the opposite: the mechanism in the whole series whose trigger is indistinguishable from its justification. Only a rented attack block can put three hostiles in one /24; a rented attack block is precisely the thing worth banning whole; and the homogeneous, single-campaign behaviour inside every one of the ten proves the collateral was never innocent to begin with.

Judged one address at a time, a fleet is exhausting and nearly endless. Judged by the block it rents, it is finite, mappable, and — in ten firewall lines — already handled. The verdict on the subnet is the verdict on the operator, and the operator is who we were after the entire time.