Microsoft investigó dos intrusiones que comenzaron con ingeniería social idéntica pero terminaron de forma distinta según cómo se gestionó la contención automatizada de identidades.
Microsoft Threat Intelligence documentó dos intrusiones en las que actores de amenaza utilizaron mensajes y llamadas de Microsoft Teams para hacerse pasar por personal de soporte técnico, convencieron a usuarios de aprobar sesiones remotas mediante Quick Assist y, una vez dentro, explotaron configuraciones inseguras de Active Directory Certificate Services (AD CS) para obtener certificados de autenticación de cuentas privilegiadas. Aunque ambos casos compartieron el mismo patrón de acceso inicial, divergieron en la técnica de abuso de certificados y, sobre todo, en el resultado de la respuesta: en uno, una identidad excluida de la contención automatizada permitió la exfiltración de datos; en el otro, el aislamiento temprano de la estación de trabajo detuvo la progresión del ataque.
La actividad no explotó ninguna vulnerabilidad en Microsoft Teams. Se basó exclusivamente en ingeniería social y en configuraciones de AD CS excesivamente permisivas o mal protegidas, un patrón que convierte una sesión remota aprobada por el usuario en acceso persistente respaldado por certificados a identidades de dominio y controladores de dominio.
Cómo una llamada de soporte falsa se convierte en acceso remoto interactivo
En ambos incidentes, los atacantes iniciaron contacto mediante mensajes y llamadas de Teams que suplantaban personal de IT o help desk. La ingeniería social persuadió a usuarios de establecer una sesión remota controlada por el atacante, principalmente guiándolos a abrir Quick Assist y proporcionar el código de conexión. Esto otorgó acceso directo al teclado y al sistema del usuario.
A lo largo de la actividad más amplia documentada por Microsoft, los atacantes utilizaron nombres de tenant onmicrosoft.com temáticos de la organización y nombres de visualización orientados a soporte para que el contacto externo pareciera familiar. Una vez establecida la sesión remota, el atacante transfirió archivos comprimidos, extrajo runtimes portables de Python, Bun o Java, y ejecutó scripts de descubrimiento de host y red desde ubicaciones escribibles por el usuario, manteniendo metadatos de archivo legítimos.
Este patrón de ejecución portable permite al atacante operar con herramientas que no requieren instalación ni permisos administrativos, dificultando la detección basada en firmas de malware convencional. El siguiente paso fue evaluar la configuración de AD CS en busca de rutas de autenticación basadas en certificados.
Caso 1: plantilla ESC1 vulnerable y el costo de una exclusión de identidad
En el primer caso, el atacante abusó de una plantilla de certificado vulnerable clasificada como Enterprise CA Security Configuration 1 (ESC1). Esta configuración permite que un solicitante de bajo privilegio proporcione información de identidad arbitraria en la solicitud de certificado y, si la plantilla está configurada con permisos de inscripción amplios, puede obtener un certificado de autenticación para una cuenta privilegiada.
Una vez obtenidos los certificados para cuentas privilegiadas, el atacante utilizó autenticación Kerberos basada en certificados (PKINIT) y realizó DCSync, una técnica que replica datos de Active Directory, incluyendo hashes de contraseñas de todas las cuentas del dominio. Microsoft Defender attack disruption restringió identidades cubiertas y bloqueó actividad posterior sustancial, pero una identidad privilegiada excluida de la contención automatizada permaneció utilizable.
Esa exclusión fue determinante: el atacante utilizó la identidad no contenida para apoyar la exfiltración de datos. El incidente ilustra que la efectividad de la disrupción automatizada depende de que todas las identidades comprometidas permanezcan elegibles para contención. Una sola exclusión puede preservar la ruta del atacante incluso cuando el resto del entorno está bajo control.
Caso 2: PetitPotam y ESC8 convierten una estación de trabajo en identidad de controlador de dominio
En el segundo caso, el atacante utilizó PetitPotam, una técnica que causa que un servidor Windows se autentique en un sistema controlado por el atacante. El atacante retransmitió la autenticación NTLM del controlador de dominio a AD CS Web Enrollment, un endpoint que, si carece de protecciones contra relay, permite solicitar un certificado como la identidad retransmitida. Esta configuración vulnerable se clasifica como ESC8.
Una vez obtenido el certificado para la cuenta del controlador de dominio, el atacante utilizó autenticación Kerberos basada en certificados (PKINIT) para operar con privilegios de dominio. Sin embargo, Microsoft Defender generó alertas relacionadas con ESC8, el cliente aisló la estación de trabajo asociada y no se observó progresión adicional del ataque.
La diferencia clave respecto al Caso 1 fue la eliminación del punto de ejecución activo: aislar la estación de trabajo comprometida cortó la capacidad del atacante de continuar operando, incluso habiendo obtenido un certificado de controlador de dominio. Restablecer la contraseña del usuario o reimaginar la estación de trabajo inicial no revoca un certificado ya emitido ni invalida tickets Kerberos ya generados, pero eliminar el acceso interactivo del atacante sí detiene la cadena de ataque.
Por qué América Latina queda expuesta por configuraciones AD CS heredadas
La dependencia de Active Directory Certificate Services es estructural en organizaciones medianas y grandes de toda América Latina, especialmente en sectores financiero, energético y gubernamental de México, Brasil, Colombia y Argentina. Muchas de estas implementaciones fueron configuradas hace años, cuando las plantillas ESC1 y los endpoints de Web Enrollment sin protección contra relay eran configuraciones por defecto o recomendadas en guías de despliegue que no contemplaban estos vectores de ataque.
Microsoft no reportó datos específicos de incidentes en la región en esta publicación, pero el patrón de abuso de AD CS documentado en estos dos casos es independiente de la geografía: cualquier organización con plantillas de certificado mal configuradas o endpoints de Web Enrollment sin Extended Protection for Authentication (EPA) habilitada queda expuesta al mismo riesgo. En América Latina, donde la rotación de infraestructura de dominio tiende a ser más lenta que en mercados con mayor presupuesto de modernización, la probabilidad de encontrar configuraciones ESC1 o ESC8 vulnerables en producción es alta.
El vector de ingeniería social mediante Teams agrega una capa de riesgo adicional en contextos donde el soporte remoto se normalizó durante la pandemia y muchas organizaciones todavía no implementaron controles estrictos sobre qué aplicaciones de acceso remoto pueden utilizarse ni bajo qué condiciones. La combinación de usuarios entrenados para aprobar sesiones de soporte remoto sin verificación rigurosa y configuraciones de AD CS heredadas crea un escenario de alta exposición que no requiere explotación de vulnerabilidades de software.
Nuestro análisis
Este caso revela un patrón que ya se observó en incidentes previos de abuso de AD CS, pero con una diferencia operativa clave: el uso de ingeniería social mediante plataformas de colaboración corporativa como vector de acceso inicial, en lugar de phishing tradicional con adjuntos o enlaces maliciosos. La técnica es efectiva porque no requiere que el usuario ejecute un archivo sospechoso ni haga clic en un enlace externo: solo necesita que apruebe una sesión de soporte remoto, algo que muchos usuarios están entrenados para hacer sin cuestionamiento cuando el contacto parece provenir de IT interno.
La divergencia en los desenlaces de ambos casos no se explica por diferencias en la sofisticación del atacante ni en la técnica de abuso de certificados, sino por dos decisiones de respuesta: en el Caso 1, una identidad privilegiada excluida de la contención automatizada permitió que el atacante continuara operando incluso después de que Defender bloqueara actividad sustancial; en el Caso 2, el aislamiento de la estación de trabajo comprometida eliminó el punto de ejecución activo del atacante, deteniendo la progresión del ataque a pesar de que el certificado de controlador de dominio ya había sido emitido. Esto subraya que la efectividad de la disrupción automatizada depende tanto de la cobertura completa de identidades como de la eliminación física del acceso interactivo del atacante.
Lo que todavía no se sabe es si estos dos incidentes forman parte de una campaña coordinada de un mismo actor de amenaza o si representan adopción independiente de un patrón de ataque que ya circula en foros de acceso inicial. Microsoft no atribuyó la actividad a un grupo específico. Tampoco está claro cuántas organizaciones en América Latina ya fueron objeto de intentos similares sin que se detectara la fase de abuso de certificados, dado que la ingeniería social por Teams y la ejecución de runtimes portables pueden pasar desapercibidas en entornos sin monitoreo de comportamiento de identidades y sin auditoría de solicitudes de certificados en AD CS. ¿Cuántas intrusiones exitosas basadas en este patrón ya ocurrieron sin generar alertas porque la organización no tenía visibilidad sobre ESC1 o ESC8, y cuántas están en curso ahora mismo con certificados ya emitidos esperando ser utilizados?