IT
InstaTunnel Team
Published by our engineering team
The Shadow Tunneling Crisis: Why Your 2026 Perimeter Is Already Broken
The Shadow Tunneling Crisis: Why Your 2026 Perimeter Is Already Broken
The “corporate perimeter” is no longer a useful concept. For years, Chief Information Security Officers focused their defenses on blocking unauthorized SaaS applications — the Shadow IT problem of the early 2020s. By 2026, a more insidious threat has taken its place at the top of the enterprise risk register: Shadow Tunneling.
Where Shadow IT meant employees using unapproved web apps, Shadow Tunneling means employees — and attackers — punching direct, encrypted holes through the corporate firewall to expose internal services to the public internet. Whether it’s a developer using ngrok to demo a local build, or a malicious actor using a cloudflared daemon to maintain persistence, these shadow tunnels are the invisible backdoors of the modern era. They bypass your WAF, blind your DLP, and render your IDS irrelevant — all without requiring administrative privileges.
This piece explores how we got here, why traditional IP-based defenses have failed, and the two most important tools security teams are deploying to fight back in 2026: JA4+ TLS fingerprinting and eBPF kernel-level monitoring.
Part 1 — How the Perimeter Died
From Shadow SaaS to Shadow Infrastructure
The castle-and-moat model relied on a simple premise: trust everything inside the network, block everything outside. That moat has now been bypassed by thousands of tiny, encrypted bridges — each one opened in seconds by a developer frustrated with VPN friction.
Tools like ngrok, Cloudflare Tunnel, Tailscale, and a growing ecosystem of self-hosted alternatives (Pangolin, built on WireGuard, emerged as a notable option in 2025–2026) allow a single terminal command — often without elevated permissions — to create a routable public URL for any private service. The awesome-tunneling repository on GitHub tracks over a hundred such tools, with new entries appearing regularly enough that the maintainer added a 100-star minimum requirement in early 2026 just to manage the volume.
The threat isn’t hypothetical. When a developer runs ngrok http 3000, they are publishing a port directly to the internet, cutting entirely around the corporate security stack. The tunnel’s end-to-end encryption means that even if the traffic passes through monitored infrastructure, the contents are invisible to inspection tools.
Why IP Blocking Fails
The obvious response — block the known IP ranges of tunneling providers — has been effectively dead for years. Modern tunneling services use Anycast networks and large pools of rotating addresses. By the time a blocklist propagates, the tunnel has migrated to a new node. Blocking an IP in 2026 is like trying to catch smoke with a fishing net.
This forces defenders to shift their frame of reference entirely — from where the traffic is going to what the traffic looks like.
Part 2 — JA4+ TLS Fingerprinting: Identifying the Invisible
The Problem JA4 Was Built to Solve
Every TLS connection begins with a ClientHello handshake — an unencrypted opening message in which the client declares its supported TLS versions, cipher suites, extensions, and other parameters. This message is a fingerprint. Different software — Chrome, curl, a Go HTTP library, an ngrok agent — produces distinct ClientHello messages, even when communicating with the same destination.
The original fingerprinting standard, JA3, worked by hashing these parameters into a 32-character MD5 string. It was widely adopted and proved effective for years. But in 2023, Google updated Chromium to randomize the order of TLS extensions on each connection — a privacy measure that also shattered JA3’s stability, generating billions of possible hashes for what was functionally the same browser.
What JA4+ Is and How It Works
In September 2023, John Althouse at FoxIO released JA4+, a modular suite of network fingerprinting methods explicitly designed to survive randomization. The core JA4 fingerprint for TLS client traffic follows a structured, human-readable format:
JA4 = [protocol+version][sorted_cipher_hash][sorted_extension_hash]
For example, a fingerprint might look like: t13d1516h2_a0e9c7f32f1c_e5b1d8a03d9a
The critical innovation is sorting. Before hashing, JA4 sorts both cipher suites and extensions alphabetically. This means that Chrome’s randomized extension ordering no longer produces a different hash on every connection — the sort step normalizes the output, producing a stable fingerprint regardless of presentation order. It also defeats a technique known as “cipher stunting,” where clients randomize cipher ordering specifically to evade JA3-based detection.
The JA4+ suite extends well beyond TLS:
JA4 — TLS client fingerprint
JA4S — TLS server response fingerprint
JA4H — HTTP client fingerprint
JA4X — X.509 certificate fingerprint
JA4SSH — SSH traffic fingerprint
JA4T / JA4TScan — TCP fingerprinting
The base JA4 fingerprint is open-source under the BSD 3-Clause licence. The broader JA4+ suite is licensed under the proprietary FoxIO Licence 1.1, which permits internal business use but requires a commercial arrangement for monetization.
Industry Adoption
JA4+ adoption among major platforms has been rapid. Cloudflare integrated JA4 into its bot management and Zero Trust stack — building a dedicated Rust-based TLS parser (client-hello-parser) to expose JA4 fingerprints across its firewall rules, Workers, and analytics systems. AWS, VirusTotal, and NetWitness have all adopted the standard. VirusTotal specifically allows analysts to pivot on JA4 fingerprints via its behavior_network file search modifier, enabling threat hunters to identify malware families sharing the same TLS library even when IP addresses and domains change.
Cloudflare’s enterprise bot management exposes both JA3 and JA4 fingerprints directly in firewall rules. ngrok’s own platform now surfaces JA4 fingerprints via its Traffic Inspector, and supports rate-limiting buckets keyed to the JA4 fingerprint — making the fingerprint a native policy variable, not just an observability artifact.
Applying JA4+ to Shadow Tunnel Detection
This is where JA4+ becomes directly relevant to the Shadow Tunneling problem. Tunneling agents like ngrok, cloudflared, and their equivalents have distinct TLS handshake signatures — specific combinations of supported cipher suites, extensions, and ALPN values that differ from standard browsers or operating system TLS stacks.
Critically, renaming the executable doesn’t help. If a developer renames cloudflared to chrome.exe, the behavior of the TLS handshake remains identical to the real cloudflared agent. A browser Chrome produces a JA4 fingerprint consistent with Chromium. The renamed tunnel agent produces a fingerprint consistent with the Go TLS library underlying cloudflared. These are not the same string.
Security teams in 2026 maintain curated libraries of JA4 signatures for known tunneling agents — the FoxIO database is being built explicitly for this purpose — and can drop connections at the edge the moment a matching handshake is detected, regardless of destination IP. Unlike IP blocking, this approach remains effective even as tunneling providers rotate their infrastructure.
Part 3 — eBPF: The Undercover Agent Inside the OS
The Limits of User-Space Security
JA4+ operates at the network edge. But what about tunnels that never reach a monitored chokepoint — traffic that originates from a machine inside the network and exits directly? And what happens when an attacker has already achieved process-level access and can evade network inspection entirely?
This is where eBPF (extended Berkeley Packet Filter) changes the game.
eBPF is a technology built into the Linux kernel that allows sandboxed programs to run safely inside the kernel itself. Originally designed for low-level packet filtering, it has evolved into the foundational layer of modern cloud-native security. Its key properties for security use cases are: it requires no kernel modification or recompilation, runs with minimal performance overhead compared to user-space agents, and provides deep visibility into syscalls, network events, file access, and process execution — all in real time.
Tetragon and Falco: The Two Leading Tools
Two eBPF-based security tools have emerged as the standard in enterprise and cloud-native environments:
Tetragon, a sub-project of the Cilium project (now part of Cisco via its acquisition of Isovalent), provides eBPF-based security observability combined with real-time enforcement. It translates security policies specified in YAML into eBPF programs that run directly in the kernel, and is Kubernetes-aware — it understands namespace and pod metadata, not just raw syscalls. Tetragon can detect the exact moment a process attempts to open a network socket, correlate that event with the process’s namespace, ancestry, and file access history, and terminate the process before the first byte of data exits the host. Its enforcement mechanism operates via BPF LSM (Linux Security Module) hooks, which are synchronous — the kernel decision happens inline, not after the fact.
Falco, an open-source CNCF project, is a behavioral activity monitor that audits the system at the Linux kernel layer via eBPF. Where Tetragon focuses on enforcement, Falco focuses on detection and alerting — flagging anomalous behavior against a library of rules and forwarding alerts to SIEM platforms, Slack, PagerDuty, or custom webhooks via its Falcosidekick integration layer. Falco operates as a DaemonSet in Kubernetes environments, ensuring every node in the cluster is monitored. Its eBPF driver (the modern_bpf driver) is the recommended mode on modern distributions.
These tools are complementary. As ARMO (makers of Kubescape) put it clearly: Falco for detection, Tetragon or KubeArmor for detection plus enforcement.
The Kill-at-Source Strategy
When applied to shadow tunnel detection, eBPF enables what some SOC teams are calling “kill at source.” The workflow looks like this:
An eBPF program attached to the relevant syscall tracepoints detects that a process is attempting to open a TUN/TAP interface — the kernel-level mechanism underlying most VPN-style tunnels.
Tetragon correlates this event: Has this process recently spawned a shell? Does it have unusual file-access patterns? Does its binary hash match a known tunneling agent?
If the policy is met, the process is terminated at the kernel level — not via a kill signal sent from user space (which can be caught or delayed), but via the BPF LSM hook that denies the underlying syscall.
The key advantage over user-space agents is that this approach cannot be bypassed by a process that has compromised the monitoring agent. The security is baked into the operating system layer itself. A developer cannot simply uninstall it.
Cisco’s integration of Tetragon into enterprise offerings has significantly accelerated adoption in production environments. The ability to deploy dynamic eBPF-based policies — and update them on the fly without rebooting or redeploying agents — was prominently demonstrated during the response to the xz utils backdoor (CVE-2024-3094), where eBPF programs were used to enforce mitigations within hours of disclosure.
Part 4 — The OAuth Subdomain Hijacking Threat
How Expired Tunnels Become Attack Vectors
Perhaps the most underappreciated risk in the shadow tunneling landscape is what happens after a developer closes their tunnel.
Tunneling services on free or low-friction tiers assign ephemeral subdomains: dev-app-123.ngrok-free.app, staging-preview.trycloudflare.com, and similar. When the developer closes their laptop, the tunnel dies — but the DNS record associated with that subdomain may still be live in external services.
Consider a developer who has registered their tunnel URL as the OAuth redirect URI in a GitHub App or a Stripe Webhook configuration. They finish work and close the tunnel. The subdomain becomes available again. A malicious actor who claims that subdomain via the tunneling provider’s free tier now controls the endpoint that GitHub or Stripe believes is legitimate.
OAuth Redirect Hijacking in Practice
Recent security research published in the context of USENIX Security 2025 identified related vulnerabilities across integration platforms at scale. Researchers developed COVScan, a semi-automated testing tool, and found that among 18 popular consumer- and enterprise-facing integration platforms, 11 were vulnerable to Cross-app OAuth Account Takeover (COAT) attacks — including platforms operated by Microsoft, Google, and Amazon. While not exclusively a tunneling problem, the vulnerability class — expired or misconfigured OAuth redirect URIs — is directly enabled by the ephemeral subdomain model that tunneling services rely on.
The specific tunnel variant of this attack is well-documented in 2026: an attacker claims an expired tunnel subdomain that remains whitelisted in an Identity Provider (IdP) such as Okta or Azure AD, then triggers an authorization request. If the victim has an active SSO session, the IdP may issue an authorization code to the hijacked subdomain without the user ever seeing a login prompt — the prompt=none parameter in the authorization request achieves exactly this. The attacker exchanges the intercepted code for a session token and gains full access to the developer’s corporate identity.
CrowdStrike’s security team has similarly documented subdomain takeover as a live attack surface, noting that hijacked subdomains are used for phishing, malware distribution, and credential interception — all while operating under the appearance of a legitimate corporate domain.
Part 5 — The 2026 Defense-in-Depth Strategy
Outright blocking of all tunneling tools is increasingly impractical in engineering-heavy organizations. Developers need to expose webhooks for testing, share local builds for review, and iterate without waiting days for firewall change requests. The more productive posture is govern, don’t just block.
- Identity-Aware Tunneling at the Edge The era of anonymous tunnels is over for serious enterprise environments. The model that security-forward organizations are converging on: require OIDC (OpenID Connect) authentication at the tunneling layer itself, before any traffic reaches the internal resource.
Both ngrok’s enterprise tier and Cloudflare Access (which integrates with Cloudflare Tunnel) support this model natively. Cloudflare Access, for example, intercepts every request to a tunnel-exposed endpoint, issues a JWT based on the user’s corporate SSO identity, and forwards that JWT to the backend. The tunnel is no longer an anonymous pipe — it’s a policy enforcement point. Users must be authenticated against the corporate identity provider before a single packet reaches the internal service.
- DNS Sinkholing and Passive DNS Monitoring While IP blocking fails, DNS resolution remains a chokepoint. Blocking resolution for *.ngrok.io, *.trycloudflare.com, *.ngrok-free.app, and the control-plane domains of other common tunneling services prevents the agents from establishing the initial connection — they cannot “call home” to set up the tunnel if DNS for the control plane is sinkholed.
Complementing this, Passive DNS (pDNS) monitoring allows security teams to flag unusual subdomain patterns and identify when an internal machine is resolving tunneling-related domains, even before a connection is fully established.
- PKCE Enforcement for All OAuth Flows To address the OAuth subdomain hijacking risk, security teams should enforce PKCE (Proof Key for Code Exchange) across all authorization code flows — including server-side ones, where it was previously considered optional.
PKCE works by having the initiating client generate a cryptographic secret (code_verifier) and sending a hash of it (code_challenge) with the initial authorization request. When the authorization code is exchanged for a token, the original code_verifier must be presented. An attacker who intercepts the authorization code — by hijacking a tunnel subdomain — cannot exchange it for a token without the code_verifier, which exists only in the original, legitimate browser session.
Enforcing exact-string matching on redirect URIs (rather than pattern matching or wildcard rules) at the authorization server is the complementary control: it closes the open-redirect chains that allow attackers to exploit OAuth flows even without DNS-level hijacking.
JA4 Signature Libraries at the Edge
SOC teams should build and maintain curated JA4 fingerprint libraries for known tunneling agents and deploy them at the network edge. Because the JA4 fingerprint identifies the client TLS library, not the process name or destination IP, this detection survives renaming, IP rotation, and CDN-based obfuscation. A cloudflared client producing fingerprint t13d... at the TLS handshake layer will produce that fingerprint regardless of what the executable is named or which Cloudflare edge node it connects to.eBPF Runtime Policies for Process Behavior
Deploy Tetragon or an equivalent eBPF enforcement layer with policies that flag or block:
Processes opening TUN/TAP interfaces
Binaries that are not in the approved software inventory attempting outbound connections to known tunneling control-plane ranges
Processes that exhibit the behavioral signature of a tunneling agent (e.g., maintaining a persistent outbound TCP connection while also accepting inbound connections on a local port)
Because eBPF enforcement happens at the kernel level, it applies regardless of container runtime, language, or privilege level. A developer running a tunneling agent in a Docker container on their corporate workstation is subject to the same enforcement as one running it directly on the host OS.
Conclusion: Zero Trust Is Not a Product
The Shadow Tunneling crisis is a reminder that Zero Trust is not a product you purchase and deploy — it is a security posture that must be continuously maintained as the threat landscape evolves.
The traditional perimeter has been replaced by a shifting web of encrypted micro-tunnels connecting laptops, cloud services, webhooks, and AI agents. Defenders who remain anchored to IP-based controls will find themselves perpetually chasing shadows.
The path forward runs through two layers: network behavior (JA4+ fingerprinting that identifies clients by how they speak TLS, not where they connect) and runtime enforcement (eBPF-based kernel monitoring that observes and controls what processes actually do, not just what they claim to be).
Neither layer is sufficient alone. Together, they represent the closest thing 2026 security has to genuine visibility into an otherwise invisible threat. The goal is not to build a bigger wall — it is to ensure that every tunnel, authorized or shadow, is authenticated, fingerprinted, monitored, and held to the same identity-first standard.
Related Topics
Top comments (0)