The Microsoft 365 Security Gaps I Keep Seeing Exploited

When people picture a Microsoft 365 breach, they usually imagine zero-day exploits, sophisticated malware, or compromised global admin credentials. Those happen, but the vast majority of incidents I investigate are far more mundane. They trace back to incomplete rollouts, forgotten troubleshooting exceptions, legacy authentication paths nobody realized were still active, or third-party email gateways deployed without hardening what Exchange Online accepts behind them.

Individually, these oversights look like minor operational noise. Together, they build clean, reliable attack paths. The common thread across nearly every incident is not a lack of security tooling, but the gap between what an organization assumes is enforced and what is actually running in production.

The examples below reflect patterns observed across real-world security investigations, with details generalized for confidentiality.

1. Multifactor Authentication Is More Than Just a Setting

Multifactor authentication reliably disrupts identity attacks. Microsoft data indicates MFA blocks over 99.2% of account compromise attempts, climbing past 99.9% when paired with legacy authentication blocks. On paper, that makes MFA look like a solved problem.

In reality, having MFA available is completely different from enforcing it universally. In client environments, the breakdown rarely looks like total absence. Instead, it looks like operational friction:

• Users who never completed their initial registration process.
• Temporary exclusions added during troubleshooting that were never cleaned up.
• Unsupported hardware or delayed onboarding training.
• VIP and service account bypasses created to avoid disruption.
• Security Defaults turned off after building customized policies that left coverage gaps.
• Conditional Access rules that miss specific apps, protocols, or edge cases.
• Reliance on basic SMS or push notifications that remain vulnerable to adversary-in-the-middle phishing.

Security Defaults give Microsoft Entra tenants baseline controls at no added cost, but organizations needing granular Conditional Access must step up to Entra ID P1 or higher licensing. When budgets, hardware limitations, and user friction collide, organizations often end up with a small pool of unprotected users. An attacker only needs one accessible account to establish a foothold.

Consider an organization with 80 users where 78 are fully enforced, one is tied to a legacy scanner, and another was temporarily excluded during phone replacement issues. Leadership sees 97.5% coverage and assumes the tenant is secure, while an attacker simply targets the two accounts without guardrails. The right metric during a security review is not whether MFA is turned on, but which identities, protocols, and authentication flows can still authenticate without it.

Furthermore, MFA is a spectrum rather than a binary switch. High-value accounts should use phishing-resistant methods such as FIDO2 security keys, passkeys, Windows Hello for Business, or certificate-based authentication. Standard push notifications and SMS are better than passwords alone, but they leave users open to coercion or deception.

2. Device Code Phishing: Authenticating on the Real Microsoft Domain

In one compromise I investigated, the victim followed every standard security rule: they did not type credentials into a suspicious lookalike domain, nor did they hand an MFA code over to an attacker. Instead, they followed a prompt to enter a short code into Microsoft's official device login page, authenticated, completed MFA, and inadvertently handed their OAuth tokens directly to the attacker.

Device Code Flow exists for legitimately input-constrained hardware such as conference room consoles, smart TVs, or command-line utilities. The client requests an alphanumeric code from Entra ID, directs the user to sign in via a browser on a secondary device, and receives the session tokens once authentication succeeds.

Attackers exploit this architecture by initiating the request themselves, embedding the generated code into a phishing lure, and letting the victim complete the interactive sign-in. Because the victim navigates to an authentic Microsoft domain with valid TLS certificates and completes standard MFA, conventional awareness training fails to flag the threat. The flaw lies in approving an authentication challenge the user never initiated.

The Commodification of Kali365

This technique has shifted from a manual attack into automated, commoditized tooling. In May 2026, the FBI issued a public advisory regarding Kali365, a Phishing-as-a-Service platform operating since April 2026 that allows novice operators to capture Microsoft 365 OAuth tokens via device code lures. Huntress documented an extensive infrastructure backing the service, including over 240 IP addresses, dozens of built-in templates, automated mailbox access, and tooling designed to turn intercepted tokens into active browser sessions in as little as 42 seconds.

Telemetry from LevelBlue highlighted similar surges across platforms like EvilTokens, Ghost Hub, Cyb3r, and Tycoon2FA. The defensive takeaway is straightforward: do not rely on end users to distinguish legitimate device-code prompts from attacks. If your organization has no defined operational need for Device Code Flow, block it across Conditional Access, carving out tightly scoped exceptions only where strictly necessary.

3. The Gap Between Conditional Access Policies and Actual Enforcement

Conditional Access is the core policy engine of Entra ID, yet it frequently produces a false sense of security. A policy list filled with clean titles like "Require MFA - All Users", "Block Risky Sign-ins", and "Require Compliant Devices" means nothing if the underlying assignments and exclusions leave backdoors open.

Suppose a finance employee signs in from an unmanaged device at a foreign IP using Device Code Flow to access Microsoft Graph. If the policy requiring compliant devices excludes the finance group for legacy reasons, and the high-risk block is parked in report-only mode, the sign-in is granted despite the tenant appearing fully protected on paper.

Exclusion drift is one of the most common issues in mature tenants. An administrator adds a traveling executive, an overseas contractor, or a broken service account to an exclusion group like CA-Exclude-MFA to resolve an immediate ticket. Without automated Entra Access Reviews and tight operational hygiene, temporary workarounds quietly become permanent vulnerabilities. Assessing Conditional Access requires evaluating who and what bypasses the rules, rather than reviewing the rule definitions in isolation.

4. Lingering Legacy Authentication and SMTP AUTH

While Microsoft has deprecated Basic Authentication across Exchange ActiveSync, POP, IMAP, Remote PowerShell, and EWS, historical protocols still linger. SMTP AUTH remains a key exception in 2026, with Microsoft disabling it by default for existing tenants toward the end of December 2026 rather than enforcing a total shutdown.

Microsoft telemetry historically showed that over 97% of credential-stuffing attacks and 99% of password-spray attempts targeted legacy authentication endpoints. Because legacy protocols cannot enforce modern MFA or device posture checks, a single unmonitored mailbox, legacy multifunction printer, or old automated script can expose the entire tenant to credential attacks.

Organizations should disable SMTP AUTH globally at the tenant level and permit it only on explicit, monitored mailboxes that genuinely require basic authentication. If an active legacy exception lacks a clear business owner and documented justification, it should be phased out immediately.

5. Inactive Accounts as Silent Attack Surface

Dormant accounts rarely trigger alerts, fail builds, or surface on vulnerability scans, which makes them easy to overlook. Microsoft defines inactive accounts as those no longer needed for business purposes and recommends auditing identities after 90 to 180 days of inactivity.

The risk is not merely an unmonitored mailbox, but the historical access attached to it:

• Entra and Azure RBAC roles.
• SharePoint and Teams access containing confidential files.
• Enterprise application assignments and federated SaaS connections.
• VPN profiles and previously registered MFA hardware.

As employees transfer departments or take on temporary project roles, permissions accumulate. Leaving former employee accounts enabled without automated lifecycle provisioning provides attackers with low-noise access vectors. Identity lifecycle management is fundamental attack-surface reduction.

6. Email Security Beyond Standard SPF, DKIM, and DMARC

Because Microsoft 365 consolidates email, identity, and document storage, compromising or spoofing internal communication remains a primary target for threat actors. While SPF, DKIM, and DMARC are necessary baselines, relying on them as simple checkboxes leaves architectural blind spots.

For example, message headers showing dmarc=bestguesspass indicate that no actual DMARC policy exists and Microsoft merely inferred a pass heuristically. Domains must move beyond p=none to p=quarantine or p=reject to enforce authentication.

The Ghost-Sender Architectural Bypass

In June 2026, InfoGuard published research detailing Ghost-Sender, an architectural vulnerability affecting tenants using third-party email security gateways. In these setups, public MX records route incoming mail through the external gateway, but the direct Exchange Online Protection (EOP) endpoint remains exposed to the internet.

Attackers can bypass the external filtering appliance entirely by routing SMTP traffic directly to the tenant's EOP hostname. InfoGuard demonstrated that this allowed spoofing of both internal and external domains, delivering uninspected messages directly to user inboxes even when SPF, DKIM, and DMARC were present. Organizations should review their connectors, enable tenant controls like RejectDirectSend, and ensure Exchange Online only accepts inbound mail originating from their designated security gateways.

7. Publicly Exposed Tenant Metadata

A company's Microsoft 365 footprint is not private. Using basic reconnaissance, an attacker can resolve an organization's public domain to uncover:

• Microsoft Entra tenant IDs.
• Associated custom and fallback onmicrosoft.com domains.
• Inbound mail routing infrastructure.
• Specific federated identity providers and public authentication endpoints.

Open-source tooling like AADInternals and ROADtools automates this reconnaissance, mapping out directory structures, authentication methods, and token endpoints. Tenant IDs are public identifiers rather than secrets, so security architectures must be designed under the assumption that external attackers already understand your public Microsoft environment.

8. Abusing URL Rewriting and Trusted Redirect Chains

URL-rewriting solutions like Defender for Office 365 Safe Links inspect web destinations at time-of-click. However, because security vendor domains carry high organizational trust, threat actors actively weaponize them.

LevelBlue SpiderLabs has documented campaigns where attackers harvest pre-rewritten URLs from compromised tenants to disguise malicious payloads behind trusted hostnames like Cisco, Trend Micro, Barracuda, and Mimecast. By stacking multiple redirect hops across legitimate security vendors, compromised sites, and cloud worker scripts, attackers bypass basic domain reputation filters.

Security teams should avoid creating blanket domain allowlists for third-party security vendors they do not use, and educate analysts to evaluate the final landing destination of a URL rather than trusting the initial hostname.

9. The Core Breakdown: Intended vs. Effective Trust Boundaries

Across MFA gaps, device code phishing, stale accounts, and mail routing bypasses, the root problem is consistent: a breakdown between what policy administrators intend to enforce and what the infrastructure actually permits.

Incidents happen in the margin between theoretical configuration and operational reality. An organization might believe it enforces universal MFA, routes all mail through a secure gateway, and restricts sensitive access, while legacy exclusions and open routing paths tell a different story.

High-Impact Tenant Review Areas

When conducting a tenant assessment, these fundamental areas provide the most immediate visibility into real exposure:

Identity & Authentication

• Confirm MFA is enforced for 100% of interactive users, transitioning sensitive accounts to phishing-resistant methods.
• Block Device Code Flow across the tenant unless an explicit, restricted business exception exists.
• Disable SMTP AUTH globally and disable legacy authentication protocols across all mailboxes.
• Implement automated offboarding workflows and audit accounts inactive for over 90 days.

Conditional Access

• Verify policy assignments cover all users and target resources without unintended bypasses.
• Schedule recurring Entra Access Reviews for all Conditional Access exclusion groups.
• Transition legacy report-only policies into full enforcement.

Email Architecture

• Enforce strict DMARC policies (p=quarantine or p=reject) and verify SPF and DKIM alignments.
• Lock down inbound connectors and enable RejectDirectSend to prevent gateway bypasses.
• Audit Safe Links configurations and remove blanket trust for third-party URL rewriting domains.

Security posture is rarely broken by sophisticated zero-days; it is eroded by unfinished migrations, unmonitored exceptions, and lingering trust assumptions. Attackers do not need to defeat every layer of your security stack when a single forgotten door remains unlocked. Reviewing and tightening these baseline configurations consistently yields the highest defensive return on investment.