Ciberdelincuentes están suplantando la identidad de reclutadores para engañar a desarrolladores de software mediante entrevistas de trabajo falsas. A través de desafíos de programación que parecen pruebas reales, distribuyen dos herramientas de acceso remoto (RAT) multiplataforma llamadas NodeRabbit y PollCat. Esta campaña ha afectado a víctimas de los sectores de aviación, aeroespacial y tecnología financiera en países como Egipto, Etiopía y Afganistán.

Los atacantes están convirtiendo las llamadas del servicio de asistencia de Microsoft Teams en un punto de entrada para el malware y el compromiso de redes. Una campaña rastreada como Spring Ring utilizó cuentas externas que parecían soporte técnico interno para chatear con empleados, luego llamarlos y presionar para obtener acceso remoto o la ejecución de software.

La actividad se llevó a cabo desde enero hasta abril de 2026 y se puso en contacto con más de 150 empleados en al menos 10 organizaciones.

Su peligro reside en el elemento humano: un técnico con una voz familiar y una conversación en vivo pueden hacer que una solicitud inesperada parezca urgente y legítima.

Los analistas de Unit 42 identificaron la operación tras detectar la creación de chats sospechosos en múltiples inquilinos de Microsoft 365, descubriendo 26 identidades de atacantes distintas.

Palo Alto Networks afirmó en un informe que el grupo no explotó ningún fallo en Teams. En su lugar, abusó de las funciones de comunicación externa y de la confianza que los usuarios depositan en las herramientas de colaboración laboral.

La campaña demuestra por qué la suplantación de identidad en Teams merece el mismo escrutinio que el phishing por correo electrónico. Los atacantes pueden ajustar su historia durante una llamada, persuadir a una víctima para que ejecute una utilidad de soporte remoto y moverse rápidamente desde una sola estación de trabajo hacia sistemas que controlan toda una red.

Convierten las llamadas de soporte de Microsoft Teams en armas

Spring Ring comenzó con un chat de Teams uno a uno desde inquilinos .onmicrosoft.com controlados por el atacante. Las cuentas llevaban nombres visibles autoritarios como "help desk", "asistencia de TI" o "personal de soporte", mientras que algunas utilizaban nombres de personas reales para que el contacto pareciera más creíble.

Tras una solicitud de chat, el operador realizaba llamadas de voz no solicitadas, a veces dejando mensajes de voz e intentando repetidamente contactar con diferentes objetivos.

Las conversaciones exitosas solían durar entre 10 y 15 minutos, lo que daba tiempo al interlocutor para guiar a un empleado a través de pasos que normalmente generarían sospechas en un mensaje escrito.

En la Campaña A, el falso técnico persuadió a las víctimas para que iniciaran Quick Assist o descargaran software de monitoreo y gestión remota.

Una vez concedido el control remoto, el intruso comprobó el host y el dominio, y luego utilizó PowerShell para recuperar un troyano de acceso remoto ofuscado desde su infraestructura.

Este método recuerda estrechamente a una campaña reciente de phishing en Microsoft Teams en la que personal de soporte falso distribuyó malware a través del servicio de colaboración.

También refuerza una regla básica: debes verificar de forma independiente cualquier solicitud de soporte inesperada utilizando un contacto conocido de la empresa, nunca siguiendo las instrucciones de quien llama.

Del acceso remoto al control del dominio

La Campaña B utilizó un ejecutable alojado en la nube y personalizado cuyo nombre incluía la empresa y el empleado objetivo.

El programa se copió a sí mismo en el directorio Temp, creó componentes vhlp-<em>.exe y scnr-<em>.exe para lograr persistencia, e inició un proceso oculto de Microsoft Edge que cargaba una extensión sideloaded.

Luego, los atacantes utilizaron Python para escanear sistemas internos a través de SMB y generar tráfico NTLM hacia el controlador de dominio.

Intentaron PetitPotam, una técnica destinada a obligar al controlador a autenticarse en una máquina controlada por el atacante, donde esa autenticación podría ser retransmitida para obtener acceso a nivel de dominio.

El intento de toma de control fue bloqueado, pero la secuencia ilustra cómo una llamada de soporte puede convertirse en un ataque de identidad grave. Si sigues las estafas de suplantación de soporte de Teams, reconocerás la misma dependencia de cuentas externas y un pretexto de soporte convincente.

Las organizaciones deben limitar los chats externos de Teams a necesidades comerciales genuinas, alertar sobre un cambio rápido de chat a llamada e investigar lanzamientos inusuales de herramientas remotas, descargas desde la nube y actividad SMB.

Los equipos de seguridad también deben vigilar los eventos de autenticación que involucren a los controladores de dominio, un problema explicado en la cobertura de MITM6 y el retransmisor (relay) NTLM.

La educación del usuario debe ser específica: el personal de TI nunca debe pedirte que instales herramientas no aprobadas o que concedas el control de tu pantalla tras una llamada no solicitada.

Combinar esa política con el monitoreo conductual y la revisión de los datos de auditoría de Teams puede detectar la cadena a tiempo, como se describe en los informes sobre el abuso de las funciones de colaboración externa.

Las plataformas de comunicación confiables se están utilizando ahora como una ruta para la explotación a nivel de dominio. La defensa inmediata es sencilla: detente, verifica la solicitud por un canal alternativo y reporta la cuenta externa antes de abrir cualquier herramienta.

Este enfoque reduce la probabilidad de que un atacante convierta un intercambio rutinario en Teams en un incidente costoso para toda la empresa de la noche a la mañana.