A generic RADIUS/AAA-sniffing traffic-engine plugin (NTC_RADIUS_PLUG, default SERVICE_ID 0xA2) parses live RADIUS Access/Accounting packets off the wire and extracts User-Name, Calling-Station-ID (the subscriber's phone number), Called-Station-ID, Framed-IP-Address, NAS-IP, Acct-Session-Id and related attributes, tags each record with a global stream-trace ID, and streams it to Kafka topic 'RADIUS-RECORD-LOG'. This is a concrete source-code-level match for the carrier RADIUS/AAA-ingestion mechanism the taxonomy attributes to the CyberNarrator subscriber-identity-correlation component (Pakistan deployment, Jazz/Zong/Ufone/Telenor), though this particular file is generic/unbranded rather than explicitly named CyberNarrator.
case CALLING_STATION_ID: cJSON_AddStringToObject(radius_debug, "radius_calling_station_id", (char *)(radius_body->attribute[i].value)); cJSON_AddStringToObject(radius_info_object, "radius_calling_station_id", (char *)(radius_body->attribute[i].value)); break;
Defense implications
- This correlation happens at the carrier's own RADIUS/AAA layer, entirely outside any client-observable traffic feature — no transport-protocol design choice mitigates it; it ties phone-number identity to a session independent of which circumvention protocol is used on top.
Cited artifacts
mesalab_git—PanGu/ntc_radius_plug.bundle(git-commit-log)
Provenance pointers only — no leak content is rehosted. Raw material: Enlace Hacktivista.
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.
A MAAT/AppSketch signature literally named "Psiphon-Server-IP" blocks by destination IP against a list of 1,300+ IPs (the extracted text is truncated at ~200KB so the true list is likely larger, consistent with the taxonomy's cybernarrator/vpn-thwarting note of ~70-73K harvested Psiphon IPs), directly corroborating that the CyberNarrator/vpn-thwarting Psiphon3 IP-harvesting pipeline feeds its output straight into a production MAAT/AppSketch blocking signature.
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.
An internal TSG operations/troubleshooting manual lays out TSG's full traffic pipeline (NIC -> mrzcpd/marsio capture driver -> sapp DPI engine -> firewall/proxy(KNI->TFE)/active-defense/WAN-NAT policy branches) and shows engineers using maat_redis_tool to pull the live Redis-synced blocking policy tables (TSG_SECURITY_COMPILE, TSG_OBJ_IP_ADDR, TSG_OBJ_APP_ID) and filter them by numeric policy/object ID to debug why a block rule isn't firing.
The internal 'MAAT网络流处理配置统一描述框架' engineering manual (v3.1.20, author 郑超, 2021) documents MAAT's Redis-synced rule-compilation framework and its RuleScan/Hyperscan-based pattern-matching engine (libmaatframe.so / librulescan), and records that RuleScan's fast-scan feature caused a production outage on 2019-03-19 and has been disabled ever since.