MFA prompt spamming/ MFA fatigue – What can you do to prevent/ detect attacks?
MFA prompt spamming/ MFA fatigue is a quite new term and seeing more after the LAPSUS$ attack. Currently there are many MFA options including SMS, One Time Passwords (OTP), and push notifications from the Microsoft Authenticator app. And while the intent of these methods is to provide extra protection, attackers use new ways of attacks. Push Notification/ MFA Fatigue/ MFA spamming is a trending topic in combination with the more recent adversary-in-the-middle phishing attempts.
The most common question when discussing MFA prompt spamming; MFA is secure right? Yes – it depends on the type of MFA. Of course, it’s better than no MFA configured. SMS is always better in comparison without any second factor enabled.
Blog updated: 14-07-2022 (Adding adversary-in-the-middle (AiTM) and general information.
MFA fatigue attack introduction
For years ‘MFA prompt spamming’ is a well-known attack vector and used in the real world for 2 years. Since Lapsus$ there is a lot of noise on the internet around MFA Prompt spamming. Let’s start with an introduction.
When the username/password is available, you can just generate an MFA prompt (via push, call, etc). MFA prompt spamming is a well-known attack where the victim is generating MFA prompts and hopes the user/target accepts the MFA request. They keep spamming until they accept the MFA prompt that allows them to get initial access.
Lapsus$ highlighted the weaknesses of certain MFA options. Specifically push approvals. Once they had the victim’s credentials, they would simply spam users with MFA prompts until they got approved.
A member of Lapsus$ wrote on the group’s official Telegram chat channel.
“Call the employee 100 times at 1 am while he is trying to sleep, and he will more than likely accept it. Once the employee accepts the initial call, you can access the MFA enrollment portal and enroll another device.”LAPSUS$ Telegram
Mandiant created the following report about Russian APTs using the same MFA Prompt spamming technique. Mandiant reports the following:
Mandiant has also observed the threat actor executing multiple authentication attempts in short succession against accounts secured with multi-factor authentication (MFA). In these cases, the threat actor had a valid username and password combination. Many MFA providers allow for users to accept a phone app push notification or to receive a phone call and press a key as a second factor. The threat actor took advantage of this and issued multiple MFA requests to the end user’s legitimate device until the user accepted the authentication, allowing the threat actor to eventually gain access to the account.
What is Push Notification Spamming?
This technique is simple and only requires the attacker to manually, or automatically, send repeated push notifications while trying to log into the victim’s account. The credentials could be obtained via password reuse, password spraying, or brute-forcing. Once the attacker obtains credentials, they can perform the Push Notification spamming.
Recent investigations have shown a significant increase in the number of attacks that leverage Push Notification Spamming, Many MFA users are not familiar with this type of attack and would not understand the fraudulent MFA request.
When the message below appears during work, what is the chance after multiple MFA valid requests, that the users will accept them?
What can we do to stop this?
There are several important steps that can be configured for the environment. Below are some ideas which can be implemented based on Microsoft technology. Most important is awareness and reporting real attempts.
- Implement Impossible travel detections
- Implement advanced authentication features using geography
- Enable Azure MFA number matching/ MFA codes
- Implement Azure AD Identity Protection (blog)
- Track alerts for new MFA and MDM device enrollments
- Collect AzureAD/ MFA events in Microsoft Sentinel
- Protect against password spray (blog)
Multifactor authentication (MFA) is one of the primary lines of defense against MFA prompting spamming, there is a huge difference in MFA methods
Some Identity recommendations:
- Require MFA for all users on all locations
- Use Microsoft Authentication with number matching enabled or FIDO tokens
- Start testing password-less
- Create sign-in risk-based policies that block high-impact actions like device enrollment and MFA registration
- Keep break-glass accounts offline and not part of online password managers
- Block easily guessed passwords with Azure AD Password Protection
Now some technical explanation of MFA number matching / Geographical context.
Enable Azure MFA number matching
Number matching is currently in public preview. Microsoft gives the following explanations and marks the feature as a key security upgrade to traditional second-factor notifications in the Microsoft Authentication app.
Number matching is a key security upgrade to traditional second-factor notifications in the Microsoft Authenticator app that will be enabled by default for all tenants a few months after general availability (GA). We highly recommend enabling number matching in the near-term for improved sign-in security.Microsoft
Number matching gives improvements against MFA Prompt spamming and will increase the security posture of MFA Authentication prompts. When a user responds to an MFA push notification using Microsoft Authentication, they will be presented with a number. The user needs to type that number into the app to complete the approval.
Read the Microsoft Docs for ADFS adapter/ NPS extension implementation.
To enable number matching in the Azure AD portal, complete the following steps:
- Go to Azure Active Directory -> Security -> Authentication Methods
- Within the blade Authentication methods click on Policies and select Microsoft Authenticator
Under Microsoft Authenticator, choose Enable (1) and target all users or selected users (2). Recommended is to start with Select users and configure some test groups. If you select a group so you can pilot this change, the configuration will impact the group and not all users.
The three dots (3) on the right gives more options for the configuration. The default is “Any” which allows the users to configure push MFA or passwordless authentication. Click on configure.
For the Azure AD number matching feature make sure the setting; Require number matching (preview) is enabled. Microsoft Managed means that the feature will be enabled by default for all tenants after the General availability of the feature.
We are now done with the number matching configuration, the user’s next MFA attempt will show a code on the screen and require it to be entered. Make sure the user is added to the configured group for the feature.
Azure MFA experience without number matching
Azure MFA number matching experience
During the sign-in and the following experience is visible. As you can see, this way of MFA is way more secure in comparison with the general MFA accept prompt.
Show additional context in notifications
Another improvement for the security posture is the enablement of the Additional Context in Notifications. Additional Context in Notifications shows the end-user which application is performing the MFA request. For the end-user the app and location ( based on IP) are directly visible from the main screen.
For enabling the new Additional Context in Notifications feature, follow the previous MFA matching steps and enable the following configuration:
Additional context in notifications experience
During the sign-in and the following experience is visible. As you can see, in comparison with only the number matching feature, there is more information visible. ( App name, Location).
Implement Azure AD Identity Protection
Azure AD Identity Protection is important and protects users based on the Microsoft threat signals. Azure AD Identity protection is all about risk, detection, and remediation based on the identity level. Microsoft uses threat intelligence to specify risky detection for all users. MFA prompt spamming can be resolved when the password is safe. Important is to make sure no credentials are leaked or another malicious activity is detected. MFA spamming starts always with leaked credentials of the user.
Azure AD Identity Protection detects for example;
- Atypical travel
- Unfamiliar sign-in properties
- Malicious IP address
- Password spray
- Impossible travel
- New country
- Leaked credentials
Microsoft explains all the detections for sign-in and user-linked detections.
Previously the following blogs focused on Azure AD Identity Protection were created:
- Azure AD Identity Protection: User Risk and Sign-in Risk protection with automation
- Identity Protection Risk Analysis workbook: Get more Azure AD Identity Protection insights
- Stream Azure AD Identity Protection events to Microsoft Sentinel/ Log Analytics
- Protecting against password spray attacks with Azure Sentinel and Azure AD
Hunting for data
Log Analytics or Microsoft Sentinel can be used to analyze the queries and create detections. Based on KQL some queries can be created for detecting possible malicious attempts.
SigninLogs contains interesting data for checking the MFA status.
MFA status denied by the user
SigninLogs | where ResultType == 500121 | where Status has "MFA Denied; user declined the authentication" or Status has "MFA denied; Phone App Reported Fraud"
MFA status denied (user did not respond)
SigninLogs | where ResultType == 500121 | extend AuthResult = tostring(parse_json(AuthenticationDetails).authenticationStepResultDetail) | where AuthResult in ("MFA denied; user declined the authentication","MFA denied; user did not respond to mobile app notification")
KQL from the community
The community created interesting queries.
- Detect MFA registration followed by Self Service Password Reset(SSPR)
- Detect MFA changes from Unknown IP
- Detect when a user denies MFA several times within a single sign-in attempt and then completes MFA
- Identity SummarizeMFAFailures
Check the Reprise99 Github for more identity/ MFA queries that can be used for extra monitoring.
Improve awareness of MFA spamming/ social engineering attacks
Social engineering attacks are not new and will increase when more users are protected with MFA. Microsoft recommends raising and improving awareness of social engineering/ MFA spamming and other new tactics to protect your organization.
Train the user that not all MFA requests are correct and how the user can detect malicious attempts. Many MFA users are not familiar with this type of attack and would not understand they are approving a malicious MFA notification. Number matching and additional context improve the MFA security posture.
Detected by Microsoft 365 Defender Research Team, currently 14-07-2022 there is a large-scale phishing campaign that used adversary-in-the-middle (AiTM) phishing sites. Even if the user had enabled multifactor authentication (MFA) the attacks used the stolen credentials and session cookies to access affected users. Microsoft explains the AiTM attack more in-depth.
MFA provides an added security layer against credential theft, attackers are also finding new ways to bypass the MFA security. In AiTM phishing, attackers deploy a proxy server between a target user and the website. Examples are Evilginx2, Modlishka, and Muraena.
Above preventions against MFA spamming are not relevant for AiTM phishing. Important for protecting against AiTM is enabling the complete threat stack; including Defender for Office 365, Defender for Cloud Apps, Azure AD Identity Protection, and Continuous Access evaluation (CAE).
AiTM threat activity can be detected using the following threat activity based on Microsoft 365 Defender products:
- Defender for Office 365
- Email messages containing malicious file removed after delivery
- Email messages from a campaign removed after delivery
- Defender for Cloud Apps
- Suspicious inbox manipulation rule
- Impossible travel activity
- Activity from infrequent country
- Azure AD Identity Protection
- Anomalous Token
- Unfamiliar sign-in properties
- Unfamiliar sign-in properties for session cookies
- Anonymous IP address
More threat/ protection information can be founded here.
In addition to the MFA spamming prevention, it is recommended to use additional Conditional access policies focussing on identity-driven signals, IP location, device status, and more device and identity-related controls.
Hopefully, this blog gives some insights into new attacks like MFA spamming/ MFA fatigue. Of course, above solutions are some preventions that can improve the security posture. There are more preventions and hunting options available.
The new (public preview) MFA number matching feature can be effective against this “MFA fatigue/ spamming” tactic because users won’t know 2 digit code presented and can’t accidentally approve a request.
Microsoft: Use number matching