Falso soporte informático en Teams y después certificados del dominio: Microsoft detalla dos intrusiones a través de AD CS

Microsoft ha investigado dos intrusiones que empezaron con falsos técnicos en Teams y continuaron con el abuso de Active Directory Certificate Services. En uno de los casos, los certificados de cuentas privilegiadas acabaron en el robo de datos de un servidor de archivos. No se explotó ninguna vulnerabilidad de Teams: bastaron un empleado convencido y una configuración insegura de AD CS.

Qué ha pasado

En un informe del 30 de octubre de 2026, Microsoft Threat Intelligence describe dos intrusiones en organizaciones cuyo nombre no revela. Ambas empezaron igual: mensajes y llamadas de Teams desde cuentas que se hacían pasar por el servicio de soporte, para convencer a los empleados de abrir una sesión de Asistencia rápida (Quick Assist) o similar. Microsoft indica que no se explotó ninguna vulnerabilidad de Teams y no atribuye la actividad a ningún actor.

Cómo entraron los atacantes

Primer caso (ESC1). Una primera oleada se dirigió a tres usuarios y comprometió un equipo. Una plantilla de certificado mal configurada dio entonces al atacante certificados para tres cuentas con privilegios elevados. Unos 90 minutos después de la interrupción de la primera sesión, una segunda oleada se dirigió a 16 usuarios y le proporcionó certificados para otras ocho cuentas privilegiadas. A los pocos segundos de obtener uno de ellos, el atacante se autenticó en un controlador de dominio e inició un DCSync. Una cuenta privilegiada había quedado excluida de la respuesta automática: con ella llegó a un servidor de archivos, desde donde una copia renombrada de Rclone envió datos a un destino SFTP externo.

Segundo caso (ESC8). PetitPotam obligó a un controlador de dominio a autenticarse ante un sistema controlado por el atacante. Esa autenticación se retransmitió a la inscripción web de AD CS, lo que proporcionó un certificado y luego un ticket Kerberos para la cuenta del controlador. El cliente aisló el equipo tras las alertas y Microsoft no observó más avances.

Qué hacer ahora

1. Controle Teams y la asistencia remota: limite los dominios externos, permita solo las herramientas de soporte aprobadas y confirme toda solicitud de soporte no pedida por un canal interno conocido.
2. Audite las plantillas de certificado: ejecute certutil -v -template y busque CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT en las plantillas que permiten autenticación. Desactive la opción Proporcionar en la solicitud, restrinja los derechos de inscripción o exija la aprobación de un administrador.
3. Proteja la inscripción web: inventaríe los puntos de acceso de Web Enrollment y Certificate Enrollment Web Service y elimine los innecesarios. En los demás, exija HTTPS y ponga la protección ampliada para la autenticación (EPA) en “Requerido”, según el KB5005413, y ejecute iisreset /restart.
4. Active la auditoría de la entidad de certificación para solicitudes y emisiones. Revoque los certificados ilegítimos y revise también los tickets Kerberos: la revocación no invalida los ya emitidos.
5. Revise las exclusiones de contención: toda cuenta fuera de la respuesta automática necesita un responsable y una acción manual.

Nuestra opinión

El phishing explica la entrada, pero la configuración de los certificados explica la rapidez: un solo equipo bastó para alcanzar cuentas de nivel de dominio. AD CS suele instalarse una vez y olvidarse, aunque merece la misma protección que un controlador de dominio.

Fuentes

• Microsoft Security Blog — From help desk impersonation to AD CS abuse: Investigating ESC1 and ESC8 intrusion paths
• Microsoft Support — KB5005413: Mitigating NTLM relay attacks on Active Directory Certificate Services
• Microsoft Learn — Certificates security posture assessment in Defender for Identity
• SpecterOps — Certified Pre-Owned
• The Hacker News — Attackers Pose as IT Support on Microsoft Teams, Abuse AD CS to Steal Company Data

Cómo elegimos, verificamos y redactamos nuestros análisis →