TI-2026-037A
The Ghost Machines

I. Abstract — The 91% Anomaly

In four months of continuous LSN honeypot operation, one IP address has done something no other attacker has achieved: a 91% login success rate across 4,336 attempts.

That IP is 87.251.64.176.

To understand why this is extraordinary, consider the baseline. The average brute-force attacker in our dataset hits a success rate of 0-5%. The credential sprayers, the Mirai variants, the amateur scripts — they try root:password, root:123456, root:toor, and they fail. They're playing a numbers game with terrible odds.

87.251.64.176 is not playing that game. It logged into our honeypot 3,942 times out of 4,336 attempts. It did this with a single credential pair: admin:admin. It did this using a custom Go-based SSH scanner. And after every successful login, it ran one command — the most sophisticated reconnaissance script we have ever observed in this honeypot.

This is not a brute-force attack. This is a device recruitment operation.

This dossier follows the operation from the single IP to a coordinated 6-node cluster, through four countries, three bulletproof hosting providers, and a web of Kazakhstan-registered shell entities with Russian RDAP maintainers — all serving a single purpose: finding devices that can be turned into proxy tunnels.

II. The Scanner — What It Is and What It Wants

The scanner identifies itself through its SSH handshake fingerprint (HASSH): eff4c24daffc8532c160e86e5f006e53. Our fingerprint database classifies this as go_scanner — a custom SSH client written in Go.

This is not off-the-shelf. This is not Mirai's Telnet/SSH module. This is not Medusa or Hydra. Go-based SSH scanners are purpose-built tools, typically compiled for the specific operation. The language choice is deliberate: Go compiles to a single binary with no dependencies, runs on any Linux architecture, and handles thousands of concurrent SSH connections efficiently.

The scanner operates as a 6-node cluster:

Six IPs. Four ASNs. Four countries (Poland, Bulgaria, Russia, UAE). One Go binary. One HASSH fingerprint. One credential: admin:admin. One command.

This is coordination.

III. The Command — A Forensic Deconstruction

After a successful login, the scanner executes exactly one command. It is 1,247 characters long. It is the most information-dense reconnaissance payload we have ever captured. Here it is, section by section:

# PHASE 1: System Identification
echo '===UNAME===';    uname -a          # Kernel, arch, hostname
echo '===HOSTNAME===';  hostname          # Device name
echo '===ARCH===';      uname -m          # CPU architecture (arm? mips? x86?)
echo '===ID===';        id                # Current user privileges
echo '===SHELL===';     echo $SHELL       # Shell type
echo '===PASSWD===';    grep "^$(whoami):" /etc/passwd  # User details
echo '===OSRELEASE==='; cat /etc/os-release    # Distribution
echo '===ISSUE===';     cat /etc/issue         # Login banner

# PHASE 2: SSH Tunnel Capability Assessment ← THE KEY SECTION
echo '===SSHD==='; grep -iE 'AllowTcpForwarding|DisableForwarding|PermitTunnel|GatewayPorts|ForceCommand' /etc/ssh/sshd_config
# ↑ This is WHY they're scanning. They want devices where:
#   AllowTcpForwarding = yes  (can proxy TCP through this device)
#   PermitTunnel = yes        (can create VPN-like tunnels)
#   GatewayPorts = yes        (can bind to all interfaces)
#   ForceCommand = none       (no restricted shell)

# PHASE 3: Network Intelligence
echo '===IPADDR===';    ip -4 addr show || ifconfig    # Network interfaces — real IP
echo '===LISTENING==='; ss -tlnp || netstat -tlnp       # Open ports — what else runs here

# PHASE 4: Resource Assessment
echo '===UPTIME===';    cat /proc/uptime       # How long has this been running?
echo '===MEMINFO===';   head -3 /proc/meminfo  # RAM available
echo '===NPROC===';     nproc                  # CPU count
echo '===DF===';        df -h /                # Disk space

# PHASE 5: Proxy Tool Inventory ← WHAT THEY'RE LOOKING FOR
echo '===TOOLS==='; which socat curl wget python3 python ncat chisel gost 2>/dev/null
# ↑ socat:   TCP relay, port forwarding
#   chisel:  HTTP-tunneled SSH/TCP proxy
#   gost:    Go Simple Tunnel — multi-protocol proxy/tunnel
#   ncat:    Nmap's netcat — proxying, relay
#   curl/wget: Download capability for stage 2 payloads
#   python:  Scripting — can create ad-hoc SOCKS proxies

# PHASE 6: Writability & Escalation
echo '===WRITABLE==='; touch /tmp/.sshprobe && rm /tmp/.sshprobe && echo OK
echo '===PKGMGR===';   which apt yum apk opkg dnf pacman zypper 2>/dev/null
echo '===SUDO===';     sudo -n true 2>&1 && echo SUDOOK
# ↑ Can we write files? Can we install software? Can we escalate?

# PHASE 7: Router/IoT Firmware Detection ← THE TARGET PROFILE
echo '===MIKROTIK===';  /system resource print   # MikroTik RouterOS
echo '===OPENWRT===';   cat /etc/openwrt_release  # OpenWrt routers
echo '===UBNT===';      cat /etc/version           # Ubiquiti devices
echo '===END==='

Read this command carefully. It tells you everything about what this operation wants.

It does not check for cryptocurrency. It does not download malware. It does not attempt to spread. It collects intelligence. Specifically:

1. Can this device act as a proxy? (SSH forwarding config, installed tunnel tools)
2. Is this a router? (MikroTik, OpenWrt, Ubiquiti detection)
3. What IP does it have? (Real IP discovery — the valuable asset)
4. How stable is it? (Uptime, resources, disk space)
5. Can we deploy tools? (Writability, package manager, sudo)

This is a shopping list. The scanner is evaluating every compromised device for one thing: can it be turned into a proxy node?

IV. The Network — Kazakhstan Shells, Russian Maintainers

The primary operator is registered as ISAEV Igor, under Autonomous System AS200730, registered in Kazakhstan.

But Kazakhstan is only the paperwork.

The RDAP maintainer handle ru-avm-1-mnt deserves attention. The prefix ru- is a RIPE convention indicating the maintainer object was created for a Russian entity. The novahost.kz domain — the abuse contact — returns no website. The domain exists solely as a contact address in RIPE records.

The entity graph reveals 8 IPs belonging to this ASN, all in the 87.251.64.0/24 subnet:

The partner entity is equally instructive:

Two Kazakhstan-registered ASNs. Two .kz abuse domains. Russian maintainer handles. IPs geolocating to Poland and Bulgaria. BGP routing through Russia. German upstream provider (1337 Services GmbH).

This is not a hosting company. This is an identity laundering network.

V. The Accomplices — Proton66, Private Layer, Omegatech

The go_scanner campaign cluster connects directly to three other bulletproof hosting networks — each a known enabler of cybercrime, each investigated independently by security researchers worldwide.

Proton66 OOO (AS198953) — The Russian Bulletproof Giant

IP 37.77.150.119 in the go_scanner cluster belongs to Proton66 OOO — the single most documented bulletproof hosting provider of 2024-2026.

The same network that hosts ransomware toolkits, phishing pages, and nation-state exploits is running nodes in a device recruitment campaign alongside Kazakhstan shell entities. This is not coincidence. This is infrastructure sharing — the same bulletproof pipes serving multiple operations simultaneously.

Omegatech LTD (AS202412) — The Seychelles Phantom

A parallel campaign — hassh-a7a87fbe86774c2e, using libssh2_scanner — runs a 4-node cluster with strikingly similar behavior: 3,289 attempts, 3,289 successes, 100% success rate, same admin:admin credential.

Private Layer INC (AS51852) — The Swiss-Panamanian Pipeline

Two IPs in the Omegatech campaign cluster belong to Private Layer INC — registered in Panama, operating from Switzerland.

57 open ports. Not web servers. Not mail servers. Not databases. Proxy ports. Each one potentially a tunnel to a compromised router somewhere in the world, emerging with a clean residential IP.

VI. The Credential Strategy — Why admin:admin Works

The credential used across all scanner nodes is overwhelmingly admin:admin — with 4,652 uses across the go_scanner campaign alone, and 5,589 uses across the libssh2_scanner campaign.

This is not stupidity. This is precision targeting.

The ISAEV/SOLDATOV network also uses a secondary dictionary targeting the support account with common passwords (123456, 1234567, 123456789, 1q2w3e4r5t, 111111, 1234, 12345, 000000, 123, 123123). This is a standard support account dictionary for network equipment — the kind of credentials left on managed switches, VoIP gateways, and enterprise routers.

Combined with the reconnaissance command that checks for MikroTik, OpenWrt, and Ubiquiti firmware, the target profile becomes clear: they're not hacking servers. They're logging into routers that still have default passwords.

And there are millions of them.

VII. The Timeline — 88 Days of Precision Clockwork

The go_scanner campaign has been continuously active from March 26 to June 21, 2026 — 88 days without interruption.

The precision is mechanical. The 3-day interval is consistent across months. The volume per cycle is nearly identical (94-100). The single dip to 60 attempts on June 18 — likely a brief network interruption — was followed by an immediate return to 100 on June 21.

This is an automated system running unattended. It has been running for at least 88 days. Given the sophistication, it has likely been running far longer — our honeypot's observation window is simply limited.

VIII. The Purpose — What Gets Built From Compromised Devices

The evidence points to a single purpose: residential proxy network construction.

The residential proxy market is one of the fastest-growing segments of cybercrime infrastructure. Legitimate providers like Bright Data (formerly Luminati, founded by former Israeli intelligence personnel — documented in TI-2026-034A) operate massive networks of "opted-in" residential IPs. But the underground market runs on compromised devices.

The economics are compelling:

But residential proxies aren't just for evading rate limits. They enable:

• Credential stuffing: Testing stolen passwords against banking sites, from a residential IP that bypasses fraud detection
• Ad fraud: Generating fake ad clicks from real residential IPs, indistinguishable from legitimate traffic
• Sanctions evasion: Routing financial transactions through residential IPs in non-sanctioned countries
• Intelligence operations: Accessing geographically restricted services without revealing the operator's true location
• Disinformation: Posting from residential IPs that appear to be real local users

The reconnaissance command reveals the sophistication: it doesn't just check "can I use this device?" — it evaluates how well it can be used. SSH forwarding capability. Existing proxy tools. Sudo access for installing new tools. Resource availability. Architecture (for deploying pre-compiled proxy binaries). This is a quality assessment pipeline for proxy inventory.

Cross-reference with the honeypot's broader command landscape:

The sophistication gap is telling. Most attackers behave like teenagers in a candy store — checking for Telegram, checking for miners, injecting SSH keys one step at a time. The ISAEV scanner behaves like a systems administrator auditing a fleet. The command is structured, labeled (===SECTION===), and designed for automated parsing.

This is not a hacker. This is an operation.

IX. Cross-Investigation — Where These Networks Appeared Before

The infrastructure in this dossier connects to multiple prior LSN investigations:

The GRU connection deserves specific attention. The DOJ's 2020 Sandworm indictment documented Unit 74455 leasing infrastructure from bulletproof hosting resellers — exactly the type of provider Proton66 operates as. Proton66's ASN-DROP listing, its documented role in GootLoader/SpyNote distribution, and its PROSPERO/BEARHOST forum presence place it squarely in the ecosystem the DOJ identified.

We cannot prove that the ISAEV scanner serves GRU operations specifically. But we can prove that the same bulletproof hosting ecosystem serves both the ISAEV scanner and documented state-linked operations. The infrastructure is shared. The question is whether the customers overlap.

X. The Questions That Remain