While on-premises Active Directory environments are being hardened against threats (tiering model, network segmentation, admin bastions, domain controller hardening), attackers are now exploiting a new component to compromise their targets: cloud resources, particularly App Registrations linked to Microsoft 365 services.
Often underestimated by internal technical and defence teams, and frequently over-privileged, App Registrations can enable powerful pivots following a cloud environment compromise.
Among the most exposed services, Microsoft SharePoint stands out. Present on most M365 tenants and often configured permissively, it provides access to company files via SharePoint and to collaborators files through OneDrive.
This article shares several observations from Red Team operations: how a simple App Registration, loosely or closely linked to SharePoint, can offer broad access to your on-premises IT system, and how exploiting this weak link can render your Tiering segmentation merely symbolic for an attacker.
Introduction to App Registrations
In Microsoft Azure, registering an application (App Registration) in Entra ID allows you to create an identity for that application, along with an associated Enterprise Application. The App Registration defines the application (identifiers, keys, permissions), while the Enterprise Application represents its instance within the tenant, where access policies are applied (such as conditional access policies or assigned roles).
An App Registration contains the necessary information to authenticate to Entra ID and obtain access tokens to interact with Microsoft 365 services via APIs like Microsoft Graph. Depending on the permissions granted – delegated (scopes) or application-level (roles) – it can read or modify resources such as emails, files, users, or groups, as long as the Enterprise Application is instantiated in the tenant.
Typically used to register applications designed to automate business processes (user management, SharePoint file cleanup, O365 activity monitoring, etc.), App Registrations represent a largely unmonitored but high-impact surface.
Indeed, the secrets of App Registrations (certificates, client secrets) are often stored insecurely – in code repositories, workstations, or servers. These secrets allow an application to impersonate itself with potentially elevated privileges (as listed in the App Registration), resulting in stealthy persistence across corporate resources.
For an attacker, compromising an App Registration means acquiring an Entra ID application identity with direct access to certain corporate data – without needing to pivot through interactive user accounts or MFA. While security measures around user accounts are increasing (mandatory MFA, conditional access requiring trusted IPs or devices), these protections are often not yet applied to applications.
Connecting as an App Registration
Azure applications can authenticate with Entra ID using application secrets generated in the associated App Registration:
- AppId + App Secret: This authentication method is equivalent to using a username and password and is subject to the same limitations: it is difficult to ensure their protection, as they can easily be stored insecurely, exposed in command histories, etc.
- AppId + Certificate: This method is more secure, as security solutions installed on machines effectively protect installed certificates. However, it is generally less used due to operational constraints, such as the need to install the certificate on each machine that uses the account.
The application’s credentials and secrets allow it to retrieve an OAuth2 access token, enabling authentication and API calls to Microsoft services (Graph, SharePoint, Exchange, etc.) that it is authorized to contact. This connection method is typically hard to detect if access logs are not enabled or monitored.
App Registration permissions
Each App Registration defines the API permissions associated with the registered application. These are described as roles or scopes across various Microsoft services. For example, application permissions may allow:
- Reading or modifying user profiles (User.ReadWrite.All),
- Managing objects in the Entra ID directory (Directory.ReadWrite.All),
- Reading, writing, or deleting files in SharePoint or OneDrive (Files.ReadWrite.All),
- Reading or writing emails across all mailboxes (Mail.ReadWrite),
- Etc.
During audits, it is observed that these permissions are often oversized compared to the actual needs of the applications. As a result, they can provide attackers with a significant privilege escalation vector if compromised.
Moreover, an attacker can identify an application’s permissions through its associated and compromised App Registration by authenticating via the URL https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token :
The access token obtained is in base64 format, and the permissions defined by the App Registration are embedded within it.
Compromise of App Registrations during Red Team operations
In the context of an attack, it is very common for the compromise to occur progressively. Typically, an initial server is compromised, then a second, and so on, until more critical infrastructure components or more privileged users are reached: initial access, privilege escalation, lateral movement, and so forth.
In recent years, the implementation of the Tier model (Tier-0, Tier-1, and Tier-2) within Active Directory infrastructures has become widespread, resulting in increased security for on-premises IT systems. Another factor has also emerged with the development of EDR agents: detection!
Now, in mature environments, it is much more difficult to compromise Tier-0 (domain controllers, PKI, etc.) simply by compromising a Tier-1 server, all without being detected by the Blue Team (the defence team).
However, during several operations across very diverse environments, SharePoint has proven to be a formidable vector for privilege escalation, and in these cases, no detection was reported by the Blue Team.
Several Red Team operation case studies illustrating this point are shared below.
Case 1: Tier-2 Administrator of a domain leading to the compromise of the Active Directory Forest
This case illustrates an operation for an international client whose IT system includes several thousand servers – application and business servers, industrial systems, infrastructure, etc. The compromise of an initial server led to the compromise of Tier-1 and then Tier-2 administrator accounts.
As soon as administrative privileges were obtained on workstations (Tier-2), a targeted collection phase began with the aim of identifying application secrets.
On several workstations belonging to technical users (DevOps teams, Cloud teams, etc.), PowerShell scripts were discovered. Some of these contained credentials linked to App Registrations, including an AppId, an AppSecret, and the Azure tenant ID to which they were associated:
Exploiting these secrets allows the attacker to connect directly to the Microsoft Graph API, using the permissions already granted in the compromised App Registration.
The App Registration identified in this context had extensive application rights over O365, including:
- User.ReadWrite.All: Read and modify all user profiles.
- Directory.Read.All: Read directory data.
- Directory.ReadWrite.All: Read and write directory data.
- Group.ReadWrite.All: Read and write all group information.
- Files.ReadWrite.All: Read and write all files.
- Mail.ReadWrite: Read, write, update and delete emails in user mailboxes.
- Calendars.ReadWrite: Read and write all calendars.
- Contacts.ReadWrite: Read and write all contacts.
- Tasks.ReadWrite: Read and write all tasks.
Among this set of application permissions, the Files.ReadWrite.All right is particularly critical and attractive for an attacker, as it grants full access to all files stored on SharePoint and OneDrive.
Note: These permissions can be “delegated”, in which case they only apply within the context of what the user can do.
A PowerShell script has been developed by the Wavestone Red Team (SharePwned) to perform keyword-based searches on SharePoint and OneDrive and to download the desired files.
Using this script, and by searching for the name of the Active Directory administration forest (e.g., admin.xx.xxxx.net), several files were identified within users’ OneDrive spaces and subsequently downloaded:
These files, stored in the OneDrive spaces of technical users, made it possible to identify the pivot servers used to access the Active Directory administration forest of the information system.
The insecure secrets storage on workstations and in cloud spaces represent a major security vulnerability. However, the lack of security controls and monitoring around this App Registration – linked to significant privileges – constitutes a critical weakness as soon as an associated Enterprise Application is instantiated in the tenant.
In this case, the Tier-2 compromise, followed by read access to files stored in employees’ OneDrive spaces, quickly enabled the identification of secrets and network pivots necessary to compromise the company’s Tier-0 environment.
Case 2: Remote access to the group’s corporate network following the compromise of a subsidiary
This second case describes a Red Team operation targeting a company with numerous subsidiaries whose networks do not communicate with each other.
First, the IT system of one subsidiary was compromised, along with its Azure tenant.
For persistence and further exploration, the Red Team then created an App Registration, adding the Files.Read.All application permission.
By downloading the application’s secrets at creation, it was once again possible to use the tool developed by the Wavestone Red Team to search SharePoint and OneDrive:
By searching for passwords, accounts associated with remote access solutions to the Red Team’s target company were identified. In fact, some members of the Finance teams in the compromised subsidiary had access to the group’s remote desktop solution and stored their passwords in clear text on their OneDrive.
Although MFA was configured for all users of this solution, only notification approval was required – no code was requested. By flooding users with MFA notifications, one eventually approved the authentication, allowing the Red Team operators temporary access to the remote desktop solution.
Finally, by accessing the Finance application hosted on a Windows virtual machine, access to the group’s internal network was obtained.
Thus, starting from the compromise of a subsidiary with no direct interconnection to the group network, the use of App Registrations once again enabled the discovery of secrets and a pivot into the group’s IT system.
Case 3: Compromise of the EDR deployed on Domain Controller via the CICD pipeline
The compromise of the client’s CICD environment (hosted on AWS) led to the compromise of their GitLab server. With root access to the GitLab server, it was possible to access its database and the secrets stored within. Although these secrets were encrypted, they could be decrypted via the GitLab Rails console.
Among these secrets, Azure clientID and clientSecret for an App Registration were recovered. These credentials allowed access to Azure under the identity of the associated application – in this case, the GitLab application.
On the client’s tenant, the GitLab application had a contributor role on the resources of an Azure subscription. This meant it could manage access to resources and read their contents.
Among the accessible resources, secrets were stored (and readable) in an Azure Key Vault. In particular, clientId and clientSecret values were present:
A new Azure application, named xxxxx-NettoyageSharePoint, was thus obtained. This application had the necessary permissions to read the entirety of SharePoint and OneDrive.
Using an early version of the SharePwned tool, a search for secrets was carried out within employees’ OneDrive spaces. Insecurely stored secrets were discovered in configuration files for administration tools such as mRemoteNg. By default, these configuration files typically contain passwords encrypted with a known public key. As a result, it is possible to decrypt them and obtain users’ passwords in clear text:
The account retrieved here had administrative privileges on the company’s IAM application.
After multiple searches of documentation on SharePoint – still using the SharePwned tool to target the searches – the Red Team was able to understand the SOC team’s intervention methods on the Information System, the vaults where their secrets were stored, and the permissions required to access them.
Then, using the IAM administrator account recovered from OneDrive, an attack was carried out based on the SOC’s intervention procedures, resulting in the complete compromise of the client’s on-premise Information System.
In this scenario as well, targeted searches on SharePoint and OneDrive enabled the retrieval of highly valuable technical information for an attacker, including the EDR agent deployed on the domain controllers, the secrets required for its use, and the permissions needed to access it.
Beyond the passwords recovered (whether encrypted or not) in all the previously described scenarios, SharePoint and OneDrive represent a gateway to knowledge of the Information System for the attacker. When the attacker wishes to remain discreet, they must closely mimic the company’s legitimate business and administrative workflows. The prerequisite for this is first to know them, then to understand and replicate them.
Protect and detect malicious use of App Registrations
As previously mentioned, SharePoint and OneDrive have enabled the retrieval of sensitive and compromising secrets for client information systems. It is therefore essential to raise employee awareness about secure secret storage and to provide them with the necessary tools for this purpose.
Nevertheless, it is important to implement processes and security measures for these applications to ensure compliance with the principles of least privilege and defence in depth. Below are recommendations to apply to these App Registrations.
Regular review and principle of least privilege
It is important to inventory applications with permissions on SharePoint and restrict these applications to the bare minimum. The relevant permissions are:
- Sites.Read.All;
- Sites.ReadWrite.All;
- Sites.FullControl;
- Files.Read.All;
- Files.ReadWrite.All.
As with privileged users and groups, a regular review of these App Registrations is necessary.
Management and monitoring of secrets
To prevent App Secrets from being stored insecurely (in scripts, documentation, emails, etc.), it is recommended to favour the use of connection certificates.
In general, connection secrets should be subject to regular and automated renewal.
Creating an App Registration automatically generates an Enterprise Application. When this is granted read permissions on SharePoint, consent from a Global Administrator is required. As a result, it is not trivial for an attacker to create such privileged applications, and adding a secret to an existing privileged application is often preferred by attackers.
It is therefore important to monitor the creation of new connection secrets on privileged applications.
Reduce the attack surface
Finally, it is recommended to limit the usage capabilities of these applications. This may involve restrictions on source IP addresses or on the time windows during which the application can be used.
Note: It is not always necessary to apply these measures in a “blocking” mode. In fact, detection without blocking can already allow the Blue Team to become aware of an attack and begin their response.
