EvilTokens: phishing chiffré qui est activé dans le navigateur DOM et casse les défenses

Un nouveau vecteur d'hameçonnage exploite une faiblesse opérationnelle que beaucoup d'équipes de sécurité assument couverture: l'attaque reste cryptée et "ghost" jusqu'à ce que le navigateur de l'employé défigure et y renonce. La campagne EvilTokens qui détecte l'activité aux États-Unis et en Europe utilise exactement cette technique : la page malveillante vient comme une charge chiffrée (AES-GCM) et ne devient visible qu'après avoir déchiffré dans le DOM du navigateur, où elle active un flux légitime de code de périphérique Microsoft pour convaincre la victime d'autoriser l'accès à votre compte sans révéler le mot de passe.

La conséquence immédiate est que les contrôles conventionnels - examen statique des URL, blocages sur les passerelles de courrier ou filtrage au niveau du réseau - peuvent donner un faux négatif. Le lien inspecté à froid affiche un contenu inoffensif ou un blob chiffré, tandis que l'utilisateur, en l'ouvrant dans son navigateur, voit une page qui démarre le flux d'authentification et livre un code de périphérique qui finit par être utilisé pour obtenir des jetons et accéder à Microsoft 365. Microsoft documente comment fonctionne le flux de code de périphérique et pourquoi il ne nécessite pas d'entrée d'identifications dans le contexte original de l'attaquant https: / / learn.microsoft.com / fr-us / azure / répertoire actif / develop / v2-oauth2-device-code.

Cela crée un "point aveugle" critique dans les opérations SOC: les preuves qui atteignent la queue d'analyse de niveau 1 peuvent être incomplètes, les décisions de confinement sont retardées et les attaquants obtiennent une fenêtre pour consolider l'accès, déplacer côté et extraire des données. Les secteurs les plus touchés, selon la télémétrie des bacs à sable, comme AUCUN. RUN, comprennent conseil, services financiers, fabrication et technologie, où l'exposition à l'hameçonnage déclarée est de plus de 65 % dans de nombreuses verticales; une connexion compromise dans Microsoft 365 peut signifier courrier d'entreprise, fichiers et flux de travail compromis, ainsi que les risques de fraude et de BEC.

La façon la plus pratique de fermer cet angle mort est d'apporter l'inspection au navigateur. Les outils interactifs de bac à sable qui capturent les DOM, XHR / Fetch et le trafic derrière la scène vous permettent de voir le moment exact où la charge chiffrée est décomposée, qui demande le lancement du code de périphérique et quels sont les paramètres utilisés (par exemple, en traquant les appels vers / api / périphérique / start et similaire). Aucune. RUN est un exemple de cette approche interactive, où les sessions reproduisent l'expérience de l'utilisateur et produisent des preuves concrètes pour la réponse https: / / any.run /.

Pour les leaders de sécurité cela signifie rééquilibrer les contrôles : il ne suffit pas de bloquer les URL suspectes, il est nécessaire de compléter avec l'inspection du navigateur et des contrôles d'identité forts. Microsoft recommande déjà des politiques de consentement et des contrôles sur les applications OAuth; examiner et limiter les demandes qui peuvent obtenir des permissions, bloquer le consentement des applications tierces par défaut et les autorisations de vérification est fondamental pour réduire les dommages possibles si un jeton est émis à un acteur malveillant https: / / learn.microsoft.com / fr-us / azure / répertoire actif / manage-apps / suite-your-app-consent.

Sur le plan opérationnel, il existe des mesures concrètes et urgentes qui devraient faire partie de la réponse à ce type d'incident : isoler la session engagée et révoquer les jetons et les sessions fédérés d'Azure AD, éliminer le consensus sur les demandes non reconnues, analyser les dossiers d'inscription et d'audit pour déterminer quand et comment les jetons ont été émis, et mettre en oeuvre des politiques d'accès conditionnel et d'AMF qui rendent difficile la réutilisation des titres de compétence ou des jetons volés. Il est également essentiel de conserver les preuves des demandes de DOM et de XHR pour obtenir des indicateurs d'engagement (domaines, paramètres, hachages) qui permettent de bloquer les règles d'infrastructure et de détection des aliments pour animaux.

Au-delà de la réponse technique, il est nécessaire d'ajuster les processus : donner plus de visibilité au niveau 1 (captures par les navigateurs, résumés automatisés et COI) réduit la pression sur les analystes seniors et accélère le confinement ; automatiser la production de rapports en fonction du contexte des sessions évite les pertes de temps sur les reconstructions manuelles et réduit les coûts opérationnels. Revoir les livres de lecture afin d'inclure des étapes spécifiques contre les flux d'autorisation de code OAuth / périphérique devrait être une priorité.

Toutes les attaques chiffrées ne sont pas identiques, mais le modèle est répété : le contenu qui échappe aux filtres traditionnels réapparaît dans le navigateur et déclenche un flux légitime qui donne accès. Une protection efficace combine les restrictions d'identité et de consentement, la détection par navigateur et les boîtes de sable qui enregistrent les appels DOM et XHR pour suivre toute la chaîne d'attaque. La compréhension et la saisie de la phase au cours de laquelle HTML passe du chiffrement à l'exécution est la différence entre un incident contenu et une telle échelle à la fraude, la perte de données et la réponse coûteuse.

Pour les équipements qui gèrent les risques dans les environnements Microsoft 365, la priorité immédiate est de mettre en place des contrôles d'identité et de consensus, d'ajouter l'inspection du navigateur à la chaîne de détection et de définir des livres de lecture qui comprennent la révocation des jetons et l'audit de consensus. Dans le même temps, il convient de revoir le chiffrement utilisé par les attaquants - par exemple, AES-GCM est la technique qui cache la charge utile dans ces campagnes - pour comprendre pourquoi les solutions basées uniquement sur URL ou le contenu statique échouent https: / / fr.wikipedia.org / wiki / Galois / Counter _ Mode.

En bref, EvilTokens et variantes similaires n'introduisent pas une nouvelle vulnérabilité dans Microsoft, mais un vecteur d'exploitation qui exploite le manque de visibilité dans le navigateur et la confiance dans les flux d'autorisation légitimes. La défense déplace l'inspection vers le site où l'attaque se produit : les DOM et les communications du navigateur, puisent dans des bacs à sable interactifs pour obtenir des preuves complètes et durcir le consentement en nuage et les politiques d'accès. Cette combinaison réduit la fenêtre d'exposition et empêche un accès unique à Microsoft 365 de devenir un incident majeur.