Hameçonnage par code d'appareil OAuth : comment Storm-2372 a transformé un flux légitime en vol de jetons
Le Device Authorization Grant OAuth 2.0, normalisé dans la RFC 8628, a été conçu pour les appareils qui ne peuvent pas facilement afficher un navigateur ou accepter un clavier : téléviseurs, imprimantes, outils CLI et matériel IoT. Il permet à l'utilisateur de s'authentifier sur un second appareil pendant que l'appareil contraint interroge le serveur pour un jeton. En 2025, des attaquants ont compris que ce même flux est une excellente primitive d'hameçonnage. La victime effectue une vraie connexion sur un vrai fournisseur d'identité, satisfait le MFA et consent à une vraie application — et l'attaquant reçoit les jetons.
1. Le flux en cinq étapes
- Le client envoie une requête à l'endpoint d'autorisation d'appareil avec son
client_idet les scopes demandés. - Le serveur renvoie un
device_code(secret, long), unuser_code(court, lisible), unverification_uriet une expiration. - Le client affiche le
user_codeet demande à l'utilisateur de visiter l'URI. - L'utilisateur se connecte sur son téléphone ou navigateur, saisit le code et approuve.
- Le client interroge l'endpoint de jeton avec le
device_codeet reçoit les jetons d'accès et de rafraîchissement.
Rien dans cette séquence n'est intrinsèquement insecurisé. La faiblesse est sociale : l'attaquant peut initier les étapes 1 et 2 lui-même, puis envoyer le user_code et un lien de vérification authentique à la victime. Celle-ci voit un domaine Microsoft, Google ou Okta légitime, complète le MFA et croit se connecter à un service. L'attaquant, qui détient le device_code, interroge et reçoit les jetons.
2. Storm-2372 et les campagnes de 2025
Microsoft Threat Intelligence a documenté Storm-2372 en février 2025. L'acteur utilisait l'hameçonnage par code d'appareil contre des tenants Microsoft 365, ciblant gouvernements, ONG, services IT, défense et télécommunications. La campagne n'exploitait pas de vulnérabilité logicielle. Elle abusait du Device Authorization Grant avec un client ID légitime, puis utilisait les jetons obtenus pour accéder au courrier et à d'autres ressources.
Comme l'authentification et le MFA ont lieu sur l'appareil et le réseau de la victime, la connexion peut paraître conforme. L'usage ultérieur du jeton par l'attaquant vient d'un autre lieu, mais l'événement d'authentification initial ressemble à une connexion normale. Proofpoint a documenté d'autres activités d'hameçonnage par code d'appareil en décembre 2025, confirmant que la technique est passée d'une note de tradecraft à des playbooks criminels et étatiques reproductibles.
La tromperie centrale : la victime ne donne pas son mot de passe à l'attaquant. Elle lui donne un jeton que le fournisseur d'identité a émis après une connexion réussie protégée par MFA.
3. Pourquoi le MFA ne vous sauve pas
Le MFA protège l'étape d'authentification. Dans l'hameçonnage par code d'appareil, la victime complète correctement cette étape. L'attaquant ne voit ni le mot de passe ni le code à usage unique ; il reçoit la sortie d'une authentification réussie. C'est pourquoi la technique est souvent décrite comme un « contournement du MFA » alors qu'aucun contrôle MFA n'a échoué. Le contrôle protégeait la connexion, pas l'émission du jeton à un appareil inconnu.
La même logique s'applique aux authentifications résistantes au phishing. Une passkey prouve que l'humain sur l'appareil de la victime s'est authentifié. Elle ne prouve pas que l'appareil qui interroge le jeton est le même, ni que l'utilisateur voulait autoriser ce client.
4. Détecter l'authentification par code d'appareil
Dans Microsoft Entra ID, ces connexions apparaissent dans les logs avec le protocole d'authentification deviceCode. Cherchez :
- Des connexions par code d'appareil réussies pour des utilisateurs qui n'utilisent pas d'outils CLI ni d'appareils contraints.
- Une émission de jeton suivie peu après d'un accès au courrier depuis un nouvel ASN ou pays.
- Plusieurs utilisateurs recevant des demandes de code en peu de temps, suggérant une campagne.
- Des consentements accordés à des applications clientes inconnues.
- L'usage d'un refresh token depuis un appareil qui n'a jamais complété de connexion interactive.
// Exemple de chasse Microsoft Sentinel / Defender XDR
SigninLogs
| where AuthenticationProtocol =~ "deviceCode"
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location, ClientAppUsed
| order by TimeGenerated desc
Examinez l'ID de l'application cliente. Les attaquants utilisent souvent un client public de première partie ou très connu pour que l'écran de consentement paraisse familier. L'anomalie n'est pas l'application seule ; c'est la combinaison application, utilisateur, appareil et modèle d'accès ultérieur.
5. Contrôles défensifs
5.1 Bloquer le flux de code d'appareil là où il n'est pas nécessaire
Conditional Access d'Entra ID prend en charge une condition « Authentication flows » qui peut bloquer le flux. Créez une politique pour tous les utilisateurs, avec des exclusions pour le petit groupe qui utilise légitimement des outils CLI. C'est le contrôle au plus fort levier.
5.2 Restreindre le consentement
Désactivez le consentement utilisateur pour les applications tierces, ou limitez-le aux éditeurs vérifiés et aux scopes à faible risque. Un attaquant qui ne peut pas obtenir de consentement pour un client utile a un chemin bien plus difficile.
5.3 Exiger des appareils conformes ou gérés
Une politique exigeant un appareil conforme pour le courrier et les fichiers bloque la réutilisation du jeton depuis une machine attaquante, même si le jeton a été émis légitimement.
5.4 Utiliser la protection des jetons et l'évaluation continue
La protection des jetons lie les jetons à un certificat d'appareil lorsque c'est pris en charge. L'évaluation continue d'accès (CAE) révoque l'accès en quasi-temps réel lorsque le risque change, par exemple après une réinitialisation de mot de passe.
5.5 Réduire la durée de vie et faire tourner les refresh tokens
Réduisez la fenêtre d'utilité d'un refresh token volé. Activez la rotation et la détection de réutilisation pour qu'un jeton utilisé depuis un second lieu invalide la chaîne.
5.6 Former les utilisateurs au leurre précis
Une formation générique ne suffit pas. Dites aux utilisateurs qu'une page Microsoft ou Google légitime demandant un code court est un signal d'alarme sauf s'ils ont initié le flux eux-mêmes. Demandez-leur de signaler le message plutôt que de compléter le code.
6. Si un jeton est soupçonné volé
- Révoquez les refresh tokens de l'utilisateur concerné et forcez une réauthentification.
- Invalidez les sessions et examinez les règles de boîte aux lettres, les consentements OAuth et les paramètres de transfert.
- Examinez les logs de connexion et d'audit pour l'événement de code, l'échange du jeton et les accès ultérieurs.
- Vérifiez les nouveaux consentements et retirez ceux qui ne sont pas approuvés.
- Chassez latéralement les messages envoyés depuis le compte compromis contenant des codes ou des liens de vérification.
7. Conclusion
L'hameçonnage par code d'appareil est une conséquence de conception d'un protocole utile. Le flux existe pour qu'un téléviseur s'authentifie sans clavier ; les attaquants l'abusent parce que l'étape de vérification est facile à sous-traiter à une victime. La défense n'est pas de désactiver OAuth ni de se méfier du MFA, mais de contraindre le flux : le bloquer là où il est inutile, exiger des appareils conformes, restreindre le consentement, réduire la durée de vie des jetons et détecter le protocole dans les logs. La victime de ces campagnes a tout fait correctement à l'écran de connexion. L'architecture de sécurité doit la protéger après cet écran, quand le jeton quitte l'appareil.