Campaña de suplantación soporte TI en Teams para obtener acceso privilegiado


Operadores maliciosos se hicieron pasar por personal de soporte TI a través de mensajes y llamadas en Microsoft Teams para convencer a empleados de iniciar sesiones de asistencia remota (Quick Assist) y compartir códigos de conexión. Aprovechando configuraciones inseguras de Active Directory Certificate Services (AD CS), lograron convertir esas sesiones aparentemente aprobadas en rutas de autenticación privilegiada: obtuvieron certificados que representaban a cuentas de alto privilegio o incluso a controladores de dominio.

Las intrusiones publicadas por Microsoft combinaron ingeniería social con debilidades en la configuración de AD CS, no una falla técnica en Teams. Los atacantes usaron información de la victima y que daba confianza, transfirieron archivos a carpetas de descarga, y ejecutaron componentes portables (por ejemplo, intérpretes de Python, Bun o Java) desde directorios creados con prefijo KB. Estas herramientas realizaron descubrimiento del host, evaluaron servicios de certificados y se conectaron a la infraestructura de dominio mediante LDAPS y SMB.

En un caso identificaron una plantilla de certificado vulnerable por permisos de inscripción amplios y falta de controles de emisión (clasificada como ESC1), lo que permitió a una cuenta con pocos privilegios solicitar certificados para identidades privilegiadas. La primera ola afectó a tres usuarios y comprometió un equipo; consiguieron certificados para tres cuentas altamente privilegiadas. Aproximadamente 90 minutos después hubo una segunda oleada que comprometió otra estación y obtuvo más certificados. Microsoft Defender bloqueó más de 1,000 intentos de acceso a archivos SMB y otros intentos de inicio de sesión, pero en cuanto obtuvieron un certificado privilegiado los atacantes ejecutaron DCSync en segundos, extrayendo información de cuentas.

En otra intrusión usaron PetitPotam (coerción sobre EFSRPC) para forzar la autenticación de un controlador de dominio y retransmitir esa autenticación NTLM hacia puntos de inscripción web de AD CS con protección inadecuada (ESC8). Con un certificado de controlador de dominio pudieron autenticarse via Kerberos PKINIT y obtener un ticket de concesión de tickets para ese equipo. En uno de los incidentes el equipo fue aislado y no hubo progresión adicional.

Recomendaciones

- Restringir el acceso externo a Teams y deshabilitar contactos ajenos donde no sean necesarios.
- Verificar siempre solicitudes de soporte no solicitadas (confirmar por canales oficiales) antes de iniciar asistencia remota.
- Controlar y prohibir la ejecución de runtimes portables desde perfiles de usuario.
- Revisar y endurecer permisos de inscripción de certificados: limitar quién puede solicitar certificados y exigir verificación de identidad.
- Asegurar endpoints de inscripción con HTTPS y habilitar Extended Protection for Authentication.
- Reducir o deshabilitar NTLM en la medida de lo posible y mitigar coerción de autenticación (por ejemplo, mitigaciones a PetitPotam).
- En respuesta, revocar certificados no autorizados y realizar investigación separada de tickets Kerberos, ya que restablecer contraseñas no invalida certificados emitidos y revocar certificados no invalida tickets existentes.
- Monitorear intentos de acceso SMB y actividad inusual tras eventos de soporte remoto; aislar estaciones comprometidas rápidamente.

Referencias

https://www.microsoft.com/en-us/security/blog/2026/10/30/help-desk-impersonation-ad-cs-abuse-investigating-esc1-esc8-intrusion-paths/

El nombre es requerido.
El email es requerido.
El email no es válido.
El comentario es requerido.
El captcha es requerido.



Comentarios