Why CISOs Are Blocking ngrok (And What Developers Should Use Instead)

For years, utilities like ngrok, Plink, and VS Code Remote Tunnels have been essential in developer toolkits. With a simple command like ngrok http 3000 or code tunnel, developers can expose a local dev server to the internet in seconds — the fastest way to test a Stripe or Twilio webhook, demo a feature to a remote client, or debug a mobile app against a local backend.

Across enterprise Security Operations Centers (SOCs) and DevSecOps teams, though, the posture toward these tools has shifted from permissive tolerance to outright prohibition. Threat intelligence from vendors including CrowdStrike, Splunk, Darktrace, and Huntress shows ransomware crews, extortion groups, and state-linked actors actively abusing reverse tunneling tools to build covert, unmonitored backdoors into corporate networks — and CISOs are responding by blocking ngrok and VS Code Remote Tunnels across enterprise endpoints.

                       TRADITIONAL REVERSE TUNNEL (SHADOW IT RISK)

  [ Developer Laptop ] ════════════ Outbound TLS (443) ════════════> [ Public Relay Service ]
  (Runs ngrok / code tunnel)                                        (ngrok.io / devtunnels.ms)
           ║                                                                   ║
  Bypasses Ingress Firewall                                            Publicly Exposed URL
  No Enterprise IdP Authentication                                    Open to External Attackers

This is a classic DevSecOps dilemma: how do you eliminate a high-severity tunneling threat without destroying developer velocity?

1. The Protocol Tunneling Threat: How Attackers Weaponize Localhost Tools

To understand why security teams are locking down developer endpoints, it helps to look at how protocol tunneling works and why it’s such an effective evasion technique.

The mechanics of the attack

Traditional network perimeters rely on strict ingress rules: inbound traffic on unapproved ports gets dropped by default. Egress traffic over HTTPS (port 443), on the other hand, is almost universally allowed so employees can browse the web and reach cloud APIs.

Tools like ngrok, Plink, and VS Code Remote Tunnels exploit that asymmetry with outbound reverse tunneling. An agent on an internal endpoint opens a long-lived outbound TLS/WebSocket connection to external relay infrastructure (*.ngrok.io, *.devtunnels.ms, *.trycloudflare.com). The relay assigns an internet-reachable address that routes incoming traffic back through the encrypted tunnel to the local port.

[ Compromised Internal Host ] ─── Outbound TLS ───> [ Attacker-Controlled Relay ] ───> [ Ransomware C2 ]
  (Runs ngrok tcp 3389)                               (No Inbound Firewall Triggered)

Living off the Land

Threat actors increasingly favor legitimate, signed software over custom malware specifically to dodge signature-based detection — a technique known as Living off the Land (LotL). This isn’t hypothetical:

• MITRE ATT&CK formally tracks ngrok as software used for lateral movement and data exfiltration, citing campaigns going back to the MAZE ransomware operation and continuing through recent Scattered Spider (UNC3944 / Octo Tempest) activity.
• Scattered Spider, one of the most active eCrime groups targeting large enterprises, is documented by Cyble as using ngrok alongside AnyDesk, Tailscale, TightVNC, RustDesk, and other dual-use remote-access tooling throughout its intrusion chain. A joint CISA advisory and multiple vendor reports likewise list ngrok and Teleport among the remote-access and tunneling tools the group relies on, mapped to MITRE techniques T1219 and T1090.
• VS Code Remote Tunnels are no longer a theoretical risk either. SentinelOne and Tinexta Cyber documented a suspected China-linked espionage campaign (“Operation Digital Eye”) that abused Visual Studio Code and Azure infrastructure to compromise Southern European IT service providers, calling it one of the first observed uses of VS Code for command-and-control. Darktrace separately reported a DPRK-linked campaign against South Korean targets that installed VS Code purely to abuse its built-in tunneling feature for remote access, avoiding custom malware and dedicated C2 infrastructure entirely. Microsoft’s own June 2026 threat intelligence also flagged Kimsuky’s use of VS Code Remote Tunneling as a covert C2 channel alongside Cloudflare Quick Tunnels.
• Even in 2026, ngrok remains a live line item in ransomware toolkits: Hunt.io’s March 2026 analysis of an exposed affiliate server tied to the TheGentlemen ransomware-as-a-service operation found plaintext ngrok authentication tokens used to establish hidden remote-access tunnels alongside harvested victim credentials. Recent malware families like the Astaroth/Guildma banking trojan continue to route C2 traffic through ngrok tunnels as of mid-2026.

Common malicious use cases documented across this research include:

• Bypassing network controls — deploying ngrok.exe or code tunnel on an initial-access host to slip past NAT and internal segmentation.
• RDP and VNC forwarding — tunneling TCP traffic on port 3389 (RDP) or 5900 (VNC) for full interactive desktop control. Guardsix’s detection research traces this pattern back to the 2020 MAZE ransomware disclosures and notes it remains the most common protocol threat actors tunnel.
• Command & control and exfiltration — using the tunnel as a persistent, high-bandwidth channel for stolen data and interactive shell access.
• Camouflage via trusted domains — outbound connections to *.ngrok.io, *.devtunnels.ms, or *.trycloudflare.com often get waved through because they resolve to reputable public cloud infrastructure.

2. Why EDR Tools Trigger High-Severity “Reverse Tunnel” Alerts

Endpoint Detection and Response platforms — CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint — maintain behavioral analytics specifically tuned to catch unauthorized tunneling. Splunk’s security research team, for instance, ships and actively maintains (as of May 2026) a detection that flags DNS queries to ngrok domains as anomalous network activity.

                               EDR BEHAVIORAL SIGNATURE MATCH
  ┌───────────────────────────────────────────────────────────────────────────────────────┐
  │ [Process] ngrok.exe / code.exe                                                        │
  │   ├── [Network] Outbound TLS connection to *.ngrok.io / *.devtunnels.ms (Port 443)     │
  │   ├── [Socket] Local listening socket bound to 127.0.0.1:3389 / 127.0.0.1:8080         │
  │   └── [Process] Spawns shell execution child process (cmd.exe / powershell.exe)        │
  └───────────────────────────────────────────────────────────────────────────────────────┘
                                           │
                                           ▼
                 🚨 HIGH-SEVERITY ALERT: MITRE ATT&CK T1572 (Protocol Tunneling)

When a reverse-tunnel alert fires, it typically maps to:

• T1572 — Protocol Tunneling
• T1090 (and sub-technique T1090.003, Multi-hop Proxy / domain fronting) — Proxy
• T1021.001 — Remote Services: Remote Desktop Protocol
• T1219 — Remote Access Software

Process lineage anomalies

EDR agents don’t just look at domain names — they track process lineage and system calls. An alert typically fires when an unapproved binary shows this behavior chain:

1. Network anomaly — a non-browser binary opens persistent WebSocket/HTTP2 streams to dynamic cloud relays.
2. Local socket binding — the binary opens a listening port on 127.0.0.1 or 0.0.0.0.
3. Interactive child shells — the tunneling binary spawns cmd.exe, powershell.exe, /bin/bash, or zsh.

The “shadow IT” risk

Even used with entirely benign intent, unmanaged tunnels create real operational exposure:

• Unauthenticated internal endpoints — developers often expose local services or staging databases without auth headers or IP allowlisting.
• DLP bypass — source code or customer data on a laptop becomes globally reachable, sidestepping enterprise DLP and Zero Trust policy.
• Persistence after hours — tunnels left running on laptops keep internal subnets reachable from the public internet around the clock.

Why outright bans fail

When a CISO blocks ngrok or VS Code Remote Tunnels without offering a supported replacement, developers tend to route around it with tools like localhost.run, serveo.net, or pinggy.io. This “tunnel hopping” just pushes the problem deeper into the shadows — a game of whack-a-mole that compounds risk rather than reducing it, since none of those substitutes bring identity, logging, or audit controls either.

3. Evaluation Matrix: Developer Utility vs. Enterprise Control

Feature / Criteria	Traditional ngrok	VS Code Remote Tunnels	Managed Cloudflare Tunnel	zrok (OpenZiti)	Tailscale Funnel / Serve	Teleport App Access
Primary mechanism	Outbound HTTP/TCP relay	Microsoft Dev Tunnels (devtunnels.ms)	Cloudflare edge routing	OpenZiti zero-trust mesh	WireGuard mesh + public ingress	Cryptographic reverse proxy
Identity provider (IdP) integration	Manual / enterprise plan	GitHub / Microsoft account	Native (Okta, Entra ID, Ping)	Native / OIDC	Native (Okta, Entra ID, Google)	Native (SAML 2.0 / OIDC)
Central audit logging	Basic dashboard	Limited enterprise visibility	Enterprise SIEM / S3 export via Logpush	Full self-hosted audit trail	Centralized admin console logs	Audit logs + session recording
EDR alert profile	🔴 High risk (routinely flagged)	🔴 High risk (routinely flagged, incl. by MITRE/CISA-tracked APT campaigns)	🟢 Low risk (when managed via MDM + Access policy)	🟢 Low risk (private mesh mode)	🟢 Low risk (identity-bound ACLs)	🟢 Low risk (enterprise-signed binary)
Self-hostable infrastructure	No (SaaS only)	No (Microsoft SaaS)	Partial (Cloudflare edge managed)	Yes (fully open-source)	Partial (Headscale control plane)	Yes (self-hosted / cloud)
Private sharing (non-public)	Requires paid plan	Shared GitHub/Microsoft accounts	Enterprise Cloudflare Access	Yes (private shares by default)	Yes (tailscale serve / tailnet)	Yes (role-based access controls)

4. Enterprise-Grade Alternatives for Secure Localhost Sharing

DevSecOps teams need to give developers something with ngrok’s convenience but with Zero Trust Network Access (ZTNA), identity verification, and central logging built in.

                      SANCTIONED ZERO TRUST ACCESS ARCHITECTURE

  [ Developer Laptop ] ── Outbound TLS ──> [ Managed Enterprise Tunnel ] <── IdP Authentication ── [ Client / Webhook ]
  (Pre-approved Binary)                   (Cloudflare / zrok / Tailscale)     (Okta / Entra ID)
           │                                          │
           └── Verified MDM Device Certificate        └── Audit Log Export to Enterprise SIEM

Alternative 1: Managed Cloudflare Tunnel + Cloudflare Access

Cloudflare Tunnel (cloudflared) opens an outbound-only connection from a local machine to Cloudflare’s edge network. Notably, this product has become significantly more attractive for enterprises since Cloudflare made it free in 2021 and folded it into the broader Cloudflare One / Zero Trust platform, which now bundles Access, Gateway, DLP, and CASB under a single control plane. As of 2026, cloudflared defaults to QUIC (HTTP/3) for its outbound connection, and the Terraform provider is stable enough for full infrastructure-as-code tunnel management.

• How it works: developers run cloudflared tunnel, binding local services to enterprise-owned subdomains (e.g., dev-alice.internal.example.com).
• Zero Trust authentication: incoming requests pass through Cloudflare Access, which integrates with Okta, Microsoft Entra ID, Ping Identity, and other SSO providers, and can also gate access on device posture.
• Securing webhooks: for Stripe or GitHub webhook testing, admins can layer service tokens, header validation, or IP allowlists on top of the tunnel.
• Worth noting: Cloudflare’s own Quick Tunnels feature (*.trycloudflare.com), which requires no account and no domain ownership, has itself been abused as ad-hoc C2 infrastructure by threat actors including Kimsuky in 2026 reporting — a reminder that the “managed and identity-gated” configuration matters, not just the vendor name.

# Example: running an enterprise-managed Cloudflare Tunnel bound to local port 3000
cloudflared tunnel run --url http://localhost:3000 enterprise-dev-tunnel

Alternative 2: OpenZiti & zrok (zero trust and open source)

Built on the open-source OpenZiti zero-trust SDK, zrok is a self-hostable alternative that defaults to private, non-public sharing.

                       ZROK PRIVATE SHARING (NO PUBLIC INTERNET ENDPOINT)

  [ Developer Laptop ] ════ OpenZiti Zero Trust Mesh ════> [ Reviewer Laptop ]
  (Runs: zrok share private)                              (Runs: zrok access private)
                                No Public HTTPS Listener
                             Cryptographically Authenticated

• Private-first model: unlike ngrok’s public-by-default posture, zrok share private http://localhost:8080 generates an ephemeral identity token usable only by authorized peers on the OpenZiti overlay.
• Self-hosted control plane: security teams can run their own zrok infrastructure and own the access logs, routing, and encryption keys outright.
• Public mode with controls: when public visibility is genuinely needed (webhook testing, demos), zrok supports public shares with custom auth and domain reservations layered on top.

# Developer initiates a private zero-trust share
zrok share private http://localhost:3000

# Peer connects securely using the generated private token
zrok access private <share-token>

Alternative 3: Tailscale Funnel & Tailscale Serve

Tailscale folds localhost sharing into an organization’s existing WireGuard-based mesh VPN (tailnet).

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                                   TAILSCALE ECOSYSTEM                                    │
│                                                                                            │
│  [ tailscale serve ]  ───> Exposes localhost ONLY within the internal private tailnet     │
│                                                                                            │
│  [ tailscale funnel ] ───> Exposes localhost publicly via managed edge nodes + ACLs       │
└─────────────────────────────────────────────────────────────────────────────────────────┘

• Tailscale Serve (private): tailscale serve localhost:3000 makes a local server reachable only to authenticated devices already inside the company’s tailnet, via MagicDNS.
• Tailscale Funnel (public): tailscale funnel 3000 routes external HTTPS traffic through Tailscale’s relay infrastructure to the node, for cases where public webhook access is genuinely required.
• Granular ACLs: admins scope which developers can even create a Funnel via policy in the Tailscale admin console.
• Worth noting: Tailscale itself shows up on Scattered Spider’s tool list in multiple 2025–2026 threat reports — not because the product is insecure, but because attackers who’ve already compromised credentials can abuse any legitimate remote-access tool, sanctioned or not. This is why ACL scoping and monitoring matter even after you’ve “solved” the tooling problem.

// Example Tailscale ACL restricting Funnel creation to approved DevSecOps groups
{
  "nodeAttrs": [
    {
      "target": ["group:devsecops"],
      "attr": ["funnel"]
    }
  ]
}

Alternative 4: Teleport Application Access

Teleport targets engineering teams operating under strict compliance regimes (SOC 2, ISO 27001, HIPAA).

• Identity-based certificates: short-lived X.509 certificates tied to a developer’s identity replace long-lived API tokens or static keys.
• Full audit logging and session inspection: every HTTP request, SSH command, and app session routed through Teleport is visible to security teams.
• Unified RBAC: access permissions sync with enterprise IdP group membership, automatically revoking tunneling privileges the moment someone changes roles or leaves.
• Caveat: Teleport also appears on Scattered Spider’s documented toolset in 2025 CISA advisory reporting — again, as a legitimate tool abused post-compromise, not as an inherently vulnerable product. Certificate-based, short-lived credentials materially reduce (but don’t eliminate) that risk compared to static ngrok auth tokens.

5. The DevSecOps Implementation Playbook

Moving an enterprise off unmanaged tunneling tools takes technical controls paired with a smooth developer onboarding path — or developers will simply route around the ban.

┌──────────────────────────────────────────────────────────────────────────────────┐
│                             DEVSECOPS MIGRATION ROADMAP                          │
├──────────────────────────────────────────────────────────────────────────────────┤
│ PHASE 1: DISCOVER       🔍 Audit network egress, DNS, and EDR for active tunnels │
│ PHASE 2: DEPLOY GATEWAY 🚀 Provision enterprise ZTNA (Cloudflare, zrok, Tailscale)│
│ PHASE 3: ISOLATE HOOKS  🔒 Implement dedicated dev gateways with HMAC validation │
│ PHASE 4: ENFORCE EDR    🛡️ Deploy EDR block rules & application path allowlists  │
└──────────────────────────────────────────────────────────────────────────────────┘

Phase 1: Discover and audit existing shadow tunnels

Before enforcing blocks, find out what’s already running:

DNS and egress monitoring — audit logs for egress requests to known proxy infrastructure domains: - *.ngrok.io, *.ngrok-free.app - *.devtunnels.ms, *.vscode.dev, tunnels.api.visualstudio.com - *.trycloudflare.com (Cloudflare’s unauthenticated Quick Tunnels — distinct from a managed enterprise tunnel) - *.localhost.run, *.serveo.net, *.pinggy.link

EDR threat hunting queries — search telemetry for known reverse-tunnel tool executions:

// Example KQL query for Microsoft Defender for Endpoint / Sentinel
DeviceProcessEvents
| where ProcessCommandLine has_any ("ngrok", "plink", "code tunnel", "chisel", "frp")
   or FileName in~ ("ngrok.exe", "plink.exe", "chisel.exe")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, FolderPath

Phase 2: Deploy sanctioned enterprise localhost gateways

Pick an enterprise alternative and push it through MDM (Jamf, Microsoft Intune, Kandji):

• Pre-configure clients to authenticate automatically against corporate SSO.
• Bind public URLs to enterprise-owned domains (*.dev.yourcompany.com) under wildcard TLS certs.

Phase 3: Implement webhook isolation gateways

To stop developers from opening public endpoints just to catch webhooks, route external traffic through a central gateway instead:

[ External Service (Stripe) ] ──> [ Enterprise Webhook Ingress Gateway ]
                                               │
                                       HMAC Verification
                                    Central Log & Rate Limit
                                               │
                                               ▼
                                 [ Internal Dev Router / Tunnel ]
                                               │
                                               ▼
                                 [ Developer Laptop (Port 3000) ]

Incoming webhooks land on the gateway, get their HMAC signatures verified and rate-limited centrally, and only then get forwarded internally over an authorized, monitored tunnel to the right developer environment.

Phase 4: Configure EDR policies and application control

With sanctioned tooling in place, lock down the rest via EDR and application control (AppLocker, Windows Defender Application Control):

• Set unmanaged tunnel executables (ngrok.exe, plink.exe, unmanaged code tunnel) to Block Mode.
• Allowlist sanctioned, enterprise-signed agents (cloudflared, zrok, tailscaled) by path and hash.

6. Strategic Summary: Balancing Security and Developer Experience

Banning developer tools without a viable replacement just creates friction and pushes usage into the shadows. The threat research is unambiguous on this point: MITRE ATT&CK, CISA, CrowdStrike, Darktrace, SentinelOne, and Splunk have all independently documented ngrok, VS Code Remote Tunnels, and similar dual-use tools being abused for initial access, lateral movement, RDP/VNC hijacking, and covert C2 — by actors ranging from ransomware affiliates to state-linked APT groups, as recently as mid-2026.

At the same time, the fact that Tailscale and Teleport also turn up in threat-actor toolkits is a useful reminder: swapping ngrok for a “sanctioned” tool isn’t a silver bullet on its own. The security value comes from the combination — identity-bound access, short-lived credentials, centralized audit logging, and MDM-enforced allowlisting — not from the brand name on the binary.

By replacing unmanaged utilities with identity-bound, Zero Trust tunneling architectures — Cloudflare Tunnel, zrok, Tailscale Funnel, or Teleport, properly configured and monitored — DevSecOps teams can substantially reduce the tunneling attack surface. Developers keep the ability to share local code and test webhooks in real time; security teams get continuous visibility, real access controls, and a quieter EDR dashboard.

Key takeaways for CISOs and DevSecOps leaders

• The risk is real and current. Reverse tunnels remain in active use for initial access, C2, and RDP forwarding well into 2026 — not just in older case studies.
• EDR alerts are symptoms. A reverse-tunnel alert usually signals a gap between security policy and developer requirements, not just a rogue user.
• Zero Trust is the fix, not the tool. The shift that matters is from unauthenticated public relays to identity-aware, audited tunnels tied to your enterprise IdP — whichever vendor delivers that.
• Standardize to succeed. Deploy sanctioned tools via MDM, and keep monitoring them post-deployment, since even “safe” remote-access tools get abused once an account is compromised.

---

Sources: MITRE ATT&CK (ngrok S0508, Scattered Spider G1015), CISA advisory AA23-320A, CrowdStrike Counter Adversary Operations, Cyble threat actor profiles, Splunk Security Content, Hunt.io, Darktrace, SentinelOne Labs, Guardsix, and Cloudflare/Tailscale/Teleport product documentation, current as of August 2026.