MITM

01 — DéfinitionQu'est-ce qu'un MITM ?

Une attaque Man-in-the-Middle (MITM, littéralement « homme du milieu ») est une attaque où un attaquant s'insère dans une communication entre deux parties qui croient communiquer directement entre elles. L'attaquant peut intercepter, lire, et aussi modifier les échanges en transit.

L'image mentale

Alice écrit à Bob. Une personne au milieu (Mallory dans la terminologie crypto) intercepte la lettre, en fait une copie, peut la modifier, et la fait suivre à Bob. Ni Alice ni Bob ne savent qu'il y a un intermédiaire. Le MITM fonctionne partout où des données transitent entre deux points — réseau IP, ondes radio, fibre, DNS, BGP.

Les deux modes

• Passif (écoute) : l'attaquant lit les communications sans les modifier. Plus discret, laisse moins de traces. Objectif : collecte de renseignements, vol de credentials, espionnage.
• Actif (altération) : l'attaquant modifie les messages en transit. Plus dangereux : injection de malwares dans des téléchargements, modification de données, fausse réponses d'API.

Terminologie moderne

Plusieurs acronymes désignent la même famille d'attaques :

• MITM : terme historique, encore le plus utilisé.
• MitM : variation orthographique.
• AitM (Adversary-in-the-Middle) : terme privilégié par Microsoft, CISA, MITRE depuis 2022 pour la variante moderne via proxy de phishing.
• Machine-in-the-Middle : neutralisation linguistique récente.
• Meddler-in-the-Middle : usage moins courant.
• Monster-in-the-Middle (MitM) : usage informel.

La distinction moderne : MITM classique désigne les attaques réseau (Wi-Fi, ARP, DNS). AitM désigne les proxies de phishing contournant la MFA. Les deux sont techniquement des MITM, mais la surface d'attaque et les défenses diffèrent.

Ce que permet un MITM

• Vol de credentials : mots de passe, tokens, sessions.
• Vol de cookies : détournement de sessions authentifiées.
• Vol de données sensibles : emails, documents, conversations.
• Injection de malwares : modification de téléchargements à la volée.
• Injection de code : ajout de JavaScript dans les pages HTML.
• Fraude financière : modification de coordonnées bancaires lors d'une transaction.
• Espionnage : suivi des communications d'une cible.
• Déni de service : blocage ou corruption sélective.
• Contournement MFA : cas AitM, dominant aujourd'hui.

Le MITM est l'attaque qui matérialise la vieille question cryptographique : comment savoir à qui vous parlez vraiment ? Sans mécanisme d'authentification solide (certificats, clés publiques), une communication reste vulnérable à un tiers qui s'interpose. C'est tout l'intérêt d'une infrastructure à clé publique.

02 — FonctionnementComment un attaquant s'insère

Les conditions nécessaires

Pour réussir un MITM, l'attaquant doit :

• Être en position de voir le trafic : même réseau, opérateur, ou capable de rediriger le trafic.
• Contourner les protections cryptographiques (HTTPS, HSTS) si présentes.
• Éviter la détection : ne pas alerter la victime ni les systèmes de sécurité.

Les phases d'une attaque MITM classique

1. Se positionner

L'attaquant se place dans une position d'interception :

• Wi-Fi public : café, aéroport, hôtel.
• Réseau local compromis : LAN entreprise ou domestique.
• Opérateur malveillant : FAI compromis, backdoor opérateur télécom.
• Point de peering/échange : IXP compromis, route BGP détournée.
• Faux point d'accès : evil twin avec SSID proche du légitime.
• Appareil compromis : routeur, switch, imprimante, caméra infectés.

2. Rediriger le trafic

Selon la couche attaquée :

• ARP spoofing : l'attaquant envoie des réponses ARP forgées qui font passer son appareil pour la passerelle réseau. Tout le trafic du LAN passe par lui.
• DNS spoofing : réponses DNS falsifiées qui dirigent vers un serveur attaquant.
• DHCP rogue : faux serveur DHCP qui fournit des paramètres réseau malveillants.
• Wi-Fi evil twin : SSID visible et plus fort que le légitime.
• BGP hijacking : annonces BGP forgées qui redirigent tout un bloc IP.

3. Intercepter et traiter

Une fois le trafic capturé :

• Lecture passive : Wireshark, tcpdump pour analyser.
• Altération active : proxy transparent (mitmproxy, Bettercap, sslsplit) qui modifie en transit.
• SSL stripping : dégrader HTTPS en HTTP si la victime tape juste example.com sans https://.
• Injection de code : ajout de scripts dans les pages HTML en clair.
• Remplacement de téléchargements : substitution d'installeurs par des versions piégées.

4. Extraction / exploitation

• Stockage des credentials capturés.
• Réutilisation immédiate des sessions.
• Vente sur le dark web.
• Cas AitM : connexion immédiate avec le cookie capturé avant qu'il n'expire.

Outils des attaquants

• Bettercap : framework suisse du MITM, remplace ettercap. ARP, DNS, SSL stripping, HTTP proxy.
• mitmproxy : proxy interactif pour inspection et modification HTTPS (avec certificat installé côté victime — usage légitime pour debug).
• Wireshark / tcpdump : capture et analyse passive.
• Responder : exploitation LLMNR/NBT-NS pour capturer des hashs NTLM sur Windows.
• Wi-Fi Pineapple : matériel spécialisé pour Wi-Fi MITM.
• Evilginx, Modlishka, EvilProxy : proxies de phishing AitM.
• sslstrip : historique, dégradation HTTPS→HTTP.

Pourquoi HTTPS ne suffit pas toujours

HTTPS empêche la lecture du contenu par un MITM standard, mais plusieurs contournements existent :

• SSL stripping : si la victime tape example.com dans le navigateur (sans https://), la première requête est en HTTP. Un MITM peut la servir en HTTP et proxy vers HTTPS côté serveur, la victime voit du HTTP sans alerte si elle ne vérifie pas l'icône.
• Certificats malveillants : CA compromise, certificat installé dans le navigateur (entreprise avec MITM légitime pour inspection).
• Downgrade attacks : POODLE, BEAST historiques, FREAK, Logjam — forcer le serveur à utiliser des protocoles faibles.
• HSTS non configuré sur la première visite — bypass possible.
• Subdomain takeover : sous-domaine orphelin avec contrôle attaquant.

HTTPS est nécessaire mais pas suffisant. Il faut le combiner avec HSTS preload, pinning pour apps critiques, DNS sécurisé, et vigilance côté utilisateur.

03 — TypesLes grandes familles d'attaques MITM

MITM sur réseau local (Layer 2)

ARP spoofing / ARP poisoning

Le protocole ARP fait le lien entre adresses IP et adresses MAC sur un réseau local. Pas d'authentification — chaque machine fait confiance aux réponses ARP. Un attaquant envoie des réponses forgées annonçant que l'adresse MAC de la passerelle est son propre MAC. Les machines du réseau envoient alors leur trafic à lui au lieu de la passerelle. Outil classique : Bettercap, arpspoof. Protection : port security, dynamic ARP inspection, segmentation.

DHCP rogue

Un faux serveur DHCP répond avant le vrai à une machine demandant une adresse IP, imposant ses paramètres (DNS malveillant, passerelle attaquante). Protection : DHCP snooping sur les switches, 802.1X.

STP / VLAN hopping

Manipulations plus avancées du protocole Spanning Tree ou du trunking VLAN pour s'insérer. Rares, cibles typiques : infrastructures d'entreprise.

MITM sur Wi-Fi

Réseau Wi-Fi non chiffré

Un attaquant sur le même réseau Wi-Fi ouvert voit tout le trafic non chiffré par défaut. Les cafés, aéroports, hôtels restent des surfaces d'attaque typiques. Moins critique aujourd'hui grâce à HTTPS mais métadonnées et applications legacy restent exposées.

Evil Twin (jumeau maléfique)

L'attaquant crée un faux point d'accès avec un SSID proche ou identique à celui d'un lieu fréquenté (« Starbucks_Free_WiFi », « SNCF_Gratuit »). Signal plus fort que l'original pour attirer les connexions. Les victimes se connectent croyant au vrai réseau. Une fois connectées, tout leur trafic passe par l'attaquant. Très utilisé dans les aéroports.

KARMA attack / Wi-Fi Pineapple

Exploitation de la liste des SSID mémorisés par les appareils. Le téléphone d'une victime cherche activement son SSID domicile (« LIVEBOX-ABC »). Le Wi-Fi Pineapple répond « Oui c'est moi » et le téléphone se connecte automatiquement. MITM établi sans action de la victime.

KRACK (2017)

Vulnérabilité majeure dans le protocole WPA2 permettant un MITM. Patches déployés largement mais appareils embarqués/IoT non mis à jour restent vulnérables. Démontre que même un Wi-Fi « sécurisé » peut être attaquable.

MITM sur couche réseau/application

DNS hijacking / DNS spoofing

L'attaquant manipule les réponses DNS pour rediriger les victimes vers des serveurs malveillants. Variantes :

• DNS cache poisoning : injection de réponses forgées dans le cache d'un résolveur.
• Routeur compromis : configuration DNS modifiée (serveurs DNS malveillants).
• Registrar compromis : modification des serveurs DNS officiels d'un domaine.
• Malware local : modification du fichier hosts ou des paramètres DNS.

Cas majeur : 2019 DNSpionage — attribué à l'Iran, compromission massive de registrars et DNS au Moyen-Orient et en Europe.

SSL stripping

Technique découverte par Moxie Marlinspike (2009). Quand une victime tape example.com (sans https://), la première requête est en HTTP. Un MITM sert la page en HTTP, en modifiant les liens de https:// vers http://. La victime ne voit jamais le HTTPS, ses communications restent en clair. Protection : HSTS, HSTS preload.

BGP hijacking

Protocole BGP qui route le trafic entre opérateurs Internet — pas d'authentification historique. Un opérateur annonce malicieusement qu'il a la meilleure route vers un bloc IP cible, captant tout le trafic vers ce bloc. Cas connus : 2008 YouTube détourné par Pakistan Telecom (erreur), 2018 Amazon Route 53 détourné pour voler des cryptos, multiples cas attribués à la Russie ou Chine. Protection : RPKI (Route Origin Validation), progressivement adopté.

Certificate-based attacks

• Compromission CA : DigiNotar 2011 — autorité de certification néerlandaise compromise, certificats frauduleux émis pour Gmail utilisés contre dissidents iraniens. DigiNotar a fait faillite.
• Rogue CA : autorité malveillante ajoutée au trust store (corporate proxy légitime ou malicieux).
• Certificat de sécurité en entreprise : les proxy inspection (Zscaler, Netskope, Bluecoat) font du MITM légitime avec certificat racine poussé sur les postes, permettant l'inspection HTTPS.

MITM sur applications spécifiques

• SMB relay : capture d'authentification NTLM et relais vers une autre machine pour obtenir accès.
• SSH MITM : possible si l'utilisateur accepte un nouveau host key sans vérifier.
• RDP MITM : via certificat non vérifié.
• Applications mobiles : absence de certificate pinning, acceptation de certificats invalides.
• Emails (SMTP en clair) : historiquement MITM sur relais SMTP — aujourd'hui remédié par TLS mais pas universel.

04 — AitM moderneLe contournement de la MFA

Le tournant 2022-2023

L'Adversary-in-the-Middle (AitM) est devenu le vecteur dominant de compromission de comptes cloud depuis 2022. Principe : au lieu d'une page de phishing statique qui capture juste les identifiants, l'attaquant déploie un proxy transparent entre la victime et le vrai site cible.

Le mécanisme

1. Victime reçoit un phishing avec URL piégée (microsoft365-contoso-auth.com au lieu de login.microsoftonline.com).
2. Victime clique, arrive sur le proxy attaquant.
3. Proxy affiche une vraie page de login (interrogeant en live le vrai serveur).
4. Victime entre username/password → proxy les transmet au vrai site → vrai site demande MFA.
5. Proxy relaie la demande MFA à la victime, qui voit l'interface normale.
6. Victime entre le code MFA (ou approuve la notification push) → relayé au vrai site.
7. Vrai site authentifie la session, renvoie un cookie de session.
8. Proxy capture le cookie et l'utilise pour se connecter en tant que la victime.

Pourquoi c'est efficace

• Contourne la MFA classique : TOTP, SMS, notifications push, toutes les MFA basées sur challenge sont relayées transparemment.
• Invisible pour la victime : elle voit la vraie interface, peut même se reconnecter sans anomalie visible.
• Cookie de session réutilisable : tant qu'il n'expire pas, l'attaquant peut l'utiliser ailleurs.
• MFA fatigue optionnelle : combinable avec spam de notifications push.

Outils de l'écosystème AitM

• Evilginx : framework open source créé par Kuba Gretzky, largement utilisé (red teams et attaquants). Modules pour Office 365, Google, Okta, Facebook, LinkedIn. Utilise Nginx comme proxy.
• Modlishka : autre framework open source, approche différente.
• EvilProxy (commercial sur dark web) : « phishing-as-a-service », 200-600 USD/mois, cible les services cloud majeurs. Populaire chez les cybercriminels non techniques.
• Tycoon 2FA : autre service commercial émergent.
• Caffeine : plateforme PhaaS découverte par Mandiant 2022.

Cibles principales

• Microsoft 365 / Entra ID : cible #1 car l'accès à un compte donne souvent accès aux emails, Teams, SharePoint, OneDrive.
• Google Workspace : similaire.
• Services financiers : banques, crypto-exchanges.
• Okta, Duo, Ping : services d'authentification, accès critique.
• Réseaux sociaux / apps SaaS : LinkedIn, Salesforce, AWS.

Indicateurs d'attaque AitM

• URL de connexion différente du domaine légitime (typosquatting ou IDN homographe).
• Certificat TLS valide mais domaine inhabituel.
• Connexions détectées depuis des IP / pays anormaux.
• Multiples tentatives de MFA en peu de temps.
• Cookies de session utilisés depuis plusieurs emplacements.
• Volumes anormaux d'authentification réussie depuis IPs nouvelles.

Pourquoi les passkeys sont la solution

Les passkeys et FIDO2 sont structurellement résistants à l'AitM grâce à la liaison cryptographique au domaine. Le processus :

• La clé cryptographique est générée pour un domaine spécifique (login.microsoftonline.com).
• L'authentification exige que le domaine courant corresponde au domaine enregistré.
• Un proxy sur microsoft365-contoso-auth.com n'a pas le bon domaine → la clé refuse de signer.
• L'attaquant ne peut pas « relayer » une passkey comme il peut relayer un code TOTP.

C'est pourquoi Microsoft, Google, Apple ont poussé massivement les passkeys depuis 2023. Les entreprises avec déploiement de passkeys sur comptes admins voient leurs incidents AitM chuter significativement.

Autres défenses anti-AitM

• Conditional Access : Microsoft Entra, Okta évaluent le risque de chaque connexion (device compliant, géolocalisation, ASN, comportement) et peuvent bloquer ou exiger une confirmation.
• Device compliance : exiger que l'appareil soit managé pour accéder aux ressources sensibles.
• Session binding : lier les cookies à l'appareil/IP pour empêcher leur réutilisation ailleurs. Token Binding (TLS) en évolution.
• Durée de session courte sur services sensibles.
• Monitoring : détection de connexions anormales dans SIEM.
• Sensibilisation au phishing : la plupart des AitM commencent par un email.

05 — ExemplesIncidents historiques marquants

DigiNotar (2011)

Autorité de certification néerlandaise compromise. L'attaquant a émis des centaines de certificats frauduleux, notamment pour *.google.com, utilisés pour faire du MITM sur Gmail contre 300 000 Iraniens suspectés par le régime iranien. DigiNotar a fait faillite dans les semaines suivantes. Événement qui a conduit à :

• Renforcement des exigences CA (audits WebTrust).
• Émergence de Certificate Transparency (obligatoire depuis 2018).
• Prise de conscience de la fragilité du modèle PKI.

Superfish / Lenovo (2014-2015)

Scandale majeur : Lenovo a pré-installé sur ses laptops un adware nommé Superfish qui installait un certificat racine malveillant pour faire du MITM sur HTTPS et injecter des publicités. La clé privée était la même sur tous les appareils et a été rapidement divulguée, permettant à n'importe quel attaquant de faire du MITM sur les utilisateurs Lenovo. Retrait massif, actions en justice, amende FTC. Illustre le risque des racines de confiance non maîtrisées.

DNSpionage (2017-2019)

Campagne sophistiquée attribuée à l'Iran, ciblant des gouvernements et infrastructures au Moyen-Orient, Europe, Amérique du Nord. Méthode :

• Compromission de registrars et fournisseurs DNS.
• Modification des enregistrements DNS de cibles pour rediriger vers des serveurs attaquants.
• Émission de certificats TLS valides via Let's Encrypt pour les domaines détournés.
• Interception d'emails, credentials, VPN d'organisations ciblées.

Documenté par Cisco Talos, FireEye. CISA a émis une alerte d'urgence en janvier 2019 exigeant le changement immédiat des comptes DNS de toutes les agences fédérales américaines.

KRACK (octobre 2017)

Vulnérabilité découverte par Mathy Vanhoef dans le protocole WPA2 utilisé par la quasi-totalité des Wi-Fi sécurisés de l'époque. Permet à un attaquant à portée radio de faire du MITM via une faille dans le 4-way handshake. Patches massifs déployés dans les semaines suivantes (Windows, macOS, Android, iOS, routeurs), mais de nombreux appareils IoT jamais patchés restent vulnérables encore aujourd'hui. A conduit au développement accéléré de WPA3 qui corrige les défauts de conception.

BGP hijacks majeurs

• 2008 — Pakistan Telecom détourne YouTube : erreur de configuration BGP, YouTube globalement inaccessible pendant quelques heures.
• 2014 — Canadian ISP détourne Bitcoin : $83 000 en cryptos volés via redirection BGP des pools de minage.
• 2018 — Amazon Route 53 détourné : $150 000 volés via DNS→AWS→cryptos.
• 2022 — BGP attack sur Klayswap : $1,9M de cryptos volés.
• Incidents réguliers attribués à la Chine, Russie : détournements de trafic, souvent pour surveillance.

Vague AitM Microsoft 365 (2022+)

Microsoft Threat Intelligence a publié en juillet 2022 un rapport majeur sur une campagne AitM affectant 10 000+ organisations depuis septembre 2021. Outils : Evilginx2 déployé sur proxies attaquants. Cibles : credentials Microsoft 365 utilisés ensuite pour BEC (Business Email Compromise). Depuis, la catégorie AitM domine les incidents de compromission de comptes cloud, Microsoft annonçant des millions de tentatives bloquées par mois.

Okta breach via AitM (2022-2023)

Le groupe Lapsus$ a compromis plusieurs entreprises majeures (Microsoft, Nvidia, Samsung, Okta, Uber) en utilisant des techniques incluant AitM et MFA fatigue. Impact notable sur Okta qui a dû reconnaître une compromission d'un sous-traitant conduisant à des risques pour ses clients.

Leçons récurrentes

• PKI fragile : une seule CA compromise peut compromettre des millions d'utilisateurs.
• Appareils livrés compromis : Superfish illustre le risque supply chain.
• Infrastructure DNS critique : DNSpionage montre l'impact d'un pivot DNS.
• Protocoles historiques fragiles : WPA2, BGP sans authentification — héritage à remplacer.
• MFA n'est pas infaillible : l'AitM l'a démontré massivement depuis 2022.
• Passkeys comme réponse : évolution structurelle de l'authentification.

06 — ProtectionBonnes pratiques à tous les niveaux

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

07 — FAQQuestions fréquentes

Un Wi-Fi public est-il encore dangereux en 2026 ?

Beaucoup moins qu'il y a 10 ans grâce à HTTPS quasi universel. Un attaquant sur un Wi-Fi public voit qu'on visite un site mais pas ce qu'on y fait. Les principales protections de 2026 : 95%+ du trafic web en HTTPS, HSTS empêche le SSL stripping, apps mobiles avec certificate pinning. Risques résiduels : quelques sites restent en HTTP, les métadonnées fuitent (quel site visité), Evil Twin peut tromper la victime avec SSID similaire, attaques sur applications legacy mal configurées. Bonne pratique : utiliser un VPN personnel en Wi-Fi public pour les actions sensibles reste une protection efficace et peu coûteuse. Ne pas faire de transactions bancaires ou connexions sensibles sur Wi-Fi public sans VPN par simple prudence.

Comment détecter qu'on est victime d'un MITM ?

Indicateurs techniques : avertissement de certificat du navigateur (« certificat non valide », « autorité inconnue »), certificat avec CN ou SAN bizarres, chaîne de certification courte ou anormale, URLs subtilement différentes du site attendu (typosquatting), redirections multiples avant d'arriver au site, demandes de reconnexion dans des contextes inattendus (après un clic sur un lien), icône HTTPS absente sur un site qui devrait l'avoir. Indicateurs réseau (en entreprise) : alertes Wireshark/IDS sur patterns ARP spoofing, changements MAC de la passerelle, serveurs DHCP multiples. Dans l'AitM, la victime ne voit typiquement rien car l'interface est fidèle — d'où l'importance de la détection côté serveur (connexions anormales).

Le https:// est-il toujours fiable ?

Oui à 99%+ quand : le navigateur est à jour, l'icône cadenas est présente, pas d'avertissement de certificat, le domaine correspond exactement à celui attendu. Cas où HTTPS peut être compromis : compromission d'une CA (rare depuis Certificate Transparency), certificat racine malveillant installé dans le navigateur (corporate proxy, malware), typosquatting avec certificat valide pour le mauvais domaine (HTTPS = chiffrement avec le serveur contacté, pas garantie d'identité), protocoles faibles encore supportés. Le HTTPS est la pierre angulaire mais ne garantit que : (1) personne ne lit/modifie en transit, (2) le certificat est valide, (3) le domaine correspond. Il ne garantit pas que le site est légitime — un site de phishing en HTTPS est techniquement valide mais frauduleux.

Les VPN protègent-ils complètement contre les MITM ?

Partiellement. Un VPN chiffre votre trafic jusqu'au serveur VPN, donc protège contre les MITM sur le segment local (Wi-Fi public notamment). Mais : le trafic sort en clair du serveur VPN vers la destination finale si celle-ci est en HTTP. HTTPS reste nécessaire. Le fournisseur VPN lui-même est une position de MITM potentiel — il voit tout votre trafic non-HTTPS. D'où l'importance de choisir un VPN de confiance, avec audit indépendant, juridiction favorable (hors Five Eyes idéalement), no-logs policy vérifiée. Un mauvais VPN ne fait que remplacer qui peut vous surveiller. Pour protection complète : VPN de confiance + HTTPS + DNS sécurisé + habitudes saines.

Mon FAI peut-il faire du MITM sur mes communications ?

Techniquement oui — tout le trafic passe par eux. En pratique : pour le trafic HTTPS, ils voient le destination (SNI avant ESNI) et volumes, mais pas le contenu. Pour le trafic HTTP (rare aujourd'hui), tout est visible. Les FAI peuvent faire du DNS hijacking (rediriger les requêtes vers leur serveur pour insertion publicitaire ou blocage légal). Certains pays obligent les FAI à pratiquer l'inspection profonde (Chine, Iran, Arabie Saoudite). Dans les démocraties, le cadre légal limite les pratiques mais la rétention de métadonnées reste courante. Protection : DNS-over-HTTPS pour contourner le DNS FAI, VPN pour chiffrer les métadonnées, HTTPS partout. Aucun mécanisme ne vous protège complètement d'un FAI hostile — changer de FAI reste le recours ultime.

L'AitM peut-il être bloqué par une MFA forte ?

Tout dépend du type de MFA. TOTP, SMS, notifications push : contournables par AitM car le proxy relaie simplement le challenge. Même la MFA number-matching (plus récente) est relayable. Passkeys / FIDO2 / clés de sécurité physiques : résistantes structurellement grâce à la liaison cryptographique au domaine. Le proxy n'a pas le bon domaine, la clé refuse de signer. C'est pourquoi Microsoft, Google, Apple poussent massivement les passkeys depuis 2023 — c'est la défense structurelle contre l'AitM. Recommandation 2026 : pour les comptes critiques (admin, finance, dev), passer aux passkeys ou aux clés FIDO2 physiques (YubiKey, Google Titan). Pour les utilisateurs grand public, les passkeys déployées via Apple/Google/Microsoft offrent une expérience fluide et sécurisée.