LSN โ€” Local Sovereign Network

The Other Tenant: A Modern PAM Backdoor on the Worm's Ground

The Raspberry Worm โ€” Part 8

Classification: HIGH ยท Confidence: MEDIUM-HIGH (first-party sample analysis; separate-actor framing)

Part 6 mapped the battlefield as three industries fighting over one compromised host: miners after the CPU, flooders after the bandwidth, and the worm after the host itself. Seven letters have exhausted the worm and touched the miners. This one turns to the third corner โ€” persist โ€” and finds, sharing the exact same ground as the crude bash worm this series is named for, something that is nothing like it: a small cluster of modern, compiled, Go-authored PAM backdoors whose sophistication belongs to a different decade of malware craft entirely.

The finding of this letter is the contrast itself, and it must be stated plainly at the top so the rest is not misread: this is not the Raspberry Worm. It is a separate operation, by every technical measure โ€” a different language, a different build, a different purpose, a different tier of skill โ€” that happens to hunt the same population of cheap, under-defended Linux hosts. The two are neighbours on a battlefield, not relatives. And the reason to give the neighbour a letter is that seeing the two side by side is the clearest possible picture of what the modern threat landscape on a compromised Linux device actually looks like: not one enemy, but a stratified market spanning twenty years of craft, from a 2007-lineage bash worm to a 2025 Go implant, both reaching into the same forgotten Raspberry Pis at once.

The persist corner, catalogued

Alongside the miners and the worm, the honeypot's retained-sample corpus holds a coherent cluster of roughly eighteen samples whose purpose is neither to mine nor to spread but to keep โ€” to survive on a host and hold access quietly. The classifier's own labels name the theme: SSH-PAM Backdoor, PAM session manipulator, PAM session handler, PAM credential manipulator, PAM backdoor dropper, SSH-key backdoor dropper, Runtime monitoring tool, SSHD backdoor dropper. Set aside the one member that is actually a mislabelled worm build (an IRC Bot Backdoor script, per Part 4), and what remains is a set of compiled binaries, ranging from 32 kilobytes to nearly six megabytes, first seen across the same March-to-July window as the worm.

Their size alone marks the tier gap. The worm is a 4,745-byte bash script โ€” text, readable, crude. These are multi-megabyte compiled executables, and their internals reveal what they are built from: the strings carry Go runtime paths (/usr/lib/go-1.24/src/sync/pool.go), goroutine-scheduler diagnostics, and modern cryptographic and networking primitives โ€” chacha20, sha3, and HTTP/2 frame types like STREAM_CLOSED and WINDOW_UPDATE. These are statically-linked Go programs, compiled with a 2025 toolchain, carrying their own TLS-grade crypto and an HTTP/2 client. The worm phones home in cleartext IRC to a public channel; these speak modern encrypted HTTP. Nothing about the two shares a lineage.

The toolkit's range: a module and its machinery

The size spread across the cluster is not noise; it is architecture. At one end sits the 32-kilobyte SSH-PAM Backdoor โ€” small, tight, exactly the size of a focused PAM module whose only job is to hook authentication. At the other end are the multi-megabyte members: a 5.9-megabyte SSH-related implant, a 2.7-megabyte PAM session manipulator, several SSH-key backdoor droppers and Runtime monitoring tools in the one-to-three-megabyte range. That is the shape of a modular toolkit, not a single tool: a lightweight component that installs into the authentication path, and heavier machinery โ€” droppers that deliver it, implants that carry it plus a full networking and monitoring stack, utilities that watch the host โ€” built around it.

The presence of Runtime monitoring tool and Network logging utility members is worth its own note, because it widens the operation's ambition beyond a backdoor. A pure backdoor accepts a magic key and captures passwords; a toolkit that also ships runtime-monitoring and network-logging components is built to observe the compromised host โ€” to watch what runs on it and what talks to it, not merely to log in. That is the profile of an operator who wants situational awareness of the machines it holds: which are worth deeper attention, which sit inside interesting networks, which administrators log into them and from where. The worm treats every host as identical territory; this toolkit is built to triage its hosts, to tell the valuable listening posts from the disposable ones. That distinction โ€” territory versus intelligence โ€” is the deepest difference between the two operations, and the monitoring components are its fingerprint.

What they hook: the authentication chokepoint

The cluster's defining strings are the ones that name its mechanism, and they are unambiguous. The binaries import libpam.so.0 and call, through cgo, the core Pluggable Authentication Modules functions: pam_chauthtok, pam_setcred, pam_acct_mgmt, pam_open_session, pam_close_session, and the PAM conversation callback cbPAMConv. This is a toolkit that operates on PAM โ€” the layer through which every authentication on a Linux system passes.

That target is the strategic heart of the persist corner, and it is worth understanding why it is chosen. On a Linux host, PAM is the single chokepoint every login flows through โ€” SSH, console, su, sudo, all of it. A program that hooks PAM sits at the exact point where credentials are presented and verified, which gives it two capabilities that define this class of malware. First, credential harvesting: every real password a legitimate user or administrator types on the compromised host passes through the hooked authentication path and can be captured โ€” the cbPAMConv conversation callback is precisely where a prompt-and-response is handled, and precisely where a logger would sit. Second, the magic key: a malicious PAM module can be made to accept a hardcoded backdoor password for any account, so the operator logs in as root with a secret only they know, no matter what the real password is, and no matter how often the owner changes it.

The contrast with the worm's persistence is total, and it is the most illuminating thing in this letter. The worm's hold, from Part 2, is loud: it changes the pi password with usermod, locking the legitimate owner out of their own device โ€” a hold the owner will eventually notice, because they can no longer log in. The PAM backdoor's hold is silent: it leaves the owner's password working perfectly, lets them log in exactly as before, and simply also accepts the attacker's magic key while copying every password that passes by. The worm dispossesses the owner; the PAM backdoor robs them without their ever knowing they were robbed. One is a squatter who changes the locks; the other is a copied key the owner never realises was cut. For an operation whose product is durable, quiet, credential-yielding access โ€” the initial-access economy Part 6 identified โ€” silence is worth far more than a lock, and the PAM toolkit is built for exactly that value.

Why Go, and what it buys

The choice of Go for this toolkit is not incidental, and it is a signal about the operator worth reading, because Go carries specific advantages for malware that authors do not pick by accident. A Go binary is statically linked โ€” it bundles its entire runtime and all dependencies into one self-contained executable that needs nothing from the victim host, so it runs identically on a stripped-down Raspberry Pi, a router, or a server, with no library-version fragility. It is trivially cross-compiled โ€” the same source builds for every architecture the battlefield spans, the way Part 6's RedTail shipped riscv and arm8 payloads, so one codebase covers the whole embedded zoo. It ships modern cryptography and networking in the standard library โ€” the chacha20, sha3, and HTTP/2 strings are not the operator's own crypto but Go's, meaning stealthy encrypted exfiltration over ordinary-looking HTTPS is a few lines of code rather than a project. And Go binaries are notoriously tedious to reverse-engineer: the runtime bloats the binary, symbol recovery is awkward, and the goroutine-scheduled control flow frustrates the standard tools โ€” a passive defence the author gets for free.

Every one of those properties is precisely what a serious, portable, stealthy implant wants, and none of them belongs to the world of the bash worm. A 4,745-byte shell script is the opposite of all of it: readable at a glance, dependent on the host's own utilities, tied to no architecture because it is just text, and carrying no crypto at all. The two artifacts are separated by the entire professionalisation of malware over two decades. That a Go-1.24 cgo-libpam implant and a bash IRC worm are pulled from the same honeypot in the same week, both aimed at the same forgotten Pis, is the single most compressed illustration this series offers of how wide the modern threat landscape actually is โ€” the newest tools and the oldest ones, working the same street.

The toolkit's own signature

Part 4's central lesson was that a serious operator leaves one durable artifact that survives its per-build mutation โ€” for the worm, the RSA command-signing key. The persist corner obeys the same rule with a different artifact, and finding it is the confirmation that this cluster is one toolkit and not a coincidence of unrelated backdoors. Two of the compiled binaries โ€” the 32-kilobyte SSH-PAM Backdoor and a 2.7-megabyte PAM session manipulator โ€” carry the identical cgo build hash, the symbol prefix _cgo_eba3282b571c_ stamped through their PAM-wrapper functions. That hash is generated from the specific Go source package the binaries were built from; two binaries carrying it were compiled from the same codebase. A 32-kilobyte utility and a near-three-megabyte implant sharing a cgo package hash are not two authors who happened to both hook PAM โ€” they are one author's toolkit, built and rebuilt, the small tool and the large implant cut from the same source tree.

That the two operations โ€” worm and PAM toolkit โ€” independently exhibit the same methodology of a durable build-artifact surviving mutation, while sharing no content, is itself the meta-point. It is not that they are related; it is that both are real, maintained operations run by people who rebuild their tools, and the way you catch either across its rebuilds is the same: find the artifact the author cannot cheaply change. For the worm it was a signing key; for the PAM toolkit it is a cgo package hash. The technique of Part 4 generalises to an operator it was never derived from โ€” which is the strongest evidence that the technique, not the specific key, was the real finding.

Two opposite bets on one host

Lay the worm and the PAM toolkit side by side and they are near-perfect opposites in every strategic dimension, which is why the same battlefield sustains both.

The worm is high-volume, low-sophistication: a crude bash script, mass-propagated to thousands of hosts by guessing one default password, spreading itself blindly and holding each host with a visible lock. It wins by numbers โ€” it does not need to be good, it needs to be everywhere, and its four-month campaign and hundred-host brood are the proof. The PAM toolkit is the inverse: low-volume, high-sophistication. Its samples arrive one at a time โ€” dropped once each, from a single source, not sprayed โ€” as multi-megabyte compiled implants that take real engineering to build. It wins by depth โ€” it does not need to be everywhere, it needs to be invisible and durable on the hosts that matter, harvesting credentials that unlock more than the host itself.

These are the two poles of the compromised-Linux economy, and a single cheap device can host both without contradiction, because they want different things from it. The worm wants the host as a spreader and a held asset; the PAM backdoor wants the credentials that flow through the host, which may unlock a corporate network, a cloud account, or an administrator's other machines. The worm is a land-grab; the PAM toolkit is a wiretap. That both reach into the same forgotten Raspberry Pis is the whole texture of the modern threat landscape: the least-defended devices on the internet are contested simultaneously by the crudest and the most sophisticated actors, because to a spreader they are territory and to a wiretapper they are a listening post, and a device can be both at once to two operators who have never met.

Finding the wiretap

The countermeasure of Part 7 was built for a loud worm, and it does not transfer cleanly to a silent PAM backdoor โ€” which is itself the point, and the reason this corner deserves its own detection note. The worm announces itself: it beacons to a public IRC channel you can block, it locks a password whose absence the owner notices, it drops a script whose durable key you can YARA. The PAM backdoor does none of that. It speaks encrypted HTTP that blends into normal web traffic, it leaves every real credential working so nothing seems wrong, and it hides at the one layer administrators almost never audit. You cannot block its channel without decrypting traffic, and you cannot notice its lock because there is no lock. The loud threat is found by its noise; the silent one has to be hunted.

The hunt is at the host, and it targets the one thing the toolkit cannot avoid: to hook authentication, it must be in the authentication path. So the detections are integrity checks on that path. Audit the PAM configuration โ€” /etc/pam.d/* and /etc/pam.conf โ€” for modules that should not be there, and the module directory โ€” /lib/security/, /lib64/security/, /usr/lib/*/security/ โ€” for .so files that are not part of any installed package. Verify the integrity of the real PAM modules and of sshd itself against known-good hashes; a replaced or wrapped libpam or sshd is the backdoor's most likely home. Flag unexpected large statically-linked binaries run at authentication time, and โ€” the durable anchor, mirroring the worm's key โ€” scan for the eba3282b571c cgo build hash in any binary touching PAM, which correlates this specific toolkit across its rebuilds exactly as the RSA key correlated the worm across its. And where the resources exist, watch authentication for the anomaly the wiretap cannot hide: a successful root login that matches no credential the host should accept is the magic key being used, and it is the one moment the silent backdoor makes a sound.

The asymmetry between the two hunts is the practical takeaway. The worm's countermeasure is a firewall rule a home user can deploy in a minute; the PAM backdoor's requires file-integrity monitoring, package verification, and PAM-stack auditing that the conscripted-victim population of Part 5 will never run. The silent, sophisticated threat is not only harder to catch โ€” it is specifically out of reach of exactly the under-defended hosts it most quietly owns. Which is why, on the cheap-Linux battlefield, the loud worm is the one that gets found and banned, while the quiet wiretap keeps listening.

What holds, and what is bounded

What holds, first-party: the persist-corner cluster's composition (roughly eighteen samples), the compiled binaries' Go-1.24 provenance and their cgo-libpam authentication hooks (pam_chauthtok, pam_setcred, cbPAMConv, etc.), the modern encrypted-networking strings (chacha20, sha3, HTTP/2), and the shared cgo build hash eba3282b571c across at least two members โ€” all read directly from the honeypot's retained samples.

What is inference, not first-party proof: the behaviours of credential-harvesting and magic-password backdooring are the standard, well-established purpose of malicious PAM modules with exactly these hooks, and are consistent with the classifier's credential manipulator and backdoor labels โ€” but this letter did not extract from the string set the specific hardcoded magic password or the specific exfiltration endpoint. That those exist is a strong inference from the mechanism and the family; their exact values are a bounded gap this analysis did not close.

What is emphatically not claimed โ€” the separateness: nothing here ties the PAM toolkit to the Raspberry Worm's operator, to its infrastructure, or even to the same physical victim hosts. The two share a honeypot, a time window, and a target population (cheap Linux devices) โ€” nothing more that this investigation can demonstrate. The cgo hash correlates the PAM binaries to each other; it does not correlate them to the worm, which carries no such artifact and is not written in Go at all. This letter belongs to the series only as a survey of the ecosystem the worm inhabits โ€” the persist corner of Part 6's three-cornered market โ€” and its central claim is precisely that this corner is a different operation. To read it as "part of the worm" would be the exact conflation the whole series has worked to avoid.

Core IOCs

Cross-references

The worm this series is named for is a crude, loud, twenty-year-old idea executed in bash, and it works by being everywhere. On the very same forgotten devices, one at a time and in silence, sits its opposite: a modern compiled implant that owns the one thing every login must pass through, takes what flows past, and leaves the owner's password working so nothing ever seems wrong. They are not the same threat, and confusing them would be a mistake โ€” but they are the same victims, contested at once from both ends of the craft. The clearest lesson of the whole series may be this last one: the cheapest, most-forgotten Linux device on the internet is not fought over by one enemy but by a market โ€” and understanding what has happened to such a host means asking not "which malware is this?" but "which corner of the market got here first, and which one is still listening."

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