Objectif

  • Identifier méthodiquement les possibilités d’escalade de privilèges.
  • Ne rater aucune piste classique (sudo, SUID, cron, services).
  • Comprendre pourquoi une élévation est possible avant de tenter une exploitation.

Prérequis

  • Un accès shell sur une machine Linux (CTF / HTB).
  • La possibilité de transférer ou d’exécuter des outils d’énumération locaux.
  • Un compte utilisateur non-root.

Préparation des outils d’énumération

Avant de lancer l’analyse, installe les outils nécessaires sur ta machine Kali et transfère-les vers la cible.

Outils recommandés :

Avec l’aide de la recette « Copier des fichiers depuis et vers Kali Linux » , transfère-les vers :

  • /dev/shm (mémoire volatile, souvent discret)
  • /tmp

Pourquoi /dev/shm ou /tmp ?

  • Écriture autorisée pour l’utilisateur
  • Nettoyage automatique au reboot
  • Moins intrusif que /home
  • Standard en CTF

Une fois sur la machine cible, rends-les exécutables :

cd /dev/shm
chmod +x linpeas.sh
chmod +x pspy64
chmod +x les.sh

Méthode structurée

La recherche d’une voie d’escalade commence toujours par la vérification de sudo, puis se poursuit avec les autres pistes simples avant de passer à des vérifications plus spécifiques.

pspy64 peut être lancé en parallèle, dans une deuxième session SSH, afin d’observer l’activité de la machine sans modifier le déroulement principal de l’énumération.

Observation passive avec pspy64

pspy64 est un outil facultatif, mais très utile pour observer ce qui se passe sur la machine pendant que tu poursuis ton énumération manuelle.

Pour cele, ouvre une deuxième session SSH et lance pspy64 :

./pspy64

Tu peux alors le laisser tourner pendant que, dans ta session principale, tu examines sudo, les SUID, les capabilities, les services locaux et les autres pistes d’escalade.

pspy64 fonctionne en observation passive : il peut révéler des processus qui apparaissent périodiquement sans que tu les déclenches toi-même, par exemple :

  • des tâches cron ;
  • des scripts exécutés automatiquement ;
  • des commandes lancées par root ;
  • des processus qui n’apparaissent que brièvement.

Points à surveiller

Porte particulièrement ton attention sur :

  • les commandes exécutées avec UID=0 ;
  • les scripts appelés par root (bash, sh, python, php…) ;
  • les chemins ou fichiers utilisés par ces scripts ;
  • les exécutions qui se répètent régulièrement.

Une exécution lancée par root devient intéressante si ton utilisateur peut, par exemple :

  • modifier le script exécuté ;
  • modifier un fichier qu’il charge ;
  • contrôler un chemin utilisé par le script ;
  • influencer son comportement.

pspy64 ne remplace toutefois pas l’analyse manuelle. Il sert surtout à attirer ton attention sur une activité que tu n’aurais pas forcément observée au bon moment.

Vérifications complémentaires

Les observations de pspy64 peuvent ensuite t’amener à vérifier manuellement certains mécanismes, notamment :

  • les tâches planifiées :
    • /etc/crontab
    • /etc/cron*
    • systemctl list-timers
  • les scripts exécutés à l’ouverture d’une session :
    • .bashrc
    • .profile
    • /etc/profile
    • /etc/bash.bashrc

Tu peux donc simplement laisser pspy64 tourner dans une deuxième session pendant toute ton investigation.

Sur un système 32 bits, utilise plutôt :

./pspy32

Vérification sudo

sudo -l

Points clés :

  • NOPASSWD
  • Commandes exécutables en root
  • Binaires custom
  • Scripts modifiables
  • Variables d’environnement autorisées

Si une commande exploitable apparaît ici, c’est prioritaire.

Exploration du contexte utilisateur

Commence toujours par comprendre où tu te trouves.

whoami
id
pwd
uname -a
hostname

À analyser :

  • Ton utilisateur
  • Les groupes
  • La version du noyau
  • Indices de containerisation
  • Architecture (utile pour les binaires 32/64 bits)

Avant de poursuivre l’analyse, tu vérifies également quels fichiers sont accessibles à l’utilisateur ssh_user, en particulier dans /home et /opt, deux emplacements qui contiennent fréquemment des scripts internes, fichiers de configuration, sauvegardes ou outils personnalisés utiles pour une escalade de privilèges.

Commande rapide :

find /home /opt -type f -readable 2>/dev/null

Tu peux aussi chercher les répertoires accessibles en écriture par l’utilisateur courant. Cela permet de repérer des emplacements où un fichier pourrait être créé ou modifié, notamment dans le cadre d’un script exécuté automatiquement, d’un chemin mal protégé ou d’un répertoire temporaire oublié.

find / -writable -type d 2>/dev/null | grep -vE '^/proc|^/sys|^/dev|^/run'

Permissions spéciales (Capabilities & SUID)

Capabilities

getcap -r / 2>/dev/null

Cherche :

  • cap_setuid
  • cap_setgid
  • cap_sys_admin
  • Tout binaire inattendu

SUID avec suid3num.py

python3 suid3num.py

Ou :

find / -perm -4000 -type f 2>/dev/null

Analyse :

  • Binaires inhabituels
  • Scripts root modifiables
  • PATH hijacking possible

Pour chaque binaire suspect, vérifie sur GTFOBins.

Astuce CTF Après l’exécution de getcap -r / 2>/dev/null ou/et de suid3num.py, consulte GTFOBins pour chaque binaire suspect afin de vérifier s’il existe une technique d’exploitation connue.

Services locaux

Avant de lancer un outil automatique, vérifie les services internes.

Avec ss (recommandé)

ss -tulnp

Alternative :

netstat -tulnp

À analyser attentivement

  • Services écoutant uniquement sur 127.0.0.1
  • Ports inhabituels (3000, 5000, 8000, 8080, 9000…)
  • Processus exécutés avec les privilèges root
  • Bases de données locales
  • Interfaces web internes

L’objectif est d’identifier un service exposé uniquement en local, pouvant constituer un point d’entrée secondaire.

Pourquoi c’est intéressant ?

Un service local peut :

  • Être accessible via un tunnel SSH (port forwarding)
  • Contenir une vulnérabilité exploitable
  • Fonctionner en mode debug
  • Être mal configuré
  • Exécuter du code avec des privilèges élevés

Accès via tunnel SSH

Un service bind sur 127.0.0.1 n’est pas accessible directement depuis l’extérieur, mais tu peux le rendre accessible via un tunnel SSH (port forwarding).

Exemple :

Si un service écoute sur 127.0.0.1:8080 :

ssh -L 8080:127.0.0.1:8080 user@target

Ensuite, depuis ta machine Kali :

http://localhost:8080

Cela te permet d’analyser une interface interne (web, API, admin…) qui n’est normalement pas exposée.

Identifier le service derrière un port

Une fois un port intéressant identifié, il est essentiel de comprendre quel service l’utilise réellement.

Une méthode simple consiste à rechercher ce port dans les fichiers de configuration :

grep -r ':8080' /etc 2>/dev/null

(adapte 8080 au port identifié, par exemple 5000, 3000, 9898…)

Ce que tu peux trouver :

  • Fichiers de configuration (nginx, apache, gunicorn…)
  • Services systemd
  • Scripts internes
  • Chemins d’applications

Cela permet souvent de :

  • Identifier le service exact
  • Trouver son répertoire d’exécution
  • Découvrir des identifiants ou chemins sensibles
  • Comprendre comment il est lancé (et avec quels privilèges)

Tu peux également élargir la recherche :

grep -r '5000' /etc 2>/dev/null

Cela permet parfois de trouver des références au port même sans le préfixe :.

Méthode pratique à retenir

Quand tu identifies des services accessibles uniquement sur 127.0.0.1, commence généralement par prioriser les ports web les plus courants :

3000
5000
8000
8080
9000

Ces ports hébergent fréquemment des interfaces d’administration, dashboards internes, API locales ou outils de supervision potentiellement exploitables.

Linpeas — Énumération approfondie

Si les vérifications manuelles de la méthode structurée n’ont révélé aucune piste exploitable, passe à une énumération approfondie avec Linpeas.

./linpeas.sh

Linpeas réalise une analyse locale complète du système et met en évidence les pistes potentielles de privilege escalation.

Dans Linpeas, les vulnérabilités potentielles sont classées et surlignées par couleur.

Légende des couleurs de LinPEAS indiquant le niveau de criticité des vulnérabilités

Ce que Linpeas peut révéler

  • Mauvaises permissions
  • Fichiers sensibles accessibles en lecture
  • Services internes exposés
  • Binaires SUID suspects
  • Capabilities dangereuses
  • Tâches cron
  • Variables d’environnement sensibles
  • Mauvaises configurations sudo
  • Indices de containerisation
  • Vulnérabilités kernel potentielles

Comment utiliser Linpeas efficacement

Utilise Linpeas comme un outil de corrélation, pas comme une solution automatique.

Linpeas ne “donne” pas l’escalade : il met en évidence des anomalies que tu dois ensuite analyser manuellement.

Comment analyser la sortie

N’essaie pas de tout lire d’un bloc.

Travaille méthodiquement :

  • Repère les sections en rouge et en jaune → ce sont les éléments les plus intéressants.
  • Compare avec ton énumération manuelle → sudo, SUID, services locaux, fichiers trouvés…
  • Identifie les chemins modifiables → scripts, dossiers, fichiers accessibles en écriture.
  • Analyse les fichiers appartenant à root → surtout s’ils sont lisibles ou modifiables.
  • Cherche une incohérence exploitable → un service root lié à un fichier modifiable, par exemple.

Interpréter les résultats

  • Si Linpeas confirme une piste que tu avais déjà identifiée → ta piste est probablement la bonne
  • S’il révèle un élément nouveau → prends le temps de comprendre le mécanisme avant de tester quoi que ce soit

Dans la majorité des cas, l’escalade repose sur une mauvaise configuration, pas sur une exploitation complexe.

Bonnes pratiques en CTF

  • Lance Linpeas après l’énumération manuelle
  • Ne te base jamais uniquement sur la couleur des résultats
  • Croise toujours avec ce que tu as déjà observé
  • Garde une approche logique : compréhension → validation → exploitation
  • Supprime l’outil après utilisation si nécessaire (/tmp, /dev/shm)

Bien utilisé, Linpeas te fait gagner du temps

Mal utilisé, il te noie dans les informations



L’objectif reste toujours le même : comprendre le système avant d’exploiter.

Dernier recours : le kernel

Quand toutes les pistes logiques ont été explorées, il reste une possibilité : le noyau.

Examine la version du noyau :

uname -a

Puis teste avec les.sh pour identifier une vulnérabilité potentielle.

Un exploit kernel doit rester un dernier recours, après avoir exploré toutes les pistes liées à la configuration du système.

Dans la majorité des machines CTF (surtout Easy/Medium), l’escalade repose sur une mauvaise configuration et non sur une vulnérabilité kernel.

Avant toute tentative :

  • Vérifie précisément la version du noyau
  • Confirme la compatibilité de l’exploit
  • Comprends le mécanisme d’élévation

Une bonne privilege escalation privilégie toujours les erreurs de configuration avant les exploits noyau.

Checklist rapide

  1. whoami / id / pwd / uname
  2. sudo -l
  3. getcap
  4. suid3num.py
  5. ss -tulnp / netstat -tulpn
  6. linpeas.sh
  7. pspy64 en parallèle
  8. En dernier recours : analyser le kernel

Philosophie

  • Toujours comprendre avant d’exploiter.
  • Croiser les résultats entre outils.
  • Noter chaque anomalie pour le writeup.
  • Privilégier les vecteurs simples avant les exploits kernel.
  • Appliquer une méthode reproductible sur chaque machine CTF.

Une bonne privilege escalation est structurée, reproductible et documentée.