Microsoft 365 gives organisations extensive controls over identity, authentication, applications, devices, collaboration, and privileged access. The problem is rarely that these controls are missing.
In real-world incident response engagements, Microsoft has observed combinations of misconfigurations, administrative oversights, access-control gaps, and identity weaknesses that can lead to Microsoft Entra ID compromise. That distinction matters. Individual controls can operate exactly as configured. Yet the relationships between identities, applications, devices, permissions, exclusions, and cloud workloads can still form a path an attacker can use.
A configuration review asks whether a setting matches a baseline. A red team asks a different question: what can an attacker actually achieve with the environment as it exists today?
That shift, from reviewing settings individually to testing how they interact, is where Microsoft 365 red teaming becomes valuable.
Executive TL;DR
- Microsoft 365 compromise often results from several legitimate configurations and trust relationships chained together, rather than one obviously broken control.
- Conditional Access can be fully deployed and still contain exclusions, coverage gaps, or dependencies an attacker can exploit.
- Effective privilege extends beyond visible administrator roles into groups, applications, service principals, devices, and delegated access.
- OAuth permissions, application registrations, device-code authentication, trusted devices, and guest identities all expand the identity attack surface.
- SharePoint and OneDrive sharing settings can turn limited account access into meaningful data exposure.
- Automated baselines such as CISA’s ScubaGear are valuable for spotting configuration weaknesses. Offensive validation answers a different question: can those weaknesses be chained into a realistic attack path?
- Microsoft 365 red teaming should test the effective state of trust, not only whether individual controls are switched on.
The Microsoft 365 attack surface is larger than the login page
Microsoft 365 security discussions often start with authentication. Strong passwords, multifactor authentication (MFA), Conditional Access, and phishing-resistant authentication are essential controls. But authentication is only one part of what an attacker looks at.
Microsoft Entra ID connects users, groups, devices, privileged roles, applications, service principals, external identities, and Microsoft 365 workloads. Microsoft’s identity management and access-control best practices treat identity as a primary security perimeter, recommending Conditional Access, MFA, role-based access control, and fewer standing privileged accounts.
CISA’s Microsoft 365 Secure Configuration Baseline for Microsoft Entra ID takes a similarly broad approach, covering authentication, Conditional Access, application registration, consent, privileged roles, and guest access.
Attackers look at relationships, not settings
Attackers don’t look at these controls one by one. They look for the relationships between them.
A user might have limited permissions but reach an application with far more authority. One excluded account can slip past a Conditional Access policy entirely. Elsewhere, a trusted device may satisfy a requirement another system depends on. A guest identity, meanwhile, can expose information useful for a deeper compromise.
This reflects a broader shift we explored in Modern Credential Theft: Why Identity Is the New Attack Surface. Modern identity attacks increasingly target the trust surrounding authentication, not just the password itself.
So the important question is not simply which controls are enabled. It’s what happens when an attacker starts connecting them.
1. Conditional Access can exist and still leave an attack path
Conditional Access is one of Microsoft 365’s most important identity-security mechanisms. It lets organisations check users, applications, devices, authentication flows, locations, and risk before granting access.
But the existence of Conditional Access doesn’t mean every relevant path is covered. Microsoft Incident Response reports finding gaps in Conditional Access policies during customer engagements, including gaps affecting privileged identities. Microsoft also notes that attackers with ordinary user access can map out Conditional Access policies and spot weaknesses.
Consider a policy that requires MFA for most employees but excludes one group for operational reasons. The policy may be working exactly as intended. The attacker sees something different, though. Can I compromise an excluded account, join that group, or reach another identity that already sits outside the policy? The weakness is not necessarily the Conditional Access technology. It’s the relationship between policy scope, exclusions, identity membership, and attacker access.
Complexity hides the gaps
Complexity makes this harder to see. Microsoft IR has also seen environments where dozens of Conditional Access policies make it hard to tell which protections are actually enforced.
That creates an important distinction for offensive testing. A configuration assessment may simply ask whether Conditional Access is enabled. A red-team assessment digs further. Which identities are excluded, and which applications fall outside the expected policy? Do all authentication flows get equal protection, and can an attacker influence who belongs to an exclusion group? Are trusted locations still treated differently, can device state change the access decision, and can one policy quietly weaken another?
The value lies in testing effective coverage, not counting policies.
2. Visible privilege is not always effective privilege
Privileged admin accounts are obvious targets. Microsoft recommends least privilege, Privileged Identity Management for just-in-time access, MFA for admins, regular access reviews, and less standing Global Administrator exposure.
Those controls matter, but an attacker is not interested only in accounts labelled “Global Administrator.” They want any identity that can influence something more privileged.
Where indirect authority hides
That list is longer than most teams expect. A group owner can change membership. An application admin can modify credentials. Someone who controls an automation workflow may reach far past their own account, and a service principal can carry broad permissions nobody reviews. A device-management admin can influence compliance decisions, while an identity with access to an onboarding or admin platform holds real leverage. A delegated relationship can hand someone indirect authority too, quietly.
Peer-reviewed research on Azure Active Directory misconfigurations and privilege escalation has examined how configuration weaknesses create paths to higher privilege in similar ways. On-premises environments show a related pattern through different mechanics. Misused certificate services, covered in ADCS Exploitation Explained, can hand an ordinary account that same kind of unearned authority.
This is a cloud version of a familiar problem. On-premises Active Directory can contain accounts with real practical authority despite lacking obvious admin-group membership. We examine that pattern in Shadow Admins in Active Directory: The Hidden Privilege Problem. Microsoft 365 creates its own version of that challenge. Where AD and Entra ID meet in a hybrid setup, the two environments can even compound each other. We cover that dynamic in Hybrid Identity Attacks: Bridging Active Directory and the Cloud.
The red-team question becomes: what can this identity influence, and what can that influence reach next? That’s more useful than exporting a list of admins.
3. Applications and service principals create a parallel identity layer
Applications are identities too, which makes application governance one of the most overlooked parts of the Microsoft 365 attack surface.
CISA’s Entra ID baseline specifically addresses application registration and consent, recommending that registration be restricted and user consent be controlled. CISA notes that malicious applications and service principals can act and access data on behalf of users.
The issue is not limited to newly created malicious applications; existing ones matter just as much. Organisations build up integrations with productivity tools, HR platforms, ticketing systems, analytics products, automation services, and other SaaS platforms over time. Each integration can introduce permissions, and those permissions often outlive the reason they were granted.
What a red-team assessment should check
Microsoft IR warns that applications and service principals need their own access controls and monitoring. Attackers have abused existing applications by adding credentials or expanding privileges. A compromised application identity can be attractive too, because it may draw less scrutiny than an interactive user.
A solid assessment looks at who can register applications and who can approve consent requests. It checks which applications hold high-impact permissions, and which service principals carry credentials that are old or poorly governed. It also asks which application owners can modify credentials, and whether inactive applications are still trusted. Can a low-privilege user reach a business application that runs privileged workflows? Workload identities deserve the same monitoring attention as human admins.
Microsoft IR documented an incident where a compromised user reached an internal application used for account onboarding. That access was enough to obtain a privileged account. The initial identity wasn’t privileged — the system it could influence was.
4. MFA doesn’t make every authentication path equivalent
MFA raises the barrier to many credential-based attacks, but attackers increasingly target what happens around and after authentication.
In May 2026, the FBI’s Internet Crime Complaint Center warned about Kali365, a phishing-as-a-service platform targeting Microsoft 365 access tokens. Its campaign uses device-code phishing to convince users to authorise access through Microsoft’s own authentication workflow. From there, the attacker obtains OAuth access and refresh tokens, and can use them to reach Outlook, Teams, and OneDrive without another password or MFA challenge.
None of that makes the technique itself a tenant misconfiguration. The real configuration question is whether the organisation allows an authentication flow it doesn’t actually need. CISA’s Entra ID baseline recommends blocking device-code authentication where it is unnecessary, citing its abuse in phishing attacks directly.
The session is the new perimeter
Defenders sometimes treat successful MFA as the end of the authentication-security conversation. Attackers may treat it as the beginning of the trusted session.
We examined this problem in Token Theft: Why Trusted Sessions Survive Remediation, where the operational risk shifts from stealing credentials to inheriting authenticated trust. For Microsoft 365 red teams, that means asking several things. Do unnecessary authentication flows stay enabled, and can tokens or authenticated sessions be reused? Can OAuth consent establish persistent access, and does session activity get adequate monitoring? Just as important, does remediation actually invalidate the authentication evidence tied to an incident?
The goal isn’t to prove MFA is ineffective. It’s to determine whether the environment protects the entire authentication chain.
5. A trusted device can become part of the attack
Conditional Access frequently relies on device state, which makes the process used to establish device trust part of the security boundary.
Microsoft IR has documented a particularly useful example. In one engagement, attackers compromised a regular user through phishing, then joined an attacker-controlled device to the organisation’s Entra ID tenant. A Microsoft Intune configuration weakness let that device get marked compliant.
The attackers then satisfied Conditional Access requirements and reached Microsoft 365 resources. There, they found credentials for a privileged account stored in email.
Individually legitimate, together dangerous
The sequence matters here. The attackers didn’t bypass Conditional Access — they manipulated the conditions required to satisfy it.
From a defensive perspective, several controls existed: user authentication, device enrolment, device compliance, Conditional Access, and Microsoft 365 access itself. Individually, each component may have looked legitimate. Together, they created a viable attack path.
This is why Microsoft 365 red teaming should look at more than access decisions. It should examine the systems that feed the signals behind those decisions. Who can register or join devices, and what controls govern enrolment? How is compliance established, and could a compromised identity enrol an attacker-controlled endpoint? Which admins can influence device state, are unusual registrations caught, and does device trust unlock access to other resources?
The configuration problem sits in the trust chain, not necessarily in one control.
6. Guest access can move the security boundary
Microsoft 365 is built for collaboration. Organisations routinely give access to suppliers, consultants, customers, contractors, and other outside users. That creates business value, and it also expands the identity boundary.
CISA’s Entra ID Secure Configuration Baseline recommends limiting what guest users can view in the directory. It also calls for restricting who can invite guests, and controlling which external domains can receive invitations. CISA specifically links excessive guest visibility to higher reconnaissance risk.
The Microsoft 365 Guidance for UK Government treats external collaboration as its own security area, alongside secure configuration and information protection.
What guest access gives an attacker
Guest access opens up several possibilities for an attacker. A compromised partner identity may already have legitimate access. A stale guest account can remain active long after a project ends. An external user might see more directory information than expected, and an employee may be allowed to invite additional outside identities. A trusted domain relationship can also stay configured after the underlying business relationship changes.
The relevant red-team questions follow from that. Which guest accounts remain active, and when were they last reviewed? What directory objects can they see, and which Teams, SharePoint sites, files, or applications can they reach? Who can create new guest identities, which external domains are trusted, and can outside identities reach applications meant only for employees?
The security boundary is no longer simply inside the company network versus outside it. It now includes a network of trusted identities belonging to other organisations.
7. SharePoint and OneDrive can turn a foothold into data exposure
Initial access has limited value unless the attacker can reach something useful. In Microsoft 365 environments, SharePoint and OneDrive often hold a large concentration of business information. That can include internal documentation, customer information, project files, financial material, technical documentation, operational procedures, security architecture, administrative instructions, and even credentials stored improperly in documents.
A compromised identity doesn’t need full tenant administration if it can already reach information that moves the attack forward.
CISA’s SharePoint Online and OneDrive Secure Configuration Baseline addresses external sharing, default link behaviour, anonymous links, verification-code access, and other controls meant to reduce unnecessary exposure. CISA strongly discourages weakly authenticated sharing mechanisms such as “Anyone” links, and recommends restrictions when organisations still need them.
What becomes reachable after one compromise
From a red-team perspective, the question is not simply whether external sharing exists. It’s what becomes reachable once one identity is compromised. A red team may look at accessible SharePoint sites, overly broad groups, and externally shared files. It can also check stale sharing links and sensitive material reachable by ordinary users. Documents that reveal internal infrastructure or security processes, and credentials or secrets stored in collaboration platforms, matter just as much.
This is where identity compromise becomes business impact. A low-privilege account may not control the tenant. It may not need to.
8. Remediation can remove the compromise without removing the access path
Another Microsoft 365 risk shows up after an incident looks contained. Security teams may reset a user’s password, require MFA re-registration, remove malware from an endpoint, disable an account, or revoke an obvious session.
Those actions may all be appropriate. But they don’t automatically address every application credential, delegated permission, refresh token, guest identity, device relationship, or persistence mechanism tied to the compromise.
This is the same broader problem examined in How to Validate Attacker Persistence Is Removed. Visible remediation and complete removal of attacker access aren’t necessarily the same thing. Microsoft 365 widens that challenge, because authentication and authorisation spread across multiple cloud services and identity types.
What survives a response
A red team should test not only whether initial compromise is possible, but also what survives when defenders respond. Can an application credential remain active, or an existing token still get used? Does the attacker retain access through another identity, or register an additional device? Was a guest account created, or were permissions added to an existing application? Did the attacker build an alternative route into SharePoint, Exchange, or Teams?
These are persistence questions, but their roots are usually configuration and identity governance.
Why mature security programmes still miss Microsoft 365 attack paths
Many of these issues don’t come from obvious negligence. They accumulate.
A business unit requests an exception, or an employee changes roles. A SaaS application receives extra permissions, and a contractor becomes a guest. Projects end, but the access often remains. Rather than simplify an existing Conditional Access policy, an admin adds another one. Device-management processes change, and a service principal stays active because nobody owns its lifecycle.
Each decision may look reasonable on its own. The weakness emerges from the combination.
A visibility problem, not a negligence problem
This creates a recurring problem for mature organisations: security teams often have visibility into individual controls, but less visibility into the relationships between them.
Microsoft IR’s own incident-response findings show how configuration gaps across applications, devices, identities, roles, and Conditional Access can combine into larger compromise paths.
Attackers naturally work across those boundaries. Defensive ownership often doesn’t. Identity may belong to one team, while endpoint management sits with another. Microsoft 365 administration and application governance often belong to two more, and incident response can sit somewhere else entirely. The attack path crosses all of them regardless.
Configuration compliance is not the same as attack-path resistance
Organisations should absolutely use secure configuration baselines. CISA’s ScubaGear was built specifically to assess Microsoft 365 tenants against CISA’s Secure Configuration Baselines, and those baselines provide a strong reference point.
The importance of SaaS configuration has also moved into formal government requirements. CISA’s Binding Operational Directive 25-01 requires U.S. Federal Civilian Executive Branch agencies to implement defined secure cloud baselines and use automated configuration assessment for covered services.
But configuration assessment and red teaming answer different questions. A configuration assessment asks: does this setting match the expected secure state? A red team asks: what happens if it doesn’t, and what can we chain it with?
From finding to attack path
Suppose an assessment identifies that a group is excluded from MFA. That’s a finding. A red team goes further, asking whether an attacker could discover that exclusion and reach the excluded identity. From there, could they influence group membership, use the access to reach an application, and find sensitive data? Could they escalate privilege, establish persistence, and keep operating without triggering an effective response?
That sequence tells leadership far more about business risk than the finding alone. The individual misconfiguration matters, but the attack path determines its significance.
The same controls attackers abuse are often legitimate business features
This is one reason Microsoft 365 can be difficult to defend. The attacker often doesn’t need obviously malicious technology. Valid accounts, Microsoft Graph, OAuth, existing applications, approved admin portals, PowerShell, SharePoint, Teams, OneDrive, and trusted devices can all get the job done instead.
This mirrors the broader operational problem behind living-off-the-land attacks: the technology itself may be legitimate, while the intent behind its use is malicious.
That creates a real detection challenge. Blocking every admin capability isn’t realistic. Security teams instead need to understand which legitimate actions turn dangerous in the wrong hands, the wrong order, or the wrong context.
Red-team exercises are particularly useful here because they evaluate the environment as a system rather than a collection of controls.
What Microsoft 365 red teaming should validate
A Microsoft 365 red-team engagement should go beyond checking whether security recommendations have been implemented. It should test how the environment behaves under realistic attacker pressure. Depending on scope and authorisation, that typically means validating the following.
| Area | What it tests |
|---|---|
| Conditional Access gaps | Whether exclusions, authentication flows, trusted locations, applications, or device states create unintended access paths |
| Effective privilege | How identities, groups, administrative roles, applications, service principals, devices, and business systems influence one another |
| Application trust | Whether application registration, consent, existing permissions, or application ownership create persistent or excessive access |
| Authentication pathways | Whether unnecessary authentication flows, token reuse, OAuth abuse, or trusted sessions create access beyond what defenders expect |
| Device trust | Whether device enrolment, compliance, or device-management permissions can influence Conditional Access decisions |
| External collaboration | Whether guest identities, external domains, or external sharing expand the attack surface |
| Sensitive cloud data | What SharePoint, OneDrive, Exchange, or Teams information becomes accessible after an initial foothold |
| Durable access | Whether applications, tokens, guest users, credentials, or other identity relationships can survive initial containment actions |
| Detection and response | Whether defenders recognise the sequence as malicious, understand its scope, and remove the underlying access path |
The goal is not to prove that every configuration issue results in compromise. It’s to determine which combinations create meaningful attacker opportunities in this specific environment.
Why the attack narrative matters to leadership
A CISO doesn’t need another list of 47 configuration findings with identical severity ratings. Leadership needs to understand which weakness matters first.
There’s a real difference between a dry finding and a story. “Application registration is insufficiently restricted” is a configuration issue. “A standard user can register an application, obtain delegated permissions, access sensitive SharePoint data, and keep an alternative cloud access path open” explains the actual risk.
That attack narrative also improves remediation priority-setting. Security teams can focus first on weaknesses inside a viable path — one leading to privilege escalation, sensitive-data access, or business email compromise. Persistent cloud access, admin control, cross-workload movement, and identity compromise belong on that short list too.
This is one of the main advantages of offensive validation: it converts isolated findings into operational consequences.
What security leaders should ask
For CISOs and security leaders, Microsoft 365 security shouldn’t stop at confirming that a hardening project was completed. The more useful questions are operational ones.
Start with effective privilege: do you actually know it? That means going beyond who holds admin roles, to which identities, applications, groups, devices, and systems can influence privileged access. From there, ask what sits outside Conditional Access — every exclusion, exception, authentication flow, trusted location, or unsupported scenario deserves clear ownership. Application identities need a governor too. Someone should know which applications exist, who owns them, and what permissions they still need.
A few more questions worth the agenda
Tokens and sessions deserve treatment as security-sensitive assets, since credential security has to include what happens after successful authentication. It’s worth knowing what one compromised employee can actually reach — applications, SharePoint, OneDrive, Teams, business systems, guest relationships, and other users. External access needs continuous review too, so guest identities and collaboration relationships reflect current business needs rather than historical ones. Perhaps most important: have these assumptions been tested offensively? A secure configuration baseline shows what the environment should look like. A red-team exercise shows what an attacker can actually do.
Security is defined by the path, not the setting
Microsoft 365 ships with mature security capabilities, and Microsoft backs it with extensive identity and access guidance. CISA adds detailed secure configuration baselines and automated assessment tooling, and UK government guidance layers on further recommendations for configuration and collaboration. Those resources matter.
But attackers don’t approach Microsoft 365 as a compliance checklist. They look for relationships. A Conditional Access exception connects to an identity, which connects to a device. That device satisfies a trust requirement, and the application riding along carries its own permissions. A service principal opens another route, a guest identity reaches into a SharePoint site, and a token unlocks Outlook, Teams, or OneDrive.
Individually, each element may look manageable. Together, they may form the attack path.
Red teaming Microsoft 365 is ultimately about finding that path, testing whether defenders can see it, and determining what it means for the business.
For organisations looking to test those assumptions under realistic attacker conditions, offensive security assessments and adversary simulation can help. They show whether identity, access, application, collaboration, and response controls behave as expected once they’re tested together, not just one at a time.
If you want to understand what those attack paths look like in your Microsoft 365 environment, get in touch with wizlynx group.
FAQs
What are the most common Microsoft 365 misconfigurations attackers exploit?
Common weaknesses include incomplete Conditional Access coverage, excessive or standing privilege, and unrestricted application registration or consent. Unnecessary authentication flows, weak device-governance processes, poorly controlled guest access, and excessive SharePoint or OneDrive sharing round out the list. The severity of each issue depends heavily on what the affected identity or configuration connects to.
Is Microsoft 365 secure by default?
Microsoft 365 provides extensive security capabilities, but organisations still need to configure, govern, monitor, and maintain those controls for their own environment. Microsoft, CISA, and the UK Government all publish configuration guidance covering identity, privilege, authentication, and collaboration. (Microsoft | CISA | GOV.UK)
What’s the difference between a Microsoft 365 security assessment and a red-team assessment?
A configuration assessment generally checks whether settings align with an expected baseline or standard. A red-team assessment tests whether weaknesses can be combined into a realistic attacker path. For example, a configuration assessment may flag a Conditional Access exclusion. A red team would investigate whether an attacker could discover that exclusion, reach the affected identity, access additional resources, escalate privilege, or establish persistence.
Can attackers bypass MFA in Microsoft 365?
Attackers don’t always need to defeat MFA directly. They may instead target authentication flows, OAuth authorisation, tokens, browser sessions, or other trusted artefacts created after authentication. The FBI’s 2026 Kali365 advisory provides a current example involving device-code phishing and OAuth token theft.
Why is not Conditional Access enough by itself?
Conditional Access decisions depend on scope, exclusions, identities, applications, devices, locations, authentication flows, and other signals. A policy can operate exactly as configured and still leave an unintended route outside its effective coverage. That’s why Microsoft itself recommends periodically reviewing policies, with particular attention to exclusions and privileged identities.
Why are application registrations and service principals important in red-team testing?
Applications and service principals can hold significant Microsoft 365 permissions, and may operate without the same interactive controls applied to human users. Poor application governance can therefore create alternative access, privilege, or persistence paths. CISA’s Entra ID baseline specifically addresses application registration and consent, because malicious or overprivileged applications can access organisational data.
How can SharePoint and OneDrive misconfigurations increase attacker impact?
An attacker who compromises an ordinary identity may still reach sensitive documents, business information, internal procedures, or externally shared files. Weak sharing controls can increase that exposure. CISA publishes a dedicated SharePoint Online and OneDrive baseline covering external sharing and link-security settings.
Does a password reset remove Microsoft 365 attacker access?
Not necessarily. The answer depends on what the attacker obtained or changed. Existing tokens, application credentials, additional identities, delegated permissions, device relationships, or other access mechanisms may need separate remediation. This is why identity-focused incident response should validate the broader access path, not only reset the original credential.
How does red teaming improve Microsoft 365 security?
Red teaming evaluates Microsoft 365 from an adversary’s perspective. Rather than treating identities, applications, devices, permissions, authentication, and collaboration controls independently, it tests whether weaknesses can be combined to achieve meaningful objectives. That helps security teams understand which findings represent genuine attack paths, and which should get remediation priority first.
wizlynx group is a CREST-accredited offensive security company headquartered in Switzerland, operating across Europe, North America, Latin America, and Asia. wizlynx group specialises in penetration testing, red teaming, adversary simulation, social engineering, and advanced security assessments for enterprise clients.