Un falso técnico escribe por Teams: una sesión remota puede tomar el dominio
El 2 de septiembre de 2026, Microsoft Threat Intelligence publicó una investigación sobre una campaña de intrusión operada por personas: atacantes que se hacen pasar por soporte técnico contactan desde un tenant externo de Microsoft Teams y persuaden al empleado para que conceda control remoto. La investigación de Microsoft documenta cómo esa autorización permite instalar un implante con Node.js, reconocer Active Directory y desplazarse mediante WinRM hacia controladores de dominio y otros sistemas críticos.
La campaña seguía descrita como activa en la cobertura de TechRadar del 3 de septiembre. No se ha atribuido públicamente a un grupo concreto ni se ha cuantificado su alcance; el robo de datos y el ransomware son posibles fases posteriores, no resultados confirmados para todas las intrusiones.
Del contacto externo al implante de JavaScript
El ataque no explota una vulnerabilidad de Teams. El operador usa la colaboración externa para iniciar un chat o una llamada con una identidad que aparenta pertenecer al área de TI. Puede alegar una actualización de seguridad, una verificación de cuenta o una acción necesaria para impedir su desactivación.
Teams conserva señales como la etiqueta de remitente externo y las opciones para aceptar o bloquear el contacto. El engaño consiste en lograr que el usuario ignore esas advertencias, comparta la pantalla y apruebe el control, o abra Quick Assist y comunique el código de conexión. A veces se añade una conversación de voz, lo que permite guiar a la víctima sin dejar todas las instrucciones en el chat.
Una vez dentro, el atacante ejecuta PowerShell para descargar desde almacenamiento en la nube un MSI malicioso e instalarlo silenciosamente con Windows Installer. El paquete coloca un cargador y un implante cifrado en LocalAppData; si el equipo no dispone de Node.js, obtiene una distribución portátil legítima. El cargador descifra el código JavaScript y lo ejecuta mediante Node.js, PowerShell, cmd.exe o WScript.
La persistencia observada funciona por usuario: una entrada del registro o un acceso directo de inicio vuelve a lanzar el cargador cuando se abre la sesión. El uso combinado de instaladores, intérpretes y herramientas administrativas legítimas dificulta distinguir la intrusión de ciertas tareas ordinarias si cada proceso se examina por separado.
Las señales que revelan la cadena
Para el empleado, la combinación decisiva es un contacto no solicitado, marcado como externo, que invoca urgencia y solicita control remoto o elevación de privilegios. Ni un nombre visible como “Help Desk” ni el uso de una aplicación corporativa acreditan la identidad del interlocutor.
Para administradores y SOC, la cadena empieza con una sesión de asistencia seguida de cmd.exe o PowerShell y una instalación MSI sin interfaz. Después aparecen Node.js —en ocasiones renombrado— ejecutándose desde una ruta escribible por el usuario, cargadores con extensiones poco habituales y mecanismos de inicio bajo el perfil afectado.
El implante recibe tareas por HTTPS, recopila datos del equipo, consulta productos de seguridad y entornos virtualizados y realiza capturas periódicas del escritorio. A continuación, el operador enumera cuentas, usuarios y servidores mediante comandos nativos y consultas ADSI, construyendo un mapa de Active Directory antes de probar el acceso a otros equipos.
La fase observada de movimiento lateral utiliza WinRM desde el proceso de Node.js para alcanzar sistemas unidos al dominio. Entre los objetivos había servidores, controladores de dominio y autoridades de certificación. Esa progresión sustenta el alcance del titular: una sesión concedida en un puesto de trabajo puede abrir acceso hacia la infraestructura de identidad, aunque no equivalga por sí sola a controlar todo el dominio.
Cómo validar la supuesta solicitud de soporte
La verificación debe realizarse fuera del canal iniciado por el supuesto técnico. El empleado debe interrumpir el contacto y acudir al portal, teléfono o directorio interno que la organización ya haya establecido, sin utilizar enlaces, números o identidades proporcionados por el interlocutor.
- Comprobar si existe un ticket y si su identificador corresponde al problema alegado.
- Confirmar por un canal interno la identidad del técnico y la herramienta de asistencia autorizada.
- Preguntar qué acciones se realizarán y si requieren control interactivo o privilegios elevados.
- Rechazar la sesión si persisten la marca de contacto externo, la presión para actuar o una petición de ignorar avisos.
- Notificar el chat o la llamada al equipo de seguridad y conservar el historial.
El protocolo debe aplicarse también cuando el interlocutor conoce datos internos: esa información no sustituye la validación del ticket. Entre las medidas preventivas descritas para esta campaña figuran establecer frases internas de autenticación, restringir el acceso externo de Teams a dominios de confianza cuando sea viable y limitar las herramientas de soporte remoto permitidas.
Contención después de conceder el control
Si la sesión ya fue autorizada, la prioridad es cortar el acceso y preservar la información necesaria para determinar el alcance. El usuario debe finalizar la asistencia y avisar por un canal independiente; el equipo de respuesta debe aislar el endpoint conforme a su procedimiento y conservar registros de Teams, de la herramienta remota, de PowerShell, de Windows Installer y de los procesos ejecutados.
La investigación no debe detenerse en el ordenador inicial. La evaluación de SOC Prime recomienda asumir que las credenciales accesibles pueden estar comprometidas, rotarlas y revisar ejecuciones de Node.js desde directorios escribibles, actividad de WinRM e interacciones externas de Teams.
También corresponde revocar las sesiones activas de la identidad afectada, comprobar cambios en sus métodos de autenticación y buscar conexiones hacia otros equipos. Si aparecen cuentas privilegiadas, servidores o infraestructura de certificados en la trayectoria, la contención debe ampliarse a esos activos y a las credenciales usadas desde ellos. Bloquear únicamente al remitente de Teams no elimina un implante persistente ni una conexión lateral ya establecida.
El alcance sigue sin estar cuantificado
Microsoft ha publicado la cadena técnica, indicadores de actividad y consultas de búsqueda, pero no ha identificado públicamente a los operadores ni ha indicado cuántas organizaciones fueron afectadas. Lo observado llega hasta la persistencia, el reconocimiento del dominio, las capturas de pantalla y las conexiones laterales hacia sistemas de alto valor.
Tampoco se ha establecido que todas las intrusiones terminaran en exfiltración o cifrado. Hasta que aparezcan datos de víctimas o una atribución, el límite factual es ese: la campaña puede preparar robo, extorsión o ransomware, mientras que el compromiso confirmado consiste en transformar una sesión remota autorizada mediante engaño en un punto de apoyo con capacidad de expansión por la red.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.