El 30 de octubre de 2026, Microsoft publicó una investigación sobre dos intrusiones que empezaron con mensajes y llamadas en Teams de falsos técnicos de soporte. Tras convencer a empleados para que concedieran acceso remoto, los atacantes siguieron dos rutas distintas para abusar de Active Directory Certificate Services (AD CS), la infraestructura que emite certificados de autenticación. Microsoft indicó que no explotaron una vulnerabilidad de Teams: el servicio fue el canal de ingeniería social. La investigación de Microsoft describe resultados distintos según la vía de certificados y la respuesta aplicada.
De un mensaje en Teams al control remoto
Los atacantes se hicieron pasar por personal de soporte y guiaron a los usuarios para que iniciaran una sesión remota, principalmente con Quick Assist. Una vez dentro del equipo, prepararon archivos y ejecutaron código desde directorios modificables por el usuario, con entornos portátiles de Python, Bun o Java. Después buscaron información del equipo y de la red y examinaron AD CS.
La entrada dependió de que los empleados aceptaran el contacto y concedieran acceso. Por eso, las señales de Teams y de la sesión remota adquieren más valor al relacionarlas con lo que ocurrió después en el equipo y en los sistemas de identidad.
Dos rutas distintas para abusar de AD CS
En el primer caso, una plantilla de certificados mal configurada permitió solicitar certificados de autenticación que representaban cuentas privilegiadas. En el segundo, PetitPotam forzó la autenticación NTLM de un controlador de dominio y esa autenticación se retransmitió a AD CS Web Enrollment mediante ESC8.
ESC1: certificados para cuentas privilegiadas
La primera oleada afectó a tres usuarios y un equipo; los atacantes obtuvieron certificados para tres cuentas muy privilegiadas. Unos 90 minutos después, otra oleada apuntó a 16 usuarios y a otro equipo, y consiguió certificados para ocho cuentas privilegiadas más.
La contención de Microsoft Defender bloqueó más de 1.000 intentos posteriores de acceso a archivos por SMB e inicios de sesión. Sin embargo, una cuenta privilegiada excluida de la contención automática siguió siendo utilizable. El atacante la empleó después para acceder a un servidor de archivos y transferir datos a un destino SFTP externo.
Además, la operación DCSync, que replica información del directorio, empezó segundos después de obtener un certificado privilegiado. La contención limitó la actividad de replicación posterior, pero la cuenta excluida mantuvo una vía de acceso.
PetitPotam y ESC8: relay NTLM y certificado de máquina
En el segundo caso, PetitPotam provocó que un controlador de dominio se autenticara mediante NTLM ante un sistema controlado por el atacante. Este retransmitió la autenticación a AD CS Web Enrollment con ESC8 y obtuvo un certificado para la cuenta del controlador de dominio. Después lo usó para autenticarse en Kerberos mediante PKINIT y solicitar un TGT, o ticket de concesión de tickets.
Microsoft Defender generó alertas relacionadas con ESC8 y el cliente aisló el equipo asociado. Tras ese aislamiento, Microsoft no observó más progresión del ataque.
Qué señales pueden orientar una investigación
Microsoft describe cuatro tipos de consultas de búsqueda avanzada para investigar esta cadena:
- Contactos externos sospechosos e indicios de suplantación en Teams.
- Ejecución de Bun o Java desde rutas de preparación con el prefijo
KB. - Actividad de red iniciada por esos entornos de ejecución desde dichas rutas. Las consultas de Microsoft incluyen los puertos 80, 445, 636 y 88.
- Alertas relacionadas con relay NTLM, Certificate Services, PKINIT o solicitudes de tickets Kerberos.
El nombre de un archivo o una coincidencia aislada no demuestra una intrusión. Microsoft recomienda ajustar las consultas al entorno y relacionar sus resultados con otras señales: el contacto y la sesión remota en Teams, la actividad y la secuencia de procesos del equipo, las solicitudes y emisiones de certificados, las alertas de identidad y la actividad Kerberos.
Qué revisar en la respuesta y en AD CS
Microsoft recomienda verificar las solicitudes de soporte inesperadas mediante canales internos conocidos, revisar qué contactos externos de Teams necesita la organización y limitar las herramientas de asistencia remota a flujos aprobados. En AD CS, las comprobaciones pertinentes incluyen las plantillas que permiten aportar datos de identidad, los permisos de inscripción demasiado amplios y los controles de emisión débiles. También propone retirar los servicios Web Enrollment innecesarios, exigir HTTPS y Extended Protection for Authentication (EPA), y desactivar NTLM en los servicios de inscripción cuando sea viable. La guía de Microsoft para mitigar ataques de relay NTLM contra AD CS detalla estas protecciones.
Si se emite un certificado no autorizado, revocarlo es una acción distinta de cambiar una contraseña o reinstalar el equipo inicial: ninguna de esas dos medidas revoca por sí sola el certificado. También hay que revisar por separado los tickets Kerberos ya emitidos. Y si una cuenta o un dispositivo queda excluido de la contención automática, Microsoft recomienda asignar una respuesta manual compensatoria y comprobar que se complete.
