Listen to this Post
Introduction:
Multi-Factor Authentication (MFA) was once the undisputed champion of account security, but a new social engineering technique known as MFA Fatigue is systematically dismantling its defenses. This attack exploits human psychology rather than technical flaws, bombarding users with push notifications until they succumb to approval, granting attackers immediate access to critical systems. Understanding and mitigating this threat is paramount for every cybersecurity professional.
Learning Objectives:
- Understand the mechanics and psychology behind MFA Fatigue attacks.
- Implement technical controls within Microsoft Entra ID (Azure AD) and Okta to mitigate attack success.
- Develop user awareness and reporting protocols to identify and respond to ongoing attacks.
You Should Know:
1. The Anatomy of an MFA Bombing Campaign
Attackers leverage compromised credentials to initiate a flood of MFA push notifications to the target’s authenticator app (e.g., Microsoft Authenticator). The sheer volume, often coupled with context like location data from the initial sign-in attempt, creates pressure and confusion, leading the user to accidentally “Approve” the request.
- Hardening Microsoft Entra ID (Azure AD) Against MFA Fatigue
Microsoft’s identity platform provides critical number matching and location context features to combat this threat.
Command/Configuration Snippet (Azure AD):
Connect to MSOL Service (if using older MSOnline module) Connect-MsolService Or Connect to Microsoft Graph (Modern recommended) Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess" Enable Number Matching for all users via Authentication Methods Policy (Modern Auth) This is primarily configured in the Azure Portal under: Security > Authentication methods > Microsoft Authenticator Enable "Require number matching for push notifications"
Step-by-Step Guide:
- Navigate to the Azure Portal > Azure Active Directory > Security > Authentication methods > Policies.
2. Select Microsoft Authenticator.
- Under Configure, target your desired users (e.g., “All users”).
4. Set Enable and Target to `Yes`.
- Under Authentication mode, select Require number matching for push notifications. This forces the user to type a number displayed on their sign-in screen into their app, preventing accidental approval.
- Additionally, enable Show application name in push and passwordless notifications and Show geographic location in push and passwordless notifications to provide user context.
3. Configuring Okta Verify with Number Challenge
Similar to Azure AD, Okta offers built-in security features to require user verification for each push.
Command/Configuration Snippet (Okta Admin Console):
While Okta configurations are primarily GUI-based, you can use the Okta API to enforce policies programmatically.
Example API call to update a policy rule (conceptual)
PUT /api/v1/policies/{policyId}/rules/{ruleId}
{
"actions": {
"signOn": {
"access": "ALLOW",
"requireFactor": true,
"factorPromptMode": "ALWAYS",
"rememberDeviceByDefault": false,
"factorLifetime": 15,
"session": {
"usePersistentCookie": false,
"maxSessionIdleMinutes": 120,
"maxSessionLifetimeMinutes": 480
}
}
},
"conditions": {
"people": { ... },
"network": { ... }
}
}
Step-by-Step Guide:
1. Log in to your Okta Admin Console.
2. Go to Security > Authenticators.
- Select Okta Verify and ensure it is Active.
- Check the box for Number Challenge to enforce number matching.
5. Navigate to Security > Authentication Policies.
- Edit your global session or sign-on policy and ensure the factor prompt is set appropriately to challenge users for MFA.
4. Implementing Conditional Access Geofencing and Trusted IPs
Restricting MFA prompts to only originate from expected networks can drastically reduce the attack surface.
Command/Configuration Snippet (Azure CA Policy):
Creating a Named Location for Trusted IPs (e.g., Corporate HQ IP ranges)
New-AadIpConditionalAccessPolicy -Name "Trusted Network Locations" -IpRange @("192.168.1.0/24", "10.10.0.0/16") -IsTrusted $true
This creates the location condition used in a CA policy built in the portal.
Step-by-Step Guide:
- In Azure AD > Security > Conditional Access, create a new policy.
- Name it (e.g., “Block MFA outside trusted locations”).
- Under Users and groups, select all users or critical admin groups.
4. Under Cloud apps, select All cloud apps.
5. Under Conditions > Locations, configure:
Include: `Any location`
Exclude: `All trusted locations` (This is the list of IPs you defined earlier).
6. Under Access controls > Grant, select Block access.
7. Enable the policy and select Create.
5. Leveraging Microsoft Graph API for Continuous Monitoring
Automate the detection of anomalous MFA requests by querying sign-in logs for a high volume of failures or duress triggers.
Command/Configuration Snippet (Microsoft Graph API Call):
Example Graph API call to filter sign-in logs for multiple MFA failures on a user account GET https://graph.microsoft.com/v1.0/auditLogs/signIns? $filter=( createdDateTime ge 2024-05-20T00:00:00Z and createdDateTime le 2024-05-20T23:59:59Z and userDisplayName eq 'Alice Doe' and status/errorCode eq 50140 and mfaDetail/authMethod eq 'MicrosoftAuthenticatorPush' )
Step-by-Step Guide:
- Use an API client like Postman or automate with PowerShell (
Invoke-MgGraphRequest). - Authenticate with an app registration possessing the `AuditLog.Read.All` permission.
3. Query the `/auditLogs/signIns` endpoint with filters for:
`status/errorCode eq 50140` (This specific code often indicates a user dismissing an MFA prompt, which could indicate fatigue).
`mfaDetail/authMethod eq ‘MicrosoftAuthenticatorPush’`.
A high count of these events in a short time for a single user is a critical alert.
- The Last Line of Defense: User Training and Phishing-Resistant Factors
Technical controls are ineffective without user awareness. Train users to:
Never approve an unexpected MFA request.
Immediately report any barrage of notifications to the IT/Security team.
Use the “Deny” button, which can often be configured to report the attempt as fraudulent.
Ultimately, migrate high-privilege accounts to phishing-resistant MFA like FIDO2 security keys (e.g., YubiKey), which are immune to MFA fatigue and push phishing entirely.
What Undercode Say:
- MFA is No Longer a Silver Bullet. Its effectiveness is now contingent on intelligent configuration and user vigilance. Relying on basic push notifications is a significant security risk.
- The Future is Phishing-Resistant. The long-term solution lies in adopting FIDO2/WebAuthn standards. Security keys and Windows Hello for Business provide a seamless user experience while completely neutralizing MFA fatigue, push phishing, and even password theft.
The MFA fatigue attack is a powerful reminder that security is a human-centric challenge. While pushing for stronger, phishing-resistant authentication methods is the ultimate goal, immediate action is required. Organizations must diligently configure number matching, implement granular conditional access policies, and foster a security culture where users are empowered to recognize and report these attacks. The window where simple push MFA was considered secure has officially closed.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: https://lnkd.in/p/dmyTwUtb – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
