The Silent Handshake

Three hundred and thirty-three shells opened. In three hundred and twenty-one of them, nothing happened.

The Go_SSH fleet authenticates successfully — confirms the password works — and immediately disconnects. No commands. No file downloads. No lateral movement. The session lasts half a second. The connection drops. The next target begins.

This is not exploitation. This is inventory.

The Go_SSH fleet is building a list of doors that open. The question we came here to answer — what happens after the shell opens? — turns out to be the wrong question. For 96.4% of sessions, nothing happens. The shell is the product, not the beginning of the attack. Someone else comes back later.

And when we find who comes back, the investigation breaks open.

I. The Two Phases

Read the architecture. The validation fleet is a swarm of cheap, disposable probes — 318 IPs on European VPS providers that exist only to answer one question per target: does this password work? If an IP gets blocklisted, it costs €5 to replace. The fleet absorbs the abuse reports, the reputation damage, the automated blocks. That's its job.

The reconnaissance nodes are different. Only two IPs. Same /24 block. Same offshore company (TechTies Inc., Seychelles). They never attempt passwords that might fail. They only visit hosts already confirmed accessible by the validation fleet. They carry the expensive payload — the 1,876-character mega-command that profiles the target host. They are protected by the fleet that runs ahead of them.

II. The Mega-Command

1,876 characters. One line. Executed in under a second. This is the entire reconnaissance payload:

Eight data points, collected in under a second, compressed into a single command to minimize session duration. Let's examine each one.

The Compute Census

III. The Honeypot Trap

The last section of the mega-command is the most sophisticated — and the most dangerous to our observation platform.

Two tests. Both run a command that cannot possibly exist: ./xxxxxx (execute a non-existent file in the current directory) and xxxxxx (execute a non-existent command via PATH lookup). The operator doesn't care about the command — they care about the error message.

This is counter-intelligence. The operator assumes some percentage of their validated hosts are honeypots — which is correct, because one of them is ours. The shell fingerprint test allows automated classification: real host → queue for exploitation. Honeypot → discard from inventory. The operator is cleaning their dataset.

IV. The TechTies Bridge

In TI-2026-049F — the final letter of the libssh series — we identified TechTies Inc. as a Seychelles-registered offshore shell company operating 35 IPs within the libssh swarm. AS197170. RDAP registration: techties-mnt. Abuse contact: abuse@tech-ties.net. We called them the "second offshore shell" — a hosting entity that rents infrastructure to scanning operations.

Now TechTies appears again. In a different campaign. With a different tool. Playing a different role.

The analytical question: what does this mean?

Hypothesis A: Shared Hosting Provider

TechTies is a bullet-proof hosting company that rents servers to multiple independent operators. The libssh operator rents 35 scanning nodes. The Go_SSH operator rents 2 recon nodes. They are customers of the same landlord, not divisions of the same organization. The fact that both appear at the same ASN proves nothing more than that both operators shopped at the same store.

Evidence for: TechTies is a registered entity with its own ASN and RDAP records — this is the profile of a hosting company, not a scanning operation. Different operators frequently use the same bullet-proof hosts.

Evidence against: The Go_SSH operator uses TechTies specifically for the command-execution role — the ONLY two IPs (of 320) that run post-auth commands. If TechTies were just another hosting provider, why wouldn't other TechTies IPs appear in the validation fleet?

Hypothesis B: Same Organization, Different Tools

One organization operates both campaigns. They use libssh for mass scanning (the factory) and Go_SSH for precision validation (the boutique). TechTies is their persistent infrastructure — stable, reliable, used for the roles that require operational continuity. The disposable VPS nodes (DigitalOcean, Contabo, Hetzner) are rented and discarded for the credential validation grind.

Evidence for: TechTies plays the exploitation/recon role in BOTH campaigns. The same /24 block (91.92.40.0/24). The same dominant credential (admin:123456). The coincident end date (both campaigns went silent around May 21).

Evidence against: The automated attribution system found no actor cluster link. The HASSH fingerprints are completely different. The infrastructure profiles are geographically opposite. If this were one organization, they maintain remarkably strict operational separation.

Hypothesis C: Access Broker

TechTies operates as an access broker — an entity that validates credentials for multiple scanning operations and sells verified access. The libssh swarm feeds TechTies raw scan results. TechTies validates and profiles the hosts. Then sells the verified, triaged access to buyers. The Go_SSH fleet is either a TechTies-owned operation or a customer.

Evidence for: The two-phase architecture is exactly what an access broker needs: validate credentials at scale (Phase 1), profile hosts to determine their value (Phase 2), then sell the profiled access. GPU-equipped hosts sell for more than IoT devices. High-uptime unmonitored servers sell for more than actively-managed ones.

Evidence against: No direct evidence of sale. The access broker model is inferred from the operational pattern, not observed.

V. The Credential Question

The Go_SSH fleet's most successful credential is admin:123456 — the same pair that dominates the libssh swarm's attack dictionary. This is not surprising: admin:123456 is the most common default credential on internet-facing devices worldwide. Any operator who has spent a week scanning SSH will discover this independently.

But the success rate tells a different story.

The Go_SSH fleet's 44× higher success rate cannot be explained by better passwords — they're using the same trivial defaults. It must be explained by better targeting. The fleet is scanning a pre-filtered list of hosts known to accept default credentials, or it's scanning hosts that have already been partially compromised by other operations and had their passwords changed to known defaults.

VI. The Value Extraction Model

The mega-command is not just reconnaissance. It is a pricing algorithm.

Every piece of data collected maps to a market value:

The mega-command, read as a pricing algorithm, produces a scored inventory:

This is not hacking. This is asset management.

VII. The Contrast

Place the Go_SSH mega-command beside the libssh swarm's 19-command reconnaissance script from TI-2026-049B:

The Go_SSH mega-command is a more sophisticated tool. It handles more platforms, detects more hardware, evades more defenses, and runs faster. But the libssh script runs on 2,341 nodes simultaneously. Volume versus precision. Factory versus laboratory.

The Go_SSH operator invested in tooling quality. The libssh operator invested in scale. Both strategies work. Both generate revenue. They represent two different business models applied to the same market.

VIII. The Thread Forward

The Go_SSH fleet validates credentials. TechTies profiles the hosts. The mega-command prices the inventory. But where does that inventory go?

333 hosts validated. Some classified as GPU-equipped. Some as high-uptime abandoned servers. Some as honeypots (discarded). The profiled inventory exists somewhere — in a database, a spreadsheet, a dark web listing. The validated access has value: $5-50 per host on access broker markets, more for GPU-equipped systems.

The next letter maps the geography — where are these 320 Go_SSH IPs, which countries house the validation fleet, which networks carry the most traffic. The spatial pattern may reveal procurement chains, operational bases, and the jurisdictional arbitrage that keeps the operation alive.