MFA Prompt Bombing and How to Stay Protected

We’ve written previously on one-time password intercept bots and the threat they pose to multi-factor authentication (MFA) implementations utilizing one-time passwords (OTP) sent through SMS. Now there is a new threat to some less secure MFA implementations known as prompt bombing. This technique was used in the recent Microsoft and Okta breaches. In their forensic report on the breaches, Mandiant explains the MFA prompt bombing process used.

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.

MFA prompt bombing essentially is an attempt to trick a user into completing an MFA security request on their devices. Methods utilized in the attacks include.

• Sending a series of MFA requests and hoping the target finally accepts one to make the noise stop.
• Sending one or two prompts per day. This method often attracts less attention, but “there is still a good chance the target will accept the MFA request.”
• Calling the target, pretending to be part of the company, and telling the target they need to send an MFA request as part of a company process.

The MFA prompt bombing attack vector takes advantage of a design or configuration flaw in some MFA implementations. These implementations utilize a combination of device id and/or biometrics as an authentication factor which is good. The problem is that these factors are being completed on a different device than the device attempting the login. Think of logging in on your laptop but completing a Google Authenticator MFA request on your phone. If your MFA is configured to allow a separate device to authenticate, your risk-based authentication policy should require that both devices be in the same location. This would virtually eliminate the attack vector. Another solution is to require biometric data to be confirmed from the same device that is attempting the login — think of using the fingerprint reader on your laptop instead of your phone in the example above.

Many attacks today are leveraging relatively new techniques such prompt bombing or other forms of social engineering. These attacks take advantage of our flaws as humans and can be avoided through awareness and education campaigns with your employees. Share this information with your team so that when they receive strange authentication requests, they know what is happening and are aware of how to respond. The cyber threats we face today are real and determined but sometimes raising awareness of the latest techniques can give us all the advantage we need.

Even though some MFA solutions aren’t perfect, any MFA implementation is still significantly more secure than password authentication alone. Password-only authentications have their own significant flaws and those unavoidable flaws have begun a needed shift towards passwordless authentication. MFA remains a top implementation on our 2022 cybersecurity checklist and a top Cybersecurity and Infrastructure Security Agency (CISA) defense against ransomware.