TI-2026-062B — The Census of the Forward Probe: Three Ways to Ask One Question

Classification: MEDIUM–HIGH · Forensic threat intelligence · Honeypot-derived · Published 2026-07-07 · Series: The Proxy Recruiters

TI-2026-062A followed one toolkit that asked our SSH server to relay a DNS packet. Step back to the whole honeypot, and that toolkit is one of three. Across 110 days the honeypot logged 50,348 direct-tcpip forward requests from 263 source IPs — every one of them a stranger asking the same question, will you relay traffic for me? But they ask it in three distinct dialects, and the dialect is a fingerprint. This dossier is the census: it sorts the entire forward corpus by what the attacker forwards to, and shows that the destination — a DNS resolver, a big website, or an IP-echo service — cleanly partitions the swarm into three toolkits serving three different proxy markets.

1. The Corpus

Every SSH direct-tcpip request the honeypot received in the window 2026-03-21 → 2026-07-07:

No traffic left the network — Cowrie logs and drops each request. What survives is the intent, and intent is written in the destination address. Three destination families account for essentially the entire corpus, and each maps 1:1 to a single SSH client toolkit.

2. Method One — The DNS Canary

Destination: 1.1.1.1:53 (Cloudflare's resolver). Volume: 4,808 forwards. Toolkit: HASSH eff4c24daffc8532c160e86e5f006e53 (go_scanner, client banner SSH-2.0-Go) — exclusively. Every forward to 1.1.1.1:53 carries the same byte-identical payload: a DNS A query for the canary domain a.to.

This is the subject of TI-2026-062A — the go_scanner cluster operated from AS200730 (ISAEV) and AS154383 (ZornTech/BearShield). The question it answers is narrow: can this host resolve DNS through me? A box that relays a DNS lookup to Cloudflare is a working UDP-adjacent relay — the cheapest possible proof of forwarding capability, one round-trip, no shell.

The signature is absolute: SSH-2.0-Go + HASSH eff4c24d + a forward to 1.1.1.1:53 = this toolkit, no exceptions in 4,808 events.

3. Method Two — The Provider Fetch

Destinations: the front doors of the world's biggest websites, on port 80.

Volume: the bulk of the corpus — tens of thousands of forwards. Toolkits: two, both scripted brute-forcers that carry a full GET / HTTP/1.0 after the tunnel opens:

• HASSH a7a87fbe86774c2e40cc4a7ea2ab1b3c (SSH-2.0-libssh2_1.8.1) — 20,226 forwards.
• HASSH 57e4cc8ee36c3d78f75c6a05acd55963 (paramiko_script) — 23,994 forwards, and notable for rotating its advertised client banner across PuTTY_Release_0.63, OpenSSH_5.3, paramiko_1.8.1, libssh_0.11 and dozens more while the HASSH stays constant — banner spoofing defeated by fingerprint consistency.

The question this method answers is different from the DNS canary: can this host fetch a real, large, geographically-anchored website? — i.e. is it a usable web proxy. The provider choice is itself a market signal, a point already established in the corpus: TI-2026-038B "The Permanent Residents" documents that Private Layer validates against Yahoo alone (Western market) while w1n validates against both Yahoo and Yandex (Western + Russian/CIS market). This dossier does not re-derive that finding; it places it in the taxonomy. The two dominant actors here — 179.43.139.58 (Private Layer INC, AS51852) and 185.246.128.133 (w1n ltd, AS42237) — are the subjects of TI-2026-038A and TI-2026-001 respectively.

4. Method Three — The Mirror

Destination: ip-who.com:80. Volume: 629 forwards. Toolkit: HASSH fda360b1b4f4d3455cb75c6e7edb1d11 (SSH-2.0-AsyncSSH_2.1.0) — exclusively, 629 of 629.

ip-who.com is not a website to fetch or a resolver to query. It is an IP-echo service: you connect, it tells you the source address it saw. Forwarding to it through our SSH server answers a third, distinct question: if I relay traffic through this host, what IP does the outside world see? That is the question that only matters to a residential proxy operation — where the entire product is "traffic that exits from a real consumer IP," and the exit address must be verified to be sold.

The AsyncSSH cluster behind this method is 151 source IPs, and — unlike the datacenter-hosted Methods One and Two — they are residential: overwhelmingly Vietnamese Viettel (AS7552) "Fixed Line ISP" addresses. They are profiled separately in TI-2026-062C. The concept of the ip-who.com exit-IP oracle was first noted in TI-2026-021M "The Phantom Pipes"; what is new here is the clean 1:1 binding of that method to the AsyncSSH toolkit and the residential cluster running it.

5. The Taxonomy

Three destinations, three toolkits, three questions, three markets:

The load is extraordinarily concentrated. A single IP — 185.246.128.133 (w1n) — accounts for 23,944 forwards, ~48% of the entire corpus on its own. The next, 179.43.139.58 (Private Layer), adds 15,972. The two documented bulletproof operators together produce ~79% of all forward volume; the go_scanner DNS cluster and the residential AsyncSSH cluster are smaller but each defines its own method.

Top forwarders:

6. Alternative Interpretation

Steelman: "Forwarding to Yahoo or 1.1.1.1 is just a connectivity check. Any scanner, benign or not, might test whether a box has working internet before proceeding — this is over-reading a TCP dial-tone." And Cowrie discards the forwards, so nothing is proven to have relayed.

Why the taxonomy holds:

• The destinations are chosen, and the choice is legible. A generic connectivity check does not need Yahoo and Yandex from the same operator (that is geographic market targeting, per 038B), nor an IP-echo service (whose only purpose is to learn your exit address), nor a DNS canary to a specific short domain. Benign uptime tools ping or resolve their own infrastructure; they do not ask a stranger's SSH server to relay to a proxy-market oracle.
• The 1:1 toolkit↔destination binding is not what noise looks like. If these were incidental connectivity checks, destinations and toolkits would mix. Instead each HASSH maps to exactly one destination family, across tens of thousands of events — a property of purpose-built software, not coincidence.
• Persistence proves it is a product, not a probe. w1n's 185.246.128.133 forwarded ~71 times per day for 70+ consecutive days (per TI-2026-001). Nobody connectivity-checks the same honeypot 71 times a day for ten weeks. That cadence is catalog re-validation — keeping a proxy inventory fresh for sale.

What this dossier does not claim: that the four operators are one entity. They are four separately-documented actors (ISAEV, ZornTech, Private Layer, w1n) plus a residential cluster, converging on the same honeypot because they are in the same business — not because they share a hand.

Confidence: MEDIUM–HIGH — HIGH that the three destination families are three deliberate proxy-validation methods with clean toolkit signatures; MEDIUM on the precise market interpretation of each (well-supported for HTTP by prior dossiers, inferential for the DNS and mirror methods).

7. Defense Response

• One control neutralises all three methods. AllowTcpForwarding no (with PermitTunnel no, GatewayPorts no) in sshd_config makes every method fail at the channel-open step, regardless of destination or toolkit. admin/admin and the other default credentials these tools rely on should never authenticate.
• Detection is per-method and high-precision. Each method is a two-token rule that needs no payload inspection:
• SSH-2.0-Go + forward to 1.1.1.1:53 → go_scanner (Method One)
• libssh2_1.8.1 or HASSH 57e4cc8e + forward to a Yahoo/Yandex/Google/MS :80 → provider-fetch validators (Method Two)
• AsyncSSH_2.1.0 + forward to ip-who.com → residential-proxy mirror (Method Three)
• The forward destination is the highest-value single field. Because it partitions the swarm cleanly, logging the direct-tcpip target (which Cowrie already does) is sufficient to classify a proxy-recruiter by market without any other signal.

8. Investigation Metadata

Cristian Lișneanu · shuffle-on.com · Threat Intelligence