Cerramos el Módulo 4 con uno o varios footholds en TechNova, casi siempre con privilegios limitados: una shell como www-data en la tienda, un usuario de servicio en el servidor interno Linux, una cuenta sin permisos en una estación Windows. La pregunta que abre el Módulo 5 —¿hasta dónde llega realmente este compromiso?— empieza a responderse aquí. La escalada de privilegios es el paso que convierte un acceso menor en control total del host: de www-data a root, de un usuario de dominio corriente a Administrador o SYSTEM. Sin este salto, muchos hallazgos parecen inofensivos; con él, un fallo "menor" se demuestra como un compromiso completo.

El encuadre no se relaja, al contrario. La post-explotación es el punto donde un pentest profesional se distingue de un manual de abuso. Todo ocurre en el laboratorio autorizado de TechNova, dentro del scope y las Reglas de Enfrentamiento (RoE). La escalada tiene un único fin: medir y demostrar el impacto real para el informe del Módulo 6, no perjudicar a nadie. Y la regla de oro que repetiremos en cada lección de este módulo: el pentester documenta cada acción y cada artefacto que crea, y lo revierte al terminar. Aquí, además, cada técnica ofensiva va acompañada de su remediación, porque el objetivo es que TechNova cierre el hueco, no coleccionar rutas a root.

1. Qué es la escalada de privilegios y por qué importa
2. Escalada vertical vs. horizontal
3. Enumeración: el 90% del trabajo (linPEAS/winPEAS)
4. Vectores en Linux
5. Vectores en Windows
6. PoC de bajo impacto y captura de evidencia
7. Contrapartida: hardening y mínimo privilegio
8. Errores comunes y consejos
9. Ejercicios
10. Conclusión

Escalar privilegios es pasar del nivel de acceso que da el foothold a uno superior. Importa por tres razones que van directas al informe:

• Mide el impacto real. Un RCE como www-data es serio; el mismo RCE que acaba en root significa control del servidor, sus datos y sus credenciales. La diferencia es la que el cliente necesita para priorizar.
• Habilita todo lo demás. Con privilegios altos se accede a hashes de credenciales, configuraciones y otros hosts. La persistencia (05-02) y el pivoting (05-03) suelen requerir este paso.
• Revela fallos de hardening. Cada vía de escalada es una mala configuración concreta y corregible: un SUID de más, un sudo demasiado permisivo, un servicio con permisos débiles.

Dos movimientos distintos que conviene no confundir:

La escalada horizontal parece menos grave, pero a menudo es el trampolín: la cuenta de contable puede tener acceso a datos sensibles o a un sudo que la de devapp no tenía. Ambas se documentan. Y ojo: moverse a otra máquina ya no es escalada, es movimiento lateral —eso es 05-03, no lo cubrimos aquí.

La escalada rara vez es un exploit espectacular; casi siempre es encontrar la mala configuración que ya está ahí. Por eso la fase reina es la enumeración local desde el foothold: entender el sistema desde dentro. Se automatiza con scripts especializados que revisan cientos de comprobaciones conocidas.

Estos scripts resaltan los hallazgos interesantes (en linPEAS, en rojo/amarillo). No sustituyen al criterio: hay que entender por qué cada hallazgo es explotable. Nota profesional: linPEAS/winPEAS son ruidosos y los detecta cualquier EDR decente —lo cual, en un pentest, es también información útil: si el SOC de TechNova no salta, es un hallazgo defensivo por sí mismo.

Los caminos clásicos de usuario a root en un host Linux. Cada uno con qué lo hace explotable y cómo se remedia.

SUID — el vector más didáctico. Un binario con el bit SUID se ejecuta con los privilegios de su propietario, no de quien lo lanza. Si ese propietario es root y el binario permite ejecutar comandos (o leer/escribir ficheros arbitrarios), tenemos root. El proyecto GTFOBins cataloga qué binarios comunes son abusables así.

La salida uid=0(root) es la prueba. No abrimos una shell root persistente ni tocamos /etc/shadow: demostrar la escalada basta para el informe. Remediación: ese find nunca debió tener SUID; se retira con chmod u-s /usr/bin/find y se audita el resto.

sudo mal configurado. Se revisa con sudo -l. Si aparece algo como (root) NOPASSWD: /usr/bin/vim, es explotable: vim permite lanzar una shell desde dentro, así que ejecutarlo como root da root. Remediación: conceder por sudo solo comandos que no permitan escape a shell, con argumentos concretos, evitando comodines.

En Windows el objetivo suele ser SYSTEM o Administrador. Los caminos cambian de nombre pero la lógica —una configuración débil que da más de lo debido— es idéntica.

Ejemplo — permisos de servicio débiles. Si un servicio corre como SYSTEM y nuestra cuenta puede reconfigurar su binario, podemos hacer que ejecute algo nuestro con privilegios SYSTEM.

El fichero poc.txt con nt authority\system demuestra la ejecución como SYSTEM. Inmediatamente después se restaura el binPath original (lo anotamos antes de tocarlo) para no dejar el servicio roto: revertir es obligatorio. Remediación: corregir la ACL del servicio para que usuarios normales no puedan reconfigurarlo; auditar con accesschk.

Credenciales a alto nivel. Ya con privilegios de administrador, un atacante volcaría secretos de la memoria del proceso LSASS (herramientas tipo Mimikatz) o de configuraciones inseguras. Aquí solo lo nombramos como impacto a documentar: el uso de esas credenciales para saltar a otros hosts es movimiento lateral (05-03), no escalada.

El principio de todo el módulo: demostrar, no destruir. Una PoC de escalada correcta:

• Ejecuta la mínima acción que prueba el privilegio: id (Linux) o whoami (Windows), con hora y hostname.
• No abre backdoors, no toca datos sensibles, no deja shells root permanentes.
• Revierte cualquier cambio temporal (un binPath alterado, un fichero de PoC): se restaura el estado y se anota en la bitácora.
• Captura evidencia clara para el Módulo 6: comando, salida (uid=0/SYSTEM), marca de tiempo, y el vector concreto (qué SUID, qué regla sudo, qué servicio).

El mensaje que llevará el informe a TechNova. Casi todas las vías de escalada son configuración, no fallos irreparables:

• Mínimo privilegio en todo: servicios con el menor privilegio posible, usuarios sin sudo innecesario, cuentas de administrador separadas del uso diario.
• Auditar SUID/capabilities/servicios: revisiones periódicas de find -perm -4000, getcap -r /, ACL de servicios; retirar todo lo que no tenga justificación.
• sudo restringido: reglas específicas, sin comodines, sin binarios con escape a shell.
• Parcheo del kernel y del SO: cierra los exploits locales de escalada.
• Windows moderno: LAPS (contraseñas de administrador local únicas y rotadas), Credential Guard, UAC alto, permisos NTFS correctos.
• Detección: EDR y monitorización de creaciones de procesos anómalas, cambios de configuración de servicios, ejecución de linPEAS/winPEAS o de herramientas conocidas.

• Saltar a un kernel exploit primero. Son los más propensos a tumbar el host (kernel panic = denegación de servicio no acordada). Agota antes SUID, sudo, cron y servicios; deja el kernel para el final y solo con acuerdo.
• No revertir un cambio temporal. Dejar un binPath alterado o un servicio parado es romper producción y saltarse la regla de oro. Anota el estado antes de tocar y restáuralo siempre.
• Escalar y ponerse a hurgar en datos. La PoC termina en uid=0/SYSTEM. Leer nóminas o correos excede la demostración salvo que el RoE lo pida explícitamente.
• Confundir escalada horizontal con "no grave". Moverse a otra cuenta del mismo nivel suele ser el trampolín a root o a datos sensibles; documéntala.
• Reportar la vía sin la remediación. "Se escaló a root" sin decir qué SUID o qué regla sudo lo permitió no le sirve al cliente. El valor está en el arreglo concreto.
• Olvidar que linPEAS/winPEAS son ruidosos. Si el EDR no los detecta, eso también es un hallazgo (defensa insuficiente) que va al informe.
• Consejo: enumera exhaustivamente antes de intentar nada. El 90% de las escaladas están servidas en la salida de linPEAS/winPEAS si sabes leerla.

Ejercicio 1. Desde tu foothold como www-data en la tienda de TechNova, find / -perm -4000 revela que /usr/bin/find tiene SUID root. Explica por qué eso permite escalar, escribe una PoC de bajo impacto que solo demuestre el privilegio, y da la remediación exacta. ¿Cómo detectaría el equipo azul este abuso?

Ejercicio 2. En una estación Windows tienes una cuenta de usuario normal. accesschk muestra que puedes reconfigurar un servicio que corre como SYSTEM. Describe la secuencia de escalada respetando el control de impacto y la reversión, qué evidencia capturarías y dos medidas de hardening que lo habrían impedido.

Ejercicio 3. Distingue, con un ejemplo de TechNova cada uno, escalada vertical y horizontal, y explica por qué la horizontal, aunque parezca menos grave, se documenta igual. Indica además dónde termina la escalada y qué ya sería materia de la lección 05-03.

Solución 1. find con SUID root se ejecuta con privilegios de su propietario (root), y find permite lanzar comandos con -exec; por tanto puede ejecutar cualquier orden como root. PoC de bajo impacto (según GTFOBins), demostrando solo el privilegio: find . -exec /bin/sh -p -c 'id' \;, cuya salida uid=0(root) es la prueba —no se abre shell persistente ni se tocan ficheros. Remediación: ese find nunca debió tener SUID; se retira con chmod u-s /usr/bin/find y se auditan periódicamente los binarios SUID con find / -perm -4000. Detección (equipo azul): la auditoría del kernel (auditd) o el EDR alertan ante un proceso hijo /bin/sh con EUID 0 lanzado por find desde una cuenta sin privilegios, un patrón anómalo característico del abuso de SUID.

Solución 2. Secuencia: (1) confirmar con accesschk que el servicio es reconfigurable por nuestra cuenta; (2) anotar el binPath original antes de tocar nada; (3) reconfigurarlo temporalmente a un comando inocuo (cmd /c whoami > C:\Windows\Temp\poc.txt); (4) reiniciar el servicio y leer poc.txt, que muestra nt authority\system como prueba de ejecución con privilegios SYSTEM; (5) restaurar de inmediato el binPath original con sc config y borrar poc.txt, anotándolo en la bitácora. Evidencia: el whoami como SYSTEM, hora y nombre del servicio afectado. Hardening que lo habría impedido: (a) corregir la ACL del servicio para que los usuarios normales no puedan reconfigurarlo; (b) aplicar mínimo privilegio y auditar servicios con accesschk de forma periódica.

Solución 3. Vertical: de www-data (usuario de servicio) a root en el servidor de la tienda —se sube de nivel de privilegio—. Horizontal: de devapp a la cuenta contable, ambos usuarios normales sin privilegios de root —se pasa de una cuenta a otra del mismo nivel—. La horizontal se documenta porque suele ser el trampolín: contable puede tener acceso a datos sensibles o una regla sudo que devapp no tenía, habilitando después una escalada vertical. La escalada termina en el control del host (root/SYSTEM en esa máquina); usar las credenciales o el acceso obtenidos para saltar a otras máquinas de la red 10.10.10.0/24 ya es movimiento lateral (05-03), fuera del alcance de esta lección.

Hemos dado el primer paso de la post-explotación: convertir un foothold con privilegios limitados en control del host. Vimos la diferencia entre escalada vertical y horizontal; que el grueso del trabajo es enumerar (linPEAS/winPEAS) para encontrar la mala configuración que ya está ahí; y recorrimos los vectores clásicos en Linux (SUID, sudo, cron, capabilities, PATH, kernel) y en Windows (servicios, tokens, UAC, credenciales), cada uno con una PoC de bajo impacto que solo demuestra el privilegio, con reversión de todo cambio temporal y su remediación concreta. La contrapartida fue constante: mínimo privilegio, hardening y parcheo, con detección por EDR.

Ya somos root/SYSTEM en uno o varios hosts de TechNova, con la evidencia capturada. La siguiente pregunta natural del atacante —y por tanto del pentester que mide su capacidad— es cómo conservar ese acceso sin tener que reexplotar cada vez. Eso es 05-02 Mantenimiento del Acceso: los mecanismos de persistencia, pero entendidos como demostración de impacto en un engagement autorizado, con la contrapartida defensiva en primer plano y la regla de oro más presente que nunca: todo lo que se crea, se documenta y se revierte.