Un petit tour d’horizon des techniques d’hameçonnage sur Azure et Office 365

Les attaques par hameçonnage (phishing) sont connues de tous. L’objectif de ce type d’attaque est de réaliser des actions depuis le compte d’une victime ou de récupérer des informations sur la personne ou l’entreprise ciblée.

Malgré leur notoriété, elles restent très efficaces pour les attaquants. En effet, parmi les attaques investiguées par le CERT Wavestone, environ 51% d’entre elles commencent par l’utilisation de comptes valides, ce qui inclut les attaques par hameçonnage (phishing).

Face aux attaques par l’hameçonnage, nous sommes tous vulnérables ! Un attaquant disposant de suffisamment de ressources et d’informations sur sa cible peut générer un piège assez élaboré pour faire baisser la garde du destinataire. De même, les suites de produits Office365 et Azure disposent de fonctionnalités pouvant être exploitées dans le cadre d’attaques moins conventionnelles et dont les impacts peuvent être méconnus des utilisateurs.

La sensibilisation des employées, bien que nécessaire pour faire face aux menaces les plus répandues, ne suffit pas face à certains types d’attaques plus ciblées ou moins traditionnelles. Un durcissement des conditions d’accès aux ressources hébergées sur le cloud, une bonne hygiène dans la gestion des droits d’accès ainsi que la détection d’accès inhabituels et suspicieux sont primordiales dans la stratégie de défense des entreprises.

Les attaquants disposent d’une large gamme d’outils et de possibilités pour accéder aux documents stockés sur le SharePoint d’une entreprise, tenter de récupérer des emails sensibles ou récupérer des informations sur les employés. L’attaque par hameçonnage traditionnelle ainsi que par l’authentification « device code » seront brièvement expliquées ci-dessous avant d’examiner plus en détails les attaques par consentement illicite.

 

L’attaque de phishing traditionnelle : une menace connue et évitable via l’usage d’authentification multi facteur

Les attaques de phishing traditionnelles reposent généralement sur l’envoi d’un lien dirigeant les victimes ciblées vers un site qu’il contrôle. Grace à une mire d’authentification similaire à celles auxquelles sont habituées les employées de l’entreprise ciblée, l’attaquant récupère les identifiants et mots de passe des utilisateurs piégés.

L’attaque par hameçonnage traditionnelle est simple à mettre en œuvre en l’absence d’authentification multi-facteur

La simplicité de mise en œuvre à grande échelle d’une telle attaque en fait un outil de choix pour les attaques non ciblées. Une méthode pour se prémunir contre ce type d’attaque est d’imposer l’utilisation d’un second facteur d’authentification.

Il est à noter cependant que bien que plus complexe à mettre en œuvre, l’interception du second facteur d’authentification est techniquement réalisable et fera l’objet d’un article dédié.

 

L’attaque via l’authentification « device code » : une méthode méconnue d’authentification détournée par des attaquants

Cette attaque repose sur la fonctionnalité d’octroi d’autorisation d’appareil (device authorization grant)[1]. Cette méthode d’authentification permet d’authentifier un utilisateur sur un appareil ne disposant pas de navigateur web. Un code s’affichant sur cet appareil doit alors être renseigné sur un ordinateur ou un smartphone via le site de Microsoft dédié. Cet appareil disposera ensuite d’une partie des droits d’accès aux ressources Office 365 que l’utilisateur ayant renseigné le code.

Cette procédure peu connue des utilisateurs, peut être exploitée par un attaquant à des fins malveillantes :

• L’attaquant génère tout d’abord un code d’appareil, en utilisant le même processus utilisé par les appareils ne disposant pas de navigateur web.
• Ensuite, l’objectif de l’attaquant sera d’amener la victime à renseigner son code d’appareil sur la page https://microsoft.com/devicelogin. Par exemple, l’attaquant pourrait prétexter que pour accéder à un document sensible, il est nécessaire de se connecter à ce lien en utilisant le code qu’il a généré.
• Si la cible accède au lien, renseigne le code et s’authentifie, cela permettra à l’attaquant d’usurper l’identité de la victime.

Exemple d’attaque par hameçonnage par device code

Cette attaque est plus difficile à réaliser pour un attaquant en raison de la faible durée de vie des « device codes » : ces derniers sont uniquement valables pendant une durée de 15min et doivent donc être générés peu de temps avant que l’utilisateur ne le renseigne. Cette attaque est donc plus facilement réalisable dans le cadre d’attaques par « phoning » ou de phishing via Teams. Par exemple, l’attaquant pourrait appeler la victime, prétexter faire partie de l’équipe du support IT de l’entreprise pour demander à l’utilisateur de s’authentifier sur le lien indiqué et de renseigner le code de son choix.

Pour se prémunir contre ce type d’attaque, les politiques d’accès conditionnel sur Azure permettent notamment d’interdire les connexions suspicieuses provenant d’appareil non maitrisés par l’entreprise.

 

L’attaque par consentement illicite

En plus de ces deux méthodes, l’attaque par consentement illicite permet aussi à un attaquant de récupérer un accès à un environnement Azure de manière illégitime. Cette dernière était même initialement plus simple à mettre en œuvre pour un attaquant que les attaques via l’authentification « device code ». Face à la recrudescence de cette menace, des actions ont été menées en 2020 par Microsoft pour limiter les conditions de réalisation de l’attaque. Si des configurations durcies d’Azure permettent de totalement bloquer cette menace, les configurations implémentées par certaines entreprises les exposent à ce type d’attaque. Quels sont les prérequis pour la réalisation d’une telle attaque, quelles sont les conséquences possibles et comment s’en prémunir ?

 

Qu’est-ce qu’une attaque par consentement illicite ?

Pour comprendre le principe de cette attaque, mettons-nous dans la peau d’un employé victime d’une telle attaque :

• La victime reçoit un mail d’hameçonnage indiquant une action urgente à réaliser pour maintenir son compte Microsoft activé. Les employés sont sensibilisés à ne pas cliquer sur des liens de phishing et à ne pas entrer leur mot de passe sur des plateformes inconnues. Le lien sous le format https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=<CLIENT_ID>&redirect_uri=<Attacker_controled_URL>&response_type=code&response_mode=query&scope=Mail.ReadWrite%20Files.Read.All%20Mail.Send%20User.Read contient un domaine associé à Microsoft, ce qui rassure la victime.
• En cliquant sur le lien, la victime doit s’authentifier. Cette authentification est souvent automatique puisqu’elle bénéficie de l’authentification unique (SSO) de Microsoft. La victime reçoit alors une demande de délégation de permissions:

 

L’application malveillante demande à l’utilisateur de lui déléguer ses permissions

• Si la victime clique sur « Annuler » par prudence, elle est redirigée vers le serveur de l’attaquant avec une URL du type <Attacker_controled_URL>/?error=consent_required &error_description=AADSTS65004%3a+User+declined+to+consent+to+access+the+app.&error_uri=https%3a%2f%2flogin.microsoftonline.com%2ferror%3fcode%3d65004#. L’attaquant, comprenant que la victime n’a pas accepté la délégation de permissions, peut ensuite rediriger la victime sur la page de phishing, lui donnant l’impression que les permissions demandées doivent être acceptées pour passer à l’étape suivante.
• En raison du nom de domaine légitime et la vue de l’urgence indiquée dans le mail d’hameçonnage, la victime de l’attaque choisit d’accepter. Elle observe alors un message indiquant que son compte sera bien maintenu activé, comme suggéré dans le mail initial. Elle reprend donc une activité normale.

Or, ce consentement permet à l’attaquant de réaliser des actions au nom de la victime, en fonction des permissions accordées. A noter que l’attaque par consentement illicite a de nombreux avantages pour un attaquant, notamment :

• L’utilisation d’une URL associée à Microsoft lors de la demande de consentement, considérée comme de confiance et impliquant donc moins de méfiance de la part des utilisateurs ciblés.
• L’obtention d’un accès persistant pendant 90 jours, sans connaissance du mot de passe de l’utilisateur ni du second facteur d’authentification, si aucune stratégie d’accès conditionnels n’est implémentée.
• La possibilité de requêter directement les APIs de Microsoft pour récupérer de manière automatisée les fichiers, emails et autres ressources de l’entreprise accessibles par l’utilisateur piégé.

 

Aparté technique

D’un point de vue technique, l’attaque par consentement illicite repose sur la capacité d’un attaquant à créer une application demandant des délégations de permissions. La délégation de permission est une fonctionnalité qui est régulièrement utilisée par les utilisateurs sans qu’ils s’en rendent compte, par exemple le client Outlook est autorisé par défaut à récupérer et les notifier de l’arrivée de nouveaux emails.

Voici les étapes clés lors de la réalisation de ce type d’attaque (qui repose sur la cinématique Authorization Code Grant d’OAuth 2.0) :

• L’attaquant crée une application d’entreprise sur Azure AD (application registration) et configure les permissions qu’il souhaite obtenir de la part des utilisateurs. Il peut instancier également un « client_secret» sur l’application. Certaines contraintes liées à cette application sont détaillées plus bas.
• Il met en place un serveur vers lequel les utilisateurs seront redirigés suite aux consentements et indique son URL en tant qu’URL de redirection valide pour l’application.
• À la suite du consentement d’un utilisateur, celui-ci sera redirigé vers le site malveillant et un code sera fourni à l’attaquant. Ce code est la preuve à montrer à Microsoft que l’utilisateur autorise l’application à faire des actions en son nom.
• A l’aide de ce code et du « client_secret » de l’application, l’attaquant pourra récupérer un jeton OAuth. Ce jeton est un récépissé signé par Microsoft qui précise les actions que la victime autorise à faire en son nom. L’attaquant peut également récupérer un « refresh_token » permettant de renouveler la validité du jeton OAuth.
• Ce jeton OAuth est alors utilisable pour envoyer des requêtes à la Graph API au nom de la victime et par conséquent permet d’usurper son identité.

 

Quelles sont les conséquences d’une telle attaque ?

Si certaines permissions nécessitent par défaut l’approbation d’un administrateur pour être déléguées, d’autres permissions peuvent être déléguées directement par les utilisateurs dans les environnements Azure non durcis. Les permissions pouvant être récupérées par l’attaquant lors de ce type d’attaque dépendent donc de la configuration du tenant Azure AD ciblé.

Voici quelques exemples d’abus possibles par un attaquant qui aurait réussi à récupérer les permissions d’un utilisateur sur un environnement non durci.

Actions réalisables à la suite d’une attaque par consentement illicite réussie sur en environnement Azure non durci

• Azure Active Directory :
  • La permission Microsoft Graph User.ReadBasic.All permet de récupérer les adresses email des tous les utilisateurs d’un tenant, ce qui permet de déployer des attaques de phishing à plus grande échelle à partir d’une première compromission.
• Outlook :
  • L’envoi d’un email au nom d’un utilisateur peut permettre la réalisation d’attaques dites de « fraude au président » à l’aide des permissions Microsoft Graph Mail.Send et Mail.ReadWrite. Un employé compromis disposant d’un niveau hiérarchique élevé pourrait par exemple demander par email l’envoi en urgence d’une somme important d’argent à un compte non répertorié par l’entreprise.
  • Les emails envoyés peuvent également être dissimulés à l’aide de règles de filtrage Outlook pouvant être modifiées à l’aide de la permission MailboxSettings.ReadWrite. L’attaquant pourra alors rediriger tous les emails liés à son attaque et les réponses associées vers un dossier différent des boites d’envoi et de réception.
• Teams :
  • La lecture et l’envoi de messages via Teams (Microsoft Graph Chat.ReadWrite) est une méthode efficace pour un attaquant d’usurper l’identité d’un utilisateur. Cette méthode peut également être utilisée pour réaliser des attaques de « fraude au président ».
• OneDrive et SharePoint :
  • L’accès en lecture aux fichiers accessibles sur OneDrive et SharePoint (Microsoft Graph Files.Read.All) peut donner accès à l’ensemble des fichiers accessibles par l’utilisateur. De plus, les droits d’accès aux fichiers SharePoint sont souvent stockés avec des droits d’accès permissifs ce qui permet aux attaquants de récupérer un très grand nombre de fichiers. Il n’est pas rare par exemple d’avoir à accès à des scripts ou fichiers de configurations contenant des mots de passe en clair.
  • Par ailleurs, les fonctionnalités de recherche de SharePoint, permettant notamment la lecture et l’indexation du contenu des fichiers Office, peuvent être utilisées afin de cibler certains mots clés tels que « mot de passe ».
  • Les droits d’écriture sur un fichier SharePoint (Microsoft Graph Files.ReadWrite.All) peuvent également avoir un impact important : les fonctionnalités de versioning de SharePoint limitent par défaut l’enregistrement des anciennes versions des fichiers à 100 versions. Cela signifie qu’en cas de réécritures automatisées et successives plus de 100 fois, la version initiale du fichier ne serait plus récupérable. Cela permettrait donc à un attaquant d’effacer un grand nombre de données en cas de compromission d’un compte disposant de droits d’écriture sur des fichiers sensibles. En cas d’effacement, il faudrait alors contacter le support Microsoft pour tenter de récupérer les données sur les sauvegardes quotidiennes à froid.
• OneNote :
  • Les fichiers OneNote synchronisés (Microsoft Graph Notes.ReadWrite ou Read.All) peuvent contenir des informations sensibles tels que des comptes-rendus de réunion, confidentielles, mais aussi des informations techniques telles que des mots de passes stockés de manière non sécurisée.
• Ressources Azure :
  • L’accès aux key vaults et storage accounts (Azure Key Vault et Azure Storage user_impersonation) peuvent donner accès à des éléments sensibles en cas de compromission de comptes de développeurs ou d’utilisateurs techniques. Ces éléments peuvent faciliter la compromission de ressources Azure telles que des machines virtuelles et servir de point de rebond pour un attaquant externe.

 

Ces actions peuvent avoir de graves impacts pour une entreprise. Par ailleurs, elles peuvent faciliter la réalisation d’attaques plus élaborées en divulguant des informations sensibles à un attaquant externe.

En cas d’approbation par un administrateur, des permissions plus sensibles peuvent être récupérées comme l’accès en écriture à l’ensemble des informations de l’annuaire Azure Active Directory.

Enfin, les administrateurs disposent du droit de déléguer à une application les permissions de tous les utilisateurs du tenant. Dans cette éventualité, l’identité de l’ensemble des utilisateurs pourraient être usurpée pour la permission déléguée.

 

La mise en place par Microsoft du « risk-based consent step up » pour limiter les attaques par consentement illicite

Face à cette menace Microsoft a implémenté en novembre 2020 des protections supplémentaires pour limiter l’impact de ce type d’attaques. La fonctionnalité de « risk-based consent step up » a pour objectif de lever un avertissement et de demander la validation d’un administrateur en cas de demande de permission semblant frauduleuse.

La demande d’accès depuis une application non vérifiée de droits considérés comme sensible est bloquée par défaut

Celle-ci s’applique dans le cas d’une demande de permissions par une application non vérifiée crée hors du tenant ciblée. Par défaut, toutes les permissions sont concernées, à l’exception de la lecture du profil de l’utilisateur cible, pour faciliter l’authentification unique (SSO) avec des applications tierces.

Cette restriction est implémentée par défaut sur tous les tenants Azure.

Si ces restrictions permettent de limiter les attaques, 3 types d’applications sont cependant toujours utilisables à des fins malveillantes : les applications « legacy », les applications internes au tenant ciblé et les applications vérifiées.

• Applications « legacy » :
  • Afin de permettre une rétrocompatibilité, aucun message d’avertissement n’est affiché pour une demande de permissions provenant d’une application créée avant novembre 2020.
  • Prérequis pour l’attaquant : disposer d’une application créée sur un tenant Azure avant novembre 2020 ou compromettre un tenant contenant de telles applications.
• Applications internes au tenant ciblé :
  • Ces applications ne sont pas couvertes par le « risk based consent step up ». Par défaut, tous les utilisateurs d’un tenant Azure disposent du droit de création d’une application d’entreprise sur leur tenant ce qui facilite la réalisation de l’attaque sur un environnement non durci.
  • Prérequis pour l’attaquant : disposer d’un premier compte compromis sur le SI de l’entreprise ciblée, s’apercevoir que la création des applications est autorisée pour les utilisateurs standards et déployer une application interne au tenant.
• Applications vérifiées :
  • Les applications vérifiées ne sont pas couvertes par le « risk based consent step up ». La procédure de vérification de Microsoft nécessite d’intégrer le Microsoft Partner Network.
  • Prérequis pour l’attaquant : disposer d’une application vérifiée ou compromettre un tenant Azure disposant d’applications vérifiées et détourner l’utilisation de ces applications légitimes.

 

Remédiations possibles

Afin de limiter la probabilité et l’impact de telles attaques, les recommandations suivantes peuvent être appliquées et adaptées au contexte de l’entreprise :

• Autoriser uniquement les applications explicitement approuvées par les administrateurs. Cette configuration est la plus sécurisée, mais l’étape de validation peut constituer un goulot d’étranglement puisque ce sont généralement les Global Administrators et Privileged Role Administrators qui doivent faire la validation. En pratique, certains droits peuvent être aussi délégués via les Cloud Application Administrators ou les Application Administrators.

Le consentement de délégation de privilèges par les utilisateurs standards peut être bloqué via les configurations Azure AD

• Limiter les permissions pour lesquelles les délégations peuvent être réalisées. Un administrateur peut spécifier les permissions à faible risque (Low) pour lesquelles les délégations peuvent être directement faites par les utilisateurs.

Le consentement de délégation de privilèges par les utilisateurs standards peut être limité aux droits considérés non sensibles via les configurations Azure AD

• Créer un processus de validation des applications légitimes et de admin consent workflow pour tracer et justifier ces validations. En durcissant les modalités d’octroi de consentements, il est nécessaire de conjointement mettre en place un manière simple et intuitive pour les utilisateurs de demander des dérogations pour déléguer des permissions liées à des cas d’usage légitimes. Ces exceptions doivent être tracées et justifiées afin de s’assurer de la légitimité des demandes.
• Faire une revue régulière des droits délégués aux applications (Entreprise applications) : les permissions déléguées par les utilisateurs doivent être revues afin de s’assurer que seules des applications légitimes disposent de droits sur les ressources Office 365 du tenant.

La revue régulière des applications disposant de droits sur un tenant Azure permet de valider que les privilèges octroyés sont toujours d’actualité

• Superviser les accès suspects aux ressources Office 365. Il est possible par exemple de mettre en place des règles d’alerte sur le nombre de fichiers téléchargés sur un temps court afin d’identifier les tentatives d’exfiltration de données.
• Limiter les droits d’accès aux fichiers SharePoint au strict nécessaire: les fichiers accessibles à tous les utilisateurs d’un tenant doivent être vérifiés à intervalle régulier et les droits d’accès aux fichiers les plus sensibles doivent être revus pour s’assurer que seules les personnes nécessaires y ont accès.

 

 

Conclusion

Les différentes attaques par phishing présentées dans cet article reposent sur un manque de durcissement des configurations Azure AD. La mise en place d’un second facteur d’authentification, bien que nécessaire face aux attaques par phishing traditionnelles, n’est pas suffisante pour se prémunir des autres attaques présentées. Pour les attaques via l’authentification « device code », les administrateurs peuvent mettre en place des politiques d’accès conditionnel pour limiter les connexions suspicieuses provenant d’appareil non maitrisés par l’entreprise. Pour les attaques par consentement illicite, la mesure la plus efficace consiste à autoriser uniquement les applications approuvées par les administrateurs.

Ces trois éléments de durcissement, bien que simples en apparence, peuvent faire l’objet de véritables chantiers de sécurisation afin de prendre en compte l’historique, notamment en s’assurant que les applications existantes ne soient pas bloquées par ces mesures, et en implémentant des processus de revues régulières et de validation des nouvelles applications.

 

 

Bibliographie

https://aadinternals.com/post/phishing/

https://jeffreyappel.nl/protect-against-oauth-consent-phishing-attempts-illicit-consent-attack/

https://positivethinking.tech/insights/what-is-an-illicit-consent-grant-attack-in-office-365/

https://docs.microsoft.com/en-us/azure/active-directory/develop/publisher-verification-overview

https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/user-admin-consent-overview

https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-app-consent

https://www.microsoft.com/en-us/security/blog/2021/07/14/microsoft-delivers-comprehensive-solution-to-battle-rise-in-consent-phishing-emails

[1] https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code