A harvested JSON dataset matches Windscribe VPN's own internal server-list API format exactly (dns_hostname on windscribe.com, node hostnames on whiskergalaxy.com, WireGuard public keys per node, OpenVPN x509 certificate names, and per-node latency-probe ping_host URLs) — i.e. a commercial VPN provider's full server infrastructure (IPs, WireGuard pubkeys, ping/latency endpoints) has been scraped/harvested wholesale, the same pattern documented for the CyberNarrator/ vpn-thwarting Psiphon3 pipeline but applied to a different provider (Windscribe).
"dns_hostname": "us-central.windscribe.com" ... "wg_pubkey": "pASG4FD9LwOfJukT\/wYbUF10gD6v8DVuv5hrNbiOnHQ=" ... "wg_endpoint": "dfw-86-wg.whiskergalaxy.com" ... "ping_host": "https:\/\/us-central-014.whiskergalaxy.com:6363\/latency"
Defense implications
- VPN-server-list harvesting is not limited to Psiphon — treat any provider's public/semi-public server-discovery API as a target for wholesale scraping and IP-blocklist seeding, not just the specific providers already known to be targeted.
Related findings
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.
MESA Lab group-meeting notes record parallel R&D on a whitelist-filtering module and a project to fingerprint cloud-hosted circumvention/proxy infrastructure at the IP-block (not single-IP) level, explicitly modeled on 2017/2019 academic 'Bulletproof-hosting IP block' research; the notes also mention local packet captures that found Psiphon IPs, the domain types/ratios Psiphon uses, and active-probing behavior with candidate detection countermeasures.
The same T1/NTC node config (ntcconf/t1conf/main.conf, K18/Astana/Kazakhtelecom) exposes concrete DPI enforcement toggles: a SYNACK_OR_RST switch and SEND_INJECT_PKT flag governing active TCP-response/packet-injection behavior; ASN- and IP-based blocklists (ASN_MAAT, IPD_DYN_MAAT, IPD_STATIC_MAAT) refreshed from MAAT/Redis on a 1-second effect interval; a dynamic blacklist with a 180s timeout; explicit protocol-blocking switches for BitTorrent (DHT/uTP) and eMule (Kad); and TLS metadata harvesting including certificate SAN fields (NTC_SSL_COLLECT, collect_san_sw=1) streamed to a Kafka topic.
A dedicated AppSketch/MAAT signature object named 'Psiphon-Volunteer-IP' (signature_id 4054) blocklists specific IPv4/IPv6 CIDR ranges by ip.dst regardless of port (192.122.190.0/24, 2001:48a8:687f:1::/64, 141.219.0.0/16, and more), i.e. Geedge maintains infrastructure-level blocking of known Psiphon volunteer-hosted proxy server ranges rather than relying solely on app/protocol fingerprinting.
A signature object dated 2024-10-28 and named 'VPN servers in Russia' (fqdn variant signature_id 6217, IP variant 6216) blocklists specific FQDNs (api.tap2free.net, vpnlocal.app) and a companion IP-address object, showing Geedge curates geography-scoped VPN-infrastructure collections by country rather than only per-app-brand signatures — i.e. any server identified as VPN infrastructure hosted in a given country can be swept into a blocklist independent of which client app uses it.
An exported IP-blocklist object with the literal header format 'IP[Single||/CIDR||-Range]#[Port]' and 5,511 entries, each a single IP with port range 0-65535 (i.e. full-IP block regardless of port), includes 185.220.101.77 — an address in the 185.220.101.0/24 block long associated with Tor exit-relay operators — suggesting at least part of this object targets Tor exit infrastructure by IP rather than by protocol fingerprint.