Manipulation et diffusion
Particuliers et entreprisesHameçonnage par relais d’authentification
Adversary-in-the-Middle phishing
Un faux intermédiaire relaie la connexion et peut récupérer une session.
Je pense être concerné : que faire ?
Comprendre et agir
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
Une situation concrète
Vous ouvrez un lien et vous connectez sur une page presque identique à votre messagerie. Le service vous demande une validation supplémentaire sur le téléphone, que vous effectuez. La connexion semble réussir. Pourtant, la page intermédiaire a transmis les échanges au vrai service tout en récupérant la preuve de connexion.
Comment cela fonctionne
Cette attaque fonctionne comme un faux guichet installé devant le vrai. Le faux guichet transmet vos réponses et voit certains éléments échangés. Il peut ainsi voler une session utilisable après la validation du mot de passe et du second facteur. Cela ne signifie pas que toutes les doubles authentifications sont inutiles : certaines sont liées au vrai site et résistent précisément à ce piège.
- Vous ouvrez un faux guichet
Il imite la connexion du vrai service.
- Le guichet relaie vos réponses
Même la validation peut être transmise.
- Une session est copiée
Le tiers tente de continuer sans vous.
Les signes qui doivent attirer l’attention
- L’adresse du site de connexion diffère de celle habituellement utilisée.
- Une nouvelle session apparaît après une connexion déclenchée par un message.
- Des règles de transfert ou des accès applicatifs inconnus sont ajoutés.
Ces signes invitent à vérifier la situation. Pris isolément, ils ne prouvent pas tous qu’une attaque a réussi.
Ce que vous pouvez faire
Vos premiers réflexes
Rejoignez votre messagerie par son application ou un favori. Si disponibles, activez les clés d’accès (« passkeys ») ou clés de sécurité, liées au vrai site.
Si vous êtes responsable du service ou de l’organisation
Déployez une authentification liée au domaine attendu. Préparez la révocation des sessions : changer seulement le mot de passe peut laisser fonctionner une session volée.
Un code SMS ou une notification de validation peut être relayé. La présence de MFA ne prouve donc pas, à elle seule, qu’une session n’a pas été détournée.
À vous de décider
Vous avez validé un code sur une fausse page, puis changé le mot de passe. Que reste-t-il à faire ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Déconnectez les sessions depuis les paramètres officiels et vérifiez les accès ajoutés au compte. Le relais a pu copier une session déjà authentifiée.
Analyser un cas technique
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
Un faux site relaie la connexion et récupère la session authentifiée
Le faux site se place entre la personne et le vrai service d’authentification. Il relaie les échanges : le mot de passe et le code temporaire peuvent donc être acceptés par le service réel. La personne voit une connexion qui fonctionne, alors que l’intermédiaire peut récupérer des éléments de session selon le parcours utilisé.
Dans le cas présenté, l’authentification A7 indique que le facteur a bien été validé. Une session est ensuite utilisée pour créer un transfert de courrier. La réussite de la MFA n’exclut donc pas cet incident. Il faut examiner le domaine visité par la personne, le trajet de connexion et les actions effectuées avec le jeton.
Les méthodes d’authentification liées à l’origine du site, comme les passkeys correctement déployées, résistent à ce type de relais d’une manière que les codes saisis sur une page ne permettent pas. Il reste nécessaire de protéger les sessions contre d’autres formes de vol. En réponse, fermer les sessions concernées et supprimer les règles ou délégations créées ; un changement de mot de passe seul ne garantit pas leur disparition.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Saisie dans la fausse origine
Titulaire vers Relais
Trace navigation du titulaire
- Action
Échange d’authentification relayé
Relais vers Fournisseur d’identité
Trace A7
- Réponse
Challenge transmis
Fournisseur d’identité vers Titulaire
Trace facteur exécuté
- Réponse
Session délivrée
Fournisseur d’identité vers Relais
Trace S8
- Action
Accès avec la session
Relais vers Application
Trace read_mail
- Action
Création de persistance
Relais vers Application
Trace règle de transfert
- Refus / blocage
Révocation vérifiée
Fournisseur d’identité vers Application
Trace ancienne session refusée
Comment repérer cette attaque
Indices à rechercher
Repérer les visites sur un domaine d’authentification imité, l’usage d’une session depuis un environnement inattendu et les transferts de courrier, facteurs ou consentements non reconnus.
Éléments à croiser
Relier la visite du domaine trompeur à l’authentification puis à l’activité non reconnue. Utiliser les identifiants de session disponibles ; ne pas assimiler deux sessions parce qu’elles portent le même compte.
Limites de l’interprétation
Une IP nouvelle et une MFA réussie ne prouvent pas à elles seules un relais AitM. La preuve du domaine visité et la réutilisation de session doivent être étayées séparément, sans collecter le jeton actif.
Comment réagir
Révoquer les sessions et les jetons de renouvellement, retirer règles et facteurs non reconnus, puis traiter les applications consenties. Déployer une authentification résistante au phishing avec une procédure de récupération cohérente. Vérifier le refus des anciennes sessions sur chaque application exposée.
Vérifier la correction
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- Dans un environnement de test, vérifier qu’une authentification liée au site refuse une origine différente de celle du service attendu.
- Confirmer que le retrait d’une règle de transfert ne laisse pas le cookie actif.
- Tester les exceptions d’accès conditionnel et les chemins de récupération.
À vous de raisonner
Le titulaire a bien saisi son code, puis une règle de transfert inconnue apparaît. Changer son mot de passe suffit-il à terminer la réponse ? Expliquez.
Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Il faut aussi révoquer les sessions concernées et retirer la règle de transfert. Le relais peut avoir récupéré une session malgré la validation du code. Vérifiez ensuite le refus de l’ancienne session et les autres changements du compte ; le changement de mot de passe ne prouve pas leur suppression.
Consulter les détails techniques
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-les dans les extraits.
session- Identifiant simplifié reliant les événements du cas. Les journaux de navigateur, d’identité et de messagerie n’utilisent pas nécessairement le même identifiant.
Authentification et accès après relais
JournalL’empreinte de session est pseudonymisée ; l’adresse vue par le fournisseur peut être celle du relais.
browser origin=connexion-demo.example user=u8
idp auth_tx=A7 user=u8 mfa=performed method=otp source=198.51.100.24
idp auth_tx=A7 session_fp=S8 result=success
app session_fp=S8 ts=10:02 device_context=relay action=read_mail
app session_fp=S8 ts=10:05 device_context=new_client action=create_forward_rule
user_report expected_origin=login.entreprise.examplePréparer une collecte dans votre environnement
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.
Chrome DevTools — panneau Network du navigateur
- Où les trouver
- Dans une capture déjà conservée, ou sur une reproduction autorisée en environnement de test : ouvrir Network et conserver la navigation avec Preserve log. Examiner Headers et Initiator.
- Quoi relever
- Conserver l’origine réellement visitée au moment de l’authentification, à partir d’une capture ou d’un historique disponible. L’apparence de la page et la présence de HTTPS ne prouvent pas qu’il s’agit du domaine attendu.
- Accès et prérequis
- La capture doit être active pendant l’observation : elle ne reconstitue pas le passé. Un export HAR peut contenir des données privées, même après retrait des en-têtes sensibles ; le nettoyer avant partage.
Microsoft Entra ID — Sign-in logs
- Où les trouver
- Centre d’administration Entra → Entra ID → Monitoring & health → Sign-in logs. Examiner séparément les connexions interactives, non interactives et celles des applications si elles sont concernées.
- Quoi relever
- Comparer authentification, méthode MFA, contexte réseau et accès ultérieurs. Une MFA peut avoir été satisfaite pendant une authentification relayée ; la mention de succès ne garantit pas l’absence d’intermédiaire.
- Accès et prérequis
- Rôle de lecture adapté, par exemple Reports Reader. Vérifier la période conservée et les exports disponibles ; une session applicative n’engendre pas nécessairement une nouvelle connexion Entra.
Microsoft 365 — audit dans Microsoft Purview
- Où les trouver
- Portail Microsoft Purview → Audit : rechercher par utilisateur, période et activité, puis exporter les résultats détaillés du service concerné, par exemple Exchange ou SharePoint.
- Quoi relever
- Rechercher les actions réalisées ensuite dans Microsoft 365, notamment les changements de règles de boîte et les accès couverts par l’audit. Documenter les limites de couverture des lectures.
- Accès et prérequis
- Rôle d’audit requis. Les activités disponibles et la durée conservée varient selon la licence et la configuration ; vérifier la couverture avant d’interpréter une absence.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Des faits réels pour situer ce mécanisme. Les années sont celles des faits ; chaque notice précise qui établit le lien avec le groupe ou la campagne.
- àGroupeScattered Spider / Octo Tempest
Le support et les identités comme portes d’entrée
Des attaquants usurpent des interlocuteurs de confiance, appellent l’assistance et détournent des numéros de téléphone. Ils combinent hameçonnage, interception de connexions et pression sur les validations MFA pour prendre le contrôle de comptes.
Ce qu’établit la source. Microsoft décrit Octo Tempest comme un périmètre recoupant Scattered Spider, 0ktapus et UNC3944. Ces noms de suivi ne sont pas nécessairement des synonymes exacts.
Consulter le rapport Octo Tempest crosses boundaries to facilitate extortion, encryption, and destructionMicrosoft · Publié le
- CampagneCampagnes utilisant EvilProxy
Intercepter une session malgré la double authentification
Proofpoint décrit des campagnes où un faux point de connexion relaie les échanges avec le vrai service. Les attaquants récupèrent les identifiants et les cookies de session pour accéder aux comptes, même lorsque certaines formes de MFA sont activées.
Ce qu’établit la source. EvilProxy est un service et un kit d’hameçonnage utilisé par plusieurs acteurs. Ce rapport ne permet pas d’attribuer toutes ces campagnes à un groupe unique.
Consulter le rapport Cloud Account Takeover Campaign Leveraging EvilProxy Targets Top-Level ExecutivesProofpoint · Publié le
Sélection de cas documentés, non exhaustive. Une technique peut être utilisée par de nombreux acteurs. Les cas fictifs de la fiche ne sont attribués à aucun de ces groupes.
Si vous pensez être concerné
- Depuis un accès fiable, révoquez les sessions et jetons concernés, puis changez le secret exposé.
- Vérifiez les méthodes de récupération, facteurs et applications autorisées.
- Examinez les messages envoyés, règles de transfert et documents consultés après l’événement.
Pour qualifier votre situation et être orienté : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- MITRE ATT&CK — Adversary-in-the-Middle — attack.mitre.org
- MITRE ATT&CK — Steal Web Session Cookie — attack.mitre.org
- Microsoft — campagne AiTM et cookies — www.microsoft.com
- W3C — Web Authentication — www.w3.org
