Partager via

Investigation d’octroi de consentement d’application

  • Article

Cet article offre une aide sur l’identification et l’examen des attaques de consentement d’application, sur la protection des informations, ainsi que sur la minimisation des risques supplémentaires.

Cet article contient les sections suivantes :

  • Conditions préalables requises : décrit les exigences spécifiques que vous devez respecter avant de commencer l’examen. Par exemple, la journalisation qui doit être activée, et vous devez disposer des rôles et des autorisations nécessaires, entre autres.
  • Workflow : affiche le flux logique que vous devez suivre pour effectuer cet examen.
  • Liste de vérification : contient une liste de tâches pour chacune des étapes de l’organigramme. Cette liste de vérification peut être utile dans les environnements hautement réglementés afin de vérifier ce que vous avez fait ou simplement comme un contrôle de qualité pour vous-même.
  • Étapes d’examen : contient des instructions pas à pas détaillées pour cet examen spécifique.
  • Récupération : contient des étapes de haut niveau sur la façon de récupérer/limiter une attaque d’octroi de consentement d’application illicite.
  • Références : contient des documents de référence et de lecture supplémentaires.

Prérequis

Voici les paramètres généraux et les configurations que vous devez compléter lors d’une enquête sur les octrois de consentement d’application. Avant de commencer l’examen, assurez-vous d’avoir lu les informations sur les types d’autorisations de consentement expliquées dans Types d’autorisation de consentement.

Données client

Pour démarrer le processus d’examen, vous avez besoin des données suivantes :

  • Détails des indicateurs de compromission (IoC)
  • La date et l’heure auxquelles l’incident a été détecté
  • Plage de dates
  • Nombre de comptes compromis
  • Nom des comptes compromis
  • Rôles du compte compromis
  • Les comptes sont-ils hautement privilégiés (en disponibilité générale (GA) sur Microsoft Exchange, SharePoint) ?
  • Existe-t-il des applications d’entreprise liées à l’incident ?
  • Les utilisateurs ont-ils signalé des applications qui ont demandé des autorisations aux données en leur nom ?

Configuration requise

Assurez-vous d’effectuer les installations et les configurations requises suivantes :

  • Le module AzureAD PowerShell est installé.
  • Vous disposez des droits d’Administrateur général sur le locataire sur lequel le script est exécuté.
  • Un rôle d’administrateur local vous a été attribué sur l’ordinateur que vous utilisez pour exécuter les scripts.

Remarque

Les modules Azure AD et MSOnline PowerShell sont dépréciés depuis le 30 mars 2024. Pour en savoir plus, lisez les informations de dépréciation. Passé cette date, la prise en charge de ces modules est limitée à une assistance de migration vers le SDK et les correctifs de sécurité Microsoft Graph PowerShell. Les modules déconseillés continueront de fonctionner jusqu’au 30 mars 2025.

Nous vous recommandons de migrer vers Microsoft Graph PowerShell pour interagir avec Microsoft Entra ID (anciennement Azure AD). Pour explorer les questions courantes sur la migration, reportez-vous au FAQ sur la migration. Remarque : Les versions 1.0.x de MSOnline peuvent connaître une interruption après le 30 juin 2024.

Installer le module AzureAD

Utilisez cette commande pour installer le module AzureAD.

Install-Module -Name AzureAD -Verbose

Remarque

Si vous êtes invité à installer les modules à partir d’un référentiel non fiable, tapez Y, puis appuyez sur Entrée.

Installer le module MSOnline PowerShell

  1. Exécutez l’application Windows PowerShell avec des privilèges élevés (exécuter en tant qu’administrateur).

  2. Effectuez cette commande pour permettre à PowerShell d’exécuter des scripts signés.

    Set-ExecutionPolicy RemoteSigned

  3. Installez le module MSOnline en vous servant de cette commande.

    Install-Module -Name MSOnline -Verbose

    Remarque

    Si vous êtes invité à installer les modules à partir d’un référentiel non fiable, tapez Y, puis appuyez sur Entrée.

Télécharger le script AzureADPSPermissions à partir de GitHub

  1. Téléchargez le script Get-AzureADPSPermissions.ps1 à partir de GitHub dans un dossier à partir duquel vous allez exécuter le script. Le fichier de sortie « permissions.csv » est également écrit dans ce même dossier.

  2. Ouvrez une instance PowerShell en tant qu’administrateur, puis ouvrez le dossier dans lequel vous avez enregistré le script.

  3. Connectez-vous à votre annuaire à l’aide de l’applet de commande Connect-AzureAD. Voici un exemple.

    Connect-AzureAD -tenantid "aaaabbbb-0000-cccc-1111-dddd2222eeee" -AccountId "user1@contoso.onmicrosoft.com"

  4. Exécutez cette commande PowerShell.

    Get-AzureADPSPermissions.ps1 | Export-csv -Path "Permissions.csv" -NoTypeInformation

    Déconnectez votre session AzureAD en vous servant de cette commande.

    Disconnect-AzureAD

Le consentement est le processus d’octroi d’autorisation donné à une application pour accéder à des ressources protégées au nom de l’utilisateur. Un administrateur ou un utilisateur peut être invité à donner son consentement pour autoriser l’accès à ses données individuelles ou à ses données sur l’organisation.

Une application est autorisée à accéder aux données en fonction d’un utilisateur en particulier ou de l’ensemble de l’organisation. Toutefois, ces consentements peuvent être utilisés de façon incorrecte par les attaquants afin d’obtenir une persistance de l’environnement et d’accéder à des données sensibles. Ces types d’attaques portent le nom d’Octrois de consentement illicites, et peuvent se produire par le biais d’un hameçonnage par e-mail, d’un compte d’utilisateur compromis par une pulvérisation de mots de passe ou lorsqu’un attaquant enregistre une application en tant qu’utilisateur légitime. Dans les scénarios où un compte administrateur est compromis, l’inscription et l’octroi du consentement s’appliquent à l’échelle du locataire et pas seulement pour un seul utilisateur.

Pour qu’une application puisse accéder aux données de votre organisation, un utilisateur doit lui accorder les autorisations nécessaires. Les différentes autorisations ont trait à des niveaux d’accès différents. Par défaut, tous les utilisateurs peuvent accorder à des applications des autorisations qui ne nécessitent pas de consentement de l’administrateur. Par exemple, par défaut, un utilisateur peut autoriser une application à accéder à sa boîte aux lettres, mais ne peut pas lui donner un accès illimité lui permettant de lire et d’écrire dans tous les fichiers de votre organisation.

Remarque

Si les utilisateurs peuvent autoriser des applications à accéder à des données, il peuvent facilement acquérir des applications utiles et être productifs. Toutefois, dans certains cas, une telle configuration peut constituer un risque si elle n’est pas analysée et contrôlée avec précaution.

Pour pouvoir octroyer un consentement administrateur au niveau du locataire, vous devez vous connecter avec au moins l’un des rôles suivants :

  • Administrateur d’application
  • Administrateur d’application cloud
  • Administrateur : indique que le consentement a été fourni par l’administrateur (au nom de l’organisation)
  • Utilisateur individuel - indique que l’utilisateur a donné son consentement et que l’accès est limité aux informations de cet utilisateur
  • Valeurs acceptées
    • AllPrincipals : consenti par un administrateur pour l’ensemble de la location
    • Principal : consenti par l’utilisateur individuel uniquement pour les données relatives à ce compte

L’expérience utilisateur réelle d’octroi du consentement varie selon les stratégies définies au niveau du locataire de l’utilisateur, le niveau d’autorité (ou rôle) de l’utilisateur et le type d’autorisations demandé par l’application cliente. Cela signifie que les développeurs d’applications et les administrateurs de locataires contrôlent certains aspects de l’expérience de consentement. Les administrateurs peuvent configurer et désactiver des stratégies à partir d’un locataire ou d’une application afin de contrôler l’expérience de consentement au sein de leur locataire. Les développeurs d’applications peuvent décider des types d’autorisations qui sont demandés et s’ils souhaitent guider les utilisateurs vers le flux de consentement utilisateur ou vers le flux de consentement administrateur.

  • Flux de consentement de l’utilisateur : intervient lorsqu’un développeur d’application dirige les utilisateurs vers le point de terminaison d’autorisation avec l’intention d’enregistrer le consentement pour l’utilisateur actuel uniquement.

  • Flux de consentement administrateur : intervient lorsqu’un développeur d’application dirige les utilisateurs vers le point de terminaison de consentement administrateur avec l’intention d’enregistrer le consentement pour l’ensemble du locataire. Pour s’assurer que le flux de consentement administrateur fonctionne correctement, les développeurs d’application doivent répertorier toutes les autorisations dans la propriété RequiredResourceAccess qui se trouve dans le manifeste de l’application.

Permissions déléguées et permissions d’application

Les permissions déléguées sont utilisées par les applications dont l’utilisateur connecté est présent et qui peuvent obtenir des consentements appliqués par l’administrateur ou l’utilisateur.

Les autorisations d’application sont utilisées par les applications s’exécutant sans un utilisateur connecté présent. Par exemple, les applications qui s’exécutent en tant que services ou démons en arrière-plan. Les permissions d’application peuvent uniquement être accordées par un administrateur.

Pour plus d’informations, consultez l’article suivant :

Classification des autorisations à risque

Il existe des milliers (au moins) d’autorisations dans le système, et il est impossible de toutes les répertorier ou de toutes les analyser. La liste ci-dessous montre les autorisations couramment utilisées de manière incorrecte, ainsi que celles qui pourraient avoir un impact catastrophique en cas d’utilisation incorrecte.

À un niveau élevé, Microsoft a observé que les autorisations déléguées (Application+Utilisateur) « racine » suivantes étaient utilisées à mauvais escient dans des attaques par hameçonnage de consentement. La racine correspond au niveau supérieur. Par exemple, Contacts.* signifie inclure toutes les permutations déléguées des autorisations de Contacts : Contacts.Read, Contacts.ReadWrite, Contacts.Read.Shared et Contacts.ReadWrite.Shared.

  1. Mail.* (notamment Mail.Send*, mais pas Mail.ReadBasic*)
  2. Contacts. *
  3. MailboxSettings.*
  4. Les personnes*.
  5. Fichiers.*
  6. Notes.*
  7. Directory.AccessAsUser.All
  8. user_impersonation

Les sept premières autorisations de la liste précédente concernent Microsoft Graph, ainsi que les équivalents d’API « hérités », tels qu’Azure Active Directory (Azure AD) Graph et Outlook REST. La huitième autorisation concerne Azure Resource Manager (ARM) et peut également être dangereuse sur toute API exposant des données sensibles avec cette étendue d’emprunt d’identité.

D’après les observations de l’équipe Réponse aux incidents Microsoft, les attaquants utilisent une combinaison des six premières autorisations dans 99 % des attaques par hameçonnage de consentement. La plupart des gens ne considèrent pas la version déléguée de Mail.Read ou de Files.Read comme une autorisation à haut risque. Toutefois, dans la plupart des cas, les attaques sont répandues et ciblent les utilisateurs finaux, plutôt que d’être des tentatives d’hameçonnage contre des administrateurs pouvant réellement donner leur consentement à des autorisations dangereuses. Il est recommandé de protéger les applications avec ces autorisations de niveau d’impact « critiques ». Même si les applications n’ont pas d’intention malveillante, et si un intervenant malveillant essaye de compromettre l’identité de l’application, alors toute votre organisation peut être à risque.

Pour obtenir les autorisations d’impact de risque le plus élevé, commencez ici :

  • Les versions de permission d’application (AppOnly/AppRole) de toutes les autorisations ci-dessus, le cas échéant

Versions déléguées et AppOnly des autorisations suivantes :

  • Application.ReadWrite.All
  • Directory.ReadWrite.All
  • Domain.ReadWrite.All*
  • EduRoster.ReadWrite.All*
  • Group.ReadWrite.All
  • Member.Read.Hidden*
  • RoleManagement.ReadWrite.Directory
  • User.ReadWrite.All*
  • User.ManageCreds.All
  • Toutes les autres autorisations AppOnly qui permettent l’accès en écriture

Pour obtenir la liste des autorisations avec risque le plus faible, commencez ici :

  • User.Read
  • User.ReadBasic.All
  • Open_id
  • E-mail
  • Profil
  • Offline_access (uniquement en cas d’association à d’autres autorisations sur cette liste de « risque le plus faible »)

Affichage des autorisations

  1. Pour afficher les autorisations, accédez à l’écran Inscription dans l’application d’entreprise.

    Capture d’écran montrant comment afficher différentes autorisations.

  2. Sélectionnez Afficher les autorisations d’API.

    Capture d’écran montrant comment afficher et ajouter des autorisations d’API.

  3. Sélectionnez Ajouter une autorisation pour afficher l’écran suivant.

    Capture d’écran montrant comment demander des autorisations d’API.

  4. Sélectionnez Microsoft Graph pour afficher les différents types d’autorisations.

    Capture d’écran de différents types d’autorisations d’API.

  5. Sélectionnez le type d’autorisations que l’application inscrite utilise : Autorisations déléguées ou Autorisations d’application. Dans l’image ci-dessus, Autorisations de l’application est sélectionné.

  6. Vous pouvez rechercher l’une des autorisations d’impact à haut risque, telles que EduRoster.

    Capture d’écran d’un exemple de demande d’autorisation d’API.

  7. Sélectionnez EduRoster et développez les autorisations.

    Capture d’écran d’un élément d’autorisation d’API avec une info-bulle.

  8. Vous pouvez désormais attribuer ou évaluer ces autorisations.

    Pour plus d’informations, consultez Autorisations Graph.

Workflow

[Organigramme d’un flux de travail d’investigation d’octroi de consentement de l’application.]

Vous pouvez également :

  • Téléchargez les workflows de playbook sur les réponses à l’octroi de consentement d’application et à d’autres incidents sous la forme d’un fichier PDF.
  • Téléchargez les workflows de playbook sur les réponses à l’octroi de consentement d’application et à d’autres incidents sous la forme d’un fichier Visio.

Liste de contrôle

Utilisez cette liste de vérification pour effectuer la validation d’octroi de consentement d’application.

  • Indicateurs de compromission (IoC)

    Vérifiez les indicateurs de compromission (IoC) suivants :

    • Quand avez-vous remarqué l’incident ?
    • Plage de dates de l’incident (depuis quand la publication de l’objectif est-elle terminée ?)
    • Nombre de comptes compromis
    • Noms des comptes compromis
    • Rôles des comptes compromis
    • Les comptes compromis sont-ils hautement privilégiés, un utilisateur standard ou une combinaison des deux ?

  • Rôles

    Ces rôles doivent vous être attribués :

    • Rôle d’administrateur local sur l’ordinateur à partir duquel le script est exécuté

  • Configuration de PowerShell

    Configurez votre environnement PowerShell avec les étapes suivantes :

    1. Installez le module Azure AD PowerShell.
    2. Exécutez l’application Windows PowerShell avec des privilèges élevés. (Exécutez en tant qu’administrateur).
    3. Configurez PowerShell pour exécuter des scripts signés.
    4. Téléchargez le script Get-AzureADPSPermissions.ps1.

  • Déclencheurs d’investigation

    • Compromission du compte
    • Paramètres de consentement d’application modifiés sur le locataire
    • Raison de l’état de l’événement d’alerte/d’audit d’« application à risque » détectée
    • Applications impaires détectées

Vous pouvez également télécharger les check-lists de playbook sur l’octroi de consentement d’application et d’autres incidents sous la forme d’un fichier Excel.

Étapes d’investigation

Vous pouvez utiliser les deux méthodes suivantes pour examiner les octrois de consentement d’application :

  • Portail Azure
  • Script PowerShell

Remarque

L’utilisation du portail Azure vous permet uniquement d’afficher les octrois de consentement administrateur au cours des 90 derniers jours. En fonction de cela, nous vous recommandons d’utiliser la méthode de script PowerShell uniquement pour réduire les étapes d’investigation des inscriptions de l’attaquant.

Méthode 1 : utilisation du portail Azure

Vous pouvez utiliser le Centre d’administration Microsoft Entra pour rechercher des applications auxquelles des utilisateurs individuels ont accordé des autorisations.

  1. Connectez-vous au portail Azure en tant qu’administrateur.
  2. Sélectionnez l’icône Microsoft Entra ID.
  3. Sélectionnez Utilisateurs.
  4. Sélectionnez l’utilisateur que vous souhaitez examiner.
  5. Sélectionnez Applications.
  6. Vous pouvez voir la liste des applications qui sont attribuées à l’utilisateur, ainsi que les autorisations dont elles disposent.

Méthode 2 : utilisation de PowerShell

Il existe plusieurs outils PowerShell que vous pouvez utiliser pour investiguer les octrois de consentement illicites, tels que :

PowerShell est l’outil le plus simple et ne nécessite pas de modifier quoi que ce soit dans la location. Nous allons nous baser sur notre enquête concernant la documentation publique de l’attaque d’octroi de consentement illicite.

Exécutez Get-AzureADPSPermissions.ps1 pour exporter tous les octrois de consentement OAuth, ainsi que les applications OAuth pour tous les utilisateurs de votre location dans un fichier .csv. Consultez la section Conditions préalables requises pour télécharger et exécuter le script Get-AzureADPSPermissions.

  1. Ouvrez une instance PowerShell en tant qu’administrateur, puis ouvrez le dossier dans lequel vous avez enregistré le script.

  2. Connectez-vous à votre répertoire en vous servant de la commande Connect-AzureAD suivante. Voici un exemple.

    Connect-AzureAD -tenantid "aaaabbbb-0000-cccc-1111-dddd2222eeee" -AccountId "user1@contoso.onmicrosoft.com"

  3. Exécutez cette commande PowerShell.

    Get-AzureADPSPermissions.ps1 | Export-csv c:\temp\consentgrants\Permissions.csv -NoTypeInformation

  4. Une fois le script terminé, il est recommandé de déconnecter la session Microsoft Entra en vous servant de cette commande.

     Disconnect-AzureAD

    Remarque

    L’exécution du script peut prendre plusieurs heures, en fonction de la taille et des autorisations configurées, ainsi que de votre connexion.

  5. Le script crée un fichier nommé Permissions.csv.

  6. Ouvrez le fichier, puis filtrez ou formatez les données dans une table et enregistrez-les en tant que fichier .xlxs.

    Les en-têtes de colonne pour la sortie sont représentées sur cette image.

    Capture d’écran des en-têtes de colonne Excel.

  7. Dans la colonne ConsentType (G), recherchez la valeur AllPrinciples. L’autorisation AllPrincipals permet à l’application cliente d’accéder au contenu de chaque personne dans la location. Les applications Microsoft 365 natives ont besoin de cette autorisation pour fonctionner correctement. Chaque application non Microsoft disposant de cette autorisation doit être examinée avec précaution.

  8. Dans la colonne Autorisation(F), examinez les autorisations de chaque application déléguée. Recherchez l’autorisation de Lecture et d’Écriture ou *. Toutes, et vérifiez soigneusement ces autorisations, car elles ne sont peut-être pas appropriées. Capture d’écran des autorisations d’application dans la colonne F.

    Remarque

    Vérifiez les utilisateurs spécifiques qui ont accordé des autorisations. Si des utilisateurs ayant un profil ou un impact élevé possèdent des consentements inappropriés accordés, vous devez approfondir votre examen.

  9. Dans la colonne ClientDisplayName(C), recherchez les applications qui semblent suspectes, par exemple :

    • Applications avec des noms mal orthographiés Capture d’écran d’un nom mal orthographié.

    • Noms inhabituels ou anodins Capture d’écran d’un nom inhabituel.

    • Noms de pirate. Vous devez attentivement examiner ces noms. Capture d’écran d’un nom de pirate.

Exemple de sortie : AllPrincipals et lire-écrire tout. Les applications n’ont peut-être rien de suspect, comme des noms banales et utilisent MS Graph. Toutefois, effectuez des recherches et déterminez l’objectif des applications, ainsi que les autorisations réelles des applications dans le locataire, comme illustré dans cet exemple.

Capture d’écran d’exemples d’applications avec AllPrincipals ConsentType.

Voici quelques conseils utiles pour examiner les examens de stratégie de sécurité des informations (ISP) :

  • ReplyURL/RedirectURL
    • Rechercher des URL suspectes
  • L’URL est-elle hébergée sur un domaine suspect ?
    • Est-elle compromise ?
    • Le domaine a-t-il été enregistré récemment ?
    • S’agit-il d’un domaine temporaire ?
  • Existe-t-il des conditions d’utilisation du service/accord de service dans l’inscription de l’application ?
  • Le contenu est-il unique et spécifique à l’application/au serveur de publication ?
  • Le locataire qui a inscrit l’application a-t-il été récemment créé ou compromis (par exemple, l’application a-t-elle été enregistrée par un utilisateur à risque) ?

Techniques d’attaque

Bien que chaque attaque varie, les techniques d’attaque principales sont :

  • Un attaquant inscrit une application auprès d’un fournisseur OAuth 2.0, comme Microsoft Entra ID.

  • Les applications sont configurées de manière à les rendre légitimes. Par exemple, les attaquants peuvent utiliser le nom d’un produit populaire disponible dans le même écosystème.

  • L’attaquant obtient un lien directement à partir des utilisateurs, ce qui peut être effectué par le biais d’un hameçonnage conventionnel par e-mail, en compromettant un site web non malveillant ou en utilisant d’autres techniques.

  • L’utilisateur sélectionne le lien et affiche une invite de consentement authentique lui demandant d’accorder à l’application malveillante des autorisations d’accès à des données.

  • Si un utilisateur sélectionne « Accepter », il accorde les autorisations à l’application pour accéder à des données sensibles.

  • L’application obtient un code d’autorisation, qu’elle accepte contre un jeton d’accès et éventuellement contre un jeton d’actualisation.

  • Le jeton d’accès est utilisé pour effectuer des appels d’API au nom de l’utilisateur.

  • Si l’utilisateur accepte, l’attaquant peut accéder aux e-mails de l’utilisateur, aux règles de transfert, aux fichiers, aux contacts, aux notes, au profil, ainsi qu’à d’autres données et ressources sensibles.

    Capture d’écran de l’exemple de demande d’autorisations.

Repérer les signes d’une attaque

  1. Dans le portail Microsoft 365 Defender à l’adresse https://security.microsoft.com, accédez à Audit. Ou pour accéder directement à la page Audit, utilisez l’adresse https://security.microsoft.com/auditlogsearch.

  2. Dans la page Audit, recherchez toutes les activités et tous les utilisateurs, entrez la date de début et la date de fin si nécessaire, puis sélectionnez Recherche.

    Capture d’écran de l’exemple d’une recherche dans le journal d’audit.

  3. Sélectionnez Filtrer les résultats et dans le champ Activité, entrez Consentir à l’application.

    Capture d’écran de l’exemple de filtrage d’une recherche dans les journaux d’audit.

  4. Si vous disposez d’une activité sous consentement à octroyer, passez à l’étape suivante.

  5. Sélectionnez le résultat pour afficher les détails de l’activité. Sélectionnez Plus d’informations pour obtenir les détails de l’activité.

  6. Vérifiez si IsAdminContent est défini sur « Vrai ».

    Remarque

    Ce processus peut prendre entre 30 minutes et 24 heures pour que l’entrée du journal d’audit correspondante s’affiche dans les résultats de la recherche après qu’un événement se soit produit.

    L’intervalle de temps durant lequel un enregistrement d’audit est conservé et peut être recherché dans le journal d’audit dépend de votre abonnement Microsoft 365, et en particulier du type de licence qui est attribué à un utilisateur spécifique. Si cette valeur est vraie, cela indique qu’une personne peut avoir accordé un accès étendu aux données. S’il s’agit d’un événement inattendu, effectuez des mesures immédiates pour confirmer une attaque.

Comment confirmer qu’une attaque s’est produite ?

Si vous possédez une ou plusieurs instances des IoCs précédemment répertoriées, vous devez effectuer une enquête supplémentaire pour confirmer que l’attaque s’est produite.

Inventorier les applications avec un accès dans votre organisation

Vous pouvez inventorier les applications pour vos utilisateurs en utilisant le centre d'administration Microsoft Entra, PowerShell, ou demander à vos utilisateurs d'énumérer individuellement leur accès aux applications.

  • Utilisez le Centre d’administration Microsoft Entra pour inventorier les applications et leurs autorisations. Cette méthode est complète, mais vous ne pouvez vérifier qu’un seul utilisateur à la fois, ce qui peut prendre du temps si vous devez vérifier les autorisations de plusieurs utilisateurs.
  • Utilisez PowerShell pour inventorier les applications et leurs autorisations. Cette méthode est la plus rapide et la plus complète, avec un minimum de surcharge.
  • Encouragez vos utilisateurs à vérifier individuellement leurs applications et autorisations et à signaler les résultats aux administrateurs pour correction.

Inventorier les applications attribuées aux utilisateurs

Vous pouvez utiliser le centre d’administration Microsoft Entra afin d’afficher la liste des applications pour lesquelles des utilisateurs individuels ont accordé des autorisations.

  1. Connectez-vous au portail Azure avec des droits d’administration.
  2. Sélectionnez l’icône Microsoft Entra ID.
  3. Sélectionnez Utilisateurs.
  4. Sélectionnez l’utilisateur que vous souhaitez examiner.
  5. Sélectionnez Applications.

Vous pouvez voir la liste des applications qui sont attribuées à l’utilisateur, ainsi que les autorisations dont elles disposent.

Déterminer l’étendue de l’attaque

Une fois l’inventaire de l’accès à l’application terminé, vérifiez le journal d’audit pour déterminer l’étendue complète de la violation. Recherchez les utilisateurs concernés, les délais d’exécution au cours desquels l’application illégale a eu accès à votre organisation, ainsi que les autorisations dont l’application disposait. Vous pouvez rechercher le journal d’audit dans les portails de conformité Microsoft 365 Security et Microsoft Purview.

Important

Si l’audit n’a pas été activé avant l’attaque possible, vous ne pourrez pas examiner, car les données d’audit ne sont pas disponibles.

Comment empêcher les attaques et limiter les risques ?

Si votre organisation dispose de la licence appropriée :

  • Utilisez d’autres fonctionnalités d’audit d’application OAuth dans Microsoft Defender for Cloud Apps.
  • Utilisez les Classeurs Azure Monitor pour superviser les autorisations et le consentement relatifs à l’activité. Le classeur Consent Insights fournit une vue des applications par nombre de demandes de consentement ayant échoué. Il peut être utile de classer par ordre de priorité les applications afin de permettre aux administrateurs de les passer en revue et de décider de leur accorder ou non le consentement de l’administrateur.

Après avoir identifié une application avec des autorisations illicites, désactivez immédiatement l’application en suivant les instructions fournies dans Désactiver une application. Ensuite, contactez le Support Microsoft pour signaler l’application malveillante.

Une fois qu’une application est désactivée dans Microsoft Entra, elle ne peut pas obtenir de nouveaux jetons pour accéder aux données, et d’autres utilisateurs ne peuvent pas se connecter ni accorder le consentement à l’application.

Remarque

Si vous pensez que vous avez rencontré une application malveillante dans votre organisation, il est préférable de le désactiver que de le supprimer. Si vous supprimez uniquement l’application, elle peut réapparaître ultérieurement si un autre utilisateur accorde son consentement. Au lieu de cela, désactivez l’application pour vous assurer qu’elle ne peut pas réapparaître ultérieurement.

Étapes pour protéger votre organisation

Il existe différents types d’attaques de consentement, ces défenses recommandées atténuent tous les types d’attaques, en particulier le hameçonnage par consentement, où les attaquants incitent les utilisateurs à accorder à une application malveillante un accès à des données sensibles ou à d’autres ressources. Au lieu d’essayer de voler le mot de passe de l’utilisateur, un attaquant cherche à obtenir une autorisation pour qu’une application contrôlée par un pirate accède à des données précieuses.

Pour éviter que des attaques de consentement n’affectent Microsoft Entra ID et Office 365, consultez les recommandations suivantes :

Définir des stratégies

  • Ce paramètre a des implications d’utilisateur et peut ne pas s’appliquer à un environnement. Si vous prévoyez d’autoriser des consentements, assurez-vous que les administrateurs approuvent les demandes.

  • Autorisez les consentements pour les applications à partir d’éditeurs vérifiés uniquement et avec des types spécifiques d’autorisations classées comme ayant un faible impact.

    Remarque

    Les recommandations ci-dessus sont proposées en fonction des configurations les plus appropriées et sécurisées. Toutefois, étant donné que la sécurité est un équilibre parfait entre les fonctionnalités et les opérations, les configurations les plus sécurisées peuvent entraîner des frais généraux supplémentaires pour les administrateurs. Cette décision doit être prise après consultation des administrateurs.

    Configurer le consentement de passage à une édition supérieure en fonction des risques : activation par défaut si le consentement de l’utilisateur aux octrois est activé

  • La réaffectation du consentement en fonction des risques contribue à réduire l’exposition des utilisateurs aux applications malveillantes qui font des demandes de consentement illicites. Si Microsoft détecte une demande de consentement de l’utilisateur final à risque, la demande nécessitera une « évolution » vers le consentement de l’administrateur à la place. Cette capacité est activée par défaut, mais elle entraîne un changement de comportement uniquement lorsque le consentement de l’utilisateur final est activé.

  • Quand une demande de consentement à risque est détectée, l’invite de consentement affiche un message indiquant que l’approbation de l’administrateur est requise. Si le workflow de demande de consentement administrateur est activé, l’utilisateur peut envoyer la demande à l’administrateur pour une révision supplémentaire, directement à partir de l’invite de consentement. S’il est activé, le message suivant s’affiche :

    AADSTS90094 : <clientAppDisplayName> a besoin d’une autorisation pour accéder aux ressources de votre organisation, et cet accès ne peut être autorisé que par un administrateur. Veuillez demander à un administrateur d’accorder une autorisation pour cette application avant de pouvoir l’utiliser. Dans ce cas, un événement d’audit est également journalisé avec la catégorie « ApplicationManagement », le type d’activité « Consentement à l'application » et la raison de l’état « Détection d'une application à risque ».

Remarque

Toutes les tâches qui requièrent l’approbation de l’administrateur ont une surcharge opérationnelle. « Consentement et autorisations, paramètres de consentement de l’utilisateur » est actuellement en Préversion. Une fois prête pour la disponibilité générale (GA), la fonctionnalité « Autoriser le consentement de l’utilisateur à partir d’éditeurs vérifiés pour des autorisations sélectionnées » doit réduire la surcharge des administrateurs et est recommandée pour la plupart des organisations.

Capture d’écran de l’exemple d’autorisations de consentement.

Apprenez à vos développeurs d’application à suivre l’écosystème d’application fiable. Pour aider les développeurs à générer des intégrations de haute qualité sécurisées, nous proposons également une préversion publique de l’Assistant d’intégration dans les inscriptions d’application Microsoft Entra.

  • L’Assistant d’intégration analyse l’inscription de votre application et l’évalue par rapport à un ensemble de meilleures pratiques de sécurité recommandées.
  • L’Assistant d’intégration met en évidence les meilleures pratiques qui sont pertinentes au cours de chaque phase du cycle de vie de votre intégration, du développement jusqu’à la surveillance, et garantit que chaque étape est correctement configurée.
  • Il est conçu pour faciliter votre travail, que vous intégriez votre première application ou que vous soyez un expert cherchant à améliorer ses compétences.

Informez votre organisation des tactiques de consentement (tactiques d’hameçonnage, consentements administrateur et d’utilisateur) :

  • Vérifiez les erreurs orthographiques et grammaticales. Si un e-mail ou l’écran de consentement de l’application contient des erreurs orthographiques et grammaticales, il est probable qu’il s’agisse d’une application suspecte.
  • Vérifiez les noms d’application et les URL du domaine. Les attaquants aiment usurper les noms d’application qui semblent provenir d’applications ou d’entreprises légitimes, mais qui ont pour conséquence que vous donniez votre consentement à une application malveillante.
  • Assurez-vous de reconnaître le nom de l’application et l’URL du domaine avant de donner votre consentement à une application.

Promouvoir et autoriser l’accès aux applications de confiance

  • Promouvez l’utilisation des applications qui ont été vérifiées par l’éditeur. La vérification de l’éditeur permet aux administrateurs et aux utilisateurs finaux de s’assurer de l’authenticité des développeurs d’applications. Plus de 660 applications ont été vérifiées par 390 éditeurs jusqu’à présent.
  • Configurez des stratégies de consentement d’application en permettant aux utilisateurs de donner leur consentement uniquement à des applications spécifiques fiables, telles que les applications développées par votre organisation ou par des éditeurs vérifiés.
  • Apprenez à votre organisation le fonctionnement de l’infrastructure de nos autorisations et consentements.
  • Comprenez les données et les autorisations demandées par une application et comprenez le fonctionnement des autorisations et du consentement au sein de notre plateforme.
  • Veillez à ce que les administrateurs sachent comment gérer et évaluer les demandes de consentement.

Effectuer l’audit des applications et des autorisations accordées au sein de votre organisation pour vous assurer que les applications utilisées n’accèdent qu’aux données dont elles ont besoin et qu’elles adhèrent aux principes de privilège moindre.

Corrections

  • Informer le client et proposer une sensibilisation et une formation relatives à la sécurisation des octrois de consentement d’application
  • Renforcer le processus d’octroi de consentement d’application à l’aide d’une directive organisationnelle et de contrôles techniques
  • Configurer Créer une planification pour évaluer les applications Consenties
  • Vous pouvez utiliser PowerShell pour désactiver les applications suspectes ou malveillantes en désactivant l’application

Contenu connexe

Playbooks sur les réponses aux incidents supplémentaires

Parcourez les conseils afin d’identifier et d’examiner ces types d’attaques supplémentaires :

Ressources pour répondre aux incidents