CyberPlay

Hameçonnage de session et de code d’appareil : vérifier l’accès

Distinguez vol de session, code d’appareil et consentement OAuth. Exercez les bons réflexes avec les cours CyberPlay et le jeu Find the Fake Login.

Équipe éditoriale de CyberPlay · Publié le · Mis à jour le · 10 min de lecture

Guide et exercices en français

Une page de connexion mise en scène et une invite d'approbation d'authentification dans le cours sur l'hameçonnage de session de CyberPlay.

Agrandir l’image · Image du cours vidéo · interface en anglais

Image réelle tirée du cours Ne finalisez pas la connexion à cet endroit, avec du texte à l'écran en anglais. Cette scène de connexion fictive présente le risque d'autoriser une session via un itinéraire contrôlé par un attaquant.

L'authentification multifacteur (MFA) reste précieuse, mais le fait de passer une vérification de connexion supplémentaire ne prouve pas que la requête sous-jacente est sûre. L'hameçonnage de session cible une session authentifiée ; l'hameçonnage de code d'appareil vous pousse à autoriser une connexion initiée ailleurs ; l'hameçonnage par consentement vous demande d'accorder un accès à une application. La décision de l'employé consiste à vérifier la destination, l'auteur de la requête et ce que l'approbation permettra.

Ce guide utilise les cours CyberPlay pour distinguer ces trois mécanismes, puis les relie à Find the Fake Login. Il s'agit d'une leçon pratique pour les personnes recevant des liens vers des documents, des invitations à des réunions et des messages d'assistance. Les vidéos du cours sont narrées en anglais ou en roumain ; la plateforme et le jeu sélectionné prennent en charge les neuf langues du site.

Les points à retenir

  • Une véritable page de fournisseur d'identité peut afficher une requête d'appareil ou d'application non sécurisée.
  • Ne saisissez un code d'appareil que pour un processus approuvé que vous avez initié et que vous pouvez vérifier.
  • Lisez le nom de l'application, de l'éditeur et les autorisations demandées avant d'accorder votre consentement.
  • Signalez ce que vous avez approuvé ; le simple changement d'un mot de passe peut laisser d'autres accès en place.

1. Enseigner l'approbation, pas seulement la case du mot de passe

L'étude EvilTokens de Microsoft de septembre 2026 décrit l'hameçonnage de code d'appareil dans lequel une personne saisit un code fourni par un attaquant sur le véritable service de connexion de Microsoft. La page légitime fait partie de la tromperie. En septembre 2026, le FBI a également mis en garde contre l'hameçonnage par consentement OAuth qui redirige les cibles vers un véritable écran d'autorisation du fournisseur. Ce sont des modèles d'attaque documentés, et non des raisons d'abandonner la MFA.

Pour la formation, demandez à l'apprenant de terminer cette phrase avant de cliquer : « J'approuve l'accès pour... ». Une réponse telle que « le document me l'a demandé » laisse la question centrale sans réponse. Une leçon utile rend l'appareil, l'application ou la session suffisamment visible pour que l'apprenant puisse expliquer sa décision.

Sources de cette section: Démasquer EvilTokens : aller à la racine de l'hameçonnage de code d'appareil · Des cyberacteurs malveillants accèdent aux comptes des victimes par le biais de l'hameçonnage par consentement

2. Comparer les trois mécanismes

Ces termes décrivent différentes manières d'obtenir un accès. Ne les enseignez pas comme trois noms pour une fausse page de mot de passe. Utilisez d'abord cette comparaison synthétique, puis étudiez un exemple distinct pour chacun d'eux. Le tableau est un support de formation ; le confinement réel dépend du service et des conclusions de l'équipe d'intervention.

2. Comparer les trois mécanismes
MécanismeCe que l'attaquant rechercheQuestion avant de continuer
Hameçonnage de cookie de session, souvent par le biais d'un adversaire au milieuLa session authentifiée créée lors d'une connexion relayée.Ai-je atteint le service attendu par une voie de confiance ?
Hameçonnage de code d'appareilL'autorisation pour une connexion initiée par l'attaquant.Ai-je initié cette connexion d'appareil, et puis-je vérifier son code et son objectif ?
Hameçonnage par consentement OAuthLes autorisations pour une application contrôlée par l'attaquant.Ai-je choisi cette application approuvée, et ces autorisations correspondent-elles à sa tâche ?

Sources de cette section: Résurgence d'une campagne d'hameçonnage AiTM et BEC en plusieurs étapes abusant de SharePoint · Démasquer EvilTokens : aller à la racine de l'hameçonnage de code d'appareil · Se protéger contre l'hameçonnage par consentement

3. Hameçonnage de session : la vérification supplémentaire peut être relayée

Dans une connexion avec un adversaire au milieu, un intermédiaire malveillant relaie l'interaction avec le véritable service et capture les données de session qui en résulte. Une enquête de Microsoft de janvier 2026 décrit une campagne AiTM suivie d'une manipulation de boîte aux lettres et d'autres hameçonnages. Ses conseils de remédiation vont au-delà de la réinitialisation d'un mot de passe pour inclure la révocation de session et la vérification de la persistance.

Pour l'employé, répétez la navigation de confiance. Si un document ou un message inattendu exige une connexion, arrêtez-vous et ouvrez l'application approuvée ou le portail enregistré de manière indépendante. Confirmez l'élément à cet endroit ou demandez à un contact connu. Ne continuez pas à suivre un processus suspect parce qu'une invite MFA est apparue, et n'ignorez pas un problème de correspondance signalé par la clé d’accès ou le gestionnaire de mots de passe simplement pour faire fonctionner la page.

Sources de cette section: Résurgence d'une campagne d'hameçonnage AiTM et BEC en plusieurs étapes abusant de SharePoint

4. Hameçonnage de code d'appareil : vérifier qui a initié la connexion

La connexion par code d'appareil a des utilisations légitimes, notamment pour les appareils avec une saisie limitée. Dans le processus abusif décrit par Microsoft, l'attaquant initie la requête et transmet son code à la cible. Saisir et confirmer ce code peut autoriser la session de l'attaquant sans lui remettre le mot de passe. N'inspecter que l'adresse web du fournisseur fait passer à côté de cette différence.

Utilisez deux fiches fictives lors d'une discussion. Sur l'une, un apprenant vient de commencer à connecter un appareil de salle de réunion approuvé et peut voir son code. Sur l'autre, un contact de chat fournit un code pour « déverrouiller un document ». Demandez ce qui a initié chaque action et quel appareil ou application recevra l'accès. Un code non sollicité n'est pas un mot de passe de document. Annulez et vérifiez la requête auprès de l'assistance ; ne le saisissez pas à titre expérimental.

Une page de connexion d'appareil mise en scène demande un code masqué et explique l'accès au compte qu'elle accorde.

Agrandir l’image · Image du cours vidéo · interface en anglais

  1. Un vrai domaine n'est qu'une seule vérification

    La page authentique du fournisseur ne prouve pas que vous avez initié l'autorisation de l'appareil.

  2. Vérifiez d'où vient le code

    Ne poursuivez qu'avec un processus d'appareil que vous avez initié pour votre propre application ou appareil connu.

Image réelle tirée du cours Une vraie page peut quand même être la mauvaise requête, avec du texte à l'écran en anglais. Le code est masqué et la scène est un exemple pédagogique.

Sources de cette section: Démasquer EvilTokens : aller à la racine de l'hameçonnage de code d'appareil

6. Expliquer ce que change une authentification plus forte

Les clés d'accès et les clés de sécurité FIDO2 utilisent des identifiants liés au service prévu, offrant une résistance à l'hameçonnage qui relaie un mot de passe ou un code via un site sosie. Microsoft décrit cela comme une authentification par clé publique liée à l'origine. Encouragez les employés à utiliser la méthode approuvée par leur organisation et à contacter l'assistance si une page inattendue leur demande de rétrograder vers une autre méthode.

Gardez les limites de la leçon claires : une authentification plus forte ne décide pas si une autorisation d'application demandée sert un objectif professionnel légitime. Les administrateurs ont également besoin de contrôles appropriés pour les processus d'appareil, le consentement des applications et les sessions. Les employés ne doivent pas modifier ces politiques lors d'un exercice de sensibilisation. Leur travail consiste à reconnaître l'approbation non résolue, à s'arrêter et à fournir des informations utiles à la personne responsable.

Comparaison de trois questions d'approbation : vérifier l'itinéraire pour une session, l'appareil initiateur pour un code d'appareil, et l'application et les autorisations pour le consentement OAuth.

Agrandir l’image

Comparaison pédagogique originale de CyberPlay. Les contrôles techniques et la réponse aux incidents dépendent du service d'identité de l'organisation.

Sources de cette section: Méthodes d'authentification dans Microsoft Entra ID : clés d'accès (FIDO2) · Se protéger contre l'hameçonnage par consentement

7. Relier les cours à Find the Fake Login

Utilisez Ne finalisez pas la connexion à cet endroit pour l'hameçonnage de session, Une vraie page peut quand même être la mauvaise requête pour les codes d'appareil, et N'autorisez pas une application que vous n'avez pas choisie pour le consentement. Chaque cours fait une pause à cinq points de contrôle de réponse avant l'explication. Passez en revue la raison derrière une réponse, en particulier lorsqu'un apprenant utilise « la page était vraie » comme seule justification. Les vidéos sont disponibles en anglais et en roumain, l'accès étant régi par le compte et le forfait.

Ouvrez ensuite Find the Fake Login. Ses scénarios réels incluent un chat d'assistance fournissant un code d'appareil, une application inattendue demandant l'accès aux e-mails et aux fichiers, et une application de calendrier interne légitime. Comparez les exemples de consentement malveillant et légitime afin que l'apprenant s'exerce à prendre une décision réfléchie. Il s'agit de scénarios fictifs, uniquement sur navigateur ; le jeu n'inspecte pas un compte réel ni ne teste la configuration d'identité de votre organisation.

8. Expliquer la décision sûre dans un nouveau scénario

Utilisez le cas ci-dessous après le cours et le jeu. Gardez-le comme une discussion sur table avec des services fictifs ; aucun vrai code d'appareil, consentement d'application ou compte n'est nécessaire. Demandez à chaque apprenant d'identifier les preuves manquantes avant de lire la réponse.

9. Signaler l'action que vous avez entreprise, puis laisser les intervenants en évaluer la portée

Signalez rapidement si vous avez effectué une connexion suspecte, saisi un code d'appareil fourni ou approuvé une application inattendue. Indiquez l'heure, le compte, le message de départ et l'action que vous avez entreprise. Pour une application, incluez son nom affiché et ses autorisations s'ils sont déjà disponibles. Conservez le message via le circuit de signalement approuvé ; ne rouvrez pas la requête pour recueillir plus de preuves.

Indiquez aux intervenants si vous avez saisi des identifiants, approuvé une connexion d'appareil ou accordé des autorisations d'application. Ces différences affectent les sessions, les jetons, les applications et les modifications de compte qui nécessitent une enquête. Ne supposez pas que la fermeture du navigateur ou la modification du mot de passe termine la récupération. Le responsable de l'intervention doit confirmer le confinement et le suivi pertinents selon les procédures du service.

Pour la prochaine session de pratique, changez le leurre mais conservez le mécanisme d'approbation. Comparez les explications entre les tentatives et notez les questions non résolues pour l'accompagnement. L'achèvement du cours et les décisions dans le jeu montrent la participation et les performances dans ces exercices ; ils ne prouvent pas qu'un compte réel est sécurisé ou que les futurs hameçonnages échoueront.

Sources de cette section: Résurgence d'une campagne d'hameçonnage AiTM et BEC en plusieurs étapes abusant de SharePoint · Des cyberacteurs malveillants accèdent aux comptes des victimes par le biais de l'hameçonnage par consentement

S’entraîner à approuver les accès au compte

Utilisez Find the Fake Login pour enquêter sur une requête de code d'appareil et comparer les autorisations d'applications légitimes et malveillantes après les cours.

Jouer à Find the Fake Login

Sources et lectures complémentaires

  1. Démasquer EvilTokens : aller à la racine de l'hameçonnage de code d'appareil — Sécurité Microsoft. Consulté le 2026-10-03
  2. Résurgence d'une campagne d'hameçonnage AiTM et BEC en plusieurs étapes abusant de SharePoint — Sécurité Microsoft. Consulté le 2026-10-03
  3. Méthodes d'authentification dans Microsoft Entra ID : clés d'accès (FIDO2) — Microsoft Learn. Consulté le 2026-10-03

Poursuivez votre lecture

Tous les articles

Contact · À propos