A MAAT/AppSketch signature named "WARP on CF Edge" identifies Cloudflare WARP by matching destination IP against Cloudflare's published WARP anycast CIDR ranges (both IPv4, e.g. 162.159.192.0/24, and IPv6, e.g. 2606:4700:d0::/48) AND IP protocol UDP (ip.proto=17), while explicitly excluding destination port 443 (not_flag on a dstport=443 condition) — implying a separate rule is needed to catch WARP traffic that uses port 443.
"signature_name": "WARP on CF Edge" ... "ip_cidr": "162.159.192.0/24" ... "low_boundary": 17, "up_boundary": 17 ... "attribute_name": "dstport", "port": {"port": "443"} ... "not_flag": 1 ... "app_name": "WARP", "description": "WARP provides anonymous browsing experience, operated by Cloudflare."
Defense implications
- The rule explicitly excludes destination port 443, meaning a WARP-style tunnel masquerading as HTTPS on 443 to a Cloudflare anycast IP may not match this specific signature — but a companion port-443 rule should be assumed to exist and verified before relying on this gap.
- Static, well-known cloud-provider anycast CIDR ranges (Cloudflare, in this case) are trivial to enumerate and hard-code into a blocklist; a transport that tunnels through such ranges for domain-fronting-style cover should not assume the provider's public IP space is unmonitored.
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.
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.
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.
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.