Marie-Michèle Normandeau
Experte en la matière
Aperçu
La semaine dernière, une campagne d'hameçonnage a frappé plusieurs de nos clients — celle que notre équipe de recherche a documentée dans Détournement de liens et tromperie par code d'appareil. Elle visait nommément des dirigeants et d'autres boîtes aux lettres importantes, et elle provenait des boîtes aux lettres authentiques et authentifiées de véritables petites entreprises canadiennes. Il ne s'agissait ni d'usurpations ni de domaines sosies. Les courriels prenaient l'apparence d'une correspondance de facturation courante, et le lien qu'ils contenaient pointait vers Google.
Selon tous les critères qu'enseigne la plupart des formations sur l'hameçonnage, ces courriels passaient le test. Les expéditeurs étaient réels. Le domaine était connu de tous. Il n'y avait aucune faute d'orthographe à repérer, aucune URL suspecte à survoler pour la démasquer.
Les défenses de courriel en couches ont fait leur travail pour l'essentiel. La variante visant les dirigeants a été signalée et mise en quarantaine. Mais une variante a échappé aux filtres et est arrivée dans une boîte de réception.
La personne qui l'a reçue l'a signalée.
Ce seul signalement a mené notre équipe de recherche à l'ensemble de la campagne et a permis d'alerter rapidement tous les autres clients dans le rayon d'impact. C'est précisément à cela que sert un programme de sensibilisation moderne : une personne a repéré le message que les filtres avaient laissé passer.
En bref
Ce qui a changé
- De vrais expéditeurs compromis peuvent réussir les vérifications de réputation.
- Des services de confiance peuvent masquer la destination finale de l'attaquant.
- Une page de connexion Microsoft authentique peut quand même faire partie d'une attaque.
Ce qu'il faut enseigner
- S'arrêter dès qu'apparaît une demande d'authentification qu'on n'a pas amorcée.
- Ouvrir les documents et les portails au moyen d'un favori ou d'une application connus, et non d'un lien dans un courriel.
- Signaler rapidement tout doute : la détection revient aux employés, le diagnostic à la sécurité.
Un lien propre n'est pas une preuve qu'une interaction est sûre.
L'inspection des liens compte toujours, mais les programmes de sensibilisation modernes doivent aussi apprendre aux gens à remarquer quand le déroulement d'une tâche ne tient plus debout.
Ce que notre équipe de recherche a découvert
Notre équipe de recherche a analysé la campagne en temps réel et retracé ce qui se passait après ce lien Google d'apparence anodine. Il était « blanchi » par une redirection de suivi légitime de Monday.com avant de livrer la victime à l'infrastructure de l'attaquant — une chaîne conçue précisément pour qu'aucune étape ne semble anormale. La fausse page de connexion Microsoft, à la fin, affichait même l'adresse courriel de la victime déjà remplie, si bien qu'elle ressemblait moins à un formulaire à remettre en question qu'à une session expirée. La trousse utilisée pouvait capter les codes d'authentification multifacteur en temps réel, et pas seulement les mots de passe.
Un second leurre découvert dans la même enquête était encore plus retors. Il n'affichait aucune fausse page de connexion. Il remettait à la victime un véritable code d'autorisation d'appareil Microsoft et l'incitait à le coller dans la page de connexion
authentique de Microsoft. La victime s'authentifie sur login.microsoftonline.com— le vrai domaine et la vraie page — et l'attaquant repart avec des jetons d'accès fonctionnels.
L'analyse technique complète vaut la peine d'être lue. Mon propos ici est différent : ce que ces constats signifient pour la façon dont les organisations préparent les gens à prendre des décisions.
La vérification des liens compte toujours, mais elle a ses limites
Notre équipe de recherche a écrit dans cet article une phrase qui mérite une lecture attentive :
La leçon n'est pas « former les utilisateurs à repérer les mauvais liens ».
Il serait erroné de conclure qu'il faut cesser d'enseigner l'inspection des liens, une compétence de base que tout le monde devrait idéalement maîtriser. Inspecter les liens, reconnaître les domaines sosies et comparer le texte affiché avec la destination réelle permettent encore de bloquer de nombreuses tentatives d'hameçonnage courantes.
Mais leur véritable rôle est plus restreint que ce que laisse entendre la plupart des formations. L'inspection technique peut donner à un employé des raisons de ne pas poursuivre. Ce qu'elle ne peut pas faire, et n'a jamais pu faire, c'est fournir une preuve positive qu'une interaction entière est sûre. Un vrai expéditeur peut être un expéditeur compromis. Un premier domaine connu ne dit rien du dernier de la chaîne. Une page de connexion Microsoft authentique peut être la dernière étape d'une attaque.
La plupart des programmes de sensibilisation accordent trop de poids à un lien propre. La campagne que notre équipe a disséquée a été conçue précisément pour exploiter ce modèle mental. Le problème n'est pas que nous apprenions aux gens à vérifier les liens. C'est que la plupart des programmes ont peu à dire sur ce qui se passe lorsque la vérification du lien ne révèle rien et que quelque chose cloche quand même.
Le volet qui manque à la plupart des programmes : ce qui se passe une fois la vérification réussie
Voici à quoi ressemble une règle de sensibilisation moderne. Elle découle directement des constats de notre équipe :
Aucun service légitime ne vous demande de coller dans un écran de connexion un code qu'un site Web vous a fourni. Cette instruction, à elle seule, est l'attaque.
Cette règle consiste à reconnaître une demande d'authentification inattendue : une connexion que vous n'avez pas amorcée, un code que vous n'avez pas demandé ou une demande d'approbation qui ne correspond à rien de ce que vous venez de faire. C'est la situation qui constitue le signal d'alarme, même lorsque tous les détails techniques sont en règle.
En pratique, pour un employé sans formation en sécurité, le moment qui méritait d'être enseigné dans cette campagne était la demande de mot de passe elle-même. Le destinataire était déjà connecté à Microsoft 365 et lisait ses courriels lorsqu'une page ouverte depuis ce courriel lui a demandé son mot de passe. Une demande de connexion qui surgit au milieu d'une tâche qui n'en a jamais eu besoin, voilà l'événement auquel réagir. Deux règles en langage simple couvrent ce cas :
1. Est-ce moi qui ai lancé cette action?
Toute demande de mot de passe, notification d'approbation ou code de vérification que vous n'avez pas amorcé signifie qu'il faut s'arrêter, et non évaluer.
2. Ne jamais se connecter par le lien
Si un document ou une facture exige vraiment une connexion, fermez la page et accédez au portail comme vous le faites toujours — au moyen de votre favori ou de votre application de bureau. Si le document est réel, il vous y attendra.
Cette seule habitude neutralise toute une chaîne de liens blanchis, sans que l'employé ait besoin de comprendre quoi que ce soit aux redirections.
Des règles comme celles-ci fonctionnent parce qu'elles ne demandent pas aux employés d'être plus fins analystes que l'attaquant. Ils n'ont pas besoin d'avoir raison. Ils doivent remarquer que le déroulement de leur tâche ne tient plus debout et le signaler. La personne qui a permis de contenir cette campagne n'a jamais prouvé que le courriel était malveillant, et elle n'en a jamais eu besoin. Le signalement a été rapide, sans aucune sanction, et quelqu'un y a donné suite à temps. La détection est le travail de l'employé. Le diagnostic appartient à l'équipe de sécurité. Les programmes qui brouillent cette répartition en demandent trop aux gens, puis les blâment pour cela.
Combien de règles comme celles-ci votre programme actuel enseigne-t-il? Pour bien des organisations, la réponse honnête est « peu » ou « aucune », parce que le programme a été conçu autour d'indicateurs et que ces attaques sont conçues pour n'en présenter aucun. Les règles dont une organisation a besoin — et la façon d'en faire des réflexes plutôt que des affiches — dépendent de ses flux de travail, de sa configuration d'authentification et de son processus de signalement. C'est un travail de conception de programme.
Cinq questions à vous poser sur votre programme
Votre programme affiche presque certainement de bons chiffres : taux d'achèvement, résultats aux questionnaires et peut-être des taux de clics en baisse lors des simulations. Mais ces chiffres mesurent la participation à un cursus. Ils ne vous disent pas si le signalement qui a permis de contenir cette campagne se produirait dans votre organisation.
- À quand remonte la dernière mise à jour du contenu en fonction de campagnes réelles? Couvre-t-il les attaques où l'expéditeur est authentique et la page de connexion réelle, ou seulement les signaux d'alarme classiques?
- Enseigne-t-il des règles pour les demandes d'authentification inattendues? Cela comprend les codes d'appareil, les approbations d'authentification multifacteur non sollicitées et les demandes de connexion que les employés n'ont pas amorcées.
- Vos simulations comprennent-elles parfois des scénarios avec peu ou pas d'indicateurs techniques? Mesurez-vous si les gens signalent, ou chaque test contient-il une faille à trouver?
- Un employé peut-il signaler un message suspect en un clic, sans craindre de se tromper? Et quelqu'un donne-t-il suite à ces signalements assez rapidement pour que cela compte?
- Que mesurez-vous en dehors de l'achèvement de la formation? Si un hameçonnage d'apparence irréprochable arrivait demain, l'un des indicateurs que vous suivez aujourd'hui permettrait-il de prédire s'il sera signalé?
Si vous pouvez répondre aux cinq questions avec assurance, votre programme devance la plupart des autres. Si deux ou plus vous ont fait hésiter, la lacune ne se résume pas à un module de formation manquant. Elle touche le contenu, les processus, la mesure et la façon dont la sensibilisation s'arrime à vos contrôles techniques.
Des simulations réalistes, sans piéger les gens
Une objection légitime à ce stade : on conseille avec raison aux responsables de la sensibilisation de garder les simulations réalisables pour que les employés restent confiants, continuent de participer et continuent de signaler. Nous sommes d'accord. Alors, un scénario conçu pour réussir toutes les vérifications ne revient-il pas simplement à piéger les gens?
Oui, s'il est mené comme une simulation ordinaire. La première condition est qu'il doit être traité différemment, et pas seulement présenté différemment. Les résultats sont lus de façon globale. Personne n'est suivi ni nommé individuellement. Le message affiché après un clic est honnête : ce test a été conçu pour réussir toutes les vérifications, la plupart des gens poursuivent, et voici l'unique indice qui le trahissait. Personne ne peut être à l'abri d'une attaque qui ne présente aucune faille à trouver, et l'exercice devrait le dire.
C'est pourquoi l'indicateur change avec le niveau de difficulté : il ne s'agit pas de savoir qui a cliqué, mais si quelqu'un a signalé le message et à quelle vitesse. Un signalement fait après un clic compte quand même, parce que, lors d'un véritable incident, c'est ce signalement qui limite les dégâts. Le résultat constitue une rétroaction sur le programme.
La deuxième condition est la séquence. Les scénarios réalistes n'ont leur place dans un programme qu'une fois les bases en place : des compétences de reconnaissance acquises au moyen de simulations réalisables, un moyen de signalement en un clic et une culture où signaler une fausse alerte est bien accueilli.
Lorsque ces deux conditions sont réunies, un test réaliste n'est pas un piège et ne mine pas la confiance. Il montre aux employés que leur jugement compte même quand la liste de vérification ne révèle rien — ce qui est exactement le comportement qui a permis de contenir la campagne analysée par notre équipe.
Pour aller plus loin
Moderniser un programme face à ces attaques ne consiste pas à ajouter un autre module générique sur l'hameçonnage. Il faut repenser ce que les employés sont formés à décider, la façon dont les situations ambiguës sont signalées, ce qui est réellement mesuré en matière de préparation et la façon dont le volet humain s'arrime à des contrôles comme l'authentification multifacteur résistante à l'hameçonnage et les flux d'authentification restreints — les défenses techniques que notre équipe de recherche recommande dans son analyse.
Ce travail touche la formation, les TI et la gouvernance, et il commence par un regard honnête sur l'état actuel de votre programme.
Si vous n'êtes pas certain de la façon dont votre programme résisterait à la campagne décrite ici, c'est généralement signe qu'un regard externe en vaut la peine.