A TSG-OLAP Storm topology (galaxy/tsg_olap/relationship-gtpc-user, class GtpRelation.java) builds a live correlation table between GTP-C (mobile-carrier GPRS tunneling control-plane) tunnel identifiers/TEIDs and user sessions, streaming from Kafka into HBase — a mobile-network subscriber-correlation capability structurally analogous to the RADIUS-based correlation already documented under CyberNarrator's Pakistan deployment, but implemented as a general-purpose TSG-OLAP component rather than a single named/branded product.
Repo galaxy/tsg_olap/relationship-gtpc-user.bundle. Commits: "GTPC初始版本" (initial GTPC version), "上下行teid" (uplink/downlink TEID), "线上版本" (production version, 2023-05-23). Files: src/main/java/com/zdjizhi/topology/GtpRelation.java, com/zdjizhi/pojo/Gtp.java, com/zdjizhi/utils/hbasepackage/HbaseSink.java
Defense implications
- TSG's mobile-carrier deployments can correlate GTP-C tunnel endpoint IDs (TEID) to user sessions independently of the RADIUS-based CyberNarrator pipeline — circumvention traffic traversing a mobile carrier network under TSG should be assumed identity-correlated via GTP-C control-plane signaling even where RADIUS/AAA correlation is absent.
Cited artifacts
mesalab_git—galaxy/tsg_olap/relationship-gtpc-user.bundle(git-commit-log)
Provenance pointers only — no leak content is rehosted. Raw material: Enlace Hacktivista.
Related findings
relationship-gtpc-user derives a single per-subscriber correlation key as Hashkey = md5(IMEI + IMSI + phone_number + vsys_id) from mobile-core GTP-C signaling, and a separate per-tunnel key gtp_uuid = md5(uplink_teid + "|" + downlink_teid). On every update it writes not just the primary user<->TEID row (tsg_galaxy:relation_user_teid) but up to four additional secondary-index rows into tsg_galaxy:gtpc_knowledge_base, one per identifier (IMEI, IMSI, phone number, APN) with a type-digit prefix ("0"/"1"/"2"/"3") and — for phone number and APN — the value's characters reversed before use as the row key, a range-scan-friendly key design that lets any of the four identifiers be used to look up the associated tunnel/session independently.
log-subscriber-hbase-datacenter is a Storm topology that, on a 300-second tick, scans a "national center" HBase cluster (national.hbase.zookeeper.servers) for subscriber_id/account rows changed in that window and replicates them into a separate "branch/regional datacenter" HBase cluster (center.hbase.zookeeper.servers, table sub:subscriber_info) — confirming a two-tier, hub-and-spoke data-federation architecture where subscriber-account correlation data is centrally maintained at a national level and periodically pushed down to per-datacenter local copies for regional/site-level querying.
radius-relationship-hbase and relationship-gtpc-user both ship byte-identical plaintext, hardcoded Kafka SASL credentials (a fixed admin username, product-branded password) in their default_config.properties — the same static credential shared verbatim across at least two independent TSG-OLAP pipeline components rather than injected per-deployment.
radius-account-knowledge decrypts its Kafka SASL credentials at runtime using a jasypt StandardPBEStringEncryptor whose password is the hardcoded literal string "galaxy", compiled directly into RadiusKnowledgeConfig.java — the same string used as the internal product/platform name throughout this corpus (Galaxy / tsg_galaxy HBase namespace), reused here as a shared symmetric secret rather than a deployment-specific one.
radius-relationship-hbase (galaxy/tsg_olap) builds a bidirectional, MD5-keyed RADIUS accounting index in HBase — a framed-IP-to-account table and its account-to-IP mirror — so any subscriber account or assigned IP can be looked up in O(1) from either direction, per multi-tenant vsys_id. Each direction is fronted by a Guava write-through cache (10M-entry cap, 24h TTL) so lookups do not hit HBase on the hot path.
radius-account-knowledge's MapCompletedFunction explicitly prefers the RADIUS acct_multi_session_id field over acct_session_id when both are present in an accounting record, specifically to keep a single logical session identifier stable across events that would otherwise fragment it (e.g. re-authentication, mobility/roaming, NAS handoff) — a deliberate design choice for session-identity continuity rather than a default library behavior.