ClickFix : comprendre les faux CAPTCHA et se protéger
Comment reconnaître une attaque ClickFix ? Faux CAPTCHA, PowerShell, vol de sessions : comprendre le piège, prévenir l’infection et réagir après un clic.
Vous vérifiez l’adresse du site : elle est correcte. Vous vous authentifiez comme d’habitude. Pourtant, le code transmis par votre interlocuteur peut servir à ouvrir sa session à lui. Le device code phishing détourne un parcours légitime. Pour comprendre le piège, il faut examiner ce que vous autorisez, pas seulement l’endroit où vous vous connectez.
En résumé
- Le device code sert normalement à autoriser un appareil ou une application depuis un autre écran.
- Un imposteur peut vous transmettre le code de sa propre demande pour vous faire autoriser son accès.
- EvilTokens illustre l’industrialisation de ce scénario, documentée par Microsoft en septembre 2026.
- Le MFA reste nécessaire, mais il ne remplace pas la maîtrise des flux d’authentification autorisés.
- La prévention associe restriction des usages, exceptions maîtrisées, surveillance et signalement.
EvilTokens : ce que Microsoft a documenté
Dans son analyse du 22 septembre 2026, Microsoft décrit EvilTokens, une plateforme de phishing permettant notamment de détourner la connexion par code et d’exploiter des boîtes mail compromises. Microsoft indique avoir participé à une action de perturbation de son infrastructure. Ces observations illustrent un mécanisme ; elles ne permettent pas d’affirmer que toute attaque similaire utilise cette plateforme. Consulter l’analyse Microsoft.
Pour une entreprise, le nom de l’outil est moins durable que la leçon : une consigne d’authentification peut être trompeuse même lorsqu’elle mène à un service réel. C’est un complément important aux formations centrées exclusivement sur les faux domaines et les mots de passe.
Un parcours normal, puis son détournement
Imaginez un équipement dont l’écran ne permet pas de saisir confortablement des identifiants. Il affiche un code et vous demande de terminer la connexion sur un autre appareil. Le service utilise ce code pour associer votre validation à la demande en attente. Le code désigne donc une opération précise ; il n’est pas un simple numéro de dossier.
Dans le scénario frauduleux, la demande provient de l’imposteur. Celui-ci fournit le code sous un prétexte professionnel. Vous réalisez la connexion sur la page attendue, mais l’autorisation bénéficie à sa demande. Cette distinction explique pourquoi une page authentique peut participer au piège sans être elle-même contrefaite.
| Question à poser | Parcours normal | Parcours suspect |
|---|---|---|
| Qui a lancé la demande ? | Vous, pour une opération identifiée. | Un interlocuteur vous impose un code. |
| À quoi sert le code ? | À connecter un appareil ou une application attendus. | À prétendument lire, vérifier ou débloquer un document. |
| Que faire en cas de doute ? | Vérifier l’opération avant de continuer. | Arrêter et contacter le support connu. |
Pourquoi le MFA ne répond pas à toutes les questions
Le MFA apporte une preuve supplémentaire lors de l’authentification. Il reste un contrôle essentiel. Mais prouver qui vous êtes et comprendre quelle demande vous autorisez sont deux problèmes différents. L’entreprise doit aussi décider quels protocoles, applications et parcours sont permis.
Une clé FIDO2 ou une passkey protège contre des formes de phishing grâce au lien avec le service authentique. Il ne faut pas en déduire une protection universelle contre toute autorisation trompeuse sur un vrai service. Un poste compromis, un détournement de session ou un flux autorisé à tort soulèvent d’autres questions. La sécurité repose sur l’ensemble du parcours, avec ses conditions et ses exceptions.
- Besoin réelIdentifier les usages de connexion par code.
- Règle d’accèsLimiter le flux aux cas nécessaires.
- VérificationTester les usages permis et les refus attendus.
- SurveillanceTraiter les connexions et demandes inhabituelles.
Un plan de maîtrise pour Entra ID
Microsoft documente le blocage des flux d’authentification par les stratégies d’accès conditionnel. Avant toute activation, l’équipe identité doit inventorier les usages et examiner les conditions de licence et de configuration. Un équipement métier ou un outil d’administration peut dépendre du flux concerné. Documentation des stratégies.
Nous recommandons un pilote avec un responsable, des comptes de test et un scénario de retour arrière. Le mode rapport seul permet d’étudier des effets attendus avant application, mais ne constitue pas un blocage. Examinez les résultats avec les propriétaires des services, puis contrôlez réellement le refus après activation. Prévoyez aussi la continuité de l’administration et les comptes de secours.
Chaque exception devrait préciser l’identité concernée, la ressource, la justification, le propriétaire et la date de réexamen. Une exception trop large peut annuler l’intérêt du contrôle. Les détails doivent suivre la documentation correspondant au tenant ; une recette universelle copiée sans analyse serait inadaptée.
Si un utilisateur a déjà saisi le code
Le premier message au support doit préciser l’heure, le compte utilisé et la demande reçue. La personne ne doit ni recommencer pour vérifier, ni tenter de nettoyer seule son compte. Le support détermine si une autorisation a abouti et coordonne la protection du compte avec l’équipe habilitée.
L’investigation doit examiner les sessions, les traces d’accès aux ressources et les changements de configuration pertinents. Il faut également rechercher les conséquences métier : messages envoyés, échanges de factures ou documents potentiellement consultés. Une boîte qui fonctionne normalement peut néanmoins avoir été utilisée par un tiers.
Conservez une chronologie et distinguez ce qui est confirmé, suspecté ou non observable. La clôture exige plus qu’un mot de passe changé : elle doit expliquer quels accès ont été retirés, quels contrôles ont été vérifiés et quels éléments restent inconnus.
La phrase à ajouter à la sensibilisation
« Ne saisissez pas un code reçu d’un interlocuteur pour une connexion que vous n’avez pas initiée et comprise. » Cette consigne complète la vérification des liens ; elle ne la remplace pas. Donnez un exemple avec un code fictif, sans déclencher de vraie demande d’authentification.
Un exercice utile demande au participant d’identifier l’opération autorisée. On peut réussir à repérer un faux site tout en se trompant sur une demande authentique détournée. Faites de ce constat un apprentissage, pas un reproche. L’objectif est qu’une personne puisse interrompre une demande présentée comme urgente et obtenir rapidement une confirmation fiable.
Sources et références
Sources consultées le 19 octobre 2026. Les schémas et grilles de préparation sont des propositions pédagogiques de Kenawek, à adapter au contexte de l’organisation.
Préparer vos contrôles avec Kenawek
Pour cadrer un audit, améliorer la surveillance ou préparer votre organisation, parlons de votre projet. En cas d’incident urgent, les clients sous contrat utilisent leur procédure dédiée.