TI-2026-015B — Echo BMOK Revisited: The Fingerprint That Spread

Classification: HIGH · Forensic threat intelligence · Honeypot-derived · Published 2026-07-07 · Series: Honeypot Field Reports

TI-2026-015 "Echo BMOK" closed on 2026-05-25 with a clean identifier: a threat actor whose SSH client announced OpenSSH 10.0p2 on Debian 13 (Trixie) — a bleeding-edge OS released in 2025 — producing HASSH eeca2460550b9ded084ecf2f70a75356, a fingerprint that existed on exactly two IPs in a database of 5,300+ attackers. The dossier called it "a near-perfect unique identifier for this operator." Six weeks later, that prediction can be tested: the identifier is now on four IPs, two of them joined after the dossier published, and the new nodes answer a question the original could not — is the fingerprint real, or spoofed? This part re-opens the case with the evidence that has since arrived.

1. The Cluster, Then and Now

The HASSH eeca2460 cluster, full history (2026-05-11 → 2026-06-16, 325 sessions):

The original dossier documented the Indonesia→Germany pair. The two US nodes appeared after publication — 193.31.31.234 two weeks later, 159.203.66.5 three weeks later. The near-unique identifier did exactly what a good identifier should: it kept identifying the operator as they moved onto new infrastructure. The rarity of the fingerprint (almost nobody runs Debian 13 Trixie's OpenSSH build) is what made the continuity legible.

Every node in the cluster shares the operator's signatures from the original investigation: the pi:raspberry credential (393 attempts across all four IPs — the Raspberry Pi default that defines BMOK), and the echo BMOK callback beacon (278 executions from the Indonesian primary), a marker the operator echoes to confirm command execution on a live host.

2. The Fingerprint Is Real — and Portable

The open question TI-2026-015 could not settle: was OpenSSH_10.0p2 Debian-7+deb13u2 a genuine client, or a spoofed banner (the trick documented later in TI-2026-057C "The Handshake Doesn't Lie")? The two new nodes answer it — and the answer is more interesting than either option alone.

193.31.31.234 — the operator's own box. The banner is authentic. Shodan sees its listening services directly:

The host that attacks as OpenSSH 10.0p2 Debian genuinely runs OpenSSH 10.0p2 on Debian, with Python 3.13.5 — a matched, current toolchain. This is not a spoof. It is a real Debian 13 Trixie machine, almost certainly the operator's own VPS (SPARKED HOST, a US gaming/VPS provider), with an open directory on :9999 — the kind of thing operators use to stage payloads.

159.203.66.5 — a hijacked box. The banner travelled. Its own Shodan profile is the opposite:

This node's own server is an ancient, unpatched Ubuntu box running Apache 2.4.7 and OpenSSH 6.6.1p1 — a real business host (samimetrics.com) riddled with a decade of vulnerabilities. Yet when it attacked the honeypot, it announced the identical OpenSSH_10.0p2 Debian-7+deb13u2 client and produced HASSH eeca2460. The fingerprint cannot have come from the host; it came from the operator's tooling, carried onto a compromised legitimate machine and run from there.

That is the finding. The eeca2460 fingerprint is not a property of any one host — it is the property of a portable client the operator carries, which is why it survives the jump from the operator's own Debian 13 VPS to a hijacked Ubuntu victim. A near-unique OS becomes a near-perfect tool-fingerprint precisely because the operator brings it with them.

3. The Operator Learned Our Name

The credential set evolved, and the evolution is a tell. Alongside the constant pi:raspberry, the cluster now tries passwords built from the honeypot's own public domain, shuffle-on.com:

The tokens shuffle and on are the two halves of shuffle-on, permuted with year suffixes and punctuation. This is targeted credential generation — the operator (or its tooling) derived a custom wordlist from the target's domain name rather than firing a static default list. Layered on top are financially-motivated guesses (bitcoin:bitcoin, bitcoind:bitcoind!@#, postgres:postgres!!!, walrus:walrus!!!), consistent with the operator's post-access behaviour (see §4).

Targeted credential generation raises the sophistication ceiling of this actor above the commodity brute-forcers elsewhere in the corpus. Most scanners do not know or care what domain they hit; this one did.

4. What It Does Inside — and How It Checks for Us

Once authenticated, the cluster runs a deep, purposeful recon that confirms its motive and its caution. Three themes stand out from the captured command set:

• Cryptocurrency theft. It hunts wallets and keys explicitly: find … wallet.dat, keystore, *.keystore, wallet.json, mnemonic*, seed*, private.key, *.pem, plus .env/secrets files and SSH private keys (id_rsa, id_ed25519, authorized_keys). The bitcoin/bitcoind credential guesses in §3 are the same motive from the front door.
• Persistence and lateral reach. It enumerates systemctl running/enabled units, crontab (user and sudo), /etc/cron.d/, Docker containers and docker-compose.yml, and harvests SSH keys and known_hosts — the raw material for pivoting to the victim's other machines.
• Honeypot awareness. Most striking, it actively checks whether it has landed in a trap: grep '^phil:' /etc/passwd && echo HONEYPOT_USER_PHIL; ps waux | grep -E 'cowrie|kippo|dionaea|honeytrap|opencanary|glutton|heralding'; ls -d /etc/cowrie /opt/cowrie /var/log/cowrie; and a check whether /bin/ls, /bin/cat are suspiciously sized fake binaries. The reference to user phil — a name it also ls'd under /home/phil/ — indicates cross-victim memory: the operator has seen a "phil" before and now screens for it as a honeypot tell.

An operator that fingerprints its landing zone for cowrie is not a spray-and-pray botnet. It is a hands-on-tooling actor that expects some of its targets to be traps and wants to abandon them before revealing more — which is itself the reason the honeypot captured so much of the recon and comparatively little follow-through.

5. Alternative Interpretation

Steelman: "Four IPs sharing a rare banner is not a campaign — Debian 13 Trixie shipped a specific OpenSSH build, and anyone who installed it produces the same version string and the same HASSH. The two US nodes could be unrelated operators who happen to run the same fresh OS. And Shodan proves nothing about intent."

Why the same-operator reading is HIGH confidence:

• It is never the banner alone. The four nodes share a stack of signatures: HASSH eeca2460, the pi:raspberry credential (393×), the echo BMOK beacon, an identical recon command family (wallet-hunt + honeypot-check), and the shuffle-on-derived targeted passwords. A shared OS explains the banner; it does not explain a target-specific wordlist and a shared beacon string. That composite is one campaign.
• The spread is temporally coherent with the original. The two US nodes did not appear randomly — they continue the same operator's activity in the weeks after the Indonesia/Germany pair, with the same behaviour, exactly as infrastructure rotation looks.
• Authenticity is independently corroborated. 193.31.31.234 runs OpenSSH 10.0p2 + Python 3.13.5 on Debian per Shodan — an external source the operator does not control. The fingerprint is real, not a SSH-2.0-OpenSSH_7.4-style spoof.

What is bounded: whether this is one individual or a small team sharing tooling is not resolvable from honeypot data (MEDIUM). And 159.203.66.5 (samimetrics.com) is best read as a compromised third party — a victim relaying the operator's tool — not a knowing participant; it should be notified, not blocklisted as hostile infrastructure.

Confidence: HIGH — that the four nodes are one BMOK campaign, that the OpenSSH 10.0p2 fingerprint is authentic and portable across hosts, and that the operator performs targeted credential generation and honeypot-aware recon. MEDIUM on operator singularity.

6. Defense Response

• The fingerprint is a gift — use it as an IOC. HASSH eeca2460550b9ded084ecf2f70a75356 (client SSH-2.0-OpenSSH_10.0p2 Debian-7+deb13u2), paired with a pi:raspberry login or an echo BMOK command, is a near-zero-false-positive detection for this operator regardless of source IP. Its rarity is the defender's advantage.
• Block the hostile nodes; notify the victim. Blocklist 103.24.212.42, 5.182.204.221, 193.31.31.234 (SPARKED HOST — the operator's staging VPS with an open :9999 directory). Treat 159.203.66.5 / samimetrics.com as compromised and route an abuse notice to DigitalOcean, not a permanent ban of an ordinary business host.
• Targeted credentials mean generic policies are not enough. This actor built passwords from shuffle-on. Any credential derived from your own domain, brand, or year must be impossible — enforce key-based SSH and reject password auth entirely; pi:raspberry and shuffle2026!!! should never authenticate.
• Honeypot-awareness cuts both ways. Because the operator screens for cowrie artefacts (/etc/cowrie, user phil, fake-binary sizes), a well-camouflaged sensor captures more of this actor's tooling than a default one. Hardening the honeypot's tells is, here, an intelligence-collection upgrade.

7. Investigation Metadata

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