La Crisis de Shadow Tunneling: Por qué tu perímetro 2026 ya está roto

El “perímetro corporativo” ya no es un concepto útil. Durante años, los Chief Information Security Officers centraron sus defensas en bloquear aplicaciones SaaS no autorizadas — el problema de Shadow IT de principios de los 2020. Para 2026, una amenaza más insidiosa ha tomado su lugar en la cima del registro de riesgos empresariales: Shadow Tunneling.

Donde Shadow IT significaba que los empleados usaban aplicaciones web no aprobadas, Shadow Tunneling implica que empleados — y atacantes — perforan agujeros encriptados y directos a través del firewall corporativo para exponer servicios internos a internet público. Ya sea un desarrollador usando ngrok para demostrar una compilación local, o un actor malicioso usando un daemon cloudflared para mantener persistencia, estos túneles sombra son las puertas traseras invisibles de la era moderna. Ellos evaden tu WAF, ciegan tu DLP, y hacen que tu IDS sea irrelevante — todo sin requerir privilegios administrativos.

Este artículo explora cómo llegamos aquí, por qué las defensas tradicionales basadas en IP han fallado, y las dos herramientas más importantes que los equipos de seguridad están desplegando en 2026 para luchar contra esto: JA4+ fingerprinting TLS y monitoreo a nivel kernel con eBPF.

---

Parte 1 — Cómo murió el Perímetro

De Shadow SaaS a Shadow Infrastructure

El modelo castillo y foso se basaba en una premisa simple: confiar en todo lo que está dentro de la red, bloquear todo lo que está fuera. Ese foso ahora ha sido superado por miles de puentes encriptados — cada uno abierto en segundos por un desarrollador frustrado con la fricción del VPN.

Herramientas como ngrok, Cloudflare Tunnel, Tailscale, y un ecosistema creciente de alternativas auto-hospedadas (Pangolin, basado en WireGuard, emergió como una opción notable en 2025–2026) permiten un solo comando en la terminal — a menudo sin permisos elevados — para crear una URL pública enrutable para cualquier servicio privado. El repositorio awesome-tunneling en GitHub rastrea más de cien de estas herramientas, con nuevas entradas que aparecen con suficiente regularidad que el mantenedor añadió un requisito mínimo de 100 estrellas a principios de 2026 solo para gestionar el volumen.

La amenaza no es hipotética. Cuando un desarrollador ejecuta ngrok http 3000, está publicando un puerto directamente a internet, saltándose por completo la pila de seguridad corporativa. La encriptación de extremo a extremo del túnel significa que incluso si el tráfico pasa por infraestructura monitoreada, su contenido es invisible para las herramientas de inspección.

Por qué falla el bloqueo IP

La respuesta obvia — bloquear los rangos IP conocidos de los proveedores de túneles — ha sido efectivamente inútil desde hace años. Los servicios de tunneling modernos usan redes Anycast y grandes pools de direcciones rotativas. Para cuando una lista de bloqueo se propaga, el túnel ha migrado a un nuevo nodo. Bloquear una IP en 2026 es como tratar de atrapar humo con una red de pesca.

Esto obliga a los defensores a cambiar completamente su marco de referencia — de dónde va el tráfico a cómo es el tráfico.

---

Parte 2 — JA4+ TLS Fingerprinting: Identificando lo Invisible

El problema que JA4 fue creado para resolver

Cada conexión TLS comienza con un apretón de manos ClientHello — un mensaje inicial sin encriptar en el que el cliente declara sus versiones TLS soportadas, suites de cifrado, extensiones y otros parámetros. Este mensaje es una huella digital. Diferentes softwares — Chrome, curl, una librería HTTP en Go, un agente ngrok — producen mensajes ClientHello distintos, incluso cuando comunican con el mismo destino.

El estándar original de huellas, JA3, funcionaba hashing estos parámetros en una cadena MD5 de 32 caracteres. Fue ampliamente adoptado y efectivo durante años. Pero en 2023, Google actualizó Chromium para aleatorizar el orden de las extensiones TLS en cada conexión — una medida de privacidad que también destrozó la estabilidad de JA3, generando miles de millones de hashes posibles para lo que era funcionalmente el mismo navegador.

Qué es JA4+ y cómo funciona

En septiembre de 2023, John Althouse en FoxIO lanzó JA4+, un conjunto modular de métodos de huellas de red diseñados explícitamente para sobrevivir a la aleatorización. La huella core JA4 para tráfico TLS cliente sigue un formato estructurado y legible:

JA4 = [protocolo+versión]_[hash_cifrado_ordenado]_[hash_extensiones_ordenadas]

Por ejemplo, una huella podría parecerse a: t13d1516h2_a0e9c7f32f1c_e5b1d8a03d9a

La innovación clave es ordenar. Antes de hacer hashing, JA4 ordena alfabéticamente tanto las suites de cifrado como las extensiones. Esto significa que el orden aleatorio de extensiones en Chrome ya no produce un hash diferente en cada conexión — el paso de ordenación normaliza la salida, produciendo una huella estable independientemente del orden de presentación. También derrota una técnica conocida como “cipher stunting,” donde los clientes aleatorizan el orden de cifrado específicamente para evadir la detección basada en JA3.

La suite JA4+ se extiende mucho más allá de TLS:

• JA4 — huella del cliente TLS
• JA4S — huella de respuesta del servidor TLS
• JA4H — huella del cliente HTTP
• JA4X — huella del certificado X.509
• JA4SSH — huella del tráfico SSH
• JA4T / JA4TScan — huellas de TCP

La huella base JA4 es de código abierto bajo la licencia BSD 3-Clause. La suite más amplia JA4+ está licenciada bajo la licencia propietaria FoxIO Licence 1.1, que permite uso interno en negocios pero requiere un acuerdo comercial para monetización.

Adopción en la industria

La adopción de JA4+ entre plataformas principales ha sido rápida. Cloudflare integró JA4 en su gestión de bots y pila Zero Trust — creando un analizador TLS en Rust (client-hello-parser) para exponer huellas JA4 en sus reglas de firewall, Workers y sistemas de análisis. AWS, VirusTotal y NetWitness han adoptado el estándar. VirusTotal permite a los analistas pivotar sobre huellas JA4 mediante su modificador de búsqueda behavior_network, permitiendo a cazadores de amenazas identificar familias de malware que comparten la misma librería TLS incluso cuando cambian IPs y dominios.

La gestión empresarial de bots de Cloudflare expone huellas JA3 y JA4 directamente en reglas de firewall. La plataforma de ngrok ahora muestra huellas JA4 a través de su Traffic Inspector, y soporta buckets de rate-limiting vinculados a la huella JA4 — haciendo que la huella sea una variable de política nativa, no solo un artefacto de observabilidad.

Aplicando JA4+ para detección de Shadow Tunnel

Aquí es donde JA4+ se vuelve directamente relevante para el problema de Shadow Tunneling. Agentes de tunneling como ngrok, cloudflared, y sus equivalentes tienen firmas distintas en el apretón TLS — combinaciones específicas de suites de cifrado soportadas, extensiones y valores ALPN que difieren de navegadores o stacks TLS de sistemas operativos.

Crucialmente, cambiar el nombre del ejecutable no ayuda. Si un desarrollador renombra cloudflared a chrome.exe, el comportamiento del apretón TLS permanece igual al agente real de cloudflared. Un navegador Chrome produce una huella JA4 consistente con Chromium. El agente de túnel renombrado produce una huella compatible con la librería TLS en Go que soporta cloudflared. Estas no son la misma cadena.

Los equipos de seguridad en 2026 mantienen librerías curadas de firmas JA4 para agentes de tunneling conocidos — la base de datos de FoxIO se construye precisamente para esto — y pueden bloquear conexiones en el borde en cuanto detectan un apretón coincidente, independientemente de la IP de destino. A diferencia del bloqueo IP, este método sigue siendo efectivo incluso cuando los proveedores de tunneling rotan su infraestructura.

---

Parte 3 — eBPF: El Agente Encubierto Dentro del SO

Los límites de la seguridad en espacio de usuario

JA4+ opera en el borde de la red. Pero, ¿qué pasa con túneles que nunca alcanzan un punto de control monitoreado — tráfico que se origina en una máquina dentro de la red y sale directamente? ¿Y qué pasa cuando un atacante ya tiene acceso a nivel proceso y puede evadir la inspección de red?

Aquí es donde eBPF (extended Berkeley Packet Filter) cambia las reglas.

eBPF es una tecnología integrada en el kernel de Linux que permite que programas sandboxed corran de forma segura dentro del kernel mismo. Originalmente diseñado para filtrado de paquetes de bajo nivel, ha evolucionado hasta convertirse en la capa fundamental de la seguridad moderna en la nube. Sus propiedades clave para casos de uso de seguridad son: no requiere modificación o recompilación del kernel, funciona con mínima sobrecarga de rendimiento comparado con agentes en espacio de usuario, y proporciona visibilidad profunda en syscalls, eventos de red, acceso a archivos y ejecución de procesos — todo en tiempo real.

Tetragon y Falco: Las dos herramientas líderes

Dos herramientas de seguridad basadas en eBPF han emergido como estándar en entornos empresariales y nativos en la nube:

Tetragon, un sub-proyecto del proyecto Cilium (ahora parte de Cisco tras su adquisición de Isovalent), ofrece observabilidad de seguridad basada en eBPF junto con aplicación en tiempo real. Traduce políticas de seguridad en YAML a programas eBPF que corren directamente en el kernel, y es consciente de Kubernetes — entiende metadatos de namespace y pod, no solo syscalls crudos. Tetragon puede detectar el momento exacto en que un proceso intenta abrir un socket de red, correlacionar ese evento con el namespace, linaje y historial de acceso a archivos del proceso, y terminar el proceso antes de que salga el primer byte de datos del host. Su mecanismo de enforcement opera vía BPF LSM (Linux Security Module) hooks, que son síncronos — la decisión del kernel sucede en línea, no después.

Falco, un proyecto open-source de CNCF, es un monitor de actividad comportamental que audita el sistema en la capa del kernel Linux mediante eBPF. Mientras Tetragon se enfoca en enforcement, Falco se centra en detección y alertas — señalando comportamientos anómalos según un conjunto de reglas y enviando alertas a plataformas SIEM, Slack, PagerDuty, o webhooks personalizados vía su capa de integración Falcosidekick. Falco opera como DaemonSet en Kubernetes, asegurando que cada nodo del clúster sea monitoreado. Su driver eBPF (modern_bpf) es el modo recomendado en distribuciones modernas.

Estas herramientas son complementarias. Como lo expresan claramente los creadores de ARMO (los de Kubescape): Falco para detección, Tetragon o KubeArmor para detección más enforcement.

La estrategia de matar en origen

Aplicado a la detección de shadow tunnel, eBPF permite lo que algunos equipos SOC llaman “kill at source”. El flujo de trabajo es:

1. Un programa eBPF en los puntos de traza syscalls detecta que un proceso intenta abrir una interfaz TUN/TAP — mecanismo a nivel kernel que soporta la mayoría de los VPN-style tunnels.
2. Tetragon correlaciona este evento: ¿Este proceso ha spawnado recientemente un shell? ¿Tiene patrones de acceso a archivos inusuales? ¿Su hash binario coincide con un agente de tunneling conocido?
3. Si la política se cumple, el proceso se termina a nivel kernel — no mediante una señal kill enviada desde espacio de usuario (que puede ser capturada o retrasada), sino mediante el hook BPF LSM que niega la syscall subyacente.

La ventaja clave sobre agentes en espacio de usuario es que este método no puede ser evadido por un proceso que haya comprometido el agente de monitoreo. La seguridad está integrada en la capa del sistema operativo misma. Un desarrollador no puede simplemente desinstalarlo.

La integración de Cisco de Tetragon en ofertas empresariales ha acelerado significativamente su adopción en entornos productivos. La capacidad de desplegar políticas dinámicas basadas en eBPF — y actualizarlas en tiempo real sin reiniciar o redeployar agentes — fue demostrada durante la respuesta a la vulnerabilidad xz utils (CVE-2024-3094), donde programas eBPF se usaron para aplicar mitigaciones en horas tras la divulgación.

---

Parte 4 — La Amenaza de Secuestro de Subdominios OAuth

Cómo los túneles caducados se convierten en vectores de ataque

Quizá el riesgo menos valorado en el panorama de shadow tunneling es lo que pasa después de que un desarrollador cierra su túnel.

Los servicios de tunneling en niveles gratuitos o de baja fricción asignan subdominios efímeros: dev-app-123.ngrok-free.app, staging-preview.trycloudflare.com, y similares. Cuando el desarrollador cierra su portátil, el túnel muere — pero el registro DNS asociado a ese subdominio puede seguir activo en servicios externos.

Considera un desarrollador que ha registrado su URL de túnel como el URI de redirección OAuth en una App de GitHub o configuración de Webhook de Stripe. Termina su trabajo y cierra el túnel. El subdominio vuelve a estar disponible. Un actor malicioso que reclame ese subdominio a través del tier gratuito del proveedor de tunneling ahora controla el endpoint que GitHub o Stripe creen que es legítimo.

Secuestro de redirección OAuth en la práctica

Investigaciones recientes publicadas en USENIX Security 2025 identificaron vulnerabilidades relacionadas en plataformas de integración a escala. Los investigadores desarrollaron COVScan, una herramienta semi-automatizada de testing, y encontraron que entre 18 plataformas populares de integración, 11 eran vulnerables a ataques de Cross-app OAuth Account Takeover (COAT) — incluyendo plataformas de Microsoft, Google y Amazon. Aunque no es exclusivamente un problema de tunneling, la clase de vulnerabilidad — URIs de redirección OAuth caducados o mal configurados — se habilita directamente por el modelo de subdominio efímero en los servicios de tunneling.

La variante específica de este ataque en 2026 es: un atacante reclama un subdominio de túnel caducado que aún está en la lista blanca en un Proveedor de Identidad (IdP) como Okta o Azure AD, y luego inicia una solicitud de autorización. Si la víctima tiene una sesión SSO activa, el IdP puede emitir un código de autorización al subdominio secuestrado sin que el usuario vea un prompt de login — el parámetro prompt=none en la solicitud de autorización logra exactamente esto. El atacante intercambia el código interceptado por un token de sesión y obtiene acceso completo a la identidad corporativa del desarrollador.

El equipo de seguridad de CrowdStrike también documenta el secuestro de subdominios como una superficie de ataque activa, señalando que los subdominios secuestrados se usan para phishing, distribución de malware y interceptación de credenciales — todo operando bajo la apariencia de un dominio corporativo legítimo.

---

Parte 5 — La Estrategia de Defensa en Profundidad 2026

Bloquear todos los tools de tunneling de forma total es cada vez más impráctico en organizaciones con fuerte enfoque en ingeniería. Los desarrolladores necesitan exponer webhooks para pruebas, compartir compilaciones locales para revisión, y iterar sin esperar días por cambios en firewalls. La postura más productiva es gobernar, no solo bloquear.

1. Tunneling con Autenticación OIDC en el Borde

La era de túneles anónimos terminó para entornos empresariales serios. El modelo que las organizaciones de seguridad están adoptando: requerir autenticación OIDC (OpenID Connect) en la capa de tunneling misma, antes de que cualquier tráfico llegue al recurso interno.

Tanto la versión empresarial de ngrok como Cloudflare Access (que se integra con Cloudflare Tunnel) soportan este modelo de forma nativa. Cloudflare Access, por ejemplo, intercepta cada solicitud a un endpoint expuesto por túnel, emite un JWT basado en la identidad SSO corporativa del usuario, y envía ese JWT al backend. El túnel ya no es un conducto anónimo — es un punto de control de políticas. Los usuarios deben autenticarse contra el proveedor de identidad corporativo antes de que un paquete llegue al servicio interno.

2. Sinkholing DNS y Monitoreo Pasivo de DNS

Mientras el bloqueo IP falla, la resolución DNS sigue siendo un punto de control. Bloquear la resolución para *.ngrok.io, *.trycloudflare.com, *.ngrok-free.app, y dominios de control de otros servicios de tunneling evita que los agentes establezcan la conexión inicial — no pueden “llamar a casa” para configurar el túnel si el DNS del plano de control está sinkholeado.

Complementariamente, el monitoreo de Passive DNS (pDNS) permite a los equipos de seguridad detectar patrones inusuales en subdominios y identificar cuándo una máquina interna resuelve dominios relacionados con tunneling, incluso antes de que se establezca una conexión.

3. Aplicar PKCE en todos los flujos OAuth

Para mitigar el riesgo de secuestro de subdominios OAuth, los equipos de seguridad deben aplicar PKCE (Proof Key for Code Exchange) en todos los flujos de código de autorización — incluyendo los de servidor.

PKCE funciona generando un secreto criptográfico (code_verifier) en el cliente iniciador y enviando un hash de este (code_challenge) en la solicitud inicial. Cuando se intercambia el código de autorización por un token, se debe presentar el code_verifier original. Un atacante que intercepte el código de autorización — secuestrando un subdominio de túnel — no puede intercambiarlo por un token sin el code_verifier, que solo existe en la sesión legítima del navegador.

Aplicar coincidencia exacta en los URIs de redirección (en lugar de patrones o comodines) en el servidor de autorización cierra las cadenas de redirección abiertas que permiten a atacantes explotar flujos OAuth incluso sin secuestro DNS.

4. Bibliotecas de firma JA4 en el borde

Los equipos de SOC deben construir y mantener librerías curadas de huellas JA4 para agentes de tunneling conocidos y desplegarlas en el borde de la red. Porque la huella JA4 identifica la librería TLS del cliente, no el nombre del proceso ni la IP de destino, esta detección sobrevive a cambios de nombre, rotación de IPs y ofuscación basada en CDN. Un cliente cloudflared que produzca la huella t13d... en el apretón TLS generará esa huella independientemente del nombre del ejecutable o del nodo de Cloudflare al que se conecte.

5. Políticas en tiempo de ejecución con eBPF para comportamiento de procesos

Desplegar Tetragon u otra capa de enforcement eBPF con políticas que detecten o bloqueen:

• Procesos abriendo interfaces TUN/TAP
• Binarios no en inventario de software aprobado intentando conexiones salientes a rangos de control de tunneling conocidos
• Procesos que muestran la firma comportamental de un agente de tunneling (por ejemplo, manteniendo una conexión TCP persistente saliente y aceptando conexiones entrantes en un puerto local)

Debido a que la enforcement con eBPF sucede a nivel kernel, aplica sin importar el runtime del contenedor, lenguaje o nivel de privilegio. Un desarrollador que ejecute un agente de tunneling en un contenedor Docker en su estación de trabajo corporativa está sujeto a la misma enforcement que uno que lo ejecute directamente en el sistema operativo host.

---

Conclusión: Zero Trust no es un Producto

La crisis de Shadow Tunneling nos recuerda que Zero Trust no es un producto que compras y despliegas — es una postura de seguridad que debe mantenerse continuamente a medida que evoluciona el panorama de amenazas.

El perímetro tradicional ha sido reemplazado por una red cambiante de micro-túneles encriptados que conectan laptops, servicios en la nube, webhooks y agentes de IA. Los defensores que se aferran a controles basados en IP se encontrarán persiguiendo sombras eternamente.

El camino hacia adelante pasa por dos capas: comportamiento de red (fingerprinting JA4+ que identifica clientes por cómo hablan TLS, no por dónde se conectan) y ejecución en tiempo real (monitoreo kernel con eBPF que observa y controla lo que los procesos hacen, no solo lo que dicen ser). Ninguna capa por sí sola es suficiente. Juntas, representan lo más cercano a la visibilidad genuina en 2026 sobre una amenaza que de otra forma sería invisible. El objetivo no es construir una muralla más grande — sino asegurar que cada túnel, autorizado o sombra, esté autenticado, fingerprinted, monitoreado y sometido a un estándar de identidad primero.