Phishing Entra ID via redirection OAuth : alerte sécurité

Introduction : pourquoi c’est important

Les liens OAuth vers des fournisseurs d’identité (IdP) bien connus comme Microsoft Entra ID sont souvent considérés comme fiables par les utilisateurs et, dans certains cas, traités avec davantage de tolérance par les contrôles de sécurité. Les dernières recherches de Microsoft mettent en évidence un comportement de redirection OAuth « by design » exploité pour envoyer les utilisateurs depuis des domaines de connexion légitimes vers l’infrastructure des attaquants — permettant du phishing et la distribution de malware tout en ressemblant à un flux de connexion normal.

C’est particulièrement pertinent pour les administrateurs IT dans les organisations gouvernementales et du secteur public, qui ont été spécifiquement ciblées dans l’activité observée.

Nouveautés / principaux constats

La Microsoft Defender Security Research Team a observé une exploitation, initiée par phishing, des mécanismes de redirection OAuth à travers des signaux email, identité et endpoint :

• Abus des flux OAuth silencieux : les attaquants fabriquent des URL d’autorisation OAuth en utilisant des paramètres comme prompt=none pour tenter une vérification d’authentification silencieuse (sans UI).
• Scopes volontairement invalides pour forcer un chemin d’erreur : les requêtes incluent scope=<invalid_scope> (ou d’autres déclencheurs d’échec) pour générer de manière fiable une erreur OAuth.
• Redirection déclenchée par erreur vers un URI contrôlé par l’attaquant : lorsque l’IdP renvoie une erreur (par exemple, interaction_required), le navigateur est redirigé vers le redirect URI enregistré de l’application, que l’attaquant configure pour pointer vers des pages de phishing ou des sites de téléchargement de malware.
• Aucun vol de jeton requis pour la redirection : l’attaquant ne cherche pas nécessairement à faire aboutir OAuth ; la redirection est l’objectif principal.
• Mauvais usage du paramètre state pour la personnalisation : le paramètre state — destiné à la corrélation requête/réponse — a été détourné pour transmettre l’adresse email de la victime (en clair, hex, Base64 ou encodage personnalisé) afin que les pages de phishing puissent pré-remplir les identifiants.
• Schémas de diffusion de la campagne : les leurres de phishing incluaient des demandes de signature électronique, des thèmes financiers/de sécurité sociale, du partage de documents, du contenu Teams/réunion, et des invites de réinitialisation de mot de passe. Certains utilisaient des pièces jointes PDF avec des liens intégrés et même des invitations calendrier .ics.
• Outillage en aval : les pages post-redirection utilisaient fréquemment des frameworks de phishing comme EvilProxy (attacker-in-the-middle) conçus pour capturer identifiants et cookies de session, en ajoutant parfois des étapes CAPTCHA/interstitial.

Impact sur les administrateurs IT et les utilisateurs finaux

• Risque accru de clic : les liens commencent sur des domaines IdP de confiance (par exemple, login.microsoftonline.com), ce qui augmente la confiance des utilisateurs.
• Pression de contournement des défenses : les vérifications de réputation d’URL traditionnelles peuvent se concentrer sur le domaine initial et manquer la destination finale.
• Besoin de visibilité multi-couches : Microsoft indique que Defender a corrélé des signaux sur email, identité et endpoint, soulignant qu’une détection via un seul contrôle peut être insuffisante.
• Menace persistante : Microsoft Entra a désactivé les applications OAuth malveillantes observées, mais l’activité associée persiste — une surveillance reste nécessaire.

Actions / prochaines étapes

1. Chasser des patterns d’autorisation OAuth suspects dans les logs et la télémétrie proxy, notamment :
   • prompt=none combiné à des valeurs scope inhabituelles/invalides
   • Échecs OAuth fréquents suivis de redirections vers des domaines non корпоративеs
   • Usage de /common/ dans des contextes de phishing inattendus et à fort volume
2. Revoir et restreindre le consentement d’application et les enregistrements d’applications :
   • Auditer les applications récemment créées et les redirect URIs visant des domaines non fiables
   • Renforcer qui peut enregistrer des applications/modifier des redirect URIs dans Entra ID
3. Renforcer les protections anti-phishing au-delà des contrôles « domaine de confiance » :
   • S’assurer que les outils de detonation d’URL / safe-link suivent les redirections
   • Éduquer les utilisateurs : « commence sur la page de connexion Microsoft » ne garantit pas la sécurité
4. Valider Conditional Access et les contrôles de session :
   • Surveiller la télémétrie de sign-in et les erreurs OAuth pour détecter des anomalies et des groupes d’utilisateurs ciblés
5. Exploiter la corrélation Defender :
   • Tirer parti de Microsoft Defender for Office 365 + Defender for Identity/Endpoint pour corréler le leurre email, le comportement de sign-in et l’activité de charge utile sur l’endpoint.