LSN โ€” Local Sovereign Network

The Countermeasure: Detecting and Cutting the Raspberry Worm

The Raspberry Worm โ€” Part 7

Classification: HIGH ยท Confidence: HIGH (first-party, live)

Six letters have taken the Raspberry Worm apart: the drop, the self-propagation, the public-IRC command channel, the operator's signing key, the conscripted victims, and the rivals it evicts. This one puts the pieces back together for the only purpose that finally matters to a defender โ€” stopping it. It is a detection-and-response deliverable, and it is not academic. As this letter was being written, the honeypot logged pi:raspberry login attempts timestamped within the same minute, from a rotating set of source addresses, several per minute, each a one-to-three-second scp-push. The worm is not a case study being autopsied. It is arriving right now, at this sensor and countless others, and everything below is meant to be deployed today.

The organising principle comes from Part 4, and it is worth stating first because it determines the shape of everything that follows: detect and correlate on what the operator cannot cheaply change, not on what they change every drop. Part 4 showed the same worm produce thirteen file hashes in four months while its RSA command-signing key never moved. A defence built on hashes is a treadmill; a defence built on the key and the channel holds. So the controls here are ordered by durability โ€” the network cut first, the key-based detection second, the perishable indicators last and labelled as such.

Every control interrupts a different stage

The value of assembling the whole package, rather than picking one indicator, is that the worm's life has distinct stages and a defence that interrupts any of them stops the infection there. Laid against the worm's own kill chain, the controls form a layered defence in which no single evasion is fatal to the defender:

That last property is what makes the package robust: the stages are ordered in time, and the C2 cut sits at the end, so even a host that a defender never caught being infected is still severed from its operator the moment it tries to phone home. A worm that beats the password, the delivery alert, the YARA rule, and the host sweep still dies at the egress rule โ€” inert, backdoored but uncommandable, a held asset its holder can no longer reach. Defence in depth is not a slogan here; it is the specific reason each layer is worth deploying even though the others exist.

Cut first: block the channel

The single highest-value control against this worm requires no detection at all, and Part 3 already named it: deny outbound TCP to port 6667. The worm's command channel is IRC on UnderNet, and IRC on its standard port is a protocol almost no modern production host โ€” least of all a Raspberry Pi, a router, or an IoT device โ€” has any legitimate reason to speak. An egress rule dropping outbound 6667 severs every infected host on the protected network from #biret at once, no matter which of UnderNet's six servers it rolls, and no matter which build it runs. A bot that cannot reach its channel cannot be commanded; the held asset of Part 6 becomes inert.

This is the control to deploy before any of the detection below, because it works even against infections you have not yet found. It does not clean the host โ€” the backdoor and the lock remain โ€” but it cuts the operator's hand off the machine, which is the urgent half. On a perimeter firewall or a MikroTik-class edge router, it is one rule: drop outbound tcp/6667, log the matches, and every logged match is a host on your network you now know is compromised.

This estate already runs much of the package, which is why the worm's live arrival here is observed rather than suffered. The honeypot instant-bans every pi:raspberry source on first contact; a tiered escalation ladder promotes repeat offenders; and the edge router carries the blocklists both feed. On a MikroTik-class edge โ€” the router protecting this network โ€” the channel cut is a single pair of rules: an address-list of UnderNet's servers and a forward-drop of traffic to them on 6667, or, more simply, a blanket drop of outbound tcp/6667 from the LAN with logging. Something like:

/ip firewall filter add chain=forward protocol=tcp dst-port=6667 \
    action=drop log=yes log-prefix="worm-c2-6667" comment="Raspberry Worm C2 cut"

The point of showing it concretely is that the highest-value control in this entire letter is one firewall line, deployable on the commodity router in front of almost any small network, and that a home or small-business defender โ€” exactly the population Part 5 found conscripted โ€” could apply it in a minute. The worm's whole design bets that its victims will never look at their outbound traffic. A single logged drop rule on the edge is the cheapest possible way to make that bet lose.

Detect on the durable: the key and the channel

For detection that survives the worm's per-drop mutation, key on the two things Part 4 proved durable.

The command-signing key. Every build of this operator's worm โ€” all thirteen in four months, despite thirteen different file hashes โ€” drops the identical RSA public key to /tmp/public.pem and carries it inline. A YARA rule keyed on that public key's distinctive modulus catches the whole campaign, past and future, because changing it would mean re-keying every existing bot:

rule raspberry_worm_biret_operator_key {
  meta:
    description = "Raspberry Worm (MulDrop fork) - operator RSA command-signing key"
    reference   = "TI-2026-087C / 087D"
  strings:
    $key = "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/ihTe2DLmG9huBi9DsCJ90MJs"
    $c2  = "#biret"
    $svr = "undernet.org"
  condition:
    $key or (all of ($c2,$svr))
}

The $key string alone is high-confidence โ€” it is the operator's cryptographic identity, and no unrelated file carries it. The #biret + undernet.org pair is the fallback for any variant that re-keys but keeps the channel. This one rule does what a list of thirteen hashes cannot: it identifies the operator's worm as a family, on a durable artifact, forward as well as back.

The network rendezvous. On the wire, the worm's registration sequence is fixed and distinctive: a TCP connection to an UnderNet server on 6667, an IRC USER user 8 * :IRC hi registration, a host-derived NICK aโ€ฆ, and a JOIN #biret. A network-IDS signature keyed on the literal JOIN #biret over port 6667 โ€” or on the specific USER user 8 * :IRC hi registration string โ€” flags the beacon regardless of build. Combined with the egress block above, network detection gives both the cut and the alarm: the firewall drops the traffic, the IDS names the host.

Detect on the host: the installation fingerprints

For hosts already compromised, or caught in the act, the worm leaves a set of first-party, observed install artifacts โ€” several of them seen live at this honeypot in the current campaign โ€” that make excellent host-detection rules.

None of these are exotic; all are grep-able across a fleet with a configuration-management tool or a simple SSH sweep, and each one is durable in a way the file hash is not.

Watch the door: the credential and the choreography

Detection at the perimeter is cheapest of all, because the worm announces its propagation with a single, unmistakable credential. Every host running the worm's spread loop attempts pi:raspberry, and it does so in a distinctive choreography observed live here: a connection lasting one to three seconds, an scp -t server-side transfer pushing a file into /tmp, and an immediate chmod +x and execute โ€” get in, drop, run, leave. A honeypot, a canary SSH service, or authentication logging that flags any pi:raspberry attempt is flagging a member of the brood. During the writing of this letter such attempts arrived at a rate of several per minute from a rotating set of addresses โ€” which is both the measure of how active the campaign is and the reason perimeter credential-monitoring is worth deploying: the signal is loud, constant, and trivial to catch.

The sub-three-second scp-push itself is a behavioural signature. An SSH session that authenticates, performs an scp server-side receive into /tmp or /dev/shm, executes the received file, and disconnects inside a few seconds is the worm's delivery pattern, and it is anomalous enough on a normal host โ€” where interactive SSH sessions last minutes and rarely scp-then-immediately-execute โ€” to alert on directly.

False positives, honestly

A detection package is only useful if its false-positive behaviour is understood, and the controls here span the full range from near-perfect to needs-tuning. It is worth being candid about each, because a rule that cries wolf gets disabled, and a disabled rule protects nothing.

The ordering by false-positive safety happens to track the ordering by durability: the artifacts hardest for the operator to change (the key, the channel) are also the ones safest to alert on, while the one control that touches a shared protocol (6667) is the one requiring a moment's thought about the environment. That alignment is convenient, and it means a defender can deploy the durable, zero-FP detections aggressively and reserve judgement only for the single protocol-level rule.

The response the detection cannot deliver: remediation and the gap

Every control above protects the defender's estate. None of them fixes the victim โ€” and Part 5 established that four-fifths of the brood is victims: compromised home routers, telecom devices, and municipal boxes running the loop involuntarily. This is the honest limit of a detection package, and it must be stated rather than papered over. Banning the brood, blocking #biret, and grep-ing your own fleet for the backdoor key does nothing for the conscripted device in Malagueรฑo or Jakarta still scanning on the operator's behalf. Its owner does not read this. Its carrier may never act. The notification gap of Part 5 โ€” the abyss between those who can see a compromise and those who can fix it โ€” is not closed by any firewall rule.

What a defender who has done the detection can do, beyond self-protection, is two collaborative things. First, report #biret to UnderNet. The worm's one structural weakness is that it lives in someone else's house; UnderNet's abuse and network-operations teams can monitor the channel, G:line its bots, or kill it, and the channel name is the actionable indicator to hand them. Second, feed the durable IOCs upstream โ€” the operator key, the channel, the backdoor keys โ€” to the threat-intelligence sharing and CERT ecosystems that can, in aggregate and over time, drive carrier-level notification to victims. Neither is fast, and neither is guaranteed. But the alternative โ€” treating the brood purely as attackers to be blocked โ€” mistakes the victims for the enemy and abandons the one lever, collaborative reporting, that reaches past the perimeter toward the conscripts.

What holds, and what is bounded

What holds, first-party and live: the durable IOCs (the operator RSA key, #biret, port 6667), the observed install one-liner and backdoor key (seen 105 times), the pi:raspberry propagation choreography (observed live, several attempts per minute during the writing of this letter), and the host artifacts (password lock, /opt + rc.local persistence, DNS append) โ€” all read from this estate's own retained samples and logs.

What is bounded: the detection rules here are derived from what this sensor has captured. A variant that re-keys, changes channels, or alters its install routine would evade the perishable host indicators โ€” which is precisely why the YARA and network rules are anchored on the most durable artifacts available, and why the egress cut (which needs no signature at all) is placed first. No detection is permanent against an adaptive operator; the ranking by durability is the defence against that adaptation, not an immunity to it.

What is not claimed: that deploying this package eradicates the worm. It protects an estate, names its compromised hosts, and hands the collaborative levers to those who can pull them. Eradication of a self-propagating, victim-built, public-channel botnet is not a thing a detection package delivers; slowing it, seeing it, and cutting it off your own ground is.

The consolidated package (IOCs and rules)

Cross-references

The worm arrives as this is written, several times a minute, wearing a fresh hash each time and a label that has been wrong four times in four months. None of that helps it against a defence that ignores the hash and the label and reaches instead for the two things it cannot change โ€” the key it signs with and the channel it lives in. Block the channel, detect the key, grep for the lock, watch the door, and report the house it squats in. The worm was built to own nothing seizable; the countermeasure is built to need nothing but the one thing it cannot stop being โ€” itself, signed and rendezvoused, the same underneath every disposable skin.

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