LSN โ€” Local Sovereign Network

The Kill List: What the Worm Clears to Own the Host

The Raspberry Worm โ€” Part 6

Classification: HIGH ยท Confidence: HIGH (first-party kill-list; corroborated by captured competitors)

Every letter in this series has read the Raspberry Worm forward โ€” how it arrives, spreads, takes commands, is built, and who it conscripts. This one reads it sideways, at its rivals. Because buried in the worm's setup routine, before it plants a single backdoor or joins a single channel, is a block of code that does nothing to the host except empty it of other malware โ€” a killall and rm -rf sequence that terminates and deletes a specific, named list of programs. That list is not incidental housekeeping. It is a target package: a curated census of exactly which other infections the operator expects to find already squatting on a freshly-compromised Linux device, and intends to evict. Read carefully, the kill-list is the clearest map this investigation has of the ecosystem the worm competes in โ€” and the honeypot's own captured samples confirm, family by family, that the map is accurate and current.

The worm, it turns out, is not primarily a thing that does something to a host. It is a thing that clears a host, locks it, and holds it โ€” a reaper that comes to an infected machine, kills whatever it finds, changes the locks, and waits.

The list itself

Read from the worm's own bytes, the eviction routine is explicit:

killall bins.sh minerd node nodejs \
        ktx-armv4l ktx-i586 ktx-m68k ktx-mips ktx-mipsel \
        ktx-powerpc ktx-sh4 ktx-sparc arm5 zmap kaiten perl
rm -rf /tmp/ktx* /tmp/cpuminer-multi /var/tmp/kaiten

Sixteen process names and three deletion paths, and every one of them is a known category of Linux commodity malware. Sorted by what they are, the list resolves into the three industries that fight over cheap Linux and IoT hosts:

That eight-architecture ktx-* list is worth pausing on, because it is a fingerprint of the whole battlefield's shape. An attacker who bothers to compile a DDoS bot for m68k, sh4, sparc, and powerpc is not chasing modern servers โ€” those are the CPUs of old routers, industrial controllers, set-top boxes, and the long tail of embedded Linux that never dies and never updates. The worm's kill-list is built to sweep that entire zoo, which means the operator expects its victims to be that zoo. The Raspberry Pi is only the most famous member of a much larger population of cheap, forgotten, default-credentialed Linux devices, and the kill-list is sized for all of it.

The honeypot caught what the list hunts

A kill-list is a claim about what is out there; the honeypot's retained-sample corpus is the check on that claim, and it corroborates cleanly. Two of the exact industries the worm evicts are not just present in the corpus โ€” they are its dominant captures.

XMRig โ€” thirty-three real samples. After setting aside the four worm builds the classifier mislabelled as XMRig (Part 4), thirty-three genuine XMRig miners remain โ€” the single largest real family in the honeypot. XMRig is the modern successor to minerd: the dominant open-source Monero CPU miner, endlessly abused because mining Monero on stolen CPUs is the most direct way to convert a compromised host into money. The captured samples are multi-megabyte ELF binaries carrying unmistakable configuration strings โ€” current_preset_xmrig_poolAddr, xmrig_algo โ€” and, tellingly, several are delivered under the filename sshd, disguised as the very daemon whose weakness let them in. Several also ship a clean.sh โ€” because the miners, too, kill their rivals before settling in. The worm's killall minerd is aimed at exactly this industry's older generation; XMRig is the generation that replaced it, and it is thick on the ground.

RedTail โ€” eleven samples. RedTail is a more organised mining operation: a Monero-mining botnet, built on XMRig internally (its binaries carry cryptonight-monerov8 and XMRIG_VERSION strings), but wrapped in propagation and delivered as a cross-compiled fleet โ€” the corpus holds redtail.i686, redtail.x86_64, redtail.arm8, and redtail.riscv. That last one matters: a RISC-V payload is a bet on the newest wave of cheap embedded hardware, the architecture now shipping in the next generation of the same low-cost devices the whole battlefield fights over. Where the ktx-* list points backward at the m68k-and-sparc past, RedTail's riscv payload points forward at the future โ€” and the worm sits in the middle of that timeline, evicting both the old DDoS bots and clearing ground the new miners want.

So the kill-list is not a historical artifact copied from some ancestor and left to rot. It names the live competition, and the honeypot independently caught that competition arriving in force: thirty-three modern miners and eleven multi-arch mining-botnet payloads, exactly the industry the worm's eviction routine is built to displace.

Mining is the market

Before reading the three industries as equals, it is worth weighing them, because the corpus does not weigh them equally. Of the honeypot's roughly eighty-four retained samples, forty-four are miners โ€” thirty-three XMRig and eleven RedTail โ€” more than half of everything captured. No other single purpose comes close. If the compromised-Linux underworld has a dominant product, the numbers say it is Monero, mined on other people's processors, and everything else โ€” the flooders, the loaders, the worm โ€” competes for a resource that the mining industry is trying to occupy wall to wall.

The reason mining dominates is that it is the shortest path from a stolen host to money. A DDoS bot has to be rented to a customer who wants a target hit; a stolen host has to be sold or used by someone with a plan; but a miner monetises itself the instant it starts, converting CPU cycles directly into cryptocurrency in the operator's wallet with no buyer, no command, and no further effort. It is passive, immediate, and infinitely scalable โ€” one more host is just one more trickle of Monero โ€” which is exactly why it is deployed by the thousand and why XMRig, a legitimate open-source miner, is the single most-abused piece of software on the Linux battlefield. The sshd-disguised filenames on the captured samples are the one concession to stealth: a miner wants to run quietly and forever, so it wears the name of a daemon no administrator would kill. Mining is the market's ground state, the thing a host drifts toward if nothing more ambitious claims it first โ€” and it is precisely that default outcome the worm's killall minerd is built to prevent, so the host can be claimed for something else.

RedTail: the professional end of the competition

The eleven RedTail samples deserve their own read, because they mark the point where the competition stops being commodity scripts and becomes an operation. RedTail is a Monero-mining botnet that emerged into wide reporting in 2024 and distinguished itself from the XMRig crowd in two ways that the captured payloads confirm. First, it is built on XMRig but wrapped โ€” the binaries carry XMRig's own cryptonight-monerov8 and XMRIG_VERSION strings, but bundled inside a self-propagating, self-updating package rather than dropped as a raw miner; the operator took the commodity engine and industrialised its delivery. Second, it is aggressively cross-compiled โ€” the corpus holds i686, x86_64, arm8, and riscv builds, meaning the operator maintains a build pipeline targeting the full sweep of processors a compromised device might carry, rather than betting on one.

That the honeypot caught RedTail at all, and caught its RISC-V payload specifically, says something about where the battlefield is heading. RISC-V is the architecture of the newest generation of cheap single-board computers and embedded devices โ€” the successors, in cost and ubiquity, to the very Raspberry Pis this series is named for. A mining operation compiling for RISC-V in 2026 is positioning for the next decade's install base of under-defended hardware before it has fully arrived. The worm and RedTail are, in that sense, two different bets on the same future: both expect the population of cheap, default-credentialed Linux devices to keep growing, and both are building to harvest it โ€” RedTail to mine it, the worm to hold it. The professional miner and the land-grabbing worm are not opposites; they are two ways of monetising the same expanding frontier, and they will keep meeting on it.

Three industries, one host

Step back and the whole ecosystem resolves into three business models competing for a single scarce resource โ€” a compromised, unattended Linux host โ€” and the worm's kill-list is a map of all three.

The miners (XMRig, RedTail, the old minerd/cpuminer) want the host's CPU: they convert stolen cycles directly into Monero, quietly, for as long as they can stay resident. The flooders (kaiten, the ktx-* fleet, the Mirai loaders behind bins.sh) want the host's bandwidth and its address: they enlist it into denial-of-service swarms, renting the aggregate firepower of thousands of small devices. And the worm wants something the other two do not directly monetise: the host itself โ€” root, persistence, and a command channel โ€” held in reserve.

That third model is the strategic key to the entire series. The Raspberry Worm carries no miner of its own. It clears the miners, it clears the flooders, it locks the door, it installs a backdoor and joins #biret โ€” and then it does nothing visibly profitable at all. Its value proposition is not immediate revenue; it is optionality. A host that is cleared of rivals, locked so no rival can return, and wired to an authenticated command channel is a host that can be turned to anything the operator later decides is worth doing โ€” deployed as a miner on command, enlisted in a flood, rented to a third party, or used as a pivot โ€” with a single signed message. The worm's competitors take the host's cycles or its bandwidth now; the worm takes the host, and defers the question of what to extract from it. Kill first, monetise later. It is the land-grab model of botnet-building: seize and hold the territory, and decide its use afterward.

What the worm actually sells

If the worm carries no miner and issues, in the honeypot's four months of observation, no visible profit-taking command, a fair question is what it is for โ€” and the most likely answer reframes it from a botnet into a supplier. A host that has been cleared of all rivals, locked so none can return, given a root backdoor, and wired to an authenticated command channel is, in the economics of this underworld, a finished product: reliable, exclusive, persistent access to a compromised machine. That product has a standing market. The initial-access economy โ€” brokers who compromise hosts and sell entry to others rather than exploiting it themselves โ€” is one of the most mature parts of the criminal ecosystem, and a self-propagating worm that mass-produces clean, exclusive, backdoored hosts is, whether by intent or by convergence, an access-manufacturing engine.

Seen this way, the worm's refusal to mine is not a gap in its business model; it is the business model. Mining a host commits it to one low-margin use and advertises the compromise through elevated CPU and network noise, inviting the cleanup that ends the access. Holding a host quietly โ€” evicting the noisy miners precisely so it does not draw attention, keeping it exclusive so its value is not diluted, deferring all use to a single signed command โ€” preserves the asset in its most sellable and most flexible state. The #biret channel of Part 3 is then not merely a control plane but a delivery mechanism: the point at which held access is finally spent, whether by the operator deploying their own payload or by a buyer's, one signed message at a time. The worm's whole architecture โ€” clear, lock, backdoor, wait โ€” is the architecture of an inventory system, and the inventory is compromised hosts kept fresh until sold or used.

This is why the eviction is so thorough, and why it pairs with the password-lock of Part 2. A miner tolerates neighbours it must merely out-compete for CPU; a land-grab cannot. To hold a host as an asset, the worm must be the only thing on it โ€” otherwise a miner is stealing the cycles it might later want, a flooder is drawing the attention that might get the host cleaned, and a rival with the same default password could re-take it tomorrow. So it kills everything, deletes their files, sinkholes its own parent's C2 (Part 2), and changes the pi password to seal the host against re-entry. The kill-list and the lock are two halves of one strategy: clear the property completely, then make it impossible for anyone else to move back in.

A war of all against all

The final thing the kill-list reveals is that the worm is not an aggressor in a peaceful market โ€” it is one combatant in a war that every family is already fighting. The captured XMRig samples ship their own clean.sh to kill their rivals; RedTail propagates and displaces; the Mirai loaders behind bins.sh are famous for killing competing bots on infection. Every serious family on this battlefield arrives expecting to find the host already occupied and comes armed to evict. The compromised Linux device is not virgin territory that malware discovers; it is contested ground that malware conquers, often repeatedly, each new infection killing the last, in a churn that can cycle a single vulnerable host through miner, flooder, and worm in succession as each is displaced by the next.

The Raspberry Worm's edge in that war is not a better weapon โ€” its killall is the same crude tool everyone uses โ€” but a better hold. The miners and flooders evict rivals but leave the door open, still reachable with the default password, so they in turn get evicted. The worm evicts and changes the lock, and that single addition โ€” the usermod password change that dispossesses the owner and every future worm at once โ€” is what turns a momentary conquest into a durable holding. In an ecosystem where everyone can clear a host, the winner is whoever can keep it, and the worm wins by being the one combatant that bothers to lock the gate behind itself. The kill-list clears the field; the lock is what lets the worm walk away owning it.

What holds, and what is bounded

What holds, first-party: the kill-list and deletion paths are read directly from the worm's retained bytes โ€” the sixteen process names, the three rm -rf targets, verbatim. The identification of the captured competitors is from the honeypot's own retained samples: thirty-three real XMRig binaries (with in-file mining-configuration strings and sshd-disguised filenames), eleven RedTail payloads across four architectures including RISC-V, all first-party captures on this estate.

What is characterisation, not first-party proof: the mapping of each kill-list name to a malware family (kaiten as the IRC DDoS bot, ktx-* as a Kaiten/Tsunami multi-arch variant, bins.sh as a Mirai-style loader) rests on well-established public knowledge of these long-lived families, not on capturing each named binary here. The names in the kill-list are the operator's own labels for its expected rivals; the family attributions are the standard reading of those labels.

What is inferred, not observed per-host: this letter does not prove that the worm and a given competitor met on the same physical victim. The competition is established at the level of the shared battlefield โ€” the same honeypot, the same target population, the worm's explicit intent to kill exactly what the corpus captured โ€” not by observing a single host cycle from XMRig to worm in one session. The three-industry, war-of-all-against-all model is the well-supported ecological reading of that shared ground, not a per-host forensic timeline.

What is not claimed: attribution of the competitors' operators, or that they are related to the worm's. The miners and flooders are rivals, named only as industries and families; who runs them is outside this letter, which is about what the worm fights, not whom.

Core IOCs

Cross-references

The worm's most revealing line is the one that produces no profit and plants no backdoor โ€” the killall that simply empties the house. Read as housekeeping it is trivial; read as a census it is the whole competitive landscape drawn in sixteen names, and read as a strategy it is the difference between the families that rent a host for an hour and the one that moves in to stay. Miners take the cycles, flooders take the bandwidth, and the Raspberry Worm takes the deed โ€” clearing every other claimant off the property first, and locking the gate on its way to owning ground it has not yet decided how to use.

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