LSN โ€” Local Sovereign Network

The Lineage: A 2017 Worm, Forked and Turned Against Its Parent

The Raspberry Worm โ€” Part 9

Classification: HIGH ยท Confidence: HIGH (first-party behaviour; public corroboration of lineage)

Eight letters have taken the Raspberry Worm apart in the present tense โ€” what it does, how it spreads, who runs it, whom it robs, what it fights, how to stop it. This one asks the question that has hung, unspoken, over all of them: where did it come from? A self-propagating bash worm that hunts pi:raspberry did not spring from nothing in 2026. It has a documented ancestor, nine years old, and placing the fork against its parent turns out to tell a story that none of the present-tense analysis could โ€” a story of a piece of malware that kept its body, inverted its purpose, and turned to devour the very family it was born from.

The ancestor is Linux.MulDrop.14, the first Raspberry Pi worm to be widely documented, discovered and named by Dr.Web in June 2017 and covered at the time across the security press. Read its 2017 description beside this series' 2026 first-party analysis and the descent is not a guess โ€” it is written in the code, line for line, and then, at one decisive point, deliberately broken.

The parent, on the public record

The 2017 profile of Linux.MulDrop.14 is a near-exact template of the worm this series documented. Per its original Dr.Web description and the contemporary coverage, MulDrop.14 was:

Every one of those bullet points is a finding of this series, restated from 2017. The zmap+sshpass+pi:raspberry propagation of Part 2; the usermod password lock of Part 2; the sub-three-second scp-push-then-execute choreography of Parts 1 and 7 โ€” all of it is the 2017 parent, unchanged. This is not two worms that happen to share a technique. The propagation body of the 2026 worm is MulDrop.14's, preserved intact across nine years, because the weakness it exploits โ€” a Raspberry Pi shipped with pi:raspberry and left that way โ€” is the one thing about the internet that has not changed since 2017 either. The worm did not need to evolve its spread, because its target never healed.

Why the body never had to change

There is a deeper reason the propagation mechanism survived nine years unaltered, and it is the same reason default-credential worms as a class refuse to die: nothing in the environment ever selected against it. Evolution โ€” of organisms or of malware โ€” changes what the environment punishes and preserves what it does not. For nine years, the environment punished nothing about zmap+sshpass+pi:raspberry, because the vulnerability it exploits was never fixed at the population level. Individual Pis got patched or replaced; the population of factory-default Raspberry Pis and default-credentialed Linux devices did not shrink โ€” it grew, as Part 5 found, faster than anyone hardened it, at exactly the under-defended edges where the fork's brood now lives.

A propagation technique that still works against a growing target base is under no evolutionary pressure to change, and so it doesn't. The 2026 fork kept MulDrop.14's spread not out of laziness but out of correctness: there was nothing to improve, because the weakness the spread targets is the one part of the internet that has stubbornly stayed broken since 2017. This is the uncomfortable inversion of the usual "malware evolves to evade defences" story. The propagation body did not evolve precisely because the defence never arrived. Where defenders did adapt โ€” reputation feeds, C2 takedowns โ€” the fork mutated in response, as the next sections show. Where defenders did nothing โ€” the default password โ€” the fork changed nothing either. Malware is a mirror of the defence it faces, and a nine-year-old spread mechanism running unmodified in 2026 is a nine-year-old indictment of a weakness no one closed.

The German thread

There is a geographic detail in the lineage worth drawing out, because it connects the parent's record to a specific marker in the fork's code. The 2017 analyses placed one documented MulDrop.14 attacker at IP 83.135.10.12 โ€” Versatel Deutschland, a German network. And the command-and-control domain that the 2026 fork goes out of its way to neutralise โ€” the one it writes into /etc/hosts pointed at loopback โ€” is bins.deutschland-zahlung.eu: deutschland-zahlung, German for "Germany-payment," a German-language domain.

The thread is suggestive rather than conclusive, and it is worth stating as exactly that: a German-origin attacker in the parent's record, and a German-named C2 domain that the fork treats as its parent's, do not prove a single continuous operator across nine years โ€” the MulDrop code has been public since 2017, and anyone could fork it. But the fork's own behaviour tells us it knows that German domain intimately: it does not merely ignore deutschland-zahlung.eu, it specifically blackholes it, which is the act of something that expects that domain to be present and wants it silenced. Whatever the human continuity, the code continuity runs through a German-flavoured C2 that the parent used and the fork has turned against.

The great divergence: the fork stopped mining

Here is where the lineage stops being a copy and becomes a story. The single most-emphasised fact about Linux.MulDrop.14 in every 2017 account is that it was a cryptocurrency miner. Its entire purpose โ€” the reason it hunted Pis at all โ€” was to launch a Monero mining program on each conscripted device and pool their stolen cycles into the operator's wallet. MulDrop.14 was a miner that happened to spread.

The 2026 fork does not mine. It carries no miner at all (Part 6). And it does not merely omit mining โ€” it actively destroys miners, its killall block terminating exactly the class of software its own ancestor was. The parent's reason for existing is the fork's primary target for eviction. A worm descended from a Monero miner now sweeps the host clean of Monero miners and holds it empty instead, monetising not the CPU but the access โ€” the land-grab, initial-access-broker model of Part 6.

This is the inversion that makes the lineage worth a letter. The fork kept everything about how MulDrop.14 spread and threw away everything about why it spread. It preserved the propagation body and replaced the purpose organ โ€” mining out, access-holding in. And the replacement is not arbitrary; it tracks nine years of change in the criminal economy. In 2017, mining Monero on a Raspberry Pi was a plausible, if meagre, revenue model. By 2026, a single Pi's CPU is worth almost nothing to a miner competing against the industrialised RedTail operations of Part 6 โ€” but a cleared, exclusive, backdoored host is worth something to the mature initial-access market that did not exist in the same form nine years earlier. The fork read the market, kept the delivery mechanism that still worked, and swapped the payload for the one that now pays. It is malware evolution in the literal sense: a stable body, a mutated function, selected by a changed environment.

Mining out, access in: nine years of economics

The payload swap deserves to be read as the economic decision it is, because it is the sharpest thing the lineage reveals about how this underworld changed. In 2017, launching a Monero miner on a captured Raspberry Pi was a marginal but defensible business: Monero was minable on a CPU, the mining-malware market was young, and a few thousand conscripted Pis trickling coins into a wallet was real, if modest, revenue. MulDrop.14 was built for that moment, and for that moment it made sense.

By 2026 the moment has passed, and the fork's abandonment of mining is the proof. A single Raspberry Pi's CPU, set against the industrialised, CVE-exploiting, multi-architecture RedTail operations of Part 6 and the professionalised mining-botnet economy they represent, produces a rounding error of Monero โ€” the marginal value of one more Pi to a miner has collapsed toward zero. What has risen, in the same nine years, is the value of access itself: the initial-access-broker economy โ€” actors who compromise hosts and sell entry to ransomware crews, data thieves, and pivoting operators โ€” matured over exactly this period into one of the most liquid markets in the criminal ecosystem. A cleared, exclusive, backdoored host wired to a command channel is a sellable unit in that market in a way it simply was not in 2017.

So the fork's payload swap is a piece of market timing encoded in code. It is not that the new operator was cleverer than MulDrop.14's author; it is that the author faced 2017's economics and the fork faces 2026's, and each chose the payload that paid in their moment. The delivery mechanism was worth keeping because the vulnerability it targets is timeless; the payload was worth replacing because the value of a compromised Pi shifted from its cycles to its access. Read the two generations side by side and you are reading a nine-year chart of where the money in compromised Linux went โ€” out of the CPU, into the doorway.

The fork ate its parent

The divergence is not passive. The 2026 worm does not simply pursue a different goal than MulDrop.14 โ€” it is built to destroy MulDrop.14 specifically, and the evidence is in three deliberate acts read from its own code across this series.

First, it kills the miners โ€” the thing its parent was โ€” with the killall of Part 6. Second, it sinkholes bins.deutschland-zahlung.eu, the parent lineage's own command-and-control domain, mapping it to 127.0.0.1 so any surviving parent-generation worm on the host goes deaf (Part 2). Third, it changes the pi password to a value only it knows (Part 2), sealing the host against the very pi:raspberry default that its parent โ€” and every sibling still using the old code โ€” needs to get back in. Clear the miners, deafen the parent's C2, change the lock the parent uses: the fork's entire persistence routine is, read through the lineage, a systematic patricide. It hunts the same hosts its ancestor hunts, reaches them the same way, and then makes them uninhabitable to the ancestor.

This is why the fork is so much more thorough about eviction than a worm merely seeking an empty host would need to be. It is not competing with unrelated malware in the abstract; it is competing with its own family โ€” the installed base of MulDrop-lineage miners still spreading with the 2017 playbook โ€” for a finite supply of vulnerable Pis, and it wins that competition by turning the family's own techniques against the family. The fork is what happens when a successful piece of malware's code outlives the moment its business model made sense: a descendant takes the still-working body, points it at a more profitable goal, and clears the field of its now-obsolete relatives to have that goal to itself.

What the fork invented

If the propagation body is inherited, the fork's own contributions are precisely the parts this series found novel โ€” the parts absent from the 2017 record, which are the branch's evolutionary innovations. Two stand out, and both are improvements on documented weaknesses of the parent.

The first is the command channel. The parent used a conventional C2 domain โ€” deutschland-zahlung.eu โ€” the kind of infrastructure that can be, and by 2026 evidently was, sinkholed and abandoned; the fork's own sinkholing of it is the proof it treats that domain as dead. The fork replaced it with #biret on the public UnderNet IRC network (Part 3) โ€” infrastructure that cannot be sinkholed because the operator does not own it. The branch learned, from its own parent's takedown-able C2, to move its control channel somewhere no takedown could reach. The second is the cryptographic command authentication โ€” the RSA-signed channel and the durable operator key of Parts 3 and 4 โ€” a governance layer no 2017 account of MulDrop.14 describes, added by an operator who wanted a fleet that could not be stolen. These are the mutations that distinguish the 2026 branch from the nine-year-old trunk: same spread, same lock, same patricidal thoroughness, but a resilient public-channel C2 and a signed command bus the parent never had.

That the fork's #biret and its RSA key appear in no public record of MulDrop.14 is itself the finding: this is a new branch, documented first-party here, whose durable markers are not yet in the wider threat-intelligence corpus. The parent is on the public record since 2017; this specific evolved fork โ€” mining abandoned, parent-C2 sinkholed, public-IRC control, signed commands โ€” is, as far as the public sources reach, characterised here. The thread Part 3 promised to hand to "other perimeters holding this key" is, at the time of writing, still ours alone to have pulled.

A bushy tree, and what lineage buys a defender

One consequence of the parent being public since 2017 is that this fork is almost certainly not the only one. MulDrop.14's bash source has been available and analysed for nine years; a codebase that simple, that well-documented, and that still-effective is forked, re-forked, and remixed continuously, and the family tree is therefore not a straight line from parent to this branch but a bush โ€” many descendants, most of them minor variations, a few, like this one, substantially re-engineered. This series characterised one branch in depth; it makes no claim to have mapped the tree. Other forks, running other payloads, on other channels, are near-certain to exist, and some will share this branch's propagation body while diverging on everything downstream exactly as this branch diverged from the trunk.

That bushiness is why lineage matters to a defender in a concrete, forward-looking way, and it is the practical payoff of this letter. Knowing the parent tells you which parts of any MulDrop descendant are load-bearing and which are disposable โ€” and therefore where to anchor a defence that survives the next fork. The propagation body is the invariant: any descendant, this one or the next, will almost certainly spread by pi:raspberry over SSH and lock the host, because that is the timeless, environment-selected core the whole lineage is built on. The payload is the variable: this branch brokers access, the next may ransom, or proxy, or do something not yet invented. So the durable defence โ€” the one that catches the fork you have not seen yet โ€” is the one anchored on the invariant propagation, exactly as Part 7 argued: watch for pi:raspberry, block the default-credential spread, change the password that the entire nine-year lineage depends on. A defence keyed on this branch's specific payload โ€” its #biret channel, its RSA key โ€” catches this fork; a defence keyed on the lineage's invariant spread catches the family. Lineage analysis is not archaeology; it is the map of which indicators will still be true after the operator's next mutation.

What holds, and what is bounded

What holds: the parent's identity and 2017 profile are on the public record (Dr.Web's original description and contemporary coverage), and the descent is established first-party by the identity of the propagation mechanism โ€” zmap+sshpass+pi:raspberry, the password lock, the scp-push choreography โ€” between the documented 2017 worm and the 2026 samples analysed across this series, together with the fork's deliberate sinkholing of the parent lineage's own deutschland-zahlung.eu C2. A worm that reproduces its ancestor's spread line for line and then specifically neutralises its ancestor's control domain is a descendant by any reasonable forensic standard.

What is bounded: descent of code is not continuity of operator. Linux.MulDrop.14's techniques have been public since 2017; the 2026 fork could have been built by the original author, by an unrelated actor who forked the public lineage, or by anyone in between. This letter claims a lineage โ€” the fork is a MulDrop descendant โ€” not an unbroken chain of authorship. The German thread (a German-origin parent attacker, a German-named parent C2) is corroborating colour, not proof of a German operator behind the 2026 branch.

What is not claimed: the person, in either generation. The 2017 operator and the 2026 operator are both pseudonymous to this analysis; the durable RSA key of Part 4 identifies the fork's operator across its own samples, not across the nine-year gap to the parent. Whether one hand runs both, or the fork is a stranger's inheritance of public code, is a question this investigation cannot close and does not pretend to.

Lineage summary (IOCs)

Cross-references

The Raspberry Worm turns out not to be a thing that was made, but a thing that was inherited โ€” a nine-year-old body of code, still spreading through a default password that nine years never fixed, carried forward by a new operator who kept everything about how it moves and changed everything about why. It stopped mining because mining stopped paying, started brokering access because access started paying, and cleared its own obsolete relatives off the hosts to have them to itself. The oldest thing on this battlefield and one of the newest business models are, it turns out, the same worm โ€” proof that on the under-defended edge of the internet, malware does not so much get replaced as evolve, keeping whatever still works and mutating only what the market forces it to. The default password is the constant. Everything built on top of it is a lineage, still branching.

Sources: Dr.Web โ€” Linux.MulDrop.14 ยท BleepingComputer ยท Boing Boing ยท Open Source For You

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