Examen d’octroi de consentement d’application

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 pour effectuer un examen 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 :

  • Accès au locataire en tant qu’Administrateur général : uniquement un compte cloud (ne faisant pas partie de son environnement local)
  • 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(s) du/des compte(s) 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 système requise

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

  1. Le module AzureAD PowerShell est installé.
  2. Vous disposez de droits d’administrateur général sur le locataire sur lequel le script est exécuté.
  3. Un rôle d’administrateur local vous a été attribué sur l’ordinateur que vous allez utiliser pour exécuter les scripts.

Installer le module AzureAD

Utilisez cette commande pour installer le module AzureAD.

Install-Module -Name AzureAD -Verbose

Notes

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 "2b1a14ac-2956-442f-9577-1234567890ab" -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 d’Administrateur général 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.

Notes

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 d’administrateur au niveau du locataire, vous devez vous connecter en tant que l’un des éléments suivants :

  • Administrateur général
  • Administrateur d’application
  • Administrateur d'applications 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 permissions 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 les pages suivantes :

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é, nous avons observé les autorisations déléguées (Application+Utilisateur) « racine » suivantes qui ont été utilisées incorrectement afin d’autoriser des attaques par hameçonnage. La racine correspond au niveau supérieur. Par exemple, Contacts.* signifie inclure toutes les permutations déléguées des autorisations Contacts : Contacts.Read, Contacts.ReadWrite, Contacts.Read.Shared et Contacts.ReadWrite.Shared.

  1. Mail.* (y compris Mail.Send*, mais pas Mail.ReadBasic*)
  2. Contacts : *
  3. MailboxSettings.*
  4. Personnes.*
  5. Fichiers.*
  6. Remarques.*
  7. Directory.AccessAsUser.All
  8. User_Impersonation

Les sept premières autorisations de la liste ci-dessus 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é.

Conformément à notre observation, les attaquants ont utilisé une combinaison des six premières autorisations dans 99 % des attaques par hameçonnage de consentement. La plupart des gens ne pensent pas à la version déléguée de Mail.Read ou Files.Read en tant qu’une autorisation à haut risque. Toutefois, les attaques que nous avons rencontrées sont généralement des attaques répandues ciblant les utilisateurs finaux, plutôt que des tentatives d’hameçonnage interne contre les administrateurs qui peuvent réellement donner leur consentement aux 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 si associées à 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.

    afficher les autorisations

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

    apipermissions

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

    api

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

    types d’autorisations

  5. Sélectionnez le type d’autorisations que l’application inscrite utilise : autorisationsdéléguées ou autorisationsd’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.

    examplepermission

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

    eduroster

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

    Pour plus d’informations, lisez les autorisations Graph.

Workflow

Workflow d’enquête d’octroi de consentement d’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.

Check-list

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

  • Configuration requise

    Vérifiez que vous avez accès au locataire en tant qu’Administrateur général. Il s’agit d’un compte cloud uniquement qui ne fait pas partie de votre environnement local.

  • 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
    • Nom(s) du/des compte(s) compromis
    • Rôles du/des compte(s) 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 :

    • Droits d’administrateur général sur le locataire pour exécuter le script
    • Rôle d’administrateur local sur l’ordinateur à partir duquel le script est exécuté
  • Configuration de PowerShell

    Configurez votre environnement PowerShell avec les éléments suivants :

    • Installez le module Azure AD PowerShell.
    • Exécutez l’application Windows PowerShell avec des privilèges élevés. (Exécutez en tant qu’administrateur).
    • Configurez PowerShell pour exécuter des scripts signés.
    • 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

Notes

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 portail Azure Active Directory pour rechercher les applications auxquelles un utilisateur individuel a accordé des autorisations.

  1. Connectez-vous au portail Azure en tant qu’administrateur.
  2. Sélectionnez l’icône Azure Active Directory.
  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 qui ne nécessite pas de modifier quoi que ce soit dans la location. Nous allons nous baser sur notre investigation 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 "2b1a14ac-2956-442f-9577-1234567890ab" -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 Azure AD en vous servant de cette commande.

     Disconnect-AzureAD
    

    Notes

    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, filtrez ou formatez les données dans une table, puis enregistrez-les en tant que fichier .xlxs (pour le filtrage).

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

    Exemple d’en-têtes de colonne

  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 Lecture et Écriture ou *. Toutes, et vérifiez les, car elles ne sont peut-être pas appropriées. Exemple de colonne d’autorisation F

    Notes

    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 Exemple d’un nom mal orthographié

    • Noms inhabituels ou blands Exemple d’un nom inhabituel

    • Noms de pirate. Vous devez attentivement examiner ces noms. Exemple de nom de pirate

Exemple de sortie : AllPrincipals et lire-écrire tout. Il se peut que les applications n’aient rien de suspect, elles n’ont peut-être pas de noms banales. De plus, elles 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.

Exemple d’applications avec AllPrincipals ConsentType

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

  1. ReplyURL/RedirectURL
    • Rechercher des URL suspectes
  2. 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 ?
  3. Existe-t-il des conditions d’utilisation du service/accord de service dans l’inscription de l’application ?
  4. Le contenu est-il unique et spécifique à l’application/au serveur de publication ?
  5. 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 Azure AD.

  • L’application est configurée de telle sorte qu’elle semble légitime. 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.

    Exemple de demande d’autorisations

Repérer les signes d’une attaque

  1. Ouvrez le Centre de conformité de la sécurité&.

  2. Accédez à Recherche et sélectionnez Recherche dans le journal d’audit.

  3. Recherchez (toutes les activités et tous les utilisateurs) et, si nécessaire, entrez la date de début et la date de fin, puis sélectionnez Rechercher.

    Exemple d’une recherche dans un journal d’audit

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

    Exemple de filtrage d’une recherche dans un journal d’audit

  5. Si vous disposez d’une activité sous consentement à octroyer, continuez comme indiqué ci-dessous.

  6. 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é.

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

    Notes

    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, il indique que quelqu’un disposant d’un accès administrateur général peut avoir accordé un accès étendu aux données. S’il s’agit d’un événement inattendu, effectuez des étapes immédiates pour confirmer une attaque.

Comment confirmer qu’une attaque s’est produite ?

Si une ou plusieurs instances des IOC sont répertoriées ci-dessus, vous devez effectuer des examens supplémentaires pour confirmer que l’attaque s’est produite.

Inventorier les applications avec un accès dans votre organisation

Vous pouvez inventorier les applications de vos utilisateurs à l’aide du portail Azure Active Directory, de PowerShell, ou en faisant en sorte que vos utilisateurs énumèrent individuellement leur accès à l’application.

  • Utilisez le portail Azure Active Directory pour inventorier les applications, ainsi que 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 portail Azure Active Directory pour afficher la liste des applications auxquelles un utilisateur individuel a accordé des autorisations.

  1. Connectez-vous au portail Azure avec des droits d’administration.
  2. Sélectionnez l’icône Azure Active Directory.
  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 le Centre de conformité et de sécurité Microsoft 365.

Important : si l’audit n’est pas activé avant l’attaque potentielle, vous ne pouvez pas réaliser d’investigation puisque 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 des classeurs Azure Monitor pour surveiller les autorisations et l’activité associée au consentement. 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.

Une fois que vous avez 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 Support Microsoft pour signaler l’application malveillante.

Une fois qu’une application a été désactivée dans votre locataire Azure AD, elle ne peut pas obtenir de nouveaux jetons pour accéder aux données, et d’autres utilisateurs ne pourront pas se connecter à l’application ou lui accorder son consentement.

Notes

Si vous pensez que vous avez rencontré une application malveillante dans votre organisation, il est préférable de la désactiver que de la supprimer. Si vous supprimez uniquement l’application, elle peut revenir 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 revenir ultérieurement.

Étapes pour protéger votre organisation

Il existe différents types d’attaque de consentement, mais si vous respectez ces défenses recommandées, qui atténuent tous les types d’attaques, en particulier l’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 Azure AD 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 tous les 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.

    Notes

    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 n’est pas activé, le message suivant s’affiche :

    AADSTS90094 : <clientAppDisplayName> a besoin de l’autorisation d’accéder aux ressources de votre organisation que seul un administrateur peut accorder. Avant d’utiliser cette application, demandez à un administrateur d’accorder une autorisation à celle-ci. Dans ce cas, un événement d’audit est également enregistré avec une catégorie de type d’activité « ApplicationManagement » de « Consentement à l’application » et la raison d’état « Application à risque détectée ».

Notes

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.

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 Azure AD.

  • 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

Références

La source du contenu de cet article est la suivante :

Playbooks sur les réponses aux incidents supplémentaires

Vérifiez les aides afin d’identifier et d’examiner ces types d’attaques supplémentaires :

Ressources pour répondre aux incidents