Consentement illicite : enquêter sur les applis OAuth M365
Repérer un consentement OAuth illicite dans le journal d'audit unifié et l'audit Entra, savoir quelles autorisations comptent et retirer l'accès de l'appli.
En bref. Dans un octroi de consentement illicite (illicit consent grant), un utilisateur clique sur Accepter dans une invite de consentement et l'application d'un attaquant obtient un accès délégué à sa boîte ou à ses fichiers, avec ses propres jetons d'actualisation. Cherchez Consent to application (ainsi que Add delegated permission grant, Add app role assignment to service principal, Add service principal) dans l'UAL ou l'audit Entra, lisez ConsentAction.Permissions à la recherche d'autorisations comme Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, offline_access, et vérifiez ConsentContext.IsAdminConsent. Ni la réinitialisation du mot de passe ni la MFA ne retirent cet accès ; seule la révocation de l'autorisation le fait.
Le consentement frauduleux est attractif parce qu'il contourne complètement le mot de passe. Le guide de Microsoft le dit clairement : les mesures de remédiation habituelles, comme la réinitialisation des mots de passe ou l'exigence de la MFA, sont inefficaces contre cette attaque, parce que l'application est externe à l'organisation (Microsoft Learn). Dans les BEC, je le vois aussi comme une seconde étape : l'attaquant, déjà dans la boîte grâce à une session volée, consent à une application de « synchronisation de courrier » pour garder l'accès une fois la session révoquée. MITRE le rattache à Steal Application Access Token (T1528).
À quoi ressemble la piste d'audit
Un même consentement produit souvent plusieurs enregistrements en une ou deux secondes :
Opération (audit Entra / UAL AzureActiveDirectory) | Signification |
|---|---|
Add service principal | L'application apparaît dans le tenant (premier consentement, quel qu'en soit l'auteur) |
Add delegated permission grant | Autorisations déléguées accordées (un oauth2PermissionGrant) |
Add app role assignment to service principal | Autorisations d'application accordées (consentement administrateur) |
Consent to application | Le consentement lui-même, avec son contexte |
Dans l'UAL, les noms se terminent souvent par un point (Consent to application.). Les détails sont dans ModifiedProperties :
| Propriété | Ce qu'il faut lire |
|---|---|
ConsentContext.IsAdminConsent | True : un administrateur a consenti pour le tenant ; Microsoft y voit un possible accès étendu |
ConsentContext.OnBehalfOfAll | True : consentement pour tous les utilisateurs |
ConsentAction.Permissions | Les autorisations, par ex. Scope: Mail.ReadWrite Mail.Send offline_access User.Read, et ConsentType: Principal (un utilisateur) ou AllPrincipals |
TargetId.ServicePrincipalNames | L'identifiant de l'application |
| Nom d'affichage de la cible | Le nom de l'application, souvent générique (« Mail Sync », « PDF Viewer », « Secure Docs ») |
Notez aussi l'acteur, l'IP et l'heure. Un consentement depuis la même IP ou la même session qu'une connexion rejouée est une action de l'attaquant, même si c'est « l'utilisateur » qui a cliqué.
Les autorisations qui doivent inquiéter
| Autorisation | Pourquoi |
|---|---|
Mail.Read, Mail.ReadWrite | Lire (et modifier) la boîte via Graph |
Mail.Send | Envoyer au nom de l'utilisateur : la charge utile du BEC |
MailboxSettings.ReadWrite | Créer règles et transferts via l'API |
Files.Read.All, Files.ReadWrite.All, Sites.Read.All | Tout ce que l'utilisateur peut atteindre dans OneDrive et SharePoint |
offline_access | Un jeton d'actualisation : un accès durable, sans l'utilisateur |
full_access_as_user, EWS.AccessAsUser.All, IMAP.AccessAsUser.All | Accès complet à la boîte par les anciens protocoles |
Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All | Prise de contrôle du tenant si un administrateur les accorde |
User.Read seul (connexion et profil) est normal pour les applications « Se connecter avec Microsoft ». offline_access plus une autorisation sur le courrier, pour une application que personne ne reconnaît, ne l'est pas.
Confirmer et délimiter
Le guide de détection et de remédiation de Microsoft propose d'inventorier les autorisations par utilisateur (centre d'administration Entra → Users → l'utilisateur → Applications), avec PowerShell sur tout le tenant, ou en demandant aux utilisateurs de passer en revue leurs applications sur myapps.microsoft.com. Pour la revue, il pointe les consentements AllPrincipals accordés à des applications non Microsoft, les autorisations Read/Write/All, les utilisateurs à forte valeur et les noms d'applications suspects.
Délimitez ensuite ce que l'application a fait. Son activité est journalisée sous l'identité de l'application : enregistrements MailItemsAccessed avec l'AppId / ClientAppId de l'application, activité Graph si vous disposez des journaux d'activité Microsoft Graph, et connexions du principal de service. L'avis CISA/FBI sur l'intrusion Exchange Online de 2023 explique que des valeurs ClientAppID et AppID inattendues dans les enregistrements MailItemsAccessed ont révélé l'activité (AA23-193A). Voir MailItemsAccessed : ce qu'il prouve.
La persistance côté applications
Les attaquants disposant de droits d'administration vont plus loin que le consentement :
Add service principal credentials/Update application – Certificates and secrets management: un secret ou un certificat ajouté à une application existante, qui permet à l'attaquant de s'authentifier en tant qu'application (T1098.001).Add application: une nouvelle inscription d'application dans le tenant.Add member to roleavec une application comme membre : un rôle privilégié pour l'application.
Tout cela survit aux réinitialisations de mot de passe et mérite le même examen.
Comment M365 Forensics le signale
L'analyseur dans le navigateur comporte quatre constats liés :
| Constat | Gravité | Déclencheur |
|---|---|---|
| Consentement accordé à une application avec accès aux messages ou fichiers | Élevée | Consentement, autorisation déléguée ou attribution de rôle d'application dont les propriétés contiennent une autorisation de sa liste à risque (Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, offline_access, full_access_as_user…) |
| Consentement accordé à une application | Faible | Tout autre consentement : vérifier qu'il est attendu |
| Identifiants ajoutés à une application | Élevée | Secret ou certificat ajouté à une application ou à un principal de service |
| Nouvelle application ou nouveau principal de service | Faible | Application inscrite ou principal de service ajouté |
Si le consentement vient de l'IP ou de la session d'une connexion suspecte, le constat de corrélation ajoute une « action effectuée depuis la session de l'attaquant », critique. La liste de remédiation propose alors Retirer l'application autorisée et Restreindre le consentement des utilisateurs.
Remédiation
- Révoquer l'autorisation : dans Entra, l'utilisateur → Applications → l'application → Remove ; ou
Remove-MgOauth2PermissionGrantpour les autorisations déléguées etRemove-MgServicePrincipalAppRoleAssignmentpour les attributions de rôle d'application (tous deux cités dans le guide de Microsoft). - Supprimer ou désactiver le principal de service si l'application n'est pas légitime, pour que personne d'autre ne puisse l'utiliser.
- Révoquer aussi les sessions de l'utilisateur : l'attaquant qui a consenti disposait probablement d'une session.
- Restreindre le consentement des utilisateurs : ne les autoriser à consentir qu'aux éditeurs vérifiés et aux autorisations à faible risque, et activer le flux de consentement administrateur (configurer le consentement des utilisateurs).
- Passer en revue identifiants, propriétaires et rôles d'applications ajoutés sur la même période.
Questions fréquentes
Qu'est-ce qu'un octroi de consentement illicite ?
Une attaque où un utilisateur, ou un administrateur, est amené à accorder à une application contrôlée par l'attaquant l'accès à ses données, par exemple la lecture et l'envoi de courrier. L'application accède ensuite aux données avec ses propres jetons, sans le mot de passe de l'utilisateur.
Quels événements d'audit montrent un consentement ?
Consent to application dans le journal d'audit unifié et l'audit Entra, généralement accompagné de Add delegated permission grant ou Add app role assignment to service principal, et souvent de Add service principal quand l'application est nouvelle dans le tenant.
Une réinitialisation du mot de passe retire-t-elle l'accès de l'application ?
Non. Le consentement et les jetons d'actualisation de l'application sont indépendants du mot de passe de l'utilisateur. Supprimez l'autorisation accordée, et supprimez le principal de service si l'application n'est pas légitime.
Pour aller plus loin
- Microsoft Learn : Détecter et corriger les octrois de consentement illicites
- Guide d'enquête BEC Microsoft 365
- Les applications OAuth sont aussi un chemin de persistance sur GitHub : githubforensics.com.