Manipulation et diffusion
Particuliers et entreprisesHameçonnage par relais d’authentification
Adversary-in-the-Middle phishing
Un faux site transmet votre connexion au vrai service et peut en voler la session.
Je pense être concerné : que faire ?
Comprendre et agir
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
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
Imaginez un faux guichet installé devant le vrai : il transmet vos réponses tout en observant une partie des échanges. Ce relais peut voler une session, c’est-à-dire la preuve que vous êtes connecté, après la validation de votre mot de passe et de votre second facteur d’authentification. Certaines doubles authentifications résistent à ce piège parce qu’elles vérifient aussi que vous vous connectez au vrai site.
- 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.
Si vous remarquez l’un de ces signes, vérifiez la situation. Un indice isolé ne suffit pas à prouver 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 faux site peut transmettre votre code SMS ou votre validation au vrai service. La double authentification ne suffit donc pas à exclure le vol d’une session.
À vous de décider
Vous avez validé un code sur une fausse page, puis changé le mot de passe. Que reste-t-il à faire ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Déconnectez les sessions dans les paramètres officiels et vérifiez les nouveaux accès au compte. Le faux intermédiaire a pu copier une session déjà validée, qui ne disparaît pas forcément quand vous changez le mot de passe.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Un faux site relaie la connexion et récupère la session authentifiée
Le faux site transmet au vrai service les échanges avec la personne qui se connecte. Le mot de passe et le code temporaire peuvent ainsi être acceptés normalement. La connexion semble fonctionner, tandis que le relais 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.
Quelles informations comparer
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.
Ce que ces indices ne permettent pas de conclure
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
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- 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.
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez 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
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-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
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les 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
Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.
- àGroupeScattered Spider / Octo Tempest
Le support et les identités comme portes d’entrée
Les attaquants imitent des contacts de confiance, appellent l’assistance et détournent des numéros de téléphone. Pour prendre le contrôle des comptes, ils associent hameçonnage, interception de connexions et pression pour faire accepter les validations MFA.
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 un faux site de connexion qui transmet les échanges au vrai service. Les attaquants récupèrent les identifiants et les cookies de session, puis les utilisent pour entrer dans les comptes, même lorsque certaines méthodes 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
Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’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 comprendre votre situation et trouver de l’aide : 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
