Geedge's AppSketch/MAAT signature store contains a large, actively-maintained catalog of per-app FQDN+IP blocking signatures for dozens of named consumer VPN apps (StartVPN, DotVPN, VPNLite, BullVPN, RapidVPN, QuarkVPN, AdGuardVPN, BulletVPN, NotVPN, LetsVPN, PandaVPN, ACE VPN, BetternetVPN, HulaVPN, ThunderVPN, TurboVPN, and more, patch-dated across 2024), each tagged category='networking'/subcategory='tunnels' (or similar) with a deny_action of packet drop (sometimes with TCP RST), and some apps additionally flagged characteristics='evasive' with elevated risk scores; several apps' FQDN lists show the same domain-generation pattern (random word + .xyz/.info) later seen automated in a companion detection script.
"app_longname": "PandaVPN_Patch06" ... "category": "business-systems", "subcategory": "auth-service" ... "characteristics": "evasive", "deny_action": {"method": "drop", "send_icmp_unreachable": 1, "send_tcp_reset": 1} ... fqdn patterns: "$api.pandavpnpro.com", "*.hijy.xyz", "*.panskeet.xyz", "*.puln.xyz", "$api.quiev.xyz"
Defense implications
- Any consumer VPN app with a recognizable name, fixed API domain, or predictable server-provisioning pattern is a near-certain target for a dedicated named signature within weeks to months -- generic 'looks like a VPN app' obfuscation is not sufficient; the adversary signature-matches specific products by name.
- Randomly-generated subdomains on a small set of cheap TLDs (.xyz, .info) are themselves a fingerprint the adversary already pattern-matches on (see companion finding on the VPNLite auto-classification script) -- avoid this exact DGA shape.
Related findings
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.
The batch contains 200+ individual MAAT/AppSketch signature JSON files, most defining FQDN- and/or destination-IP-based blocking rules for a single named commercial/consumer VPN app each (LetsVPN, TurboVPN, QuarkVPN, PandaVPN, StarkVPNReloaded, VPNTurkey, BitdefenderVPN, SnapVPN, SuperSpeedVPNProxy, SuperUnlimitedVPN, CafeVPN, and dozens more), each carrying a build date — the dated files span June 2024 through November 2024 — showing a large, actively and continuously maintained per-app VPN signature catalog rather than a static blocklist.
Geedge's MAAT/AppSketch signature system contains a dedicated, dated ruleset naming Lantern by product: signature_id 7312 "Lantern_fqdn_20241104" matches common.server_fqdn against the literal keyword "$lantern.io", and a companion signature_id 7240 "Lantern_ip_20241104" matches ip.dst against a static list of 1,604 individual IPv4 addresses, both dated 2024-11-04. The same signature file appears twice in the leak at two different artifact paths (identical content, not independent corroboration). Independent whois verification of all 1,604 IPs (not itself present in the leak document -- done by the extracting analyst against current registry data) found they collapse into only 38 distinct /16 ranges, of which ranges totaling 86.7% of the IPs return an explicit Oracle Corporation whois org record (netnames like OC-195, OC-260, ORACLE-4, ORACLE-MY, ORACLE-SE, OPC1); the remaining 13.3% are unattributed legacy RIPE/APNIC-ERX blocks with no other org found, consistent with the same historical-Oracle-lease pattern as the confirmed ranges. The individual IPs are a stale point-in-time snapshot given Lantern's IP rotation, but the provider concentration is the durable signal: this enumeration was effectively a sweep of Oracle Cloud Infrastructure's address space, not a list of arbitrarily-located relays.
Live TSG session logs from an internal test bed (device 21426003 / XXG-TSG-BJ) show active Deny actions firing against named commercial VPN apps -- Super Unlimited VPN, BetternetVPN, TouchVPN, LetsVPN -- via dated signature patches (e.g. BetternetVPN_Patch01_20240812 through Patch06_20240920, SuperUnlimitedVPN_Patch05 through Patch10 within six weeks), and LetsVPN's block fires on a JA3 TLS fingerprint (LetsVPN_by_ja3) even when the SNI/Host is spoofed to www.bytedance.com.
A large set of individually-dated per-product signature files shows at least 31 distinct named commercial VPN apps under active, ongoing detection engineering (SecureVPN, LetsVPN, BetternetVPN, SuperUnlimitedVPN, TunnelBear, AtlasVPN, TurboVPN, UrbanVPN, GeckoVPN, VPNUnlimited, BitdefenderVPN, QuarkVPN, FlyVPN, HulaVPN, SurfVPN, BulletVPN, BeePassVPN, SnapVPN, WhitehatVPN, LunaVPN, SuperNetVPN, GitiVPN, CleanerAntivirusVPN, V2VPN/V2Netvpn, 7VPN, and country-branded VPNIndia/VPNCanada/VPNIndonesia/VPNKorea apps), each with multiple detection vectors per app (destination-IP ranges, FQDN, DNS QNAME, TLS cert issuer, JA3, WireGuard-protocol matching, ISAKMP/IKE matching, raw TCP payload); one file shows the resulting policy rule object wired directly to an explicit deny action.