LSN โ€” Local Sovereign Network

The Payload: The Round That Actually Lands

TI-2026-075K ยท The Armory, Part K Confidence: HIGH โ€” direct honeypot download record + multi-source corroboration Classification: TLP:WHITE

The tool wins the door; the payload does the damage

Everything the Armory has counted so far โ€” the SSH clients, the credential magazines, the fleets and the operators โ€” buys one thing: a foothold. A shell prompt on a machine that was not supposed to give one. But a foothold is not a compromise. The login is the moment the door opens; nothing has actually happened to the victim yet. What happens next is a second, separate act: the intruder reaches back out to the internet and fetches a payload โ€” a different weapon entirely, with its own author, its own architecture, its own command-and-control, and its own life independent of the tool that won the door.

This letter is about that second weapon. The census told us what the attacker carries; the credential letter told us what they load; this one tells us what they deliver. And the download record is where the whole series' abstraction becomes concrete, because the download is the exact instant the access becomes the compromise โ€” where a neutral SSH tool that got through hands off to a payload that does harm.

The honeypot has watched this handoff 247 times, from 152 IPs. What it delivers is a small, reused, and revealing arsenal.

A small arsenal, endlessly reused

The first surprise of the download record is how little variety it holds. 247 downloads, 152 source IPs โ€” but only 69 unique hashes, and the distribution is dominated by a handful of binaries pulled again and again. One single payload, SHA-256 a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2, was fetched by 81 distinct IPs. A second was fetched by 55. The rest trail off into a long tail of singletons.

This is the inverse of the delivery layer. The tools that win the door are diverse โ€” dozens of SSH client builds, library versions, languages. But the payloads they deliver converge. Eighty-one unrelated footholds, won by who-knows-how-many different access tools, all reach out and pull the same binary. The second stage is not bespoke, not tailored per victim; it is a mass-produced round, stamped out once and loaded by whole populations of compromised machines. The delivery is a bespoke break-in; the payload is a commodity.

That convergence is a gift, and we will return to it: a reused payload hash is one of the strongest cluster keys a defender has, because it collapses a crowd of unrelated-looking intrusions into a single campaign.

The miner that pretends to be the kernel

What is that most-reused round โ€” the binary 81 footholds all reached for? It is a cryptominer. An XMRig-based ELF that, once running, burns the victim's CPU to mine currency for someone else โ€” and that hides by masquerading as kswapd0, the legitimate Linux kernel-swap thread.

The disguise is the clever part. An administrator who notices a machine running hot and opens the process list sees kswapd0 near the top, consuming CPU โ€” and thinks nothing of it, because kswapd0 is supposed to be there; it is part of the operating system. The miner has borrowed the name of a kernel process to make its own theft look like the kernel doing its job. Monetisation by stolen compute, wrapped in the appearance of the OS itself.

This is the single most common terminal payload of the access tools the Armory has catalogued. It is not new to the corpus โ€” the same a8460f446โ€ฆ hash is documented in The SSH Parasite (TI-2026-025A) as the kswapd0 miner, and the whole miner supply chain is mapped in depth across the 052 Malware Graph series and 071R. The Armory does not re-litigate that analysis; it simply names the miner for what it is in this frame โ€” the round the neutral delivery tools of the census exist, ultimately, to fire.

Compiled for every CPU

The second thing the download record reveals is how the offense solves a problem it cannot avoid: it does not know, in advance, what kind of machine its next foothold will be.

So it carries a round for each. The RedTail family appears in the record compiled for every architecture at once โ€” redtail.i686, redtail.x86_64, redtail.arm7, redtail.arm8 โ€” bundled with a setup.sh dropper. The modzmodz meow loader ships as both meow (x86) and meowarm64. The whisper IoT bot comes as whisper.armv5 and whisper.armv6. One campaign, many binaries, one per instruction set.

This is the compiled mirror of the device-fingerprinting documented in The First Move (075F). There, the intruder's first reconnaissance learns the target's device class and CPU; here, the answer selects which binary is loaded. An x86 server gets the x86_64 build; an ARM router gets arm7; an IoT gadget gets armv5. The reconnaissance and the multi-arch payload set are two halves of one machine: learn the CPU, load the matching round.

And notice the symmetry with the delivery layer. The Resident (075H) showed AsyncSSH solving portability on the delivery side by carrying an interpreter-portable Python script that runs anywhere. RedTail solves the identical portability problem on the payload side by cross-compiling a native binary for every architecture. Two ends of the same operation, both engineered to run on the messy zoo of hardware the internet actually is. A multi-arch payload set is, in itself, a signal: it marks an operation built to enrol a heterogeneous device population, not a one-off.

Where the rounds are staged

The payloads have to live somewhere between builds and delivery, and the record shows two staging strategies โ€” the same two the whole series keeps finding at every layer.

Some rounds sit on raw disposable IPs. 31.170.22.205 serves the whisper IoT bots and a dl600 loader; 202.155.10.112 serves a binary called shr. These are the hosting equivalent of a burner โ€” an address that stages the payload until it is burned and replaced.

Other rounds hide inside a service the defender already trusts. Shell loaders and a neofetch-disguised pull come straight from raw.githubusercontent.com โ€” GitHub's raw-content endpoint. Riding a trusted CDN means the payload fetch blends into the ocean of legitimate developer traffic that talks to GitHub all day; IP reputation is useless, because the IP is GitHub's. This is The Cloud Contractor (075B) and The Resident (075H) replayed one layer down: some operators buy disposable ground, others hide in the well-lit centre. A payload pulled from GitHub's raw endpoint is not benign because of where it came from. The behaviour โ€” a freshly-compromised server fetching an executable โ€” is the signal, and the destination's brand is a distraction.

Two weapons, two chances

The load-bearing idea of this letter is a separation the earlier letters could afford to blur: the payload is a different weapon from the tool that delivered it.

The SSH client โ€” Hydra, AsyncSSH, a libssh scanner โ€” has its own HASSH, its own reuse graph, its own operator. The payload โ€” the kswapd0 miner, RedTail, meow โ€” has a different author, a different architecture set, a different C2, and a different reuse graph keyed on its own hash. They meet for exactly one instant, at the download, and then diverge. The delivery tool's job is finished the moment the shell opens; the payload's job is only beginning.

For a defender, that separation is not academic โ€” it is a second chance. Because the compromise is not complete at login (it is complete only when the payload lands), the download is an independent detection opportunity that arrives after the access tool has already succeeded. A defender who lost the credential fight โ€” who did not stop the guessed login โ€” can still win at the fetch, by catching the outbound pull of an executable to an arbitrary IP or a raw CDN path from a machine that has no business fetching binaries. The access got through; the compromise still has to phone home for its weapon, and that phone call is loud.

This is why the reused payload hash matters so much. One binary pulled by 81 IPs means the second-stage arsenal is far smaller than the population deploying it โ€” so the payload hash clusters footholds into campaigns the way HASSH clusters connections into fleets. Where the delivery tool names the fleet, the payload names the monetisation operator behind many fleets, and a shared payload SHA-256 is a durable, cross-victim IOC that survives every rotation of the disposable delivery infrastructure.

Reading the payload โ€” for defenders

The download layer collapses into a short posture that treats the payload as the distinct weapon it is:

The census taught us what wins the door. This letter names what walks through it. The two are different weapons, they leave the door at different moments, and the second one โ€” the round that actually lands โ€” is where the whole quiet catalogue of access tools finally does its harm.

Indicators (TLP:WHITE)

IndicatorTypeMeaning
Payload SHA-256 a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2Payload IOCXMRig miner masquerading as kswapd0; pulled by 81 IPs โ€” a campaign cluster key
redtail.i686 / .x86_64 / .arm7 / .arm8; meow / meowarm64Payload IOCsMulti-architecture second stage โ€” device-agnostic enrolment
whisper.armv5 / whisper.armv6, dl600 on 31.170.22.205Payload / host IOCsIoT-bot staging on a disposable host
202.155.10.112/shrHost IOCDisposable payload staging host
Shell droppers / neofetch pull from raw.githubusercontent.comBehaviourPayload staged on a trusted CDN โ€” reputation is not safety
Post-login outbound fetch of an executableBehaviourThe compromise moment โ€” a second detection chance after the access tool won

Cross-references

This dossier documents observed adversary infrastructure and behaviour for defensive purposes. Payload hashes and staging hosts are published as IOCs. TLP:WHITE.

โš  Personal capacity. Research published independently โ€” not reflecting employer views. Derived from passive observation of attacks against personal infrastructure. Full disclaimer โ†’
โ† Previous The Armory โ€” 11 / 26 Next โ†’