TI-2026-062A — The Recruiter's Handshake: One Go Proxy-Scanner Across Two Bulletproof Operators

Classification: MEDIUM–HIGH · Forensic threat intelligence · Honeypot-derived · Published 2026-07-07

An SSH login that succeeds, asks the server to forward a single DNS packet to 1.1.1.1, and hangs up 0.4 seconds later is not a break-in attempt. It is an audition. The attacker is not trying to use the machine — it is testing whether the machine can be rented: as an open proxy, a tunnel, a piece of someone else's infrastructure. This dossier traces one such recruiter — a Go SSH scanner identified by a single HASSH fingerprint — as it operates from two entirely separate bulletproof hosting operations, and shows why the same tool in different hands is a harder attribution problem than a single actor.

1. The Signal

On 2026-07-07 at 12:35:36 UTC, the Cowrie honeypot recorded a sequence it had seen thousands of times before:

New connection: 176.53.159.196 → :2222
Remote SSH version: SSH-2.0-Go
SSH client HASSH: eff4c24daffc8532c160e86e5f006e53
login attempt [admin/admin] succeeded
direct-tcp connection request to 1.1.1.1:53 from 0.0.0.0:0
discarded direct-tcp forward request to 1.1.1.1:53
Connection lost after 0.4 seconds

The forwarded payload, captured verbatim:

b'\x00\x16\xab\xcd\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\x01a\x02to\x00\x00\x01\x00\x01'

Decoded, it is a complete DNS query wrapped for TCP transport:

The attacker authenticates, then asks our SSH server to open a channel to Cloudflare's resolver and relay a DNS lookup for a.to — a live, deliberately short domain used as a canary. If a reply came back, the box would be catalogued as a working DNS relay and open SSH proxy: resaleable infrastructure. Cowrie's FakeForwardingChannel logs the request, discards the payload, and never dials out. No traffic left the network. The from 0.0.0.0:0 originator is attacker-declared and meaningless.

This is not an isolated event. In the current honeypot log window (2026-03-21 → 2026-07-07):

The DNS-to-1.1.1.1 probe and the HTTP-to-Yahoo probe are two dialects of the same question: does this host relay traffic for a stranger?

2. The Fingerprint

Every one of these sessions presents the same SSH client HASSH:

eff4c24daffc8532c160e86e5f006e53 — classified in our pipeline as go_scanner ("Go crypto/ssh scanner").

HASSH is a hash of the SSH client's key-exchange, cipher, MAC and compression algorithm lists in offer order. It is a toolkit fingerprint, not an operator fingerprint — and this is the first place attribution must stay honest (see §5). Across the full history the fingerprint appears in 4,277 sessions from 4 source IPs, first seen 2026-04-17, last seen 2026-07-07, and in every single session the credential offered was admin / admin.

Two prefixes. Two different networks. One tool.

3. Two Modes of the Same Audition

The toolkit was observed in two distinct probe modes.

Mode A — Shell capability recon (the fingerprint's debut)

On 2026-04-17 at 18:08:33 UTC, in the very first session this HASSH ever produced, 87.251.64.146 opened a shell and ran a single, purpose-built reconnaissance command. It is not generic enumeration — read what it actually asks:

uname -a; hostname; uname -m; id; echo $SHELL;
grep "^$(whoami):" /etc/passwd; cat /etc/os-release; cat /etc/issue;
# --- the tell ---
grep -iE 'AllowTcpForwarding|DisableForwarding|PermitTunnel|GatewayPorts|ForceCommand' /etc/ssh/sshd_config;
ip -4 addr show || ifconfig; ss -tlnp || netstat -tlnp;
cat /proc/uptime; head -3 /proc/meminfo; nproc; df -h /;
which socat curl wget python3 python ncat chisel gost;   # pivot / tunnel tooling
touch /tmp/.sshprobe && rm /tmp/.sshprobe && echo OK;      # is /tmp writable?
which apt yum apk opkg dnf pacman zypper; sudo -n true && echo SUDOOK;
/system resource print;         # MikroTik RouterOS
cat /etc/openwrt_release;       # OpenWRT
cat /etc/version;               # Ubiquiti / EdgeOS

Three signals mark this as a proxy/pivot recruitment probe, not a botnet loader:

1. It greps sshd_config for exactly the five directives that govern whether a host can be used as a tunnel: AllowTcpForwarding, DisableForwarding, PermitTunnel, GatewayPorts, ForceCommand.
2. It checks for chisel and gost — SOCKS-over-HTTP tunneling tools — alongside socat, ncat, curl, wget.
3. It fingerprints for MikroTik RouterOS, OpenWRT and Ubiquiti — the embedded-router platforms that make the best disposable proxies because nobody patches them and they sit on residential IPs.

The honeypot answered /system resource print with "Command not found," the session collected its admin/admin shell, and moved on. Mode A was captured once; it is the tool showing its hand.

Mode B — Network forward-probe (the volume)

Mode B skips the shell entirely. Authenticate, request a direct-tcpip channel to a known-good destination (1.1.1.1:53 for DNS, Yahoo/Yandex :80 for HTTP), and measure whether the relay works. This is the 50,331-event firehose. It is faster than Mode A, needs no shell, and answers the only question a proxy reseller cares about: does traffic come back? 176.53.159.196 ran Mode B exclusively — 220 sessions, each ~0.4 seconds, each a single forward request.

The division of labour is coherent: Mode A profiles a box worth keeping; Mode B mass-validates relay capability at scale.

4. The Two Operators

The four fingerprint IPs resolve to two unrelated bulletproof hosting operations — and neither is a coincidence of geography.

AS200730 — ISAEV (87.251.64.0/24)

The 87.251.64.x block belongs to AS200730 "ISAEV — ISAEV Igor", registered KZ but geolocating PL, abuse contact abuse@novahost.kz. 87.251.64.176 alone carries an AbuseIPDB score of 100 across 9,208 reports and a maximal threat score. This operator is already documented in TI-2026-020B — ISAEV: A Darknet Operator. Its role here is as the origin of the go_scanner fingerprint and the source of the only captured Mode A recon.

AS154383 — ZornTech / BearShield (176.53.159.0/24)

The 176.53.159.x block is the newer and more interesting half. It belongs to AS154383 "ZORNTECH WEB SOLUTIONS", and its paperwork disagrees with itself at every layer:

A Bangladeshi ASN, allocated eight months ago, announcing a Polish-geolocated prefix, maintained by a Turkish handle, fronted by a Czech corporate suffix, reachable at a .top abuse address. This is the standard signature of a leased, laundered prefix — bought or rented rather than operated by a real network. AS154383 announces 28 IPv4 prefixes scattered across Brazilian, US and European ranges (189.13.142.0/24, 104.250.176.0/24, 172.111.222.0/24, …) with no v6, no IXP presence, and two transit upstreams (AS62610, AS207208). Its risk score is 85.6. Via shared BGP upstream it clusters with AS152179 (Global Communication Network Ltd, HK — bulletproof, risk 88.9) and AS5065 (Bunny Communications, US — bulletproof).

The whole /24 behaves as one unit: four IPs (.196–.199), all admin/admin, all appearing within days of each other in July 2026, sharing the abuse contact abuse@bearshield.top and the tr-hopes-1-mnt maintainer.

5. Alternative Interpretation

The forensic weak point in this dossier is the HASSH itself, and it deserves to be stated plainly rather than buried.

Steelman: HASSH eff4c24d is the default algorithm ordering emitted by Go's golang.org/x/crypto/ssh package. Any program built against that library with default settings — including legitimate internet-wide scanners like research crawlers — produces an identical fingerprint. On the HASSH alone, "these four IPs are the same actor" is unsupported: they could be four independent people who all happen to have compiled a Go SSH client. And Cowrie discards the forwards, so one could argue no harm and no intent is proven.

Why the evidence still holds — at a bounded confidence:

• Same build, not just same library. The fingerprint is not carried alone. It travels with a fixed behavioral bundle: admin/admin and only admin/admin across 4,277 sessions; the identical a.to / 1.1.1.1:53 DNS canary payload byte-for-byte; and, where a shell was taken, the identical 30-signal recon command. A stock Go SSH library does not choose a.to as a DNS canary or grep sshd_config for PermitTunnel. That composite is a specific tool, and the same-toolkit conclusion is HIGH confidence.
• Intent is legible from the probe, not the outcome. The forwards are discarded on our end, but the choice of target is the attacker's, and it reveals purpose: a benign uptime scanner does not test whether it can relay DNS through your host to Cloudflare, nor grep your SSHd config for tunnel permissions. GreyNoise independently classifies 176.53.159.196 as malicious; AbuseIPDB scores the cluster 94–100.
• Same operator is the claim we do NOT make. Whether ISAEV and ZornTech/BearShield are one operator or two customers of the same scanner-as-a-service is LOW–MEDIUM and left open. The honest finding is a shared tool across separate bulletproof infrastructure — which is arguably the more important pattern, because it means blocking one operator does not retire the tool.

Confidence: MEDIUM–HIGH — HIGH that this is a single proxy-recruitment toolkit with deliberate intent; MEDIUM that the two hosting operations are coordinated rather than co-incidental customers.

6. Defense Response

• No action required against the forwards themselves. Cowrie's FakeForwardingChannel discards every direct-tcpip request by design; the "Connection refused to 1.1.1.1:53" line is the honeypot declining to dial, not a leaked connection. This is correct, expected behaviour.
• On a real host, the defence is one line of sshd_config: AllowTcpForwarding no (plus PermitTunnel no, GatewayPorts no) neutralises Mode B entirely, and admin/admin should never authenticate in the first place.
• Blocklist candidates (AbuseIPDB ≥ 94, active): 176.53.159.196, 176.53.159.197, 176.53.159.198, 176.53.159.199 (AS154383), and the dormant-but-hostile 87.251.64.146/.150/.176 (AS200730). Prefix-level blocks on 176.53.159.0/24 and 87.251.64.0/24 are defensible given uniform behaviour.
• Tracking signal: the HASSH eff4c24daffc8532c160e86e5f006e53 paired with an admin/admin success and a direct-tcpip request is a high-precision detection rule for this toolkit regardless of source IP — useful precisely because the tool outlives any single operator.

7. Investigation Metadata

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