Escalada de privilegios en Windows

Has conseguido ejecutar comandos en una máquina Windows, pero como un usuario cualquiera. La escalada de privilegios es el paso de esa cuenta limitada a NT AUTHORITY\SYSTEM (o a un administrador), que es quien de verdad controla el equipo. Rara vez se logra con un solo exploit mágico: casi siempre es el resultado de enumerar con paciencia y encontrar una configuración descuidada.

1. El modelo de seguridad de Windows

Para escalar hay que entender contra qué se juega. Windows identifica y autoriza así:

• SID (Security Identifier): el identificador real de cada cuenta y grupo, no el nombre. El administrador local siempre termina en -500; el grupo Administrators es S-1-5-32-544; SYSTEM es S-1-5-18.
• Token de acceso: cada proceso lleva un token que contiene el SID del usuario, sus grupos y sus privilegios. La autorización se decide mirando el token, no "quién ejecutó" el programa. Robar o suplantar un token es, literalmente, convertirse en otro usuario.
• Privilegios: capacidades con nombre (SeDebugPrivilege, SeImpersonatePrivilege, SeBackupPrivilege...). Algunos, en manos equivocadas, equivalen a ser SYSTEM. Se ven con whoami /priv.
• Niveles de integridad: Windows etiqueta procesos como Low, Medium, High o System. Un usuario normal corre en Medium; un administrador, hasta que eleva, también.
• UAC (User Account Control): aunque seas administrador, tus procesos corren en integridad Medium hasta que apruebas una elevación. Por eso "ser del grupo Administrators" y "tener un proceso administrador" no son lo mismo, y existe toda una familia de técnicas de UAC bypass.

La meta de la escalada es conseguir un token de mayor privilegio: el de un administrador o el de SYSTEM.

2. Metodología: enumerar antes de explotar

La escalada en Windows es 90% enumeración. Se recopila el estado del sistema y se buscan descuidos. A mano, los comandos base:

$ whoami /priv        # privilegios del token actual
whoami /groups      # grupos y su SID
systeminfo          # versión, parches (hotfix) para privesc por kernel
net user / net localgroup administrators

Y automatizado, el estándar del sector: winPEAS (enumeración exhaustiva que resalta en color lo explotable), PowerUp (PowerShell, orientado a servicios y rutas) y accesschk de Sysinternals (comprueba permisos concretos). No sustituyen al criterio —marcan candidatos que hay que verificar—, pero ahorran horas.

Este laboratorio te entrega precisamente una salida tipo winPEAS ya recogida: el trabajo es leerla como la leería un pentester.

3. Servicios mal configurados

Los servicios de Windows suelen correr como SYSTEM, así que son el vector más rentable. Tres fallos distintos:

3.1. Ruta sin comillas con espacios (unquoted service path)

Si la ruta del binario de un servicio tiene espacios y no está entre comillas, Windows, al arrancarlo, prueba a interpretar cada fragmento como ejecutable. Con la ruta C:\Program Files\Meridian Sync\sync service\syncsvc.exe, Windows intenta en orden:

$ C:\Program.exe
C:\Program Files\Meridian.exe
C:\Program Files\Meridian Sync\sync.exe
...

Si el atacante puede escribir en C:\ o en C:\Program Files\Meridian Sync\, coloca ahí un sync.exe (o Meridian.exe) malicioso y el servicio, que corre como SYSTEM, lo ejecutará en su lugar. La condición doble es: ruta sin comillas con espacios y permiso de escritura en una de las carpetas intermedias.

3.2. Permisos débiles del servicio

Si tu usuario tiene SERVICE_CHANGE_CONFIG sobre un servicio (lo revela accesschk), puedes reconfigurar qué binario ejecuta y reiniciarlo:

$ sc config MeridianBackup binPath= "C:\Windows\Temp\rev.exe"
sc stop MeridianBackup & sc start MeridianBackup

El servicio arranca tu binario como SYSTEM. Es de los más directos.

3.3. Permiso de escritura sobre el binario

Si puedes sobrescribir directamente el .exe del servicio, lo reemplazas por el tuyo y esperas (o fuerzas) un reinicio.

4. AlwaysInstallElevated

Es una política que permite a cualquier usuario instalar paquetes .msi con privilegios de SYSTEM. Está activa solo si las dos claves del registro valen 1:

$ reg query HKLM\...\Installer /v AlwaysInstallElevated   -> 0x1
reg query HKCU\...\Installer /v AlwaysInstallElevated   -> 0x1

Con ambas a 1, se genera un MSI malicioso (por ejemplo con msfvenom -f msi) y se instala; su carga se ejecuta como SYSTEM. Basta una de las dos en 0 para que no funcione.

5. Credenciales guardadas

Windows y sus aplicaciones dejan contraseñas por muchos rincones. Los clásicos:

Una contraseña de administrador encontrada aquí escala sin explotar nada: simplemente la usas.

6. Privilegios de token peligrosos

Ciertos privilegios en tu token equivalen a SYSTEM aunque seas un usuario normal. El más frecuente es SeImpersonatePrivilege, que tienen por defecto las cuentas de servicio (IIS, MSSQL): permite suplantar el token de un cliente que se conecte. La familia de exploits "Potato" (JuicyPotato, RoguePotato, PrintSpoofer, GodPotato) abusa de él forzando a un proceso SYSTEM a autenticarse contra ti y robando su token.

$ whoami /priv | findstr SeImpersonate   -> SeImpersonatePrivilege  Enabled
PrintSpoofer.exe -i -c cmd   # shell como SYSTEM

Otros de la misma liga: SeBackupPrivilege (leer cualquier fichero, incluido el SAM), SeRestorePrivilege, SeDebugPrivilege (inyectar en procesos SYSTEM) y SeTakeOwnershipPrivilege. Ver un privilegio de estos habilitado en whoami /priv es señal de escalada casi segura.

7. DLL hijacking

Cuando un programa carga una DLL por su nombre sin ruta completa, Windows la busca en un orden concreto de directorios. Si el programa (corriendo como SYSTEM) intenta cargar una DLL que no existe, y el atacante puede escribir en uno de los directorios donde se busca, coloca ahí una DLL maliciosa con ese nombre y el proceso privilegiado la cargará y ejecutará su código. La condición: una DLL ausente (se ve con Procmon como NAME NOT FOUND) y un directorio de búsqueda escribible.

8. Tareas programadas y autoruns

Dos vectores gemelos basados en "algo privilegiado ejecuta un fichero que tú puedes modificar":

• Tareas programadas: una tarea que corre como SYSTEM y ejecuta un script (.ps1, .bat) sobre el que tu usuario tiene permiso de modificación. Editas el script, esperas al disparador, y tu código corre como SYSTEM. Se enumeran con schtasks /query /fo LIST /v y se comprueban permisos con icacls.
• Autoruns: una entrada de arranque (clave Run del registro, carpeta Startup) que lanza un binario escribible por tu usuario cuando inicia sesión un administrador. Reemplazas el binario y esperas ese inicio de sesión.

En ambos, el patrón defensivo es el mismo: lo que ejecuta un usuario privilegiado no debe ser modificable por uno sin privilegios.

9. Escalada por kernel

Cuando la configuración está limpia, queda el propio sistema operativo: un Windows sin parchear puede ser vulnerable a un exploit de kernel (por ejemplo la familia que da SYSTEM directamente). systeminfo revela la versión y los hotfix instalados; herramientas como Watson o el propio winPEAS cruzan esa información con exploits conocidos. Es el último recurso, porque un exploit de kernel puede tumbar la máquina si falla: se prueba con cuidado y, a ser posible, en una réplica primero (módulo 10).

Autoevaluación

1. ¿Por qué la autorización en Windows depende del token del proceso y no de "quién lo ejecutó"?
2. ¿Qué dos condiciones deben darse a la vez para explotar una ruta de servicio sin comillas?
3. ¿Por qué AlwaysInstallElevated necesita las dos claves del registro a 1?
4. Ves SeImpersonatePrivilege habilitado en tu token. ¿Qué familia de exploits te viene a la cabeza y por qué?
5. ¿Qué hace explotable a una tarea programada que corre como SYSTEM?
6. ¿Por qué un exploit de kernel es el último recurso de una escalada?
7. Ser miembro del grupo Administrators no es lo mismo que tener un proceso con privilegios de administrador. ¿Por qué?