MFA Is On—But Is It Really? How MFASweep Exposes Your Entra ID Blind Spots + Video

Listen to this Post

Featured Image

==========================================================

Introduction

Many organizations operate under the dangerous assumption that simply “enabling MFA” on their Microsoft 365 tenant guarantees protection. The reality is far more complex, as conditional access policies, legacy authentication protocols, and varied client applications can create significant gaps where only a single factor is required for access. This article explores how attackers exploit these inconsistencies using tools like MFASweep and provides actionable steps for defenders to identify and remediate these critical security blind spots.

Learning Objectives

  • Understand how conditional access policies can inadvertently create MFA bypass opportunities across Microsoft Graph, Exchange Web Services, and other Microsoft endpoints.
  • Learn to operate MFASweep, a PowerShell tool that systematically tests multiple Microsoft services for MFA enforcement gaps.
  • Implement defensive measures including legacy authentication blocking, comprehensive conditional access rules, and continuous monitoring to close identified MFA gaps.

You Should Know

  1. Deploying and Executing MFASweep for MFA Coverage Testing

MFASweep is a PowerShell script that attempts authentication to seven distinct Microsoft services using a single set of credentials, revealing which endpoints enforce MFA and which remain in single-factor mode. The tool simulates authentication from different device types—Windows, Linux, Android, iPhone, and unknown devices—because conditional access policies often apply different rules based on the platform and client used.

To begin, download the script from the official GitHub repository:
`https://github.com/dafthack/MFASweep`

Execute the script from an elevated PowerShell console using the following command structure:

 Basic usage – tests Graph API, Azure Management, EWS, Web Portal (desktop+mobile), and ActiveSync
Invoke-MFASweep -Username [email protected] -Password Winter2020

Full reconnaissance including ADFS detection and testing
Invoke-MFASweep -Username [email protected] -Password Winter2020 -Recon -IncludeADFS

Understanding the output: The script will attempt each authentication method sequentially. A successful login without an MFA challenge indicates a security gap. The tool attempts login six times (seven if including ADFS); an incorrect password may lock the account, so ensure credentials are accurate before testing.

Running individual modules for granular testing:

 Test Microsoft Graph API only
Invoke-GraphAPIAuth -Username [email protected] -Password Password123

Test Exchange Web Services
Invoke-EWSAuth -Username [email protected] -Password Password123

Test Azure Service Management API
Invoke-AzureManagementAPIAuth -Username [email protected] -Password Password123

Test Microsoft 365 Web Portal with mobile user agent
Invoke-O365WebPortalAuthMobile -Username [email protected] -Password Password123

Test ActiveSync protocol
Invoke-O365ActiveSyncAuth -Username [email protected] -Password Password123

Test on-premises ADFS server
Invoke-ADFSAuth -Username [email protected] -Password Password123

Linux alternative – MFade (Python port): For cross-platform compatibility, a Python port called MFade is available. It removes the encoded EWS DLL dependency from the original PowerShell codebase and offers improved operational security features for red team engagements.

2. Understanding Conditional Access Policy Blind Spots

Conditional Access policies are the fine-grained controls that determine when and where MFA is applied, but they introduce significant complexity. The following misconfigurations frequently create MFA gaps:

Legacy authentication protocols remain one of the most common vectors. Protocols such as EWS, IMAP, SMTP, and POP3 do not support modern authentication and cannot enforce MFA natively. Attackers specifically target these protocols to bypass MFA entirely.

Platform inclusion gaps occur when policies specify only “Windows” or “iOS” but omit newer platforms such as Chrome OS, Linux distributions, or emerging device types. An attacker can spoof an excluded platform’s user agent to evade MFA enforcement.

Location-based exceptions are particularly dangerous. Many organizations configure conditional access to allow single-factor authentication from trusted corporate IP ranges while requiring MFA elsewhere. An attacker who compromises a credential can simply route traffic through that trusted IP range using a VPN or proxy.

Federated identity gaps arise when organizations use external identity providers. The federation may authenticate directly with the external provider, completely bypassing Azure AD’s conditional access policies.

Detection and verification: Use the Entra ID “What-If” tool to simulate authentication scenarios and identify policy exceptions before attackers do. Navigate to Entra ID → Protection → Conditional Access → What If and enter user, application, device platform, and location parameters to preview which policies apply.

3. Defensive Hardening: Closing the MFA Gaps

Once MFASweep identifies unprotected endpoints, implement the following hardening measures:

Block legacy authentication entirely. Use either security defaults (which automatically block legacy protocols) or create a dedicated conditional access policy:

 Connect to Exchange Online PowerShell
Connect-ExchangeOnline -UserPrincipalName [email protected]

Block basic authentication for all protocols
Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Basic Auth"

Verify legacy protocol access
Get-OrganizationConfig | Format-List DefaultAuthenticationPolicy

Create a comprehensive conditional access policy that includes all cloud applications, all platforms, and all locations. Exclude only explicitly justified service accounts, and require MFA for every authentication attempt. Avoid the common pitfall of using “include” lists that inadvertently omit critical platforms.

Enforce modern authentication across all clients. Disable per-user MFA (deprecated as of September 2025) and migrate entirely to conditional access policies for centralized management.

Monitor for MFASweep-like activity. Attackers using this tool generate specific sign-in patterns. Configure Microsoft 365 audit log monitoring to detect multiple authentication attempts to different services from the same user within a short timeframe:

 Search for suspicious authentication patterns in Unified Audit Log
Search-UnifiedAuditLog -Operations UserLoginFailed,UserLoggedIn -StartDate (Get-Date).AddHours(-24) -ResultSize 1000 | 
Where-Object {$_.UserIds -match "suspicious_pattern"}

4. Advanced Exploitation Techniques Beyond MFASweep

Attackers have developed numerous methods to bypass MFA even when properly configured. Understanding these techniques is essential for building robust defenses.

Evilginx proxy attacks use adversary-in-the-middle frameworks to intercept session tokens. The attacker positions a proxy between the user and Microsoft, capturing both credentials and MFA tokens in real time. When the user completes MFA, the attacker captures the authenticated session and can replay it indefinitely.

OAuth application abuse has emerged as a sophisticated technique. Attackers create malicious multi-tenant OAuth apps that request high-privilege API scopes such as Mail.Read or Files.ReadWrite.All. When a user consents, the attacker gains persistent access without ever requiring the password or MFA again.

Token replay attacks exploit conditional access policies that rely on “session continuity” rather than re-authenticating for every request. Once an attacker captures a valid token, they can reuse it until it expires, bypassing any MFA requirement for subsequent actions.

ConsentFix attack represents the latest evolution in this space. This technique abuses the Azure CLI OAuth app to hijack Microsoft accounts without requiring a password or MFA verification at all.

Mitigation strategies: Implement token binding, shorten session timeouts to 4 hours or less, enforce continuous access evaluation, and regularly audit all OAuth applications approved in your tenant.

5. Building a Complete MFA Testing Program

An effective MFA testing program extends beyond a single tool execution. Implement the following ongoing processes:

Monthly automated testing. Schedule MFASweep execution against a test account using a service principal or automation account. Compare results month over month to detect configuration drift.

Quarterly red team exercises. Simulate credential compromise scenarios where the red team attempts to authenticate using the compromised credential to all Microsoft endpoints. Document which services unexpectedly grant access without MFA.

Post-incident gap analysis. After any security incident or significant configuration change, rerun MFASweep against affected accounts to verify that MFA enforcement remains intact.

Integration with SIEM. Forward MFASweep test results to your SIEM platform (Splunk, Sentinel, or Log Analytics) and create alerts for any detection of single-factor authentication success. The Splunk detection “O365 Multiple OS Vendors Authenticating From User” specifically identifies MFASweep usage patterns.

Documentation and remediation tracking. Maintain a spreadsheet of tested services, expected MFA status, actual results, and remediation owners. Treat any single-factor authentication success as a critical finding requiring immediate remediation.

What Undercode Say

  • Trust but verify is insufficient in cloud identity security. Organizations must actively test their MFA configurations across all authentication endpoints, not assume that enabling MFA on the portal protects the entire ecosystem.
  • Conditional access introduces complexity that becomes the attacker’s advantage. Every exception, every protocol inclusion, and every platform omission represents a potential bypass vector. Default-deny configurations with explicit, justified exceptions are the only safe approach.
  • The credential remains the crown jewel. Whether through phishing, password spraying, or credential stuffing, attackers who obtain valid credentials will systematically test every possible authentication method until they find one that works without MFA.

The landscape of Microsoft 365 authentication has become increasingly complex, with conditional access policies, security defaults, legacy protocols, and federated identities creating a web of interdependent configurations. Attackers have moved beyond simple MFA bypass claims—they have developed sophisticated tooling to systematically identify and exploit these configuration gaps. MFASweep serves both as a red team weapon and a blue team diagnostic tool, but the fundamental lesson remains: MFA is only effective when it is truly universal. Any gap, any exception, any forgotten protocol effectively nullifies the protection for the entire account.

Prediction

By 2027, continuous authentication and risk-based access evaluation will replace static MFA policies as the primary identity protection mechanism. Microsoft will continue phasing out legacy authentication protocols entirely, and security defaults will become mandatory rather than optional. However, as organizations adopt AI-driven identity protection, attackers will shift focus to OAuth application abuse and token theft, rendering traditional MFA increasingly obsolete. The most forward-thinking security teams are already implementing token binding, hardware security keys, and continuous access evaluation as the foundation of their identity security strategy, recognizing that the era of “MFA as a silver bullet” has definitively ended.

▶️ Related Video (80% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Laurent Biagiotti – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky