Institut internationale 2i POLE POLYTECHNIQUE

Analyse et simulation des attaques de

l'homme du milieu (MITM) : Du
détournement réseau à l'exfiltration de
données.

Présente par :
IKOULE JAPHET ->220303BZ1328
MOUNTOU JUSTESSE>220303BZ1030
MAKOUEZI REINE -
>220303BZ0142
NTONDO BIKODI CELESVY-
>220303BZ0389

Sous la supervision de : M. Menet

SOMMAIRE

INTRODUCTION GÉNÉRALE

1. Contexte de la cybersécurité en environnement local

2. Définition des concepts fondamentaux

o Phishing (Hameçonnage)

o ARP Spoofing (Empoisonnement ARP)

o DNS Spoofing (Détournement DNS)

3. Objectifs de l'atelier : Comprendre l'interception de flux et le vol de données.

4. Présentation des outils utilisés

o Kali Linux, Windows (Cible), Cisco Packet Tracer et Wireshark.

PARTIE I : ANALYSE ET MODÉLISATION (CISCO PACKET TRACER)

1. Architecture du réseau simulé

o Topologie et adressage IP des équipements.

2. Mécanisme du détournement DNS

o Configuration du service DNS frauduleux.

o Observation du flux de paquets (Mode Simulation).

3. Validation de la connectivité HTTP

PARTIE II : RÉALISATION DE L'ATTAQUE (ENVIRONNEMENT RÉEL)

1. Préparation du Laboratoire Virtuel (Lab Setup)

2. Mise en place du serveur de Phishing avec SET

o Clonage de la page de connexion (Social-Engineer Toolkit).

o Configuration de l'IP de retour pour la capture des données.

3. Interception du trafic avec Ettercap

o A. Initialisation, scan du réseau et sélection des cibles.

o B. Empoisonnement de la table ARP (Man-in-the-Middle).

o C. Configuration et activation du plugin dns_spoof.

4. Résultats de l'attaque

o Capture des identifiants en temps réel (Credential Harvester).

o Analyse des logs de connexion.

PARTIE III : ANALYSE TECHNIQUE PROFONDE (WIRESHARK)

1. Analyse des paquets ARP

o Détection de l'empoisonnement entre la victime et le routeur.

2. Analyse des requêtes et réponses DNS

o Preuve visuelle de la redirection vers l'IP de l'attaquant.

3. Étude du flux HTTP POST

o Extraction des données saisies (email/mot de passe) à partir du trafic brut.

PARTIE IV : ÉVALUATION ET MESURES DE SÉCURITÉ

1. Limites de l'attaque

o Impact du protocole HTTPS et du mécanisme HSTS.

o Influence du cache DNS et du DNS over HTTPS (DoH).

2. Solutions de protection

o Bonnes pratiques pour les utilisateurs (Vigilance et 2FA).

o Sécurisation des infrastructures (DAI, DHCP Snooping).

CONCLUSION

• Bilan de l'atelier

• Ouverture sur l'importance de la sécurité pour les utilisateurs

INTRODUCTION GÉNÉRALE
1-Contexte de la cybersécurité en environnement local

Cette simulation met en exergue la facilité avec laquelle un acteur malveillant, ou un terminal
compromis à l'intérieur du réseau, peut détourner des protocoles de communication
essentiels mais vieillissants. Ces protocoles, conçus à une époque où la menace interne était
sous-estimée, présentent des lacunes structurelles :
 • L'ARP (Address Resolution Protocol) : Ce protocole de couche 2 est intrinsèquement
vulnérable car il ne possède aucun mécanisme d'authentification. Il accepte
aveuglément les réponses provenant de n'importe quelle machine, permettant ainsi
l'empoisonnement des tables de correspondance (ARP Poisoning).

• Le DNS (Domain Name System) : Bien qu'essentiel à la navigation, le DNS standard

sur un réseau local fait par défaut une confiance absolue aux réponses reçues. Sans
sécurisation (comme DNSSEC), il devient une cible privilégiée pour la redirection de
trafic vers des serveurs frauduleux.

2-Objectifs de l'atelier : Comprendre le Phishing et le DNS Spoofing

L’objectif central de cet atelier est de décomposer la chaîne d’une cyberattaque moderne
pour mieux s’en protéger. Cette simulation se concentre sur deux piliers de l’exploitation
réseau :

Maîtriser le mécanisme du DNS Spoofing (Détournement)

Le but technique est d'apprendre à manipuler la résolution de noms de domaine au sein d'un
réseau local.

• Comprendre l'empoisonnement ARP : Analyser comment un attaquant peut

s'interposer entre une victime et sa passerelle (Man-in-the-Middle) pour intercepter
le trafic.

• Falsification de l'identité réseau : Démontrer comment forcer un équipement cible à

associer un nom de domaine légitime (ex: [Link]) à une adresse IP
frauduleuse (celle de l'attaquant) au lieu de l'IP réelle du serveur distant.

Analyser le vecteur d'attaque par Phishing (Hameçonnage)

Au-delà de l'aspect réseau, l'atelier vise à étudier l'ingénierie sociale appliquée au web :

• Simulation de clonage de services : Utiliser des outils comme SETOOLKIT pour

reproduire une interface de connexion crédible, capable de tromper la vigilance de
l'utilisateur.

• Extraction de données critiques : Observer comment les informations saisies par la

victime (identifiants, mots de passe) sont transmises en clair sur le réseau et
capturées par l'attaquant.

1. 3-Présentation des outils utilisés

La simulation s'appuie sur quatre outils complémentaires couvrant l'ensemble du cycle

d'audit :
 • VirtualBox : L'infrastructure de base. Il assure le cloisonnement et la communication
(via le mode Bridged) entre la machine attaquante et la victime dans un
environnement virtuel sécurisé.

• Kali Linux : Le centre d'opérations. Il fournit les outils d'exécution : Ettercap pour le
détournement réseau (ARP/DNS Spoofing) et SET pour la création du piège (Phishing).

• Wireshark : L'outil d'expertise. Il sert de "microscope" pour capturer le trafic brut,

apportant la preuve irréfutable du détournement des paquets et du vol des
identifiants en clair.

• Cisco Packet Tracer : Le support théorique. Il permet de modéliser la topologie et de

visualiser le comportement des protocoles (OSI) de manière schématique avant la
phase pratique.

PARTIE I : ANALYSE ET MODÉLISATION (CISCO PACKET TRACER)

1-Architecture du réseau simulé

La topologie repose sur un environnement virtuel simulant un réseau local (LAN) standard.
L'objectif est de reproduire une interaction entre un client interne, un switch et un serveur
de confiance, tout en y introduisant une machine attaquante.

• Topologie et adressage IP des équipements

L'ensemble des équipements est configuré sur un réseau local (LAN) unique utilisant le
masque de sous-réseau /24 (soit [Link]).

• Machine Attaquante (Serveur Attaquant) :

o IP : [Link]

o Rôle : Héberge Kali Linux, le Social-Engineer Toolkit (SET) pour le phishing et

Ettercap pour l'empoisonnement ARP.

• Machine Cible 1 :

o IP : [Link]

o Rôle : Premier utilisateur victime tentant d'accéder aux services web.

• Machine Cible 2 :

o IP : [Link]

o Rôle : Deuxième utilisateur permettant de tester la portée de l'attaque sur

plusieurs postes simultanément.

• Serveur DNS :

o IP : [Link]

o Rôle : Serveur légitime chargé de résoudre les noms de domaine en adresses

 IP.

• Serveur Web :

o IP : [Link]

o Rôle : Serveur hébergeant le site internet réel que les cibles souhaitent
consulter.

• Équipement d'interconnexion (Switch) :

o Rôle : Commutateur central permettant la liaison physique et logique entre

tous les nœuds du réseau.

2-Mécanisme du détournement DNS

• Configuration du service DNS frauduleux

L'attaque se déroule en quatre étapes clés, transformant une requête légitime en une
capture d'identifiants :

• A. Empoisonnement ARP (L'interception) : L'attaquant (.18) usurpe l'identité du

serveur DNS (.11) auprès des cibles (.10 et .13). Il devient l'intermédiaire obligé
(MITM) : tout le trafic passe désormais par sa machine.

• B. Interception DNS : Lorsqu'une victime demande l'adresse IP d'un site (ex:

[Link]), la requête arrive directement sur la machine de l'attaquant au lieu
du vrai serveur.

• C. Réponse falsifiée (Le "Spoof") : L'attaquant envoie immédiatement une réponse

DNS mensongère. Il affirme que le site demandé se trouve à l'adresse [Link]
(sa propre IP) au lieu de la véritable IP du serveur web (.12).

• D. Redirection et Phishing : Le navigateur de la victime, trompé, se connecte au

serveur de l'attaquant. Celui-ci affiche une copie parfaite du site original (via SET) et

• Capture les identifiants saisis en clair.

 • Observation du flux de paquets (Mode Simulation)

3-Validation de la connectivité HTTP

L'objectif est de confirmer que le détournement est opérationnel et totalement invisible

pour la victime :

• Vérification du routage (Ping) : Un test ping vers le nom de domaine (ex:

[Link]) depuis la cible (.10) confirme que le nom est désormais résolu vers
l'IP de l'attaquant (.18) et non plus vers le serveur réel.
 • Accès au service Web : L'ouverture de l'URL dans le navigateur de la victime
déclenche l'affichage immédiat de la page clone hébergée sur la machine attaquante.
La connexion TCP/IP est techniquement valide, ce qui permet le chargement du site.

• Transparence de l'attaque : La simulation démontre qu'aucun message d'erreur

réseau n'est généré. La proximité de l'attaquant sur le réseau local garantit un temps
de réponse rapide, rendant l'interception indétectable pour un utilisateur non averti.

Conclusion de la phase 1 : Le réseau est compromis. La victime est connectée au serveur de

l'attaquant en pensant naviguer sur un site de confiance.

PARTIE II : RÉALISATION DE L'ATTAQUE (ENVIRONNEMENT RÉEL)

1. Préparation du Laboratoire Virtuel (Lab Setup)

La réussite de l'attaque dépend entièrement de la configuration de l'hyperviseur VirtualBox.

Nous avons mis en place un environnement où l'attaquant et les victimes partagent le même
segment de communication.

A. Configuration du réseau virtuel

Toutes les machines virtuelles (VM) doivent être capables d'échanger des trames de couche
2.

• Mode de carte réseau : Nous avons opté pour le mode "Réseau par pont" (Bridged).
Ce choix permet à chaque VM d'obtenir une adresse IP directement auprès du
routeur local, les plaçant ainsi sur le même plan logique que des machines physiques
réelles.

B. Déploiement des instances

Le laboratoire mobilise trois types de systèmes :

1. Le Pivot (Kali Linux) : Machine principale équipée de la suite de test (IP :

[Link]).
 2. Les Cibles (Windows 10) : Postes clients simulant des utilisateurs en entreprise (IP :
[Link]).

3. L'Infrastructure (Serveurs simulés) : Services DNS (.11) du routeur physique, Web

déployer par le setoolkit par kali nécessaires pour valider le détournement.

C. Test de "Santé" du Réseau

Avant de lancer SET ou Ettercap, une phase de vérification est indispensable :

• Ping Test : On s'assure que Kali peut joindre la cible windows et que la cible peut
joindre kali

Ping KALI -> windows réussi Ping windows10 -> KALI reussi 2-Mise en place du serveur
de Phishing avec SETOOLKIT

L'efficacité d'une attaque repose sur la crédibilité de l'interface présentée à la victime. Pour
cet atelier, nous utilisons SETOOLKIT, un Framework d'automatisation d'attaques par
ingénierie sociale intégré à Kali Linux.

Démarrage du SETOOLKIT

Commande a taper dans le terminale de kali « SETOOLKIT »

Utilisation d'un Modèle de Connexion (Web Templates)

Plutôt que de cloner dynamiquement un site distant (ce qui peut parfois échouer si le site
cible possède des protections anti-clonage), nous avons opté pour l'utilisation des Web
Templates intégrés à SET.

• Menu Principal : Sélection de l'option 1) Social-Engineering Attacks.

• Vecteur d'Attaque : Choix de l'option 2) Website Attack Vectors.
• Méthode de Capture : Sélection de l'option 3) Credential Harvester Attack Method.
• Choix de la Source : Sélection de l'option 1) Web Templates.

• Avantages Techniques :

o Fiabilité : Les modèles (Google, Facebook, Twitter, Java Update, etc.) sont
préconfigurés pour capturer exactement les variables POST (identifiants et
mots de passe).

o Rapidité : Pas de temps de téléchargement des ressources distantes ; le

serveur de phishing est opérationnel instantanément.

o Camouflage : Ces modèles sont conçus pour être légers et s'afficher

parfaitement sur tous les navigateurs, minimisant les doutes de la victime.
 • Configuration de l'IP de retour pour la capture des données

Cette étape consiste à transformer le modèle de page choisi en un piège actif capable de
récupérer et de stocker les informations de la victime.

• LHOST ([Link]) : L'adresse de la machine Kali est injectée dans le code HTML
de la page. Elle remplace l'adresse officielle du site pour que les identifiants soient
envoyés directement à l'attaquant via une requête HTTP POST.

• Stratégie du Modèle : L'efficacité de l'attaque repose sur la crédibilité de l'interface.

En utilisant le Template Google, nous exploitons un environnement familier pour
l'utilisateur. Cette reconnaissance visuelle immédiate permet de mettre la cible en
confiance et de baisser son niveau de vigilance au moment de saisir ses identifiants,
Une fois la configuration terminée, le serveur web du SEToolkit est instantanément
déployé sur le port 80. À ce stade, le "Credential Harvester" est en mode écoute, prêt
à capturer toute donnée qui transitera par son interface. Le piège est désormais armé
et fonctionnel. Il ne reste plus qu'à configurer Ettercap pour détourner le flux réseau
de la victime vers ce serveur frauduleux.
A. Initialisation, Scan du réseau et sélection des cibles

L'attaque commence par une phase d'énumération via l'interface d'Ettercap (Unified Sniffing)
:

Lancement de l'interface : Nous exécutons la commande ettercap -G dans le terminal

Kali pour ouvrir l'interface graphique.

1. Scan des hôtes (Hosts Scan) : Nous lançons un balayage du sous-réseau pour lister
toutes les machines actives.

2. Choix des cibles (Target Selection) : Une fois la liste établie, nous isolons les deux
points de communication critiques :

o Target 1 (La Passerelle) : Nous sélectionnons l'IP du routeur (ex: [Link]).

C'est elle qui gère l'accès à Internet.

o Target 2 (La Victime) : Nous sélectionnons l'IP de la machine cible (ex:

[Link]).
 3. Validation : Cette sélection "bilatérale" est essentielle pour se placer au milieu de la
conversation (Man-in-the-Middle) et intercepter le flux montant (requêtes) et
descendant (réponses).

B. Empoisonnement de la table ARP (Man-in-the-Middle)

Une fois les cibles verrouillées, nous activons l'ARP Poisoning.

• Mécanisme : Nous envoyons des messages ARP falsifiés de manière bidirectionnelle.

Nous faisons croire au routeur que nous sommes la victime, et à la victime que nous
sommes le routeur.

• Résultat : Tout le trafic circulant entre ces deux équipements transite désormais
physiquement par notre machine Kali Linux, nous rendant totalement "invisible" sur
le trajet des paquets.

C. Configuration et activation du plugin dns_spoof

L'interception physique étant établie, nous activons le détournement logique :

1. Le fichier [Link] : Modification du fichier pour lier le domaine [Link] à l'IP de

notre machine Kali ([Link]).

2. Activation du plugin : Le lancement de dns_spoof permet à Ettercap de répondre aux

requêtes DNS de la victime en priorité, substituant l'IP réelle du site par celle de notre
serveur de Phishing.
4. Résultats de l'attaque

Une fois le détournement réseau (Ettercap) et le serveur de phishing (SET) synchronisés,

l'attaque entre dans sa phase active. Les résultats sont instantanés dès que la victime tente
de naviguer sur le web.

A. Capture des identifiants en temps réel (Credential Harvester)

Le succès de l'interception se manifeste directement dans le terminal de la Kali Linux.

• Déclenchement : Lorsque la victime saisit [Link], elle est redirigée vers notre IP
locale. Pensant être sur la page officielle, elle entre ses identifiants.
 • Réception : Le module Credential Harvester de SET intercepte la requête HTTP POST.
Les informations apparaissent en clair (souvent en rouge dans le terminal), affichant
précisément les champs email, password et l'adresse IP de la source.

• Expérience utilisateur : Pour ne pas éveiller de soupçons, après avoir validé le

formulaire, la victime est automatiquement redirigée vers le véritable site de Google.
Elle peut penser à un simple bug de rafraîchissement, alors que ses accès sont déjà
compromis.

PARTIE III : ANALYSE TECHNIQUE PROFONDE (WIRESHARK)

L'utilisation de Wireshark permet de valider scientifiquement l'attaque en observant le

comportement des protocoles au niveau microscopique. C'est l'étape de l'autopsie des
paquets.

1. Analyse des paquets ARP (Preuve du MITM)

L'observation du trafic ARP confirme l'empoisonnement de la table de correspondance :

• Détection de l'anomalie : Nous observons des paquets "ARP Reply" non sollicités
envoyés à la victime et au routeur.
 • Conflit d'adresse : L'analyse montre que deux adresses IP distinctes (le routeur et la
machine Kali) sont désormais associées à la même adresse MAC (celle de l'attaquant)
dans le cache de la victime.

• Résultat : Le flux est officiellement intercepté ; la machine Kali est devenue le passage
obligé de tout le trafic.

2. Analyse des requêtes et réponses DNS (Preuve du Spoofing)

Nous suivons le trajet d'une requête de résolution de nom effectuée par la cible :

• Requête DNS : La victime demande l'adresse IP de [Link].

• Réponse falsifiée : Wireshark capture la réponse immédiate générée par le plugin

dns_spoof d'Ettercap. Au lieu de l'IP réelle de Google, la réponse contient l'IP de
l'attaquant ([Link]).

• Preuve visuelle : La redirection est flagrante : le navigateur de la victime est dirigé

vers notre serveur de phishing sans qu'aucune erreur ne soit levée au niveau DNS.

3. Étude du flux HTTP POST (Extraction des données)

C'est l'étape finale où l'on visualise le vol d'informations dans le trafic brut :

• Filtrage HTTP : En filtrant les paquets sur la méthode POST, nous isolons le moment
où la victime valide le formulaire.

• Analyse du "HTML Form URL Encoded" : En ouvrant le détail du paquet, les

identifiants apparaissent en texte clair.

• Données extraites : Nous récupérons directement les variables saisies (ex:

email=victime@[Link] et password=123456). Cela démontre que malgré
l'apparence de la page, aucune couche de chiffrement (SSL/TLS) n'était active sur ce
lien frauduleux.
PARTIE IV : ÉVALUATION ET MESURES DE SÉCURITÉ

1. Limites de l'attaque

Bien que spectaculaire en environnement de test, cette attaque rencontre des obstacles
majeurs dans un contexte moderne et sécurisé.

• Impact du protocole HTTPS et du mécanisme HSTS : Le HSTS (HTTP Strict Transport

Security) est une politique de sécurité qui force les navigateurs à n'utiliser que des
connexions HTTPS. Si la victime a déjà visité le vrai site Google, son navigateur
refusera de se connecter à notre serveur SET s'il ne présente pas un certificat SSL
valide et reconnu, affichant une alerte de sécurité critique ("Votre connexion n'est pas
privée").

• Influence du cache DNS et du DNS over HTTPS (DoH) : * Si la victime possède déjà
l'IP réelle dans son cache DNS local, elle ne fera pas de requête et notre dns_spoof
sera inefficace.

o Le DoH chiffre les requêtes DNS via le port 443. Ettercap ne peut alors plus
intercepter ou modifier les réponses DNS à la volée, car elles passent dans un
tunnel chiffré illisible pour l'attaquant.

2. Solutions de protection

Pour contrer ces menaces, des mesures doivent être prises tant au niveau humain qu'au
niveau des infrastructures.

• Bonnes pratiques pour les utilisateurs :

o Vigilance : Toujours vérifier la présence du cadenas et l'exactitude du nom de

domaine dans la barre d'adresse.

o 2FA (Double Authentification) : Même si l'attaquant capture le mot de passe,

il ne pourra pas accéder au compte sans le code temporaire envoyé sur le
téléphone de la victime.

• Sécurisation des infrastructures :

 o DAI (Dynamic ARP Inspection) : Une fonctionnalité sur les commutateurs
(Switch) qui vérifie la validité des paquets ARP et bloque les tentatives
d'empoisonnement.

o DHCP Snooping : Empêche l'utilisation de serveurs DHCP pirates et aide à

construire une table de correspondance IP/MAC fiable pour le DAI.

CONCLUSION

1. Bilan de l'atelier

Cet atelier nous a permis de comprendre techniquement comment une faille de confiance
dans les protocoles de base (ARP et DNS) peut conduire à une compromission totale des
données utilisateur. La modélisation sur Cisco Packet Tracer a validé la théorie, tandis que la
pratique sur Kali Linux a démontré la simplicité d'exécution pour un attaquant bien outillé.

2. Ouverture sur l'importance de la sécurité

La cybersécurité n'est pas seulement une question d'outils, mais de culture. Alors que les
techniques d'attaque comme le DNS Spoofing deviennent plus complexes à réaliser face aux
protocoles chiffrés, l'ingénierie sociale reste le maillon faible. La sensibilisation des
utilisateurs et l'adoption systématique du MFA (Multi-Factor Authentication) sont aujourd'hui
les remparts les plus efficaces pour protéger nos infrastructures numériques.