Spring Ring, la campaña de vishing en Microsoft Teams que apunta al control del dominio de Windows
Cloud Security

Imagen ilustrativa generada con IA

Spring Ring, la campaña de vishing en Microsoft Teams que apunta al control del dominio de Windows

Campaña Spring Ring usa falso help desk en Teams para lograr acceso remoto vía Quick Assist y RMM e intentar relay NTLM al domain controller.

Texto generado por inteligencia artificial, publicado sin revisión humana. Transparencia IA

Un supuesto técnico del help desk abre un chat en Microsoft Teams, llama a la víctima y la guía en la instalación de herramientas de acceso remoto. Detrás de esta asistencia simulada hay, sin embargo, una operación ofensiva que puede llegar hasta el domain controller.

La campaña, denominada Spring Ring por Palo Alto Networks y detectada el 2 de septiembre de 2026, tuvo como objetivo al menos a 150 usuarios pertenecientes a un mínimo de 10 organizaciones. La actividad observada se desarrolló entre enero y abril.

Los atacantes combinaron ingeniería social, software legítimo de soporte remoto, payloads de PowerShell y técnicas de relay NTLM. En el vector más avanzado intentaron obligar a un domain controller a autenticarse contra una infraestructura bajo su control.

El falso help desk entra directamente en Teams

El ataque comienza dentro de Microsoft Teams, una plataforma que muchos empleados asocian automáticamente con comunicaciones corporativas fiables. Los atacantes crean conversaciones utilizando nombres visibles que hacen referencia al help desk, al soporte informático o al personal de asistencia.

A continuación, realizan una llamada de voz. Este paso permite al supuesto técnico ejercer presión en tiempo real, responder a las dudas y guiar a la víctima a través de una secuencia precisa de operaciones.

Las llamadas que llegan a completarse duran generalmente entre 10 y 15 minutos. Los operadores también muestran cierta persistencia: repiten los intentos de contacto y, cuando es necesario, dejan mensajes de voz.

El objetivo no es convencer al usuario de que haga un solo clic. La víctima es inducida a ejecutar programas, instalar herramientas de administración remota o abrir archivos preparados específicamente para su organización.

Se trata de un cambio relevante respecto al phishing tradicional. El empleado no solo debe evaluar un mensaje estático, sino tomar decisiones durante una conversación con alguien que se presenta como un compañero autorizado.

Según un informe de threat hunting de CrowdStrike citado en el análisis de la campaña, los ataques de vishing se habrían duplicado durante la primera mitad de 2026. Sin embargo, este dato no constituye una confirmación independiente de Spring Ring.

Quick Assist y el software RMM abren el primer acceso

En el primer escenario observado, el supuesto técnico convence al usuario para iniciar Windows Quick Assist o un software RMM, es decir, una herramienta legítima para la monitorización y la gestión remota de dispositivos.

Los administradores suelen utilizar estos programas para proporcionar asistencia. Sin embargo, si la víctima autoriza la sesión, el atacante puede obtener el control del equipo sin necesidad de explotar una vulnerabilidad de software.

Tras acceder al sistema, los operadores de Spring Ring realizan un reconocimiento inicial del host y del dominio de Windows. De este modo, intentan comprender la configuración del dispositivo, el contexto corporativo y las posibles oportunidades para continuar la intrusión.

En una de las actividades analizadas se intentó descargar un RAT escrito en PowerShell y ofuscado. El payload habría proporcionado capacidades de acceso remoto persistente, pero la protección del endpoint bloqueó su ejecución.

No se ha hecho público el nombre del RAT. Tampoco hay hashes de archivos, dominios, direcciones IP u otros indicadores técnicos que puedan utilizarse directamente para una búsqueda retrospectiva.

Esta carencia hace que la detección basada en el comportamiento sea aún más importante. Limitarse a buscar una firma de malware específica puede dejar sin detectar la fase inicial, llevada a cabo mediante herramientas autorizadas y acciones confirmadas por el usuario.

Del navegador oculto al intento de relay NTLM

El segundo vector presenta una cadena técnica más compleja. Los atacantes dirigen a la víctima hacia archivos alojados en infraestructuras cloud y personalizados en función del usuario y de la organización objetivo.

Los ejecutables establecen un mecanismo de persistencia e inician una instancia oculta de Microsoft Edge. A continuación, cargan lateralmente una extensión, realizan un reconocimiento de la red interna y generan tráfico de autenticación NTLM.

La fase más peligrosa consiste en un intento de NTLM relay basado en PetitPotam. Esta técnica busca inducir a un sistema Windows —en este caso, el domain controller— a iniciar una autenticación contra un destino controlado por el atacante.

A continuación, el atacante intenta reenviar esa autenticación a otro servicio para aprovecharla y obtener privilegios que no posee directamente. Si la operación tiene éxito en sistemas y configuraciones expuestos, el control puede extenderse desde el endpoint inicial hasta la infraestructura de identidades.

El objetivo final es especialmente sensible. Un domain controller gestiona las autenticaciones, las cuentas, las políticas y las relaciones de confianza del entorno Windows; comprometerlo puede allanar el camino hacia el control de todo el dominio.

El servicio de managed detection de Unit 42, la división de Palo Alto Networks, bloqueó el intento de hacerse con el control de la infraestructura. Por tanto, no consta que el domain controller observado llegara a verse comprometido.

Alcance y límites de la información disponible

Palo Alto Networks contabilizó al menos 150 usuarios objetivo en un mínimo de 10 organizaciones. Sin embargo, no se ha comunicado una tasa de éxito global, por lo que no es posible determinar cuántas víctimas ejecutaron los archivos o concedieron el acceso remoto.

Los dos intentos descritos en detalle fueron detenidos: el RAT de PowerShell por la protección del endpoint y el ataque contra el dominio por el servicio Unit 42. Esto no demuestra que todos los incidentes asociados a la campaña tuvieran el mismo desenlace.

No se han indicado las versiones específicas de Microsoft Teams, Windows, Quick Assist o Edge implicadas. Spring Ring no se presenta como la explotación de un fallo en una versión concreta, sino como el abuso de funciones legítimas combinado con técnicas de ingeniería social y autenticación de Windows.

Por consiguiente, no se ha indicado ningún parche correctivo ni una CVE asociada a la campaña. Mantener los sistemas actualizados sigue siendo una medida necesaria, pero no neutraliza una llamada telefónica en la que el usuario autoriza voluntariamente una sesión remota.

Los datos disponibles proceden de la investigación de Palo Alto Networks. No se ha aportado una corroboración independiente del mismo conjunto de incidentes.

Cómo reconocer y contener Spring Ring

La primera contramedida consiste en separar la plataforma de contacto de la verificación de identidad. Una solicitud recibida a través de Teams no debe considerarse auténtica únicamente porque aparezca en un entorno corporativo.

Cuando un supuesto técnico pide iniciar Quick Assist, instalar un RMM o ejecutar un archivo, el empleado debe interrumpir el procedimiento y ponerse en contacto con el help desk mediante un número o un portal ya conocido. No debe utilizar los datos de contacto proporcionados por el interlocutor.

Las organizaciones también pueden actuar en varios niveles:

  • limitar Quick Assist y las herramientas RMM a los usuarios, dispositivos y flujos de asistencia autorizados;
  • registrar el inicio de sesiones remotas inesperadas y correlacionarlo con nuevos contactos recibidos en Teams;
  • detectar PowerShell ofuscado, descargas anómalas, navegadores iniciados en modo oculto y sideloading de extensiones;
  • revisar los archivos ejecutables descargados desde servicios cloud, especialmente si están personalizados o se entregan durante una llamada;
  • analizar las autenticaciones NTLM hacia destinos externos o sistemas no aprobados;
  • buscar comportamientos compatibles con la coerción de autenticación y el relay;
  • reforzar la monitorización de los domain controllers y de las anomalías relacionadas con las identidades;
  • formar al personal mediante simulaciones de llamadas de voz, no solo con ejercicios de phishing por correo electrónico.

Ante la ausencia de hashes y direcciones de red públicas, los indicadores más útiles son los relacionados con el comportamiento: contactos repetidos desde cuentas de soporte falsas, llamadas inesperadas, inicio no autorizado de RMM, ejecución de PowerShell y tráfico NTLM inusual.

Los problemas de disponibilidad de Teams son incidentes separados

El 4 de septiembre de 2026 también se notificaron problemas operativos en Microsoft Teams, pero no hay elementos que los vinculen con Spring Ring.

El incidente TM1466820 puede impedir la apertura del cliente de escritorio de Windows o retrasar hasta dos minutos la primera carga. Microsoft señaló Teams en la web, la aplicación móvil y otros métodos de acceso como soluciones temporales.

Otro problema, identificado como TM1466659, afecta a algunos usuarios de Mac que no pueden participar en llamadas o reuniones. Microsoft estaba analizando los registros y reevaluando la causa después de una primera hipótesis relacionada con una modificación del código.

Se trata de fallos de disponibilidad, no de pruebas de una intrusión. No consta que hayan causado, facilitado u ocultado los ataques de Spring Ring.

La distinción es esencial: la campaña explota la confianza depositada en las herramientas de colaboración, no los problemas de servicio notificados en los clientes. Por tanto, la defensa debe centrarse tanto en los controles técnicos como en la verificación de los procesos de asistencia y de las identidades.

Lee también

Fuentes

Este artículo es una reelaboración original basada en las siguientes fuentes.

Temas relacionadosSpring Ringvishing Microsoft Teamsfalso help deskQuick Assistherramientas RMMNTLM relaydomain controller
Volver al inicio