Microsoft 365 delivers one of the most comprehensive security ecosystems available today. From Entra ID to Defender, organizations have access to powerful controls for identity, access, and threat protection, along with the flexibility to tailor those controls to their specific environment.

That flexibility also introduces a new set of challenges.

Microsoft 365 offers hundreds of configuration surfaces spanning identity, email, collaboration, and third-party integrations. Each setting plays a role in shaping an organization’s security posture. But at this scale, even well-managed environments can develop gaps, not because controls are missing, but because they are difficult to consistently configure, validate, and maintain over time.

These aren’t zero-day vulnerabilities or software flaws. They are blind spots: misconfigurations or overlooked settings that create unintended access paths. And because they exist within legitimate systems, they are often difficult to detect using traditional controls alone.

Two real-world attacks illustrate how attackers exploit these blind spots.

In this case, attackers initiated contact through Microsoft Teams, using a familiar and trusted workflow.

Users received what appeared to be a legitimate meeting invitation. As part of the interaction, they were prompted to approve an OAuth application. The request looked routine, and the user approved it.

That single action granted the attacker persistent access.

What Happened

• The OAuth application was malicious but convincingly disguised

• User consent granted the application API-level access

• The attacker obtained a token tied to that access

Why It Worked

From a control perspective, nothing was “broken.”

• Multifactor authentication (MFA) was enabled

• Identity protections were functioning as designed

However, OAuth consent created a trusted access path. Once the token was issued, the attacker no longer needed credentials or MFA to maintain access. Even if the user changed their password, the token remained valid.

Why It Was Difficult to Detect

• No suspicious login activity

• No brute-force or credential theft signals

• Access occurred through legitimate APIs

From the system’s perspective, this looked like normal, authorized behavior.

This is a key characteristic of modern attacks: they operate within approved workflows, leveraging user actions to establish persistence.

In a separate case, attackers targeted a different kind of blind spot: legacy authentication protocols.

Despite investments in modern identity security, protocols such as IMAP and POP were still enabled in the environment. These protocols rely on password-only authentication and do not support MFA.

What Happened

• Attackers authenticated using valid credentials via legacy protocols

• MFA policies were not enforced in this pathway

• The compromised account was used to send internal phishing emails

Why It Worked

Legacy authentication often remains enabled for compatibility reasons. Disabling it can disrupt existing workflows, so it is frequently left in place (sometimes unintentionally).

In this case:

• The login method bypassed modern authentication requirements

• Standard protections did not apply to the legacy protocol

• The attacker gained full mailbox access immediately

Why Standard Response Failed

When the compromise was detected, typical remediation steps were taken:

• Password reset

• MFA enforcement

However, these actions did not stop the attack. The legacy authentication pathway remained open, allowing the attacker to re-enter the account without triggering those controls.

Impact

• Continued unauthorized access

• Internal phishing campaigns launched from a trusted account

• Increased risk of lateral compromise

Again, the issue was not the absence of controls but the fact that they were not universally enforced across all access paths.

While these attacks differ in execution, they share a common theme:

• Security controls were present and correctly implemented

• Attackers leveraged alternative access paths created by configuration gaps

• Activity appeared legitimate within the context of those systems

This highlights a broader challenge in Microsoft 365 environments.

Security policies define what should happen. But in practice, environments evolve:

• New features are introduced

• Default settings remain unchanged

• Permissions expand

• Integrations accumulate

Over time, this creates drift, where the actual state of the environment no longer fully reflects its intended security posture.

Attackers are increasingly targeting that drift.

Configuration is foundational. But it cannot account for how systems—and users—behave in real time.

In both examples:

• The OAuth attack involved legitimate consent and valid API usage

• The legacy authentication attack involved a technically valid login

From a policy standpoint, these actions were allowed. From a security standpoint, they were clearly abnormal.

This is where a behavioral layer becomes critical.

A behavioral approach evaluates:

• How identities typically interact with systems

• What normal access patterns look like

• When activity deviates from established behavior

Applied to these attacks:

• Unusual OAuth consent patterns can be flagged

• Abnormal API usage can be identified

• Suspicious internal email behavior can be detected, even when access is valid

Rather than relying solely on whether an action is permitted, behavioral analysis focuses on whether it is expected.

Microsoft 365 provides the foundation for modern cloud security: identity controls, policy enforcement, and a broad set of defensive capabilities.

But as these examples demonstrate, attackers are no longer attempting to break those controls. They are working around them, operating within legitimate systems and exploiting the complexity of real-world environments.

Addressing this requires more than additional rules or policies. It requires the ability to continuously evaluate both:

Configuration state: Are controls correctly applied across all surfaces?

Behavioral context: Are those controls being used in expected ways?

To explore these attacks in more detail—and understand how to identify and close similar gaps in Microsoft 365—watch the full webinar.