🔄 The Proxy Verifier

At 23:15 local time on June 22, 2026, Telegram alerts fired. The honeypot was under sustained assault from a single IP address: 179.43.139.58. Over 30,000 events in 20 hours. Continuous. Relentless. Still active as this investigation was conducted.

This is not an unknown attacker. This IP was documented in TI-2026-037A "The Proxy Hunters" as part of the Omegatech/Private Layer scanner duo. It was identified as running industrial-scale credential harvesting with a libssh2_scanner fingerprint.

But 037A documented the scanning. This investigation documents what comes next: the proxy verification — the quality control step where a compromised device is tested for its ability to relay traffic.

And the evidence shows this IP has been doing it for 94 consecutive days.

I. The Attacker — Private Layer INC

The jurisdictional architecture is deliberate: Panama registration (one of the hardest jurisdictions for cybercrime enforcement), Swiss phone number (banking secrecy tradition), LACNIC IP allocation (Latin American registry, different legal framework from RIPE/ARIN). The name itself — "Private Layer" — is a statement of intent.

112 Open Proxy Ports

Shodan reveals what this server actually is: a proxy concentrator with 112 open ports, spanning the range 10000-21935.

Each port is a proxy endpoint. 112 ports on a single IP means this server is aggregating traffic from up to 112 simultaneous proxy customers or exit nodes. Port 135 (Windows RPC) and 5985 (WinRM) suggest additional attack surface beyond the proxy infrastructure.

II. The Attack — 94 Days of Proxy Verification

Private Layer has been probing our honeypot every single day since March 21, 2026. The pattern reveals a three-phase operational cycle:

Phase 1: Baseline Polling (86 days, avg 203 events/day)

Approximately 24 login attempts per hour, around the clock. Each session: connect → authenticate with admin:123456 → request SSH tunnel to Yahoo.com → receive rejection → disconnect → repeat in ~2.5 minutes. This is keepalive verification — checking every few minutes that the "proxy" (our honeypot) is still responsive.

Phase 2: Escalation (5 days, avg 418 events/day)

Brief periods of increased activity, typically preceding or following a flood. The scanner increases its polling rate, possibly testing different forwarding configurations or cycling through Yahoo's DNS results.

Phase 3: Flood Verification (3 days, avg 22,225 events/day)

The flood days are bulk re-verification sweeps. The operator is testing their entire proxy pool simultaneously — connecting to each registered "proxy" IP in rapid succession, sending tunnel requests, and marking which ones respond. Our honeypot never responds to the forwarding request (Cowrie drops it), but the attacker keeps trying because they maintain it in their pool as a potential proxy.

III. The Verification Protocol

Every single one of the 86,239 sessions follows the same protocol:

Why Yahoo.com?

The verification target is Yahoo.com — specifically, all 12 of Yahoo's frontend IPs (6 IPv4, 6 IPv6):

Yahoo is the ideal verification target for three reasons:

1. Availability: Yahoo.com has 99.99%+ uptime. If the tunnel fails, it's the proxy, not the target.
2. Multiple IPs: 12 frontend IPs allow testing diverse routing paths through the proxy.
3. HTTP/1.0: The GET / HTTP/1.0 request is the simplest possible HTTP transaction — no TLS, no connection keep-alive, no cookies. A binary test: either the bytes come back or they don't.