Le 2026-05-21, le FBI a publié l'avis de service public I-052126-PSA, alertant sur un kit de Phishing-as-a-Service appelé Kali365 qui détourne des comptes Microsoft 365. Il ne vole pas de mots de passe. Il n'intercepte pas de codes MFA. La victime se connecte sur la page de Microsoft, termine l'authentification multifacteur, et l'attaquant repart quand même avec un accès persistant. Kali365 y parvient en détournant l'octroi d'autorisation d'appareil d'OAuth 2.0 pour capturer les jetons d'accès et de rafraîchissement que Microsoft émet après une connexion parfaitement légitime.
Ce n'est pas une technique nouvelle. En février 2025, Microsoft a documenté une campagne de phishing par code d'appareil menée par Storm-2372, un acteur qu'elle évalue comme aligné sur les intérêts étatiques russes, actif contre des cibles gouvernementales, de défense, de télécommunications et d'énergie. Ce qui a changé, c'est l'empaquetage. Kali365 transforme cette tactique en un kit par abonnement avec des leurres générés par IA, de sorte qu'un acteur peu qualifié peut l'exécuter. La connexion réussit, l'invite MFA réussit, et l'hypothèse sous-jacente aux deux échoue : qu'un événement d'authentification réussi indique qui détient la session une minute plus tard.
Cette hypothèse est la véritable cible. « L'utilisateur s'est authentifié avec succès » a cessé d'être une frontière de confiance. La session active, portée par un jeton au porteur lié à rien, l'est.
Ce que Kali365 automatise réellement
Le FBI décrit Kali365 comme une plateforme de PhaaS distribuée via Telegram, apparue pour la première fois en avril 2026. Elle regroupe des leurres de phishing générés par IA, des modèles de campagne automatisés, des tableaux de bord en temps réel pour suivre des personnes ciblées, et la capture de jetons OAuth. Selon les mots du FBI, elle « abaisse la barrière d'entrée, donnant aux attaquants moins techniques accès à des leurres de phishing générés par IA, des modèles de campagne automatisés, des tableaux de bord de suivi d'individus/entités en temps réel, et des capacités de capture de jetons OAuth ».
Voyez-y une division du travail. Les parties difficiles du phishing par code d'appareil étaient autrefois de rédiger un leurre convaincant et d'exploiter de manière fiable l'infrastructure de capture et d'échange de jetons dans une fenêtre de 15 minutes. L'IA rédige le leurre. Le kit gère la plomberie OAuth. L'opérateur ne fait que choisir des cibles. C'est ce qui en fait un exemple plus net d'IA qui met le fraude à l'échelle que la plupart : il n'invente pas une nouvelle attaque, il supprime la compétence qui gardait l'accès à une attaque existante.
Le flux de code d'appareil, étape par étape
L'octroi d'autorisation d'appareil existe pour une bonne raison. Il permet de se connecter sur des appareils où la saisie est malaisée, comme les téléviseurs connectés, les décodeurs et les outils en ligne de commande. Vous voyez un code court, vous le saisissez sur votre téléphone, l'appareil est connecté. La conception est légitime et utilisée en permanence dans Microsoft 365.
Voici le même flux transformé en attaque :
- L'attaquant envoie un
POSTàhttps://login.microsoftonline.com/common/oauth2/v2.0/devicecodeen utilisant unclient_idpropre et public, souvent Microsoft Office (d3590ed6-52b3-4102-aeff-aad2292ab01c) ou Azure CLI (04b07795-8ddb-461a-bbee-02f9e1bf7b46). Ce sont des clients Microsoft pré-consentis, donc aucun enregistrement d'application personnalisée ni consentement d'administrateur n'est nécessaire. - Microsoft renvoie un
device_code, unuser_codesaisissable par un humain, l'URL de vérificationhttps://microsoft.com/deviceloginet unexpires_inde 900 secondes. L'attaquant dispose maintenant d'une fenêtre de 15 minutes. - L'attaquant incite la victime à ouvrir
microsoft.com/deviceloginet à saisir leuser_code. Microsoft Entra ne prend pas en chargeverification_uri_complete, la variante préremplie du lien, donc la victime doit taper le code à la main. Cette étape manuelle est précisément ce qu'un leurre à forte conversion rédigé par IA est conçu pour provoquer. - La victime s'authentifie sur la vraie page de Microsoft, termine la MFA et donne son consentement. Chaque élément est réel : le domaine est Microsoft, le certificat est valide, l'invite MFA est celle qu'elle reçoit toujours.
- L'attaquant interroge
https://login.microsoftonline.com/common/oauth2/v2.0/tokenavecgrant_type=urn:ietf:params:oauth:grant-type:device_codeet ledevice_code, en respectant l'interval(5 secondes) et en absorbant les réponsesauthorization_pending, jusqu'à ce que le point de terminaison renvoie unaccess_tokenet unrefresh_token.
Il n'y a pas de domaine usurpé à signaler ni de charge utile sur le terminal à détecter. La partie frauduleuse est un flux Microsoft légitime effectué par la mauvaise personne, et le jeton qu'il produit est indiscernable d'un jeton émis pour une vraie session.
Pourquoi la MFA est satisfaite et l'Accès conditionnel laisse passer
C'est la partie qui prend les équipes au dépourvu. La victime a réellement effectué la connexion interactive, MFA comprise, contre le vrai point de terminaison de Microsoft. La connexion est donc enregistrée comme satisfaite par MFA, reflétée dans le détail d'authentification du journal de connexion d'Entra et, sur les jetons v1.0, dans le claim amr portant mfa. L'Accès conditionnel évalue cette connexion comme une connexion interactive conforme et validée par MFA, et émet les jetons en conséquence.
L'attaquant ne contourne pas la MFA au sens de vaincre le défi. Le défi s'est exécuté et a réussi. Ce que le modèle de jeton au porteur ne fait jamais, c'est lier le jeton émis à l'appareil qui a relevé le défi. La MFA a répondu à « la bonne personne s'authentifie-t-elle en ce moment ? ». Elle n'a pas répondu à « est-ce le bon appareil qui détient ce jeton trente secondes plus tard ? », et rien dans le flux standard ne le fait.
La portée des dégâts : jetons de rafraîchissement FOCI et escalade vers le PRT
Un jeton d'accès capturé est nuisible pendant une heure. Le jeton de rafraîchissement est le vrai prix, et le modèle de jetons de Microsoft le rend pire que la compromission d'une seule application.
Les jetons de rafraîchissement émis aux clients propres de Microsoft sont généralement des jetons FOCI, Family of Client IDs. Un jeton de rafraîchissement de famille obtenu via un client peut être échangé contre des jetons d'accès en tant qu'autres clients de la famille, de sorte qu'un jeton capturé via Microsoft Office peut être échangé contre un accès à Exchange Online, Teams, SharePoint et OneDrive, et Microsoft Graph. Un seul jeton de rafraîchissement volé est un mouvement latéral à travers les données du locataire, et non un point d'appui dans une application.
L'arithmétique de la durée de vie aggrave la situation. Depuis janvier 2021, les durées de vie des jetons de rafraîchissement ne sont plus réglables via les politiques de durée de vie des jetons ; la fenêtre d'inactivité par défaut du jeton de rafraîchissement est de 90 jours et l'âge maximal est, en pratique, jusqu'à révocation. Là où le client et la ressource prennent en charge l'Évaluation continue de l'accès, les jetons d'accès peuvent s'étendre à 24 à 28 heures, bien qu'ils soient révocables en quasi-temps réel lors d'événements critiques. Pour forcer la réauthentification, vous vous appuyez désormais sur la fréquence de connexion de l'Accès conditionnel, et non sur la politique de jeton.
Le plafond d'escalade est encore plus haut. Dans la mise à jour de février 2025 de son rapport sur Storm-2372, Microsoft a observé l'acteur basculer vers le client Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) pour obtenir un jeton de rafraîchissement, enregistrer un appareil contrôlé par l'attaquant dans Entra ID, puis frapper un Primary Refresh Token. Un PRT est un matériel d'identité durable et lié à l'appareil qui débloque une authentification unique étendue. Le code d'appareil est le point d'entrée ; le PRT est le locataire.
« Authentifié avec succès » a cessé d'être une frontière de confiance
Pendant des années, le modèle dominant était simple : vérifier l'utilisateur à la connexion, puis faire confiance au jeton jusqu'à son expiration. Les back-ends enregistrent l'événement d'authentification, les fournisseurs d'identité alertent sur les schémas de connexion inhabituels, et une fois la session établie, la plupart des applications cessent de demander qui se trouve de l'autre côté.
Le phishing par code d'appareil est une réfutation nette de ce modèle. L'événement de connexion est authentique, le jeton est authentique, et la seule chose qui cloche, c'est que le jeton est maintenant détenu par quelqu'un d'autre que la personne qui s'est authentifiée. Un jeton émis pour un utilisateur sur son ordinateur portable dans un pays peut être échangé et rejoué depuis l'infrastructure de l'attaquant dans un autre, et Entra voit une session valide et satisfaite par MFA parce que, au moment de l'authentification, elle l'était.
Il est utile de voir les trois chemins courants de vol de jetons côte à côte. Ils aboutissent tous à un jeton valide post-authentification, mais ils touchent des parties différentes de la surface d'attaque, ce qui change à la fois la façon dont ils évitent les contrôles et l'endroit où vous pouvez encore les attraper.
| Attaque | Jeton capturé | Ce qui touche la victime | Où se produit l'usage malveillant | Principale lacune de télémétrie |
|---|---|---|---|---|
| Phishing par code d'appareil (Kali365) | OAuth d'accès et de rafraîchissement (souvent FOCI) | Un message de phishing plus la vraie page microsoft.com/devicelogin | Échange et réutilisation du jeton depuis l'infrastructure de l'attaquant | La connexion est la vraie connexion MFA de la victime ; l'échange lui est attribué |
| Phishing adversary-in-the-middle | Jeton de session ou cookie capturé en transit | Une fausse page de connexion en proxy inverse | Session rejouée depuis l'infrastructure de l'attaquant | Un domaine ressemblant existe mais la session paraît valide en aval |
| Malware infostealer | Cookies de session copiés sur le disque | Malware s'exécutant sur le terminal | Session reprise depuis le cookie volé | Compromission du terminal, mais la session reprise passe les contrôles côté serveur |
Le fil conducteur est la dernière colonne. Dans chaque cas, l'application détient un jeton valide et traite son détenteur comme l'utilisateur authentifié. L'appareil qui s'est authentifié et l'appareil qui utilise désormais le jeton sont différents, et le modèle standard n'a aucun contrôle natif pour cette différence.
Le détecter et le bloquer
Il y a deux tâches ici : fermer le flux, et trouver où il a déjà été utilisé.
Bloquer le flux dans l'Accès conditionnel d'Entra
Cela correspond directement à la recommandation principale du FBI. Dans l'Accès conditionnel, utilisez la condition de flux d'authentification et réglez le flux de code d'appareil sur Bloquer, et bloquez le transfert d'authentification dans la même politique. La propre recommandation de Microsoft est de bloquer le flux de code d'appareil partout où c'est possible.
- Appliquez la politique à tous les utilisateurs et à toutes les ressources, puis excluez les comptes de secours et d'accès d'urgence pour qu'une mauvaise configuration ne vous verrouille pas dehors.
- Si un processus légitime enregistre des appareils via le flux de code d'appareil, excluez le Service d'enregistrement des appareils (
01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9), car les politiques de flux d'authentification y sont appliquées lorsque la politique vise toutes les ressources. - Auditez l'usage actuel du code d'appareil avant d'appliquer, pour que les exceptions légitimes soient connues plutôt que devinées.
Chercher l'usage antérieur dans les journaux de connexion
Les connexions par code d'appareil sont visibles dans les journaux de connexion d'Entra ID. Le filtre de détection le plus utilisé est le protocole d'authentification :
SigninLogs
| where AuthenticationProtocol == "deviceCode"
| summarize logins=count() by UserPrincipalName, AppDisplayName, IPAddress, tostring(LocationDetails.countryOrRegion)
Surveillez aussi OriginalTransferMethod == "deviceCodeFlow" pour repérer les sessions suivies par protocole lors de rafraîchissements ultérieurs, et signalez les événements d'enregistrement d'appareil effectués par le client Microsoft Authentication Broker là où vous ne les attendez pas, qui est le signe de l'escalade vers le PRT.
La limite honnête est dans le tableau ci-dessus. L'événement d'authentification qui a produit le jeton est la vraie connexion satisfaite par MFA de la victime, donc la détection par journaux est forte sur le flux lui-même mais faible sur l'échange et la réutilisation qui suivent, qu'Entra attribue à cette connexion légitime.
Là où la faille du code d'appareil se ferme vraiment : la couche de session
Un jeton volé doit être utilisé quelque part, et cet endroit n'est presque jamais l'appareil qui s'est authentifié. Ce décalage est le signal que le modèle de jeton au porteur jette et celui que cside est conçu pour conserver.
L'empreinte d'appareil avancée de cside collecte plus de 100 signaux de navigateur, d'appareil et de réseau pour créer un identifiant persistant de chaque visiteur. À l'authentification, ces signaux établissent une base de référence pour la session. Quand un jeton est ensuite présenté depuis un environnement différent, une empreinte TLS et navigateur différente, un ASN ou une sortie par proxy résidentiel différents, des marqueurs d'automatisation ou de mode headless qui n'étaient pas présents à la connexion, l'empreinte ne correspond pas à la base de référence, et ce décalage peut déclencher l'invalidation du jeton ou un défi renforcé avant que l'attaquant n'atteigne les données. Nous approfondissons cela dans comment les données de localisation avancées détectent la réutilisation non sûre de jetons et sur le changement plus large dans pourquoi la session du navigateur est désormais un plan de contrôle de sécurité.
cside surveille également l'environnement côté client à la recherche des scripts malveillants et des charges de détournement de session qui opèrent entièrement sous la couche d'authentification. C'est la visibilité au niveau du navigateur que les journaux back-end ne peuvent pas fournir, et c'est la partie de la surface d'attaque où le vol de jetons se décide réellement. Pour savoir où cela s'inscrit dans une pile plus large de prise de contrôle de compte, notre guide pour comparer les solutions de prévention de l'ATO cartographie où s'arrête la MFA et où commencent les signaux au niveau de la session.
Réservez une démo pour voir comment cside détecte les sessions compromises avant que les dégâts ne soient faits.
Les contrôles Microsoft 365, le comportement d'Entra et les recommandations du FBI sont exacts au 2026-05-31. Les flux des fournisseurs, les ID de client et les avis évoluent ; confirmez les options actuelles de flux de code d'appareil et d'Accès conditionnel de Microsoft avant de vous appuyer sur un réglage spécifique.
