The Other Swarm

While we spent six letters dissecting the libssh swarm — 2,341 IPs, 84 countries, three library versions braided into one organism — something else was scanning alongside it. Something quieter. Something better at its job.

The Go_SSH fleet appears in the same observation window as the libssh swarm. Same target space: internet-facing SSH servers. Same observation period: spring 2026. Same honeypot catching both. But where the libssh swarm is industrial — massive, noisy, firing 84,726 attempts to achieve 90 successes — the Go_SSH fleet operates differently. 320 IPs. 7,115 attempts. 333 successes.

That success rate — 4.68% — is forty-four times higher than the libssh swarm's 0.11%.

This is not a difference in degree. It is a difference in kind.

I. The Fingerprint

Every SSH client announces itself through its handshake — the key exchange algorithms it offers, the ciphers it supports, the MAC and compression methods it proposes. The HASSH algorithm hashes these parameters into a single fingerprint, an unforgeable signature of the software at the other end of the connection.

Go is not a scripting language. You don't write Go SSH scanners casually. The x/crypto/ssh package is part of Go's extended standard library — maintained by the Go team at Google, reviewed, tested, production-grade. Choosing Go for a scanner is a deliberate engineering decision. It says: the person who built this tool thinks about deployment, about binary distribution, about concurrent I/O at scale. They think about goroutines — Go's lightweight threads that let a single process manage thousands of simultaneous SSH connections with minimal memory overhead.

Compare this with libssh. The C library. Lower-level, more flexible, but requiring compilation against system libraries, managing memory manually, linking against OpenSSL or GnuTLS. The libssh operator distributes scanners as compiled binaries for specific architectures. The Go_SSH operator distributes a single static binary that runs anywhere.

II. The Numbers That Don't Lie

Strip away interpretation. Look at the raw comparison.

Read across each row. The Go_SSH fleet is smaller on every dimension except the one that matters: successful compromises. It gets 3.7 times more shells with 12 times fewer attempts from 7 times fewer IPs.

The libssh swarm is a firehose. The Go_SSH fleet is a rifle.

What 44× Means

A 44-fold difference in success rate demands explanation. Four hypotheses:

The evidence supports a combination. The infrastructure profile (next section) suggests Hypothesis 4 — this is a professional operation, not a mass campaign. But Hypotheses 1 and 2 likely contribute: better targeting and better credentials are the how of that professionalism.

III. The Infrastructure Tells the Story

Where you rent your servers reveals who you are. Or at least, who your procurement department is.

The pattern is stark. The Go_SSH operator buys European VPS — 60 of 320 IPs (19%) sit on German hosting alone (Contabo, Hetzner, IONOS). Add DigitalOcean and you have 107 IPs (33%) on four Western providers. These are the €5-10/month servers that any developer can provision with a credit card and an email address.

The libssh operator inhabits a different world entirely. Aceville Pte Ltd (Singapore), ByteDance/Volcano Engine (China), UCloud (Hong Kong) — Asian cloud platforms with different payment systems, different abuse-handling cultures, different jurisdictions. The libssh swarm's infrastructure screams East Asian cloud procurement.

The German Preference

Contabo, Hetzner, IONOS — three German hosting providers hosting 60 Go_SSH nodes. Germany offers a specific value proposition for illicit scanning: strong privacy laws (GDPR/BDSG), historically slow abuse response from budget providers, and excellent network connectivity to the rest of Europe. Contabo in particular is known for providing remarkably cheap VPS (€4.99/month for a capable instance) with minimal verification. It's the infrastructure of choice for operators who need disposable compute.

Not a single Contabo, Hetzner, or IONOS IP appears in the libssh campaigns. This infrastructure is exclusive to Go_SSH.

IV. Zero Overlap

We cross-referenced every Go_SSH IP against every libssh IP across all three campaigns (0.9.6, 0.11.x, 0.12.0). The result:

Zero. Not one IP appears in both ecosystems. Combined with the absence of a shared actor cluster (the automated attribution system found no link), different HASSH fingerprints (different software), and opposing geographic preferences (Europe vs. Asia), the evidence is unambiguous: the Go_SSH fleet and the libssh swarm are operationally independent.

They are competitors, not collaborators. They fish in the same ocean but dock at different ports.

The Coincident End Date

Both ecosystems went quiet around May 20-21, 2026. Go_SSH started March 24. libssh started March 28. Both stopped within 24 hours of each other, eight weeks later.

Three explanations:

1. Coincidence. Two months is a natural scanning campaign lifecycle. Infrastructure gets flagged, abuse reports accumulate, blocklists catch up. Both operators hit the same diminishing-returns threshold independently.

2. Shared target exhaustion. If both operators are scanning the same target list (the internet's SSH servers), they might exhaust accessible targets at roughly the same rate. The target space is finite; two predators deplete the same prey population.

3. External event. A major hosting provider crackdown, a law enforcement operation, or a significant blocklist update could disrupt both ecosystems simultaneously — even though they use different infrastructure — if the disruption targeted the target side rather than the source side.

We don't know which. The coincidence is noted. The investigation continues.

V. The Ecosystem Map

Go_SSH and libssh are not alone. The honeypot identifies at least six distinct SSH scanning ecosystems operating simultaneously in the same observation window. Each has its own HASSH fingerprint, its own infrastructure, its own operator.

Six ecosystems. Three confirmed actor clusters. Three unattributed operators. The total landscape: 3,464+ IPs from at least six different organizations scanning SSH simultaneously.

The Success Rate Spectrum

The six ecosystems arrange themselves along a spectrum from mass scanning to precision targeting:

The spectrum reveals the division of labor in the SSH threat ecosystem. At the bottom, libssh2 maps the terrain — which ports respond, which services run. Above it, the libssh swarm performs mass credential testing at industrial scale. Go_SSH operates more efficiently in the middle. AsyncSSH runs a concentrated operation from a single country. At the top, Paramiko and go_scanner target only hosts they know they can access — working from pre-validated credential lists.

This isn't chaos. This is specialization.

VI. The First Four Days

Go_SSH appeared on March 24, 2026. The libssh swarm's first component (0.11.x) appeared four days later on March 28.

Four days is not much. But in scanning operations, four days is meaningful. A scanner that starts first has first-mover advantage: it reaches default-credential hosts before they're compromised (or patched) by competitors. The hosts that accept root:password on Monday may have their password changed by Thursday — by the first attacker who got in.

Go_SSH's higher success rate may be partly explained by timing: it reached some fraction of targets while they were still pristine. By the time the libssh swarm's 2,341 nodes began their 84,726 attempts, the easy targets were already taken — claimed by Go_SSH's 320 precision scanners.

VII. The Third Actor

The libssh2 fleet (HASSH 14b2ddda386a4d10) deserves special attention. 628 IPs — larger than Go_SSH — across 48 countries. 16,253 connection attempts. Zero successes.

Zero is not failure. Zero is the intended outcome.

The libssh2 fleet never sends credentials. It connects, completes the SSH handshake to identify the server's software, algorithms, and capabilities — then disconnects. This is pure service enumeration. The output is not compromised hosts but intelligence: a database of every SSH server that responded, what version it runs, what algorithms it supports, what it reveals about itself.

This intelligence has value. To the libssh2 operator, obviously — it informs their own future operations. But also to others. A curated list of SSH servers with their version strings and supported algorithms is a product. It can be sold, traded, or used to build targeted credential lists.

The three confirmed actor clusters — actor-6285990cc704 (libssh), actor-0d9fdff8bb3d (libssh2), and the unattributed Go_SSH operator — form a triad. Scanner, mapper, and precision striker. Whether they collaborate or merely coexist, their combined effect is a comprehensive assault on the SSH ecosystem.

VIII. What Go Reveals

The choice of Go tells us about the operator's background. Go is not a language you learn in a hacking forum. It's a language you learn in a DevOps team, a cloud infrastructure company, a software engineering organization. Go's adoption profile is professional: Kubernetes, Docker, Terraform, Prometheus — all written in Go. The people who write Go SSH scanners are the same people who write cloud infrastructure tools.

This means the Go_SSH operator is likely:

• A professional software developer with experience in cloud infrastructure. Not a script kiddie adapting downloaded tools, but someone who designs, compiles, and deploys custom scanning software.

• Familiar with DevOps workflows. The choice of static binaries, European VPS, and efficient scanning patterns suggests someone who thinks in terms of deployment pipelines, infrastructure-as-code, and operational efficiency.

• Operating as a business. The precision of the operation — fewer IPs, higher success, European infrastructure — suggests someone minimizing costs while maximizing returns. This is not ideology or curiosity. This is economics.

IX. The Thread Forward

This letter maps the terrain. Six scanning ecosystems. Three known actors. One unattributed operator running Go-compiled precision scanners from German VPS providers with a success rate 44 times higher than the largest swarm.

The next letter drills into what the Go_SSH fleet does after it gets in. 333 successes means 333 post-authentication sessions. What commands run after the shell opens? What gets downloaded? What gets exfiltrated? The credential testing is the front door. The command sequences are the floor plan.

The libssh swarm had two command families — the 19-command reconnaissance script and the sentinel-download sequence. Does Go_SSH show the same patterns? Different ones? Or something entirely new?

333 shells. 333 stories. Letter B opens them.