Three artifacts contain complete server-side infrastructure catalogs for commercial VPN provider families rather than just observed traffic: (1) a JSON dump of 38 VPN server nodes for the WaselPro/BVPN/SmokeTunnel/iWasel brand family, each with a full CA certificate, an SSH private key (for stunnel obfuscation), an IPsec pre-shared key, and listen IP, spanning US/EU/Asia/Middle East; (2) a ~150-datacenter API dump from VPN infrastructure reseller pointtoserver.com (data center id/name/ping-IP/hostname, reseller_id 2); (3) a similarly-structured per-country VPN config/cert bundle list referencing flag_url assets from bgnmobi.com. Together these show systematic collection of VPN providers' backend server credentials and infrastructure maps, not just client-side traffic fingerprints.
"domain": "ca.us.waselpro.com", "name": "US-SanJose-PrivateIP", "ssh_user_key": "LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQ..." [RSA PRIVATE KEY], "ipsec_shared_secret": "oorg5y8ajugiwgc" ... pointtoserver.com: {"id": 20, "name": "RapidSwitch_SD_UK_Maidenhead", "host_name": "dc-20.pointtoserver.com"}
Related findings
The TSG session_record schema in use at the Myanmar (YGN-MYTEL) deployment includes, in the same per-session record, both TLS-interception status fields (proxy_pinning_status, proxy_intercept_status, proxy_cert_verify, proxy_passthrough_reason, proxy_intercept_error) and individual-subscriber-identity fields (subscriber_id, imei, imsi, apn, phone_number) -- confirming MITM/certificate-interception capability and per-person subscriber correlation are built into the same live logging pipeline at an actual export site, not just described separately in marketing/config material.
A raw, verbatim capture of ProtonVPN's own "LogicalServers" API response (127 server entries with entry/exit IPs, WireGuard X25519 public keys, and country/city metadata) sits alongside a MAAT "ProtonVPN_ip"/"ProtonVPN_fqdn" signature in the same corpus, indicating the operator harvests VPN providers' own server-list APIs to seed IP/domain blocklists -- the same methodology documented for the Psiphon-IP-harvesting "vpn-thwarting" pipeline (CyberNarrator), here shown applied to a second, unrelated VPN provider (ProtonVPN).
Across dozens of individual signature-rule JSON files in this batch, at least 40 distinct named commercial VPN products carry dedicated detection signatures (by IP src/dst, FQDN, JA3 hash, or protocol-specific payload): BeePassVPN, BetternetVPN (separate isakmp/ja3/WireGuard sub- signatures), BigMamaVPN, BravePrivateVPN, ExpressVPN (JA3 + UDP-payload variants), FlyVPN, hidemevpn (OpenVPN UDP payload), JourneyVPN, JumpjumpVPN, LetsVPN (JA3), Psiphon3 ("psiphon3vpn_serverip"), QuarkVPN, SecureVPN, SuperUnlimitedVPN, TurboVPN, VPNHero, VPNTurkey, and others, each dated/versioned (e.g. "_20240812") indicating an ongoing signature-maintenance pipeline rather than a one-off ruleset.
Session-log exports from a Beijing test/demo TSG device ("XXG-TSG-BJ") show live "Deny" enforcement actions (security_rule_list "Deny_VPNHero", "deny_TowerVPN") against traffic the app-ID engine classified with nested app chains "VPNHero" and "OPENVPN.TowerVPN.Psiphon Provider.Psiphon-Server" -- i.e. TowerVPN is specifically tagged internally as riding on Psiphon infrastructure, and both it and VPNHero are actively blocked, not just logged, on this device.
An internal methodology memo for the '新疆省口项目' (Xinjiang provincial-gateway project) and '联通IDC项目' (Unicom IDC project) states both rely on 现有的系统(TSG与CN) (the existing TSG and CN [CyberNarrator] systems) to Block/Monitor/identify mainstream apps, and describes a largely manual signature-engineering workflow -- download the target app, capture traffic with 科莱(Colasoft Capsa)/Wireshark, extract fingerprint fields (http.host, http.user_agent, quic.sni, ssl.handshake.extensions_server_name) by hand, and register a per-app signature -- extending CyberNarrator's documented role beyond Psiphon-IP-harvesting/Pakistan subscriber correlation into general domestic app-blocking alongside TSG.
A MESA Lab monthly report states that adjustments to a VPN-detection module accumulated over 10,000 Psiphon3 server IPs and delayed a Psiphon3 client's ability to get online by at least 3 minutes in the researchers' test environment, an earlier-stage data point consistent with the much larger-scale (~70-73K IP) 'vpn-thwarting'/CyberNarrator Psiphon-harvesting pipeline documented elsewhere in this corpus.