From ValleyRAT C2 to 'ZSpeeding' Proxy: A Tencent Cloud HK Box Swaps Silver Fox Jobs for a GFW-Busting VPN — and Leaks pprof
From ValleyRAT C2 to "ZSpeeding" Proxy: A Tencent Cloud HK Box Swaps Silver Fox Jobs for a GFW-Busting VPN — and Leaks pprof
TL;DR
Yesterday we published a deep-dive on Silver Fox's Telegram Chinese Language Pack / ValleyRAT MSI campaign. One of the follow-up pivots from that investigation hit 101.33.117.200 — a Tencent Cloud Hong Kong node that had been previously documented (by Zscaler and in our own campaign notes) as a ValleyRAT C2 on ports 6666/8888.
When we walked the box today, those two C2 ports were gone. In their place: nine high-numbered ports (32080–43080) running a custom-built Xray-core wrapper called ZSpeeding — a VLESS + REALITY + SOCKS4A + gRPC proxy stack impersonating DingTalk and Alibaba CDN via SNI spoofing, configured to bypass the Great Firewall of China. The binary's Go module dependencies, certificate subjects, and an unauthenticated /debug/pprof/ endpoint on port 40804 give us the full build lineage, the developer's real name (pengjunwen / 彭俊文), email, Xiamen location, GitHub handle fanyiguang, and the agile-proxy library on which the ZSpeeding binary is built.
What this report adds to the public record:
- The C2-to-proxy transition on
101.33.117.200— same box, formerly Silver Fox ValleyRAT C2, now a commercial GFW-busting VPN node with 49 days of continuous uptime on the proxy service - The unauthenticated
net/http/pprofOPSEC failure that exposes the entire binary's module graph, config path (/etc/zsp/101.33.117.200.conf), runtime state, and the developer-identifyingO=agile-proxy, L=Xiamenself-signed certificate - The developer attribution chain from the
agile-proxycertificate →github.com/fanyiguang/agile-proxy→pengjunwen <2397711850@qq.com>→Xiamen, Fujian - Evidence of Chinese national cryptographic standards (SM4 cipher suites) negotiated on the DingTalk-spoofing ports, further anchoring this as Chinese-operated infrastructure built to blend with domestic TLS patterns
Yesterday's post is the context you want before reading this one. If you've already published prior work on ZSpeeding, fanyiguang, the agile-proxy project, or the 101.33.117.200 transition, please reply or DM — we'll update and credit.
The Box That Changed Jobs
| Field | Value |
|---|---|
| IP | 101.33.117.200 |
| ASN | AS132203 (ACEVILLE PTE.LTD.) |
| WHOIS netname | ACEVILLEPTELTD-SG |
| Hoster | Tencent Cloud (via Aceville Pte Ltd, Singapore) |
| Location | Hong Kong |
| Reverse DNS | None (NXDOMAIN) |
| Shodan presence | None (not indexed — evades passive scanners) |
| Prior role | ValleyRAT / Silver Fox APT C2 (ports 6666, 8888) |
| Current role | ZSpeeding commercial VPN/proxy node |
The historical C2 ports are no longer accepting connections — 6666 and 8888 are both filtered. So are 22, 80, 443, 3000, 3306, 5060, 5432, 8080, and every other standard port. Whatever's on this box today is only reachable on the high-numbered set the operator picked.
The Nine Active Ports
| Port | Service | Tech | Cert |
|---|---|---|---|
| 32080 | SOCKS4A | Xray-core SOCKS inbound | Plaintext |
| 40003 | VLESS + REALITY | Tengine DingTalk/1.0.0 | *.dingtalk.com (GlobalSign, legit Alibaba cert) |
| 40018 | Unknown | Silent listener | — |
| 40338 | gRPC | TLS | Self-signed CN=localhost, created 2026-04-07 (one day before our scan) |
| 40801 | VLESS + REALITY | Tengine DingTalk/1.0.0 | *.dingtalk.com (same as 40003) |
| 40803 | VLESS + REALITY | Tengine | *.tbcdn.cn — a mega-SAN cert covering 70+ Alibaba / Taobao / Aliyun / DingTalk / AliExpress / Cainiao / Fliggy / Tmall domains |
| 40804 | HTTPS (Go net/http) | agile-proxy | Self-signed O=agile-proxy, L=Xiamen, CN=localhost — expired 2023-06-13 |
| 40820 | Unknown | Silent listener | — |
| 43080 | SOCKS4A over TLS | Xray-core SOCKS inbound | Self-signed CN=101.33.117.200, created 2026-01-05 |
REALITY + DingTalk — What's Happening on 40003 / 40801 / 40803
The *.dingtalk.com and *.tbcdn.cn certificates on ports 40003, 40801, and 40803 are legitimate — they're signed by GlobalSign GCC R3 OV TLS CA 2024, issued to "Alibaba (China) Technology Co., Ltd.", and valid through 2026-10 and 2026-07 respectively. They didn't come from a private key compromise; they got there through Xray-core's REALITY protocol, which proxies the TLS handshake through to the real DingTalk / Alibaba server, captures the genuine cert chain presented by Alibaba, and then hijacks the connection for proxy traffic after the handshake completes.
To a network observer watching this box from inside China, the connections look exactly like legitimate HTTPS traffic to DingTalk (Alibaba's corporate chat, ubiquitous in Chinese enterprise) and tbcdn.cn (Taobao's CDN). The GFW cannot block DingTalk or Taobao without breaking commerce in mainland China, so REALITY's trick is to make proxy traffic hide inside a shape the censor refuses to touch.
SM4 Cipher Support Is the Tell
The DingTalk-spoofing ports (40003, 40801) offer two TLS cipher suites worth noticing:
TLS_AKE_WITH_SM4_CCM_SM3
TLS_AKE_WITH_SM4_GCM_SM3
Those are ShangMi / SM ciphers — Chinese national cryptographic standards. You don't see them in Western TLS deployments. Their presence here is the operator going out of their way to make domestic Chinese observers see domestic-looking TLS.
The pprof Leak on Port 40804
Port 40804 is the interesting one. It runs a separate Go net/http service that answers at /debug/pprof/ with no authentication. That's the standard Go profiling / debug endpoint set, and it will happily cough up everything an attacker (or a researcher) could want to know about a running binary:
goroutine— full stack traces for all 75 active goroutines, which enumerate every module import and every code path in the running binaryheap— memory allocation patterns showing active connection statecmdline— the exact command line the binary was invoked with, including the config pathallocs— 2,532 allocation records, uptime counter reading ~70,806 minutes
From the cmdline dump:
/usr/local/bin/ZSpeeding run -confdir /etc/zsp/101.33.117.200.conf -format=json
That gives us the binary name (ZSpeeding), the config directory (/etc/zsp/), the config naming convention (the IP address of the host is the config filename), and the fact that the config is JSON-formatted. The goroutine dump gives us the Go module dependency graph:
| Module | Version | Purpose |
|---|---|---|
github.com/xtls/xray-core | latest | Core proxy engine (V2Ray fork with XTLS) |
github.com/xtls/reality | v0.0.0-20231112171332 | REALITY TLS anti-detection |
github.com/fanyiguang/rawtext | v0.0.0-20250129161029 | SNI spoofing / TLS simulation (a private module, not a public package) |
google.golang.org/grpc | v1.62.1 | gRPC multiplexing |
gopkg.in/natefinch/lumberjack.v2 | v2.2.1 | Log rotation |
rawtext is the part that's interesting — it's a private Go module published under github.com/fanyiguang/rawtext that provides the rawtext/protocol.Tls and rawtext/dokodemopocket calls showing up in the goroutine dump. The function name refreshSimSniServerHelloData on the stack tells you what it does: it keeps a cache of realistic TLS ServerHello bytes to mimic during SNI spoofing. That's purpose-built GFW-evasion machinery.
The 70,806-minute uptime on the main goroutine puts the ZSpeeding service start at approximately February 18, 2026, which lines up neatly with when the ValleyRAT C2 ports went silent. That's the same calendar window.
The Developer — fanyiguang / pengjunwen
The attribution starts with the agile-proxy self-signed certificate on port 40804:
Subject: C=CN, ST=Fujian, L=Xiamen, O=agile-proxy, CN=localhost
Issuer: Self-signed
Valid: 2022-06-13 → 2023-06-13 (EXPIRED)
SANs: localhost, 127.0.0.1
The organization field O=agile-proxy matches the public GitHub project github.com/fanyiguang/agile-proxy (described by the author as "一款灵活，轻量，易于扩展的代理工具" — "a flexible, lightweight, easily-extensible proxy tool"). The certificate's location field L=Xiamen matches the author's Git commit location. And the certificate's valid-from date of 2022-06-13 is essentially the same day the GitHub repo was created.
GitHub profile
| Field | Value |
|---|---|
| Handle | fanyiguang |
| GitHub ID | 52657276 |
| Public repos | 38 |
| Profile name | fanyiguan |
| Real name (Git commit history) | pengjunwen / 彭俊文 |
2397711850@qq.com | |
| Location | Xiamen, Fujian, China |
First Git commit in agile-proxy
Author: pengjunwen <2397711850@qq.com>
Date: 2022-09-09
Message: doc: 修改readme
The QQ number 2397711850 is tied to real identity in China via phone-verification requirements on QQ accounts. It's not a hash; it's an ID.
The author's toolkit
The 38 public repos are almost entirely proxy/circumvention/traffic-shaping libraries:
agile-proxy— the main projectXray-core— fork of Xray (the V2Ray + XTLS fork)rawtext— private — the TLS SNI simulation library we see running on this boxclash,clashh— forks of Clashsing-shadowsocks,sing-shadowsocks2wireguard-go,wireguard-go-newgost,gost-3utls— TLS fingerprint mimicrycloudflare-tlssmux,smux-copygvisorforkquic-go-copy
This is a developer who maintains a full stack of circumvention tooling, including private forks of libraries that are publicly available. The ZSpeeding binary running on 101.33.117.200 is built out of that stack.
What the Transition Means
We can read the Silver Fox → ZSpeeding transition three ways:
- Same operator, different use. The Silver Fox actor who previously ran ValleyRAT C2 on this box is now monetizing its dormant capacity by running a VPN service when campaigns aren't active.
- Infrastructure recycled. Tencent Cloud reclaimed the IP after the original tenant's account lapsed or was suspended, and a separate VPN operator acquired it in the normal rotation.
- Shared infrastructure. The same physical VPS serves both purposes — C2 during active campaigns, VPN during downtime — because the two user bases don't overlap and the VPN revenue pays the hosting.
The evidence slightly favors (1) or (2): the 49-day continuous uptime from the pprof leak, the fact that the gRPC transport certificate was regenerated on April 7 (the day before our scan — active maintenance), and the complete disappearance of the C2 ports rather than their co-existence alongside the proxy service. What we can't distinguish from the outside is whether the VPN operator and the original Silver Fox operator are the same people or different tenants on the same box.
What we can say is that the developer identity attached to the VPN binary is fanyiguang / pengjunwen — and nothing in that identity directly overlaps with documented Silver Fox tooling. Silver Fox's documented kernel-driver and BYOVD work on the Windows side doesn't share authorship signals with the Xamen-based Xray-core circumvention ecosystem. These could be the same person wearing two hats, or they could be two unrelated tenants of the same Tencent Cloud VPS.
OPSEC Lessons
Two OPSEC failures matter here:
- The unauthenticated
/debug/pprof/endpoint. This is the canonical Go developer mistake: leaving_ "net/http/pprof"imported in a production build, or binding a debug listener to0.0.0.0instead of127.0.0.1. Every goroutine, every module import, every allocation sample, the full command line, and the config path all came from pprof alone — no reversing required. If you ship Go binaries, grep your builds forpprofbefore deploy. - The attribution-labeled certificate. The
O=agile-proxy, L=Xiamenself-signed cert didn't need to sayagile-proxyin the Subject field to function. Defaults for self-signed certs are justCN=localhost; someone actively chose to stamp the project name and city into the cert, and the cert has since become the strongest single attribution anchor for the developer. Treat self-signed cert Subject fields as eitherCN=localhostor random garbage, never as project branding.
Detection & Hunting
Network
- Block
101.33.117.200on all ports — regardless of whether you treat it as Silver Fox C2 infrastructure or a GFW-busting commercial proxy, neither is something you want traffic going to from an enterprise network. - If Tencent Cloud HK is not expected in your environment, consider range-blocking
101.33.116.0/20(the Aceville / Tencent HK allocation).
Protocol signatures
- Flag SM4 cipher negotiation in TLS handshakes:
TLS_AKE_WITH_SM4_CCM_SM3andTLS_AKE_WITH_SM4_GCM_SM3are Chinese national ciphers and are anomalous outside of Chinese enterprise environments. - Flag REALITY fingerprints — unusual JA3 / JA4 fingerprints on TLS connections to known Chinese domestic services (DingTalk, Taobao, Alibaba CDN) originating from unexpected client populations.
Binary signatures
- The binary name
ZSpeedingand the config directory/etc/zsp/are tight unique identifiers. If either shows up on another host, you've found another ZSpeeding node. /debug/pprof/exposed on non-standard HTTPS ports on Chinese cloud IPs is a good hunting pattern for sister infrastructure.
Intelligence pivots
- Monitor the exposed
https://101.33.117.200:40804/debug/pprof/endpoint for configuration changes — when the uptime counter resets, something has been redeployed. - Monitor
crt.shfor any newagile-proxy/L=Xiamenself-signed certs on Chinese cloud IPs. - Track the
fanyiguangGitHub account for new module tags — therawtextversioning (v0.0.0-20250129161029) tells us releases are commit-timestamped, so new private releases will surface in any sister box's pprof graph.
MITRE ATT&CK
Historical (ValleyRAT C2 phase)
T1071 · T1090 · T1571 · T1583.003
Current (ZSpeeding proxy phase)
T1090.003 · T1205 · T1001.003 · T1571 · T1573
IOCs
Infrastructure
101.33.117.200 Target IP (Tencent Cloud HK)
101.33.117.200:32080 SOCKS4A plaintext
101.33.117.200:40003 VLESS+REALITY (DingTalk SNI)
101.33.117.200:40018 Silent listener
101.33.117.200:40338 gRPC TLS (cert created 2026-04-07)
101.33.117.200:40801 VLESS+REALITY (DingTalk SNI)
101.33.117.200:40803 VLESS+REALITY (Alibaba CDN SNI)
101.33.117.200:40804 agile-proxy pprof (EXPOSED)
101.33.117.200:40820 Silent listener
101.33.117.200:43080 SOCKS4A over TLS
Binary identifiers
/usr/local/bin/ZSpeeding Binary path
/etc/zsp/ Config directory
/etc/zsp/101.33.117.200.conf Config file (IP-as-filename pattern)
github.com/fanyiguang/rawtext Private SNI-simulation Go module
github.com/fanyiguang/agile-proxy Public proxy tool (repo of origin for cert O=)
Attribution anchors
fanyiguang GitHub handle
52657276 GitHub user ID
pengjunwen / 彭俊文 Real name (Git commit history)
2397711850@qq.com QQ email (Git commit history)
Xiamen, Fujian, CN Self-reported location (agile-proxy cert)
Historical (ValleyRAT C2 phase)
101.33.117.200:6666 Former C2 (now filtered)
101.33.117.200:8888 Former C2 (now filtered)
Malware: ValleyRAT (Gh0stKCP variant)
Actor: Silver Fox APT
GHOST — Breakglass Intelligence "One indicator. Total infrastructure."