Chaîne d'échecs d'hameçonnage Microsoft 365: de Evilginx et repos publics à l'abus de code de périphérique

Une découverte apparemment banale - un serveur public Python avec la liste des répertoires activés et un .bash _ histoire lisible - démêler le rideau sur trois campagnes d'hameçonnage visant Microsoft 365 et a permis aux chercheurs de reconstruire une chaîne complète d'outils, d'opérateurs et de tactiques. Cette petite défaillance opérationnelle est morale : la sécurité n'est généralement pas brisée par une seule explosion sophistiquée, mais par une combinaison de code accessible au public, de mauvaise hygiène opérationnelle et d'automatisation qui abaisse la barrière d'entrée pour les attaquants non expérimentés.

Dans les cas analysés, deux mécanismes techniquement différents ont été utilisés pour saisir l'accès aux comptes d'entreprise: d'une part, les points de vue de l'adversaire dans le milieu construits sur des fourchettes du projet Evilginx (un proxy qui préserve la page réelle pour tromper l'utilisateur et capturer les cookies de session) et d'autre part, un abus légitime du flux OAuth connu sous le nom de flux de code de périphérique, qui force la victime à terminer le démarrage sur microsoft.com / devicanisation et où l'attaquant "polling" prend le jeton lorsque l'utilisateur l'autorise. Les deux approches sont dangereuses, mais nécessitent des défenses différentes : la première est atténuée par le MFA résistant au phishing (FIDO2 / Passkeys) et la liaison source ; la seconde nécessite des politiques d'accès conditionnel qui bloquent ou limitent le flux de code de périphérique.

Il est important que toutes les trames utilisées par les opérateurs soient des fourches précompilées publiques ou binaires distribuées dans GitHub, certaines avec des améliorations conçues pour éviter la détection et prolonger la validité des cookies ou des jetons. Cela confirme une tendance: la commercialisation du phishing comme service et la réutilisation massive du code disponible dans les dépôts publics font des campagnes efficaces peuvent être montées à faible coût et par des acteurs qui ne développent pas l'infrastructure à partir de zéro. Le dépôt original d'Evilginx reste une ressource connue et accessible: https: / / github.com / kgretzky / maleginx2.

Les implications pratiques pour une équipe de sécurité Microsoft 365 sont claires et urgentes. Premièrement, l'absence de politiques d'accès conditionnel qui restreignent le débit du code de l'appareil laisse une porte ouverte qui ne se rapproche pas de la simple mise en œuvre de FIDO2. Microsoft, pour sa part, documente le flux de code de périphérique et ses utilisations légitimes dans les développements: https: / / learn.microsoft.com / azure / répertoire actif / develop / v2-oauth2-device-code. Pour atténuer les abus, le levier d'exploitation est l'accès conditionnel : inventer les applications qui ont vraiment besoin de ce flux, tester une politique en mode de rapport simple et ensuite interdire le flux là où ce n'est pas nécessaire. Le guide général sur l'accès conditionnel et ses capacités est disponible ici: https: / / learn.microsoft.com / azure / répertoire actif / accès conditionnel / aperçu.

En parallèle, la défense de proxies AiTM nécessite le déploiement de MFA résistant à l'hameçonnage et de commandes qui valident l'origine de la connexion. FIDO2 et les mots de passe sont efficaces pour bloquer le classique Evilginx parce qu'ils associent l'authentification à une origine légitime; cependant, ils ne sont pas assez à eux seuls pour couvrir l'abus de code de périphérique. En outre, Microsoft recommande d'ajouter l'évaluation d'accès continu aux réévaluations de session lorsqu'un jeton volé apparaît à des endroits ou dans des conditions anormales : https: / / learn.microsoft.com / azure / répertoire actif / accès continu-évaluation-overview.

De la détection et de la chasse aux menaces, il y a des signes précis à prioriser. Vérifiez les enregistrements d'accès à l'entrée (Azure AD) pour rafraîchir les concessions associées au client ID du bureau La Commission a décidé de ne pas modifier le règlement (CE) n° 40/94. lorsque ce client ne fait pas partie de la base d'utilisation normale. Surtout, suivre le terrain. Méthode de transfert originale et pas seulement l'événement d'authentification en cours, parce que les sessions initiées par le code de périphérique peuvent garder cette piste même si l'authentification ultérieure ne l'affiche plus explicitement.

Dans les paramètres, recherchez des dispositifs persistants que les opérateurs laissent derrière leur pivot, y compris les outils RMM qui sont souvent déployés pour maintenir l'accès. Dans les cas étudiés, un agent appelé XEOX (p. ex. C:\\ Program Files (x86)\\ XEOX\\ xeox-agent _ x64.exe) et des tâches programmées avec des motifs pouvant être détectés. Ces impressions varient, combinant ainsi la télémétrie EDR avec des recherches de signature et une alerte sur des exécutables inconnus ou de nouvelles montres de persistance.

Il y a aussi une leçon opérationnelle pour les développeurs et les gestionnaires d'infrastructure : ne jamais exposer les listes de répertoires ou les informations sensibles sur les serveurs publics, nettoyer les historiques de shell et non pas les magasins de mots de passe en texte clair sur les panneaux ou les fichiers en version. Si un dépôt public contient des secrets ou des binaires précompilés, il expose à l'opération complète : apprendre à supprimer les données sensibles de l'historique de Git et à transformer les identifiants engagés ; GitHub explique comment traiter les dépôts avec des informations sensibles ici : https: / / docs.github.com / fr / authentification / gardant-votre-compte-et-données-sécurité / enlevant-sensible-données-de-un-dépôt.

En réponse immédiate à une suspicion : révoquer les jetons et les sessions touchées, forcer l'expiration des jetons de rafraîchissement compromettants, mettre en œuvre la politique d'accès conditionnel qui bloque le flux de code d'appareil si ce n'est pas nécessaire, mettre en quarantaine et prévenir les paramètres détectés avec RMM, et aviser Microsoft et les fournisseurs de services engagés à coordonner les blocs d'atténuation et d'infrastructure rotatifs. Considérez qu'il s'agit d'un exercice de « confinement + durcissement » ; le blocage des PI et des domaines est utile, mais insuffisant si les politiques qui permettent la technique ne sont pas corrigées.

La conclusion éditoriale est que la protection efficace contre ces campagnes nécessite deux couches simultanées : les politiques techniques qui ferment les vecteurs protocolaires (code de l'appareil de blocage lorsque ce n'est pas nécessaire et appliquer CAE) et améliorations opérationnelles qui ferment les fuites et les mauvaises pratiques (contrôle des dépôts, nettoyage des dossiers, rotation secrète). Tant que l'écosystème d'hameçonnage restera commercial et modulaire - avec des fourchettes polies, des binaires prêts et une génération assistée par modèle - les organisations qui croient que le déploiement du MFA et de la triation des utilisateurs est suffisant seront exposées. Défense Microsoft 365 signifie aujourd'hui combiner MFA résistant, accès conditionnel bien conçu, détection d'anomalies de jetons et de bonnes pratiques de sécurité sur les serveurs et les dépôts.