Audit OAuth Microsoft 365 : détecter les apps malveillantes

Le phishing par consentement OAuth est l’angle mort des défenses Microsoft 365 classiques. Le MFA ne le bloque pas. Les passerelles email ne le voient pas. L’attaquant n’a même pas besoin du mot de passe de la victime. Il lui fait simplement cliquer « Accepter » sur une vraie page Microsoft, hébergée sur le vrai domaine login.microsoftonline.com, avec le vrai logo et la vraie infrastructure d’authentification de Microsoft.

C’est cette technique qui a permis au groupe Midnight Blizzard (NOBELIUM, lié au renseignement russe) de compromettre le tenant corporate de Microsoft en janvier 2024. Microsoft a publié le détail de l’incident sur microsoft.com/security/blog : les attaquants ont pris pied via un compte test legacy, créé de nouvelles applications OAuth malveillantes, puis obtenu le rôle full_access_as_app sur Exchange Online — ce qui leur a donné un accès en lecture aux boîtes mail des cadres de Microsoft.

Cette même technique est exploitée par Storm-0324, par les kits commerciaux de Phishing-as-a-Service apparus en 2024-2025, et par une vague de « device code phishing » qui a explosé fin 2025. Help Net Security et Infosecurity Magazine ont documenté en décembre 2025 deux acteurs distincts : TA2723 (motivation financière) usurpant des notifications RH liées aux salaires, et UNK_AcademicFlare (soupçonné de liens avec un service de renseignement russe) ciblant des gouvernements, organismes de transport et institutions éducatives en Europe et aux États-Unis.

Le point commun de tous ces incidents : l’attaquant n’a jamais eu à voler un mot de passe. La victime s’est connectée elle-même à Microsoft 365, légitimement, avec son vrai MFA. Et c’est précisément à ce moment-là que l’attaque a réussi.

Cet article couvre trois choses : comprendre techniquement comment fonctionne le phishing par consentement OAuth, auditer votre tenant pour identifier les applications déjà installées qui posent problème, et durcir vos politiques de consentement pour empêcher la prochaine compromission. Pour les bases : notre glossaire du phishing. Pour la vision macro de Microsoft 365 : notre guide pour sécuriser Microsoft 365.

Comment fonctionne le phishing par consentement OAuth

La mécanique est différente de tous les autres phishings que les équipes sécurité ont appris à repérer. Il n’y a pas de page de login frauduleuse. Pas d’usurpation de domaine. Pas de credential stuffing. L’attaque exploite un mécanisme normal de Microsoft 365, conçu pour permettre aux applications tierces d’accéder aux données utilisateur avec son accord.

Les six étapes d’une attaque OAuth

Étape 1 — L’attaquant prépare son application. Dans son propre tenant Microsoft Entra, l’attaquant crée une application OAuth. Il lui donne un nom anodin ou trompeur (« Microsoft Security Update », « Document Viewer », « SharePoint Migration Tool »). Variante : l’attaquant compromet une application légitime existante d’une PME tierce, ce qui rend l’origine encore plus crédible.

Étape 2 — L’attaquant configure les permissions demandées. L’application demande des scopes OAuth : Mail.Read (lire les emails), Files.Read.All (lire OneDrive et SharePoint), User.Read (lire le profil utilisateur), offline_access (obtenir un refresh token pour persister l’accès). Les attaquants techniquement compétents demandent souvent Mail.ReadWrite pour pouvoir effacer leurs traces, et User.ReadBasic.All pour énumérer ensuite l’annuaire interne.

Étape 3 — L’attaquant génère une URL de consentement. L’URL ressemble à https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id={appId}&scope={permissions}&redirect_uri={attacker_url}&response_type=code. Cette URL est techniquement valide. Elle pointe vers le vrai domaine Microsoft. Aucun produit de filtrage ne peut la classer comme malveillante à priori — c’est une URL Microsoft légitime.

Étape 4 — L’attaquant envoie l’URL à la cible. Le vecteur peut être un email, un message Teams (le lateral phishing via comptes compromis fonctionne particulièrement bien — voir notre article sur le phishing via Teams et SharePoint), un message LinkedIn, un SMS, ou un QR code imprimé. Le prétexte est variable : « Validez votre accès à la nouvelle plateforme RH », « Confirmez vos informations pour le portail fournisseur », « Activez votre licence Power BI ».

Étape 5 — La victime authentifie sur Microsoft. L’utilisateur clique sur le lien. Son navigateur l’amène sur la vraie page de login Microsoft. Il entre ses identifiants — légitimes. Le MFA se déclenche — la victime valide normalement. Microsoft authentifie la session avec succès. Aucune anomalie n’est détectable à ce stade par les outils de sécurité : l’authentification est conforme, depuis le bon utilisateur, avec le bon MFA.

Étape 6 — La victime accorde le consentement. Après authentification, Microsoft affiche l’écran de consentement OAuth. Cet écran liste le nom de l’application (celui choisi par l’attaquant), son éditeur (souvent « Unverified » mais beaucoup d’utilisateurs n’y prêtent pas attention), et les permissions demandées. L’utilisateur clique sur « Accepter ». Microsoft délivre alors un authorization code à l’application, qui l’échange contre un access token et un refresh token.

À partir de cet instant, l’attaquant peut lire la boîte mail, télécharger OneDrive, lister les fichiers SharePoint, envoyer des messages au nom de l’utilisateur. Le refresh token lui permet de renouveler son access token indéfiniment, sans nouvelle interaction de la victime. Tout cela sans jamais avoir connu le mot de passe.

Pourquoi cette technique est référencée

Microsoft documente précisément ce vecteur sur learn.microsoft.com sous le terme « illicit consent grant ». MITRE ATT&CK le classe en technique T1528 : « Steal Application Access Tokens ». Ce n’est pas une attaque expérimentale. C’est une procédure documentée, automatisée par des kits commerciaux, et utilisée à grande échelle.

Cas réels documentés

Midnight Blizzard contre Microsoft (janvier 2024)

L’incident le plus emblématique reste la compromission du tenant corporate de Microsoft. Le scénario tel que Microsoft l’a publié :

• Vecteur initial : un compte test legacy non protégé par MFA. Le compte a été pris par password spraying.
• Élévation : sur ce compte, une application OAuth héritée disposait du rôle Office 365 Exchange Online avec la permission full_access_as_app. Cette permission permet d’accéder à toutes les boîtes mail du tenant en application permission, sans contexte utilisateur.
• Persistance : à partir de l’application compromise, l’attaquant a créé d’autres applications OAuth malveillantes, leur a accordé des consentements administrateurs via la compromission existante, et a obtenu un accès durable.
• Impact : exfiltration d’emails de cadres dirigeants et d’équipes cybersécurité de Microsoft, entre novembre 2023 et janvier 2024.

Le détail technique est dans la publication officielle Microsoft : Midnight Blizzard: Guidance for responders on nation-state attack. Microsoft y précise notamment que l’application OAuth héritée n’était plus utilisée mais n’avait jamais été supprimée — un cas classique de hygiène insuffisante sur le cycle de vie des applications.

Campagnes OAuth phishing 2023-2025

Au-delà de Midnight Blizzard, le vecteur a été exploité industriellement par des groupes criminels. Storm-0324, signalé par Microsoft en septembre 2023, distribuait des charges malveillantes via Teams en couplant lateral phishing et consentement OAuth. BleepingComputer a documenté plusieurs vagues entre 2023 et 2025, avec des kits qui automatisent l’enregistrement de l’application, la génération du lien et la collecte des tokens.

Device code phishing — fin 2025

Le device code authorization flow est un mécanisme OAuth conçu pour les appareils sans navigateur (TVs connectées, IoT, lignes de commande). L’application affiche un code à 8 caractères ; l’utilisateur se rend sur microsoft.com/devicelogin, saisit ce code, s’authentifie et autorise l’application.

L’attaquant détourne ce flow : il lance lui-même la requête device code, récupère le code, puis envoie le code à la victime en lui demandant de le saisir sur microsoft.com/devicelogin. Quand la victime authentifie le code, c’est le client de l’attaquant qui reçoit les tokens.

Help Net Security et Infosecurity Magazine ont publié fin 2025 sur deux campagnes parallèles :

• TA2723 (Proofpoint, octobre-décembre 2025) — usurpations d’emails RH liées aux salaires : « Votre fiche de paie est disponible, scannez ce QR code pour y accéder. » Le QR code mène à un site de phishing qui demande à la cible d’entrer le code device. Acteur à motivation financière, cibles principalement aux États-Unis.
• UNK_AcademicFlare (Proofpoint) — soupçonné de liens avec un service de renseignement russe. Cible des gouvernements, opérateurs de transport et institutions éducatives en Europe et aux États-Unis. Modus operandi similaire mais avec un degré de sophistication supérieur dans les lures.

Ces deux groupes exploitent le fait que le device code flow ne déclenche pas les mêmes signaux d’alerte qu’une connexion classique : la victime est au bon endroit (microsoft.com/devicelogin), entre un code, valide son MFA — tout est conforme, sauf que le client qui reçoit les tokens n’est pas celui de la victime.

Pourquoi MFA et défenses email ne bloquent rien

C’est le point central et celui qui résiste le plus à l’intuition des responsables sécurité.

Le MFA ne bloque pas, parce qu’il n’a rien à bloquer. L’authentification de la victime est légitime : elle utilise ses vrais identifiants, son vrai facteur secondaire, sur la vraie infrastructure Microsoft. Le MFA s’exécute comme conçu. La compromission survient AVEC succès au moment du consentement, qui est un événement post-authentification.

Les passerelles email (SEG) ne bloquent pas non plus. Le lure email contient un lien vers login.microsoftonline.com. C’est un domaine Microsoft légitime. Aucun produit de filtrage email raisonnable ne classera ce domaine comme malveillant — il faudrait bloquer Microsoft 365 lui-même. La payload n’est pas une pièce jointe : c’est un paramètre dans l’URL (client_id de l’application malveillante), invisible pour la quasi-totalité des analyses d’email.

Safe Links ne bloque pas. Le mécanisme de réécriture de Microsoft Defender for Office 365 vérifie au clic si l’URL est connue comme malveillante. login.microsoftonline.com n’est pas malveillant. L’application OAuth derrière le client_id peut être créée le matin et utilisée l’après-midi : elle n’a aucune réputation négative dans les bases de menaces.

Le Conditional Access peut filtrer la session, mais pas systématiquement. Une politique d’accès conditionnel qui exige un appareil conforme bloquera l’attaque si l’authentification se fait depuis un appareil non géré. Mais l’attaque peut aussi se dérouler depuis l’appareil légitime de la victime — c’est même le cas standard. Le Conditional Access voit alors une authentification depuis un appareil conforme, depuis un utilisateur légitime, depuis une IP attendue : aucun motif de blocage.

La seule défense efficace est en amont du consentement lui-même : empêcher l’utilisateur de consentir à n’importe quelle application, par configuration du tenant. Le reste est secondaire.

Étape 1 — Auditer les applications OAuth existantes

Avant de durcir les politiques de prévention, il faut savoir ce qui est déjà installé dans votre tenant. La plupart des tenants Microsoft 365 contiennent des dizaines d’applications consenties au fil des années : intégrations SaaS, extensions de productivité, anciens outils abandonnés, et parfois des applications dont personne ne se souvient.

Méthode via l’interface

Pour une vue rapide :

1. Microsoft Entra admin center → Applications → Enterprise applications → All applications
2. Filtre : Application type = Enterprise applications, Application visibility = Any
3. Pour chaque application : ouvrir → Permissions (voir les scopes accordés), Users and groups (voir qui a consenti), Sign-in logs (voir l’activité récente)

L’interface est utilisable pour un audit ponctuel sur quelques applications suspectes. Elle devient impraticable au-delà de 50 applications, ce qui est la situation normale d’un tenant PME.

Méthode via PowerShell — la seule sérieuse

Le Microsoft Graph PowerShell SDK permet d’exporter la liste complète des applications, avec leurs permissions et leurs dates de création, en quelques commandes.

# Installation (une seule fois)
Install-Module Microsoft.Graph -Scope CurrentUser

# Connexion avec les scopes nécessaires
Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All","AuditLog.Read.All"

# Liste de toutes les applications avec ID et tags
Get-MgServicePrincipal -All |
    Select DisplayName, AppId, Id, PublisherName, SignInAudience, Tags, AccountEnabled |
    Export-Csv -Path service_principals.csv -NoTypeInformation -Encoding UTF8

Pour chaque application, on veut ensuite les permissions OAuth accordées :

# Permissions déléguées (au nom des utilisateurs)
$delegated = Get-MgOauth2PermissionGrant -All
$delegated | Select ClientId, ConsentType, PrincipalId, ResourceId, Scope |
    Export-Csv -Path delegated_permissions.csv -NoTypeInformation

# Permissions d'application (au nom de l'application elle-même)
$apps = Get-MgServicePrincipal -All
foreach ($app in $apps) {
    $appPerms = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $app.Id
    # Traitement : associer AppRoleId à son nom via Get-MgServicePrincipal du ResourceId
}

Pour identifier les applications consenties récemment (par exemple les 90 derniers jours), interroger le journal d’audit :

$startDate = (Get-Date).AddDays(-90).ToString("yyyy-MM-ddT00:00:00Z")
Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Consent to application' and activityDateTime ge $startDate" |
    Select ActivityDateTime, InitiatedBy, TargetResources |
    Export-Csv -Path recent_consents.csv -NoTypeInformation

Microsoft documente la procédure complète sur learn.microsoft.com (« Detect and Remediate Illicit Consent Grants »).

Étape 2 — Identifier les signaux d’une application suspecte

Le résultat de l’audit est en général une liste de 80 à 300 applications. Le travail consiste à isoler les 1 à 5 % d’applications qui méritent attention.

Signaux à fort poids

Permissions excessives par rapport à la fonction affichée. Une application qui prétend gérer un calendrier n’a aucune raison de demander Mail.ReadWrite.All. Une application de signature électronique n’a pas besoin de Files.ReadWrite.All sur toute l’organisation. La règle générale : la portée .All (toute l’organisation) est rare et toujours à justifier.

Application permissions sans cas d’usage clair. Les application permissions s’exécutent sans contexte utilisateur, donc avec un accès global. Une intégration ETL qui synchronise des données entre Microsoft 365 et un outil métier peut en avoir besoin légitimement. Une application sans publisher connu qui dispose d’Application.ReadWrite.All ou de Directory.ReadWrite.All mérite enquête immédiate — ces permissions permettent à l’application de créer d’autres applications, donc de pivoter à l’intérieur du tenant.

Aucun Verified Publisher + création récente. Les Verified Publishers sont des éditeurs ayant fait valider leur identité par Microsoft via un processus payant et documenté. Une application sans Verified Publisher n’est pas malveillante en soi (beaucoup de petits éditeurs ne sont pas vérifiés), mais combinée à une création récente et des permissions sensibles, le signal devient fort.

Reply URLs sur des domaines non liés à l’application. Le redirect_uri d’une application légitime pointe vers le domaine de l’éditeur. Si l’application « Microsoft Security Update » a un redirect_uri vers un domaine *.ngrok.io, *.azurewebsites.net créé la veille, ou pire un domaine sans rapport sémantique avec le nom de l’application, c’est un signal très net.

Une seule personne ayant consenti. Les applications légitimes utilisées dans une organisation sont consenties par plusieurs utilisateurs ou par un admin pour tout le tenant. Une application avec une seule entrée dans Users and groups est soit un outil personnel d’un utilisateur, soit une attaque réussie.

Sign-in logs aberrants. Une application qui se connecte depuis des IPs anonymisantes (Tor, VPN commerciaux), à des horaires inhabituels, depuis des géolocalisations différentes de celles de l’utilisateur, est suspecte par construction.

Outils de scoring : Defender for Cloud Apps

Pour les tenants disposant d’une licence E5 ou de Microsoft Defender for Cloud Apps (anciennement Microsoft Cloud App Security — MCAS) en add-on, le module App governance fournit un scoring de risque automatique sur chaque application OAuth. Le score combine :

• Risque des permissions demandées (matrice Microsoft)
• Comportement de l’application (volume de data access, anomalies)
• Lineage (qui a publié l’application, depuis quel tenant)
• Conformité réglementaire de l’éditeur

L’interface : Microsoft Defender → Cloud apps → App governance → Apps. La liste est triable par score de risque. Pour les tenants sans Defender for Cloud Apps, le travail se fait manuellement à partir des exports PowerShell.

Étape 3 — Révoquer une application malveillante

Une fois une application identifiée comme malveillante (ou simplement non autorisée), la révocation se fait en deux temps : supprimer l’application elle-même, puis invalider les tokens déjà délivrés.

Suppression de l’application

Via PowerShell :

# Identifier l'ID du service principal
$app = Get-MgServicePrincipal -Filter "displayName eq 'NomApplicationMalveillante'"

# Suppression
Remove-MgServicePrincipal -ServicePrincipalId $app.Id

Via l’interface : Enterprise applications → sélectionner l’application → Properties → Delete.

La suppression empêche l’application d’obtenir de nouveaux tokens. Les tokens déjà délivrés restent valides jusqu’à leur expiration.

Révocation des tokens existants

C’est l’étape souvent oubliée. Un access token Microsoft Graph a une durée de vie par défaut de 60 à 90 minutes. Sans intervention, l’attaquant peut continuer à exfiltrer pendant cette fenêtre. Le refresh token, lui, peut durer jusqu’à 90 jours s’il n’est pas explicitement révoqué.

Pour chaque utilisateur ayant consenti à l’application, exécuter :

Revoke-MgUserSignInSession -UserId "utilisateur@votredomaine.fr"

Cette commande invalide tous les refresh tokens de l’utilisateur et force une réauthentification. Les access tokens en cours deviennent inutilisables pour obtenir de nouveaux jetons. C’est une mesure préventive large : l’utilisateur devra se reconnecter sur tous ses appareils et toutes ses applications, ce qui est un compromis acceptable face à une compromission.

Pour révoquer en masse sur plusieurs utilisateurs :

$utilisateurs = @("user1@domaine.fr", "user2@domaine.fr", "user3@domaine.fr")
foreach ($u in $utilisateurs) {
    Revoke-MgUserSignInSession -UserId $u
    Write-Host "Sessions révoquées pour $u"
}

Étape 4 — Durcir les politiques de consentement

La détection et la révocation traitent les incidents passés. La prévention repose sur les politiques de consentement utilisateur du tenant.

Les trois niveaux de user consent

Microsoft Entra propose trois options dans Enterprise applications → Consent and permissions → User consent settings :

Option 1 — Allow user consent for apps. N’importe quel utilisateur peut consentir à n’importe quelle application pour ses propres données. C’est l’option par défaut sur les anciens tenants. Catastrophique pour la majorité des organisations.

Option 2 — Allow user consent for apps from verified publishers, for selected permissions. Les utilisateurs peuvent consentir uniquement aux applications de Verified Publishers, et uniquement pour des permissions classées « low impact » par Microsoft (profil utilisateur, lecture du calendrier, etc.). Toute application non vérifiée, ou toute permission sensible, exige un admin consent.

Option 3 — Do not allow user consent. Aucun utilisateur ne peut consentir à aucune application. Toute installation OAuth passe par un administrateur.

La recommandation pour une PME

L’option 2 est le bon compromis pour la majorité des organisations : elle bloque les attaques OAuth phishing tout en n’imposant pas une charge administrative excessive. Les permissions classées « low impact » sont suffisantes pour la plupart des intégrations légitimes de productivité.

Pour configurer :

1. Microsoft Entra admin center → Enterprise applications → Consent and permissions → User consent settings
2. Sélectionner « Allow user consent for apps from verified publishers, for selected permissions »
3. Dans Permission classifications, vérifier que les permissions à faible risque sont classifiées (par défaut : User.Read, offline_access, openid, profile)

L’Admin consent workflow

L’option 2 ou 3 implique que certaines applications légitimes ne pourront plus être consenties directement par les utilisateurs. Pour ne pas bloquer leur travail, configurer l’Admin consent workflow :

1. Enterprise applications → User settings → Admin consent requests → Yes
2. Désigner les utilisateurs ou groupes qui recevront les demandes (équipe IT, RSSI)
3. Configurer les notifications email
4. Optionnel : configurer une expiration automatique (15-30 jours)

Quand un utilisateur tente de consentir à une application qui exige un admin consent, il voit un bouton « Demander l’approbation ». La demande est envoyée aux approbateurs désignés. C’est un cycle qui ralentit légèrement les déploiements légitimes — mais qui ferme proprement le vecteur OAuth phishing.

Étape 5 — La Risk-based step-up consent

Microsoft active depuis 2020 une protection minimum nommée Risk-based step-up consent. Quand une demande de consentement est classifiée à risque (combinaison de signaux : application non vérifiée, permissions sensibles, comportement de l’application), le user consent est automatiquement bloqué et un admin consent est exigé, même si la politique du tenant autorise le user consent.

Cette protection est activée par défaut. Vérification :

1. Microsoft Entra admin center → Enterprise applications → Consent and permissions → User consent settings
2. Vérifier que « Block user consent for risky apps » est activé

Pour le détail technique du mécanisme de scoring, voir l’annonce originale sur techcommunity.microsoft.com (« Risk-based step-up consent », publié en 2020).

C’est une protection utile mais qui ne remplace pas les options 2 ou 3 décrites précédemment : le scoring de Microsoft a des angles morts, en particulier sur les applications fraîchement créées dont le comportement n’est pas encore caractérisé.

Étape 6 — Surveiller en continu

Les politiques de consentement préviennent les nouveaux consentements à risque. La surveillance détecte les anomalies sur l’existant.

Journaux Entra ID

Les événements à surveiller dans Microsoft Entra admin center → Monitoring → Audit logs :

• Consent to application — un utilisateur ou admin a consenti à une application
• Add app role assignment to service principal — une permission d’application a été ajoutée
• Add OAuth2PermissionGrant — une permission déléguée a été ajoutée
• Add service principal — une nouvelle application a été ajoutée au tenant

Pour exporter périodiquement :

Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Consent to application'" -Top 100 |
    Select ActivityDateTime, InitiatedBy, Result, TargetResources

Defender XDR Advanced Hunting (KQL)

Pour les tenants avec Microsoft Defender XDR, une requête KQL surveille les ajouts d’applications OAuth en quasi temps réel :

CloudAppEvents
| where Timestamp > ago(7d)
| where ActionType in ("Add OAuth application", "Consent to application")
| extend AppName = tostring(RawEventData.ModifiedProperties[0].NewValue)
| extend Permissions = tostring(RawEventData.ModifiedProperties[1].NewValue)
| project Timestamp, AccountObjectId, AccountDisplayName, ActionType, AppName, Permissions, IPAddress
| order by Timestamp desc

Pour détecter les patterns suspects (consentements multiples par un même utilisateur dans un laps court — signature de phishing) :

CloudAppEvents
| where Timestamp > ago(24h)
| where ActionType == "Consent to application"
| summarize ConsentCount = count(), Apps = make_set(ApplicationId) by AccountObjectId, bin(Timestamp, 1h)
| where ConsentCount >= 3

Sentinel et règles de détection

Pour les organisations sous Microsoft Sentinel, des règles de détection OAuth phishing prêtes à l’emploi sont disponibles dans le content hub Sentinel. Les requêtes typiques surveillent : nouvelles applications avec permissions à haut risque, consentements depuis IPs inhabituelles, augmentation soudaine du volume de consentements.

Alertes Defender for Office 365

Dans le portail Defender → Settings → Email & Collaboration → Alert policies, activer les alertes :

• App consent created — toute application consentie dans le tenant
• Suspicious OAuth app — application OAuth marquée suspecte par les analyses Microsoft
• App with high risk permissions — application disposant de permissions classées sensibles

Envoyer ces alertes à une adresse email hors Microsoft 365. Si votre tenant est compromis, les alertes envoyées en interne peuvent être supprimées par l’attaquant via les règles Inbox.

Étape 7 — Bloquer le device code flow

Le device code authorization flow est le vecteur principal des attaques fin 2025 (TA2723, UNK_AcademicFlare). Si votre organisation n’a pas de cas d’usage légitime du device code flow (devices sans navigateur, scripts d’automatisation spécifiques), le bloquer en Conditional Access ferme proprement ce vecteur.

Configuration :

1. Microsoft Entra admin center → Protection → Conditional Access → New policy
2. Nommer : « Block Device Code Flow »
3. Users : All users (exclure les comptes break-glass)
4. Cloud apps : All cloud apps
5. Conditions → Authentication flows → activer Configure
6. Cocher Device code flow → Block
7. Grant : Block access
8. Activer d’abord en mode Report-only pendant 7 jours pour identifier d’éventuels usages légitimes
9. Passer en On après vérification

Les usages légitimes du device code flow sont rares dans les organisations standard : ils concernent essentiellement les déploiements PowerShell sur serveurs headless, certaines intégrations IoT spécifiques. Pour ces cas, exclure les utilisateurs concernés via un groupe spécifique.

Help Net Security a publié en décembre 2025 un guide complet sur le blocage du device code flow, avec les variations selon les configurations de Conditional Access. La référence reste l’article original sur les campagnes TA2723 et UNK_AcademicFlare.

Réponse à incident : un utilisateur a consenti à une application malveillante

Quand la détection arrive après le consentement (cas le plus fréquent), la réponse doit être rapide et systématique.

1. Révocation immédiate de l’application et des tokens.

$app = Get-MgServicePrincipal -Filter "displayName eq 'AppMalveillante'"
Remove-MgServicePrincipal -ServicePrincipalId $app.Id
Revoke-MgUserSignInSession -UserId "utilisateurconcerne@votredomaine.fr"

2. Reset du mot de passe + force sign-out global. Même si le mot de passe n’a pas été compromis (l’attaque OAuth ne le requiert pas), un reset force la révocation de tous les tokens. La force sign-out invalide les sessions actives.

3. Audit de la boîte mail. L’attaquant crée souvent des règles Outlook pour :

• Transférer automatiquement les emails entrants vers une adresse externe
• Supprimer ou déplacer en silence les alertes de sécurité Microsoft
• Marquer comme lus les emails d’un dossier précis

Get-InboxRule -Mailbox "utilisateurconcerne@votredomaine.fr" |
    Select Name, ForwardTo, ForwardAsAttachmentTo, RedirectTo, DeleteMessage, MoveToFolder

Toute règle de transfert vers un domaine externe doit être supprimée. Vérifier également Exchange Admin Center → Rules → Mail flow rules pour les règles au niveau organisation.

4. Vérification des méthodes MFA. Un attaquant ayant obtenu un accès à un compte Microsoft 365 ajoute parfois sa propre méthode MFA (numéro de téléphone, application Authenticator) pour préserver l’accès même après changement de mot de passe. Vérifier dans Microsoft Entra → Users → utilisateur concerné → Authentication methods.

5. Audit des accès aux fichiers. Identifier les téléchargements SharePoint et OneDrive dans la fenêtre de compromission (entre le consentement et la révocation) :

CloudAppEvents
| where Timestamp between(datetime(YYYY-MM-DD) .. datetime(YYYY-MM-DD))
| where AccountObjectId == "userId"
| where ActionType in ("FileDownloaded", "FileAccessed", "FileSyncDownloaded")
| project Timestamp, ActionType, ObjectName, IPAddress, UserAgent
| order by Timestamp desc

Si une exfiltration de données personnelles est confirmée, la notification à la CNIL doit être faite sous 72 heures conformément à l’article 33 du RGPD — voir notre page conformité RGPD. Pour les organisations soumises à NIS2, la notification ANSSI/CSIRT s’ajoute (voir notre page conformité NIS2).

La couche humaine reste décisive

Tous les contrôles techniques décrits précédemment aident considérablement. Aucun ne suffit si l’utilisateur clique aveuglément « Accepter » sur n’importe quelle demande OAuth.

Or, l’écran de consentement est familier. L’utilisateur a appris à cliquer « Accepter » pour installer Teams. Pour utiliser Power BI. Pour autoriser son outil de visioconférence à accéder à son calendrier. Pour activer un plugin Excel. Ce geste est devenu un réflexe, exactement comme cliquer « Suivant » lors d’une installation logicielle.

Distinguer à l’œil nu une vraie demande de consentement d’une fausse demande est extrêmement difficile. Les indices existent — Verified Publisher, scopes excessifs, redirect URI suspect — mais ils exigent une lecture analytique que la quasi-totalité des utilisateurs n’effectue jamais. Le traitement par défaut est en Système 1, automatique : « écran familier, bouton bleu Accepter ».

La formation des utilisateurs sur ce vecteur précis est largement absente des programmes de sensibilisation classiques. Les modules standards couvrent l’email de phishing, parfois les fausses pages de login, rarement les demandes OAuth. C’est un angle mort des programmes de sensibilisation eux-mêmes, qui n’ont pas évolué au même rythme que les attaques.

Notre plateforme nophi.sh intègre un scénario spécifique de demande de consentement OAuth dans ses simulations de phishing : le collaborateur reçoit une demande qui imite parfaitement une vraie demande Microsoft, observe son comportement, et s’il clique « Accepter », il reçoit immédiatement un micro-learning ciblé sur les indices à vérifier. C’est la seule manière d’inscrire ce réflexe dans la mémoire procédurale des utilisateurs.

Pour aller plus loin sur les bases : notre glossaire du social engineering et notre guide pour se protéger des attaques AiTM Microsoft 365. Pour la simulation interne via Microsoft : notre guide de Microsoft Defender Attack Simulator. Pour anticiper les évolutions : notre article sur les attaques d’IA contre les entreprises en 2026.

Ce qu’il faut retenir

Le phishing par consentement OAuth est aujourd’hui la technique d’attaque la plus difficile à bloquer dans Microsoft 365, parce qu’elle exploite un mécanisme normal du produit et qu’elle contourne l’intégralité des défenses email et MFA classiques. Trois priorités d’action pour une PME :

1. Auditer le tenant existant — exporter via PowerShell la liste de toutes les applications OAuth, identifier celles aux permissions disproportionnées ou créées par un seul utilisateur, révoquer ce qui n’est pas justifié.

2. Configurer le user consent en mode restrictif — soit Verified Publishers + low-risk permissions, soit blocage complet avec admin consent workflow. C’est le contrôle préventif qui ferme le vecteur principal.

3. Bloquer le device code flow via Conditional Access si aucun cas d’usage légitime n’existe — c’est le contrôle qui ferme les campagnes TA2723 et UNK_AcademicFlare de fin 2025.

Et en parallèle, former les équipes au scénario spécifique de demande de consentement OAuth — un vecteur que la quasi-totalité des programmes de sensibilisation ignore encore.

Découvrez la simulation de phishing OAuth de nophi.sh → — ou consultez nos tarifs pour démarrer un programme de sensibilisation incluant ce vecteur.