🔀 Part II — Three Fingerprints, One Operator

Each libssh version negotiates SSH key exchange and ciphers in a different default order. This ordering is encoded in the HASSH fingerprint — an MD5 hash of the client's key exchange init message. Different library version = different HASSH:

This has a direct defensive consequence. A network defender who identifies HASSH f555226d as malicious and blocks it has addressed only 18% of the swarm. The other 82% — running different versions with different fingerprints — passes through undetected.

This is the network-scanning equivalent of polymorphism: same payload, same operator, same targets — but three different signatures. The cost of running three versions (deployment complexity, configuration management, multiple build pipelines) is the price of making single-fingerprint detection useless.

🔒 Part III — The Operator's Own Vulnerabilities

Here is the counterintuitive finding: the swarm's version choices make the operator vulnerable, not just the targets.

The operator accepts these risks because:

1. Patching changes the HASSH. Upgrading 0.9.6 to 0.10.x would change the fingerprint, invalidating any defender's classification of the old signature — but also losing the established identity. The operator has decided that fingerprint stability is worth more than fixing their own MitM exposure.
2. The targets are commodity SSH servers. The swarm connects to random SSH endpoints, not adversarial honeypots (usually). The probability of encountering a server that exploits CVE-2023-2283 against the scanner is low in the wild.
3. The data has low per-unit value. Each compromised credential is one of thousands. Losing some to a MitM attacker doesn't threaten the operation.

📊 Part IV — What the Success Rates Reveal

The success rates are inversely correlated with version newness:

The oldest fleet is the most effective. Three possible explanations:

• Strategy differentiation. The 0.9.6 fleet is classified as "botnet" — it may use more selective targeting (pre-screened vulnerable hosts). The 0.11.x and 0.12.0 fleets are "scanner" — they spray more broadly with lower yield.
• Operational maturity. The 0.9.6 fleet has been running longest — its target lists may have been refined through iteration. The newer fleets are still in their initial spray phase.
• The 0.12.0 anomaly. The newest fleet has 43.1 attempts per IP — 28% more than the other two at 33.8. More attempts per node could mean more aggressive scanning parameters, different target lists, or the operator testing a new configuration.

🧬 Part V — Why libssh? The Technical Case

With dozens of SSH libraries available — OpenSSH, Paramiko (Python), Go_SSH (Go), libssh2 (C), Dropbear — why does this operation standardize on libssh?

libssh wins on three criteria that matter for mass deployment:

1. Minimal footprint. A C library with no runtime dependencies beyond libc and OpenSSL/mbedTLS. Each scanner node needs minimal RAM.
2. Embeddable. libssh can be linked into a custom binary — the operator compiles a purpose-built scanner, not a script that imports a library.
3. Deterministic HASSH. Because libssh handles key exchange directly (no OS SSH client involvement), the operator controls exactly what fingerprint the scanner presents.

🔗 Related & Coming Next

Sources: NVD (NIST) · Cowrie honeypot · HASSH fingerprints · libssh project · campaign dossiers · TI-2026-049A/B/C · TI-2026-008
Investigation: TI-2026-049D · 8 evidence · 3 actors · 6 findings · 5 connections · 5 infrastructure
Confidence: HIGH — NVD CVE records + observed HASSH fingerprints + campaign statistics
Classification: TLP:WHITE