Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Les applications Azure demandent des autorisations pour accéder aux données utilisateur (informations de base, mais aussi accès aux documents, envoi d'emails...).
Si autorisé, un utilisateur normal peut accorder son consentement uniquement pour les "autorisations à faible impact". Dans tous les autres cas, le consentement de l'administrateur est requis.
GA, ApplicationAdministrator, CloudApplication Administrator et un rôle personnalisé incluant la permission d'accorder des autorisations aux applications peuvent fournir un consentement à l'échelle du locataire.
Seules les autorisations qui ne nécessitent pas le consentement de l'administrateur sont classées comme à faible impact. Ce sont les autorisations requises pour la connexion de base : openid, profile, email, User.Read et offline_access. Si une organisation autorise le consentement des utilisateurs pour toutes les applications, un employé peut accorder son consentement à une application pour lire les informations ci-dessus de son profil.
Par conséquent, un attaquant pourrait préparer une application malveillante et avec un phishing, amener l'utilisateur à accepter l'application et voler ses données.
Non authentifié : À partir d'un compte externe, créer une application avec les autorisations User.Read et User.ReadBasic.All par exemple, phishing un utilisateur, et vous pourrez accéder aux informations du répertoire.
Cela nécessite que l'utilisateur phishé puisse accepter des applications OAuth provenant d'environnements externes !
Authentifié : Ayant compromis un principal avec suffisamment de privilèges, créer une application à l'intérieur du compte et phishing un utilisateur privilégié qui peut accepter des autorisations OAuth privilégiées.
Dans ce cas, vous pouvez déjà accéder aux informations du répertoire, donc l'autorisation User.ReadBasic.All n'est plus intéressante.
Vous êtes probablement intéressé par les autorisations qui nécessitent qu'un administrateur les accorde, car un utilisateur ordinaire ne peut accorder aucune autorisation aux applications OAuth, c'est pourquoi vous devez phisher uniquement ces utilisateurs (plus d'informations sur les rôles/permissions qui accordent ce privilège plus tard)
La commande PowerShell suivante est utilisée pour vérifier la configuration du consentement pour les utilisateurs dans Azure Active Directory (Azure AD) concernant leur capacité à consentir à des applications :
Désactiver le consentement des utilisateurs : Ce paramètre interdit aux utilisateurs de donner des autorisations aux applications. Aucun consentement des utilisateurs aux applications n'est autorisé.
Les utilisateurs peuvent consentir aux applications de publishers vérifiés ou de votre organisation, mais uniquement pour les autorisations que vous sélectionnez : Ce paramètre permet à tous les utilisateurs de consentir uniquement aux applications publiées par un publisher vérifié et aux applications enregistrées dans votre propre locataire. Il ajoute une couche de contrôle en permettant le consentement uniquement pour des autorisations spécifiques.
Les utilisateurs peuvent consentir à toutes les applications : Ce paramètre est plus permissif et permet à tous les utilisateurs de consentir à toutes les autorisations pour les applications, tant que ces autorisations ne nécessitent pas de consentement administratif.
Politique de consentement d'application personnalisée : Ce paramètre indique qu'une politique personnalisée est en place, qui peut être adaptée aux exigences organisationnelles spécifiques et peut impliquer une combinaison de restrictions basées sur le publisher de l'application, les autorisations demandées par l'application et d'autres facteurs.
Dans une attaque par consentement illicite, les attaquants trompent les utilisateurs finaux pour qu'ils accordent des autorisations à une application malveillante enregistrée avec Azure. Cela se fait en faisant apparaître l'application comme légitime, conduisant les victimes à cliquer sans le savoir sur un bouton "Accepter". En conséquence, Azure AD émet un jeton vers le site de l'attaquant, leur permettant d'accéder et de manipuler les données de la victime, telles que la lecture ou l'envoi d'e-mails et l'accès à des fichiers, sans avoir besoin d'un compte organisationnel.
L'attaque implique plusieurs étapes ciblant une entreprise générique. Voici comment cela pourrait se dérouler :
Enregistrement de domaine et hébergement d'application : L'attaquant enregistre un domaine ressemblant à un site de confiance, par exemple, "safedomainlogin.com". Sous ce domaine, un sous-domaine est créé (par exemple, "companyname.safedomainlogin.com") pour héberger une application conçue pour capturer des codes d'autorisation et demander des jetons d'accès.
Enregistrement de l'application dans Azure AD : L'attaquant enregistre ensuite une application multi-locataire dans son locataire Azure AD, la nommant d'après l'entreprise cible pour paraître légitime. Il configure l'URL de redirection de l'application pour pointer vers le sous-domaine hébergeant l'application malveillante.
Configuration des autorisations : L'attaquant configure l'application avec diverses autorisations API (par exemple, Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Ces autorisations, une fois accordées par l'utilisateur, permettent à l'attaquant d'extraire des informations sensibles au nom de l'utilisateur.
Distribution de liens malveillants : L'attaquant crée un lien contenant l'identifiant client de l'application malveillante et le partage avec des utilisateurs ciblés, les trompant pour qu'ils accordent leur consentement.
L'attaque peut être facilitée en utilisant des outils comme 365-Stealer.
Si l'attaquant a un certain niveau d'accès à un utilisateur de l'organisation victime, il pourrait vérifier si la politique de l'organisation permet à l'utilisateur d'accepter des applications :
Pour exécuter l'attaque, l'attaquant devra créer une nouvelle application dans son locataire Azure (dans les enregistrements d'application), configurée avec les autorisations :
User.ReadBasic.All se trouve dans Microsoft Graph dans Autorisations déléguées. (Les autorisations d'application nécessiteront toujours une approbation supplémentaire).
User.ReadBasic.All est l'autorisation qui vous permettra de lire les informations de tous les utilisateurs de l'organisation si elle est accordée.
N'oubliez pas que seuls GA, ApplicationAdministrator, CloudApplication Administrator et un rôle personnalisé incluant la permission d'accorder des autorisations aux applications peuvent fournir un consentement à l'échelle du locataire. Donc, vous devriez hameçonner un utilisateur avec l'un de ces rôles si vous voulez qu'il approuve une application nécessitant un consentement administratif.
Vous pouvez également créer une application via cli avec :
Vérifiez https://www.alteredsecurity.com/post/introduction-to-365-stealer pour apprendre à le configurer.
Notez que le jeton d'accès obtenu sera pour le point de terminaison graph avec les portées : User.Read et User.ReadBasic.All (les autorisations demandées). Vous ne pourrez pas effectuer d'autres actions (mais celles-ci suffisent pour télécharger des informations sur tous les utilisateurs de l'organisation).
Vous pouvez également utiliser cet outil pour effectuer cette attaque.
Une fois que vous avez accès à l'utilisateur, vous pouvez faire des choses comme voler des documents sensibles et même télécharger des fichiers de documents avec des portes dérobées.
Apprenez et pratiquez le piratage AWS :HackTricks Training AWS Red Team Expert (ARTE) Apprenez et pratiquez le piratage GCP : HackTricks Training GCP Red Team Expert (GRTE)
