Impersonación de tokens en Windows: guía del defensor para detección y endurecimiento

En Windows, casi toda decisión de seguridad se reduce en última instancia a un pequeño objeto del kernel: el token de acceso. Cuando un atacante que ya tiene un punto de apoyo quiere pasar de una cuenta de servicio a SYSTEM, o actuar como administrador de dominio sin conocer la contraseña de esa persona, la impersonación y manipulación de tokens es una de las técnicas clásicas a las que recurre. Este artículo está escrito para defensores. El objetivo no es enseñar a nadie a comprometer una máquina, sino explicar a nivel conceptual qué son los tokens, por qué la impersonación es una función legítima y muy usada y, sobre todo, cómo detectar el abuso y endurecer el entorno para que la técnica se vuelva ruidosa, frágil y fácil de detener. Todo lo siguiente se corresponde con la técnica de MITRE ATT&CK T1134 (Access Token Manipulation).

Qué es realmente un token de acceso de Windows

Cada proceso e hilo en Windows lleva un token de acceso. Piénselo como una credencial firmada que responde a la pregunta que el kernel hace en cada acción protegida: ¿quién eres y qué puedes hacer? El token contiene el identificador de seguridad (SID) del usuario, los SID de todos los grupos a los que pertenece, una lista de privilegios habilitados y deshabilitados (como SeDebugPrivilege o SeImpersonatePrivilege), un nivel de integridad y otros atributos. Cuando un hilo intenta abrir un archivo, conectarse a una tubería con nombre o iniciar un servicio, el Monitor de Referencia de Seguridad compara el token con el descriptor de seguridad del objeto. Esto no es un error ni una puerta trasera: es el fundamento de la autorización de Windows y funciona exactamente como se diseñó.

Aquí importan dos tipos de token. Un token primario se adjunta a un proceso y define su identidad base. Un token de impersonación permite que un solo hilo actúe temporalmente en nombre de otro contexto de seguridad. La impersonación existe por buenas razones: un servidor web, de archivos o de base de datos a menudo necesita realizar trabajo como el cliente que se conectó, para que las comprobaciones de acceso reflejen al usuario real y no a la cuenta de servicio altamente privilegiada. Windows expone esto mediante API y privilegios documentados. El abuso ocurre cuando un atacante reutiliza esa misma maquinaria para tomar prestada una identidad más poderosa de la que legítimamente posee.

Cómo funcionan la impersonación y la manipulación a alto nivel

Conceptualmente, el abuso de tokens sigue unos pocos patrones. En el primero, un atacante que controla un proceso con derechos de impersonación convence a un cliente más privilegiado —a menudo un servicio o el propio sistema operativo— de autenticarse contra algo que él controla, captura el token de impersonación resultante y lo adopta. En el segundo, un atacante con derechos suficientes duplica un token existente de otro usuario con sesión iniciada y lanza un nuevo proceso con él. En el tercero, se aprovechan privilegios ya presentes en un token (como derechos de depuración o de impersonación) para alcanzar un proceso más privilegiado y adoptar su contexto.

El hilo común es que no se roba ninguna contraseña ni se explota necesariamente un fallo de corrupción de memoria. El atacante usa funciones previstas de Windows con una identidad que no debería manejar. Precisamente por eso la técnica resulta atractiva para los adversarios y por eso la prevención basada en firmas por sí sola es insuficiente: las llamadas a la API parecen ordinarias. La defensa debe apoyarse en el contexto: qué cuenta, desde qué linaje de proceso, en qué momento, haciendo qué a continuación.

Superficie de ataque: los privilegios que lo hacen posible

Un puñado de privilegios de Windows habilita el abuso de tokens de forma desproporcionada, e inventariar quién los posee es una de las actividades defensivas de mayor valor. SeImpersonatePrivilege y SeAssignPrimaryTokenPrivilege permiten a un proceso impersonar o asignar identidades de token y, de forma predeterminada, se conceden a cuentas de servicio como LOCAL SERVICE, NETWORK SERVICE y cuentas que ejecutan IIS o SQL Server. SeDebugPrivilege permite abrir prácticamente cualquier proceso, incluidos los muy privilegiados, y casi nunca debería estar en manos de usuarios comunes. SeCreateTokenPrivilege es aún más sensible y las aplicaciones normales casi nunca lo necesitan.

Como estos privilegios se usan de forma legítima, la pregunta defensiva no es '¿podemos quitar la impersonación de Windows?' —no se puede— sino '¿qué cuentas no de servicio, interactivas o de baja confianza han acumulado estos derechos, y podemos quitárselos?' La proliferación de privilegios en cuentas de servicio, los grupos de administradores locales demasiado permisivos y las credenciales compartidas son lo que convierte un único proceso comprometido de bajo privilegio en un problema para todo el dominio.

Detección: los registros y eventos que importan

La señal más útil por sí sola es el registro de seguridad de Windows. Los inicios de sesión exitosos se registran como evento 4624, y el campo tipo de inicio de sesión es crítico: el tipo 9 (NewCredentials) y los inicios de sesión de impersonación inusuales merecen escrutinio, sobre todo cuando se originan en cuentas de servicio o de máquina que luego actúan como administradores humanos. El evento 4672 ('Privilegios especiales asignados a nuevo inicio de sesión') se dispara cada vez que a una sesión se le conceden privilegios sensibles como SeDebugPrivilege o SeImpersonatePrivilege; una línea base de qué cuentas lo activan normalmente convierte las anomalías en alertas. El evento 4688 (creación de proceso) con auditoría de línea de comandos permite reconstruir el linaje de procesos: una cuenta de servicio que lanza cmd.exe o powershell.exe como SYSTEM poco después de un evento de impersonación es una pista fuerte.

Donde tenga Sysmon desplegado, el ID de evento 1 (creación de proceso) enriquece el linaje con hashes y detalles del padre, el ID de evento 8 (CreateRemoteThread) y el ID de evento 10 (ProcessAccess) sacan a la luz accesos entre procesos hacia objetivos sensibles como lsass.exe, y el ID de evento 25 (manipulación de proceso) marca la manipulación. Las plataformas EDR modernas añaden telemetría a nivel de token directamente: pueden informar cuándo la identidad efectiva de un hilo diverge de su propietario de proceso, cuándo se duplica un token y cuándo se usa un token privilegiado para crear un proceso hijo. El arte defensivo consiste en correlacionar esto en una historia en lugar de alertar sobre cualquier llamada aislada de apariencia benigna.

Ingeniería de detección: convertir telemetría en alertas

Las detecciones eficaces son conductuales y correlacionadas. Las reglas de alto valor incluyen: una cuenta de servicio (LOCAL/NETWORK SERVICE o la identidad de un grupo de aplicaciones) que se convierte en padre de una shell interactiva; un evento 4672 de privilegios especiales para una cuenta que nunca ha necesitado legítimamente esos privilegios; un proceso cuyo SID de token de hilo no coincide con el SID de token de proceso realizando acciones sensibles; y cualquier handle abierto a lsass.exe con derechos de acceso que permitan leer o duplicar tokens desde un proceso que no sea un producto de seguridad conocido. Enriquezca cada alerta con el nivel del activo, el tipo de cuenta y el historial de autenticación reciente para que los analistas triajen rápido.

Construya estas reglas contra una línea base. La mayoría de los entornos tienen un conjunto pequeño y estable de procesos que impersonan legítimamente: agentes de copia de seguridad, servidores web, motores de base de datos, herramientas de gestión. Enumérelos, ponga en lista de permitidos el comportamiento esperado de forma explícita y alerte sobre la cola larga. Combine las alertas con respuesta automatizada donde confíe en ella: aislar un host, deshabilitar una sesión o forzar la reautenticación de un administrador por niveles puede contener el movimiento lateral antes de que se propague.

Mitigación y endurecimiento

La prevención empieza por el mínimo privilegio. Audite qué cuentas poseen SeImpersonatePrivilege, SeAssignPrimaryTokenPrivilege, SeDebugPrivilege y SeCreateTokenPrivilege, y quíteselos a todo lo que no los requiera estrictamente. Use las políticas de asignación de derechos de usuario en la directiva de grupo para mantener los privilegios sensibles fijados a un conjunto mínimo. Adopte un modelo de administración por niveles: las credenciales de dominio y de alto valor nunca deben iniciar sesión de forma interactiva en estaciones de trabajo de nivel inferior, porque un token robado o impersonado solo es tan peligroso como las identidades presentes en esa máquina.

Proteja las credenciales privilegiadas en el origen. Añada las cuentas sensibles al grupo Usuarios protegidos y márquelas como 'confidencial y no se puede delegar' para que sus tokens no se almacenen en caché ni se deleguen donde puedan abusarse. Habilite Credential Guard y la protección de LSASS (RunAsPPL / LSASS como proceso protegido) para dificultar mucho más la lectura o duplicación de material de credenciales y tokens desde la memoria. Restrinja los derechos de administrador local con una solución como LAPS para que un único endpoint comprometido no otorgue acceso de administrador reutilizable en toda la flota. Por último, mantenga los sistemas parcheados: varias rutas de escalada de privilegios que terminan en abuso de tokens comienzan con un servicio sin parchear que se ejecuta con derechos de impersonación.

Errores comunes y puntos ciegos

El mayor error de los defensores es suponer que, por ser la impersonación una función normal de Windows, no puede monitorizarse. Sí puede, pero solo si la auditoría de línea de comandos y de creación de procesos está realmente habilitada, si Sysmon o EDR están desplegados de forma consistente y si los registros se envían fuera del host a un SIEM donde sea posible la correlación. Un segundo error es la fatiga de alertas: disparar en cada 4672 sin una línea base ahoga a los analistas y los entrena para ignorar la señal. Un tercero es la mezcla de niveles: permitir que un administrador de dominio ejecute herramientas en una estación común 'solo por esta vez' deshace gran parte de su endurecimiento, porque el token que aterriza allí puede tomarse prestado. Por último, no olvide las cuentas de servicio: suelen estar sobreprivilegiadas, rara vez se rotan y casi nunca se vigilan tan de cerca como las cuentas humanas, lo que las convierte en la plataforma de lanzamiento preferida para el abuso de tokens.

Lista de verificación defensiva

Use esto como base inicial y adáptelo a su entorno: (1) Inventaríe toda cuenta y proceso que posea SeImpersonatePrivilege, SeAssignPrimaryTokenPrivilege, SeDebugPrivilege y SeCreateTokenPrivilege, y pode sin piedad. (2) Habilite la auditoría de creación de procesos (4688) con líneas de comandos, y audite el uso de privilegios especiales (4672). (3) Despliegue Sysmon o EDR con reglas para el acceso entre procesos a lsass.exe y la duplicación de tokens. (4) Envíe todos los registros de seguridad a un SIEM y construya reglas de correlación basadas en línea base. (5) Implemente administración por niveles y prohíba los inicios de sesión de alto valor en hosts de nivel inferior. (6) Añada las cuentas privilegiadas a Usuarios protegidos y márquelas como no delegables. (7) Active Credential Guard y la protección de LSASS. (8) Despliegue LAPS para eliminar las contraseñas compartidas de administrador local. (9) Parchee con prontitud, priorizando los servicios que se ejecutan con privilegios de impersonación. (10) Ensaye la respuesta: aislamiento, revocación de sesión y reautenticación forzada.

Preguntas frecuentes

¿Es una opción deshabilitar la impersonación? No. La impersonación es fundamental para que los servicios de Windows atiendan a los clientes de forma segura; eliminarla rompería IIS, SQL Server, el uso compartido de archivos e innumerables aplicaciones. El enfoque correcto es mínimo privilegio más detección, no eliminación. Si la detección es conductual, ¿tendré falsos positivos? Algunos, al principio. Por eso importa el baselining: enumere los impersonadores legítimos de su entorno, póngalos explícitamente en lista de permitidos y alerte sobre las desviaciones. En unas semanas el ruido cae bruscamente y las alertas restantes son de alta señal.

Conclusión

La impersonación y manipulación de tokens es poderosa precisamente porque se esconde dentro de funcionalidad legítima de Windows: sin contraseña descifrada, sin exploit evidente, solo una identidad tomada prestada. Justamente por eso los defensores deben tratarla como un problema de detección y endurecimiento en lugar de algo que un único control bloquea. Inventaríe y pode los privilegios que la hacen posible, habilite la auditoría que la hace visible, correlacione la telemetría en alertas basadas en comportamiento y aplique un modelo por niveles para que un token prestado no llegue a sus joyas de la corona. Haga esto de forma consistente y una técnica de la que los adversarios dependen para la escalada sigilosa de privilegios se convertirá en uno de los movimientos más ruidosos y contenibles que pueden hacer.