Están suplantando la identidad del personal de soporte técnico en Microsoft Teams para engañar a los empleados y obtener acceso remoto a sus ordenadores Windows. Mediante el uso de identidades convincentes, inundaciones de correos electrónicos y herramientas de soporte legítimas, los atacantes logran instalar malware y explorar redes corporativas explotando la confianza del usuario.

Esta actividad combina identidades de centros de ayuda convincentes, inundaciones de correos electrónicos no deseados y herramientas de soporte remoto legítimas, convirtiendo una conversación laboral aparentemente rutinaria en una oportunidad para instalar malware e investigar redes corporativas.

Los ataques explotan la confianza en lugar de una vulnerabilidad de Microsoft Teams. La mensajería externa permite que los atacantes se acerquen a los empleados desde entornos de Microsoft 365 independientes cuando ambas organizaciones permiten la comunicación.

Llamadas falsas de soporte técnico informadas previamente muestran cómo la inundación de la bandeja de entrada crea confusión antes de que llegue un impostor ofreciendo solucionar el problema.

Investigadores de Arctic Wolf identificaron una cadena de infección de malware potencialmente nueva mientras investigaban esta actividad.

Su informe de investigación del 26 de octubre analizó más de 400 incidentes que involucraban el abuso del chat externo de Teams, documentando patrones de suplantación repetidos, el mal uso de software de acceso remoto e infraestructura compartida entre múltiples intrusiones.

Suplantan al soporte técnico en Microsoft Teams

Los atacantes suelen crear o adquirir inquilinos (tenants) de Microsoft 365 y configuran identidades que se asemejan a cuentas de soporte corporativo.

Entre el 30% y el 40% de los casos examinados involucraban dominios predeterminados de inquilinos de Microsoft. Otros utilizaron dominios de pago, donde la extensión .top representó aproximadamente la mitad de las identidades de dominios de pago observadas durante los últimos meses.

Los nombres mostrados refuerzan el engaño. Los atacantes añaden nombres de pila amigables, cargos de soporte, nombres de empresas o una etiqueta de “Interno” para hacer que una cuenta externa parezca confiable.

Estas etiquetas no cambian el estado real de la cuenta, pero animan a los empleados a ignorar la advertencia de usuario externo de la plataforma y a aceptar una solicitud de soporte inesperada.

En muchos incidentes, el contacto ocurre después de que llegan cientos de suscripciones a boletines o correos de confirmación en cuestión de minutos. El atacante entonces ofrece ayuda a través del chat o una llamada de voz de Teams.

Este problema fabricado le da al impostor una razón creíble para solicitar que compartas pantalla, el control remoto o la instalación de software.

Quick Assist fue la herramienta de soporte remoto observada con más frecuencia, junto con AnyDesk, ScreenConnect, TeamViewer, Atera y otras. Ataques anteriores de puertas traseras mediante vishing en Teams utilizaron de manera similar sesiones remotas aprobadas para entregar malware.

Estas aplicaciones legítimas no son maliciosas por naturaleza; el peligro proviene de conceder acceso a una persona no verificada. La transición puede ser rápida.

Los clientes informaron la ejecución de la carga útil (payload) en menos de 15 minutos desde el inicio de la interacción, mientras que los atacantes a menudo contactaban a varios empleados en aproximadamente cinco minutos.

Tras ganar el control, los operadores a veces instalaban otra aplicación de gestión remota, creando un canal de acceso independiente que podría permanecer disponible después de que el malware inicial fuera eliminado.

Entrega de Malware, Detección y Medidas Defensivas

En la cadena de infección recientemente descrita, el impostor instruyó a un empleado para que ejecutara PowerShell e iniciara un instalador descargado.

El comando recuperó un paquete MSI desde Azure Blob Storage que contenía un script y un archivo comprimido. Ambas acciones iniciales se ejecutaron bajo la cuenta de la víctima, quedando registrado Windows Explorer como su proceso padre.

Unos 30 segundos después de la instalación, se ejecutó un script adjunto desde el directorio de datos de aplicaciones locales del usuario. Este decodificó contenido hexadecimal y desencriptó otra etapa de PowerShell utilizando una clave AES y un vector de inicialización integrados.

Una comparación de hash verificó el contenido desencriptado antes de su ejecución a través de un ScriptBlock de PowerShell. La siguiente etapa extrajo un intérprete de Python y un implante, y luego lanzó el implante tras un retraso de cinco segundos.

Inició otra transacción MSI y consultó el Active Directory en busca de objetos de ordenador y usuario. Los nombres y descripciones de cuentas recopilados se enviaron a endpoints de comando y control seleccionados aleatoriamente de destinos integrados en el código.

Arctic Wolf identifica el evento inicial ChatCreated como una oportunidad de detección temprana. Sin embargo, tú como defensor deberías correlacionarlo con la inundación de correos electrónicos, el lanzamiento de herramientas remotas, la actividad de PowerShell y las alertas de identidad.

La guía de investigación de ataques de Teams relacionada resalta las limitaciones de visibilidad de los registros de auditoría, lo que hace que la evidencia del endpoint sea importante al reconstruir cómo la interacción de un empleado se convirtió en un compromiso.

Las organizaciones deberían seguir la guía de acceso externo de Microsoft y permitir solo dominios de socios confiables donde sea práctico.

Restringe las aplicaciones de soporte remoto innecesarias, investiga las instalaciones inesperadas y exige a los empleados que verifiquen cualquier asistencia no solicitada a través de un número de centro de ayuda conocido o un portal de servicios. Una interfaz de chat familiar no es prueba de que el remitente pertenezca al departamento de IT interno.