HASSH is the MD5 hash of the SSH client's KEX-algorithm preference list — a deterministic toolkit fingerprint that varies by SSH library version. Our honeypot's session-fingerprint table groups every connection by HASSH. Two clusters dominate the dataset:

The HASSHes differ because the libssh 0.11→0.12 release re-ordered KEX algorithms. Everything else about the toolkits is identical — including the post-authentication behavior, which makes attribution unambiguous.

1. Cross-family pivot IPs

Two IPs appear in both HASSH families with identical post-authentication behavior:

• 91.99.110.230 — Hetzner DE, AS24940. Ran identical 8-command recon across both Family A and Family B sessions. Downloaded the same sha256 sentinel in both contexts.
• 94.232.41.236 — RocketCloud (RU/KG), AS64439. Top attacker in both families' top-10 (by login-attempt volume). Same target dictionary, same session pattern.

Two independent infrastructure pivots is enough on its own to rule out coincidence. One node could be a false-positive cross-overlap. Two nodes running both libssh versions, on completely different ASNs and continents, with identical behavior — that's tooling reuse, not coincidence.

2. Byte-identical 8-command recon block

For every authenticated session in either family, the operator's tool runs exactly this 8-command sequence in this order — no deviation, no interactive activity follows:

whoami
which ls
w
uname -m
uname -a
uname
top
lscpu | grep Model

Sessions average 1.5–3 seconds. No chmod +x, no crontab, no ~/.ssh/authorized_keys writes. This is a behavioral fingerprint stronger than HASSH itself: the network fingerprint changes every time libssh ships a new release; the command sequence does not change unless the operator rebuilds their tool.

3. Shared sentinel payloads

Two sha256 hashes are downloaded across both families immediately after authentication. Neither is malware:

Operators use sentinel downloads to verify their exfil channel works (does wget reach the C2? is outbound HTTP open? is there a captive-portal blocking traffic?) before shipping the second-stage payload. The fact that we see "Hello World!" being downloaded — a literal CI/CD test fixture — and nothing else means we are observing the operator's pre-deployment checkout, not the actual campaign. When the sentinel sha256 flips to an unknown blob, the campaign has gone live.

Both families share the same target list and password dictionary (sample of 600 of 1,650 member IPs):

Top 10 passwords account for ~70% of all attempts. No targeted credential-stuffing, no leaked-database tests, no SSH-key auth attempts. Pure dictionary brute force against the standard root/ubuntu/admin trinity. This is not a sophisticated targeting operation — it is reach maximization.

The two families share 65 of their top-100 ASNs. The set is dominated by major commercial cloud providers — Microsoft Azure, Tencent, UCloud, OVH, IONOS, Hetzner. This operator is renting and burning short-lived cloud-VPS instances at scale, not using a residential or compromised-IoT botnet. Different operational economics, different takedown profile.

Full live IOC bundle (1,650+ IPs, all observed sentinels, every HASSH attribution) is reproducible from the SOC platform — see Methodology below for the live URLs. The samples here are illustrative of the campaign's spread.

🔁 = IP appears in both family clusters. Cross-family pivots are the strongest infrastructure-level attribution signal in the bundle.

Equally important to what they are doing:

• No persistence. No chmod +x, no crontab, no rc.local edits, no systemd unit drops, no ~/.ssh/authorized_keys writes. Sessions average 1.5–3 seconds.
• No live malware deployment. The two sha256s observed are smoke-test fixtures, not malware. The operator is in a testing or pre-deployment posture.
• No targeted credentials. No SSH-key auth attempts. No certificate stuffing. Pure dictionary brute force against the universal root/ubuntu trinity.
• No lateral movement. No ssh-keygen, no ~/.ssh/authorized_keys reads, no ~/.bash_history exfil.

Interpretation: this is scanner-development traffic or a toolkit operator validating reach. They've built a 1,650-node distributed scanner using libssh (rather than OpenSSH or pure-Python paramiko) and they're stress-testing it. The real campaign — when the sentinel sha256 changes to actual malware — will signal go-live.

1. HASSH-based blocklist at the SSH gateway. Block any inbound SSH session whose KEX-list MD5 matches either 03a80b21afa810682a776a7d42e5e6fb or af8223ac9914f509afdadfaf5f7ee94e. False-positive risk is low — libssh is rare for interactive SSH; most legitimate clients are OpenSSH-based with different HASSHes.
2. Banner-string match. SSH-2.0-libssh_0.11.1 and SSH-2.0-libssh_0.12.0 on inbound connections to your management plane should be flagged regardless of authentication outcome.
3. Recon-sequence regex on TTY/audit log. The 8-command sequence is byte-deterministic. The pattern whoami; which ls; w; uname -m; uname -a; uname; top; lscpu within 2 seconds of a session opening is the strongest behavioral signal — an order of magnitude harder for the operator to randomize than the network fingerprint.
4. DNS / outbound monitoring for sentinel exfil paths. Look for outbound HTTP/HTTPS to fresh infrastructure within seconds of a successful SSH auth — the operator is testing exactly this primitive. The two sha256 fixtures are non-malicious, so don't use them as a malware indicator; instead detect the pattern of post-auth fetch.

All data is post-rebuild (commit 0d20547, 2026-05-02), so cowrie events from 2026-03-21 onward are complete (a previous 14-day backfill gap masked Family A's first three weeks). Fingerprint extraction (commit 360372f) populates session_fingerprints from cowrie's cowrie.client.kex events; HASSH itself is computed by cowrie, not derived. WHOIS / ASN / BGP-prefix attribution comes from Team Cymru bulk WHOIS over whois.cymru.com:43, no auth required.

Cluster expansion was performed entirely through SOC API endpoints — /api/honeypot2/fingerprints, /similar, /ip/{ip}, /downloads, /timeline_bucket. No privileged DB access. The same intelligence is reproducible from any client with read access to the honeypot. Operators (and analysts) who want the full live IOC bundle can query the SOC platform at the URLs below — the published JSON / CSV / AbuseIPDB-format bundles are regenerated on every request and reflect the current honeypot state.