Phishing par Device Code touche 340+ organisations Microsoft 365
Analyse technique
Mécanisme du device code et vecteur d'abus
Le flux OAuth 2.0 dit "device code" a été conçu pour permettre l'authentification sur des appareils à interface limitée (box, consoles, TV, outils en ligne de commande). Un appareil sans navigateur obtient un device_code et un user_code, puis indique à l'utilisateur d'aller sur la page d'authentification (par exemple https://microsoft.com/devicelogin) et d'entrer le user_code pour lier l'appareil au compte. La description normative de ce flux est disponible dans la documentation Microsoft ².
Les campagnes récentes exploitent cette logique sans toucher au mot de passe. Les attaquants utilisent deux modes principaux:
- Phishing par invitation directe - la victime reçoit un lien ou est redirigée vers une page qui initie le flux device code pour une application malveillante. L'utilisateur pense terminer une vérification et accepte, donnant ainsi un consentement qui permet à l'application d'obtenir des jetons.
- Support technique falsifié - l'attaquant se fait passer pour un support et demande à la victime d'entrer un code sur la page d'authentification pour "vérifier" un problème. L'attaquant a préalablement commencé le flux côté application malveillante et récupère le token une fois le code validé.
Quand la victime valide le code, l'application obtient un access_token et, si la scope offline_access a été accordée, un refresh_token. Avec ces jetons l'attaquant peut accéder aux ressources Microsoft 365 et maintenir un accès persistant sans connaître le mot de passe de l'utilisateur.
Ces attaques ont un fort impact opérationnel car elles exploitent un mécanisme légitime prévu pour faciliter l'accès, et non une vulnérabilité technique au sens classique. Des campagnes récentes ont touché plus de 340 organisations, réparties sur plusieurs pays, ce qui montre l'efficacité du vecteur¹.
Indicateurs techniques observables
Pour détecter et enquêter, surveillez ces signaux dans vos logs Azure AD, SIEM et solutions de protection des endpoints:
- Entrées dans les Sign-in Logs où la méthode d'authentification contient "device_code" et le client_app_id n'est pas reconnu. Recherchez des créations d'applications ou d'objets ServicePrincipal immédiatement avant ou après ces connexions.
- Présence d'objets OAuth2PermissionGrant ou de ServicePrincipal liés à des applications récemment créées ou imitant des noms internes. Interrogez Graph API: GET /oauth2PermissionGrants pour lister les grants, et GET /servicePrincipals pour repérer des enregistrements suspects.
- Utilisation de jetons depuis des IP inhabituelles, des ASN étrangers ou des plages résidentielles. Corrélez avec le User-Agent et la fréquence des appels vers les endpoints Graph API pour repérer des comportements d'automatisation.
- Notifications d'élévation de privilèges quand une application demande des scopes sensibles (par exemple mail.read, files.readwrite, offline_access). Un pic de demandes de scopes sur des comptes peu habituels doit alerter.
Exemples de requêtes utiles:
- Lister les grants suspects via Graph API: GET https://graph.microsoft.com/v1.0/oauth2PermissionGrants
- Vérifier les connexions device_code: filtrer les sign-ins sur authenticationMethods ou par clientAppId dans les logs Azure AD.
Techniques d'évasion observées
Les attaquants réduisent leur surface d'alerte en utilisant des noms d'applications très proches de services légitimes et en conservant des chaînes de redirection valides. Ils demandent souvent des scopes minimaux au départ et réalisent des escalades après compromission. La rotation rapide de client_id et le déploiement sur plusieurs tenants rendent l'inventaire et la réponse plus complexes.
Impacts business
Exfiltration et usurpation
Un accès obtenu via des jetons OAuth permet l'extraction d'emails, de fichiers OneDrive et d'éléments Teams. L'attaquant peut mener du spear-phishing interne, manipuler des conversations pour demander des virements ou des informations sensibles, et établir des relais vers d'autres comptes. Des campagnes documentées ont déjà entraîné des vols de données sensibles et des compromissions de comptes avec privilèges élevés¹.
Coûts estimés
Les coûts d'un incident varient fortement selon la portée. Pour une compromission isolée d'un collaborateur non administratif, nous estimons entre 30k et 75k EUR, incluant investigation, remédiation et communications internes. Pour une compromission d'un compte à privilèges, le coût peut atteindre 1M EUR ou plus si l'on ajoute l'enquête forensique, la perte commerciale et les obligations réglementaires. Ces ordres de grandeur sont cohérents avec les tendances observées dans les rapports d'incident et les études de coût des fuites de données³.
Risque réglementaire et réputationnel
L'accès non autorisé à des ressources contenant des données personnelles déclenche souvent des obligations de notification sous le RGPD et impacte la confiance des partenaires. Les incidents basés sur des consentements OAuth sont parfois détectés tardivement car l'utilisateur a validé volontairement le code, ce qui retarde la corrélation d'événements et prolonge la fenêtre d'exfiltration.
Recommandations
Contrôles techniques immédiats (priorité haute)
- Restreindre le consentement aux applications non vérifiées. Exiger l'approbation administrateur pour toutes les permissions sensibles et désactiver le consentement utilisateur pour les scopes critiques.
- Révoquer les OAuth2PermissionGrants suspects via Microsoft Graph: lister les grants (GET /oauth2PermissionGrants) et supprimer les entrées douteuses (DELETE). Revoir les ServicePrincipals récemment créés ou modifiés.
- Activer la vérification des éditeurs pour les applications internes: n'accepter que les applications avec un Verified publisher quand c'est possible.
- Bloquer les flux "public client" si non nécessaires. Pour les applications sensibles, interdire l'usage du device code et des autres flux qui n'apportent pas de contrôle d'authentification fort.
Détection et surveillance (priorité moyenne)
- Créer des règles SIEM qui alertent sur toute création/modification d'application Azure AD, sur la suppression ou l'ajout de OAuth2PermissionGrants, et sur les connexions utilisant device_code. Corréler ces événements avec l'accès aux boîtes mail et aux stockages OneDrive/SharePoint.
- Scanner régulièrement les Sign-in Logs pour le champ authenticationMethods et pour des client_app_id inconnus. Automatiser des rapports hebdomadaires des nouveaux ServicePrincipals.
- Repérer les patterns d'accès atypiques: utilisation de jetons depuis IP résidentiels, ASN étrangers, ou accès en dehors des horaires de travail habituels.
Politiques organisationnelles (priorité moyenne)
- Imposer la MFA sur tous les comptes et renforcer les contrôles conditionnels: exiger MFA pour l'accès aux ressources critiques et bloquer l'accès depuis régions non approuvées.
- Former les collaborateurs au schéma device code: expliquer que Microsoft ne demandera jamais d'entrer un code fourni par un tiers et montrer les étapes légitimes du flux.
- Mettre en place des procédures rapides pour révoquer des consentements, changer des secrets et invalider des tokens en cas de suspicion.
Procédures de remédiation et post-incident
- Sur suspicion de compromission: révoquer immédiatement les sessions et les refresh tokens via Azure AD, supprimer les grants malveillants, et changer les credentials administratifs exposés.
- Lancer une investigation forensique ciblée: reconstituer la chronologie des consentements, analyser les logs d'audit Azure AD et les appels Graph API effectués par l'application compromise.
- Communiquer rapidement aux équipes concernées et préparer les notifications réglementaires si des données personnelles sont impliquées.
Adopter une approche qui dépasse la seule protection des mots de passe est indispensable. Il faut intégrer la gouvernance des autorisations OAuth et renforcer la visibilité sur les consentements pour réduire de façon durable la surface exposée.
