Les attaques AiTM ne volent pas de mots de passe ; ils copient le résultat d’une véritable connexion. Vous devez surveiller ce qui se passe une fois que l’utilisateur s’est connecté pour détecter une session piratée.
Le secteur de la sécurité a passé des années à améliorer l’authentification. Mots de passe plus longs, seconds facteurs, jetons matériels. Et les attaquants ont répondu en dépassant complètement l’authentification.
Le phishing par adversaire au milieu (AiTM) ne vole pas les informations d’identification et ne les rejoue pas. Il se situe entre l’utilisateur et le service légitime, observe une véritable authentification réussir en temps réel et repart avec le jeton de session qui prouve que cela s’est produit. La connexion était authentique. L’invite MFA était réelle. L’attaquant vient d’observer et de copier le résultat.
Si vous avez lu l’analyse du fonctionnement de ces attaques, vous en comprenez le mécanisme. Cette pièce parle de ce qui vient après cette compréhension. Plus précisément : quels contrôles réduisent les risques lorsque l’attaque ne touche pas du tout les informations d’identification ?
Pourquoi la plupart des défenses actuelles passent à côté de l’essentiel
Après avoir découvert le phishing AiTM, l’instinct est de renforcer l’authentification. Achetez des clés matérielles. Déployez des mots de passe. Forcez l’authentification MFA résistante au phishing pour les comptes privilégiés.
Cet instinct est correct mais incomplet.
L’authentification résistante au phishing arrête la phase de vol d’identifiants. FIDO2 et les clés d’accès lient cryptographiquement le défi d’authentification au domaine légitime, de sorte qu’un domaine proxy ne peut pas terminer la prise de contact. Cela fonctionne. Les organisations qui ont déployé des clés d’accès à grande échelle ont considérablement réduit leur exposition à AiTM au niveau de la couche d’authentification.
Mais l’authentification n’est pas la seule couche qui compte. Les jetons de session émis après une authentification réussie sont la véritable cible, et la plupart des organisations les considèrent comme intrinsèquement dignes de confiance une fois émis. Ce n’est pas le cas.
Un cookie de session est un jeton au porteur. Celui qui le détient est authentifié. Il n’y a aucune liaison cryptographique entre le jeton et l’appareil qui l’a généré, aucune preuve continue que le détenteur est bien celui qu’il prétend être, et aucune expiration automatique déclenchée par un changement d’emplacement ou une incompatibilité d’appareil. Un attaquant qui vole un jeton de session dans un pays peut le rejouer dans un autre pays et le fournisseur d’identité l’acceptera comme légitime.
C’est là que la plupart des défenses présentent actuellement une lacune.
Les 3 contrôles qui comblent l’écart
Contrôle n° 1 : lier les sessions aux appareils gérés
Le contrôle le plus efficace pour la sécurité des sessions consiste à exiger des appareils gérés et conformes comme condition d’accès aux ressources sensibles. Lorsque les politiques d’accès, telles que l’accès conditionnel Microsoft Entra, exigent que l’appareil présentant un jeton de session soit inscrit, géré et réponde aux exigences de conformité, les jetons volés deviennent beaucoup plus difficiles à rejouer.
Un attaquant qui intercepte un jeton de session ne peut pas facilement le rejouer à partir d’une machine non gérée si la politique exige la conformité de l’appareil. La session est terminée. L’attaquant n’a pas seulement besoin du jeton, mais également d’un appareil conforme – une barre beaucoup plus élevée.
Ce contrôle n’est pas infaillible. Des attaquants sophistiqués peuvent tenter de compromettre directement les appareils gérés. Mais cela élimine le vecteur de relecture le plus simple : prendre un jeton volé et l’ouvrir dans un navigateur sur une machine complètement différente.
Le défi pratique est le déploiement. Exiger des appareils gérés pour tous les utilisateurs crée immédiatement des frictions pour les sous-traitants, les travailleurs à temps partiel et toute personne utilisant des appareils personnels à des fins professionnelles. L’approche pragmatique consiste à commencer par les accès les plus risqués : les rôles administratifs, les systèmes financiers et toute application traitant des données sensibles. Développez-vous à partir de là à mesure que la couverture de gestion des appareils s’améliore.
Contrôle n°2 : Surveiller les anomalies post-authentification
Les attaques AiTM ne génèrent pas de tentatives de connexion infructueuses. Ils en génèrent des réussis. La surveillance traditionnelle axée sur les échecs d’authentification passera totalement inaperçue de ces attaques.
Les signaux importants résident dans ce qui se passe une fois l’authentification réussie. Spécifiquement:
- Voyage impossible. Si une session s’authentifie à partir d’un emplacement, puis accède aux ressources à partir d’un emplacement géographiquement éloigné quelques minutes plus tard, cela justifie une enquête. Le temps entre les événements est important : une session qui s’authentifie à New York puis accède à des ressources d’un autre continent trente minutes plus tard n’est pas un scénario utilisateur normal.
- Enregistrement d’un nouvel appareil. Les attaquants qui obtiennent un accès à une session enregistrent souvent immédiatement un nouveau périphérique MFA ou ajoutent une nouvelle méthode d’authentification pour garantir un accès persistant. L’enregistrement d’un nouvel appareil se produisant quelques minutes après une connexion réussie est un signal haute fidélité qui mérite d’être alerté.
- Création de règles de boîte de réception. Un comportement post-compromission cohérent dans de nombreuses campagnes d’attaque est la création de règles de transfert de courrier électronique ou de filtres de boîte de réception conçus pour masquer les alertes de sécurité et transférer les communications vers des adresses contrôlées par les attaquants. Les propres équipes de réponse aux incidents de Microsoft ont documenté ce modèle à plusieurs reprises. La surveillance de la création de règles de boîte de réception, en particulier les règles qui transfèrent en externe ou masquent les e-mails contenant des mots clés spécifiques, détecte ce comportement de manière fiable.
- Tentatives d’élévation de privilèges. Les attaquants qui accèdent à un compte d’utilisateur standard tentent généralement d’accéder à des rôles dotés de privilèges plus élevés ou d’accéder aux interfaces d’administration. Les tentatives d’accès anormales contre les portails d’administration ou les systèmes de gestion des privilèges peu de temps après l’authentification d’une nouvelle session méritent d’être signalées.
Aucun de ces signaux n’est concluant en soi. Mais la création de règles de détection autour de la combinaison (une authentification réussie suivie d’un voyage impossible suivi d’un nouvel enregistrement d’appareil, par exemple) crée une capacité de détection qui détecte l’activité post-compromise d’AiTM que la surveillance de l’authentification manque complètement.
Contrôle n°3 : raccourcissez la durée de vie des sessions pour un accès à grande valeur ajoutée
Les jetons de session de longue durée donnent aux attaquants plus de temps pour opérer après une interception réussie. Un jeton qui reste valide pendant sept jours offre une fenêtre beaucoup plus longue qu’un jeton qui expire après une heure et nécessite une nouvelle authentification.
Les frictions liées à des réauthentifications plus fréquentes sont réelles. Les utilisateurs le remarquent. Pour les applications de productivité utilisées en continu tout au long de la journée, les délais d’expiration de session agressifs créent une mauvaise expérience.
La réponse est une gestion de session basée sur les risques plutôt que des politiques uniformes. Les sessions accédant à des outils de productivité à faible sensibilité peuvent avoir une durée de vie plus longue. Les sessions accédant aux systèmes financiers, aux interfaces administratives, aux données RH ou à tout ce qui manipule des informations réglementées doivent avoir des durées de vie courtes et nécessiter une réauthentification avant d’effectuer des opérations sensibles. Les lignes directrices sur l’identité numérique du NIST fournissent un cadre utile pour réfléchir aux seuils d’expiration de session par niveau d’assurance.
Cette approche concentre les frictions là où le risque est le plus élevé, ce qui la rend plus défendable tant auprès des utilisateurs que des dirigeants.
Le problème de la formation n’a pas disparu
Les contrôles techniques réduisent les risques. Ils ne l’éliminent pas. Les utilisateurs restent une partie de la surface d’attaque, et la formation de sensibilisation dispensée par la plupart des organisations ne les prépare pas à ce à quoi ressemble le phishing AiTM.
La formation traditionnelle au phishing apprend aux gens à rechercher les indicateurs de fausses pages : fautes d’orthographe, URL suspectes, adresses d’expéditeur inhabituelles. Les pages de phishing AiTM ne affichent aucun de ces indicateurs car elles ne sont pas fausses. Ils proxy le service réel en temps réel. L’URL peut être suspecte, mais les utilisateurs qui cliquent sur des liens dans des e-mails vérifient rarement les URL attentivement, même après une formation.
Le seul changement de comportement qui réduit l’exposition à AiTM est simple et s’apprend : ne démarrez pas de flux d’authentification à partir de liens dans les e-mails. Accédez directement au service. Pages de connexion aux favoris. Si vous recevez un e-mail vous demandant de vous connecter quelque part, ouvrez un onglet de navigateur et saisissez vous-même l’adresse plutôt que de cliquer.
Cela semble évident. Ce n’est pas instinctif. La plupart des utilisateurs ont passé des années à cliquer sur les liens de connexion dans les e-mails, car c’est plus rapide et ces liens sont généralement légitimes. Changer ce comportement nécessite une formation explicite et répétée qui explique pourquoi l’ancienne approche n’est plus sûre – et pas seulement une instruction pour se méfier davantage du phishing en général.
Associez cela à un mécanisme de rapport à faible friction. Les utilisateurs qui remarquent que quelque chose ne va pas devraient pouvoir le signaler en quelques secondes. La valeur d’un signalement précoce pour limiter les dommages résultant d’une compromission réussie d’une session est significative, et cette valeur disparaît si le signalement nécessite des efforts ou donne l’impression qu’il générera des reproches plutôt que des actions.
L’évaluation honnête
Le phishing AiTM est une menace réelle et croissante. Les plateformes de phishing en tant que service telles que Tycoon 2FA et FlowerStorm ont abaissé les barrières à l’entrée au point qu’il ne s’agit plus d’une technique avancée nécessitant des acteurs malveillants sophistiqués. Il s’agit d’une attaque marchande accessible à toute personne disposée à payer un abonnement.
Les organisations qui réduisent leur exposition sont celles qui prennent la sécurité des sessions aussi au sérieux que la sécurité des identifiants, construisent des capacités de détection autour du comportement post-authentification plutôt que des simples échecs de connexion, et donnent aux utilisateurs un modèle réaliste du fonctionnement du phishing moderne.
L’authentification résistante au phishing est la bonne direction à long terme. Y arriver demande du temps, du budget et de la gestion du changement. En attendant, les contrôles ci-dessus permettent une réduction significative des risques sans attendre le déploiement complet du mot de passe.
Le but n’est pas de rendre impossible les attaques AiTM. C’est pour les rendre suffisamment chers que les attaquants se tournent vers des cibles plus faciles.
Cet article est publié dans le cadre du Foundry Expert Contributor Network.
Voulez-vous nous rejoindre ?
