The Handshake Doesn't Lie

Summary

Two IP addresses — 89.248.168.227 (NL, AS202425) and 77.246.159.182 (RU, AS29182) — share an identical SSH client fingerprint: HASSH c39f4cec145ee3d50fb590595143b9d5. The NL node declares SSH-2.0-Go; the RU node declares SSH-2.0-OpenSSH_7.4. Both produce the same HASSH. The version string from the RU node is a spoof. Both nodes run the same Go-based SSH client. The HASSH is unclassified — it does not match any of the 68 known SSH client signatures in the honeypot database, including the three known Go-based scanner fingerprints. The client is private or custom-built.

Section 1 — What HASSH Is and Why It Cannot Be Spoofed

HASSH (Hash of All SSH Handshake) is a client fingerprinting method that operates at the library level of the SSH protocol stack, not at the identification layer. To understand why it is resistant to banner spoofing, the SSH connection sequence must be examined at the protocol level.

The Two Protocol Phases

┌─────────────────────────────────────────────────────────────────┐
│  PHASE 1 — Protocol Identification (RFC 4253 §4.2)              │
│  ─────────────────────────────────────────────────              │
│  Timing:    Immediately after TCP connection establishment       │
│  Direction: Both parties send simultaneously                     │
│  Content:   Plaintext string: SSH-protoversion-softwareversion   │
│                                                                  │
│  Examples:                                                       │
│    SSH-2.0-OpenSSH_7.4   ← declared by 77.246.159.182 (lie)    │
│    SSH-2.0-Go             ← declared by 89.248.168.227 (truth)  │
│                                                                  │
│  Authentication: NONE. Self-declared. Unverified by protocol.   │
│  Forensic value: VERY LOW — trivially falsifiable               │
├─────────────────────────────────────────────────────────────────┤
│  PHASE 2 — Key Exchange Initialization (RFC 4253 §7.1)          │
│  ─────────────────────────────────────────────────              │
│  Timing:    Immediately after Phase 1                            │
│  Direction: Both parties send SSH_MSG_KEXINIT packets            │
│  Content:   Ordered algorithm preference lists from SSH library  │
│                                                                  │
│  Fields captured in HASSH computation:                           │
│    [1] kex_algorithms                                            │
│    [2] encryption_algorithms_client_to_server                   │
│    [3] mac_algorithms_client_to_server                          │
│    [4] compression_algorithms_client_to_server                  │
│                                                                  │
│  These are set by the SSH LIBRARY compiled-in defaults           │
│  — not by any configuration the banner string can influence.    │
│  Forensic value: HIGH — library-level, not operator-configurable │
└─────────────────────────────────────────────────────────────────┘

KEY STRUCTURAL SEPARATION:
  Phase 1 (banner) ─── operator-controlled string ──→ FALSIFIABLE
  Phase 2 (HASSH)  ─── library-compiled defaults  ──→ NOT falsifiable
                        without recompiling the library

How HASSH Is Computed

Step 1: Client sends SSH_MSG_KEXINIT during Phase 2

  kex_algorithms              = "curve25519-sha256,ecdh-sha2-nistp256,
                                  diffie-hellman-group14-sha256,..."
  encryption_algs_client→srv  = "chacha20-poly1305@openssh.com,
                                  aes128-ctr,aes256-ctr,..."
  mac_algs_client→server      = "hmac-sha2-256-etm@openssh.com,
                                  hmac-sha1,..."
  compression_algs_client→srv = "none,zlib@openssh.com"

Step 2: Concatenate four lists with semicolons

  "curve25519-sha256,...;chacha20-poly1305@openssh.com,...;
   hmac-sha2-256-etm,...;none,..."

Step 3: Compute MD5

  MD5(concatenated_string) = c39f4cec145ee3d50fb590595143b9d5

         ╔════════════════════════════════════╗
         ║  HASSH = MD5(alg_list_concat)      ║
         ║  Source: SSH library compiled code ║
         ╚════════════════════════════════════╝

The algorithm lists and their ordering are set at compile time
in the SSH library. Changing the banner string in Phase 1 has
zero effect on the algorithm lists transmitted in Phase 2.

To change the HASSH, an operator must:
  (1) Recompile the SSH library with different algorithm defaults, OR
  (2) Programmatically override algorithm preferences at runtime, OR
  (3) Switch to a different SSH library entirely

None of these is achievable by banner string modification alone.

Forensic Meaning of HASSH Identity

When two observed connections share an identical HASSH, it establishes that both connections originated from the same SSH library build — same language, same library, same compiled defaults. This is a property of the implementation, not of the operator's runtime choices. Different SSH implementations produce structurally different HMACs:

The central forensic claim: same HASSH equals same SSH client code. It does not establish same operator, same machine, or same campaign with certainty — but it establishes same toolkit at the library level with high confidence.

Section 2 — The Fingerprint: c39f4cec145ee3d50fb590595143b9d5

Direct Observations

The hash c39f4cec145ee3d50fb590595143b9d5 was observed on exactly two IPs in the honeypot database:

The NL node declares SSH-2.0-Go, which is consistent with a Go SSH client. The HASSH corroborates this honest declaration. The RU node declares SSH-2.0-OpenSSH_7.4, which the HASSH directly contradicts. Both produce the identical fingerprint, meaning the same Go-based library produced both connections regardless of what the banner claims.

Population Context: Three Known Go SSH Scanners in the Honeypot Database

The honeypot fingerprint database contains 68 total SSH client signatures. Three of those belong to known Go-based SSH scanners. Comparing c39f4cec against those three reveals critical isolation:

Commodity Go SSH scanners (publicly distributed tools):
  go_scanner    (2aec6b44) ████████████████████████████████  303 IPs
  Go_SSH        (16443846) ████████████████████████████████  320 IPs
  go_scanner v2 (e54ef3ec) ██                                 18 IPs

This investigation:
  UNKNOWN       (c39f4cec) ▌                                   2 IPs

Interpretation:
  Widely distributed scanner packages accumulate hundreds of hits.
  Many actors deploy the same commodity tool across many IPs.
  A count of 2 is inconsistent with public distribution.
  
  The most parsimonious explanation:
    → A private or custom-built Go SSH client
    → Purpose-built for this actor's specific use case
    → Not publicly released or distributed widely
    → The algorithm preferences differ from all three known Go scanners
       (distinct MD5 values = distinct algorithm list contents)

What "Unclassified" Means

The honeypot database records a tool_name field when a HASSH is matched against known signatures. For c39f4cec145ee3d50fb590595143b9d5, this field is empty. This means:

• The hash does not appear in any public signature database used to populate tool classifications
• It is not a variant of the three known Go scanner HMACs — the MD5 values are distinct, meaning the underlying algorithm preference lists differ at the content level
• No previous investigation or automated classification pipeline has assigned a tool name to it

The population size (2 IPs) is consistent with a purpose-built tool used by a small number of nodes, as opposed to a widely distributed scanner package which would typically accumulate hundreds of hits from indiscriminate deployment across multiple actors.

Section 3 — The Banner Spoofing Case

77.246.159.182 presents SSH-2.0-OpenSSH_7.4 as its version string on every SSH connection it initiates. The HASSH produced by the same IP is c39f4cec145ee3d50fb590595143b9d5 — identical to the HASSH from 89.248.168.227, which declares SSH-2.0-Go.

A genuine OpenSSH 7.4 client would produce an OpenSSH-characteristic HASSH reflecting OpenSSH 7.4's algorithm preferences and ordering. It would not produce a Go SSH library HASSH. The two are structurally different because they originate from different language ecosystems with different compiled defaults. The conclusion is unambiguous: 77.246.159.182 is running a Go SSH client with a forged banner string.

Why OpenSSH 7.4 Specifically

OpenSSH 7.4 was released December 2016 and remained a common deployment through 2017–2020 across RHEL/CentOS 7 and Debian Stretch systems. This specific selection is not arbitrary:

The selection implies the operator understands how version strings are evaluated by defenders and honeypot operators. They chose a version that reads as plausible internal tooling rather than an active scanning tool. This is operational security awareness, not a default configuration.

What the Operator Knows — and May Not Know

WHAT THE OPERATOR DEMONSTRABLY KNOWS:
  ✓ SSH banners are logged and analyzed by defenders
  ✓ Declaring SSH-2.0-Go attracts classification as a scanner tool
  ✓ SSH-2.0-OpenSSH_7.4 reads as a legitimate, if old, server
  ✓ How to modify a Go SSH client to substitute the identification string
  ✓ Which version string is sufficiently plausible to avoid suspicion

WHAT THE OPERATOR MAY NOT KNOW (or assessed as acceptable risk):
  ? That HASSH fingerprinting exists as a parallel identification layer
  ? That honeypots with HASSH collection will detect the contradiction
  ? That the HASSH links both IPs to the same toolkit regardless of banner

CONSEQUENCE:
  The banner spoofing works against:   → banner-matching blocklists
                                       → IDS version-string signatures
                                       → analyst first-pass on version strings

  The banner spoofing fails against:   → HASSH-aware honeypots
                                       → library-fingerprint analysis
                                       → cross-IP HASSH correlation

  The banner is the lie.
  The HASSH is the evidence.

NL Node vs. RU Node: Comparative Portrait

Two nodes sharing a HASSH apply different opsec decisions at different protocol layers. This divergence suggests either different operators using the same private tool with independent configurations, or a single operator applying different evasion strategies per node based on targeting environment. Neither interpretation can be confirmed from current evidence.

Section 4 — Bidirectional Similarity Confirmation

The honeypot's similarity engine lists 77.246.159.182 and 89.248.168.227 as similar_ips of each other. The relationship is bidirectional: each IP appears in the other's similar_ips record. This is system-level confirmation that the engine identified the two IPs as closely related across multiple behavioral and fingerprint signals — independently of and in addition to the HASSH match.

89.248.168.227  →  similar_ips  →  [77.246.159.182, ...]
77.246.159.182  →  similar_ips  →  [89.248.168.227, ...]

─────────────────────────────────────────────────────────────────
UNIDIRECTIONAL (A→B only):
  Occurs when one IP has sparse data.
  Asymmetric scoring can produce a single-direction match.
  Lower confidence. Possible false positive from data sparsity.

BIDIRECTIONAL (A→B AND B→A):
  Both IPs had sufficient data for independent scoring.
  Both scores crossed the similarity threshold independently.
  STRONGER signal. Reduces probability of false positive.

─────────────────────────────────────────────────────────────────
The bidirectional listing was produced by the same system
that maintains the HASSH database — corroboration from a second,
independent similarity calculation aggregating multiple signals.

The similarity engine uses behavioral and fingerprint signals including but not limited to: HASSH, credential sets used (usernames/passwords), command sequences executed in sessions, download URLs and payload hashes, temporal patterns (time-of-day, inter-connection intervals), geographic and network routing attributes, and port scanning sequences. The HASSH being identical is one of the stronger individual signals, because it is library-level and not easily varied between sessions. The bidirectional listing means the total weight of shared signals crossed the threshold from both directions.

Section 5 — Evidential Limits

Forensic discipline requires explicit statement of what the HASSH evidence does not support.

Confidence Assessment