A MESA Lab student's monthly report (advisor names redacted) records a month of work building a Psiphon detection pipeline: researching Psiphon VPN client behavior, constructing features from Psiphon session behavior, compiling Psiphon server-IP features, classifying suspicious server IPs from offline logs, and designing a Psiphon server-IP identification scheme — directly corroborating the taxonomy's cybernarrator/vpn-thwarting Psiphon3 IP-harvesting pipeline at the R&D stage.
调研Psiphon VPN客户端行为 ... 根据Psiphon会话行为构建特征 ... 调研并整理Psiphon Server IP特征 ... 基于离线日志对可疑Server IP分类 ... 基于已有工作设计Psiphon Server IP识别方案
Defense implications
- Avoid session-timing/behavioral patterns that resemble Psiphon's client, since GFW-adjacent research explicitly builds a server-IP classifier from offline flow-behavior clustering rather than payload inspection alone.
Related findings
For the M22 project (domestic-China-labeled training ticket, but M22 is elsewhere confirmed as a Myanmar deployment), Geedge explicitly instructs trainers to describe 'Cyber Narrator' only as a black-box ML capability, to avoid revealing the internal domain tsg.bj.internal.geedge.net, and to omit the company logo from training materials — i.e. deliberate concealment of Geedge's involvement and internal infrastructure from the training audience.
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'.
CyberNarrator's flink-stream-schedule-platform runs its own volumetric-DDoS "sketch" detection consumer (DosSketchEtl, wired in via business.properties' dos.sketch.etl.class) that is architecturally separate from Galaxy's own storm-based DoS pipeline. Each Kafka message is a batched detection window (sketch_start_time, sketch_duration, attack_type) carrying a nested report_ip_list that the ETL explodes into one record per flagged source/destination IP pair with session, packet, and byte counters, each tagged with the originating "sled" appliance IP and data center — i.e. detection happens upstream on distributed sensor appliances that emit periodic aggregate sketches rather than raw flow records, and this stream-schedule platform is a generic reflection-based Flink job runner (one Schedule implementation class instantiated per business.properties entry) reused across CyberNarrator's ETL jobs.
The DOS-SKETCH-RECORD Kafka input topic CyberNarrator's flink-stream-schedule-platform consumes from is SASL-authenticated with a hardcoded, product-branded credential (redacted here — see evidence_quote note) against internal brokers on port 9094 — the password itself embeds the Galaxy product name and an apparent 2019 provisioning year — which, together with cn-web/cn-admin's dedicated (if still-unimplemented) net.geedge.modules.galaxy.controller.GalaxyController class already seen alongside GalaxyProxyController/GalaxyResolveController, corroborates that CyberNarrator's backend infrastructure was bootstrapped under and remains operationally tied to the Galaxy platform rather than being a fully independent product line.
license-admin-api's actual controller/util code shows CyberNarrator's HASP licensing is per-feature, not a single product-wide dongle check — every operation (C2V generation, V2C license upload, status query, verify) is scoped by a caller-supplied vendorCode + featureId pair against the Aladdin/Thales Sentinel HASP SDK, and the query-format XML schemas expose a license object model of hasp/feature/product/vendor plus a license_manager block carrying host_fingerprint, hostname, OS, uptime, and IP — meaning individual CyberNarrator capabilities can be independently entitled/revoked per customer and the license is host-fingerprint-bound (requiring a fresh C2V/V2C exchange to move to different hardware), not a simple boolean unlock.
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.