Named pipe de Windows: el canal local que puede convertirse en una puerta para la escalada de privilegios

La comunicación entre procesos no es automáticamente confiable

El 22 de agosto de 2026 se volvió a poner el foco en un riesgo que a menudo se subestima en las arquitecturas Windows: las named pipe no deben considerarse canales privados solo porque conectan procesos en el mismo equipo.

Estos objetos permiten que servicios, aplicaciones de escritorio, utilidades de línea de comandos, procesos en la bandeja del sistema y agentes en segundo plano intercambien datos. En muchos casos, el servidor de la pipe es un servicio ejecutado con privilegios elevados, mientras que el cliente se ejecuta con la cuenta del usuario.

Sin embargo, en el sistema pueden coexistir procesos pertenecientes a LocalSystem, administradores, usuarios estándar y cuentas de servicio. También puede haber software de terceros, scripts, herramientas de diagnóstico y malware iniciados mediante credenciales comprometidas.

Un proceso que conoce el nombre de la pipe y dispone de los derechos necesarios puede intentar conectarse. Windows no verifica automáticamente que el cliente sea exactamente el ejecutable previsto por el desarrollador. Una conexión exitosa solo demuestra que el token del proceso tenía los permisos requeridos.

No demuestra que el proceso fuera confiable, que el usuario estuviera autorizado ni que la operación solicitada fuera segura.

Cuándo la pipe se convierte en un límite de seguridad

El riesgo aumenta cuando los dos extremos de la comunicación tienen distintos niveles de privilegio. El ejemplo más delicado es un servicio de Windows ejecutado como LocalSystem que acepta solicitudes de una aplicación iniciada por un usuario estándar.

Un servicio de este tipo puede modificar archivos protegidos, escribir en el Registro, iniciar procesos, cambiar la configuración global, acceder a los datos de otros usuarios o comunicarse con controladores del kernel.

Por tanto, la named pipe se convierte, en la práctica, en una API local para realizar operaciones privilegiadas. Un error en la DACL, en la identificación del cliente, en la validación de los comandos o en la lógica de autorización puede permitir que un proceso local aproveche los privilegios del servicio.

El problema es típico del modelo confused deputy: el cliente decide qué acción solicitar, pero la operación la ejecuta el servicio con privilegios superiores.

Los mensajes pueden contener rutas de archivos, claves del Registro, argumentos de línea de comandos, nombres de ejecutables, instrucciones para iniciar o finalizar procesos y solicitudes de instalación. Un servicio que acepta un comando genérico como «escribir un valor en cualquier clave» expone una superficie mucho mayor que uno que solo permite actualizar una configuración concreta de la aplicación.

La sintaxis correcta no es suficiente. El servidor debe determinar si esa identidad concreta puede realizar esa operación específica sobre el recurso indicado.

Las ACL, los tokens y las autorizaciones deben funcionar conjuntamente

La protección debe comenzar con un descriptor de seguridad explícito, acompañado de una DACL que conceda acceso únicamente a las identidades necesarias: un SID específico, una cuenta de servicio, un grupo administrativo o una sesión determinada.

Confiar en la configuración predeterminada puede conceder derechos excesivos. Conviene evitar permisos generalizados para:

• Everyone;
• Authenticated Users;
• todos los usuarios interactivos.

Autenticación y autorización no son lo mismo. Un cliente puede estar autorizado a leer el estado del servicio, pero no a detenerlo, modificar configuraciones protegidas, iniciar procesos o leer archivos arbitrarios.

Por tanto, las operaciones sensibles deben evaluarse individualmente.

La suplantación de identidad (impersonation) también requiere cautela. Puede permitir que el servicio realice una acción en el contexto de seguridad del cliente, pero el servidor debe verificar que la operación se haya completado correctamente, minimizar el código ejecutado durante esa fase y restaurar siempre su identidad original.

La regla operativa es sencilla: antes de procesar un mensaje, el servidor debe verificar la identidad, los privilegios y la autorización específica.

Identificar el proceso conectado

En las comunicaciones locales, el servidor puede obtener el PID del cliente mediante GetNamedPipeClientProcessId. Del mismo modo, el cliente puede utilizar GetNamedPipeServerProcessId para identificar el proceso del servidor.

Estas funciones pertenecen a las API nativas de kernel32.dll y deben llamarse después de establecer la conexión. A continuación, el PID permite abrir un handle con PROCESS_QUERY_INFORMATION o PROCESS_QUERY_LIMITED_INFORMATION y utilizar QueryFullProcessImageName para recuperar la ruta del ejecutable.

La comprobación debe realizarse inmediatamente después de aceptar la conexión, antes de leer o aplicar comandos. La ruta obtenida debe compararse con la esperada, pero el ejecutable debe encontrarse en un directorio que los usuarios estándar no puedan modificar. De lo contrario, un atacante podría sustituir el archivo manteniendo la misma ruta.

Para una verificación más sólida, pueden comprobarse la firma Authenticode o la correspondencia criptográfica con una referencia aprobada.

El nombre de la pipe no es un secreto. Un atacante puede conocerlo, intentar crear una pipe con el mismo nombre antes de que se inicie el servidor legítimo y hacer que el cliente se conecte al proceso equivocado. La opción first-pipe-instance puede ayudar a detectar que el nombre ya ha sido reclamado, pero no sustituye unas ACL correctas ni la identificación del proceso.

Cada mensaje debe tratarse como una entrada hostil

Incluso un cliente legítimo puede enviar datos corruptos o excesivamente grandes, o diseñados para provocar errores. El protocolo debería incluir un framing estricto, límites de tamaño, un esquema verificable y una allowlist de los comandos admitidos.

También son necesarios:

• normalización de rutas;
• rechazo de operaciones ambiguas;
• gestión segura de errores;
• autorización por operación;
• separación entre funciones informativas y acciones privilegiadas;
• limitación de las funcionalidades a lo estrictamente necesario.

El servicio no debería aceptar rutas arbitrarias cuando pueda trabajar con identificadores predefinidos. Por ejemplo, es más seguro permitir la actualización de una configuración concreta que recibir del cliente la ruta completa de una clave del Registro.

Lo mismo se aplica a los procesos: un comando limitado al inicio de un componente conocido es menos arriesgado que una interfaz capaz de ejecutar cualquier programa con argumentos elegidos por el cliente.

Disponibilidad y acceso remoto

La amenaza no afecta únicamente a la confidencialidad o a la escalada de privilegios. Un proceso malicioso puede abrir numerosas conexiones, mantenerlas activas, enviar mensajes incompletos o consumir memoria, CPU y recursos del kernel.

Los tiempos de espera, la cancelación de solicitudes, el número máximo de conexiones, la concurrencia controlada y los tamaños máximos de los mensajes reducen el riesgo de abuso.

Además, no todas las named pipe están necesariamente limitadas al equipo local. En determinadas configuraciones, Windows puede permitir el acceso remoto. Las pipes destinadas exclusivamente a la comunicación entre procesos local deberían bloquear explícitamente identidades de red como NT AUTHORITY\NETWORK o utilizar un mecanismo que garantice que funcionen únicamente de forma local.

No se conoce ningún CVE asociado a este problema, ni se indican versiones específicas de Windows o productos vulnerables. Se trata de un modelo de seguridad aplicable a las implementaciones que utilizan named pipe, no de la descripción de una vulnerabilidad concreta identificada.

La verificación correcta debe considerar conjuntamente cinco elementos: identidad del proceso, permisos efectivos, autorización de la acción, seguridad de los datos y límites de recursos. Una conexión aceptada nunca equivale a una autorización general.