Kali365 contourne la double authentification Microsoft 365 :
comment cette attaque vole les jetons d’accès sans voler le mot de passe.

Kali365 existe bien. Le FBI lui a consacré une alerte publique le 21 mai 2026 et indique avoir observé la plateforme pour la première fois en avril. Elle est présentée comme un service de phishing prêt à l’emploi permettant à des attaquants moins techniques de lancer des campagnes visant Microsoft 365.

Le service fournit notamment des leurres de phishing générés avec l’aide de l’intelligence artificielle, des modèles de campagnes automatisés, un tableau de suivi des cibles et des fonctions de capture de jetons OAuth. Le modèle est celui du phishing-as-a-service : l’opérateur du kit fournit l’infrastructure et les outils, tandis que ses clients conduisent leurs propres campagnes.

Le point important est la nature du vol. Kali365 ne dépend pas nécessairement de la récupération du nom d’utilisateur et du mot de passe. Le FBI explique que la plateforme vise les jetons d’accès Microsoft 365. Un jeton valide peut permettre à une session déjà authentifiée d’accéder à des ressources sans redemander immédiatement les identifiants de la victime.

En revanche, plusieurs formulations de la première version de juin étaient trop absolues. La double authentification n’est pas devenue « totalement inutile » pour Microsoft 365 et Kali365 ne peut pas automatiquement pirater n’importe quel compte. La réussite dépend d’une interaction de la victime, de la configuration du tenant Microsoft Entra, des politiques d’accès conditionnel et des protections déjà activées.

Dire que Kali365 « rend la double authentification totalement inutile » produit un titre spectaculaire, mais décrit mal le mécanisme. La MFA continue de protéger contre de nombreuses attaques : mot de passe volé, réutilisation d’identifiants compromis, tentatives automatisées ou connexion classique depuis un nouvel appareil.

Dans une attaque par code d’appareil, la difficulté est différente. La victime peut accomplir correctement sa double authentification. Elle confirme bien son identité auprès de Microsoft. Le problème est qu’elle le fait au profit d’une session qu’elle n’a pas initiée consciemment. L’attaquant ne casse donc pas le second facteur ; il manipule l’utilisateur afin que celui-ci termine une authentification légitime pour la mauvaise session.

Cette distinction est importante pour la sécurité des entreprises. Remplacer une application d’authentification par une autre ne corrige pas à lui seul ce scénario. Former les utilisateurs à ne jamais saisir un code d’appareil reçu par email ou messagerie réduit le risque, mais la protection la plus robuste consiste à contrôler techniquement le flux d’authentification lui-même.

Microsoft permet désormais de cibler le device code flow dans les stratégies d’accès conditionnel. L’entreprise recommande un blocage aussi large que possible, avec des exceptions précises uniquement pour les appareils ou comptes qui en ont réellement besoin.

Le contexte a évolué depuis la première alerte. Microsoft documente maintenant de manière très explicite le caractère risqué du flux de code d’appareil et fournit des stratégies d’accès conditionnel dédiées à son blocage. Le constructeur recommande aux organisations de se rapprocher autant que possible d’un blocage général, puis d’ouvrir uniquement les exceptions nécessaires.

Une évolution importante est entrée en vigueur le 1er juillet 2026 : pour les nouveaux tenants Microsoft Entra utilisant les paramètres de sécurité par défaut, les demandes d’authentification passant par le device code flow sont bloquées. Cette mesure ne signifie pas que tous les environnements Microsoft 365 existants sont automatiquement protégés de la même manière. Les organisations plus anciennes doivent contrôler leur propre configuration.

Microsoft a aussi publié des recommandations spécifiques pour les appareils Teams qui utilisent encore ce mécanisme. Plutôt que d’autoriser le flux pour tout le monde, la documentation propose des exceptions ciblées sur les comptes de ressources nécessaires aux équipements Teams, tout en conservant un blocage par défaut pour le reste de l’organisation.

Par ailleurs, Microsoft avait déjà observé en avril une campagne de phishing à grande échelle exploitant le même principe de code d’appareil avec davantage d’automatisation et d’intelligence artificielle. Cette campagne était associée à un autre kit, EvilTokens. Kali365 n’est donc pas un cas isolé mais une manifestation d’une technique désormais suffisamment rentable pour être industrialisée sous plusieurs formes.

Si une personne pense avoir validé un code reçu dans un message suspect, le changement de mot de passe ne doit pas être la seule réaction. Le problème peut concerner une session et des jetons déjà accordés. Dans un environnement professionnel, l’incident doit être signalé immédiatement à l’administrateur Microsoft 365 ou au responsable informatique.

Il faut examiner les connexions récentes, rechercher l’utilisation du flux de code d’appareil, identifier les emplacements ou applications inhabituels et révoquer les sessions ou jetons concernés. Selon le contexte, le mot de passe doit également être renouvelé et les méthodes d’authentification du compte contrôlées.

L’étape suivante consiste à déterminer ce qui a pu être consulté ou utilisé. Une compromission de messagerie peut nécessiter de vérifier les règles Outlook, les messages envoyés, les suppressions, les transferts et les tentatives d’usurpation auprès de contacts. Pour un compte disposant d’accès à SharePoint, OneDrive ou Teams, l’analyse doit être élargie aux ressources professionnelles exposées.

Enfin, il faut corriger le vecteur initial. Si l’organisation n’a aucune raison d’autoriser le device code flow, le simple nettoyage du compte ne suffit pas : une autre personne pourrait tomber dans le même piège le lendemain. La réponse efficace associe donc traitement de l’incident, contrôle des comptes et modification de la politique d’authentification.