Une attaque AiTM (adversary-in-the-middle) place un proxy inverse entre l'utilisateur et le service légitime. Elle ne vise pas le mot de passe : elle attend que l'authentification aboutisse pour capturer le cookie de session émis par le service. Aucune méthode qui transmet une valeur — SMS-OTP, code TOTP, notification push — ne résiste à ce schéma, car chaque valeur est relayée en temps réel vers le vrai site.
De quoi est faite une infrastructure AiTM
L'attaque n'a rien d'artisanal. Elle mobilise quatre briques que les équipes de détection gagnent à connaître séparément, car chacune laisse une trace différente.
- Un domaine sosie, souvent enregistré depuis peu, imitant la marque, un fournisseur SaaS ou un portail RH. Les variantes typographiques et les sous-domaines longs y sont fréquents.
- Un certificat TLS valide, obtenu automatiquement. Le cadenas du navigateur n'apporte donc aucune information sur la légitimité du site : il atteste du chiffrement, pas de l'identité perçue.
- Un moteur de proxy inverse qui rejoue l'intégralité de l'interface légitime. L'utilisateur ne voit pas une copie approximative : il voit le vrai site, servi à travers l'attaquant.
- Un filtrage d'accès qui écarte les analyseurs automatiques : blocage par pays, par plage d'adresses de fournisseurs de cloud, ou exigence d'un paramètre unique dans l'URL. Une même URL peut ainsi être inoffensive pour l'outil d'analyse et hostile pour la victime.
Cette dernière brique explique un phénomène déroutant : un lien signalé par un collaborateur revient « propre » du bac à sable, alors qu'il a bel et bien servi à une compromission.
Le butin réel : session, jetons, persistance
Ce que l'attaquant emporte n'est pas un secret d'authentification mais un état de confiance déjà accordé. Trois objets sont recherchés.
Le cookie de session applicatif permet de poursuivre la navigation sans repasser par le moindre facteur. Le jeton de rafraîchissement, lorsqu'il est présent, prolonge cet accès bien au-delà de la durée de vie du cookie initial. Enfin, la présence dans une session valide permet d'installer une persistance : enrôlement d'un nouveau facteur d'authentification contrôlé par l'attaquant, création d'une règle de transfert de messagerie, ou dépôt d'une clé d'application.
Conséquence opérationnelle décisive : réinitialiser le mot de passe ne referme rien. Tant que les jetons ne sont pas révoqués et que les facteurs enrôlés ne sont pas audités, l'accès subsiste.
Chronologie et artefacts observables
La fenêtre utile est courte. Voici la séquence type, avec ce qu'elle laisse comme trace et le point où une équipe peut encore couper.
| Phase | Ce qui se passe | Artefact exploitable | Point de rupture |
|---|---|---|---|
| Préparation | Enregistrement du domaine, certificat, mise en place du proxy | Domaine récent, certificat neuf | Veille sur les domaines proches de la marque |
| Amorce | Message envoyé, souvent depuis une boîte légitime déjà compromise | En-têtes, URL à paramètre unique | Filtrage, réécriture d'URL, signalement |
| Relais | Saisie des identifiants et du second facteur | Authentification réussie depuis une adresse d'hébergeur | Facteur lié à l'origine, accès conditionnel |
| Capture | Récupération du cookie et des jetons | Session active sans nouvelle authentification | Liaison du jeton au poste, durée de vie courte |
| Exploitation | Lecture de messagerie, changement d'IBAN, nouvel enrôlement | Modification de paramètres sensibles juste après connexion | Validation d'intention sur l'action |
| Persistance | Facteur ajouté, règle de transfert, clé d'application | Journal d'enrôlement, règles de boîte | Alerte sur tout nouvel enrôlement |
La colonne la plus utile est la dernière : elle montre qu'il existe plusieurs occasions d'agir, et pas seulement au moment du clic.
Ce qui casse réellement la chaîne
La liaison à l'origine. FIDO2/WebAuthn calcule la réponse cryptographique pour un domaine précis. Sur le domaine du proxy, la réponse n'a aucune valeur, et l'attaque s'interrompt avant la délivrance de la session. C'est la seule contre-mesure qui agit sur la phase de relais elle-même.
La réduction de la valeur d'une session volée. Durées de vie courtes sur les périmètres sensibles, réévaluation du contexte en cours de session, révocation centralisée réellement testée. Une procédure de révocation qui n'a jamais été jouée n'existe pas.
La preuve d'intention au moment de l'action. Un attaquant installé dans une session valide agit au nom de l'utilisateur. Exiger une validation explicite sur l'opération — virement, modification de coordonnées bancaires, création d'un compte à privilèges — déplace le contrôle là où se situe le préjudice. C'est l'objet du facteur cognitif, qui fait résoudre un défi dans un canal éphémère ouvert par QR code dynamique à usage unique, sans secret rejouable.
Détection : quels signaux valent la peine
Trois corrélations donnent des résultats sans noyer le centre opérationnel.
- Authentification réussie suivie immédiatement d'un changement de paramètre sensible. C'est la signature d'exploitation la plus régulière.
- Divergence entre le contexte d'authentification et le contexte d'usage : l'authentification provient d'une infrastructure d'hébergement, l'usage d'un poste bureautique, ou l'inverse.
- Enrôlement d'un facteur non déclenché par l'utilisateur. Ce signal doit remonter en priorité haute, y compris hors heures ouvrées.
Côté organisation, une consigne simple aide : tout collaborateur doit pouvoir déclencher une révocation de ses sessions sans passer par une justification longue. Le coût d'une révocation inutile est négligeable devant celui d'une session laissée ouverte.
FAQ
L'AiTM et le phishing classique, est-ce la même chose ?
Non. Le phishing classique collecte des identifiants pour les rejouer plus tard. L'AiTM relaie l'échange en direct et capture l'état d'authentification. La différence est décisive : la MFA transmissible arrête le premier, pas le second.
Une passkey protège-t-elle totalement contre l'AiTM ?
Elle protège la phase de connexion grâce à la liaison à l'origine. Elle ne protège pas ce qui suit : un cookie ou un jeton volé par un autre moyen reste exploitable. Les parcours de récupération de compte, souvent retombés sur un e-mail ou un SMS, constituent l'autre angle mort.
Comment savoir si une session a été volée plutôt qu'un mot de passe ?
Regardez les journaux d'authentification : si aucune authentification anormale n'apparaît alors que des actions anormales sont tracées, l'hypothèse du vol de session prend le dessus. Comparez aussi les empreintes de navigateur associées à une même session.
Quelle est la première mesure à prendre après une suspicion d'AiTM ?
Révoquer les jetons de rafraîchissement et les sessions actives du compte concerné, puis auditer les facteurs enrôlés et les règles de messagerie. Le changement de mot de passe vient ensuite, et ne suffit jamais seul.
Aller plus loin : pilier : authentification cognitive · MFA résistante au phishing · vol de session et token theft · QR dynamique contre l'AiTM