Durante casi dos meses, el equipo de seguridad de una gran empresa de servicios en Estados Unidos vio algo aparentemente normal en su tráfico de red: conexiones salientes hacia infraestructura legítima de Microsoft Teams.
No había dominios extraños. No había servidores recién registrados. No había un destino de mala reputación al que bloquear.
Y, sin embargo, dentro de ese tráfico aparentemente legítimo viajaba el canal de mando y control de un grupo de ransomware.
El caso fue analizado por los equipos de inteligencia de amenazas de Symantec y Carbon Black, que publicaron el 16 de junio de 2026 su investigación sobre Backdoor.Turn, una puerta trasera escrita en Go y vinculada a operaciones de DragonForce. La particularidad del malware no estaba solo en sus capacidades, sino en la forma en la que ocultaba sus comunicaciones: abusando de los relays TURN que Microsoft Teams utiliza para facilitar llamadas y comunicaciones en tiempo real.
Según Symantec / Security.com, Backdoor.Turn es el primer malware conocido observado en un ataque real que abusa de los relays TURN de Microsoft Teams para ocultar tráfico de mando y control. Es una técnica especialmente preocupante porque desmonta una suposición todavía muy extendida en muchas organizaciones: que el tráfico hacia dominios o infraestructura de Microsoft es, por definición, tráfico de confianza.
El problema no es que Teams haya sido “hackeado” como producto. El problema es más incómodo: los atacantes utilizaron una función legítima de un servicio de confianza para esconderse a plena vista.
Qué ocurrió, en orden
Según el análisis de Symantec, recogido también por The Hacker News y Help Net Security, los atacantes permanecieron entre uno y dos meses dentro de la red de la víctima.
Durante ese tiempo comprometieron el entorno, realizaron reconocimiento, escalaron su posición, accedieron a sistemas internos y desplegaron el ransomware DragonForce. Después introdujeron Backdoor.Turn en la organización, inyectándolo en un proceso legítimo: DbgView64.exe, una utilidad de Sysinternals que no debería ejecutarse sin una razón clara en muchos servidores de producción.
Ese orden es importante.
Backdoor.Turn no parece diseñado para ser el primer punto de entrada, sino para mantener acceso posterior. En otras palabras: una vez producido el impacto principal del ransomware, la puerta trasera permitía conservar un canal discreto para volver, vender el acceso, preparar una segunda extorsión o mantener presión sobre la víctima.
Para los defensores, la dificultad era evidente: durante semanas, la telemetría de red no mostraba un destino sospechoso. Lo que se veía eran conexiones salientes hacia servidores legítimos de Microsoft.
La intrusión no se escondía a pesar de Teams. Se escondía dentro del tráfico que las organizaciones esperan ver cuando usan Teams.
Cómo funciona: TURN, STUN y tokens de invitado
Para entender la técnica hay que explicar brevemente cómo funcionan las comunicaciones en tiempo real.
Servicios como Microsoft Teams necesitan atravesar cortafuegos, NAT y redes corporativas para que dos usuarios puedan hablar, compartir pantalla o mantener una videollamada. Para ello se utilizan mecanismos como ICE, STUN y TURN.
STUN ayuda a descubrir cómo puede comunicarse un cliente a través de NAT. TURN actúa como intermediario cuando la comunicación directa entre extremos no es posible. En ese caso, un relay de Microsoft reenvía el flujo entre participantes. Es una pieza legítima y necesaria para que Teams funcione correctamente.
Microsoft documenta que Teams utiliza conectividad TCP 80/443 y UDP 3478-3481 para estos flujos de medios y conectividad. Por tanto, en muchas empresas ese tráfico está permitido por diseño.
Backdoor.Turn convierte ese mecanismo legítimo en un canal encubierto.
El malware solicita primero un token de visitante anónimo a servicios de identidad asociados a Skype/Teams, similar al tipo de credencial que permite a un invitado unirse a una reunión sin una cuenta corporativa tradicional. Con ese token se autentica contra la infraestructura de Microsoft Teams y usa un relay TURN legítimo para establecer conectividad.
A partir de ahí, el malware ejecuta una sesión QUIC hacia el servidor real de mando y control del atacante. El resultado es muy eficaz desde el punto de vista ofensivo: el C2 real no aparece directamente como destino evidente en la red de la víctima. Lo que ve el equipo de seguridad son conexiones hacia infraestructura legítima de Microsoft.
El atacante no necesita construir una infraestructura nueva para esconderse. Usa una infraestructura que la empresa ya confía, ya permite y rara vez inspecciona con el mismo nivel de sospecha que un dominio desconocido.
Por qué QUIC complica la detección
QUIC es un transporte cifrado sobre UDP, asociado habitualmente a HTTP/3 y a servicios modernos que buscan reducir latencia. En muchos entornos circula por UDP/443, aunque en el caso de Teams también hay que tener en cuenta los puertos UDP específicos asociados a medios, como 3478-3481.
Desde el punto de vista defensivo, esto crea varios problemas.
Muchas organizaciones inspeccionan con más detalle el tráfico TLS sobre TCP que el tráfico UDP. Otras permiten UDP hacia servicios SaaS de confianza para no romper aplicaciones críticas. Y muchas excluyen dominios o rangos de Microsoft de controles estrictos para evitar impactos operativos.
Backdoor.Turn aprovecha precisamente esa combinación: tráfico cifrado, salida UDP, destino legítimo y una aplicación empresarial ampliamente permitida.
La conclusión no es que haya que bloquear Teams ni romper QUIC indiscriminadamente. La conclusión es que permitir un destino legítimo no debería equivaler a confiar en cualquier comportamiento que pase por ese destino.
Qué puede hacer Backdoor.Turn una vez dentro
Backdoor.Turn no es solo un canal de comunicación. Una vez establecido el túnel, ofrece al operador capacidades suficientes para seguir operando dentro del entorno comprometido.
Entre las funciones atribuidas al malware están:
- Ejecución remota de comandos.
- Creación de nuevos procesos en el equipo comprometido.
- Reconocimiento de Active Directory mediante consultas LDAP.
- Escaneo de red para descubrir otros equipos y servicios alcanzables.
- Robo de credenciales, incluidas credenciales almacenadas en navegadores.
- Movimiento lateral basado en credenciales comprometidas.
- Persistencia mediante una comunicación saliente difícil de distinguir del tráfico corporativo normal.
En la práctica, es el mismo patrón que se observa en muchas intrusiones modernas: compromiso inicial, reconocimiento interno, escalada, acceso a identidad, movimiento lateral, exfiltración, despliegue de ransomware y mantenimiento de acceso.
La diferencia está en el canal de salida. En lugar de hablar con un servidor sospechoso, el malware se apoya en infraestructura de Microsoft Teams.
Por qué los controles tradicionales pueden no verlo
Muchos modelos de filtrado de salida siguen funcionando por destino: se permiten dominios y rangos de Microsoft, se vigilan destinos desconocidos y se bloquean categorías de mala reputación.
En este caso, ese enfoque falla.
El destino es legítimo. La reputación es buena. El servicio es necesario. El tráfico puede parecer compatible con una aplicación empresarial habitual.
La inspección TLS tradicional tampoco resuelve el problema por sí sola si el canal observado utiliza QUIC/UDP o si la organización excluye determinados servicios SaaS de la inspección para evitar problemas de rendimiento o privacidad.
Tampoco hay una CVE clásica que parchear. No estamos ante un caso en el que el atacante explote una vulnerabilidad concreta de Teams para tomar control del producto. Estamos ante un abuso de funcionalidad legítima: relays TURN, tokens de invitado y conectividad permitida hacia servicios confiables.
La defensa, por tanto, no puede basarse solo en reputación de dominio, listas blancas o inspección perimetral. Tiene que mirar comportamiento.
Qué proceso genera la conexión. Desde qué equipo. Con qué usuario. En qué horario. Con qué patrón de volumen. Qué hace ese mismo proceso en el sistema. Qué consultas realiza contra Active Directory. Qué credenciales toca. Qué otros movimientos ocurren antes y después.
Ahí es donde entran el EDR, el XDR, el NDR, el SIEM, la identidad y el threat hunting.
El contexto: DragonForce y la profesionalización del ransomware
El nivel de sofisticación de este caso encaja con la evolución reciente de DragonForce.
Según la radiografía de ransomware de Check Point Research, DragonForce reivindicó 101 víctimas en el primer trimestre de 2026, un 29% más que en el trimestre anterior. La progresión fue clara: 10 víctimas en enero, 35 en febrero y 56 en marzo.
Más allá del nombre concreto del grupo, lo relevante para una empresa es la tendencia: el ransomware ya no es solo cifrado de archivos. Es una operación empresarial criminal con afiliados, infraestructura compartida, robo de datos, presión reputacional, negociación, reventa de accesos y técnicas que hace unos años se asociaban a actores mucho más selectivos.
En septiembre de 2025, DragonForce promovió públicamente una idea de colaboración con otras operaciones como LockBit y Qilin. Se habló de modelo “cartel”, aunque más que una fusión formal conviene entenderlo como una estrategia de marca, afiliación e infraestructura compartida.
Para los defensores, la etiqueta importa menos que el resultado: grupos con más recursos, más especialización y mayor capacidad para reutilizar técnicas avanzadas en ataques con motivación económica.
Detección operativa: qué buscar
Si la red por sí sola no basta, la detección debe desplazarse hacia el endpoint, la identidad y la correlación entre fuentes.
Una hipótesis de caza razonable sería buscar procesos atípicos que generen conexiones UDP sostenidas hacia infraestructura de Microsoft Teams, especialmente cuando esos procesos no tienen relación con Teams, comunicaciones unificadas o navegadores habituales.
También conviene revisar la ejecución de utilidades Sysinternals en servidores, especialmente si aparecen fuera de equipos de administración o sin un cambio autorizado. DbgView64.exe, PsExec u otras herramientas legítimas pueden ser normales en manos de un administrador, pero sospechosas en un servidor de producción o en un equipo que no debería usarlas.
Señales que merece la pena instrumentar:
En Microsoft Defender, Microsoft Sentinel u otras plataformas XDR/SIEM, la clave está en cruzar proceso, red, usuario, host e identidad. Mirar solo el destino puede no servir. Mirar el comportamiento completo sí puede cambiar la historia.
Para profundizar en este enfoque, es recomendable revisar estrategias de threat hunting, SOC gestionado y detección y respuesta MDR/XDR.
Defensa práctica: qué deberían hacer las empresas
No hay un botón único que apague este riesgo, pero sí medidas que reducen la probabilidad de compromiso y, sobre todo, el tiempo de permanencia del atacante.
1. Gobernar el tráfico UDP y QUIC de salida
No se trata de bloquear Microsoft Teams de forma indiscriminada. Eso puede afectar a la calidad de llamadas, reuniones y compartición de pantalla.
La medida correcta es gobernar el tráfico de salida:
- Permitir UDP/QUIC solo donde sea necesario.
- Diferenciar políticas para usuarios, servidores y equipos de administración.
- Registrar proceso origen, usuario, equipo y destino.
- Revisar excepciones amplias hacia SaaS críticos.
- Detectar procesos que no deberían generar tráfico de medios o QUIC.
- Aplicar segmentación para que un equipo comprometido no pueda moverse libremente.
La segmentación de red sigue siendo una defensa básica: si el atacante consigue un canal de salida, al menos debe encontrar límites internos.
2. Tratar las herramientas legítimas como señales contextuales
Sysinternals, PowerShell, PsExec, herramientas de administración remota o binarios firmados no son malos por sí mismos. Pero fuera de contexto pueden ser una señal muy valiosa.
La pregunta no es “¿esta herramienta es legítima?”. La pregunta es:
- ¿Debe estar ejecutándose aquí?
- ¿La lanzó un usuario autorizado?
- ¿Aparece en un servidor donde nunca se usa?
- ¿Coincide con conexiones de red anómalas?
- ¿Se ejecuta antes o después de consultas LDAP o creación de procesos sospechosos?
Este enfoque forma parte de una buena auditoría de seguridad informática y de una operación SOC madura.
3. Reforzar EDR, XDR y reglas de reducción de superficie
Un EDR instalado pero sin reglas activas, sin alertas afinadas o sin respuesta operativa 24/7 aporta menos de lo que parece.
En casos como Backdoor.Turn, es importante tener visibilidad sobre:
- Inyección de procesos.
- Creación de procesos hijos anómalos.
- Acceso a credenciales.
- Comportamiento de reconocimiento.
- Ejecución de herramientas administrativas fuera de patrón.
- Persistencia.
- Conexiones salientes atípicas por proceso.
La combinación de EDR, XDR y MDR ayuda a transformar alertas aisladas en una investigación completa.
4. Monitorizar identidad y Active Directory
El ransomware moderno rara vez se limita a cifrar una máquina. Normalmente intenta entender el dominio, encontrar cuentas privilegiadas, moverse lateralmente y ampliar el impacto.
Por eso es crítico monitorizar:
- Consultas LDAP inusuales.
- Enumeración de usuarios y grupos.
- Accesos a controladores de dominio.
- Uso de cuentas privilegiadas fuera de horario.
- Kerberoasting, abuso de AD CS y técnicas contra Active Directory híbrido.
- Movimiento lateral entre servidores.
En entornos híbridos, conviene revisar específicamente los riesgos de Active Directory híbrido y la postura de identidad y Zero Trust.
5. Combinar NDR, endpoint e identidad
Ninguna fuente por separado lo ve todo.
La red puede ver conexiones a Microsoft, pero no siempre sabrá si el proceso origen es legítimo. El endpoint puede ver procesos y credenciales, pero no siempre tendrá contexto global de comunicaciones. La identidad puede mostrar accesos anómalos, pero no siempre explicará qué binario los originó.
La defensa real está en la correlación.
Un SOC debe poder responder preguntas como:
- ¿Qué proceso abrió esta conexión?
- ¿Desde qué host?
- ¿Con qué usuario?
- ¿Ese host suele usar Teams?
- ¿Ese proceso ha ejecutado comandos?
- ¿Ha consultado LDAP?
- ¿Ha accedido a credenciales?
- ¿Ha intentado moverse lateralmente?
- ¿Ha generado tráfico persistente hacia destinos permitidos?
Aquí es donde un SOC gestionado y una capa de NDR aportan valor real.
6. Preparar la respuesta antes del incidente
Cuando el canal de mando y control se esconde dentro de servicios de confianza, la contención no puede depender solo de bloquear un dominio.
La respuesta debe contemplar:
- Aislamiento rápido de endpoints.
- Revocación de sesiones y credenciales.
- Rotación de cuentas privilegiadas.
- Revisión de persistencia.
- Búsqueda de accesos secundarios.
- Análisis forense de equipos afectados.
- Revisión de logs de identidad, red y SaaS.
- Comunicación interna y externa.
- Restauración segura desde backups verificados.
Un plan de respuesta a incidentes y un retainer de respuesta pueden marcar la diferencia entre horas y semanas.
Implicaciones de cumplimiento: NIS2, DORA y ENS
Este caso muestra de forma muy clara por qué las normas actuales insisten tanto en detección, respuesta y resiliencia.
NIS2 exige que las organizaciones relevantes gestionen riesgos, adopten medidas técnicas y organizativas adecuadas y mejoren su capacidad de respuesta ante incidentes. Un atacante que permanece uno o dos meses dentro de la red con un canal difícil de ver es exactamente el tipo de escenario que la norma busca reducir.
DORA pone el foco en la resiliencia operativa digital del sector financiero y sus proveedores críticos. Un incidente como este afecta de lleno a la capacidad de detectar, contener, recuperar y demostrar control sobre la operación tecnológica.
ENS exige trazabilidad, monitorización, gestión de incidentes y medidas proporcionales al nivel de seguridad requerido. En categoría media o alta, no basta con tener controles documentados: hay que poder reconstruir qué ocurrió, cuándo, cómo y con qué impacto.
La lección común es sencilla: el cumplimiento no puede quedarse en papel. Sin visibilidad de endpoint, control del tráfico de salida, monitorización de identidad, gestión de vulnerabilidades y caza basada en comportamiento, las organizaciones pueden cumplir formalmente y seguir estando ciegas ante un atacante real.
Para profundizar en este enfoque, puedes revisar las guías y servicios de Hard2bit sobre NIS2, DORA, ENS e ISO 27001.
Qué deberían revisar ahora los equipos de seguridad
A raíz de este caso, una empresa debería revisar al menos estos puntos:
- Qué servidores y puestos pueden generar tráfico UDP/QUIC hacia Internet.
- Qué procesos originan conexiones hacia infraestructura de Microsoft Teams.
- Si existen excepciones demasiado amplias hacia Microsoft 365.
- Si los servidores tienen permitido usar Teams o flujos de medios sin necesidad real.
- Si se monitoriza ejecución de Sysinternals fuera de contexto.
- Si el EDR alerta ante inyección de procesos y ejecución anómala.
- Si hay visibilidad sobre consultas LDAP y reconocimiento de Active Directory.
- Si se correlacionan eventos de endpoint, red e identidad.
- Si el SOC tiene hipótesis de caza para abuso de servicios de confianza.
- Si el plan de respuesta permite aislar equipos, revocar sesiones y contener identidad rápidamente.
Estos puntos pueden evaluarse dentro de una auditoría de Microsoft 365, una revisión de seguridad Microsoft 365, una auditoría de infraestructura y red o un ejercicio de Red Team.
La lección principal
La frontera ya no es el dominio al que se conecta un equipo. La frontera es el comportamiento.
Confiar en un destino porque pertenece a Microsoft, Google, Amazon o cualquier otro proveedor legítimo es precisamente la suposición que este tipo de técnicas explota.
La defensa que funciona no se limita a preguntar “¿a dónde va el tráfico?”. También pregunta:
- ¿Quién lo genera?
- ¿Desde qué equipo?
- ¿Con qué proceso?
- ¿En qué momento?
- ¿Qué hizo antes?
- ¿Qué intenta hacer después?
- ¿Tiene sentido para ese usuario, servidor y contexto?
Backdoor.Turn no demuestra que Teams sea inseguro. Demuestra que los atacantes están aprendiendo a vivir dentro de las excepciones, servicios y confianzas que las empresas necesitan para operar.
La respuesta no es desconfiar de todo sin criterio. La respuesta es dejar de medir la confianza solo por el destino y empezar a medirla por el comportamiento.
¿Tu organización sabría detectar un canal de C2 oculto en tráfico legítimo?
En Hard2bit ayudamos a empresas a mejorar su capacidad real de detección, respuesta y resiliencia frente a ransomware, abuso de identidad y amenazas avanzadas.
Podemos ayudarte con:
- SOC gestionado
- Threat hunting
- Respuesta a incidentes
- Auditoría de Microsoft 365
- Auditoría de seguridad informática
- Gestión de vulnerabilidades
- NIS2
- DORA
- ENS
Si quieres revisar si tu organización tiene visibilidad suficiente sobre endpoint, red, identidad y Microsoft 365, puedes contactar con nuestro equipo desde la página de contacto de Hard2bit.
Fuentes recomendadas
- Symantec / Security.com: Hidden in Teams: DragonForce Attackers Weaponize Microsoft Teams Relays to Stay Hidden
- The Hacker News: DragonForce Hackers Abuse Microsoft Teams Relays to Hide Backdoor.Turn C2 Traffic
- Help Net Security: Cybercriminals mask malicious communications through Microsoft Teams relays
- Microsoft Learn: Microsoft Teams call flows
- Check Point Research: The State of Ransomware Q1 2026