De Teams al controlador de dominio: hasta dónde llega el falso soporte técnico

Microsoft Threat Intelligence publicó ayer, a las 19:51 de la Argentina, el análisis de una campaña que va de Teams al controlador de dominio sin explotar una vulnerabilidad de Teams. Empieza con un chat de Microsoft Teams que entra desde un tenant externo haciéndose pasar por el helpdesk de tu propia empresa, sigue con una sesión de asistencia remota que la víctima concede a mano, y termina con un operador humano pivotando por WinRM hacia los controladores de dominio y las autoridades certificadoras de la organización.

Lo primero, porque es lo que más se malinterpreta y lo que el informe aclara antes que nada: acá no hay una falla de Teams que parchear. Se abusan funciones legítimas de colaboración externa, y el paso decisivo lo da una persona que decide saltear las advertencias que Teams le muestra en pantalla.

Esta actividad no proviene de una debilidad en Microsoft Teams ni en sus protecciones integradas; en cambio, el atacante abusa de funciones legítimas de colaboración persuadiendo al usuario de que saltee advertencias de seguridad presentadas con claridad, lo que subraya el desafío más amplio de defenderse de la ingeniería social antes que de una explotación técnica.Microsoft Threat Intelligence — traducción del informe original

Lo que vas a encontrar acá

• De Teams al controlador de dominio: las nueve etapas del informe
• El runtime de Node.js lo bajan del sitio oficial, y ese es el truco
• El contrato de Ethereum que guarda la dirección del servidor de control
• Tercer informe sobre el mismo molde, y esta vez cambia el blanco
• Dónde se corta la cadena, según el propio Microsoft
• ¿Y esto qué significa para vos?
• Preguntas frecuentes sobre la suplantación de soporte por Teams

De Teams al controlador de dominio: las nueve etapas del informe

El documento describe una intrusión operada por humanos y la reparte en nueve etapas numeradas. La etapa 1 es la única que necesita a la víctima, y le pide tres cosas: que ignore la marca de contacto externo, que abra una sesión de administración remota y que acepte la elevación. De la 2 en adelante ya hay alguien del otro lado tecleando.

Arranca con un chat o una llamada de Teams desde un tenant distinto del tuyo, con la identidad del área de sistemas. Teams marca ese contacto —etiqueta de organización externa, aviso de aceptar o bloquear, indicadores de phishing— y la campaña depende de convencer al usuario de pasar por encima de todo eso. Los ganchos son de manual: «Microsoft Security Update», «Spam Filter Update», «Account Verification» o cuentas que supuestamente están por desactivarse. A veces suman una llamada de voz —vishing— para que las instrucciones nunca queden escritas.

El pedido tiene dos variantes y las dos las ejecuta la víctima: aprobar el «solicitar control» de una pantalla compartida, o abrir Quick Assist y dictar el código. Con eso el operador ya está sentado en el escritorio.

El runtime de Node.js lo bajan del sitio oficial, y ese es el truco

Una vez adentro, el operador usa PowerShell —dentro de la sesión remota que la víctima abrió— para bajar el MSI de almacenamiento en la nube que controla el propio atacante, de modo que la descarga se mezcle con el tráfico legítimo y aproveche la reputación de un dominio confiable. El modificador /qn suprime toda la interfaz del instalador: quien está mirando la pantalla no ve absolutamente nada.

Y conviene decir cuál es ese dominio confiable, porque callarlo sería acomodar el relato: los cinco puntos de entrega que Microsoft publica como indicadores terminan en blob.core.windows.net, o sea Azure Blob Storage, y dos de los tres servidores de control están en cloudapp.azure.com. La reputación de la que se abusa es la de la propia Microsoft: no es un fallo de Azure más de lo que era un fallo de Teams, es alquilar un depósito con nombre respetable.

Ese MSI hace dos cosas. Instala un cargador y un implante cifrado en el LocalAppData del usuario —el implante viene adentro del MSI, no se descarga aparte— y, si el equipo no lo tiene, baja el runtime portable de Node.js de la distribución oficial. Traducido: el atacante consigue un entorno completo de JavaScript sin desplegar un binario propio que llame la atención. Node.js está firmado y no tiene nada de malo; lo malicioso es el script que le dan de comer.

El resto se esconde en los detalles. El MSI programa una acción diferida que lanza código oculto por PowerShell, cmd.exe o WScript, y los cargadores y el archivo cifrado usan extensiones que nadie asocia con código: .tmp, .ini, .dat, .bin, .cfg. Con un runtime firmado, dice el informe, la operación esquiva los controles que solo miran ejecutables sin firma y extensiones de script convencionales.

Después llegan las capacidades del operador: reconocimiento del equipo y de los antivirus instalados —consultar el adaptador de video y el antivirus es, dice el informe, característico de los chequeos de entorno de análisis—, capturas periódicas de la pantalla y cargas adicionales ejecutadas con rundll32.exe sobre DLL propias.

El contrato de Ethereum que guarda la dirección del servidor de control

Hay un detalle que no aparece en las otras campañas del molde: los implantes traen una función para consultar un contrato inteligente de Ethereum y sacar de ahí una dirección actualizada del servidor de control. En las muestras recuperadas esa consulta estaba deshabilitada y el implante caía a un servidor fijo. El contrato, aclara el informe, guarda solo una cadena de texto: no contiene ni ejecuta el malware.

Pero deshabilitada no es lo mismo que vacía: el contrato está poblado y en mantenimiento. Microsoft publica en sus indicadores la dirección vigente que guarda —el mismo servidor que hace de respaldo fijo— y dos anteriores, una «almacenada brevemente». La infraestructura ya está montada y se actualizó al menos dos veces; lo apagado es la consulta en las versiones recuperadas. Por qué importa: un servidor de control se da de baja, y una cadena de bloques pública no.

Tercer informe sobre el mismo molde, y esta vez cambia el blanco

Es la tercera vez que cubrimos una campaña que entra por un chat de Teams disfrazado de soporte técnico, y conviene decirlo de entrada: no son la misma campaña ni necesariamente el mismo grupo, sino tres investigaciones de tres firmas sobre un molde que funciona. Lo que cambia es hasta dónde llega.

Y conviene sacar del medio la tentación fácil, que sería decir que las otras dos se quedaban en el equipo de entrada. No es cierto: a TWINLOOT, Ontinue le documentó un túnel SOCKS5 inverso con acceso interactivo y conexiones internas por puertos administrativos —el 5985 entre ellos—, y la de Sophos terminó con ransomware desplegado.

Lo que este informe agrega es el blanco, con nombre propio, y la escala. La etapa 9 no describe una capacidad del implante: describe tareas que el operador ejecutó contra decenas de sistemas unidos al dominio, y nombra dos que no aparecen en ninguna de nuestras dos notas anteriores — controladores de dominio y autoridades certificadoras. Microsoft subraya que apuntar a la infraestructura de identidad es la marca de las intrusiones que anteceden a un robo masivo de datos o a un ransomware. La diferencia no es que el operador salga del equipo: es que esta vez el camino de Teams al controlador de dominio está documentado punta a punta.

Dónde se corta la cadena, según el propio Microsoft

Cortar el camino de Teams al controlador de dominio no pide comprar nada nuevo en la mayoría de los tramos. El informe lista once recomendaciones. Las agrupamos así, sin esconder las que piden producto pago — omitirlas en una nota que abajo recomienda antivirus sería hacer trampa:

Lo que depende de las personas:

• Una frase de autenticación del helpdesk. Microsoft lo pone primero: frases internas acordadas, y entrenar a la gente para reconocer el indicador de organización externa y para no conceder nunca acceso remoto ni ejecutar comandos que llegan de un contacto no solicitado.
• Verificar por un canal interno conocido antes de aceptar nada.

Lo que es configuración de lo que ya tenés:

• Restringir el acceso externo de Teams a dominios de confianza, revisar las políticas de colaboración externa y las mejores prácticas de seguridad para Teams, y pedir verificación de dispositivo o identidad antes de conceder una sesión de soporte.
• Exigir MFA y acceso condicional. El doble factor limita el valor de las credenciales que se llevan de una sesión remota, y para quien ya paga Microsoft 365 no es un producto nuevo.
• Reglas de reducción de superficie de ataque: bloquear la creación de procesos desde PowerShell, WScript y cmd, y la ejecución de contenido descargado, corta el andamiaje del MSI.
• Limitar WinRM al puerto TCP 5985 desde estaciones de administración autorizadas, y alertar cuando sale de un proceso de usuario.
• Controlar qué herramientas de asistencia remota están permitidas y monitorear el resto.
• Activar la protección entregada desde la nube del antivirus de Windows, que es gratis y viene puesta.

Lo que pide producto, y es todo de Microsoft: Defender para Office 365 con Safe Links y purga de mensajes ya entregados, y la protección de red y web de Defender for Endpoint.

Y una de respuesta: si aparecen indicadores, hay que asumir que hubo acceso a nivel de red desde el equipo comprometido y rotar toda credencial accesible desde esa máquina, incluidas las de administrador de dominio.

¿Y esto qué significa para vos?

Tres cosas, y ninguna empieza con «instalá algo». La ruta de Teams al controlador de dominio no se cierra con una descarga: se cierra con una costumbre.

1. La etapa 1 se corta con una decisión, no con un parche. No hay actualización que instalar porque no hay agujero que tapar: todo cuelga de que alguien apruebe un control remoto pedido por un desconocido. La contramedida más barata cabe en una frase: el soporte de sistemas de tu empresa no te va a escribir por Teams desde afuera para pedirte que abras Quick Assist. El helpdesk que te escribe con urgencia un martes a las siete de la tarde desde otro tenant no es tu helpdesk; es alguien que aprendió a escribir como uno.

2. Para una PyME, la palabra clave es «externo». El punto de entrada no es una vulnerabilidad sino una política de colaboración que suele venir abierta de fábrica. Restringir el chat externo a los dominios con los que trabajás de verdad no cuesta una licencia y se hace desde el centro de administración. Es la misma lección que ya dejó la campaña STAC4749 que Sophos publicó en julio, y por eso incomoda que siga funcionando en septiembre.

3. El antivirus entra recién en la etapa 2, y ahí sí tiene algo que decir. Ninguna suite va a impedir que alguien conceda una sesión remota: eso es una decisión, no un archivo. Pero de la etapa 2 en adelante hay un MSI que se instala sin ventanas y un implante hablando con un servidor de control — Microsoft publica hasta los nombres con los que su antivirus detecta esas piezas. Si en la oficina hay cinco máquinas y cada una se defiende sola, una licencia que las cubra a todas es el piso, no el techo.

Preguntas frecuentes sobre la suplantación de soporte por Teams

¿Microsoft Teams tiene una vulnerabilidad que haya que parchear?

No. El informe lo dice explícitamente: la actividad no proviene de una debilidad de Teams ni de sus protecciones integradas. El atacante abusa de funciones legítimas de colaboración externa y necesita que el usuario ignore advertencias que Teams sí le muestra. No hay actualización que instalar contra esto.

¿Qué es Quick Assist y por qué aparece en el ataque?

Es la herramienta de asistencia remota que viene con Windows: uno genera un código y el otro lo ingresa para cederle el control. El informe no le atribuye ninguna falla ni la señala como comprometida: el atacante convence a la víctima de abrirla y dictarle el código, que es exactamente para lo que sirve.

¿Cómo sé si esto me pasó?

Los indicios que enumera Microsoft son un proceso de asistencia remota seguido de inmediato por cmd.exe o PowerShell en el mismo escritorio, Node.js ejecutándose desde LocalAppData y una entrada de inicio llamada EdgeUpdate. Si aparecen, hay que rotar credenciales asumiendo que hubo acceso a la red.

¿Un antivirus frena esta campaña?

Parcialmente, y conviene decirlo así. No puede impedir que alguien conceda voluntariamente una sesión remota, que es la etapa 1. Sí tiene chance en las etapas siguientes: el MSI, el cargador, el implante JavaScript y el tráfico con el servidor de control son artefactos que un producto de endpoint puede detectar y bloquear.

🛒 Te puede servir

ESET Internet Security — 12 Meses — 5 DispositivosCinco equipos cubiertos, con firewall e inspector de red para ver qué se conectó.Ver precio de hoy → Avast Essential Business Security — 12 Meses — 5 DispositivosLas cinco máquinas se administran desde una sola consola, el Avast Business Hub.Ver precio de hoy →

¿Y vos qué opinás? Dejalo en los comentarios ⬇️
Cubrí las cinco máquinas de la oficina, no solo la tuya →