PhantomRPC: una nueva técnica de escalada de privilegios en el RPC de Windows

Introducción

La comunicación entre procesos (IPC) es una de las tecnologías más complejas del sistema operativo Windows. En el centro de este ecosistema está el mecanismo de llamada a procedimiento remoto (RPC), que puede funcionar como un canal de comunicación independiente o actuar como la capa de transporte básica para tecnologías más avanzadas de comunicación entre procesos. Debido a su complejidad y amplia adopción, el RPC siempre ha sido fuente de numerosos problemas de seguridad. A lo largo de los años, los investigadores han identificado diversas vulnerabilidades en servicios que utilizan RPC, desde la escalada de privilegios local hasta la ejecución remota de código completa.

En esta investigación, presentaré los detalles de una nueva vulnerabilidad en la arquitectura RPC que permite aplicar una técnica de escalada de privilegios local hasta ahora desconocida, que parece funcionar en todas las versiones de Windows. Esta técnica permite que procesos con privilegios de suplantación escalen sus privilegios hasta el nivel SYSTEM. Tiene diferencias fundamentales con los métodos utilizados en la conocida familia de exploits Potato. Aunque Microsoft tiene conocimiento de la vulnerabilidad, no había un parche disponible al momento de esta publicación.

Mostraré cinco vectores de explotación que permiten escalar privilegios desde diversos servicios locales o de red hasta el nivel SYSTEM o usuarios con privilegios elevados. Algunas técnicas se basan en la coerción, otras requieren acciones del usuario y otras involucran servicios en segundo plano. Como la causa del problema es una falla en la propia arquitectura, el número de vectores de ataque potenciales es casi ilimitado: cualquier nuevo proceso o servicio que dependa de RPC puede convertirse en una vía adicional de escalada de privilegios. Por ello, también describiré la metodología utilizada para identificar posibles puntos vulnerables.

Por último, presentaré posibles estrategias de detección, además de medidas de protección que ayuden a reducir los riesgos y mitigar el impacto de este tipo de ataque.

Tecnología MSRPC

La llamada a procedimiento remoto de Microsoft (MSRPC) es una tecnología utilizada en Windows para posibilitar la comunicación entre dos procesos. Permite que un proceso llame funciones del código de otro proceso, incluso si existen en contextos de ejecución diferentes.

Para entender mejor el mecanismo, veamos el siguiente diagrama.

Supongamos que existe un host A con dos procesos en ejecución: A y B. El proceso B necesita una función que existe dentro del proceso A. Para este tipo de comunicación, Windows cuenta con la arquitectura de llamada a procedimiento remoto (RPC), basada en el modelo cliente-servidor. En este modelo, el proceso A actúa como servidor RPC, proporcionando acceso a parte de sus funciones a través de la interfaz A. Cada interfaz RPC se identifica de forma única mediante un identificador universal único (UUID) de 128 bits. Es a través de estos identificadores que el sistema operativo distingue las interfaces entre sí.

La interfaz define qué funciones puede llamar de forma remota el cliente RPC, papel que desempeña el proceso B. En este ejemplo, la interfaz ofrece dos funciones: Fun1 y Fun2.

Para que el cliente RPC intercambie datos con el servidor, debe establecer una conexión a través de un endpoint, que funciona como punto de acceso y garantiza la comunicación de transporte entre cliente y servidor. Como el RPC admite varios mecanismos de transporte, los tipos de endpoint pueden variar según la capa de transporte utilizada.

Ejemplos:

• Para TCP, el endpoint es el puerto TCP.
• Para SMB, la comunicación ocurre a través de una canalización con nombre.
• Para ALPC, el endpoint es el puerto ALPC.

Cada mecanismo de transporte está asociado a una secuencia de protocolos RPC correspondiente. Ejemplos:

• ncacn_ip_tcp se usa para RPC sobre TCP;
• ncacn_np se usa para RPC sobre canalizaciones con nombre;
• ncalrpc se usa para RPC sobre ALPC.

En esta investigación, me enfocaré en ALPC como mecanismo de transporte del RPC. ALPC (Advanced Local Procedure Call) es un mecanismo de comunicación entre procesos de Windows que existía antes que MSRPC. En los sistemas modernos, ALPC puede usarse como una capa de transporte eficiente para el RPC en la comunicación entre procesos en una misma máquina.

Para simplificar, el canal de comunicación basado en un puerto ALPC puede considerarse un archivo en el que los procesos envían (escriben) mensajes y del que los reciben (leen).

Para llamar a una función remota (por ejemplo, Fun1), el cliente arma una solicitud RPC. Esta debe contener información esencial, como el UUID de la interfaz, la secuencia de protocolo, el endpoint y el identificador de la función llamada. En RPC, las funciones no se llaman por nombre, sino por un identificador numérico: el número de operación (OPNUM). La solicitud también puede incluir estructuras adicionales, como datos relacionados con la seguridad, según los requisitos de la llamada.

El mecanismo de suplantación en Windows

En Windows, el mecanismo de suplantación permite que un servicio ejecute de forma temporal operaciones en el contexto de seguridad de otro usuario. Por ejemplo, un servicio puede necesitar acceder a un archivo que pertenece a un usuario durante la ejecución de determinada operación. Al actuar en nombre del usuario que realizó la llamada, el servicio recibe del sistema los derechos de acceso necesarios a ese archivo, aunque no los posea por sí mismo. Para saber más sobre la suplantación, consulte el libro Windows Security Internals de James Forshaw.

Esta investigación aborda solo la suplantación en RPC. En este contexto, los participantes del proceso no son un servicio y un usuario, sino un cliente y un servidor. El servidor RPC puede actuar de forma temporal en nombre del cliente que inició la solicitud.

Para realizar esta operación, el servidor RPC puede llamar a la función de API RpcImpersonateClient, que hace que el hilo del servidor se ejecute en el contexto de seguridad del cliente.

En algunos casos, es necesario limitar la capacidad del servidor de actuar en nombre del cliente. Para ello, Windows introdujo el concepto de nivel de suplantación, que define el alcance de los permisos otorgados al servidor para actuar en nombre del cliente.

Estos parámetros forman parte de la configuración SQOS (Security Quality of Service) y se definen mediante la estructura SECURITY_QUALITY_OF_SERVICE.

Como puede verse, esta estructura contiene el campo de nivel de suplantación (SECURITY_IMPERSONATION_LEVEL), que determina el alcance de los permisos del servidor cuando actúa en nombre del cliente. Los niveles de suplantación van desde Anonymous (Anónimo), en el que el servidor no puede actuar en nombre del cliente, hasta Impersonation (Suplantación) y Delegation (Delegación), que permiten que el servidor actúe en su totalidad en nombre del cliente.

Sin embargo, no todos los procesos de servidor pueden actuar en nombre del cliente. Si cualquier aplicación pudiera usar la suplantación con libertad, esto generaría riesgos graves de seguridad. Para evitarlo, Windows exige el privilegio especial SeImpersonatePrivilege. Solo los procesos que poseen este privilegio pueden actuar en nombre del cliente.

Por defecto, SeImpersonatePrivilege se otorga a determinadas cuentas de servicio, como Local Service y Network Service.

Interacción entre los servicios Group Policy y TermService

El servicio Group Policy Client (gpsvc) es el principal servicio de Windows encargado de aplicar e imponer la configuración de directivas de grupo en el sistema. El servicio se ejecuta con la cuenta SYSTEM dentro del proceso svchost.exe.

Para actualizar las directivas de grupo, Windows utiliza la utilidad gpupdate.exe. Puede ejecutarse con el parámetro /force para forzar la actualización de toda la configuración de directivas de grupo. Durante su ejecución, este ejecutable se comunica con el servicio Group Policy, que coordina el proceso de actualización.

En una de las etapas de la actualización, el servicio Group Policy establece comunicación con el servicio TermService a través de RPC.

TermService proporciona la funcionalidad de escritorio remoto. Por defecto, este servicio no está en ejecución: el administrador puede iniciarlo de forma manual, habilitando el acceso por RDP. Al activarse, implementa un servidor RPC con un conjunto de interfaces y endpoints. TermService se ejecuta con la cuenta NT AUTHORITY\Network Service.

Al ejecutar el comando gpupdate /force, el servicio Group Policy inicia una llamada RPC a TermService con los siguientes parámetros:

• UUID: bde95fdf-eee0-45de-9e12-e5a61cd0d4fe
• Endpoint: ncalrpc:[TermSrvApi]
• Función: void Proc8(int)

Como TermService está desactivado por defecto, la llamada RPC falla y se produce una excepción dentro de la biblioteca en tiempo de ejecución de RPC (rpcrt4.dll). Se devuelve el siguiente error:

• 0x800706BA (RPC_S_SERVER_UNAVAILABLE, 1722)

El error indica que el cliente RPC no pudo establecer conexión con el servidor de destino.

Un análisis más profundo de la cadena de llamadas que derivan en este error muestra que la causa raíz está relacionada con la función NtAlpcConnectPort, utilizada por RPC para establecer la conexión ALPC entre procesos.

La función NtAlpcConnectPort es responsable de conectarse a un puerto ALPC especificado y devuelve un identificador que el cliente usa para la comunicación posterior. Recibe varios parámetros.

Los dos primeros son:

• un puntero al identificador de puerto devuelto;
• el nombre del puerto ALPC como una cadena ASCII.

Otro argumento importante es PortAttributes, una estructura de tipo ALPC_PORT_ATTRIBUTES. Esta contiene la estructura SECURITY_QUALITY_OF_SERVICE que, como ya se mencionó, define el nivel de suplantación utilizado en la conexión.

El último parámetro de interés es RequiredServerSid, que define la identidad esperada del proceso servidor de destino. Esta identidad se determina mediante el identificador de seguridad (SID).

Al analizar esta llamada, se puede ver que el servicio Group Policy intenta conectarse al servidor RPC usando el nivel de suplantación Impersonation y espera que el servidor remoto se ejecute con la cuenta Network Service. Esto no es inusual, ya que TermService suele funcionar con la cuenta Network Service.

Reuniendo toda la información que conozco hasta ahora, puedo reconstruir el esquema de interacción entre TermService y gpsvc.

Hasta este punto, el sistema funciona según lo previsto. El cliente RPC intenta conectarse a un servidor RPC no disponible, lo que genera una excepción gestionada por el entorno de ejecución de RPC.

Pero surge una pregunta: ¿qué sucede si un atacante compromete un servicio que se ejecuta con la cuenta Network Service e intenta simular el mismo servidor RPC que usa TermService?

¿Puede el atacante implementar un servidor RPC falso con el mismo endpoint?

Si esto es posible, ¿el entorno de ejecución de RPC permitirá que el cliente se conecte a ese servidor ilegítimo?

Y ¿Qué acciones podrá realizar el atacante si la conexión se establece con éxito?

Forzando al servicio Group Policy a conectarse al servidor RPC falso

Para entender mejor las consecuencias de este comportamiento del sistema, veamos un posible escenario de ataque.

Supongamos que un atacante ha comprometido un servicio que se ejecuta en el sistema con la cuenta Network Service, por ejemplo, un servidor IIS. Con este nivel de acceso, el atacante puede implementar un servidor RPC malicioso.

Este servidor debe imitar la interfaz RPC del servicio de escritorio remoto (TermService). En concreto, debe usar el mismo UUID de interfaz RPC y el mismo nombre de endpoint: TermSrvApi. Una vez implementado, el servidor malicioso comienza a escuchar las solicitudes RPC que, en condiciones normales, se dirigirían al servicio RDP legítimo.

A continuación, el atacante inicia una actualización de directivas mediante el comando gpupdate.exe /force, forzando al servicio Group Policy a cumplir la condición necesaria. Como resultado, el servicio Group Policy Client (gpsvc), en ejecución con la cuenta SYSTEM, realiza la llamada RPC descrita antes. Cabe recordar que esta llamada RPC se realiza con un nivel de suplantación alto: Impersonation.

Cuando el servidor RPC falso del atacante recibe la solicitud, llama a la función de API RpcImpersonateClient, que permite que el hilo del servidor use el contexto de seguridad del cliente que realizó la llamada, en este caso, SYSTEM.

Al final, el atacante eleva los privilegios del nivel Network Service a SYSTEM. Nuestro exploit de prueba de concepto demuestra esta escalada de privilegios abriendo un símbolo del sistema con derechos de SYSTEM.

Cuando este escenario de ataque se consideró al inicio, tenía un carácter teórico. Pero el experimento con el servidor RPC malicioso confirmó que Windows permite implementar y ejecutar este tipo de servidor, y que el entorno de ejecución de RPC permite que el cliente se conecte a un endpoint falso. Esta técnica permite escalar privilegios del nivel Network Service a SYSTEM. Aun así, para que el ataque funcione, es necesario que al menos una directiva de grupo esté aplicada en el sistema.

Esquema de la arquitectura RPC

Un análisis más profundo mostró que muchos servicios de Windows intentan acceder a TermService a través de RPC, y estas llamadas suelen originarse en la biblioteca winsta.dll, que actúa como cliente RPC.

Los procesos de Windows llaman a funciones de la API de winsta.dll, cuya implementación interna depende de la comunicación RPC con TermService. Este patrón es común en Windows: las llamadas a las funciones exportadas de muchas DLL del sistema se redirigen, en la práctica, mediante RPC a otros componentes del sistema.

Al parecer, el entorno de ejecución de RPC (rpcrt4.dll) no verifica de ninguna manera la legitimidad de los servidores RPC. Es más, Windows permite que otro proceso implemente un servidor RPC con el mismo endpoint que un servicio legítimo.

Esta arquitectura expone una superficie de ataque considerable, ya que RPC es utilizado por muchas DLL del sistema. Las aplicaciones que llaman a API que parecen inofensivas pueden, sin intención, iniciar comunicaciones RPC privilegiadas que, en determinadas condiciones, abren la puerta a la escalada de privilegios local sin el conocimiento del usuario.

Identificación de llamadas RPC a servidores no disponibles

Como la causa del problema parece residir en fallas de la propia arquitectura, se necesita un enfoque sistemático para identificar clientes RPC que intentan acceder a servidores no disponibles. Ante todo, se necesita una plataforma capaz de monitorear la actividad RPC y extraer información relevante de cada solicitud RPC.

En concreto, es necesario registrar los siguientes metadatos esenciales del RPC:

• UUID de la interfaz, endpoint e identificador OPNUM;
• nivel de suplantación y código de estado del RPC;
• nivel de privilegio del proceso cliente, nombre del proceso y ruta del módulo.

Esta información es fundamental para reconstruir la comunicación RPC, simular el servidor RPC esperado y entender con precisión cómo se inicia la llamada.

Una plataforma adecuada para esto es el seguimiento de eventos de Windows (ETW). ETW es un sistema de registro integrado en Windows que captura eventos en tiempo real, tanto en modo kernel como en modo usuario.

Para recopilar datos de ETW, Windows cuenta con la herramienta logman, que permite crear sesiones de seguimiento, seleccionar proveedores de eventos y configurar el nivel de detalle del monitoreo. Los resultados se guardan en un archivo con formato .etl, que luego puede analizarse con el Visor de eventos u otras herramientas de análisis de ETW.

ETW ofrece visibilidad detallada de la actividad RPC sin necesidad de modificar las aplicaciones. Con él, es posible obtener información detallada sobre el RPC, incluyendo:

• asociaciones RPC (bindings);
• endpoints;
• UUID de interfaz;
• detalles de autenticación;
• secuencia y tiempo de las llamadas;
• códigos de estado del RPC.

Sin embargo, no me interesan todos los eventos RPC, sino solo las llamadas RPC fallidas, en particular las que devuelven la excepción RPC_S_SERVER_UNAVAILABLE.

Para que un evento registrado se considere relevante para la investigación, la excepción debe cumplir dos condiciones:

• el error debe provenir de un proceso muy privilegiado, ya que la capacidad de actuar en nombre de ese proceso puede permitir que el atacante escale privilegios hacia un contexto de seguridad más amplio;
• la llamada RPC debe usar un nivel de suplantación alto, que permita al servidor actuar en su totalidad en nombre del cliente una vez establecida la conexión.

Esta verificación no puede basarse solo en la salida sin procesar de ETW: contiene miles de eventos, y filtrarlos de forma manual con herramientas estándar no es eficiente. Es necesario automatizar este proceso. El flujo de trabajo que se presenta a continuación permite seleccionar y extraer de forma eficiente solo los eventos relevantes para el análisis.

Una vez generados los registros en formato .etl, pueden convertirse a JSON con la herramienta etw2json u otra similar. El formato JSON es mucho más fácil de procesar mediante código. Para ello, se puede usar un script de Python que filtra y extrae la información necesaria.

El proceso de filtrado comienza con la búsqueda del evento con ID 1, correspondiente a la finalización de una operación RPC. Este evento indica que el cliente RPC completó la llamada y que el resultado ya está disponible. De él se puede extraer la siguiente información útil:

• código de estado;
• nombre del proceso cliente;
• identificador del proceso cliente (PID);
• endpoint.

Después de extraer el código de estado, se aplica un filtro por el valor RPC_S_SERVER_UNAVAILABLE, que indica llamadas RPC en las que el servidor de destino no estaba disponible. Justo esos son los eventos que interesan para el análisis posterior.

Sin embargo, el evento con ID 1 no contiene todos los metadatos RPC necesarios. Para obtener la información faltante, es necesario correlacionarlo con el evento con ID 5, que corresponde al inicio de la operación RPC. Este evento se genera en el momento en que el cliente inicia la llamada RPC.
Al correlacionar los metadatos de los eventos con ID 1 e ID 5, es posible recuperar los detalles faltantes, entre ellos:

• UUID de la interfaz;
• identificador OPNUM;
• nivel de suplantación.

Después de correlacionar y filtrar los eventos, se genera un registro JSON casi listo para el análisis. En esta etapa, los datos pueden enriquecerse con contexto adicional, útil para la ingeniería inversa o el análisis del funcionamiento del servidor RPC. En concreto, es posible determinar:

• el nombre de la DLL en la que está implementada la interfaz RPC;
• la ubicación de esa DLL;
• el número de procedimientos que ofrece la interfaz.

Para obtener esta información, compararé el UUID con una base de datos externa de interfaces RPC. Utilicé una base de datos que contiene una lista exhaustiva de interfaces RPC y sus DLL correspondientes.

Al finalizar este proceso, tengo un conjunto completo de datos JSON listo para análisis posteriores.

Es importante señalar que las llamadas RPC de interés solo ocurren durante determinadas acciones del sistema. Además, el tipo de excepción puede variar de un sistema a otro, según qué servicios estén habilitados o deshabilitados. Por ello, se necesita un método confiable para reproducir estas excepciones RPC.

En mi investigación, utilicé varios enfoques para provocar este tipo de eventos.

1. Monitoreo de la actividad RPC durante el inicio del sistema
   Monitoreé la actividad RPC durante el proceso de inicio del sistema operativo. Durante el arranque del sistema se inicializan numerosos servicios que realizan diversas llamadas RPC, lo que aumenta la probabilidad de detectar intentos de acceso a servidores no disponibles.
2. Ejecución de operaciones administrativas
   Desarrollé scripts de PowerShell que ejecutan tareas administrativas comunes, como la actualización de directivas de grupo, el cambio de configuración de red o la creación de nuevos usuarios. Este tipo de operaciones suele iniciar comunicación RPC y puede generar excepciones.
3. Desactivación intencional de servicios
   Como el servicio de escritorio remoto está desactivado por defecto, consideré oportuno deshabilitar otros servicios de forma sucesiva y repetir los pasos anteriores. De esta forma, es posible identificar clientes RPC que intentan conectarse a servicios ya no disponibles.

Vías adicionales de escalada de privilegios

El proceso de registro y monitoreo descrito permitió identificar cuatro escenarios adicionales que pueden derivar en una elevación de privilegios. Las siguientes secciones examinan cada uno de estos casos y explican cómo puede actuar un atacante.

Interacción con el usuario: de Edge a RDP

El navegador Microsoft Edge (msedge.exe) viene instalado por defecto en los sistemas Windows. Al iniciarse, Edge realiza una llamada RPC al servicio TermService con un nivel de suplantación alto.

Como se mencionó antes, el servicio de escritorio remoto viene desactivado por defecto. Como resultado, el servidor RPC esperado no está disponible, lo que crea las condiciones para el escenario de ataque que se muestra en el siguiente diagrama.

El ataque parte de la misma premisa que antes: el atacante ya ha comprometido un proceso que se ejecuta con la cuenta Network Service. En este contexto, el atacante implementa un servidor RPC falso que imita la interfaz RPC legítima de TermService.

A diferencia del escenario anterior, que dependía de coaccionar al servicio Group Policy para que realizara determinada acción, aquí eso no es necesario. Basta con que el atacante espere a que un usuario con privilegios elevados, como un administrador, inicie Microsoft Edge.

Al iniciarse, el cliente RPC de Edge intenta conectarse a la interfaz RPC esperada de TermService. Como el servidor legítimo está inactivo, la solicitud es recibida por el servidor RPC falso del atacante. Como la llamada RPC se realiza con un nivel de suplantación alto, el servidor malicioso puede llamar a la función RpcImpersonateClient y realizar operaciones en nombre del proceso cliente.

Como resultado, el atacante puede actuar en nombre del cliente con derechos de administrador, elevando los privilegios de Network Service al nivel Administrator.

Servicios en segundo plano: de WDI a RDP

Algunos servicios en segundo plano de Windows realizan llamadas RPC al servicio RDP de forma periódica, sin intervención del usuario. Uno de ellos es WdiSystemHost. El servicio Diagnostic System Host (WDI) es un componente integrado de Windows responsable del diagnóstico y la resolución de problemas del sistema. Se ejecuta con la cuenta SYSTEM.

Durante su ejecución, WDI inicia de forma periódica llamadas RPC en segundo plano al servicio de escritorio remoto (TermService), utilizando un nivel de suplantación alto. Estas comunicaciones ocurren de manera automática cada 5 a 15 minutos, sin requerir ninguna intervención del usuario.

El comportamiento de este servicio puede aprovecharse con fines maliciosos, de forma similar a los escenarios de ataque anteriores, como se muestra en el siguiente diagrama.

Sin embargo, en este escenario no se requiere ninguna acción del usuario ni el uso de técnicas de coerción. Después de implementar el servidor RPC malicioso que imita la interfaz RPC esperada de TermService, el atacante solo necesita esperar la próxima llamada RPC periódica de WDI. Como la solicitud se realiza con un nivel de suplantación alto, el servidor malicioso puede llamar a la función RpcImpersonateClient para actuar en nombre del proceso que realizó la llamada, lo que permite escalar privilegios hasta el nivel SYSTEM.

Abuso de la cuenta Local Service: de ipconfig a DHCP

Otro escenario involucra al servicio DHCP Client, encargado de gestionar las operaciones de cliente DHCP en los sistemas Windows. Este servicio se ejecuta con la cuenta Local Service y viene habilitado por defecto.

Ofrece un servidor RPC con varias interfaces y endpoints. Estas interfaces suelen ser llamadas por DLL del sistema, a menudo con un nivel de suplantación alto.

En este escenario, en lugar de comprometer un proceso con privilegios de Network Service, se considera que el atacante obtuvo control sobre un proceso que se ejecuta con la cuenta Local Service. También se asume que el servicio DHCP Client está desactivado, lo que hace que el servidor RPC legítimo no esté disponible.

Como se muestra en el siguiente diagrama, el atacante puede aprovechar esta situación para escalar sus privilegios.

Tras obtener control sobre un proceso con privilegios de Local Service, el atacante implementa un servidor RPC falso que imita la interfaz RPC legítima de DHCP Client. Con el servidor malicioso en ejecución, el atacante espera a que un usuario con privilegios elevados, como un administrador, ejecute el comando ipconfig.exe.

Al ejecutarse, el comando desencadena una solicitud RPC al servicio DHCP Client. Como el servidor RPC legítimo está inactivo, la solicitud es recibida por el servidor RPC falso del atacante. Como la llamada RPC se realiza con un nivel de suplantación alto, el servidor malicioso puede llamar a la función RpcImpersonateClient y realizar operaciones en nombre del proceso cliente.

Como resultado, el atacante logra escalar privilegios del nivel Local Service a Administrator.

Abuso del servicio de hora

El servicio Windows Time (W32Time) es responsable de sincronizar la fecha y hora entre sistemas en el entorno Windows. Este servicio viene habilitado por defecto y se ejecuta con la cuenta Local Service.

Ofrece un servidor RPC con dos endpoints:

• \PIPE\W32TIME_ALT
• \RPC Control\W32TIME_ALT

El ejecutable C:\Windows\System32\w32tm.exe se comunica con el servicio Windows Time a través de RPC. Pero antes de conectarse a los endpoints RPC correctos de este servicio, intenta acceder a la canalización con nombre inexistente \PIPE\W32TIME. En el servicio legítimo W32Time, esta canalización no está disponible. Sin embargo, si este endpoint existiera, el ejecutable w32tm.exe intentaría conectarse a él.

Un atacante puede aprovechar esta situación implementando un servidor RPC falso que imita la interfaz RPC legítima del servicio Windows Time. En lugar de los endpoints legítimos, este servidor ofrece acceso al endpoint ficticio \PIPE\W32TIME, como se muestra en el siguiente diagrama.

Al igual que en los escenarios anteriores, se considera que el atacante ya obtuvo control sobre un proceso que se ejecuta con la cuenta Local Service. A continuación, debe implementar un servidor RPC falso que ofrezca la misma interfaz RPC que el servicio Windows Time, pero con el endpoint alternativo al que intenta acceder w32tm.exe.

Con el servidor malicioso en ejecución, el atacante solo necesita esperar a que un usuario con privilegios elevados, como un administrador, ejecute el comando w32tm.exe. Al iniciarse, el ejecutable intenta conectarse al endpoint \PIPE\W32TIME. Como este endpoint está disponible en el servidor falso, la solicitud RPC se redirige hacia él.

Como la llamada RPC se realiza con un nivel de suplantación alto, el servidor malicioso puede realizar operaciones en nombre del cliente que realizó la llamada. Como resultado, el atacante puede escalar privilegios del nivel Local Service a Administrator.

Es importante señalar que este escenario funciona incluso si el servicio legítimo Windows Time no está desactivado. Como el ejecutable intenta conectarse a un endpoint inexistente, basta con que el atacante cree ese endpoint en su servidor RPC malicioso.

Divulgación de la vulnerabilidad

Tras el descubrimiento de la vulnerabilidad, el equipo de Kaspersky Security Services preparó un informe técnico de diez páginas que describe el problema y los escenarios de explotación ya presentados. El informe se envió al Centro de Respuesta de Microsoft (MSRC) para notificar a la empresa sobre el problema y solicitar una corrección.

Después de 20 días, Microsoft respondió que sus especialistas no consideraban crítica la vulnerabilidad. Al problema se le asignó una gravedad media; por ello, no se planeaba una corrección inmediata, no se asignaría un CVE y el caso se cerró sin seguimiento adicional.

Para justificar esta evaluación, Microsoft indicó que la explotación requiere que el proceso de origen ya posea el privilegio SeImpersonatePrivilege. Como muchas veces no es posible llevar a cabo un ataque exitoso sin esto, la empresa consideró que el problema no requería una corrección urgente.
El equipo de Kaspersky Security Services respeta la evaluación de Microsoft. Esta investigación se publica una vez concluido el período de embargo. De acuerdo con los principios de divulgación coordinada de vulnerabilidades, el informe excluye cualquier detalle que pueda facilitar o acelerar la explotación masiva.

La cronología de la divulgación se presenta a continuación:

• 19 de septiembre de 2025: informe de la vulnerabilidad enviado al Centro de Respuesta de Microsoft (caso n.º 101749)
• 10 de octubre de 2025: respuesta del MSRC recibida, con la vulnerabilidad clasificada como de gravedad media, sin derecho a recompensa, sin asignación de CVE y con el caso cerrado sin seguimiento adicional
• 24 de abril de 2026: publicación del análisis técnico

Medidas de detección y protección

Como se mencionó antes, esta vulnerabilidad se debe a características de la arquitectura, y su eliminación completa depende de una corrección de Microsoft que aborde la causa raíz del problema.

Aun así, las organizaciones pueden adoptar medidas para detectar y reducir los riesgos de una posible explotación. El monitoreo basado en ETW, siguiendo el proceso descrito en esta investigación, permite que los equipos de seguridad identifiquen excepciones RPC en sus entornos, en particular los casos en que clientes RPC intentan conectarse a servidores no disponibles.

También publiqué las herramientas utilizadas en esta investigación, para que las organizaciones puedan verificar sus entornos en busca de este tipo de comportamiento. Todas están disponibles en el repositorio de la investigación.

Al monitorear estos eventos, los administradores pueden identificar situaciones en las que se espera que haya servidores RPC legítimos en ejecución, pero no lo están. En algunos casos, la superficie de ataque puede reducirse habilitando los servicios correspondientes y garantizando la disponibilidad del servidor RPC legítimo. Esto reduce el riesgo de que los atacantes implementen servidores RPC falsos que imiten endpoints legítimos.

También recomendamos limitar el uso del privilegio SeImpersonatePrivilege en procesos donde no es necesario. Aunque algunos procesos del sistema lo requieren para funcionar de forma correcta, en algunos casos se otorga a procesos de usuario, lo cual se considera una práctica insegura.

Conclusión

Todos los exploits descritos en esta investigación se probaron en Windows Server 2022 y Windows Server 2025, con las actualizaciones más recientes disponibles al momento del envío del informe. Los exploits de prueba de concepto están disponibles en el repositorio de la investigación. Aun así, es muy probable que esta vulnerabilidad también afecte a otras versiones de Windows.

Como la vulnerabilidad se debe a una falla de arquitectura, pueden existir escenarios de ataque además de los presentados en esta investigación. Los métodos específicos de explotación pueden variar de un sistema a otro, dependiendo, por ejemplo, de los componentes instalados, las DLL utilizadas en las comunicaciones RPC y la disponibilidad de los servidores RPC correspondientes.