MFASweep: Finding the Weak Links in Microsoft’s MFA Enforcement Chain
Hook
Your organization enabled MFA across Microsoft 365, yet attackers with valid credentials can still access critical services using nothing but a username and password. MFASweep reveals which doors you accidentally left unlocked.
Context
Multi-factor authentication has become the baseline security control for cloud environments, with Microsoft reporting that MFA blocks 99.9% of account compromise attacks. But here’s the uncomfortable truth: enabling MFA in your Microsoft 365 admin portal doesn’t automatically enforce it across every service endpoint. Microsoft’s ecosystem is a sprawling collection of APIs, protocols, and authentication methods accumulated over decades—Exchange Web Services, ActiveSync, ADFS, legacy SOAP endpoints, and modern REST APIs all coexist with different authentication mechanisms and enforcement behaviors.
This fragmentation creates enforcement gaps that attackers actively exploit. An organization might enforce MFA for browser-based logins while inadvertently allowing single-factor authentication through legacy protocols or Resource Owner Password Credential (ROPC) flows. MFASweep emerged from this reality as a PowerShell-based offensive security tool that systematically probes multiple Microsoft service endpoints to identify where MFA enforcement breaks down. Created by security researcher Beau Bullock (dafthack), it automates what penetration testers were doing manually: attempting authentication across different Microsoft services to map the attack surface and identify the path of least resistance.
Technical Insight
MFASweep’s architecture is elegantly straightforward—a collection of PowerShell functions, each targeting a specific Microsoft authentication endpoint with tailored request parameters. The tool operates by attempting Resource Owner Password Credential flows, a legacy OAuth 2.0 grant type that allows applications to exchange username and password directly for access tokens without interactive authentication prompts. This is precisely what makes it dangerous in misconfigured environments: ROPC bypasses the interactive flows where MFA challenges typically occur.
The core workflow begins with Invoke-MFASweep, which orchestrates authentication attempts across services including Microsoft Graph API, Azure Management API, Office 365 Portal with different user agents, Exchange Web Services, ActiveSync, and ADFS endpoints. Here’s how the Graph API check works:
function Invoke-GraphAPICheck {
param(
[Parameter(Mandatory=$true)]
[string]$Username,
[Parameter(Mandatory=$true)]
[string]$Password
)
$body = @{
client_id = '1b730954-1685-4b74-9bfd-dac224a7b894'
resource = 'https://graph.microsoft.com'
grant_type = 'password'
username = $Username
password = $Password
scope = 'openid'
}
try {
$response = Invoke-RestMethod -Uri 'https://login.microsoft.com/common/oauth2/token' `
-Method POST -Body $body
if ($response.access_token) {
Write-Host "[*] SUCCESS! Graph API access without MFA" -ForegroundColor Green
return $response.access_token
}
}
catch {
# MFA required, conditional access blocked, or invalid credentials
$errorDetails = $_.ErrorDetails.Message | ConvertFrom-Json
if ($errorDetails.error -eq 'invalid_grant') {
Write-Host "[+] MFA enforced on Graph API" -ForegroundColor Yellow
}
}
}The critical detail here is the client_id parameter—MFASweep uses publicly known Azure AD application IDs for first-party Microsoft applications. These client IDs (like the Azure AD PowerShell module ID shown above) are not secrets; they’re constants embedded in Microsoft’s own tools. The genius of this approach is that it mimics legitimate Microsoft application behavior, making detection more challenging than custom application registrations would be.
Each service check follows this pattern but with variations. The Office 365 Portal checks cycle through different user agent strings (Windows, MacOS, Linux) because conditional access policies can be configured to trust certain platforms differently. ActiveSync uses Basic authentication with XML payloads instead of OAuth tokens. EWS attempts include both Modern Auth (OAuth) and Basic Auth variants. This comprehensive approach is what makes MFASweep valuable—it doesn’t just test one authentication path, it systematically probes the entire ecosystem.
The tool maintains state by exporting successful access tokens to AccessTokens.json, creating a reusable credential cache. This is particularly useful in red team engagements where you might gain initial access through phishing with single-factor credentials and need to understand which services are immediately accessible versus which require additional MFA bypass techniques. The JSON export also enables integration with other tools in the offensive security toolkit.
One architectural decision worth noting is the tool’s deliberate choice to remain a simple PowerShell script rather than a compiled binary. This keeps the code transparent and easily auditable (critical for security tools), allows defenders to understand exactly what’s being tested, and ensures compatibility across Windows environments without dependency hell. Each function can be imported and executed independently, giving operators granular control during engagements.
Gotcha
The most significant limitation is the account lockout risk. MFASweep generates 10-11 authentication attempts in a full sweep, and if you’re testing with incorrect passwords or accounts with aggressive lockout policies (typically 3-5 failed attempts), you’ll lock the account before completing the assessment. There’s no built-in throttling or backoff mechanism, so operators need to understand the target environment’s lockout policies before execution. This isn’t a tool you can spray blindly across a list of accounts.
The effectiveness of MFASweep also diminishes rapidly as organizations mature their security posture. Microsoft has been steadily deprecating legacy authentication protocols, and organizations following security best practices should have already disabled Basic Auth for Exchange Online, blocked ROPC flows through conditional access policies, and enforced authentication policies that MFASweep relies on to identify gaps. If an organization has properly configured Security Defaults or comprehensive conditional access policies that block legacy authentication entirely, MFASweep will show everything as protected—which is the desired outcome for defenders but limits the tool’s utility for finding exploitable gaps. Additionally, the tool doesn’t capture tokens for EWS, ActiveSync, or ADFS endpoints despite testing them, which means you can identify that these services accept single-factor auth but can’t immediately leverage that access without additional manual steps.
Verdict
Use if: You’re conducting authorized penetration tests or security assessments of Microsoft 365 environments and need to validate MFA enforcement and conditional access policy effectiveness across the full spectrum of Microsoft authentication endpoints. This tool is particularly valuable for organizations with hybrid identity (on-premises AD with ADFS) or those migrating from legacy authentication protocols where you need concrete evidence of which services remain vulnerable to single-factor authentication. It’s also essential for red team engagements where you’ve obtained credentials through phishing or password spraying and need to quickly map what’s accessible. Skip if: You don’t have explicit written authorization for security testing, you’re working with accounts that have strict lockout policies without a recovery mechanism, the target organization has already disabled legacy authentication and implemented Security Defaults or comprehensive conditional access policies (in which case the tool will simply confirm everything is protected), or you’re looking for a general-purpose M365 administration tool—this is strictly an offensive security instrument designed to find weaknesses, not manage environments.
