In 2025, the most devastating breaches against Microsoft 365 tenants are rarely the result of a sophisticated zero-day exploit. They are the direct result of a handful of common, well-understood misconfigurations that provide attackers with a clear path from initial access to total domain compromise. While Microsoft’s documentation is exhaustive, it lacks a critical focus: how attackers chain these misconfigurations together into a kill-chain.
As a cloud security architect who has responded to dozens of M365 breaches, I’ve seen the same attack paths exploited time and time again. These aren’t secrets; they are fundamental security gaps that persist in enterprise environments due to a lack of proactive, attack-path-focused auditing.
“Attackers don’t see a list of security settings; they see a series of open doors. A successful defense requires you to see your environment through their eyes, identify the path they will take, and lock the doors in their path before they even begin their approach.”
Kill-Chain Stage 1: Initial Access via Legacy Authentication
Every sophisticated attack begins with a foothold. In Microsoft 365, the most reliable and commonly exploited entry point is legacy authentication.
The Misconfiguration: Legacy authentication protocols (like POP3, IMAP, and SMTP) are enabled on the tenant.
The Attacker’s View: These older protocols do not support or enforce modern multi-factor authentication (MFA). This makes them the perfect backdoor. An attacker who has acquired a user’s password—through a phishing campaign or credential stuffing—can use a legacy protocol to connect to that user’s mailbox, completely bypassing any Conditional Access policies or MFA requirements you have in place. They don’t need a session token; they just need a valid password. Microsoft reports that over 99.9% of compromised accounts did not have MFA enabled or were compromised via legacy auth where it couldn’t be enforced.
The Impact:
- MFA Bypass: The attacker gains initial access to a user’s mailbox despite your MFA policy.
- Undetected Presence: The attacker can now set up malicious inbox rules (like auto-forwarding) to silently exfiltrate data or delete security warnings before the user ever sees them.
- Reconnaissance: From inside the mailbox, the attacker can analyze the user’s emails and contacts to prepare for the next stage of the attack: lateral movement and privilege escalation.
The Remediation: Block Legacy Authentication Tenant-Wide
By executing this first remediation, you have eliminated the attacker’s most reliable and dangerous entry point. You have forced them to contend with modern authentication and MFA, significantly increasing the difficulty of their initial attack.
Architect’s Note: An attacker who has gained initial access is on a clock. Their goal is to escalate privileges as quickly and quietly as possible to achieve persistence and control. The next two misconfigurations are the primary pathways they exploit to turn a single compromised user account into a tenant-wide threat. Our job is to close these pathways.
However, a determined attacker will still get in, often by targeting a user with a sophisticated phishing attack to steal their session token. Once they have that initial foothold, their next objective is Privilege Escalation. This section details the two most common misconfigurations that allow them to achieve it.
Kill-Chain Stage 2: Privilege Escalation via Over-Permissive Admin Roles
An attacker’s first action inside your tenant is to discover if the compromised user has any elevated privileges. Many organizations, for the sake of convenience, leave users with standing, high-privilege roles long after they are needed, or assign roles that are far too permissive for the user’s actual job function.
The Misconfiguration: Excessive “standing access” for administrative roles, especially the Global Administrator role.
The Attacker’s View: Compromising a standard user account is good, but compromising a Global Administrator is “game over.” Attackers use their initial foothold to enumerate the membership of privileged roles. If they find the compromised user is a Global Admin—or can compromise a Global Admin account through lateral movement—they have won. They can now create other admin accounts, assign themselves any permission, disable security alerts, and erase their tracks. Shockingly, CoreView research found that as many as 36% of M365 admins have used Global Admin privileges for routine tasks, indicating a widespread over-provisioning of this role.
The Remediation: Enforce Just-in-Time (JIT) Access with Privileged Identity Management (PIM)
The principle of least privilege dictates that users should only have the permissions they need, for as long as they need them. Standing admin access violates this principle. The solution is to use Microsoft Entra Privileged Identity Management (PIM).
| Step | Action | Admin Center & Rationale |
|---|---|---|
| 1. Discover Privileged Roles | In the Entra admin center, navigate to PIM and run a discovery and assessment of your privileged roles. Identify all users with standing access to high-impact roles like Global Administrator, Application Administrator, and Exchange Administrator. | Microsoft Entra admin center > Identity Governance > Privileged Identity Management. Your goal is to move all users from “Active” assignments to “Eligible” assignments. |
| 2. Onboard Roles to PIM | Onboard all critical administrative roles to be managed by PIM. | This places the roles under PIM’s governance, allowing you to enforce JIT policies. |
| 3. Configure JIT Activation | For each role, configure the activation settings. Require users to provide a justification, receive approval from a designated approver, and/or complete an MFA challenge upon activation. Set a maximum activation duration (e.g., 4 hours). | This ensures that privileged access is temporary, audited, and requires a specific business reason. It eliminates the problem of forgotten, standing admin accounts. |
| 4. Conduct Access Reviews | Schedule regular (quarterly) access reviews for all privileged roles. This forces role owners or security managers to re-certify that each user’s eligibility for a role is still required. | This process prunes unnecessary permissions over time and defends against “privilege creep.” |
Kill-Chain Stage 3: Persistence via Illicit Application Consent
If an attacker cannot find an over-privileged user, their next move is to create their own privileged entity: a malicious Enterprise Application (Service Principal).
The Misconfiguration: Users are permitted to consent to applications requesting high-impact permissions, or admin consent workflows are not properly configured.
The Attacker’s View: This is a highly effective and stealthy attack. The attacker creates an application in their own Azure tenant, then crafts a phishing link that tricks a user (ideally an admin) into “consenting” to give that application permissions in your tenant. If a user consents to an application requesting permissions like Mail.ReadWrite.All or Files.ReadWrite.All, the attacker now has persistent, API-based access to your data that does not require a user account and will not be terminated if the user changes their password. Recent research shows that even roles like Application Administrator can be used to hijack service principals and escalate to Global Admin.
The Remediation: Lock Down Application Consent
You must prevent users from being able to grant dangerous permissions to unknown applications.
| Step | Action | Admin Center & Rationale |
|---|---|---|
| 1. Configure User Consent Settings | Navigate to the “Consent and permissions” settings and select “Do not allow user consent.” | Microsoft Entra admin center > Identity > Applications > Enterprise applications > Consent and permissions. This is the most secure setting, forcing all application consent requests to go through a formal review process. |
| 2. Enable the Admin Consent Workflow | Turn ON the admin consent workflow. Designate a specific group of reviewers (e.g., your security team) to receive and approve/deny these requests. | This ensures that no application gains access to your tenant’s data without being vetted by a security professional who can analyze the requested permissions. |
| 3. Audit Existing Consents | Regularly review the permissions granted to all existing applications in your tenant. Look for applications with overly broad permissions, especially high-impact delegated or application permissions like User.ReadWrite.All or Directory.ReadWrite.All. Revoke unnecessary permissions. | This is a critical housekeeping task to find and remove potentially malicious applications that were consented to before these new controls were put in place. |
By implementing JIT access with PIM and locking down application consent, you have severely handicapped an attacker’s ability to escalate their privileges and establish a persistent foothold in your environment. They are now forced to operate with the limited permissions of the initially compromised user, making their actions easier to detect and contain.
Architect’s Note: An attacker with privileged access will not remain idle. Their final objective is to access and exfiltrate sensitive data. The last two misconfigurations are the wide-open doors that allow them to achieve this objective at scale. By closing these doors, you complete the kill-chain defense, making data exfiltration a difficult, noisy, and high-risk operation for the adversary.
Now, we focus on protecting the crown jewels: your data. This final section details the misconfigurations that enable mass data exposure and exfiltration, and provides the remediation steps to lock down your SharePoint, OneDrive, and Teams environments.
Kill-Chain Stage 4: Data Access via Insecure Sharing
An attacker with access—even to a standard user account—will immediately begin to enumerate SharePoint sites and Teams channels to find sensitive data. Overly permissive default sharing settings are the most common way they find and access data far beyond the scope of their compromised account.
The Misconfiguration: Default sharing settings for SharePoint and OneDrive are set to “Anyone with the link,” allowing for anonymous and unauthenticated access.
The Attacker’s View: This is a goldmine. The default “Anyone” link is the most permissive setting available. An attacker who compromises a single user can then search that user’s SharePoint and Teams access for files shared with these anonymous links. They can then access these links from outside your tenant, completely anonymously, and exfiltrate huge volumes of data without ever authenticating again. This activity is extremely difficult to trace back to the attacker because the access logs simply show an anonymous user.
The Remediation: Enforce Authenticated and Restricted Sharing
You must change the default sharing behavior to be more restrictive, forcing users to make a conscious choice to share something insecurely.
| Step | Action | Admin Center & Rationale |
|---|---|---|
| 1. Set a More Restrictive Default | In the SharePoint admin center, under “Policies” -> “Sharing,” drag the sliders for both SharePoint and OneDrive to “New and existing guests.” | SharePoint admin center. This changes the default sharing link type from “Anyone” to “Specific people.” A user can still choose to create an “Anyone” link, but it is no longer the default, which dramatically reduces accidental oversharing. |
| 2. Limit “Anyone” Links | Check the box for “Limit ‘Anyone’ link expiration” and set a reasonable value, such as 30 days. Also, set the permissions for these links to “View” only. | This ensures that even if a user creates an anonymous link, it is short-lived and read-only by default, limiting the window of opportunity for an attacker. |
| 3. Block “Anyone” Links for Sensitive Sites | For SharePoint sites that you know contain sensitive data (e.g., HR, Finance, Legal), you can edit the sharing settings for that specific site and disable “Anyone” links entirely. | This provides a granular level of control, allowing for collaboration on non-sensitive sites while enforcing strict security on the ones that matter most. |
Kill-Chain Stage 5: Data Exfiltration via Unrestricted Outbound Sharing & Third-Party Apps
The final action on objective for an attacker is to get the data out of your tenant. There are two primary paths they exploit.
Misconfiguration A: No restrictions on external domain sharing or auto-forwarding rules.
Misconfiguration B: Unmonitored installation of third-party apps in Microsoft Teams.
The Attacker’s View:
- A (Unrestricted Sharing): An attacker with control of a mailbox can set up an auto-forwarding rule to their own external Gmail account, silently exfiltrating every email the user receives. Alternatively, they can simply share sensitive files from SharePoint directly to their external email address.
- B (Teams Apps): Attackers have begun using malicious Teams apps as a data exfiltration channel. By tricking a user into installing a seemingly harmless third-party app (e.g., a “productivity” tool), they can use that app’s permissions to siphon data from Teams channels and chats to an external server.
The Remediation: Block Unauthorized Egress Paths
| Step | Action | Admin Center & Rationale |
|---|---|---|
| 1. Block Email Auto-Forwarding | In the Exchange admin center, create a mail flow rule that blocks any message that is auto-forwarded to an external domain. | Exchange admin center > Mail flow > Rules. This is a critical control to prevent silent data exfiltration from compromised mailboxes. You can create exceptions for legitimate business cases if necessary. |
| 2. Restrict Domain Sharing | In the SharePoint admin center, under “Sharing,” you can configure an allow-list or a block-list for external domains. At a minimum, you should block sharing to known personal email domains (gmail.com, outlook.com, etc.). | This forces users to share only with approved business partners, preventing accidental or malicious sharing to personal accounts. |
| 3. Block Third-Party Teams Apps | In the Teams admin center, under “Teams apps” -> “Manage apps,” you can set the default org-wide setting to “Block all third-party apps.” | Teams admin center. You can then create a policy to explicitly allow specific, vetted applications for certain users. This “default deny” posture prevents users from installing potentially malicious or data-leaking applications. |
Conclusion: Breaking the Chain
By systematically auditing and remediating these five common misconfigurations, you have effectively broken the attacker’s kill-chain.
- You blocked their easiest entry point (Legacy Authentication).
- You removed their paths to power (PIM for Admin Roles and Admin Consent for Apps).
- You secured your data at rest (Restricted Sharing Links).
- You blocked their easiest exit routes (Egress Controls).
A well-configured Microsoft 365 tenant is a formidable defensive platform. The key is to move beyond default settings and adopt an attack-path-focused security posture. This proactive, continuous auditing and hardening is the foundation of a modern, resilient enterprise security strategy.
The Microsoft 365 Misconfiguration Kill-Chain: The FAQ
Initial Access & Authentication
- What is legacy authentication?
It refers to older authentication protocols like POP3, IMAP, and SMTP that many email clients use. Crucially, these protocols do not support modern multi-factor authentication (MFA).abnormal - Why is leaving legacy authentication enabled so dangerous?
Because it provides a backdoor for attackers to bypass MFA. If an attacker has a user’s password, they can use a legacy protocol to access the user’s mailbox without ever being prompted for a second factor.nudgesecurity - How can I check if legacy authentication is being used in my tenant?
In the Microsoft Entra admin center, review the Sign-in logs and filter by the “Client app” column. This will show you all authentication attempts and which protocol was used.coreview - Is simply enabling Security Defaults enough to block legacy authentication?
Security Defaults will block legacy authentication, but they are a blunt instrument. Modern best practice is to disable Security Defaults and create a specific, targeted Conditional Access policy to block legacy protocols, which provides more granular control and better auditing.coreview - I have a legacy application that requires SMTP. What should I do?
You should create a specific Conditional Access policy that excludes the single service account for that application from the legacy auth blocking rule. This account should have a very strong, complex password and its sign-in logs should be monitored closely. The long-term goal should be to migrate away from that application. - Will blocking legacy auth impact Outlook or other modern clients?
No. Modern Microsoft clients (Outlook 2016 and later, Teams, etc.) all use Modern Authentication, which is not affected by this change.
Privilege Escalation & Admin Roles
- What is “standing access”?
It’s when a user has administrative permissions assigned to their account permanently. This is a major risk because if that user’s account is compromised, the attacker immediately has full admin rights.coreview - What is the Principle of Least Privilege?
It’s a security concept dictating that a user should only be granted the absolute minimum permissions required to perform their job function, and no more.gitprotect - What is Privileged Identity Management (PIM)?
PIM is a Microsoft Entra ID service that enables you to manage, control, and monitor access to important resources. Its key feature is providing “Just-in-Time” (JIT) privileged access, where users must request temporary elevation to an admin role.coreview - What’s the difference between an “Active” and “Eligible” role assignment in PIM?
An “Active” assignment is standing access—the user always has the permissions. An “Eligible” assignment means the user is allowed to request temporary access to the role through the PIM activation process. The goal is to make all high-impact roles “Eligible.”gitprotect - How many Global Administrators should my organization have?
As few as possible. Best practice is to have between two and four designated Global Admin accounts. These should be “break-glass” accounts that are not used for daily tasks. All other administrators should use lower-privilege roles (like User Administrator or Exchange Administrator).learn.microsoft - What is an “illicit consent” attack?
It’s a phishing attack where the goal isn’t to steal a password, but to trick a user into granting permissions to a malicious third-party application. This application then has persistent, API-based access to the user’s (or the tenant’s) data.coreview - Why is application consent so dangerous?
Because if a user grants a malicious app high-level permissions likeMail.ReadWrite.All, the attacker can read and send emails as that user, even if the user changes their password. The permissions were granted to the app, not the user session.coreview - How do I prevent illicit consent attacks?
Configure user consent settings to “Do not allow user consent” and enable the Admin Consent Workflow. This forces all application consent requests to be reviewed and approved by a designated security administrator.plexhosted
Data Access & Exfiltration
- What is the most secure default sharing setting for SharePoint and OneDrive?
“New and existing guests.” This requires the recipient to authenticate with their email address before they can access the file. The default setting of “Anyone with the link” allows for unauthenticated, anonymous access and should be disabled as the default.partnersplus - Can I block anonymous “Anyone” links completely?
Yes. While you can set a more restrictive default for the whole tenant, you can also go to the settings for a specific, highly sensitive SharePoint site and disable the “Anyone” link option for that site entirely. - What is the risk of email auto-forwarding?
If an attacker compromises a mailbox, they can set up a silent auto-forwarding rule to their own external email address. This allows them to exfiltrate a copy of every single email the user receives, including sensitive attachments and communications.abnormal - How do I block external auto-forwarding?
In the Exchange admin center, create a mail flow rule that identifies messages where theX-MS-Exchange-Generated-Message-Sourceheader contains “Auto-Forward” and the recipient is external, then set the action to “Block the message.” - What is a DLP (Data Loss Prevention) policy?
DLP policies automatically identify, monitor, and protect sensitive information across M365. For example, a DLP policy can detect when a user tries to email a list of credit card numbers and automatically block the email.rehmann - Should I allow third-party apps in Microsoft Teams?
You should adopt a “default deny” posture. In the Teams admin center, block all third-party apps by default. Then, create a policy to explicitly allow specific, vetted applications that have a legitimate business need.
General Strategy & Auditing
- What is Microsoft Secure Score?
It’s a tool in the Microsoft 365 Defender portal that measures your organization’s security posture against Microsoft’s recommended best practices. Regularly reviewing your Secure Score and acting on its recommendations is a key part of a good security program.coreview - Is Microsoft 365’s native backup sufficient?
No. Microsoft provides data redundancy (protecting against hardware failure), but not true backup (protecting against ransomware or accidental/malicious deletion). Best practice is to use a third-party cloud-to-cloud backup solution for your M365 data.rehmann - What is the difference between Security Defaults and Conditional Access?
Security Defaults are a basic, on/off set of protections provided by Microsoft. Conditional Access is a much more powerful and granular framework that allows you to create your own “if-then” rules for access control. If you have the required license (Entra ID P1), you should use Conditional Access.coreview - How can I audit for all these misconfigurations?
While you can check each setting manually, there are also specialized third-party tools that can continuously scan your M365 tenant for misconfigurations and provide a centralized dashboard of your security posture. - My users complain that security measures like MFA are inconvenient. What should I do?
Communicate the “why.” Explain that these measures are in place to protect both the company’s data and their own personal information from attack. Frame it as a necessary part of modern business, similar to locking the office door. - What is the attack kill-chain?
It’s a model that describes the stages of a cyberattack, from initial reconnaissance to the final action on objective (like data exfiltration). Understanding the kill-chain allows you to place defensive controls at each stage. - What license do I need for features like PIM and Conditional Access?
These features typically require a Microsoft Entra ID P2 license (formerly Azure AD P2), which is included in bundles like Microsoft 365 E5 or can be purchased as a standalone add-on. - Is it safe to allow guest users in my tenant?
Yes, if managed correctly. Guest access is essential for collaboration. However, you should have a process for regularly reviewing guest accounts and removing any that are no longer needed. - How does an “Assume Breach” mindset change my approach to M365 security?
It means you shift your focus from solely trying to prevent a breach to also ensuring you can quickly detect and respond to one. It emphasizes monitoring, incident response planning, and limiting the blast radius of a potential compromise.microsoft - Of the five misconfigurations, which one should I fix first?
Block legacy authentication. It is the widest and most commonly exploited entry point for attackers and provides the biggest and most immediate improvement to your security posture.
