Escalada de privilegios en Windows: vectores y endurecimiento
Guía para equipos azules sobre la escalada de privilegios en Windows: los vectores comunes, la telemetria que los detecta y el endurecimiento que los elimina.
En este artículo
La escalada de privilegios en Windows es una de las fases más determinantes de una intrusión real y, a la vez, una de las más defendibles. Este artículo está dirigido a equipos azules, ingenieros de detección y administradores de sistemas que necesitan entender la mecánica para poder defenderse de ella. Describiremos, a nivel conceptual, cómo un atacante que ya tiene un acceso de bajos privilegios intenta convertirse en SYSTEM o en administrador de dominio, qué telemetría revela esos intentos y cómo endurecer un entorno Windows para que los vectores más comunes simplemente no existan. Aquí no hay cargas útiles listas para ejecutar: el objetivo es una detección y una mitigación duraderas, no un manual de compromiso.
Qué significa realmente la escalada de privilegios
La escalada de privilegios es la transición de un contexto de seguridad a otro más poderoso en el mismo equipo o dominio. Los defensores suelen dividirla en dos familias. La escalada vertical pasa de un usuario estándar o de baja integridad a una cuenta de altos privilegios como NT AUTHORITY\SYSTEM, un administrador local o un administrador de dominio. La escalada horizontal se mueve lateralmente hacia otro usuario de privilegio similar para alcanzar datos o confianza que la cuenta original no tenía. La escalada casi nunca ocurre de forma aislada: se sitúa entre el acceso inicial y el movimiento lateral en el ciclo del ataque, y a menudo es el paso donde una infección menor se convierte en un compromiso total. Por eso, detectar los intentos de escalada tiene mucho valor incluso cuando fallan, ya que un intento fallido revela un acceso que no sabías que existía.
Cómo Windows impone los privilegios de entrada
Para defender la frontera hay que saber dónde está. Windows asigna a cada proceso un token de acceso que lleva el SID del usuario, los SID de grupo, un nivel de integridad (Bajo, Medio, Alto, Sistema) y un conjunto de privilegios como SeDebugPrivilege, SeImpersonatePrivilege y SeBackupPrivilege. El Control de Cuentas de Usuario (UAC) divide el inicio de sesión de un administrador en dos tokens: uno filtrado de integridad media para el trabajo diario y uno completo de integridad alta que solo aparece tras una solicitud de elevación. La mayoría de las técnicas de escalada son, en esencia, intentos de obtener un token que el usuario nunca debía tener, o de ejecutar código dentro de un proceso que ya lo posee. Comprender los tokens, los niveles de integridad y los privilegios es, por tanto, el vocabulario común de toda detección y toda mitigación que sigue.
Los vectores comunes y dónde residen
Los vectores de escalada se agrupan en un puñado de configuraciones incorrectas recurrentes, y nombrarlos de forma defensiva permite auditar su ausencia. Las configuraciones incorrectas de servicios son el caso clásico: un servicio que se ejecuta como SYSTEM pero cuyo binario, o cuya carpeta, es escribible por usuarios sin privilegios permite reemplazar lo que el servicio ejecuta. Relacionado está el problema de la ruta de servicio sin comillas, donde una ruta con espacios hace que Windows pruebe primero ejecutables de nivel superior. Los permisos débiles de servicio permiten reconfigurar directamente la ruta del binario. Del lado del instalador, las políticas emparejadas AlwaysInstallElevated dejan que cualquier usuario instale paquetes como SYSTEM. El abuso de tokens aprovecha cuentas con privilegios de suplantación, común en cuentas de servicio web y de base de datos. El secuestro del orden de búsqueda de DLL coloca una biblioteca donde un proceso privilegiado la cargará. Por último, el robo de credenciales desde la memoria, el registro o archivos de instalación desatendida suele permitir al atacante saltarse la escalada por completo. No se necesitan herramientas de ataque para hallar esto; una auditoría de configuración lo encuentra antes.
Detección: la telemetría que expone la escalada
La escalada es ruidosa si se escucha en los canales correctos. Habilite y reenvíe el registro de seguridad de Windows junto con Sysmon y su EDR, y centre la detección en unas pocas señales duraderas. El evento 4672 ("Privilegios especiales asignados al nuevo inicio de sesión") se dispara cuando una sesión recibe privilegios sensibles como SeDebugPrivilege; correlacione la cuenta y el proceso padre. Los eventos 4673 y 4674 registran operaciones privilegiadas de servicio y objeto. La escalada basada en servicios aflora mediante 7045 (se instaló un nuevo servicio) y 4697, más el ID de evento 1 de Sysmon (creación de proceso) mostrando una cadena padre-hijo inesperada como services.exe lanzando cmd.exe. La manipulación e inyección de tokens aparecen como los ID 8 (CreateRemoteThread) y 10 (ProcessAccess) de Sysmon contra lsass.exe con máscaras de acceso sospechosas. Los vectores del registro como AlwaysInstallElevated aparecen como el ID de evento 13 de Sysmon. Las detecciones más fuertes los combinan: un proceso de integridad media que de pronto genera un hijo de integridad alta, o una cuenta de servicio que obtiene suplantación y luego lanza una shell.
Construir detecciones que sobrevivan a entornos reales
Los ID de evento en bruto generan ruido, así que conviértalos en reglas basadas en comportamiento. Alerte sobre transiciones de nivel de integridad: un árbol de procesos donde un padre de integridad media produce un hijo de integridad alta o de sistema sin un evento legítimo de consentimiento UAC merece investigación. Establezca una línea base de sus servicios legítimos y alerte cuando 7045 instale un servicio con una ruta de binario en C:\Users, C:\Windows\Temp u otra ubicación escribible por el usuario. Vigile las cuentas con SeImpersonatePrivilege que lanzan shells interactivas. Asigne cada regla a las técnicas de MITRE ATT&CK bajo la táctica de Escalada de Privilegios (TA0004) para que las brechas sean visibles, y valide las reglas con un ejercicio autorizado de equipo púrpura en lugar de suponer que se disparan. Alimente las alertas en un flujo de triaje que capture el token, la cadena de padres y el artefacto modificado, porque esos tres hechos suelen reconstruir toda la técnica.
Mitigación y endurecimiento que elimina los vectores
La mejor detección de escalada es un vector que ya no existe. Imponga el mínimo privilegio: los usuarios estándar nunca deben ser administradores locales, y las cuentas de servicio deben ser Group Managed Service Accounts con exactamente el alcance necesario. Audite y corrija las ACL de archivos y carpetas de cada ruta de binario de servicio para que los no administradores no puedan escribir en ellas, y resuelva cada ruta de servicio sin comillas. Establezca ambos valores AlwaysInstallElevated como deshabilitados mediante directiva de grupo. Retire privilegios sensibles como SeImpersonatePrivilege de las cuentas que no los requieran, y aísle las credenciales con Credential Guard y la protección de LSA (RunAsPPL) para dificultar el robo de memoria. Mantenga los sistemas parcheados, ya que muchos exploits de escalada apuntan a vulnerabilidades locales conocidas. Despliegue control de aplicaciones (WDAC o AppLocker) para que un binario colocado no pueda ejecutarse aunque una ACL se relaje. Por último, vigile el abuso de carga de controladores, pues los controladores firmados pero vulnerables son un puente de escalada cada vez más común.
Errores que debilitan un programa por lo demás bueno
Varios errores recurrentes vacían una defensa contra la escalada. El primero es registrar sin reenviar: los eventos existen en el endpoint pero nunca llegan al SIEM, de modo que el atacante que borra el registro local elimina la única evidencia. El segundo es la fatiga de alertas por eventos 4672 en bruto, que se disparan constantemente para administradores legítimos; sin línea base, los analistas aprenden a ignorar el que importa. El tercero es confiar demasiado en UAC como frontera de seguridad — Microsoft mismo no trata el UAC predeterminado como tal. El cuarto son las ACL de servicio obsoletas que introducen instaladores de terceros mucho después del endurecimiento inicial, por lo que la auditoría debe ser continua. Por último, los equipos suelen olvidar las tareas programadas y las carpetas de inicio, que ofrecen el mismo patrón que los servicios y merecen el mismo escrutinio.
Una lista de verificación práctica de endurecimiento y detección
Úsela como auditoría recurrente, no como un proyecto único. 1) Confirme que ningún usuario estándar es administrador local. 2) Enumere las rutas de binarios de servicio y verifique que ninguna sea escribible por no administradores. 3) Resuelva cada ruta de servicio sin comillas. 4) Verifique que ambos valores de AlwaysInstallElevated estén deshabilitados. 5) Revise qué cuentas poseen SeImpersonatePrivilege, SeDebugPrivilege y SeBackupPrivilege, y retire lo innecesario. 6) Habilite Credential Guard y la protección de LSA donde sea compatible. 7) Despliegue WDAC o AppLocker en modo de aplicación. 8) Envíe los registros de Seguridad, Sysmon y EDR al SIEM y confirme la ingesta. 9) Alerte sobre saltos de integridad, rutas 7045 sospechosas y acceso a lsass.exe. 10) Valide toda la cadena cada trimestre con una prueba autorizada de equipo púrpura.
Preguntas frecuentes
¿Es aceptable alguna vez deshabilitar UAC para reducir avisos? No. Aunque Microsoft no clasifica el UAC predeterminado como una frontera de seguridad formal, sigue elevando el coste de muchas técnicas de escalada y aporta el evento de consentimiento del que dependen varias detecciones. Reduzca los avisos mediante un empaquetado correcto de aplicaciones y el mínimo privilegio, nunca apagando UAC.
¿Seguimos necesitando detecciones de host si tenemos un EDR fuerte? Sí. El EDR es potente pero no omnisciente, y sumar Sysmon más registros de seguridad reenviados da una fuente de evidencia independiente que sobrevive a un atacante que manipula el agente. La defensa en profundidad se aplica también a su propia visibilidad, no solo a la ruta del atacante.
Conclusión
La escalada de privilegios en Windows parece intimidante porque tiene muchas técnicas con nombre, pero desde la silla del defensor se reduce a un pequeño conjunto de configuraciones incorrectas evitables y a un pequeño conjunto de señales de alto valor. Elimine los binarios de servicio escribibles, las rutas sin comillas, los privilegios innecesarios y la política AlwaysInstallElevated, y suprimirá de raíz la mayor parte de la exposición del entorno. Reenvíe el registro de seguridad con Sysmon y su EDR, alerte sobre transiciones de integridad e instalaciones de servicio sospechosas, y valide la cobertura con pruebas autorizadas, y verá los intentos que queden. Entender el ataque solo es útil aquí en la medida en que concreta la defensa — y en Windows, la defensa está al alcance.
