TSG runs an automated program named 'vpn-thwarting' that calls the CM management API hourly to push freshly-learned Psiphon3 server IPs into a live blocklist object (dynamic_psiphon_ip); at the time of this incident the object held roughly 70,000-73,000 IPs, sourced from a companion automated-learning system referred to as 'CN'.
vpn-thwarting程序每1小时调用CM的API接口向dynamic_psiphon_ip对象中推送item...验证该object中ip数量为72874，恢复正常
Defense implications
- Psiphon-style circumvention that relies on a large but eventually-enumerable pool of server IPs faces a fully automated, hourly-refreshed adversary at this scale -- server-IP churn needs to outpace an hourly harvest-and-block cycle, not just exist.
Related findings
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 Python automation script authenticates to a TSG management API (/v1/user/login, /v1/policy/object/{id}/item?type=ip|fqdn&page_size=500000) and PUTs new IP entries into an existing policy object -- the concrete mechanism matching taxonomy's description of CyberNarrator's 'vpn-thwarting' pipeline pushing freshly-learned server IPs into a live blocklist object, and confirming policy objects are paged at up to 500,000 items.
The same GEEDGE employee handbook dates the launch of 网络叙事者 (CyberNarrator) to April 2021, and separately states the company's products serve 18 data centers and carriers worldwide processing over 20 Tbps of traffic — the first primary-source confirmation of CyberNarrator's launch date and a company-stated global deployment-scale figure.
The galaxy/tsg_olap/dll-multipoint-aggregation repo defines a Flume-based multi-site log-aggregation pipeline with five parallel categories -- "active_defence", "connection" (call-detail/通联日志), "proxy", "security", and "radius" -- the last explicitly ingesting RADIUS data, corroborating that the CyberNarrator subscriber-correlation capability's RADIUS feed sits inside this broader TSG OLAP log-aggregation architecture rather than as a standalone system.
A Postman API collection titled '银河api' (Galaxy API) documents production query endpoints against the tsg_galaxy analytics backend, including dedicated 'radius日志标准查询' / 'raduis日志clickhouse查询' (RADIUS log queries) and 'Traffic Top Intercept Policies By Hits/Bandwidth' endpoints -- showing RADIUS-based subscriber correlation and interception-policy analytics are standard, generally-available query features of TSG's management API rather than a one-off built solely for the Pakistan deployment.
TSG's central ClickHouse analytics schema ('tsg_galaxy_v3', deployed on cluster 'ck_cluster') defines a 'session_record' table where every logged session carries subscriber_id, imei, imsi, phone_number, and apn fields alongside client/server geolocation and ASN -- showing that per-session subscriber-identity correlation is a built-in, standard field of TSG's core traffic-log schema (used for ordinary session_record, not a bespoke table), not an add-on limited to the already-documented Pakistan CyberNarrator deployment.