Le paysage de la compromission d'identité a radicalement évolué : pourquoi s'épuiser à contourner l'authentification multifacteur (MFA) par épuisement de notifications push quand un collaborateur peut simplement céder l'accès à son compte de son propre chef ? Référencée sous la technique T1566.002 (Consent Phishing) par le framework MITRE ATT&CK, l'attaque par abus d'application OAuth transforme les mécanismes natifs de délégation de permissions en un vecteur d'exfiltration furtif et persistant.
Anatomie de l'attaque : l'illusion de conformité OAuth 2.0
Dans ce scénario d'ingénierie sociale avancée, l'attaquant enregistre une application multilocataire (multi-tenant) au sein de sa propre infrastructure Microsoft Entra ID. Il lui attribue un nom évocateur (« Mise à jour Sécurité OneDrive », « Validation des Conditions Générales RH ») et configure un URI de redirection sous son contrôle. La victime reçoit un e-mail ou un message Teams l'invitant à valider un document urgent. En cliquant sur le lien, elle est redirigée vers la page d'authentification officielle login.microsoftonline.com.
Une fois authentifiée légitimement avec son MFA habituel, l'utilisateur fait face à la boîte de dialogue standard de consentement de Microsoft Entra ID. Le piège se referme : en cliquant sur « Accepter », la victime délègue des permissions applicatives critiques sans jamais fournir son mot de passe. L'attaquant reçoit alors un jeton d'actualisation (Refresh Token) et un jeton d'accès (Access Token) lui conférant des droits directs sur les API Graph de la victime.
L'angle mort natif et la télémétrie critique
Cette attaque contourne nativement les stratégies d'accès conditionnel (Conditional Access) basées sur l'état de conformité de l'appareil ou la localisation IP lors des accès ultérieurs. Grâce au scope offline_access, l'attaquant peut interroger silencieusement les API Microsoft Graph depuis n'importe quelle adresse IP ou infrastructure cloud sans réauthentification de l'utilisateur. Microsoft Purview et l'Audit Log standard capturent l'événement, mais l'analyse contextuelle fait souvent défaut dans les configurations par défaut sans règles de corrélation avancées.
Détection par Advanced Hunting (KQL)
Pour isoler les consentements suspects accordés par les utilisateurs à des applications tierces réclamant des privilèges élevés sur les fichiers ou les courriels, exécutez la requête KQL suivante dans votre console de chasse :
CloudAppEvents
| where ActionType in~ ("Consent to application", "Add delegated permission grant")
| extend Target = parse_json(RawEventData.Target)
| extend AppName = tostring(Target[0].DisplayName),
AppId = tostring(Target[0].Id)
| extend ModProps = parse_json(RawEventData.ModifiedProperties)
| mv-expand ModProps
| where ModProps.DisplayName =~ "ConsentAction.Permissions"
| extend GrantedScopes = tostring(ModProps.NewValue)
| where GrantedScopes has "offline_access"
and GrantedScopes has_any ("Files.ReadWrite", "Files.ReadWrite.All", "Mail.ReadWrite", "FullControl")
| project Timestamp, ConsentedBy = AccountDisplayName, IPAddress,
AppName, AppId, GrantedScopes, UserAgent, ReportIdRemédiation SOAR avec Akuity SOC
Dès la génération de la télémétrie d'un consentement à risque, Akuity SOC déploie une riposte automatisée orchestrée sans friction :
- Qualification Zero-Trust in-app : L'assistant IA in-app d'Akuity SOC exécute
audit_enterprise_apps_permissions, révélant la criticité des scopes (Files.ReadWrite.All,offline_access) et l'absence de vérification éditeur, sans aucune fuite de données vers des outils web tiers. - Riposte SOAR 1-clic immédiate : Déclenchement de la Server Action
revokeOAuthApp()depuis l'inventaire des éléments de preuve pour supprimer instantanément le Service Principal malveillant et révoquer l'ensemble des refresh tokens sur Entra ID. - Garde-fous critiques et conformité : Élévation de privilèges sécurisée par challenge MFA AAL2 obligatoire de l'analyste, consignant l'action dans un journal d'audit immuable certifié NIS 2 et SOC 2 Type II.
Détectez et révoquez les applications malveillantes en un clic grâce à la puissance du moteur SOAR sans agent d'Akuity SOC.
Démarrer votre essai gratuit de 14 jours (sans carte bancaire) →Foire Aux Questions (FAQ)
Quelle est la différence entre un consentement utilisateur et un consentement administrateur ?
Le consentement utilisateur permet à un individu de déléguer des droits sur ses propres ressources (ex. ses courriels ou son OneDrive). Le consentement administrateur (Admin Consent) permet d'octroyer des permissions applicatives au niveau du tenant entier, ce qui permet à l'application d'accéder aux données de l'ensemble des collaborateurs sans interaction supplémentaire.
Comment restreindre préventivement le consentement des utilisateurs dans Microsoft Entra ID ?
Il est recommandé de configurer les paramètres de consentement utilisateur dans Entra ID pour bloquer le consentement autonome vers des applications non vérifiées, et de mettre en place le workflow de demande d'approbation administrateur (Admin Consent Workflow).