Metasploit au cœur de la sécurité offensive : Du scan à la post-exploitation

Pour devancer un attaquant, il faut apprendre à penser comme lui : c’est cette philosophie fondamentale du hacking éthique qui a donné naissance à des outils phares comme Metasploit. Identifier les failles d’un système avant qu’elles ne soient exploitées exige de les détecter soi-même et de mesurer concrètement leur impact. C’est tout l’enjeu des tests d’intrusion. Dès lors, jusqu’où Metasploit peut-il vous accompagner ? Quelle est la véritable portée de cet outil, et peut-il prétendre au rôle de couteau suisse ultime tout au long d’une chaîne d’attaque ?

I.                   Présentation, utilité de l’outil et atouts

Développé en Ruby, le projet Metasploit voit le jour en 2003 (initialement lancé en 2003, puis réécrit en Ruby en 2007) en tant qu’ensemble d’outils de sécurité open source dédié à la réalisation de tests d’intrusion sur des systèmes cibles. Il est ensuite racheté en 2009 par l’entreprise américaine de cybersécurité Rapid7.

À l’instar de nombreuses solutions dont le modèle économique repose sur l’open source, Metasploit se décline en deux versions principales :

  • Metasploit Framework : la version libre et gratuite, dont le code source reste accessible à tous et s’enrichit grâce à l’apport d’une communauté active ;
  • Metasploit Pro : la version commerciale payante, proposant des fonctionnalités avancées, de l’automatisation et un support dédié.

Couvrant l’intégralité d’une chaîne d’attaque classique — de la phase de reconnaissance jusqu’à la post-exploitation —, Metasploit s’impose comme un framework particulièrement complet. Si cette polyvalence constitue son principal atout, elle ne nuit en rien à ses capacités d’interopérabilité, d’évolutivité et de personnalisation.

Atout 1 : interopérabilité et polyvalence dans la chaîne d’exécution d’une attaque 

1.1. Des outils de reconnaissance non négligeables déjà à portée

Metasploit Framework dispose déjà en son sein de nombreux outils de reconnaissance et d’analyse des cibles. Ils permettent notamment de dresser une carte du réseau informatique et de ses composants, ainsi que de recueillir des informations sur une machine cible (ports ouverts, services en cours d’exécution, vulnérabilités potentielles, entre autres).

Il faudra tout de même remarquer qu’en les comparant à des solutions spécialisées comme theHarvester, ces outils embarqués pourront se révéler limités ou basiques. Tout dépendra toutefois du projet, d’autant plus que Metasploit Framework a la capacité d’exploiter directement les données générées par des outils de reconnaissance tiers.

1.2. Interopérabilité et exploitation des données de reconnaissance

Metasploit s’intègre parfaitement à d’autres outils. L’énumération des correctifs Windows et l’analyse SNMP, qui interviennent lors de la phase de collecte d’informations, y figurent en bonne place. Il peut également servir de passerelle vers Nessus, le scanner de vulnérabilités de Tenable.

Par ailleurs, il est compatible avec la quasi-totalité des outils de reconnaissance grâce au respect de certains standards dans le formatage des fichiers de résultats. Le format XML est plébiscité à cet effet, permettant de conduire une analyse plus poussée et de mieux préparer son armement.

1.3. Armement (création de charges) et Exploitation des vulnérabilités

La phase d’armement dans la chaîne d’exécution d’une attaque sous Metasploit est émaillée de deux expressions dont il convient de bien maîtriser les contours : l’exploit et le payload (ou charge utile).

Un exploit est un code qui tire parti d’une vulnérabilité précise afin d’obtenir un effet sur une cible. Il désigne également la méthode par laquelle on tire profit d’une vulnérabilité découverte lors de la phase de reconnaissance en amont.

Une vulnérabilité est une faiblesse dans un logiciel, un matériel, un protocole, une configuration, une architecture ou tout autre système qui permettrait, si elle venait à être exploitée, d’en compromettre la sécurité.

L’exploit offre ainsi le moyen d’entrer dans un système en se servant de l’une de ces faiblesses. En d’autres termes, on procède à l’exploitation d’une vulnérabilité, puis intervient le payload.

La charge utile (ou payload) représente concrètement l’action que l’on souhaite effectuer une fois l’exploit réussi. C’est-à-dire qu’une fois l’accès au système effectué, que souhaiterait faire un attaquant ou un testeur d’intrusion ?

Ces actions sont structurées sous forme de code, soit une série d’instructions à exécuter une fois l’accès obtenu. Comme nous le verrons plus bas, certains payloads sont proposés par défaut sous forme de modules au sein du framework, mais il est également possible de concevoir ses propres charges utiles via les mécanismes prévus à cet effet.

1.4. Post-exploitation, Persistance, exfiltration, mouvement latéral et autres manœuvres

Une fois la machine cible compromise, Metasploit propose une suite complète d’outils de post-exploitation, enrichie chaque année de nouvelles fonctionnalités. Parce que les actions courantes intervenant après l’exploitation (post-exploitation) se rapportent souvent à la persistance, l’exfiltration ou le mouvement latéral, les modules Metasploit offrent la possibilité de ne pas se faire repérer, d’obfusquer sa charge utile afin de lui donner un aspect qui n’éveillerait pas les soupçons, et bien plus encore.

Il est notamment possible de créer une porte dérobée qui reste active même après un redémarrage. Après l’intrusion initiale, un attaquant peut chercher à garder le contrôle du système cible indépendamment des redémarrages, des changements de contexte ou de la fin de la session initiale. C’est en ce sens qu’intervient la notion de persistance.

L’exfiltration consiste à transférer vers l’extérieur du périmètre visé — c’est-à-dire vers l’infrastructure de l’attaquant ou une alternative choisie par lui — des données obtenues lors de l’intrusion. Il peut s’agir de fichiers de bases de données, de documents, de fichiers de configuration, de hashes de mots de passe, de clés, d’e-mails, et bien d’autres. Des mécanismes comme la mise en place de canaux chiffrés, la compression et le chiffrement de données peuvent, le cas échéant, être mis en œuvre via des modules du framework Metasploit.

Les mouvements latéraux permettent de se déplacer au sein d’un réseau afin d’élargir l’attaque à d’autres cibles, d’atteindre un système plus spécifique ou plus critique, susceptible de permettre par exemple une élévation de privilèges. Les privilèges les plus importants sont notamment les droits d’administration (ou privilèges administrateur), parfois SYSTEM utilisés par les composants système et pouvant donné libre accès au noyau.

Parmi les autres fonctionnalités figurent l’analyse de paquets, la capture d’écran, les enregistreurs de frappe (keyloggers), un fuzzer pour identifier les failles de sécurité potentielles dans les fichiers binaires, ainsi qu’une gamme croissante de modules auxiliaires.

Atout 2 : Evolutivité et personnalisation

Metasploit possède une architecture modulaire qui permet à chacun de créer de nouveaux modules. Cette modularité est essentielle pour réutiliser et étendre les fonctionnalités du framework.

Elle simplifie la création de vos propres exploits ou charges utiles — si vous en avez les compétences — tout en vous évitant de vous exposer à du code de qualité douteuse glané ici et là.

Pour enrichir cet écosystème, des outils gratuits existent, à l’instar de Metasploitable : une machine virtuelle Linux volontairement vulnérable conçue pour tester Metasploit ou vos modules sur mesure, sans aucun risque pour des systèmes réels.

Autres atouts 

L’organisation des outils et la documentation sont des éléments essentiels dans l’utilisation de Metasploit. L’une de ses caractéristiques majeures réside dans son système de classement des exploits (ranking), qui évalue la fiabilité et l’efficacité de chaque module. Les attaquants privilégient généralement les exploits les mieux notés : jugés plus stables, ils offrent un meilleur taux de réussite tout en réduisant le risque de détection.

II.                Les principaux modules leurs fonctionnalités

Le framework Metasploit réunit un large éventail d’outils permettant aux testeurs d’intrusion d’identifier des vulnérabilités, de mener des attaques et d’échapper à la détection. Variés et complémentaires au sein d’une chaîne d’attaque, ces outils constituent une base de travail solide pour quiconque souhaite mettre un système informatique à rude épreuve.

Un module est un composant logiciel dédié à une tâche spécifique. À ce titre, Metasploit en intègre plusieurs types.

A.    Points d’entrée console / GUI d’orchestration 

A.1. MSFconsole

Tout commence ici. Msfconsole est l’interface en ligne de commande (CLI) principale de Metasploit. C’est elle qui permet de mener l’analyse des systèmes à la recherche de vulnérabilités, d’effectuer des reconnaissances réseau, d’exécuter des exploits, et bien plus encore. Elle offre toutes les commandes nécessaires pour interagir avec le framework, ainsi que la complétion automatique.

A.2. Armitage

Contrairement à msfconsole, Armitage est une interface graphique (GUI) basée sur Java. Son principal atout réside dans sa capacité à visualiser les cibles et à recommander des exploits. Cet outil est également scriptable, ce qui permet d’automatiser les tâches répétitives comme la découverte d’hôtes. Il se distingue particulièrement dans les environnements comportant un grand nombre de systèmes.

B.     Modules d’exploitation 

Les modules d’exploitation permettent aux testeurs de cibler une vulnérabilité spécifique connue. Après l’analyse de la cible, un large éventail de modules montre tout son intérêt, tels que les dépassements de tampon ou les injections SQL.

Chacun de ces modules peut embarquer une charge utile (payload) qui s’exécute une fois l’exploit réussi. Pour se faire une idée, nous présentons à ce jour, sur la base de la littérature technique disponible, les cinq modules les plus courants par sous-catégorie :

B.1. Distance & Infrastructure (Remote Code Execution – RCE)

Modules ciblant directement les services réseau et les composants système exposés.

B.1.1. exploit/windows/smb/ms17_010_eternalblue

Ce module exploite la vulnérabilité SMBv1 (CVE-2017-0144), connue sous le nom d’EternalBlue. Son mode opératoire consiste à corrompre la mémoire du service SMBv1, ce qui permet l’exécution de code à distance (RCE) sans authentification, avec les privilèges SYSTEM sur les systèmes Windows impactés.

B.1.2. exploit/multi/samba/usermap_script

Il exploite la vulnérabilité Samba (CVE-2007-2447), dont le principe repose sur un défaut de neutralisation des entrées dans la directive username map script. L’injection de métacaractères non échappés permet d’obtenir un accès root direct sur le système cible.

Pour rappel, Samba est une suite logicielle permettant aux systèmes Linux/Unix de partager des fichiers et des imprimantes avec des clients Windows via le protocole SMB/CIFS, s’intégrant ainsi de manière transparente dans les réseaux hétérogènes.

B.1.3. exploit/windows/smb/ms08_067_netapi

Exploite la vulnérabilité NetAPI / CVE-2008-4250.

À l’instar d’EternalBlue (MS17-010), la faille MS08-067 liée au service NetAPI est un monument de la cybersécurité qui a marqué les esprits. Elle permettait une exécution de code à distance via un dépassement de tampon classique dans le service Server (netapi32.dll), s’exécutant directement avec les privilèges maximaux dans le processus svchost.exe sous Windows XP et Server 2003.

Aujourd’hui, cette faille est corrigée depuis octobre 2008 (patch hors-cycle émis par Microsoft). Elle ne subsiste que sur des systèmes obsolètes non mis à jour (Windows XP, Windows Server 2003) ou isolés.

B.1.4. exploit/windows/rdp/cve_2019_0708_bluekeep

Il exploite la vulnérabilité RDP (CVE-2019-0708), plus connue sous le nom de BlueKeep.

Il s’agit d’une faille de type Use-After-Free pré-authentification dans la gestion des canaux virtuels du protocole RDP (Remote Desktop Protocol), permettant une exécution de code à distance (RCE) au niveau du noyau (kernel).

En d’autres termes, cette vulnérabilité permet à un attaquant non authentifié d’envoyer des requêtes RDP spécialement conçues pour exécuter du code arbitraire sur le système cible, en obtenant le niveau de privilège le plus élevé.

B.1.5. exploit/linux/samba/is_known_pipename

is_known_pipename est un module qui exploite la vulnérabilité Samba (CVE-2017-7494), communément appelée SambaCry.

Une fois de plus liée au service de partage de fichiers Samba, cette faille permet à un utilisateur disposant d’un accès en écriture sur un partage d’y téléverser une bibliothèque partagée (fichier .so), puis de forcer le serveur à la charger, exécutant ainsi du code arbitraire avec les privilèges root.

B.2. Applications Web & Middleware

Modules ciblant les serveurs web, les CMS, les serveurs d’applications et les interfaces de gestion.

B.2.1. exploit/multi/http/log4shell_header_injection

Application cible : Java Log4j2 / CVE-2021-44228.

Log4Shell est une faille dans la bibliothèque de journalisation Log4j. Elle se traduit par l’injection des expressions JNDI dans les en-têtes HTTP (User-Agent, X-Forwarded-For) pour déclencher une exécution de code via LDAP/RMI.

Concrètement, un attaquant envoie des données spécialement conçues dans des en-têtes HTTP (par exemple User-Agent ou X-Forwarded-For). Log4j peut alors ‘interpréter’ ces données comme une demande JNDI et essayer d’aller chercher ailleurs (via LDAP ou RMI).

En conséquence, l’application peut charger du contenu contrôlé par l’attaquant et finir par exécuter du code à distance sur le serveur.

B.2.2. exploit/multi/http/struts2_content_type_oqnl

Application cible : Apache Struts2 / CVE-2017-5638.

Apache Struts 2 est un framework open source Java basé sur le modèle MVC (Modèle-Vue-Contrôleur), conçu pour faciliter et accélérer le développement d’applications web d’entreprise robustes et évolutives.

La vulnérabilité CVE-2017-5638 mise en cause se traduit par une gestion incorrecte de l’en-tête Content-Type permettant l’évaluation d’expressions OGNL arbitraires et l’exécution de commandes système.

En effet, quand l’application reçoit une requête HTTP, elle gère mal l’en-tête Content-Type. Du coup, un attaquant peut faire croire à Struts2 qu’il doit traiter une expression OGNL fournie par l’attaquant.

OGNL signifie Object-Graph Navigation Language (Langage de Navigation dans un Graphe d’Objets). Il s’agit d’un langage d’expression utilisé par Struts 2 pour naviguer dans la pile d’objets (ValueStack), manipuler les JavaBeans et lier automatiquement les données entre l’interface utilisateur et la logique métier Java.

L’application évalue alors cette expression (sans contrôle suffisant), ce qui peut mener à l’exécution de commandes système sur le serveur à distance. Vous vous rappeler ? Le fait de savoir sur quelle technologie repose une application peut être exploitable aussi. J’ai évoqué cet aspect dans le billet concernant theHarvester, à retrouver également sur ce blog.

B.2.3. exploit/multi/http/wp_plugin_upload

Application cible : WordPress / Générique.

Cible les installations WordPress en empaquetant une charge utile PHP dans une archive ZIP de faux plugin pour l’activer. Comme quoi les plugins qui vous promettent ciel et terre, qui plus est à coût zéro c’est bien mais, il serait important de bien se renseigner au préalable.

B.2.4. exploit/multi/http/tomcat_mgr_upload

Application cible : Apache Tomcat / Identifiants.

Léger et très populaire, Apache Tomcat est un serveur Web et un conteneur de servlets open source développé par l’Apache Software Foundation. Il permet d’exécuter des applications Web développées en Java en mettant en œuvre les spécifications Jakarta Servlet, Jakarta JSP et Jakarta WebSocket. Ses fonctionnalités sont également mises en œuvre en tant que moteur d’exécution pour des frameworks comme Spring Boot ou Apache Struts.

L’exploit tomcat_mgr_upload de Metasploit présenté ici, tire parti des identifiants valides ou faibles du Manager Tomcat pour uploader et déployer un fichier WAR malveillant.

B.2.5. exploit/multi/http/jenkins_script_console

Application cible : Jenkins CI/CD.

Jenkins est un serveur d’automatisation open source incontournable pour la mise en place de pipelines d’intégration et de déploiement continus (CI/CD).

Grâce à son écosystème de milliers de plugins, il permet d’automatiser chaque étape du cycle de vie logiciel : de la compilation du code aux tests automatisés, jusqu’à sa livraison en production.

jenkins_script_console est une attaque ciblant Jenkins de telle manière que si la fonctionnalité permettant d’exécuter des scripts Groovy via la console Jenkins est accessible sans authentification correcte ou mal protégée, un attaquant peut y envoyer un script. Le script peut ensuite exécuter des commandes directement sur la machine hébergeant Jenkins (l’hôte), ce qui donne souvent un accès très élevé.

B.3. Élévation de Privilèges Locale (Local Privilege Escalation – LPE)

Modules exécutés depuis une session bas privilège existante pour obtenir les droits root ou SYSTEM.

B.3.1. exploit/windows/local/cve_2021_36934_hivenightmare

OS / Noyau : Windows 10/11 / SeriousSam.

Dans l’ère du temps, SeriousSam (ou HiveNightmare) est une vulnérabilité critique de Windows 10/11 qui exploite des autorisations d’accès (ACL) trop laxistes sur les fichiers du Registre système.

Elle permet à un utilisateur local non privilégié de lire les bases SAM et SYSTEM (notamment via les clichés instantanés VSS) pour en extraire les hachages de mots de passe.

En récupérant ainsi les données d’authentification d’un compte d’administration, l’attaquant peut obtenir les droits système maximaux (SYSTEM) sur la machine.

B.3.2. exploit/linux/local/dirtycow

OS / Noyau : Noyau Linux / CVE-2016-5195

Dirty COW (CVE-2016-5195) est une vulnérabilité critique du noyau Linux causée par une condition de concurrence (race condition) dans la gestion du mécanisme de copie sur écriture (Copy-On-Write).

Elle permet à un utilisateur local non privilégié de modifier des zones de la mémoire normalement configurées en lecture seule.

En exploitant ce défaut pour altérer des fichiers système ou des processus exécutables, l’attaquant peut obtenir des privilèges d’accès complets (root) sur la machine.

B.3.3. exploit/linux/local/sudo_baron_samedit

OS / Noyau : Sudo / CVE-2021-3156

Baron Samedit (CVE-2021-3156) est une vulnérabilité critique de l’utilitaire sudo due à un dépassement de tampon dans la mémoire tas (heap buffer overflow) lors de l’analyse d’arguments complexes.

Elle permet à n’importe quel utilisateur local non privilégié d’échapper au contrôle d’accès habituel sans avoir besoin de connaître le mot de passe utilisateur.

En exploitant cette faille, l’attaquant peut instantanément élever ses privilèges pour obtenir un accès complet (root) sur presque tout système Linux ou Unix vulnérable.

B.3.4. exploit/windows/local/bypassuac_eventvwr

OS / Noyau : Windows UAC Bypass

Windows UAC Bypass (eventvwr.exe) désigne une technique d’élévation de privilèges contournant le Contrôle de compte d’utilisateur (UAC) sans déclencher d’avertissement à l’écran.

Elle exploite le fait que l’exécutable légitime eventvwr.exe s’exécute automatiquement avec des privilèges élevés tout en cherchant certaines clés de Registre modifiables par un utilisateur standard.

En détournant ces clés de Registre, un attaquant local peut faire exécuter son propre code pour passer un processus d’un niveau d’intégrité moyen à haut de manière totalement transparente.

B.3.5. exploit/linux/local/pwnkit_dbus_pkexec

OS / Noyau : Polkit / CVE-2021-4034.

Le module pwnkit_dbus_pkexec exploite la vulnérabilité référencée CVE-2021-4034 dans le composant Polkit, via le programme pkexec utilisé sur beaucoup de distributions Linux.

Le bug provoque une corruption de la mémoire (le programme se trompe dans la façon dont il gère certains éléments en mémoire). En l’exploitant, un attaquant peut obtenir des droits root (accès administrateur) rapidement, sans authentification suffisante, sur la machine ciblée.

B.4. Attaques Côté Client (Client-Side)

Modules nécessitant une interaction de l’utilisateur (cliquer sur un lien, ouvrir un document, exécuter une macro).

B.4.1. exploit/windows/fileformat/office_word_macro

Logiciel cible: MS Office / Word

Avec ce module, un attaquant crée un fichier Word qui contient des macros VBA malveillantes. Quand la victime ouvre le document et clique sur ‘Activer le contenu / Activer les macros’, les macros se déclenchent, téléchargent un logiciel malveillant (le ‘payload’) depuis Internet (ou ailleurs) puis l’exécutent sur l’ordinateur de la victime.

B.4.2. exploit/windows/fileformat/adobe_pdf_embedded_exe

Logiciel cible: Adobe Reader / PDF

Comme son nom l’indique, adobe_pdf_embedded_exe, permet à un attaquant de créer un fichier PDF qui a l’air normal, mais qui contient en réalité un contenu dangereux. Le PDF est configuré pour déclencher automatiquement une action dès son ouverture (ou après une étape de lecture/interaction), comme lancer du code ou charger/exécuter un programme caché.

Résultat : un exécutable malveillant peut être exécuté sur l’ordinateur de la victime via le lecteur PDF.

B.4.3. exploit/windows/browser/ms14_064_ole_code_execution

Logiciel cible: Internet Explorer / OLE

C’est une attaque qui vise Internet Explorer. Un attaquant crée une page web (piégée) qui contient un contenu spécialement conçu pour déclencher une faille dans la gestion OLE par IE. Quand la victime visite la page, même sans cliquer, la vulnérabilité peut être exploitée, ce qui permet d’exécuter du code malveillant sur l’ordinateur de la victime.

B.4.4. exploit/multi/browser/firefox_proto_crmfrequest

Logiciel cible: Mozilla Firefox

Attaque basée sur le navigateur sur les anciennes versions de Firefox.

Spécifique aux anciennes versions du navigateur web Mozilla Firefox, cette attaque se produit directement pendant que vous naviguez sur le Web. Il suffit souvent qu’un utilisateur visite un site web piégé (ou une page piratée) pour que le piège se déclenche automatiquement via le navigateur.

L’objectif du pirate ici est d’exploiter un défaut de logique ou une erreur de programmation dans le système de contrôle de Firefox pour procéder à une élévation de privilèges (Privilege Escalation) en ciblant la gestion de ceux-ci en ce qui concerne JavaScript, un langage de programmation qui accompagne souvent le langage HTML dans le codage d’une page web. L’une des particularités de Javascript est de pouvoir rendre une page web un peu plus interactive.

Au final, le pirate réussit à faire croire à ces versions de Firefox anciennes que son code JavaScript malveillant est un script système légitime du navigateur. Une fois cette barrière franchie, le script malveillant peut :

  • Prendre le contrôle du navigateur.
  • Voler des données personnelles (données de navigation, cookies de session).
  • Parfois même exécuter du code arbitraire sur le système d’exploitation de l’ordinateur de la victime.
B.4.5. exploit/windows/fileformat/ms15_100_mcl_parsing

Logiciel cible: Windows Media Center.

La vulnérabilité exploitée par ms15_100_mcl_parsing est liée à un ancien composant de Windows notamment sous Windows Vista, 7 et 8. L’application Windows Media Center y était donc intégrée et permettait de lire des vidéos, de la musique et de regarder la télévision. Et comme toute application, le système d’exploitation arrive à reconnaître les fichiers le concernant grâce aux extensions, en l’occurence « .mcl ».

Les fichiers avec l’extension .mcl sont en fait des fichiers de raccourci qui servent normalement à lancer des chaînes de TV, des applications ou des contenus au sein de Media Center.

Problème : un fichier .mcl est conçu pour exécuter du code dès l’ouverture ou la prévisualisation dans l’explorateur Windows. Mais si le fichier est corrompu ou manipulé par un pirate, il peut pointer vers un programme malveillant au lieu d’un fichier multimédia classique.

Ainsi, si la victime clique sur le fichier .mcl piégé, Media Center s’ouvre, lit le raccourci et exécute automatiquement le programme distant choisi par le pirate. De plus, le fonctionnement de l’explorateur de Windows a tendance à aggraver les choses.

Lorsqu’on clique simplement sur un fichier, ou parfois lorsqu’on ouvre juste le dossier le contenant, Windows tente de générer un aperçu ou d’extraire ses métadonnées. Dans ce cas, l’attaque réussit sans même que l’utilisateur n’ait besoin de double-cliquer pour ouvrir le fichier : la simple tentative d’affichage suffit à déclencher le code piégé.

C.     Modules de charge utile 

Les charges utiles (payloads) fournissent le code exécutable (tel qu’un shell) déployé sur la cible une fois l’exploitation réussie. Elles peuvent être statiques (préconçues) ou dynamiques (générées ou modifiées à la volée). Ces dernières permettent aux auditeurs de développer leurs propres DLL ou d’intégrer des fonctionnalités sur mesure.

Les objectifs d’un payload incluent l’établissement d’une connexion distante, l’installation de services ou l’exécution de tâches arbitraires. Le shell Meterpreter en est l’un des exemples les plus aboutis.

Dans Metasploit, les payloads sont catégorisés selon leur mode de livraison et leur structure :

  • Single (ou Inline) : Une charge utile autonome et « complète » rassemblée en un seul bloc de code, sans séparation entre phase d’amorce et phase d’exécution.
  • Stager : Un petit binaire d’amorce injecté en premier, dont le rôle unique est d’établir la connexion initiale et de charger en mémoire la suite du code.
  • Stage : La charge utile principale, plus volumineuse (ex. Meterpreter), téléchargée et exécutée en mémoire par le stager.

Selon l’architecture et l’OS ciblé, le module reverse_tcp est l’un des plus fréquemment employés. Les payloads se divisent principalement en deux architectures de communication :

A. Connexion Reverse (Sortante)

Le payload initiant une connexion sortante depuis la machine victime vers l’adresse IP et le port d’écoute de l’attaquant (LHOST/LPORT).

  • Mode opératoire :
    1. Déclenchement : Exécution du payload sur la cible après l’exploit.
    2. Connexion sortante : Établissement de la session TCP vers l’attaquant.
    3. Canal de contrôle : Ouverture de la session interactive (Shell ou Meterpreter).
  • Forces :
  • Contourne efficacement les pare-feux restrictifs en trafic entrant (inbound).
  • Limites & Détection :
  • Egress filtering : Échec de la connexion si le trafic sortant (egress) est bloqué ou filtré (proxy avec authentification, règles de pare-feu strictes).
  • Analyse comportementale : Risque de détection des flux sortants anormaux par les EDR/IDS (signatures TLS/JA3, User-Agent suspects, patterns temporels).

B. Connexion Bind (Entrante)

Le payload ouvre un port d’écoute directement sur la machine cible et attend une connexion entrante de l’attaquant.

  • Forces :
    • Utile lorsque la cible ne dispose d’aucun accès réseau vers l’extérieur (egress totalement bloqué).
  • Limites & Détection :
    • Besoins Inbound : Échoue si un pare-feu réseau, local ou un mécanisme de NAT bloque les connexions entrantes vers la cible.
    • Forte visibilité : L’ouverture d’un nouveau port d’écoute non légitime sur un hôte est très rapidement détectée par les scanners de vulnérabilités, pare-feux et EDR.

L’efficacité d’un payload dépend fortement du contexte d’exécution et des défenses en place :

FacteurImpact sur l’exécution
Environnement d’exécutionL’utilisation de payloads adaptés à l’écosystème cible (Java, PHP, Python, Node.js) offre souvent une meilleure discrétion et stabilité qu’un binaire natif au sein d’une application web.
Défenses applicatives (Scripting)Les charges utiles basées sur PowerShell subissent une forte surveillance (AMSI, Constrained Language Mode, pré-analyse EDR, logs d’événements).
Protections système (Mitigations)La réussite dépend de l’architecture (x86/x64), des droits de l’utilisateur et des protections mémoire actives (ASLR, DEP, SafeSEH).
Type de sessionUn simple shell commande/systeme offre moins de fonctionnalités de post-exploitation avancées et de discrétion qu’une session Meterpreter résidant exclusivement en mémoire.

Les différentes variantes sont donc les suivantes :

C.1. Architecture Windows (x64 / x86)

C.1.1. reverse_tcp (windows/x64/meterpreter/reverse_tcp)

Le payload reverse_tcp donne accès à un shell de commandes sur le système cible. Plus précisément, il injecte en mémoire le shell avancé Meterpreter et initie une connexion TCP sortante vers l’attaquant, afin de lui fournir une session interactive pour la post-exploitation (commande distante, exécution d’actions, collecte selon les modules post disponibles). Contourne souvent les pare-feu locaux qui bloquent les connexions entrantes.

C.1.2. reverse_https (windows/meterpreter/reverse_https)

Le module windows/meterpreter/reverse_https est une variante furtive x86/x64 encapsulant le trafic Meterpreter dans du SSL/TLS (port 443) pour passer inaperçu devant la plupart des systèmes d’inspection réseau (IDS/DPI). HTTPS est généralement moins bloqué que d’autres formes de trafic sortant, et peut mieux passer à travers des politiques egress strictes.

C.1.3. reverse_tcp (windows/x64/shell/reverse_tcp)

Plus léger que Meterpreter, le Shell interactif brut (cmd.exe) 64 bits est très utile sur les cibles où l’injection de DLL est bloquée. Il donne un accès plus “commande” que des payloads purement agent/contrôle (selon l’environnement).

C.1.4. reverse_tcp (windows/x64/powershell_reverse_tcp)

Dans la même logique que la variante ciblant le shell brut cmd, powershell_reverse_tcp met en place une session en initiant une connexion TCP sortante vers ton hôte, en s’appuyant sur PowerShell pour exécuter le code côté Windows et fournir un canal d’accès (selon le contexte du module).

C.1.5. shell_bind_tcp (windows/shell_bind_tcp)

Via sa structure nominale, nous pouvons déjà nous projeter dans sa fonction, puisque, shell_bind_tcp est un classique Single/Inline (x86) qui ouvre un port d’écoute TCP directement sur l’hôte ciblé et attend que l’attaquant se connecte depuis l’extérieur, afin de fournir un canal de type shell.

C.2. Architecture Linux (x64 / x86 / ARM)

C.2.1. reverse_tcp (linux/x64/meterpreter/reverse_tcp)

Le module linux/x64/meterpreter/reverse_tcp est un payload Metasploit (Meterpreter) pour Linux x64 qui, une fois exécuté sur la machine cible, initie une connexion TCP sortante vers l’attaquant, puis ouvre une session interactive pour la post-exploitation.

C.2.2. shell_reverse_tcp (linux/x86/shell_reverse_tcp)

Payload historique léger, le module linux/x86/shell_reverse_tcp est un payload “shell” Metasploit pour Linux x86 (32-bit) qui, une fois exécuté sur la cible, établit une connexion TCP sortante (reverse) vers ton hôte, puis fournit un accès de type shell pour exécuter des commandes via ce canal.

C.2.3. shell_bind_tcp (linux/x64/shell_bind_tcp)

A l’instar de son équivalent visant le système d’exploitation Windows, le module linux/x64/shell_bind_tcp est un payload “shell” Metasploit pour Linux x64 qui, une fois exécuté sur la cible, ouvre une écoute TCP locale sur la machine compromise (bind) et fournit un accès shell dès qu’un client distant se connecte sur ce port.

C.2.4. reverse_tcp (linux/armle/shell/reverse_tcp)

Ciblé sur l’architecture ARM Little-Endian (très fréquent sur les Raspberry Pi, boîtiers domotiques et objets connectés), le module linux/armle/shell/reverse_tcp est un payload “shell” Metasploit qui une fois exécuté sur la cible, initie une connexion TCP sortante vers l’attaquant afin de lui donner un accès de type shell pour exécuter des commandes via ce canal.

C.2.5. exec (linux/x64/exec)

Charge utile de type single, il ne crée pas de session interactive réseau, mais une fois exécuté sur la cible (après un exploit), lance un programme/une commande spécifiée dans un contexte d’exécution “local” sur la machine compromise.

C.3. Architectures Embarquées & Spécifiques (MIPS, ARM, PowerPC)

C.3.1. shell_reverse_tcp (linux/mipsbe/shell_reverse_tcp)

Le module linux/mipsbe/shell_reverse_tcp est un payload “shell” Metasploit pour des systèmes Linux MIPS big-endian. Nous parlons ici de l’exploitation de routeurs réseau, switchs et modems. Mais le principe reste le même que les autres types de cibles : il établit une connexion TCP sortante (reverse) vers un hôte contrôlé par l’attaquant, puis fournit un accès de type shell pour exécuter des commandes via ce canal.

C.3.2. shell_reverse_tcp (linux/mipsle/shell_reverse_tcp)

Notez bien la différence “mips – b – e”  et “mips – l- e”. Ce dernier est l’équivalent pour processeurs MIPS Little-Endian, présents dans de nombreux points d’accès Wi-Fi du commerce.

Le module linux/mipsle/shell_reverse_tcp ciblan ce type d’environnement va donc initier une connexion TCP sortante (reverse) vers un hôte contrôlé, puis fournit un accès shell pour exécuter des commandes via ce canal.

C.3.3. reverse_tcp (linux/aarch64/shell/reverse_tcp)

Les serveurs ARM et autres équipements industriels sont ici concernés ; reverse_tcp ne pardonne personne. Une fois exécuté sur la cible à l’architecture visée, il initie une connexion TCP sortante vers l’attaquant, puis fournit un shell pour exécuter des commandes via cette connexion. Il va de soi que la maîtrise des commandes compatibles à l’environnement cible donne du sens à ce type d’attaque.

C.3.4. reverse_tcp (android/meterpreter/reverse_tcp)

Le chemin nominatif l’indique si bien, nous parlons de téléphones dont le système d’exploitation est Androïd. Dans ce cas, l’agent Meterpreter compilé pour l’architecture Android (ARM/x86) sous forme d’application ou d’injection d’APK. Une fois déployé après un exploité réussi, il établit une connexion sortante TCP vers un hôte contrôlé, puis fournit une session pour la post-exploitation (pilotage à distance de fonctions/commandes selon les capacités disponibles).

C.3.5. reverse_tcp (osx/x64/meterpreter/reverse_tcp)

Bien qu’enveloppé dans une image de marque plus rassurante, les systèmes macOS équipés de processeurs x86_64 / émulation Intel peuvent aussi être pris à parti par des hackers. Cette variante de la charge utile reverse_tcp pour macOS x64 établit une session permettant la post-exploitation après une exploitation réussie. Tout comme les autres environnements, la maîtrise des commandes sous macOS est ici indispensable, pour une meilleure démonstration de l’impact potentiel par un testeur, au risque de se contenter d’un accès vide de sens.

C.4. Multiplateforme & Langages Interprétés (Web / Scripting)

C.4.1. reverse_tcp (java/meterpreter/reverse_tcp)

Ce type de payload s’exécute Indépendant du système d’exploitation de la cible. Dans le cas d’espèce, nous parlons de la machine virtuelle Java (JVM). Les applications web d’entreprise (Tomcat, Jenkins, WebLogic), sont généralement prises pour cible. Pour ce faire,

Le module java/meterpreter/reverse_tcp une fois lancé, établit une connexion TCP sortante (reverse) vers l’attaquant et ouvre une session pour la post-exploitation (commande/exécution d’actions selon les capacités de Meterpreter).

C.4.2. meterpreter_reverse_tcp (php/meterpreter_reverse_tcp)

Dans la même dynamique que Java, mais cette fois visant l’exploitation de failles Web PHP (upload de fichiers, LFI/RFI).

C.4.3. reverse_tcp (python/meterpreter/reverse_tcp)

Le principe est le même : le payload python/meterpreter/reverse_tcp est destiné à un environnement où du code Python peut s’exécuter sur la cible : une fois exécuté, il initie une connexion TCP sortante (reverse) vers l’hôte de l’attaquant, puis établit une session Meterpreter pour la post-exploitation.

C.4.4. reverse_tcp (node/shell/reverse_tcp)

A l’instar des précédents, la charge utile node/shell/reverse_tcp est conçue pour un environnement où le code Node.js (JavaScript côté serveur / runtime Node) peut s’exécuter sur la cible : une fois activé, il établit une connexion TCP sortante (reverse) vers un l’hôte de l’attaquant et fournit un accès de type shell pour exécuter des commandes via ce canal.

C.4.5. reverse_bash (cmd/unix/reverse_bash)

Pas besoin d’injection de binaire pour l’exécuter. Ce payload cible Bash, un shell (interpréteur de commandes) de type Unix qui permet d’exécuter des commandes, d’automatiser des tâches via des scripts et de contrôler l’environnement du système.

Le module cmd/unix/reverse_bash est donc un payload “reverse” Metasploit destiné à un contexte Unix, qui, une fois exécuté sur la cible, utilise Bash et établit une connexion sortante (reverse) vers l’attaquant, afin d’obtenir un accès de type commande/shell via ce canal.

C.4.6. MsfVenom

Nous avons fait allusion à MsfVenom dans les précédentes parties sans les savoir. Lorsque nous parlions de payloads dynamiques, nous faisions allusion à MsfVenom. Lorsque nous disions qu’il est possible de développer soi-même ses propres charges utiles, nous faisions allusion à MsfVenom.

En effet, les testeurs peuvent utiliser le module MsfVenom pour générer des payloads sur mesure pour des cibles spécifiques. Grâce à Msfvenom, vous pouvez personnaliser les payloads en fonction de la cible, et ainsi augmenter vos chances de réussite lors des tests d’intrusion, en contournant d’éventuels pare-feu, antivirus ou autre systèmes de sécurité.

D.    Modules auxiliaires 

Les modules auxiliaires de Metasploit ne sont pas directement impliqués dans l’exploitation de vulnérabilités. Ils permettent aux testeurs d’effectuer des tâches complémentaires indispensables tout au long d’un test d’intrusion, telles que :

  • La collecte d’informations (OSINT et reconnaissance) ;
  • L’énumération de services ;
  • L’analyse réseau et le balayage de ports (scanning) ;
  • Le fuzzing, qui consiste à éprouver une application en lui soumettant des données massives ou malformées afin de provoquer des erreurs, des plantages ou des comportements inattendus, permettant ainsi de déceler des débordements de mémoire (buffer overflows), des erreurs de validation ou des chemins de code non sécurisés ;
  • L’identification de bases de données ;
  • L’authentification et l’interaction avec divers services ;
  • L’analyse de déni de service (DoS) ou le test de résistance.

Ces modules s’avèrent utiles aussi bien lors de la phase de reconnaissance (en amont) que lors de la phase de post-exploitation. Parmi les catégories les plus représentatives, nous pouvons citer :

D.1. Scanners / discovery réseau

Nous faisons allusion à ces modules utilisés pour la reconnaissance, la cartographie du réseau, le fingerprinting (identification de services et versions) et la détection de mauvaises configurations.

D.1.1. auxiliary/scanner/portscan/tcp

auxiliary/scanner/portscan/tcp permet d’effectuer un scan TCP classique sur une plage d’adresses IP pour identifier les ports ouverts. Contrairement à un outil externe comme Nmap, ce module s’exécute directement depuis la console Metasploit, ce qui peut être particulièrement utile lorsqu’on effectue des scans au travers d’un rebond (pivoting via un canal déjà établi).

D.1.2. auxiliary/scanner/discovery/udp_sweep

Le protocole UDP ne fonctionnant pas en mode connecté, la découverte d’équipements actifs est plus complexe. Le module auxiliary/scanner/discovery/udp_sweep permet donc d’envoyer des requêtes UDP ciblant plusieurs services courants (DNS, SNMP, NTP, NetBIOS, Syslog…) vers un sous-réseau, afin d’identifier les machines qui répondent et dresser une première carte du parc.

D.1.3. auxiliary/scanner/smb/smb_version

Le module auxiliaire smb_version a pour rôle l’identification de version du service SMB (Server Message Block). Le partage de fichiers SMB (très présent sur les réseaux Windows) est une cible clé lors des audits d’architecture. Ce module interroge le service pour déterminer précisément la version du protocole (SMBv1, SMBv2, SMBv3), le système d’exploitation exact de la cible et le nom de domaine ou groupe de travail associées.

D.1.4. auxiliary/scanner/http/http_version

Ce module parcourt une plage d’adresses IP sur les ports Web (80, 443, 8080, etc.) pour récupérer les en-têtes de réponse (headers) HTTP. Ce faisant, il permet d’identifier rapidement les technologies hébergées (Apache, Nginx, IIS), leurs versions et les éventuels redirections ou certificats SSL actifs.

D.1.5. auxiliary/scanner/ssh/ssh_version

Spécialisé dans la détection et l’identification des services SSH, ce module auxiliaire scanne les ports SSH (par défaut le port 22) pour extraire la bannière d’accueil SSH (SSH banner). Cela permet aux administrateurs réseau de vérifier l’inventaire des serveurs d’administration à distance et d’identifier rapidement les logiciels SSH obsolètes ou non mis à jour.

D.2. Brute force / credentials

Ce type de module auxiliaire est conçu pour évaluer la solidité des mots de passe sur des services d’authentification ou auditer la présence d’identifiants par défaut / faibles.

D.2.1. auxiliary/scanner/ssh/ssh_login

auxiliary/scanner/ssh/ssh_login cible le service SSH. Ce module tente d’établir une session SSH sur une plage de machines cibles en testant des listes d’utilisateurs et de mots de passe (ou paires de clés). S’il réussit à s’authentifier, il peut automatiquement ouvrir une session de terminal interactif ou une session Meterpreter sur la cible.

D.2.2. auxiliary/scanner/smb/smb_login

Indispensable lors des audits d’infrastructure Windows, auxiliary/scanner/smb/smb_login teste des identifiants (utilisateur, mot de passe, domaine ou hash NTLM via la technique du Pass-the-Hash) sur le protocole SMB. Il permet de vérifier quels comptes disposent de privilèges d’accès ou d’administration sur plusieurs machines du réseau.

D.2.3. auxiliary/scanner/rdp/rdp_scanner / rdp_login

rdp_login est un module auxiliaire qui a pour rôle le test d’accès Remote Desktop Protocol (Bureau à distance Windows). Ce module valide l’efficacité et la résistance des identifiants d’accès sur le service RDP (port 3389). Il permet d’identifier les accès distants à interface graphique exposés et mal sécurisés au sein d’une organisation.

D.2.4. auxiliary/scanner/http/http_login

Mener une attaque par dictionnaire sur l’authentification HTTP Basic / Digest est l’essence même de ce module. Il cible les interfaces web protégées par des boîtes de dialogue d’authentification standard (Basic ou Digest Authentication), très fréquentes sur les panneaux d’administration de routeurs, d’équipements réseau, de caméras IP ou d’applications web d’entreprise.

D.2.5. auxiliary/scanner/postgres/postgres_login

Souvent masqués ou relégués en arrière-plan, les Systèmes de Gestion de Bases de Données (SGBD) restent des cibles privilégiées. Le module postgres_login en apporte la preuve en ciblant spécifiquement le serveur PostgreSQL.

Son mode opératoire repose sur des tentatives d’authentification automatisées (par force brute ou dictionnaire) sur les instances PostgreSQL détectées sur le réseau (port TCP 5432), en testant des identifiants et mots de passe par défaut ou courants (tels que l’utilisateur postgres).

Une authentification réussie sur un SGBD peut accorder un accès direct à des données sensibles, voire permettre l’exécution de commandes système selon les privilèges du service.

D.3. Enumeration & collecte “non exploitante”

Leur objectif est d’extraire des données précieuses (utilisateurs, partages, métadonnées, configurations) sans exécuter de code malveillant ni exploiter de vulnérabilité.

D.3.1. auxiliary/scanner/smb/smb_enumshares

Le module smb_enumshares met en œuvre une technique de reconnaissance visant le service de partage de fichiers Windows (SMB). Elle consiste à répertorier l’ensemble des dossiers partagés, y compris les répertoires d’administration cachés, puis à tester les permissions d’accès en mode anonyme ou restreint. Cette démarche permet d’identifier les erreurs de configuration et les autorisations excessives afin de prévenir les fuites de données confidentielles ou l’injection de fichiers malveillants.

D.3.2. auxiliary/scanner/smb/smb_enumusers

Parmi les outils de reconnaissance ciblés sur les environnements Windows et Active Directory, le module smb_enumusers joue un rôle clé. Comme son nom l’indique, il est spécifiquement conçu pour l’énumération des comptes utilisateurs.

Son mode opératoire repose sur le protocole SMB pour interagir directement avec les services système cibles (notamment via l’API SAM ou MSRPC). Cette méthode lui permet de recenser l’ensemble des identifiants valides sur un hôte autonome ou au sein d’un domaine Active Directory.

La cartographie des comptes ainsi établie constitue une étape préalable essentielle pour évaluer la surface d’attaque, notamment avant de tester la robustesse des politiques de mots de passe.

D.3.3. auxiliary/scanner/snmp/snmp_enum

Lorsque la chaîne de communauté SNMP par défaut (souvent public) est conservée sur des équipements réseau (routeurs, commutateurs, imprimantes, serveurs), ce module permet de récolter une quantité importante d’informations systèmes.

Son mode opératoire repose sur l’interrogation de la MIB (Management Information Base) de l’équipement cible. Il extrait ainsi une cartographie détaillée de l’architecture : noms d’hôte, interfaces et tables de routage, processus en cours d’exécution et applications installées.

L’ensemble de ces métadonnées révèle la configuration exacte du système et s’avère particulièrement utile pour évaluer la surface d’attaque globale.

D.3.4. auxiliary/scanner/http/dir_scanner

Le module dir_scanner réalise une recherche par dictionnaire (directory busting) sur un site web dans le but de découvrir des arborescences masquées, des dossiers d’administration, des fichiers de sauvegarde (.bak, .zip) ou des interfaces de test non référencées dans les menus publics.

En d’autres termes, l’outil teste une liste de noms fréquents pour identifier des dossiers cachés, des interfaces d’administration ou des fichiers temporaires et de sauvegarde (.bak, .zip). Cette phase de reconnaissance permet de déceler des ressources oubliées ou mal protégées pouvant exposer des données sensibles ou offrir un point d’accès non autorisé.

D.3.5. auxiliary/gather/dns_enum

Le DNS (Domain Name System) est le système qui traduit les noms de domaine (ex. example.com) en informations de connexion comme des adresses IP. Au sein d’une organisation, avoir la cartographie DNS revient à avoir une liste exhaustive de tout ce qui touche à ces noms de domaine et enregistrements DNS dans le but de comprendre comment le trafic et les services de l’organisation sont dirigés et identifier ce qui est publié ou modifié.

Dans une perspective d’attaque, cela permet de dresser la carte des actifs exposés d’une entreprise, dans le but évident d’analyser leurs faiblesses et de les exploiter. Ainsi, la fonction du module dns_enum est de ressortir une telle cartographie en interrogeant les serveurs DNS (enregistrements A, MX, NS, TXT), en tentant un transfert de zone (AXFR) ou par recherche de sous-domaines par dictionnaire.

E.     Générateurs No Operation (NOPS)

Le rôle principal des modules de type NOPS est de rendre un exploit plus robuste face aux mécanismes de détection (IDS/IPS, antivirus) et contourner l’imprécision des adresses de retour mémoire. C’est en ce sens qu’ils peuvent procéder à la génération d’opérations nulles (NOP) pour maintenir l’alignement de la mémoire, ce qui améliore la stabilité et la fiabilité des exploits.

De plus, un générateur NOPS peut produire des octets aléatoires pour remplir les tampons, afin de contourner les systèmes de détection et de prévention d’intrusion (IDS/IPS) comme nous l’avons précédemment mentionné.

Dans la chaîne d’exécution d’une attaque, les modules NOPS précèdent une charge utile (payload) lors d’une exploitation. Cette séquence d’instructions qui techniquement ne fait rien, est placée dans une zone mémoire/chaîne afin d’augmenter la probabilité que l’exécution “atterrisse” correctement.

Il est également dit qu’il permet d’augmenter la fiabilité d’un atterrissage en compensant un manque de précision dans le point exact où l’exécution commence (dans les scénarios de contrôle de flux/mémoire).

Il en existe une variété en fonction des architectures.

E.1. Pour des architectures processeur x86

E.1.1. opty2 (nop/x86/opty2)

opty2 est un générateur polymorphe x86 classique et populaire. Il produit des suites NOP très aléatoires. Pour augmenter la fiabilité d’un atterrissage dans une zone mémoire, il se révèle particulièrement utile quand l’offset exact de reprise d’exécution n’est pas parfaitement connu, et pour aider à satisfaire des contraintes comme par exemple : éviter certains octets “bad chars” dans la construction de la charge.

E.1.2. single_byte (nop/x86/single_byte)

La séquence d’instructions de single_byte est conçue pour se comporter comme des “NOP équivalents” à partir de façons très simples et avec un seul octet (utile notamment quand certains octets sont interdits ou difficiles à utiliser), afin d’augmenter la robustesse du “point d’atterrissage” de l’exécution. Cette large gamme d’instructions d’un seul octet n’affecte pas le registre du processeur.

E.2. Pour des architectures processeur ARM64 (Aarch64)

E.2.3. simple (nop/aarch64/simple)

simple (nop/aarch64/simple) est un générateur NOP pour AArch64 (ARM 64-bit) : il produit une petite séquence d’instructions “neutres” (équivalentes à des NOP) pour former un NOP sled, améliorant la fiabilité de l’exécution quand le point exact où le contrôle est transféré n’est pas parfaitement précis ou doit respecter des contraintes d’encodage/mémoire.

E.3. Pour des architectures processeur MIPS configurées en big-endian

E.3.1. better (nop/mipsbe/better)

Adapte les sleds NOP.

better (nop/mipsbe/better) est un générateur de NOP pour MIPS big-endian, c’est à dire pour les architectures embarquées (routeurs, objets connectés) en MIPS. Il produit des séquences d’instructions “neutres” adaptées à l’architecture pour construire un NOP sled et améliorer la robustesse du transfert d’exécution quand l’atterrissage exact est imparfait ou doit satisfaire certaines contraintes d’environnement/mémoire.

E.4. Pour tout type d’architecture : TTY / Universel

E.4.1. generic (nop/tty/generic)

Le module NOPS generic (nop/tty/generic) dans Metasploit sert à fabriquer une “NOP sled” (une suite d’instructions sans effet) de façon compatible avec le contexte d’exécution afin d’augmenter les chances que le flot d’exécution “atterrisse” dans la zone utile (souvent le payload) même si l’adresse exacte n’est pas parfaitement maîtrisée. Pour ce faire, il génère des caractères d’espacement (ex: espaces, tabulations) utilisables dans des contextes textuels (champs Ssh/Telnet).

F.      Encodeurs

Les encodeurs servent à transformer une charge utile ou payload afin qu’elle soit plus discrète : éviter des “bad characters” (octets interdits), contourner des filtres, réduire la signature, etc. Le but principal est l’obfuscation du contenu.

Autrement dit, les modules d’encodage ont pour rôle principal de modifier le format de la charge utile (payload) afin de supprimer des octets problématiques (comme les octets nuls \x00) ou de masquer la signature binaire directe de la charge.

Parmi les modules d’encodage les plus courants nous avons :

  • encoder/x86/shikata_ga_nai : Encodeur polymorphe pour architecture 32 bits. Il utilise une clé XOR variable et génère une routine de décodage dynamique pour masquer la charge utile.
  • encoder/x86/alpha_mixed : Transforme la charge utile en une chaîne composée uniquement de caractères alphanumériques (majuscules/minuscules), utile si le canal de transmission ne tolère pas les caractères non imprimables.
  • encoder/x64/zutto_dekiru : Équivalent 64 bits d’obfuscation par XOR dynamique, conçu pour adapter les charges x64 aux contraintes de mémoire.
  • encoder/cmd/powershell_base64 : Convertit une commande Windows en une chaîne encodée en Base64 exécutable directement par PowerShell via le paramètre -EncodedCommand.

G.    Modules d’évasion

Contrairement aux encodeurs qui se contentent de modifier le contenu d’un payload, les modules de la catégorie Evasion sont conçus pour générer des fichiers exécutables (fichiers .exe, .hta, .vbs, etc.) intégrant des techniques avancées pour contourner les défenses comportementales et antivirales (antivirus/EDR, IDS/IPS, sandboxing, heuristiques, etc.). Le but principal est la contourner la détection.

Parmi les modules d’évasion les plus courants nous avons :

  • evasion/windows/windows_defender_exe : Génère un fichier exécutable Windows (.exe) conçu pour masquer l’injection de la charge utile en mémoire et tenter d’échapper à la détection par signatures de Windows Defender.
  • evasion/windows/applocker_evasion_msbuild : Génère un fichier projet XML exploitable par l’outil légitime Windows MSBuild.exe, permettant de contourner les règles d’apprentissage ou de blocage AppLocker.
  • evasion/windows/windows_defender_js : Encapsule une charge utile dans un script JavaScript (.js) exécuté par wscript.exe, utilisant l’obfuscation de code pour éviter la détection à la livraison.
  • evasion/windows/macofusion : Module combinant plusieurs techniques d’obfuscation de code source et d’allocation mémoire pour produire des binaires moins détectables par l’analyse statique.

H.    Le datastore

Le datastore est la configuration centrale permettant aux testeurs de définir le comportement des composants Metasploit. C’est le moteur de gestion des variables et paramètres au sein de la session Metasploit (msfconsole). C’est un espace mémoire (clé-valeur) qui stocke les options nécessaires à l’exécution des modules (exploits, auxs, payloads).

Il permet également de définir des paramètres et des variables dynamiques et de les réutiliser entre les modules et les charges utiles. Metasploit dispose d’un datastore global et d’un datastore spécifique pour chaque module.

I.        msfdb

msfdb est un outil de gestion de bases de données compatible avec PostgreSQL. La base de données msfdb stocke des informations telles que les données hôtes, les résultats d’exploitation et le butin. Vous pouvez utiliser msfdb pour importer les résultats d’analyse ; il propose à cet effet une liste de commandes.

Datastore et msfdb répondent à deux besoins totalement différents : l’un gère la configuration temporaire des modules, tandis que l’autre gère la base de données persistante des résultats d’audit.

J.       Les modules de post-exploitation

Les modules de post-exploitation permettent aux testeurs d’approfondir leur accès au système cible. Ils sont conçus pour s’exécuter une fois la cible exploitée et une session Metasploit établie.

Ils peuvent être utilisés pour collecter des identifiants, recenser les fichiers et les processus, élever leurs privilèges, assurer leur persistance, extraire des mots de passe, et s’infiltrer plus profondément dans un réseau compromis.

Les modules de post-exploitation classiques

Parmi les plus courants nous pouvons citer :

  • post/windows/gather/hashdump  : Extrait les hachages de mots de passe (NTLM/LM) stockés dans la base SAM du système Windows pour tenter de les casser hors-ligne.
  • post/windows/gather/credentials/mimikatz  : Intègre l’outil Mimikatz directement dans la mémoire de la session Meterpreter afin de récupérer des mots de passe en clair, des codes PIN ou des tickets Kerberos.
  • post/windows/gather/enum_applications : Énumère l’ensemble des logiciels et applications installés sur la machine compromise, ce qui aide à identifier d’autres vulnérabilités logicielles potentielles.
  • post/multi/gather/env  : Permet de récupérer les variables d’environnement du système cible (fonctionne sur plusieurs plateformes multi-OS) pour y déceler des informations sensibles (chemins d’accès, clés ou configurations).
  • post/windows/manage/persistence : Installe un mécanisme de persistance (via le registre, les tâches planifiées ou un service) pour s’assurer qu’un accès distant subsiste même après un redémarrage de la machine cible.

Meterpreter

Meterpreter est une charge utile (payload) interactive et avancée au sein de Metasploit. Elle vient pallier les limites des payloads classiques qui exécutent une fonction unique et ne peuvent couvrir l’ensemble des besoins d’un test d’intrusion, imposant parfois d’en changer, de les combiner ou d’en développer de nouveaux.

Elle offre la capacité d’interagir directement avec le système cible après son exploitation. Meterpreter permet notamment aux testeurs de basculer facilement d’une charge utile à une autre grâce à la commande setpayload. Ses fonctionnalités dynamiques permettent également de concevoir des scripts sur mesure, adaptés aux spécificités de la cible au cours de l’évaluation.

Il est ainsi possible d’utiliser le langage Ruby pour écrire des scripts Meterpreter exécutant des fonctions personnalisées. De plus, son extension Python fournit des commandes supplémentaires pour exécuter du code Python directement sur la machine hôte.

Enfin, Meterpreter s’exécute exclusivement en mémoire vive (in-memory), sans écrire de binaire sur le disque de la cible. Cette caractéristique de furtivité le rend particulièrement complexe à détecter pour les solutions de sécurité conventionnelles.

En parcourant tous ces types de modules, nous relevons de toute évidence que les frontières entre les différentes catégories peuvent parfois sembler poreuses, car les objectifs finaux (comme contourner la sécurité ou collecter des informations) se recoupent.

Cependant, la distinction au sein de Metasploit réside principalement dans le contexte d’exécution et le mécanisme technique utilisé. Par exemples :

  • Reconnaissance externe (Auxiliaire) vs. Interne (Post-exploitation) : Un module auxiliaire de type scanner/portscan/tcp est conçu pour sonder une cible depuis l’extérieur (ou depuis une machine compromise en utilisant un routage réseau). À l’inverse, un module de post-exploitation comme post/windows/gather/enum_network réalise une énumération réseau, mais de l’intérieur, en s’appuyant directement sur les privilèges et la position de la machine déjà compromise. L’objectif final (cartographier le réseau) est similaire, mais la méthode et la source diffèrent.
  • Encodage et Évasion (Evasion) : Ces deux familles partagent le même grand objectif : tromper les solutions de sécurité (EDR/Antivirus). Toutefois, un encodeur se limite à transformer la structure des octets du payload (pour éviter les caractères nuls ou modifier la signature de base), tandis qu’un module d’évasion (introduit plus récemment dans Metasploit) encapsule ou fragmente le payload dans des formats spécifiques (comme des stubs d’exécution sophistiqués) pour contrer des analyses comportementales plus avancées.
  • Modules d’exploitation (exploit) et Post-exploitation : Certains exploits modernes intègrent directement des phases de post-exploitation automatisées (via l’option AutoRunScript ou des charges de type staged qui exécutent des commandes post-compromission immédiatement après l’accès). Néanmoins, les modules de type post restent des briques modulaires que l’on peut lancer à la demande, sur n’importe quelle session active existante, indépendamment de la manière dont la machine a été compromise au départ.

III.              Installation et modalités d’utilisation

À sa création, Metasploit était un projet entièrement gratuit. Depuis son rachat par l’entreprise américaine Rapid7 en 2009, le projet s’est structuré autour de plusieurs déclinaisons :

  • Metasploit Framework : La version gratuite, communautaire et open source.
  • Metasploit Pro : La version commerciale « tout-en-un », proposant une interface graphique (GUI), un support technique dédié et des fonctionnalités avancées pour le travail en équipe.

Metasploit est préinstallé sur la distribution Kali Linux. Comme tout projet open source, son code source est accessible sur GitHub en complément du site officiel de Rapid7.

L’arborescence des fichiers du framework se situe généralement dans le répertoire /usr/share/metasploit-framework et les principaux dossiers sont les suivants :

  • data : contient les fichiers de support et ressources tierces (wordlists, binaires de charge utile, modèles, etc.) ;
  • documentation : rassemble les guides et manuels d’utilisation du framework ;
  • lib : contient le cœur du code source en Ruby (msf/core, msf/base) ;
  • modules : dossier central regroupant les modules d’exploitation (exploits), auxiliaires (auxiliary), charges utiles (payloads), encodeurs (encoders), NOPs (nops) et évasion (evasion) ;
  • plugins : héberge les extensions permettant d’ajouter des fonctionnalités externes à la console ;
  • scripts : rassemble les scripts d’automatisation (tels que Meterpreter ou ressources shell) ;
  • tools : contient les utilitaires en ligne de commande pour le développement et la manipulation de modules.

Pour lancer l’interface principale, il suffit d’ouvrir un terminal et d’exécuter la commande msfconsole. Cette commande initialise l’environnement, charge les modules et établit la connexion avec la base de données interne (si msfdb est actif). Une bannière d’accueil affiche alors le décompte à jour des différents modules disponibles.

Bien qu’une aide intégrée soit accessible directement dans l’outil via la commande help (ou ?), la documentation officielle complète est consultable en ligne à l’adresse docs.metasploit.com.

Note sur la commande help : Saisie à la racine de la console, elle liste l’ensemble des commandes globales. Saisie au sein du contexte d’un module spécifique (après un use), la liste des commandes s’adapte automatiquement pour afficher les options propres à ce module.

IV.             Limites, outils similaires et alternatives

Le nombre de modules de Metasploit se compte par milliers et s’enrichit au fil des versions. Bien que ce catalogue soit vaste, l’évolution rapide de la menace, l’émergence constante de nouvelles vulnérabilités et la complexité des environnements font que les outils intégrés ne représentent qu’une fraction des vecteurs d’attaque réellement exploitables.

Il convient donc de toujours concentrer les audits sur les menaces les plus pertinentes pour l’organisation. Si nécessaire, les équipes de sécurité devront développer des modules Metasploit personnalisés ou s’appuyer sur des outils complémentaires afin de garantir qu’une évaluation couvre au mieux les risques réels.

Voici quelques alternatives populaires :

1. Burp Suite Professional :

Burp Suite Professional est une plateforme complète de test de sécurité des applications web, combinant des outils manuels et automatisés pour mener des évaluations de vulnérabilités et des tests d’intrusion rigoureux.

Proposée sous licence commerciale, cette solution est spécifiquement dédiée au trafic applicatif web. Elle s’articule autour de modules clés : un Proxy d’interception, un Scanner automatisé basé sur des règles, un Repeater pour réémettre et modifier des requêtes, un Intruder pour le fuzzing, ainsi que Collaborator pour la détection de vulnérabilités out-of-band (OAST).

Comparativement à Metasploit, Son point fort réside dans l’analyse granulaire, l’inspection et la manipulation du trafic HTTP/HTTPS, permettant de comprendre en profondeur le comportement logique des applications web.

En pratique, Burp Suite est généralement utilisé pour identifier, analyser et valider les vulnérabilités web, tandis que Metasploit intervient dans un second temps pour exploiter la sous-couche système ou réseau lorsque la faille le permet.

2. Synack Sara :

Synack SARA est une plateforme de test d’intrusion assistée par IA, s’appuyant sur un système multi-agents pour orchestrer et structurer les missions de sécurité.

Proposée sous licence commerciale, cette solution agit comme un assistant pour les équipes de sécurité (red team / auditeurs). Elle permet d’industrialiser le déroulement des évaluations : priorisation des cibles, exécution guidée des phases de test, consolidation des données et génération automatique des livrables.

Face à Metasploit, les axes de force de chacun sont les suivants :

  • Forces de Synack SARA : Son point fort réside dans la gestion de la méthodologie et du processus global (structuration des audits, couverture stratégique, reporting et conformité).
  • Forces de Metasploit : Metasploit est un framework centré sur l’exécution technique, spécialisé dans la validation empirique et l’exploitation directe des vulnérabilités via son catalogue de modules (exploits et payloads).

En résumé, Synack SARA aide à cadrer, orchestrer et finaliser des campagnes de tests d’intrusion de bout en bout, tandis que Metasploit fournit l’outillage technique pour valider et automatiser l’exploitation d’une vulnérabilité spécifique.

3. XBOW Captcha Bypass Tool :

Comme son nom l’indique, cet outil est spécialisé dans le contournement des dispositifs CAPTCHA — ces mécanismes de vérification intégrés aux formulaires et pages web pour distinguer un utilisateur humain d’un script automatisé.

XBOW Captcha Bypass Tool est une solution commerciale d’évaluation automatisée basée sur l’IA. Elle vise à tester la résistance des formulaires en identifiant et en exploitant les faiblesses de mise en œuvre des CAPTCHAs (défauts de logique, réutilisation de jetons, prédictibilité).

Comparaison avec Metasploit :

  • Forces du contournement CAPTCHA dédié : Cet outil propose une approche très ciblée sur la couche d’interaction web et l’automatisation d’interface, permettant d’évaluer rapidement la robustesse des protections anti-bot.
  • Forces de Metasploit : Metasploit est un framework généraliste d’exploitation technique (exploits, payloads, post-exploitation) agissant à des niveaux plus profonds (système, réseau, services).

En pratique, l’utilisation d’outils d’automatisation contre des CAPTCHAs doit strictement s’effectuer dans un cadre légal et autorisé (tests d’intrusion dûment mandatés), car leur usage non sollicité enfreint généralement les conditions d’utilisation des services web et les réglementations en vigueur.

4. FireCompass AI-powered Pen Testing :

FireCompass est une plateforme de tests d’intrusion automatisés et continus s’appuyant sur des agents IA (agentic Red Teaming). Elle combine la cartographie de la surface d’attaque (Attack Surface Management), la découverte d’actifs et l’exécution automatique de scénarios de compromission ciblant les infrastructures, les applications web et les API.

Proposée sous licence commerciale, cette solution vise à fournir des preuves d’exploitabilité concrètes plutôt que de simples alertes, s’inscrivant ainsi dans une démarche de validation de sécurité en continu.

Son point fort réside dans l’orchestration, l’automatisation globale et la couverture continue des actifs à grande échelle, permettant de découvrir, valider et prioriser les risques de manière programmatique.

En d’autres termes, FireCompass privilégie une approche globale et continue pour évaluer la surface d’attaque d’une organisation, tandis que Metasploit reste l’outil de référence pour l’exploitation manuelle, granulaire et ciblée d’une vulnérabilité spécifique.

5. ImmuniWeb® On-Demand :

ImmuniWeb® On-Demand est une plateforme commerciale d’évaluation de la sécurité des applications web et des API, s’appuyant sur l’IA et le Machine Learning. Elle combine des analyses automatisées pour accélérer la détection de vulnérabilités avec des validations menées par des experts humains pour traiter les scénarios complexes.

La plateforme propose des couvertures alignées sur des standards du marché (OWASP, ASVS, Cloud, IAM, Red Teaming) ainsi que des livrables orientés conformité, remédiation et vérification des correctifs.

Comparé à Metasploit, son point fort réside dans la gestion globale du processus d’évaluation : génération de rapports certifiés, cartographie des risques, suivi de la remédiation et retester la sécurité après application des correctifs.

Dans la pratique, l’on pourrait s’en servir de la manière suivante : ImmuniWeb intervient pour mesurer, documenter et réduire le risque applicatif à l’échelle d’une organisation dans une logique de conformité, tandis que Metasploit procède à la validation empirique permettant d’exécuter et de prouver l’exploitabilité technique d’une faille spécifique.

6. Cobalt Strike

Cobalt Strike est souvent cité comme outil de référence pour les simulations d’attaques avancées (Red Teaming). Il est orienté post-exploitation / opérations de test/red team, avec une approche différente de Metasploit mais une logique de plateforme de command-and-control/payloads).

Contrairement à Metasploit qui met l’accent sur l’exploitation initiale des vulnérabilités, Cobalt Strike intervient principalement en post-exploitation une fois le premier accès obtenu. Son cœur de fonctionnement repose sur la gestion de serveurs de commandement et contrôle (C2) et l’injection d’un agent discret (nommé Beacon). Il permet de simuler des menaces persévérantes (APT), d’effectuer des déplacements latéraux au sein d’un réseau d’entreprise et d’évaluer la capacité de réaction des équipes de défense (Blue Team).

C’est donc une plateforme d’opérations globales orientée sur la discrétion et le maintien d’accès plutôt qu’un simple outil d’attaque ponctuel. Elle est payante et son modèle économique fonctionne sous forme de licence annuelle par utilisateur.

7.Core Impact 

Contrairement aux frameworks open-source ou communautaires, Core Impact est un logiciel commercial payant conçu spécifiquement pour les grands groupes et les équipes de sécurité d’entreprise (enterprise). Il se distingue par l’automatisation de scénarios d’attaque complexes et complets, intégrant la validation des vulnérabilités, l’escalade de privilèges et la simulation de mouvements latéraux.

Son objectif est de fournir des rapports détaillés et structurés pour prouver l’impact réel des failles auprès de la direction et des responsables de la conformité. En somme, c’est une plateforme d’exploitation « clé en main » pensée pour industrialiser et crédibiliser les tests d’intrusion en milieu corporatif.

8.Veil / Veil-Evasion

Veil (ou Veil-Evasion) est un outil spécialisé dans la génération et l’obfuscation de charges utiles (payloads). Contrairement à Metasploit, qui couvre l’ensemble de la chaîne d’attaque (de la reconnaissance à la prise de contrôle), Veil se concentre exclusivement sur le contournement des solutions de protection.

Son objectif principal est de modifier l’apparence et la structure du code exécutable afin d’échapper à la détection par les antivirus (AV) et les systèmes de détection/réponse sur les hôtes (EDR). Veil ne se substitue donc pas à Metasploit : il intervient de façon complémentaire en amont, lors de la phase de préparation de la charge utile.

9.Manuel ou framework maison

Il est rare que les équipes de sécurité expertes s’appuient à 100 % sur des outils standard du marché. Dans la pratique, les auditeurs et Red Teams combinent des actions manuelles sur mesure avec leurs propres scripts ou frameworks propriétaires (in-house). Cela leur permet de combler les lacunes des plateformes génériques comme Metasploit face à des cibles très spécifiques ou particulièrement bien protégées.

Ces outils sur mesure sont conçus pour contourner des protections particulières (antivirus, EDR), exploiter des vulnérabilités 0-day non publiques ou adapter précisément la charge utile à l’environnement visé. Enfin, cette approche hybride évite d’employer des signatures d’attaque trop connues et facilement détectables par les systèmes de défense.

Qu’il s’agisse de Metasploit dans son ensemble ou du Metasploit Framework, la puissance d’exécution d’une chaîne d’attaque ne fait aucun doute. Elle est d’autant plus impressionnante lorsque l’on maîtrise la subtilité de ses différents modules, et gagne encore en efficacité une fois couplée à d’autres outils tout aussi performants.

Le problème ? Tous ceux qui l’exploitent ne le font pas avec des intentions éthiques. Dès lors, pourquoi ne pas exploiter ce potentiel à votre avantage pour renforcer votre propre niveau de sécurité ?

Références :

Vous aimerez aussi...