Por qué los CISOs están bloqueando ngrok (y qué deberían usar los desarrolladores en su lugar)

Durante años, utilidades como ngrok, Plink y VS Code Remote Tunnels han sido esenciales en las herramientas de los desarrolladores. Con un simple comando como ngrok http 3000 o code tunnel, los desarrolladores pueden exponer un servidor de desarrollo local a internet en segundos — la forma más rápida de probar un webhook de Stripe o Twilio, demostrar una función a un cliente remoto o depurar una app móvil contra un backend local.

Sin embargo, en los Centros de Operaciones de Seguridad (SOC) y equipos DevSecOps, la postura hacia estas herramientas ha cambiado de tolerancia permisiva a prohibición total. La inteligencia de amenazas de proveedores como CrowdStrike, Splunk, Darktrace y Huntress muestra que grupos de ransomware, extorsión y actores vinculados a estados están abusando activamente de herramientas de túnel inverso para construir puertas traseras covertas y no monitoreadas en redes corporativas — y los CISOs están respondiendo bloqueando ngrok y VS Code Remote Tunnels en los endpoints empresariales.

                       TÚNEL INVERSO TRADICIONAL (RIESGO SHADOW IT)

  [ Laptop del desarrollador ] ════════════ TLS saliente (443) ════════════e [ Servicio de retransmisión público ]
  (Ejecuta ngrok / code tunnel)                                        (ngrok.io / devtunnels.ms)
           ║                                                                   ║
  Evade firewall de ingreso                                              URL expuesta públicamente
  Sin autenticación de IdP empresarial                                    Vulnerable a ataques externos

Este es un dilema clásico de DevSecOps: ¿cómo eliminar una amenaza de túnel de alta severidad sin destruir la velocidad del desarrollo?

1. La amenaza del protocolo de túnel: cómo los atacantes usan herramientas localhost

Para entender por qué los equipos de seguridad bloquean los endpoints de los desarrolladores, es útil ver cómo funciona el túnel de protocolo y por qué es una técnica de evasión tan efectiva.

La mecánica del ataque

Los perímetros tradicionales de red dependen de reglas estrictas de ingreso: el tráfico entrante en puertos no aprobados se descarta por defecto. El tráfico saliente por HTTPS (puerto 443), en cambio, casi siempre está permitido para que los empleados naveguen y accedan a APIs en la nube.

Herramientas como ngrok, Plink y VS Code Remote Tunnels explotan esa asimetría con túneles inversos salientes. Un agente en un endpoint interno abre una conexión TLS/WebSocket de larga duración con infraestructura de relé externo (*.ngrok.io, *.devtunnels.ms, *.trycloudflare.com). El relé asigna una dirección accesible desde internet que enruta el tráfico entrante a través del túnel cifrado hacia el puerto local.

[ Host interno comprometido ] ─── TLS saliente ───e [ Relé controlado por atacante ] ───e [ C2 de ransomware ]
  (Ejecuta ngrok tcp 3389)                               (Ningún firewall entrante activado)

Vivir del sistema

Los actores de amenazas prefieren cada vez más software legítimo y firmado en lugar de malware personalizado, para evitar detección por firma — técnica conocida como Living off the Land (LotL). Esto no es hipotético:

• MITRE ATT6CK rastrea formalmente ngrok como software usado para movimiento lateral y exfiltración de datos, citando campañas que remontan a la operación de ransomware MAZE y que continúan con actividades recientes de Scattered Spider (UNC3944 / Octo Tempest).
• Scattered Spider, uno de los grupos de cibercrimen más activos que apunta a grandes empresas, es documentado por c2bfcite index=“12-1”c2bfas usar ngrok junto con AnyDesk, Tailscale, TightVNC, RustDesk y otras herramientas de acceso remoto de doble uso en su cadena de intrusión. Un aviso conjunto de CISA y múltiples informes de proveedores también listan c2cite index=“15-1”c2b en ngrok y Teleport entre las herramientas de acceso remoto y túneles en las que confía el grupo, mapeadas a técnicas MITRE T1219 y T1090.
• VS Code Remote Tunnels ya no son un riesgo teórico. SentinelOne y Tinexta Cyber documentaron una campaña de espionaje vinculada a China (“Operación Digital Eye”) que c2cite index=“27-1”c2bsa abusar de Visual Studio Code y la infraestructura de Azure para comprometer proveedores de servicios de TI en Europa del Sur, considerándola uno de los primeros usos observados de VS Code para comando y control. Darktrace reportó por separado una campaña vinculada a DPRK contra objetivos en Corea del Sur que instaló VS Code solo para abusar de su función de túnel incorporada para acceso remoto, evitando malware personalizado y infraestructura C2 dedicada. La inteligencia de amenazas de Microsoft de junio de 2026 también señaló el uso de VS Code Remote Tunneling por Kimsuky como canal C2 encubierto junto con Cloudflare Quick Tunnels.
• Incluso en 2026, ngrok sigue siendo un elemento activo en kits de herramientas de ransomware: el análisis de Hunt.io en marzo de 2026 de un servidor afiliado expuesto vinculado a la operación de ransomware TheGentlemen encontró tokens de autenticación de ngrok en texto plano usados para establecer túneles de acceso remoto ocultos junto con credenciales de víctimas recolectadas. Familias de malware recientes como el troyano bancario Astaroth/Guildma continúan enrutando tráfico C2 a través de túneles ngrok a mediados de 2026.

Casos comunes de uso malicioso documentados en esta investigación incluyen:

• Evadir controles de red — desplegar ngrok.exe o code tunnel en un host de acceso inicial para pasar NAT y segmentación interna.
• Reenvío RDP y VNC — túneles TCP en puerto 3389 (RDP) o 5900 (VNC) para control completo de escritorio interactivo. La investigación de detección de Guardsix rastrea este patrón hasta las divulgaciones del ransomware MAZE en 2020 y señala que sigue siendo la amenaza de protocolo más común que los actores túnelizan.
• Comando y control y exfiltración — usar el túnel como canal persistente y de alto ancho de banda para datos robados y acceso a shell interactivo.
• Camuflaje mediante dominios confiables — conexiones salientes a *.ngrok.io, *.devtunnels.ms o *.trycloudflare.com a menudo se aprueban porque resuelven a infraestructura pública de confianza.

2. Por qué las herramientas EDR generan alertas de “Túnel inverso” de alta severidad

Las plataformas de Endpoint Detection and Response — CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint — mantienen análisis conductuales específicamente diseñados para detectar túneles no autorizados. El equipo de seguridad de Splunk, por ejemplo, desarrolla y mantiene (a partir de mayo de 2026) una detección que marca consultas DNS a dominios ngrok como actividad de red anómala.

                               FIRMA DE COMPORTAMIENTO EDR
  ┌───────────────────────────────────────────────────────────────────────────────────────┐
  │ [Proceso] ngrok.exe / code.exe                                                        │
  │   ├── [Red] Conexión TLS saliente a *.ngrok.io / *.devtunnels.ms (Puerto 443)          │
  │   ├── [Socket] Socket de escucha local en 127.0.0.1:3389 / 127.0.0.1:8080                │
  │   └── [Proceso] Ejecuta shell (cmd.exe / powershell.exe)                              │
  └───────────────────────────────────────────────────────────────────────────────────────┘
                                           │
                                           ▼
                 🚨 ALERTA DE ALTA SEVERIDAD: MITRE ATT6CK T1572 (Túnel de protocolo)

Cuando se dispara una alerta de túnel inverso, generalmente se relaciona con:

• T1572 — Túnel de protocolo
• T1090 (y subtécnica T1090.003, proxy de múltiples saltos / fronting de dominio) — Proxy
• T1021.001 — Servicios remotos: Protocolo de Escritorio Remoto
• T1219 — Software de acceso remoto

Anomalías en la línea de proceso

Los agentes EDR no solo observan nombres de dominio — también rastrean la línea de proceso y llamadas al sistema. Una alerta suele dispararse cuando un binario no aprobado muestra esta cadena de comportamiento:

1. Anomalía de red — un binario no navegador abre flujos WebSocket/HTTP2 persistentes hacia relés en la nube.
2. Vinculación de socket local — el binario abre un puerto de escucha en 127.0.0.1 o 0.0.0.0.
3. Shells interactivos hijos — el binario de túnel genera cmd.exe, powershell.exe, /bin/bash o zsh.

El riesgo de “Shadow IT”

Incluso con intención benigna, los túneles no gestionados generan exposición operativa real:

• Endpoints internos no autenticados — los desarrolladores a menudo exponen servicios locales o bases de datos de staging sin encabezados de autenticación o listas blancas de IP.
• Evasión de DLP — código fuente o datos de clientes en una laptop se vuelven accesibles globalmente, evadiendo políticas de DLP y Zero Trust.
• Persistencia fuera de horario — los túneles que permanecen activos en laptops mantienen redes internas accesibles desde internet las 24 horas.

Por qué los bloqueos totales fracasan

Cuando un CISO bloquea ngrok o VS Code Remote Tunnels sin ofrecer una alternativa soportada, los desarrolladores tienden a usar herramientas como localhost.run, serveo.net o pinggy.io. Este “salto de túneles” solo desplaza el problema a las sombras — un juego de whack-a-mole que aumenta el riesgo en lugar de reducirlo, ya que ninguna de esas alternativas ofrece controles de identidad, registro o auditoría.

3. Matriz de evaluación: utilidad para desarrolladores vs. control empresarial

Característica / Criterio	ngrok tradicional	VS Code Remote Tunnels	Túnel Cloudflare gestionado	zrok (OpenZiti)	Tailscale Funnel / Serve	Teleport App Access
Mecanismo principal	Relé saliente HTTP/TCP	Túneles Dev de Microsoft	Enrutamiento en borde Cloudflare	Mesh Zero Trust OpenZiti	Mesh WireGuard + ingreso público	Proxy criptográfico inverso
Integración con proveedor de identidad (IdP)	Manual / plan empresarial	GitHub / cuenta Microsoft	Nativo (Okta, Entra ID, Ping)	Nativo / OIDC	Nativo (Okta, Entra ID, Google)	Nativo (SAML 2.0 / OIDC)
Registro de auditoría centralizado	Panel básico	Visibilidad limitada	SIEM empresarial / exportación S3 vía Logpush	Auditoría autohospedada completa	Registros en consola de administración	Registros de auditoría + grabación de sesiones
Perfil de alerta EDR	🔴 Alto riesgo (marcado rutinariamente)	🔴 Alto riesgo (marcado rutinariamente, incl. campañas MITRE/CISA)	🟢 Bajo riesgo (gestión vía MDM + política de acceso)	🟢 Bajo riesgo (modo mesh privado)	🟢 Bajo riesgo (ACL vinculadas a identidad)	🟢 Bajo riesgo (binario firmado por empresa)
Infraestructura auto-hospedada	No (solo SaaS)	No (SaaS de Microsoft)	Parcial (gestión en borde Cloudflare)	Sí (código abierto completo)	Parcial (control plane Headscale)	Sí (auto-hospedado / en la nube)
Compartición privada (no pública)	Requiere plan de pago	Cuentas compartidas en GitHub/Microsoft	Acceso empresarial Cloudflare	Sí (comparticiones privadas por defecto)	Sí (tailscale serve / tailnet)	Sí (controles de acceso por roles)

4. Alternativas de nivel empresarial para compartir localhost de forma segura

Los equipos DevSecOps necesitan ofrecer a los desarrolladores algo con la conveniencia de ngrok, pero con Zero Trust Network Access (ZTNA), verificación de identidad y registro centralizado integrados.

                      ARQUITECTURA DE ACCESO ZERO TRUST AUTORIZADA

  [ Laptop del desarrollador ] ── TLS saliente ──e [ Túnel empresarial gestionado ] c── Autenticación IdP ── [ Cliente / Webhook ]
  (Binario preaprobado)                   (Cloudflare / zrok / Tailscale)     (Okta / Entra ID)
           │                                          │
           └── Certificado de dispositivo MDM verificado        └── Exportación de logs a SIEM empresarial

Alternativa 1: Túnel Cloudflare gestionado + Cloudflare Access

Cloudflare Tunnel (cloudflared) abre una conexión saliente desde una máquina local a la red en borde de Cloudflare. Este producto ha sido mucho más atractivo para empresas desde que Cloudflare lo hizo gratuito en 2021 y lo integró en Cloudflare One / Zero Trust, que ahora incluye Access, Gateway, DLP y CASB en un solo plano de control. En 2026, cloudflared usa por defecto QUIC (HTTP/3) para su conexión saliente, y el proveedor de Terraform es lo suficientemente estable para gestión completa de túneles como infraestructura como código.

• Cómo funciona: los desarrolladores ejecutan cloudflared tunnel, vinculando servicios locales a subdominios de la empresa (ej. dev-alice.internal.ejemplo.com).
• Autenticación Zero Trust: las solicitudes entrantes pasan por Cloudflare Access, que se integra con Okta, Entra ID, Ping y otros proveedores SSO, y puede restringir el acceso según el estado del dispositivo.
• Seguridad en webhooks: para pruebas de webhook en Stripe o GitHub, los administradores pueden agregar tokens de servicio, validación de encabezados o listas blancas de IP sobre el túnel.
• Nota importante: la función Quick Tunnels de Cloudflare (*.trycloudflare.com), que no requiere cuenta ni propiedad de dominio, ha sido abusada como infraestructura C2 por actores de amenazas en reportes de 2026, incluyendo Kimsuky — recordatorio de que la configuración “gestionada y con verificación de identidad” importa, no solo el nombre del proveedor.

# Ejemplo: ejecutando un Túnel Cloudflare gestionado en puerto local 3000
cloudflared tunnel run --url http://localhost:3000 enterprise-dev-tunnel

Alternativa 2: OpenZiti y zrok (zero trust y código abierto)

Basado en el SDK de código abierto OpenZiti, zrok es una alternativa auto-hospedada que por defecto usa compartición privada y no pública.

                       ZROK COMPARTICIÓN PRIVADA (SIN PUNTO FINAL PÚBLICO)

  [ Laptop del desarrollador ] ════ Mesh Zero Trust OpenZiti ════e [ Laptop del revisor ]
  (Ejecuta: zrok share private)                              (Ejecuta: zrok access private)
                                Sin listener HTTPS público
                             Autenticación criptográfica

• Modelo privado primero: a diferencia de ngrok, zrok share private http://localhost:8080 genera un token de identidad efímero solo para pares autorizados en la superposición OpenZiti.
• Control plane autohospedado: los equipos de seguridad pueden gestionar su propia infraestructura zrok y tener control total sobre logs, enrutamiento y claves de cifrado.
• Modo público con controles: cuando realmente se necesita visibilidad pública (pruebas de webhook, demos), zrok soporta comparticiones públicas con autenticación personalizada y reservas de dominio.

# El desarrollador inicia una compartición privada zero-trust
zrok share private http://localhost:3000

# El par se conecta de forma segura usando el token privado generado
zrok access private <share-token>

Alternativa 3: Tailscale Funnel y Tailscale Serve

Tailscale integra la compartición localhost en la malla VPN basada en WireGuard (tailnet) de la organización.

┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                                   ECOSISTEMA TAILSCALE                                   │
│                                                                                         │
│  [ tailscale serve ]  ───e Expone localhost SOLO dentro del tailnet privado interno     │
│                                                                                         │
│  [ tailscale funnel ] ───e Expone localhost públicamente vía nodos de borde gestionados y ACLs │
└─────────────────────────────────────────────────────────────────────────────────────────┘

• Tailscale Serve (privado): tailscale serve localhost:3000 hace que un servidor local sea accesible solo a dispositivos autenticados dentro del tailnet, vía MagicDNS.
• Tailscale Funnel (público): tailscale funnel 3000 enruta tráfico HTTPS externo a través de la infraestructura de relé de Tailscale hacia el nodo, en casos donde se requiere acceso público a webhooks.
• ACLs granulares: los administradores controlan qué desarrolladores pueden crear un Funnel mediante políticas en la consola de Tailscale.
• Nota importante: Tailscale aparece en informes de amenazas de 2025-2026, no porque sea inseguro, sino porque actores que comprometen credenciales pueden abusar de cualquier herramienta de acceso remoto legítima, sancionada o no. Por eso, el control y monitoreo de ACLs siguen siendo cruciales.

// Ejemplo de ACL de Tailscale que restringe la creación de Funnels a grupos DevSecOps aprobados
{
  "nodeAttrs": [
    {
      "target": ["group:devsecops"],
      "attr": ["funnel"]
    }
  ]
}

Alternativa 4: Teleport Application Access

Teleport está dirigido a equipos de ingeniería en entornos con estrictas regulaciones de cumplimiento (SOC 2, ISO 27001, HIPAA).

• Certificados basados en identidad: certificados X.509 de corta duración vinculados a la identidad del desarrollador, reemplazan tokens API o claves estáticas.
• Registro completo y inspección de sesiones: cada solicitud HTTP, comando SSH y sesión de app pasa a ser visible para los equipos de seguridad.
• RBAC unificado: permisos de acceso sincronizados con el grupo del IdP empresarial, revocando automáticamente privilegios de túnel cuando cambian roles o alguien abandona.
• Advertencia: Teleport también aparece en informes de herramientas de actores de amenazas en 2025, como un uso legítimo abusado tras compromisos, no como producto inherentemente vulnerable. Las credenciales de corta duración y basadas en certificados reducen (pero no eliminan) ese riesgo en comparación con tokens de ngrok.

5. Guía de implementación DevSecOps

Mover una empresa fuera de herramientas de túnel no gestionadas requiere controles técnicos y una integración suave para los desarrolladores — o simplemente buscarán rutas alternativas.

┌──────────────────────────────────────────────────────────────────────────────────┐
│                        HOJA DE RUTA DE MIGRACIÓN DEVSECOPS                        │
├──────────────────────────────────────────────────────────────────────────────────┤
│ FASE 1: DESCUBRIR       🔍 Auditoría de salidas de red, DNS y EDR para túneles activos │
│ FASE 2: IMPLEMENTAR GATEWAY 🚀 Provisionar ZTNA empresarial (Cloudflare, zrok, Tailscale)│
│ FASE 3: AISLAR GANCHOS  🔒 Implementar gateways dedicados con validación HMAC │
│ FASE 4: HABILITAR EDR    🛡️ Desplegar reglas de bloqueo y listas blancas de aplicaciones  │
└──────────────────────────────────────────────────────────────────────────────────┘

Fase 1: Descubrir y auditar túneles shadow existentes

Antes de bloquear, averigua qué ya está en marcha:

Monitoreo DNS y salidas — revisar logs de solicitudes hacia dominios de infraestructura proxy conocidos: - *.ngrok.io, *.ngrok-free.app - *.devtunnels.ms, *.vscode.dev, tunnels.api.visualstudio.com - *.trycloudflare.com (Quick Tunnels sin autenticación, distinto de túneles gestionados) - *.localhost.run, *.serveo.net, *.pinggy.link

Consultas de hunting en EDR — buscar en telemetría ejecuciones de herramientas de túnel inverso:

// Ejemplo de consulta KQL para Microsoft Defender / 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

Fase 2: Implementar gateways de localhost autorizados

Seleccionar una alternativa empresarial y desplegarla vía MDM (Jamf, Microsoft Intune, Kandji):

• Configurar automáticamente los clientes para autenticarse con SSO corporativo.
• Vincular URLs públicas a dominios de la empresa (*.dev.tuempresa.com) con certificados TLS comodín.

Fase 3: Implementar gateways de aislamiento de webhooks

Para evitar que los desarrolladores abran endpoints públicos solo para webhooks, enruta el tráfico externo a través de un gateway central:

[ Servicio externo (Stripe) ] ──e [ Gateway de ingreso de webhooks empresarial ]
                                               │
                                       Verificación HMAC
                                    Registro central y límite de tasa
                                               │
                                               ▼
                                 [ Router / Túnel interno de desarrollo ]
                                               │
                                               ▼
                                 [ Laptop del desarrollador (Puerto 3000) ]

Los webhooks entrantes llegan al gateway, verifican firmas HMAC y límites de tasa, y solo después se envían internamente a través de un túnel autorizado y monitoreado hacia el entorno del desarrollador.

Fase 4: Configurar políticas EDR y control de aplicaciones

Con las herramientas sancionadas en marcha, bloquear el resto mediante EDR y control de aplicaciones (AppLocker, Windows Defender Application Control):

• Configurar los ejecutables de túneles no gestionados (ngrok.exe, plink.exe, code tunnel no gestionado) en Modo Bloqueo.
• Permitir solo agentes firmados por la empresa (cloudflared, zrok, tailscaled) por ruta y hash.

6. Resumen estratégico: equilibrio entre seguridad y experiencia del desarrollador

Prohibir herramientas de desarrollo sin una alternativa viable solo genera fricción y las empuja a las sombras. La investigación de amenazas es clara: MITRE ATT6CK, CISA, CrowdStrike, Darktrace, SentinelOne y Splunk han documentado independientemente que ngrok, VS Code Remote Tunnels y herramientas similares de doble uso son abusadas para acceso inicial, movimiento lateral, secuestro de RDP/VNC y C2 encubierto — por actores que van desde afiliados de ransomware hasta grupos APT vinculados a estados, incluso a mediados de 2026.

Al mismo tiempo, el hecho de que Tailscale y Teleport también aparezcan en las herramientas de actores de amenazas es un recordatorio útil: cambiar ngrok por una herramienta “sancionada” no es una solución mágica. El valor de seguridad proviene de la combinación — acceso vinculado a identidad, credenciales de corta duración, registro centralizado y listas blancas gestionadas por MDM — no solo del nombre de la marca en el binario.

Al reemplazar utilidades no gestionadas por arquitecturas de túneles Zero Trust vinculadas a identidad — Cloudflare Tunnel, zrok, Tailscale Funnel o Teleport, bien configuradas y monitoreadas — los equipos DevSecOps pueden reducir significativamente la superficie de ataque de túneles. Los desarrolladores mantienen la capacidad de compartir código local y probar webhooks en tiempo real; los equipos de seguridad obtienen visibilidad continua, controles de acceso efectivos y un panel EDR más silencioso.

Puntos clave para CISOs y líderes DevSecOps

• El riesgo es real y actual. Los túneles inversos siguen en uso activo para acceso inicial, C2 y reenvío RDP en 2026 — no solo en casos antiguos.
• Las alertas EDR son síntomas. Una alerta de túnel inverso suele indicar una brecha entre política de seguridad y requisitos del desarrollador, no solo un usuario rogue.
• Zero Trust es la solución, no solo la herramienta. La transformación que importa es de relés públicos no autenticados a túneles con verificación de identidad y auditoría vinculados a tu IdP empresarial — cualquiera que sea el proveedor.
• Estandarizar para tener éxito. Implementa herramientas sancionadas vía MDM y monitorea después del despliegue, ya que incluso herramientas de acceso remoto “seguras” pueden ser abusadas tras comprometer una cuenta.

---

Fuentes: MITRE ATT6CK (ngrok S0508, Scattered Spider G1015), aviso CISA AA23-320A, CrowdStrike Counter Adversary Operations, perfiles de amenazas Cyble, contenido de seguridad de Splunk, Hunt.io, Darktrace, SentinelOne Labs, Guardsix y documentación de productos Cloudflare/Tailscale/Teleport, actualizado a agosto de 2026.