Multi-Factor Authentication – Prompt spamming and Fatigue Attacks
MFA 101
Multifactor Authentication (MFA) for authentication has become an essential component of many cybersecurity strategies. It is the process of using two or more factors to validate a user’s identity. The three common factors used in MFA are:
- something you know, like a password or PIN;
- something you have, like a mobile device; and
- something you are, like a fingerprint, optics or voice.
For those coming to the MFA party a bit late, enabling MFA strengthens your security by ensuring an attacker must have access to more than one of these authentication factors to breach your systems successfully.
Passwords and PINs can be susceptible to leaks, successful guesses, or brute-force and phishing attacks. Therefore MFA supplements these fundamental measures with other factors, such as something you are (fingerprint) or something you have (unique mobile device) for additional protection. Current tools for enabling MFA include SMS, One Time Passwords (OTP), and push notifications from an Authenticator App.
MFA is one of the best cybersecurity controls an organisation can implement and is therefore strongly recommended; however, it suffers from both human and technical weaknesses, which means that it is not a silver bullet. Increasingly we see attacks that target and successfully bypass MFA protections.
Attacks against MFA
On a daily basis (particularly in large organisations or those with multiple systems), users are now bombarded with notifications, emails, alerts and pop-ups asking them to accept authentication requests. As a result of this overload, users experience “acceptance fatigue”, which increases the risk of users clicking, swiping, or accepting notifications without genuinely looking at what they are.
Cybercriminals are taking advantage of this acceptance fatigue by conducting attacks that flood a user’s authentication app with push notifications, hoping they will accept and enable entry to an account or device. Sometimes called MFA Prompt spamming or MFA Fatigue Attacks, these relatively simple techniques are effective as they target the human factor using social engineering.
In an MFA prompt spamming attack:
- The adversary uses previously stolen valid username/password credentials to log in to an account protected by push MFA and does this multiple times in succession;
- The victim then receives valid push notifications (generally to a mobile app of some sort) over and over;
- Eventually, the user (or a child using their parents work mobile device for gaming) tires of this notification flood and taps “yes” instead of “no.”
Often, users will accept the notification because they are distracted or overwhelmed by the notifications. However, in some sophisticated cases, the attack can be misinterpreted as a bug or a legitimate request. For example, a child on their parent’s phone swiping yes to rid the screen of a pop-up that stands in their way of watching YouTube.
The cyber security company Mandiant recently reported on the ongoing activity of UNC2452 (a Russian-state-sponsored APT group) that use these techniques to successfully bypass Multi-Factor Authentication (MFA) and compromise their targets. This highlighted that MFA fatigue is proving troublesome globally even though it is not a sophisticated technical attack.
Prevention
MFA is an effective tool if configured well and used appropriately. Some suggestions for preventing MFA fatigue and combatting attacks on MFA are to:
- Consider using adaptive authentication methods. These methods leverage tools to minimise the number of login events and avoid users becoming bombarded by them. For example, they may only challenge using MFA when there is a known level of risk. Reducing the number of alerts keeps users from being de-sensitised to them.
- Protect against credential compromise. As these attacks usually rely on previously compromised credentials protecting identity is critical. To achieve this, some basic steps such as enabling MFA for all users in all locations and blocking easily guessed passwords should be used.
- Be strict in the period in which users must enrol themselves when introducing MFA to your organisation.
- Track alerts for new MFA and MDM device enrolments.
- Move away from legacy authentication protocols such as SMTP, IMAP, and POP. Many legacy authentication protocols cannot support MFA, and if these still exist within your organisation, they leave a possible hole in your defences, regardless of MFA use elsewhere. Microsoft provides a list of legacy authentication mechanisms that you should consider deprecating.
- Regularly review and test your organisation’s MFA implementation and consider a review against an industry-accepted benchmark such as the CIS control benchmarks.
- Specific configurations to enhance MFA security in Microsoft environments and reduce MFA fatigue include:
- Enabling Azure MFA number matching/ MFA codes. These present a number to the user that they must type into the app to complete approval.
- Implementing impossible travel detections
- Implementing advanced authentication features using geography.
- Implementing Identity Protection (Azure ID protection detects events such as atypical travel, malicious IP addresses, leaked credentials and more.)
- Enabling the Additional Context in Notifications. These show the end-user which application is performing the MFA request.
- Regularly review your enterprise app/OAuth consents in your Microsoft 365 tenancy. Check the name of the applications being granted, the permissions the applications have been granted, and the application author’s validity.
Finally, improve user awareness of MFA spamming and social engineering attacks. Raising and enhancing understanding of MFA spamming and other new tactics is vital to ensure user vigilance. Ensure that users are aware that not all MFA requests are correct and educate them on how to detect and report malicious attempts.
Click here if you wish to subscribe to our Premium Edition of the Bulletin.
This Bulletin is prepared for general guidance and does not constitute formal advice. This information should not be relied on without obtaining specific formal advice. We do not make any representation as to the accuracy or completeness of the information contained within this Bulletin. Incident Response Solutions Limited does not accept any liability, responsibility or duty of care for any consequences of you or anyone else acting, or refraining to act, when relying on the information contained in this Bulletin or for any decision based on it.
Incident Response Solutions 