Un grupo de ransomware se escondió dentro de Microsoft Teams durante 2 meses y nadie lo notó. No porque Teams fue hackeado, sino porque Teams funcionó exactamente como fue diseñado. Analizamos el caso y la señal es clara: la infraestructura en la que más confían las organizaciones se convirtió en el escondite perfecto.
La escala del problema: 2 meses escondido en Teams
Según Broadcom/Symantec, que documentó el caso el 16 de junio de 2026, el Backdoor.Turn es un backdoor custom en Go y el primer malware in the wild que abusa de la infraestructura TURN relay de Microsoft Teams para comunicación C&C. La víctima: una gran empresa de servicios de EE. UU. El grupo DragonForce permaneció indetectable durante dos meses, no por una falla de detección, sino porque el tráfico era, por diseño, indistinguible de una colaboración legítima.
La paradoja es lo que importa. La orientación que la propia Microsoft publica, whitelist de IPs de Teams, exención de TLS inspection, split-tunnel VPN bypass, es exactamente lo que hace indetectable el tráfico. Los equipos de seguridad reciben instrucciones de confiar en ese tráfico. El atacante usa esa confianza como escondite.
La técnica: Backdoor.Turn y el abuso del TURN relay
El mecanismo es lo que diferencia al Backdoor.Turn de un C2 convencional. Según Broadcom/Symantec, el backdoor obtiene un token anónimo de visitor de Teams, sin cuenta, sin reunión. Usa el token para interactuar con un servidor TURN legítimo de Microsoft durante el setup de la conexión. Luego establece una sesión QUIC directa hacia el C2 del atacante.
Para los defensores de red, el tráfico observado son conexiones outbound hacia servidores legítimos de Microsoft Teams. No hay dominio sospechoso que bloquear. No hay certificado extraño que inspeccionar. No hay payload anómalo que detectar en la capa de red. El tráfico es, por diseño, confiable.
El precedente: Praetorian Ghost Calls y la omisión de Microsoft
La técnica no nació con DragonForce. Según Praetorian, que demostró la técnica "Ghost Calls" en el Black Hat USA 2025, el abuso del TURN relay para C2 se conoce desde hace al menos un año. Zoom corrigió en días: restringió las credenciales TURN para que alcanzaran solo su propia infraestructura. Microsoft no implementó una restricción similar.
Diez meses después, DragonForce fue el primero en usar la técnica in the wild. No es una vulnerabilidad. Es abuso de una funcionalidad legítima. El token de visitor anónimo y el TURN relay son features, no bugs. Por eso no tiene CVE. Y por eso es más difícil de corregir: bloquear afecta la funcionalidad legítima de Teams.
La cadena completa del ataque de DragonForce
La cadena es lo que muestra la sofisticación de la operación. Según el análisis, el acceso inicial fue vía SQL server en diciembre de 2025. Después: DLL sideloading vía DbgView64.exe legítimo. Persistencia con scheduled tasks, registry run keys y creación de usuarios. Evasión defensiva con BYOVD multi-vector.
Los drivers vulnerables, Huawei, Topaz, Tower of Fantasy y K7 Security, más un driver custom ABYSSWORKER enmascarado como Palo Alto, terminan procesos de seguridad a nivel de kernel. Después: exfiltración, despliegue del ransomware DragonForce, cifrado. El Backdoor.Turn fue inyectado después del cifrado: persistencia post-ataque o reventa de acceso.
BYOVD: matando el EDR antes del backdoor
El detalle que lo cambia todo: el atacante mató primero el EDR con BYOVD antes de desplegar el backdoor. BYOVD (Bring Your Own Vulnerable Driver) es la técnica de cargar un driver legítimo y firmado, pero vulnerable, para escalar privilegios y terminar procesos de seguridad a nivel de kernel. Sin EDR, el backdoor opera sin oposición.
Microsoft mantiene la Vulnerable Driver Block List, pero debe estar enforced, no opcional. Según la propia Microsoft, la lista protege contra drivers firmados pero vulnerables. Sin enforcement, cada driver vulnerable cargado es un EDR muerto.
El problema de categoría: no es solo Teams
El problema es de categoría. No es solo Teams. Cualquier plataforma de comunicación en tiempo real con TURN relay, Zoom, WebEx, Google Meet, es potencialmente vulnerable a la misma técnica. Toda la categoría de "tráfico de colaboración confiable" está comprometida.
Si tu estrategia de detección es "ese tráfico va hacia Microsoft, entonces es seguro", tienes un punto ciego. Y el punto ciego no es solo de Microsoft: es de toda plataforma de colaboración que usa TURN relay.
La defensa: detección en endpoint, no en red
La defensa es la detección en el endpoint, no en la red. Comportamiento de proceso: inyección en DbgView64.exe, QUIC anómalo de procesos no estándar. Monitorear el Event ID 7045, registro de nuevo kernel driver. La Microsoft Vulnerable Driver Block List debe estar enforced. Zero Trust: verificar el comportamiento, no la plataforma.
El tráfico que va hacia Microsoft no es automáticamente seguro. El tráfico que va hacia Zoom no es automáticamente seguro. La plataforma no es la señal de confianza: el comportamiento lo es.
Conclusión: la infraestructura confiable se convirtió en el escondite perfecto
Lo repetimos: la infraestructura en la que más confían las organizaciones se convirtió en el escondite perfecto. El Backdoor.Turn no hackeó Teams: usó Teams como fue diseñado. Y el atacante mató primero el EDR con BYOVD antes de desplegar el backdoor, garantizando que nada se interpusiera en el camino.
La defensa no es bloquear Teams. La defensa es detectar comportamiento, no plataforma. Monitorear el proceso, no solo la red. Hacer enforce de la Vulnerable Driver Block List. Aplicar Zero Trust al tráfico de colaboración. En Tech86 ayudamos a empresas a construir exactamente este tipo de detección, antes de que el tráfico confiable se convierta en el canal de comando y control del próximo ataque.