Contributors: Vasil Michev, Sharon Breeze, Terence Jackson, Rob Edmondson
Once an attacker has gained entry into your M365 tenant, they use a variety of tactics to elevate their privileges and permissions so they can more easily execute their objectives.
In this article, you’ll learn how to:
Executive Summary
Elevation of privilege (EoP) attacks in Microsoft tenants often start with something small (e.g. an over-permissioned user, a neglected service account, or a poorly secured app). But once inside, attackers move fast. They escalate access using token theft, consent phishing, and lateral movement. Common weak spots include excessive admin roles, legacy protocols, and misconfigured app registrations. To cut off these paths, CoreView can help you audit Entra ID roles regularly, remove standing privileges, and enforce just-in-time access as well as disable legacy auth where possible and lock down external sharing. Without tight controls, one compromised identity can lead to full tenant exposure.
Free Microsoft 365 Security Resource: Anatomy of a Microsoft 365 Attack
For organizations looking to make improvements to their security protocols fast, download the Anatomy of a Microsoft 365 Attack.
This report takes a deeper look at attack vectors used by cybercriminals and provides best practices to secure your tenant, offering insights to strengthen your security posture against cyberattacks.
The Dangers of Privilege Elevation in Microsoft 365
Gaining entry to Microsoft 365 is one thing. But, without the right privileges, attackers can’t cause much damage to your cloud environment. That’s why cybercriminals are coming up with increasingly sophisticated methods to elevate their access permissions during an attack.
For example, Semperis researchers recently found out about a new attack that allowed a Microsoft 365 Application Administrator or Cloud Application Administrator to elevate their privileges to Global Administrator by abusing the "Device Registration Service" application in Entra. While it has since been plugged by Microsoft, this vulnerability could have opened the door to a lot of attacks if left unchecked.
In real-world attacks like Midnight Blizzard, privilege escalation happens through familiar paths: overprivileged Entra apps, OAuth consent phishing, and under-governed PowerApps. Attackers often don’t need zero-days—they just need access to one misconfigured service principal or third-party app with excessive Graph permissions.
For the second part in this series, we’ll focus on Privilege Elevation. Once an attacker has gained entry into your M365 tenant, they use a variety of tactics to elevate their privileges and permissions so they can more easily execute their objectives. We’ll break down each such tactic here, along with steps you can take to prevent and detect such actions.
How Attackers Actually Escalate Privileges in M365
Privilege elevation is the act of exploiting bugs, design flaws, or configuration oversights in an operating system or application to gain elevated access to resources that are normally protected from an application or user. The result is that an attacker with limited access can increase their privileges to become an administrator.
In a Microsoft 365 environment, privilege elevation often involves compromising accounts with privileged roles like Global Administrator, Application Administrator, or Exchange Administrator. With these elevated privileges, an attacker can perform malicious actions like:
- Creating new admin accounts to maintain persistence
- Modifying security settings and policies
- Accessing sensitive data across different apps
- Performing phishing campaigns from trusted domains
There are several common techniques attackers use to elevate privileges in Microsoft 365. We’ll break down each of them below.
Attack Vector: Leveraging Copilot for Tenant Reconnaissance
If an attacker compromises a standard user account with a Copilot license, they may be able to use it to quickly find valuable information. As Copilot is rolled out across Microsoft 365, many organizations are becoming aware that they've relied on "security by obscurity" in their cloud environments. Some files and pages have organization-wide sharing settings, meaning any user with Copilot could accidentally stumble on these documents thanks to the enhanced discoverability of generative AI.
However, with Copilot for Microsoft 365, there is also a risk that an attacker accessing a user account with a Copilot license can quickly find important information to plan the next stage of their attack. Copilot's ability to search across email, documents, and collaboration spaces means attackers can use natural language queries to rapidly discover sensitive data, privileged accounts, and key systems.
For example, an attacker could ask Copilot questions like:
- “What are the most important projects the company is working on?”
- “Who are the administrators for our Azure environment?”
- “Where are passwords stored and how can I access them?”
- “What financial data do we have access to?”
By using Copilot's powerful search and summarization capabilities, attackers can significantly reduce the time needed for reconnaissance compared to manually sifting through documents and emails. This allows them to more quickly identify high-value targets and plan their next steps.
Prevention: Limit Copilot’s Data Scope with Sensitivity Labels & RBAC
- Implement lifecycle management to decommission unused SharePoint and Teams environments, reducing the attack surface that must be managed.
- Apply sensitivity labels in Microsoft Purview Information Protection or configure restricted permissions with Information Rights Management (IRM) to restrict what Copilot for Microsoft 365 can access.
- Ensure the principle of least privilege is followed and regularly review permissions. Avoid organization-wide sharing settings.
Detection: Audit Copilot Prompt Logs and Unusual Data Requests
- Create reports to get visibility of who uses Copilot and monitor for anomalous usage patterns.
- Prevent users from deleting their Copilot prompt history so a record exists of what queries were made.
- Monitor Microsoft 365 audit logs for suspicious Copilot activity originating from unexpected accounts or locations.
- Use a Cloud Access Security Broker (CASB) or Microsoft Defender for Cloud Apps to detect when sensitive data is being accessed by Copilot.
Attack Vector: Entra ID Application Registration Abuse
Creating Malicious Entra Apps with Excessive Permissions
When a user creates an application in Entra, it can easily be granted excessive permissions like the ability to fetch information about users in the directory, erasing messages from mailboxes, and sending emails. Finding or creating an application with these privileges can give an attacker an easy pathway to elevate their own access. This is the method that was used in the Midnight Blizzard Attack.
Attackers look for applications with overly broad permissions that they can abuse. For example, an app with delegated permissions like Mail.ReadWrite, Mail.Send, User.Read.All, and Directory.Read.All would allow an attacker to read and send email on behalf of users and access sensitive directory data.
If an attacker compromises an account with the Application Administrator or Cloud Application Administrator role, they could create a new application and grant it high privileged permissions. These roles have the ability to assign credentials to applications, even if they can't directly elevate their own privileges.
Attackers can also take over existing applications by adding their own credentials. If an application already has dangerous permissions granted, this provides an easy way to gain privileged access without creating suspicious new apps.
Prevention: Enforce Admin Consent & Least-Privilege OAuth Scopes
- Restrict who can create applications by disabling the default ability for all users to register apps. Allow only specific users or groups to have this ability.
- Require admin consent for apps requesting risky permissions. Do not allow users to consent to applications accessing company data on their behalf.
- Apply access reviews to regularly audit which users have the ability to register and manage applications.
- Use Entra governance features like access packages and catalogs to tightly control M365 app registration and assignment.
- Limit app permissions to only what is absolutely needed. Avoid granting broad permissions like Mail.ReadWrite or Directory.ReadWrite.All.
Detection: Alert on New App Registrations and High-Risk API Permissions
- Report on application registrations and the permissions granted to each app. Review for any applications with suspicious permission combinations.
- Monitor for new credential assignments to existing applications, especially for apps with privileged permissions.
- Use a Cloud Access Security Broker (CASB) or Microsoft Defender for Cloud Apps to detect unusual application activity and permission abuse.
- Run CoreView’s Entra Security Scanner to surface risky service principals in seconds.
Finding Third-Party Apps With Excess Permissions
Many third-party applications require Entra permissions for single sign-on and other identity/productivity enhancements. When they request these permissions, users rarely get clear information on what is being requested and why.
For example, research from Adaptive Shield has shown that 67% of third-party apps request permissions that have medium to high levels of associated risk. 15% have privileges to read, create, update, and delete all the files you can access.
Large organizations can sometimes have over 1000 third-party apps connecting to Entra, making this a highly effective target for cyber criminals. Attackers look for third-party apps with excessive permissions that they can abuse to gain unauthorized access to sensitive data and systems.
For example, an app with the Mail.ReadWrite, Files.ReadWrite.All, or Directory.ReadWrite.All permissions could allow an attacker to access and manipulate email, files, and directory objects for the entire organization. Even seemingly benign apps like event management or travel booking tools can request broad permissions during the setup process.
Prevention: Validate Publishers & Block Over-Privileged Integrations
- Put controls in place to prevent third-party apps from being granted dangerous levels of privilege. Use Entra's admin consent workflow to require admin approval for apps requesting risky permissions.
- Apply policy enforcement to detect and remediate dangerous third-party apps. Use Entra's access reviews to regularly audit permissions granted to third-party apps. Remove any apps that no longer need access or have suspicious permission levels.
- Restrict user consent to only allow consenting to apps from verified publishers or with low-risk permissions. Block user consent entirely if your organization doesn't rely on many third-party apps.
Detection: Surface Rare Consent Patterns and Scope Changes
- Report on third-party apps to get visibility into all applications integrated with your Entra environment. Review for any unfamiliar or suspicious apps.
- Report on third-party app permissions to identify apps with high-risk permission levels. Look for permissions like Mail.ReadWrite, Files.ReadWrite.All, Directory.ReadWrite.All, etc.
- Use a Cloud Access Security Broker (CASB) or Microsoft Defender for Cloud Apps to detect unusual application activity and permission abuse.
Attack Vector: OAuth Consent Phishing
OAuth consent phishing skips passwords altogether. Attackers spin up a legitimate-looking app—Adobe, DocuSign, even a fake “Security Alert” tool—and trick one employee into clicking Accept. The moment that user grants dangerous scopes such as Mail.ReadWrite, Files.ReadWrite.All, or offline_access, the attacker receives refresh tokens that work indefinitely, bypass MFA, and blend into normal Microsoft Graph traffic.
Prevention: Require Admin Consent & Scope Hygiene
- Disable blanket user consent; allow it only for low-risk, verified publishers.
- Route all high-risk scopes (anything ending in *.ReadWrite.All or including offline_access) through an admin-approval workflow.
- Audit every enterprise app quarterly and strip permissions the publisher does not explicitly need.
- Train users: “Sign in with Microsoft” is not automatically safe; show live examples of fake consent screens.
Detection: Quarantine Rogue Apps & Anomalous Grants
- Alert on new app registrations or permission changes that request high-risk scopes.
- Use Defender for Cloud Apps (or another CASB) to flag apps that suddenly move large data volumes right after consent.
- Correlate Graph API calls with the authorizing user; unusual patterns (such as a service account reading executive mailboxes) are red flags.
- Auto-revoke tokens for apps that change publisher domain or lose verified status.
Attack Vector: Dark-Web Purchased Global-Admin Credentials
Sometimes attackers don’t steal your creds—they buy them. Dark-web markets routinely auction corporate administrator accounts; domain-admin logins have listed for more than $100K, while lower-tier Microsoft 365 accounts sell for $15–$50. A single compromised Global Admin can create new elevated roles, disable logging, and quietly exfiltrate email or SharePoint data long before ransom demands appear.
Prevention: Harden Privileged Accounts with MFA & PIM
- Move every standing Global Admin into Privileged Identity Management (PIM) and require time-bound activation.
- Enforce phishing-resistant MFA (FIDO2 keys, Windows Hello for Business) plus Conditional Access geo-fencing.
- Rotate admin passwords and application secrets at least quarterly; store them in a vault with check-in/out logging.
- Run quarterly dark-web credential scans and force resets on any match.
Detection: Monitor Marketplaces & Geo-Anomalous Logins
- Subscribe to threat-intel feeds that track credential dumps and auctions tied to your domains.
- Alert on impossible-travel or first-time-seen sign-ins to privileged roles—even if MFA succeeds.
- Enable Entra ID risk policies to force password reset when a login originates from known malicious IP ranges.
- Correlate new privileged-role assignments with simultaneous mailbox exports, eDiscovery pulls, or directory-write operations.
Attack Vector: Power Apps Permission Sprawl
Similar to the issues mentioned above, many organizations have taken advantage of the PowerApps capabilities included in their Microsoft ELA, only to later realize there has been little governance over the creation and management of these apps.
This has led to many teams struggling with PowerApps sprawl, which has also led to permission sprawl.
Often, PowerApps aren't developed according to the principle of least privilege, meaning they sit in the tenant with permissions that could be exploited. Attackers look for PowerApps with excessive permissions that grant access to sensitive data or allow performing high-risk actions.
For example, a PowerApp with the User.Read.All, Mail.ReadWrite, or Files.ReadWrite.All permissions could allow an attacker to access directory data, read and send emails, or modify files across the organization. Even PowerApps intended for a specific business process may request broad permissions that go beyond what is actually needed.
Prevention: Gate Power Apps with DLP Policies and Environment Controls
- Implement an internal governance strategy to manage and oversee PowerApps throughout their lifecycle. Define who can create apps, what environments they should be deployed to, and what the approval process looks like.
- Ensure that security and governance stakeholders have input when PowerApps permissions are being configured. Require justification for any high-risk permission requests.
- Create a process to detect PowerApps with excessive permissions and trigger a remediation process to either decommission the app or reduce the permissions to an appropriate level. Regularly review permissions to ensure they adhere to least privilege.
- Provide training to app creators on how to determine appropriate permission levels and the risks of over-permissioning.
Detection: Flag Apps Accessing Sensitive Dataverse Tables
- Report on PowerApps throughout your tenant to get an inventory of all apps and their creators. Review for any unfamiliar or suspicious apps.
- Report on PowerApp permissions to identify apps requesting high-risk permissions like User.Read.All, Mail.ReadWrite, Files.ReadWrite.All, etc.
- Alert on newly created PowerApps with excessive permissions so they can be reviewed and remediated quickly.
- Use the Power Platform admin center to view PowerApps and their permissions. The Power Platform Management connectors and PowerShell cmdlets can also help automate reporting and alerting.
Attack Vector: Over-Privileged Global Admin & Shadow Admin Accounts
Microsoft 365 has arguably the most powerful privileged account role in an organization: Global Admin. The privileges associated with these accounts are so powerful that they can practically destroy a business under the right circumstances. Microsoft does provide 80 different admin roles that are less privileged, but they are still far too powerful in many circumstances.
Despite the options that Microsoft provides, CoreView research has found that as many as 36% of Microsoft admins have used Global Admin privileges just to stay productive.
This is because administrative teams are forced into choosing between security and productivity when working within Microsoft's native capabilities. Plus in mature organizations, there can be as many as 50 manual steps for onboarding a new user account and another 50 for offboarding.
But compliance mandates like NIST, SOX, NIS, ASD, etc., all require that organizations enforce least privilege, which is especially important for Microsoft 365. In the absence of that, if an attacker gains access to an account with sufficient permissions like Global Administrator or Privileged Role Administrator, they can also create new privileged user accounts to further increase the damage that they can do.
Prevention: Role-Based Access & Time-Bound Privileged Identity Management
- Leverage a solution to delegate "just enough" access to administrators instead of using the overly broad built-in Microsoft 365 admin roles. Implement least privilege and only grant the specific permissions needed.
- Enforce strong credential standards for all Microsoft Online accounts, especially privileged ones. Use long, complex passwords and don't reuse passwords across accounts.
- Enforce MFA and a zero-trust approach for all logins, with the strongest forms of MFA for privileged accounts. Implement Conditional Access policies to limit sign-ins to trusted locations and devices.
- Monitor Entra and Purview Privilege Management for configuration changes to admin roles and privileged group membership. Alert on suspicious additions.
- Automate the user onboarding and offboarding process to avoid misconfigured permissions for users. Ensure a consistent, auditable process is followed.
Detection: Monitor Privileged Role Assignments and Geo-Anomalous Logins
- Monitor Entra and Purview Privilege Management for configuration changes to admin roles and privileged groups. Review any manual additions of members.
- Get alerts for suspicious logins to privileged accounts from unexpected locations, devices, or times. Investigate failed sign-in attempts.
- Review privileged account activity in Microsoft 365 audit logs for unusual actions like mass permission changes, disabling security features, or exfiltrating data.
- You may even consider running a scan of your tenant to see what admins may be over privileged with our Admin Permissions Scanner for Microsoft 365.
Attack Vector: PowerShell Abuse for Lateral Movement
Scripting unlocks huge productivity for administrations, but it also gives attackers a fast way to make progress in your environment.
Adversaries could abuse PowerShell for information gathering and to launch remote scripts on your machines. These may also use it to discover how permissions are configured and where best to focus their attack for privilege elevation.
PowerShell is an extremely versatile tool that can be used by attackers to perform a variety of malicious activities in a Microsoft 365 environment. These include:
- Running commands to gather information about users, groups, permissions, and resources in the tenant
- Using remote PowerShell sessions to move between systems and run commands on other machines
- Exploiting misconfigurations or vulnerabilities to gain higher-level permissions through PowerShell
- Copying sensitive data and sending it to external servers using PowerShell scripts
- Creating backdoors, modifying access controls, and hiding malicious activity with PowerShell
Prevention: Constrain PowerShell with Just-Enough-Admin & Conditional Access
- Use constrained language mode to restrict access to dangerous language elements. This limits PowerShell to core cmdlets and prevents access to .NET Framework APIs, WMI, and COM objects.
- Restrict PowerShell execution to M365 administrators who have a legitimate need. Disable PowerShell for standard users who don't require it.
- Use JEA (Just Enough Administration) to limit the PowerShell commands admins and users can run. This allows providing granular, task-specific access instead of broad permissions.
- Implement network controls to restrict PowerShell Remoting and WinRM access between machines. Segment privileged systems.
Detection: Script-Block Logging and Unusual Runspace Activity Alerts
- Monitor script execution and subsequent behaviors for signs of abuse. Look for scripts running from unusual locations, spawning suspicious processes, or connecting to external servers.
- Monitor log files for process execution, especially PowerShell-related processes like powershell.exe, powershell_ise.exe, and wsmprovhost.exe.
- Enable PowerShell script block logging and transcription to capture detailed logs of all PowerShell activity. Forward these logs to a SIEM for analysis and alerting.
- Use Microsoft Defender for Cloud Apps to monitor for suspicious PowerShell behavior in the Microsoft 365 environment.
Go Deeper: See the Full Microsoft 365 Attack Lifecycle
Privilege elevation is only one chapter in a much longer breach narrative. If you want the complete picture—from the first foothold to long-term persistence—download The Anatomy of a Microsoft 365 Attack. The guide maps every stage of a real-world intrusion, shows where most tenants slip up, and lays out practical counter-moves you can deploy today.
Secure Microsoft 365 at Scale with CoreView
If you want to limit an attacker’s control over your M365 cloud environment during an unforeseen breach, the best way is to start with a foundation of good governance that enforces least privilege principles from the beginning.
For example, with the Functional Access Control (FAC) feature in CoreView, you can implement granular access permissions that go beyond the level of precision possible with Microsoft’s built-in Role-Based Access Control (RBAC). This is just one of many ways that CoreView helps implement better security controls within your Microsoft 365 environment.
Trusted by enterprises like Talan, Mateco, Save the Children, and CUNY, CoreView has a proven track record of securing and governing Microsoft 365 effortlessly. Ready to take control of your Microsoft 365 environment?