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.

Cet article SharePoint & App Registrations: A Vector for IT System Compromise and Red Team Feedback est apparu en premier sur RiskInsight.

20 years later… the situation is totally different and security has taken on a whole new dimension in companies. The figures speak for themselves: in France, there is an average of 1 security FTE per 500 to 3,000 employees, with an average of around 1 per 1,000. Some financial players can even reach record ratios of 1 per 200 by integrating the different lines of defence. I’ll let you do the math: this quickly represents several hundred, even thousands of employees! ISSM are therefore now in charge of a plethoric and highly diversified workforce. The historical experts have been joined in recent years by loads of Project Managers, PMO, COO, Program Managers, and even sometimes by specialized buyers and HR, who are gradually learning to work together. Like a sports coach, the CISO now has to deal with such a workforce and find the right organization, the right game system to get results.

NO REVOLUTION, THE FUNCTIONAL SECTOR REMAINS THE NORM

The reasons for reorganizing are always broadly the same: lack of control, a feeling of inefficiency, diffuse responsibilities… and the work involved in reorganizing can seem colossal. This leads some CISO to very quickly consider disruptive solutions, and in particular the idea of grouping all security resources into a single, hierarchical team. Let’s not waste time and let’s be very clear: in 95% of cases, this solution is not chosen. Such a move simply presents too many risks of excluding the security function, which is difficult to reconcile with the need for business proximity for certain activities: support for business projects, raising awareness among specific populations, budget negotiations, etc. The functional channel remains the norm: a central team and relays (local CISO, security correspondents, etc.) spread throughout the organization. However, some industrial players have recently moved towards centralisation, but the move is more motivated by a desire to bring together cybersecurity resources with the security team, which is particularly mature in this sector.

The attachment of the CISO also remains an element of debate, which has been widely relayed and commented on for years. CIO, Risk Management, Financial Management, CEO… it sometimes seems as if it’s a race to see who will be the highest in the hierarchy! But contrary to popular belief, there is not necessarily a trend in the field towards the exit of the IT department. Quite the contrary: 3 out of 4 CISO report to the CIO in large companies and most reorganizations lead to such an affiliation. The reason is simple: it is often an excellent place to be in action, to make progress on issues and to obtain a budget! Warning: for those who decide to be attached to a different department, remember that 80% of a cybersecurity budget falls within the scope of the IT department. It is therefore essential to nurture a quality relationship between the CISO and the CIO. I have witnessed a few power struggles in recent years, and it is rarely the CISO who wins

That’s it… we’ve got the basic principles: a functional network, often attached to the CIO, with CISO in the company’s main areas of activity. The task now is to distribute all the cybersecurity activities within this organization, and there are many of them: policies, studies, awareness-raising, the Cybersecurity Program, project support, audits, SOC, CERT, etc.

BREAKING DOWN SILOS AND SEEKING OPERATIONAL EFFICIENCY

As a service provider, I can testify to this: it is quite common to be solicited several times for the same study within a Key Account, in several different entities. This is quite understandable: in a pipeline model, each entity/country has a safety team, and without clearly established rules of the game, local management often has the reflex to reinforce its team at the slightest need (specific study, audit results, etc.). This is the whole trap of a sector: it has many advantages but creates complexity and redundancies. And believe me, when the Group CISO finds himself explaining to top management why the company has 3 SOC and 4 incident response units… it’s rarely the best meeting of the day ;-).

In order to avoid such situations, the trend is towards the pooling of expertise and the creation of central cybersecurity service offerings. In very concrete terms, this means that many organizations are pooling 1. cybersecurity expertise (studies, innovation, awareness-raising, etc.) 2. Detection and response (SOC, CERT, crisis exercises, Threat Intel, etc.) 3. Audits and controls (slopes, redteam, code analysis, etc.) 4. Project management and PMO (reporting, PMO, communication…). Add a governance and strategy entity, and you are not far from getting the organization chart of many Group CISO! Note that there are alternatives: some organisations opt for a distributed model, consisting of distributing services across entities (for example: the USA is now in charge of the intrusion test service for the entire company), and very large companies often opt for the creation of intermediate Hubs (by region, by business line…) delivering these services. Regardless of the organisation chosen, this consolidation movement is underway: it is estimated that around 40% of the sector’s employees work on activities with a cross-functional scope… and the increase has been exponential in recent years.

This move towards centralisation frees up local teams (CISO or business/country/entity correspondents) who can thus consume services and refocus on activities requiring close proximity to their businesses: risk assessment, integration of security in projects, security revenues, etc. In the security sectors, this is where we still find the bulk of the workforce (easily 30 to 40%)… but this situation is very probably temporary! The widespread use of agile technology has a direct impact on these teams, who find themselves changing jobs from one day to the next because they are projected into the Feature Teams to train, coach and equip “Security Champions” who are gradually gaining in autonomy. Result: local CISO are also industrializing and organizing their teams into service centers for these Feature Teams (development standards, code review, analysis methods…) Follow my eye: the spectre of a single, centralized security team is likely to resurface quite quickly in the debates… and it is the agile transformation that accelerates the process!

IT IS NOW POSSIBLE TO MAKE A CAREER IN A SAFETY FIELD

We have widely commented on this: some security channels have gone from a few dozen people to several hundred or even thousands in the space of a few years. Of course, this requires a bit of organisation… but it is also a great opportunity for all the employees in the sector! Project management, team management, expertise, communication… very few sectors offer such diversity, and the situation is ideal for attracting and retaining talent. I can only recommend that you take advantage of a cyber-security reorganization to highlight this wealth and work on skills management: salary alignment, re/up-skilling, training/certification plans, individual responsibilities, mobility processes… there are many topics to be addressed to boost well-being and enable employees to build a full and rewarding career within the industry!

Cet article Organize or reorganize the security sector of a large company – Feedback est apparu en premier sur RiskInsight.