A single AppSketch/MAAT signature bundle for Windscribe VPN fuses four independent detection techniques in production: an OpenVPN-handshake payload signature (fixed hex bytes at a specific byte offset/depth plus an exact packet-length check), a TLS certificate subject_organization_name match on the literal string 'Windscribe', a JA3 TLS-ClientHello fingerprint hash, and DNS query-name matching against 100+ individually enumerated obfuscation/CDN-rotation domains (windscribe.com plus many totallyacdn.com and whiskergalaxy.com hostnames).
"signature_name": "windscribe_openvpn_payload" ... "keywords": "00000001662a", "offset": 73, "depth": 78 ... "signature_name": "windscribevpn_tls_ja3" ... "keywords": "8fd202d24a15997f2d08693f950f8931" ... "signature_name": "windscribe_cert", "attribute_name": "ssl.handshake.certificate.subject_organization_name" ... "keywords": "Windscribe"
Defense implications
- A circumvention transport must defeat payload/handshake analysis, JA3 (or JA4) TLS fingerprinting, TLS certificate field inspection, and DNS-domain enumeration simultaneously -- defeating only one signal (e.g. randomizing JA3) is insufficient if the other three still match.
- Assume any fixed set of CDN-fronting/rotation domains will eventually be exhaustively enumerated (100+ observed here) and hard-coded into a DNS qname blocklist; domain rotation alone, without unpredictable generation, is not durable camouflage.
- Avoid leaving any static magic-byte pattern at a fixed offset in the first packet of a handshake (as OpenVPN's early bytes do here) -- this is trivial to signature-match.
Related findings
Exported AppSketch/MAAT signature-object JSON shows named per-VPN detection rules combining multiple independent vectors: CyberGhost's WireGuard variant is matched by a hex UDP-payload pattern (04000000*), destination port 1337, and ip.proto=17 together (signature cyberghostvpn_wireguard); Windscribe's OpenVPN control channel is matched by two offset-anchored hex byte patterns plus an exact 86-byte payload length (windscribevpn_openvpn_payload); and ExpressVPN is matched independently via a literal JA3 hash (ssl.analysis.ja3), FQDN strings (expressapisv2.com, www.expressvpn.works), and a large enumerated IP list (700+ individual ip.dst entries observed before the 200KB text-extraction cutoff).
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.
Beyond the Lantern-specific rules, this batch contains ~40 individually-dated JSON signature files from the same MAAT/AppSketch rule format, each targeting one named VPN/circumvention client by FQDN, destination IP, TLS JA3 hash, or certificate issuer: Signal, Orbot, Cloudflare WARP (including a MASQUE-specific variant combining an app_id classifier with an FQDN condition), ExpressVPN (matched by a literal JA3 hash plus a separate FQDN rule), ProtonVPN/ProtonMail, TurboVPN, QuarkVPN, LetsVPN, BetternetVPN, Browsec, GeckoVPN, HulaVPN, JumpJumpVPN, MouseVPN, NotVPN, SecureVPN, StarkVPNReloaded, SuperUnlimitedVPN, TowerVPN, TrustzoneVPN, USAVPN, VPNIndia/VPNLite/VPNPro/VPNTurkey, FlyVPN, ACE VPN, F1 Rockets VPN, and the Chinese gaming accelerator biubiu加速器. Dates cluster tightly (e.g. many on 2024-08-09, others 2024-09/10/11), indicating an active, continuously-updated per-app signature production pipeline rather than a static list.
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.
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.
Dozens of near-identical MAAT/AppSketch-style signature-definition files in this batch each target one named commercial VPN app/service (ProtonVPN, HotSpot VPN, SuperUnlimitedVPN, jumpjumpVPN, BetternetVPN, NotVPN, VPNLite, SymlexVPN, etc.), matched via FQDN suffix, destination IP list, and/or TLS JA3 hash. The same "SuperUnlimitedVPN" signature recurs with new signature_ids/dates roughly monthly (2024-06, -09, -10, -11), showing this is a continuously-maintained, actively-updated VPN-detection pipeline rather than a one-off snapshot.