Consentement OAuth suspect : enquêter sur les droits de l'application
Reliez consentement, principal applicatif, permissions et usages observés pour qualifier un accès OAuth suspect et vérifier une réponse ciblée.
Périmètre des intégrations : Seculogik utilise une architecture indépendante des sources pour ingérer les alertes et événements de sécurité via son propre modèle de données. Wazuh et OpenSearch sont les premières intégrations. Les autres sources citées correspondent à des connecteurs prévus ; leur disponibilité doit être confirmée pour chaque évaluation.
Une personne signale avoir accepté une demande d'accès inhabituelle. L'application porte un nom rassurant et la connexion humaine ne présente pas d'anomalie évidente. Le SOC doit pourtant examiner une autre question : quels droits cette application a-t-elle obtenus, et quelles opérations peut-on réellement lui rattacher ?
Le guide Microsoft sur les consentements illicites explique pourquoi une réponse limitée au changement de mot de passe ou à la MFA ne traite pas ce mécanisme d'accès applicatif. Ce constat ne prouve pas qu'un consentement donné est malveillant ; il indique où poursuivre l'investigation. Source : Microsoft, détecter et traiter les consentements illicites
Les exemples ci-dessous concernent Microsoft Entra. La méthode reste indépendante de l'outil de collecte et ne suppose aucune intégration Seculogik disponible. Vérifiez les possibilités de consultation et de réponse dans votre environnement, avec les personnes habilitées.
1. Séparer demande, droit accordé et usage
Notre recommandation : ouvrir le dossier avec trois observations distinctes. Que demandait l'application ? Quel droit a effectivement été accordé ? Quelle activité est retrouvée sur la ressource ? Une capture de l'écran de consentement ne remplace ni l'inventaire des permissions, ni les traces d'une opération.
Conservez le signalement initial, l'annuaire concerné, la période, les ressources visées et les références des éléments collectés. Un nom familier ne suffit pas à identifier l'application. Une autorisation excessive peut justifier une mesure de protection même si son utilisation reste inconnue ; cette décision doit garder sa justification et ses limites.
Demandez aussi qui peut vérifier le besoin métier. L'utilisateur sait éventuellement expliquer son intention, mais ne dispose pas nécessairement de la visibilité technique sur tous les droits. Faites confirmer l'usage attendu par le propriétaire du service, sans dépendre uniquement du compte potentiellement compromis.
2. Identifier l'application et son principal local
Microsoft distingue l'objet application de sa représentation locale, le principal de service, dans un annuaire. L'identifiant applicatif global et l'identifiant d'objet du principal local ne décrivent donc pas le même objet. Source : Microsoft, objets application et principaux de service
Notre recommandation : conserver ensemble l'annuaire, l'appId, l'objectId du principal de service, la ressource cible et l'acteur observé. Ajoutez les noms affichés pour la lisibilité, sans les utiliser comme clé unique de rapprochement. Notez la provenance de chaque identifiant et vérifiez que deux exports parlent bien du même objet.
Faites expliquer toute divergence entre application déclarée, principal présent et ressource autorisée. Une recherche fondée uniquement sur le nom peut rapprocher des objets différents ou manquer un changement de nom. Si un objet n'est plus disponible, conservez ses références dans les traces historiques et marquez ce qui ne peut plus être vérifié dans l'état courant.
3. Classer précisément les permissions
Une permission déléguée permet d'agir au nom d'un utilisateur connecté. Graph la représente par un oAuth2PermissionGrant : clientId désigne l'identifiant d'objet du principal client, pas son appId ; resourceId, le principal de la ressource. Le consentType distingue notamment le périmètre individuel de celui de tous les utilisateurs. Source : Microsoft Graph, oAuth2PermissionGrant
Notre recommandation : relever la ressource, les permissions effectivement accordées, le type de consentement et l'utilisateur concerné lorsqu'il s'applique. Gardez séparés le demandeur observé et le bénéficiaire du droit. Ne déduisez pas le périmètre du seul libellé « consentement administrateur ».
Un appRoleAssignment peut concerner un utilisateur, un groupe ou un principal de service. Lorsqu'un rôle applicatif est attribué au principal de service client, il représente une permission applicative. Toute affectation de rôle ne doit donc pas être classée automatiquement comme un accès applicatif autonome. Source : Microsoft Graph, appRoleAssignment
Notre recommandation : qualifier le type du bénéficiaire, la ressource et le rôle précis. Faites rapprocher cette affectation du besoin approuvé. Conservez les identifiants des objets d'autorisation pour permettre une décision ciblée, plutôt qu'une suppression globale fondée sur une liste de noms.
4. Construire deux chronologies et conserver les inconnues
Les logs d'audit Entra décrivent notamment les changements touchant les applications. Microsoft documente l'acteur, la cible, le statut et, selon l'activité, les anciennes et nouvelles valeurs. Source : Microsoft, logs d'audit Entra
Notre recommandation : construire d'abord la chronologie des autorisations : création ou modification du principal, consentement, changement de permission et retrait éventuel. Conservez l'heure avec son fuseau, les identifiants, le résultat rapporté et la source. Distinguez l'état actuellement visible de l'état démontré pendant la période étudiée.
Construisez ensuite la chronologie des usages : authentifications applicatives disponibles, accès à la ressource et opérations effectivement journalisées. Un événement de consentement n'établit pas une lecture de documents. Une authentification réussie ne prouve pas à elle seule un export. Pour chaque conclusion, indiquez la trace qui la soutient et la force du rattachement à l'application.
Demandez la période réellement couverte, les catégories activées, les exclusions et les limites de conservation ou d'export. Une recherche vide doit rester « aucun usage retrouvé dans les sources examinées » si ces limites empêchent une conclusion plus forte. N'inventez pas une chronologie pour combler un historique manquant.
5. Préparer une mesure ciblée et autorisée
Microsoft distingue les consentements utilisateur et administrateur dans sa revue des permissions. Les mécanismes de retrait diffèrent : la documentation précise notamment que le consentement utilisateur ne se révoque pas depuis l'onglet correspondant du portail, mais par les interfaces prévues. Source : Microsoft, revue des permissions applicatives
Notre recommandation : faire définir la cible par l'équipe identité avec le responsable métier. Quelle permission, quelle ressource, quel principal et quel périmètre faut-il traiter ? Qui approuve l'interruption et qui possède les moyens d'exécuter puis de contrôler la mesure ? Une commande générique de suppression ne remplace pas cette décision.
Préservez les éléments utiles lorsque l'urgence le permet. Si la protection doit précéder la collecte, consignez ce qui devient indisponible. Évaluez les dépendances légitimes et les options de secours ; ni le blocage de toutes les applications, ni la conservation de tous les droits ne doivent être des réflexes automatiques.
Un fournisseur qui voit l'alerte peut ne pas administrer l'annuaire. En cas d'indisponibilité de l'opérateur habilité, utilisez le relais prévu et informez le décideur du risque d'attente. Distinguez demande envoyée, mesure exécutée et résultat vérifié.
6. Vérifier l'effet et la possibilité d'un nouveau consentement
Microsoft indique que retirer une permission accordée n'empêche pas, à lui seul, un utilisateur de consentir de nouveau à la demande de l'application. La prévention d'une nouvelle autorisation doit donc être examinée séparément. Source : Microsoft, limites du retrait des permissions
Notre recommandation : contrôler l'état des objets concernés après l'action et rechercher les changements ou usages ultérieurs pertinents. Faites vérifier les effets sur les sessions et jetons selon le mécanisme et le service concernés ; ne promettez ni coupure instantanée, ni délai universel à partir du seul retrait d'un droit.
Tout test d'accès doit être préparé par l'opérateur sur un périmètre approuvé, sans récupérer un jeton suspect pour le rejouer. Vérifiez aussi la politique de consentement adaptée au risque, ses exceptions et les besoins légitimes. Un contrôle préventif annoncé doit être testé ou rester explicitement non vérifié.
Un exercice et une conclusion exploitable
Cas entièrement fictif : une application présentée comme un outil de classement reçoit un consentement utilisateur. L'inventaire confirme un droit délégué sur une ressource documentaire. Les logs établissent le consentement, mais les sources disponibles ne permettent pas d'attribuer une lecture de fichier à cette application.
Le responsable métier ne reconnaît pas le besoin. L'équipe identité retire l'autorisation ciblée sous mandat et en vérifie l'état ; la prévention d'un nouveau consentement reste une action séparée. Le dossier ne conclut pas « aucune donnée consultée » : il conserve la limite de visibilité et attribue la collecte complémentaire à un responsable.
Pour accepter l'exercice, un second analyste doit retrouver les objets exacts, le droit constaté, les usages prouvés ou inconnus, l'autorité de réponse et les contrôles réalisés. La conclusion distingue faits, risque accepté et prochaine décision. Aucun résultat de cet exemple ne décrit un client réel ou une capacité produit.
Utilisez le carnet d'investigation pour consigner ces éléments. Pour préparer une revue des accès et des procédures de réponse, échangeons sur votre projet.