The Resident: A Botnet Native to One Carrier

TI-2026-075H · The Armory, Part H Confidence: HIGH — direct honeypot HASSH coordination (155 IPs, one tool, one country) + multi-source corroboration Classification: TLP:WHITE

A fleet that was never rented

The last two letters of this series were about landlords. The Cloud Contractor (TI-2026-075B) rented its whole arsenal from one hyperscaler. The Tenant of Fifty-Six Networks (TI-2026-075G) rented 124 servers from 56 commercial providers at once. Both paid money for their infrastructure; both could, in principle, have it cancelled. This letter is about a fleet that pays nothing, owns nothing, and cannot be cancelled — because it was never rented. It was grown.

The honeypot's tool-fingerprinting resolves a cluster around a single HASSH: fda360b1b4f4d3455cb75c6e7edb1d11, the signature of AsyncSSH 2.1.0, a Python async SSH library. It was presented by 155 distinct source IPs across 5,193 sessions between 24 March and 10 July 2026. And the first thing you notice about those 155 IPs is the thing that decides everything else: every single one of them is in Vietnam. Not most. Not predominantly. All of them.

A tool population that is one hundred percent one country is not what a globally-distributed scanning service looks like. Scanners rented from clouds scatter across the map — that is the whole point of renting them. A fleet that is entirely one nation's addresses is something different: it is local. It lives inside one country's network, and to understand it you have to stop thinking about rented servers and start thinking about the millions of consumer devices — home routers, IP cameras, media boxes, small-office PBXes — that sit on that country's residential broadband, quietly, with their default passwords unchanged.

This is a portrait of one of those fleets. It is the third pole of the infrastructure this series has been mapping: not concentration on a rented cloud, not dispersion across rented clouds, but residence inside a carrier's consumer address space, on hardware that belongs to people who have no idea it is being used.

The churn that lies about its own size

The 155 addresses fall into a handful of Vietnamese consumer-broadband ranges — 27.79.x, 116.110.x, 116.99.x, 171.231.x, 171.243.x — the mobile and fixed-line pools of Viettel, Vietnam's largest carrier. These are not static server IPs bought and pointed at a target. They are dynamic, CGNAT-managed, DHCP-leased consumer addresses, the kind your home connection is assigned and reassigned without you ever noticing.

And the session records prove exactly what that means. Look at a single node. 27.79.44.126 fired 91 sessions between 23:14:09 and 23:21:00 — a seven-minute burst — and was then never seen again. It is not an anomaly; it is the rule. Across the whole fleet the pattern repeats with almost mechanical regularity: each IP appears for one burst of roughly forty-five to ninety sessions, all inside a five-to-seven-minute window, and then disappears from the record entirely. One appearance, one address, gone.

That is not the behaviour of 155 servers. Servers persist; they keep their addresses; they come back. This is the behaviour of a smaller set of physical devices, each of which wakes, hammers the honeypot with its credential list for a few minutes, and is then handed a fresh IP by the carrier's address pool before its next appearance — at which point the honeypot logs it as a "new" attacker. The 155-address count is an artefact. It is the number of faces the fleet has worn, not the number of devices it is made of. The real device count is hidden behind the churn, and the churn is not an evasion the operator designed — it is simply what compromised consumer hardware looks like when it lives on a dynamic-IP carrier.

For a defender, this is the first and most important lesson of the residential botnet: counting IPs overstates it, and blocklisting IPs cannot stop it. Block 27.79.44.126 and you have blocked an address the device already abandoned. The address is disposable in a way that has nothing to do with the attacker paying for disposability — the carrier hands out disposability for free, to everyone, as a side effect of how consumer broadband works.

What the fingerprint holds together

If the addresses churn and the device count is hidden, how do we know this is one fleet at all, rather than 155 unrelated Vietnamese machines that happen to run the same common library?

Because of what does not change. A dynamic IP rolls every few minutes. But the SSH client build baked into a compromised device does not — it cannot, not without someone reflashing the firmware. Every one of the 155 churned addresses presents the identical AsyncSSH 2.1.0 handshake, down to the same algorithm-negotiation order that produces the same HASSH. The tool is the constant that the address is not. It is the thread that survives the churn and stitches 155 disposable faces back into one coherent fleet.

This is the same lesson the whole Armory series keeps arriving at from every direction — the address says "stranger," the handshake says "same hand" — but here it does a particular kind of work. Against a rented fleet, the fingerprint proves coordination you might otherwise miss. Against a residential fleet drowning in dynamic-IP churn, the fingerprint is the only thing that makes the fleet visible as a single object at all. Strip away the HASSH and you have 155 unremarkable Vietnamese IPs, each seen once, each easy to dismiss as background noise. Add it back and the noise resolves into one organism. Fingerprint beats address — and against churn, fingerprint is the only thing that beats anything.

Why a Python library, on a router

It is worth pausing on the tool itself, because the choice is not incidental — it fits the residential model the way the model fits the carrier.

AsyncSSH is a legitimate, well-regarded open-source SSH library for Python, built on the language's asyncio framework. Its defining property is concurrency without threads: a single process can hold hundreds of SSH connections open at once, each waiting on the network, none blocking the others. For a developer automating fleets of servers, that is a convenience. For a compromised consumer device, it is close to ideal. A home router or an IP camera has a weak CPU and little memory; it cannot run a heavyweight threaded scanner. But an async event loop lets even that meagre hardware sweep many credential attempts in parallel during its brief window of activity, wringing the maximum number of guesses out of the few minutes before the carrier rolls its address. The tool is chosen to match the host: light enough for a colonised appliance, concurrent enough to be worth the electricity.

And Python itself is telling. Many embedded Linux devices — the exact routers, boxes, and gateways this fleet is made of — ship with or can easily acquire a Python interpreter, where a compiled C scanner would need to be cross-built for each device's architecture. A Python-async scanner is portable across the messy zoo of consumer-CPE architectures in a way a native binary is not; it runs wherever there is an interpreter. That portability is the same problem the payload side solves with multi-architecture builds (seen in 075F), approached from the other end: rather than compile the scanner for every CPU, carry it as a script that runs on any of them. The result is a scanning engine that is as at home on an ARM camera as on a MIPS router — which is precisely the range of hardware its credential list is hunting.

None of this makes AsyncSSH culpable. It is a blameless library doing exactly what it was built to do, on hardware it was never meant to run on, for a purpose its authors would disown. But the fit is not an accident. An operator who wanted a fleet of hijacked consumer devices to propagate itself would reach for exactly this: a lightweight, concurrent, interpreter-portable scanner. The weapon suits the body, and the body is other people's homes.

The ammunition names the prey

The tool tells you the fleet is coordinated. The credentials tell you what it is for — and this is where the fleet gives away its nature completely.

The shared credential list is not a dictionary of human passwords. There is no password123, no qwerty, no leaked-breach corpus. It is an embedded-device default table, and reading it is like reading a parts catalogue for consumer hardware:

• ubnt:ubnt — the factory default for Ubiquiti network equipment.
• root:libreelec — the default for LibreELEC, a media-centre OS that runs on set-top boxes and single-board computers.
• ftpuser:asteriskftp — a default tied to Asterisk, the open-source PBX telephony platform.
• installer:installer, support:support, operator:operator, config:config, admin:1234, admin:admin@123, guest:guest, user:user — the generic service and appliance accounts that ship on routers, cameras, DVRs, and building-management gear.

Roughly 65 of the fleet's IPs each attempt each of these — the whole fleet carries the identical list. This is not a tool for breaking into people's email or servers. It is a key ring for embedded and IoT devices, the same curated default-credential table that has driven every Mirai-lineage botnet since 2016. The list is a portrait of the prey: Ubiquiti gear, media boxes, PBXes, generic appliances.

And two entries close the argument. Among the obvious guesses, the fleet also fires system:OkwKcECs8qJP2Z and admin:0l0ctyQh243O63uD — long, random-looking, high-entropy strings that no human would ever choose as a password, each attempted by 62 to 63 of the IPs. These are not brute-force attempts. They are hardcoded vendor defaults — passwords baked into the firmware of specific device models, unguessable by design, knowable only if you extracted them from the firmware image or found them in a default-credential database. Their presence is proof that the dictionary was curated from device firmware, not assembled from human-password lists. Someone sat down with the innards of particular hardware and built a key ring to open it.

Now put the two facts together. A fleet made of compromised consumer devices is carrying a credential list curated to open more consumer devices of the same class. That is not a scanner looking for servers. It is a self-propagating organism: it exists to find and enrol the same kind of hardware it already runs on. Each infected router or box, before the carrier rolls its address away, spends its few minutes of visibility trying to make more infected routers and boxes. The ammunition names the prey, and the prey is the fleet's own future body.

Three ways to field a fleet

Step back and this letter completes a shape the series has been drawing across B, G, and H — three answers to the same question, where does an attacker put their tools?

The Cloud Contractor (075B) concentrated everything on one rented hyperscaler and trusted the platform's respectability to launder the traffic. Efficient, convenient, and killable at one abuse desk.

The Tenant of Fifty-Six Networks (075G) dispersed 124 rented nodes across 56 commercial providers so no single takedown could reach it. Survivable, but expensive — 56 hosting bills — and still, at bottom, rented: money paid for infrastructure that can be cancelled if enough parties coordinate.

The Resident (075H) does neither. It pays nothing and rents nothing. It lives on hardware it does not own, inside a carrier it does not control, hiding behind dynamic addresses the carrier hands out for free. There is no account to suspend, no invoice to cut off, no provider whose terms-of-service it violates in its own name. The rented fleets are a business expense; the resident fleet is a parasite — and parasites are cheaper and stickier than anything you can buy.

The trade-offs run the length of the spectrum. Concentration is convenient and fragile. Dispersion is resilient and costly. Residence is nearly free and nearly impossible to evict — but it is bounded by something the rented models are not: it can only grow as fast as it can compromise more devices, and it can only reach whatever its curated key ring can open. The rented operator scales by spending more; the resident operator scales by spreading — which is exactly why its ammunition is a propagation list and not a target list.

The victims are two deep

There is a moral geometry to the residential botnet that the rented models do not have, and it is worth stating plainly because it changes where the defence has to go.

When a rented fleet attacks you, there is one victim: you. The infrastructure belongs to the attacker (by contract), and the only innocent party is the target. When a resident fleet attacks you, there are two victims, and you are the second one. The first is the Vietnamese household or small business whose router, camera, or media box was quietly conscripted — who is paying for the electricity and the bandwidth that this scanning consumes, who has no idea their device spends its nights hunting for more devices to infect, and who will most likely never find out. The carrier, Viettel, is a third, unwitting party: an ordinary national ISP whose consumer edge has been colonised and whose dynamic-IP allocation is, without its consent, the botnet's cloaking device. None of these three — the subscriber, the device vendor whose defaults were left in place, the carrier — is malicious. All of them are load-bearing.

That geometry dictates the remediation, and it explains why the usual reflex fails. You cannot blocklist your way out of this fleet, because its addresses are innocent people's home connections, churning too fast to list, and blocking them punishes the first victim while barely inconveniencing the operator. The leverage is elsewhere, and it is upstream:

• At the device vendors and the standard: the propagation list is the vulnerability. Every credential in it — ubnt:ubnt, root:libreelec, ftpuser:asteriskftp, the firmware-baked defaults — is a door the fleet walks through. Devices that force a password change on first boot, and firmware that carries no shared default, close the propagation path at the source. The high-entropy vendor defaults, published as they now are, should be treated as burned and rotated.
• At the carrier: a consumer CPE that suddenly opens dozens of outbound SSH connections a minute to strangers is not doing anything a home router should do. Carrier-side detection of subscriber devices scanning is the one vantage that sees the fleet from inside its own network, before the churn hides it.
• At the defender's own edge: detection must key on what survives the churn — the AsyncSSH HASSH and the distinctive credential-list signature (especially those two high-entropy defaults, which are near-unique IOCs) — not on the disposable addresses.

What the resident teaches

The rented fleets of B and G were studies in how attackers buy survivability. The resident fleet of H is a study in how they avoid buying it at all — by living on someone else's hardware, behind someone else's addresses, at no cost and no risk to any account of their own. It is the cheapest infrastructure model in the series and, in its own bounded way, the most durable, because there is nothing to cancel and no one to bill.

But it is also, in the end, held together by exactly the same thread as every other fleet this series has caught: a tool fingerprint the devices cannot change without being reflashed, and a credential signature so distinctive it doubles as a target list. The operator gets the whole apparatus for free — the devices, the addresses, the churn, the cloaking — and pays for it with the one thing they cannot make free: a handshake that is the same everywhere, carrying ammunition that announces precisely what it is hunting. The fleet is invisible as 155 innocent Vietnamese IPs. It is perfectly visible as one AsyncSSH client firing a firmware-scraped key ring. Which of those two things you see depends entirely on whether you are looking at the address or the fingerprint. The address is a lie the carrier tells by accident. The fingerprint is the truth the device cannot help but repeat.

Indicators (TLP:WHITE)

Cross-references

• TI-2026-075B — The Cloud Contractor — pole one: concentration on a single rented cloud.
• TI-2026-075G — The Tenant of Fifty-Six Networks — pole two: dispersion across rented commercial providers; this dossier is the third, unrented pole.
• TI-2026-075A — The Armory: What 12,000 Attackers Carry — the census that named the AsyncSSH_2.1.0 fleet examined in full here.
• TI-2026-075F — The First Move — the payload side of device-fingerprinting; here the fingerprinting is in the credential list, selecting the prey before contact.

This dossier documents observed adversary infrastructure and behaviour for defensive purposes. The consumer devices and the carrier named are unwitting hosts, not culpable actors; attribution is stated at the level the evidence supports — one coordinated fleet, proven by a shared tool fingerprint and credential signature — and no further. TLP:WHITE.