Par défaut sous-estimées par les équipes techniques internes et de défense, souvent sur-privilégiées, les App registrations peuvent permettre des pivots puissants suite à la compromission de l’environnement cloud.

Parmi les services les plus exposés, Microsoft SharePoint se distingue. Présent sur la majorité des tenants M365, souvent configuré de manière permissive, il offre un accès aux fichiers de l’entreprise via SharePoint et des collaborateurs au travers de OneDrive.

Cet article revient sur plusieurs constats observés en opération Red Team : comment une simple App Registration, liée de près ou de loin à SharePoint, peut offrir un accès élargi à votre SI on-premise, et comment l’exploitation de ce maillon faible permet parfois de faire de votre segmentation en Tiers une simple formalité pour l’attaquant.

Introduction aux App Registrations

Dans Microsoft Azure, l’enregistrement d’une application (App Registration) dans Entra ID permet de créer une identité pour cette application, ainsi qu’une Enterprise Application associée. L’App Registration définit l’application (identifiants, clés, permissions), tandis que l’Enterprise Application représente son instance dans le tenant, sur laquelle sont appliquées les politiques d’accès (comme l’authentification conditionnelle portée par les politiques d’accès conditionnels ou les rôles attribués).

Une App Registration contient les informations requises pour s’authentifier auprès d’Entra ID et obtenir des jetons d’accès pour interagir avec des services Microsoft 365 via des API comme Microsoft Graph. Selon les permissions qui lui sont accordées (déléguées (scopes) ou applicatives (rôles)) elle peut lire ou modifier des ressources telles que des mails, des fichiers, des utilisateurs ou des groupes tant que l’Enterprise Application est instanciée dans le tenant.

Généralement utilisées pour enregistrer une application visant à automatiser des processus métiers (gestion des utilisateurs, nettoyage de fichiers SharePoint, supervision de l’activité O365…), elles constituent une surface peu surveillée, mais à fort impact.

En effet, les secrets des App Registrations (certificats, client secrets) sont souvent stockés de manière non sécurisée (dans des dépôts de code, postes de travails, serveurs). Ces secrets permettent de personnifier une application avec des privilèges potentiellement élevés (listés dans l’App Registration) entraînant une persistance discrète sur les ressources de l’entreprise.

Pour un attaquant, compromettre une App Registration revient à s’approprier une identité applicative EntraID disposant d’un accès direct à certaines données de l’entreprise, sans nécessiter de rebond par des comptes utilisateurs interactifs ni MFA. Alors que les sécurités se multiplient autour des comptes utilisateurs (MFA obligatoire, accès conditionnel imposant une adresse IP ou un appareil de confiance), il est souvent constaté que celles-ci ne sont pas encore appliquées aux applications.

Se connecter en tant qu’une App Registration

Les applications Azure peuvent s’authentifier auprès d’Entra ID à l’aide de secrets d’application générés dans l’App registration associée :

• AppId + App Secret: Ce moyen d’authentification, équivalent à l’usage d’un nom d’utilisateur et d’un mot de passe est soumis aux mêmes limitations : il est compliqué d’assurer leur protection car ils peuvent facilement se retrouver stockés de manière non sécurisée, exposés dans les historiques de commandes, etc…

• AppId + Certificat: Cette méthode de connexion est davantage sécurisée, puisque les solutions de sécurité installées sur les machines protègent de manière efficace les certificats installés. Néanmoins, celle-ci est généralement moins utilisée en raison des contraintes d’utilisation qu’elle implique, telle que l’installation du certificat sur chaque machine nécessitant l’utilisation du compte.

Les identifiants et secrets d’une application lui permettent de récupérer un jeton d’accès OAuth2, afin de s’authentifier et d’appeler des API Microsoft (Graph, SharePoint, Exchange, etc.) qu’elle est autorisée à contacter. Ce mode de connexion est généralement difficile à détecter si les journaux d’accès ne sont pas activés ni supervisés.

Les droits d’une App Registration

Chaque App Registration définit les permissions API associées à l’application enregistrée. Elles sont décrites sous forme de rôles ou de scopes, sur différents services Microsoft. A titre d’exemples, ces autorisations d’application peuvent permettre de :

• Lire ou modifier des profils utilisateurs (User.ReadWrite.All) ;
• Gérer des objets dans l’annuaire Entra ID (Directory.ReadWrite.All) ;
• Lire, écrire ou supprimer des fichiers SharePoint ou OneDrive (Files.ReadWrite.All) ;
• Lire ou écrire des mails dans toutes les boîtes mails (Mail.ReadWrite) ;
• Etc.

Lors des audits, il est constaté que ces droits sont souvent surdimensionnés par rapport aux besoins réels des applications. Ils peuvent ainsi offrir à un attaquant un levier d’élévation de privilèges majeur s’ils sont récupérés.

D’autre part, un attaquant peut identifier les droits d’une application au travers de l’App Registration associée et compromise en s’authentifiant via l’URL https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token :

Le jeton d’accès obtenu est au format base64, et les droits définis par l’App Registration y sont présents :

Compromission d’App Registrations en opération Red Team

Dans le cadre d’une attaque, il est très fréquent que la compromission s’opère de manière progressive.

Généralement, un premier serveur est compromis, puis un second, etc. jusqu’à atteindre des composants plus critiques de l’infrastructure ou des utilisateurs davantage privilégiés : accès initial, élévation de privilèges, latéralisation, et ainsi de suite.

Ces dernières années, l’implémentation du modèle en Tiers (Tier-0, Tier-1 et Tier-2) au sein des infrastructures Active Directory s’est généralisée, avec par la même occasion une augmentation du niveau de sécurité des SI on-premise. Un nouveau facteur s’est également ajouté avec le développement des agents EDR : la détection !

Dorénavant au sein d’environnements matures, il est plus difficile de compromettre le Tier-0 (contrôleur de domaine, PKI, etc.) par la simple compromission d’un serveur Tier-1, le tout sans se faire détecter par la Blue Team, l’équipe de défense.

Toutefois, au cours de plusieurs opérations au sein d’environnement très variés, SharePoint s’est présenté comme un vecteur d’élévation de privilèges redoutable, et où aucune détection n’a été remontée côté Blue Team.

Plusieurs retours d’expériences d’opérations Red Team illustrant ce propos sont partagés ci-dessous.

Cas n°1 : Administrateur Tier-2 d’un sous-domaine vers la compromission de la forêt Active Directory

Ce cas illustre une opération pour un client international dont le SI se compose de plusieurs milliers de serveurs, qu’il s’agisse de serveurs applicatifs et métiers, industriels, d’infrastructure, etc. La compromission d’un premier serveur a engendré la compromission de comptes administrateurs Tier-1 puis Tier-2.

Dès l’obtention de privilèges d’administration acquis sur des postes de travail (Tier-2), une phase de collecte ciblée s’est amorcée dans le but d’identifier des secrets applicatifs.

Sur plusieurs postes d’utilisateurs à profil technique (équipes DevOps, Cloud, etc.), des scripts PowerShell sont découverts. Certains contiennent des identifiants liés à des App Registrations, avec un AppId, un AppSecret, ainsi que l’identifiant du tenant Azure auquel ils sont associés :

L’exploitation de ces secrets permet à l’attaquant de se connecter directement à la Microsoft Graph API, avec les autorisations déjà consenties définies dans l’App Registration compromise.

L’App Registration identifiée dans ce contexte contient des droits d’application étendus sur O365, notamment :

• User.ReadWrite.All: Lire et modifier tous les profils utilisateurs.
• Directory.Read.All: Lire les données du répertoire.
• Directory.ReadWrite.All: Lire et écrire les données du répertoire.
• Group.ReadWrite.All: Lire et écrire toutes les informations des groupes.
• Files.ReadWrite.All: Lire et écrire tous les fichiers.
• Mail.ReadWrite: Lire, créer, supprimer des mails en toutes les boîtes mails.
• Calendars.ReadWrite: Lire et écrire tous les calendriers.
• Contacts.ReadWrite: Lire et écrire tous les contacts.
• Tasks.ReadWrite: Lire et écrire toutes les tâches.

Parmi cet ensemble de permissions d’application, le droit Files.ReadWrite.All s’avère particulièrement critique et intéressant pour un attaquant, autorisant un accès complet à tous les fichiers stockés sur SharePoint et OneDrive.

Note : Ces permissions peuvent être « déléguées » et dans ce cas ne s’appliquent que dans le contexte de ce que peut faire l’utilisateur.

Un script PowerShell a été développé par l’équipe Red Team Wavestone (SharePwned) afin d’effectuer des recherches sur SharePoint et OneDrive basées sur des mots-clefs, et télécharger les fichiers souhaités.

Par le biais de ce script et via une recherche sur le nom de domaine de la forêt d’administration Active Directory (admin.xx.xxxx.net), plusieurs fichiers ont été identifiés au sein d’espaces OneDrive d’utilisateurs, puis téléchargés :

Ces fichiers, stockés sur l’espace OneDrive d’utilisateurs à privilèges, permettent d’identifier les serveurs de rebond utilisés pour accéder à la forêt Active Directory d’administration du SI.

Le stockage non sécurisé des secrets sur les postes de travail et espaces Cloud représente une faille de sécurité majeure. Pour autant, l’absence de sécurité et de supervision autour de cette App Registration liée à d’importants privilèges représente une vulnérabilité critique dès lors qu’une Enterprise Application associée est instanciée dans le tenant.

Dans le cas présent, la compromission du Tier-2, puis l’accès en lecture aux fichiers stockés sur les espaces OneDrive des collaborateurs a permis d’identifier rapidement les secrets et rebonds réseaux nécessaires à la compromission du Tier-0 de l’entreprise.

Cas n°2 : Accès distant au réseau d’entreprise du Groupe à partir de la compromission d’une filiale

Ce second cas présente une opération Red Team ciblant une entreprise disposant de nombreuses filiales et dont les réseaux ne communiquent pas entre eux.

Tout d’abord, le SI d’une première filiale a été compromis, ainsi que son tenant Azure.

A des fins de persistances et de recherches, une App Registration a alors été créée par la Red Team, tout en ajoutant l’autorisation d’application Files.Read.All.

En téléchargeant les secrets de l’application lors de sa création, il est une nouvelle fois possible d’utiliser l’outil développé par la RT Wavestone pour effectuer des recherches SharePoint et OneDrive :

En effectuant des recherches de mots de passe, des comptes associés à des solutions d’accès distants à l’entreprise cible du Red Team sont identifiés. En effet, certains membres des équipes Finance de la filiale compromise disposent d’accès à la solution de bureau distant du groupe, et stockent leur mot de passe en clair sur leur espace OneDrive.

Bien qu’un MFA soit configuré pour l’ensemble des utilisateurs de cette solution, seule une approbation de la notification est requise, et aucun code n’est demandé. En noyant les utilisateurs de notifications MFA, l’un d’eux a finalement validé l’authentification, permettant aux opérateurs Red Team d’accéder temporairement à la solution de bureau distant.

Finalement, en accédant à l’application de Finance hébergée sur une machine virtuelle Windows, un accès au réseau interne du groupe est récupéré.

Ainsi, à partir d’une compromission de filiale sans interconnexion directe avec le réseau groupe, l’usage d’App Registrations a permis une fois encore de découvrir des secrets et rebondir sur le SI groupe.

Cas n°3 : Compromission de l’EDR déployé sur les contrôleurs de domaine à partir de la chaîne CICD

La compromission de l’environnement CICD du client (hébergé sur AWS) a mené à la compromission de son serveur GitLab. Avec les droits root sur le serveur GitLab, il est possible d’accéder à sa base de données, et aux secrets qui y sont stockés. Bien que ceux-ci soient chiffrés, il est possible de les déchiffrer via la console GitLab Rails.

Parmi ces secrets, des clientID et clientSecrets Azure d’une App Registration sont récupérés. Ces identifiants d’accès permettent de se connecter à Azure sous l’identité de l’application associée, dans le cas présent sous l’identité de l’application GitLab.

Sur le tenant client, l’application GitLab dispose d’un rôle de contributeur sur les ressources d’une souscription Azure. Cela signifie qu’elle peut gérer les accès aux ressources, et en lire le contenu.

Parmi les ressources accessibles, des secrets sont stockés (et accessibles en lecture) dans un coffre-fort Azure Vault. En particulier, des clientId et clientSecret y sont présents :

Une nouvelle application Azure, nommée xxxxx-NettoyageSharePoint, est ainsi obtenue. Celle-ci possède les permissions nécessaires pour lire l’intégralité de SharePoint et OneDrive.

En utilisant une première version de l’outil SharePwned, une recherche de secrets est effectuée au sein des espaces OneDrive des collaborateurs. Des secrets stockés de manière non sécurisée sont découverts dans des fichiers de configuration d’outils d’administration, tels que mRemoteNg. Ces fichiers de configuration contiennent généralement des mots de passe chiffrés avec une clé publique connue. Ainsi, il est possible de les déchiffrer et obtenir les mots de passe en clair des utilisateurs :

Le compte récupéré ici dispose de privilèges d’administration sur l’application IAM de l’entreprise.

Après de multiples recherches de documentations sur SharePoint, toujours en utilisant l’outil SharePwned afin de cibler les recherches, l’équipe Red Team a pu comprendre les moyens d’intervention de l’équipe SOC sur le Système d’Information, les coffres-forts où sont stockés leurs secrets, et les droits nécessaires pour y accéder.

Alors, en utilisant le compte administrateur de l’IAM récupéré dans OneDrive, une attaque se basant sur les procédures d’intervention du SOC a été réalisée pour compromettre intégralement le Système d’Information on-premise du client.

Dans ce cas de figure également, des recherches ciblées sur SharePoint et OneDrive ont permis de récupérer de l’information technique très intéressante pour un attaquant, notamment l’agent EDR déployé sur les DC, les secrets nécessaires à son utilisation, les droits à s’attribuer pour y accéder.

Au-delà des mots de passe récupérés (chiffrés ou non) dans l’ensemble des scénarios précédemment décrits, SharePoint et OneDrive représentent un accès à la connaissance du SI pour l’attaquant. Lorsque l’attaquant se veut discret, il doit reproduire au mieux les flux métiers et d’administrations légitimes de l’entreprise. Le prérequis à cela est tout d’abord de les connaître, pour ensuite les comprendre et les appliquer.

Protéger et détecter les usages malveillants des App Registrations

Comme énoncé précédemment, SharePoint et OneDrive ont permis l’obtention de secrets relativement sensibles et compromettants pour les SI clients. Il reste donc primordial de sensibiliser les collaborateurs au stockage sécurisé des secrets et de les outiller à ces mêmes fins.

Malgré cela, il convient d’appliquer des processus et des mesures de sécurité à ces applications afin de leur faire respecter les principes de moindre privilège et de défense en profondeur. Ci-dessous sont listées des recommandations à appliquer à ces App Registrations.

Revue régulière et principe de moindre privilège

Il convient d’inventorier les applications disposant des permissions sur SharePoint et restreindre ces applications au strict minimum. Les permissions en question sont les suivantes :

• Sites.Read.All;
• Sites.ReadWrite.All;
• Sites.FullControl;
• Files.Read.All;
• Files.ReadWrite.All.

Au même titre que pour les utilisateurs et groupes à privilèges, une revue régulière de ces App Registrations est nécessaire.

Gestion et supervision des secrets

Afin d’éviter que des App Secret ne se retrouvent stockés de manière non sécurisée (au sein de scripts, documentations, mails, etc.), il est recommandé de préférer l’usage de certificats de connexion.

De manière générale, les secrets de connexion doivent faire l’objet d’un renouvellement régulier et automatisé.

La création d’une App Registration génère automatiquement la création d’une Enterprise Application. Lorsque celle-ci se voit attribuer des permissions de lecture sur SharePoint, un consentement de la part d’un Global Administrator est nécessaire. Il n’est ainsi pas trivial pour un attaquant de créer ce type d’applications privilégiées et l’ajout d’un secret à une application existante à privilèges sera souvent préférée par l’attaquant.

Il convient donc de superviser la création de nouveaux secrets de connexion sur les applications à privilèges.

Réduire la surface d’exposition

Enfin, il est recommandé de limiter les capacités d’utilisation de ces applications. Il peut s’agir de restrictions sur l’adresse IP source ou encore sur les plages horaires d’utilisation de l’application.

Note : Il n’est pas toujours nécessaire d’appliquer ces mesures en mode « bloquant ». En effet, une détection sans blocage peut déjà permettre à la Blue Team de prendre connaissance de l’attaque et amorcer sa réponse.

Cet article SharePoint & App Registrations : Vecteur de compromission du SI et RETEX Red Team est apparu en premier sur RiskInsight.