Microsoft Threat Intelligence reveló una campaña de intrusión que comienza con un mensaje o una llamada a través de Microsoft Teams desde una entidad externa que suplanta a empleados de tecnología de la información o del servicio de asistencia. El atacante intenta convencer al empleado de omitir las advertencias sobre contactos externos y concederle control interactivo del dispositivo mediante herramientas como sesiones de soporte remoto o Quick Assist; después utiliza PowerShell para descargar e instalar silenciosamente un paquete MSI malicioso.
Según Microsoft, la campaña no explota una vulnerabilidad técnica de Microsoft Teams, sino que depende de la ingeniería social y de convencer al usuario para que omita las medidas de protección existentes. Su peligrosidad radica en que el punto de entrada parece un procedimiento de soporte habitual, mientras concede al atacante acceso interactivo, respaldado por las credenciales del usuario, a un dispositivo dentro de la organización.
Una cadena de ataque que utiliza herramientas confiables
Después de instalar el paquete MSI, la campaña coloca un cargador basado en texto y un archivo cifrado que contiene un implante de JavaScript dentro de la carpeta LocalAppData. Si Node.js no está instalado en el dispositivo, el paquete descarga una versión portátil legítima del entorno de ejecución desde la distribución oficial de Node.js y luego la utiliza para descifrar y ejecutar el implante.
El proceso se inicia mediante PowerShell, cmd.exe o WScript, y utiliza mecanismos de persistencia por usuario, como un valor Run en el registro o un acceso directo dentro de la carpeta Startup con el nombre EdgeUpdate. El implante se comunica con el servidor de comando y control mediante solicitudes HTTPS periódicas aleatorias y recibe tareas de JavaScript capaces de ejecutar comandos, inspeccionar el dispositivo, los programas de seguridad y el entorno virtual, y tomar capturas periódicas del escritorio.
Las muestras analizadas por Microsoft también contenían lógica desactivada para consultar un contrato inteligente en la red Ethereum con el fin de obtener una dirección actualizada del servidor de comando y control. La empresa explicó que el contrato no almacena ni ejecuta la carga maliciosa y que las muestras recuperadas utilizaban una dirección de respaldo fija.
Del dispositivo infectado a los sistemas de identidad
La actividad no se detiene con la instalación del implante. Los operadores utilizaron comandos nativos y consultas ADSI para enumerar cuentas del dominio, servidores y usuarios; después ejecutaron cargas adicionales mediante rundll32.exe. A continuación, el implante inició conexiones WinRM a través del puerto TCP 5985 hacia un gran número de sistemas unidos al dominio, incluidos servidores de archivos, bases de datos y aplicaciones, además de controladores de dominio y autoridades de certificación.
Este desplazamiento representa una transición práctica desde el engaño de un solo usuario hacia un intento de ampliar el control dentro de la organización. El material no demuestra que la campaña haya desplegado ransomware o robado datos efectivamente, pero indica que el reconocimiento y el movimiento hacia los sistemas de identidad son coherentes con etapas previas a objetivos posteriores, como el robo de datos, la extorsión o el despliegue de ransomware.
¿Por qué importa esta noticia?
La campaña demuestra que confiar en una herramienta legítima puede ser más peligroso que un archivo ejecutable desconocido. La presencia de Microsoft Teams, Node.js, Windows Installer y WinRM dentro de la cadena no significa que estas herramientas sean maliciosas, pero hace que depender únicamente de listas de programas permitidos resulte insuficiente. El indicador más importante es una secuencia de comportamiento inusual: una conexión externa urgente, seguida de una sesión de soporte remoto, después la ejecución de PowerShell o cmd.exe y la instalación de un MSI o la ejecución de Node.js desde una ruta en la que el usuario puede escribir.
Microsoft recomienda verificar cualquier solicitud de soporte externo a través de un canal interno conocido, restringir la colaboración externa en Teams a dominios confiables, exigir autenticación multifactor y acceso condicional, y supervisar las herramientas de soporte remoto. También propone habilitar reglas de reducción de la superficie de ataque y protección de red y web, limitar WinRM a estaciones de administración autorizadas y generar alertas cuando se ejecute desde el contexto de un usuario o de un proceso no administrativo.
Las organizaciones que encuentren indicadores relacionados con esta campaña deben tratar el dispositivo afectado como un posible punto de acceso a la red y dar prioridad a la investigación y a la rotación de las credenciales a las que se pudiera haber accedido desde él, incluidas, cuando corresponda, las cuentas de administradores del dominio.