Protect Against MFA Prompt Bombing Attacks

With the recent news of successful multi-factor authentication (MFA) prompt bombing attacks RSA has been increasingly asked for guidance on defending against these types of attacks. Previously, we shared a blog post detailing how attackers take advantage of MFA fatigue and use prompt bombing to gain access. In this post, we focus on specific configurations within ID Plus that can be used to detect and defend against these types MFA Fatigue and Prompt Bombing attacks.

Not all authentication factors are created equal. Although RSA might be best known for pioneering hardware-based one-time passcode (OTP) authentication, both technology and RSA have evolved. The proliferation of smartphones has facilitated the widespread adoption of convenient MFA. One approach that has gained widespread adoption is to send a push notification to a smartphone application with the option for the user to approve or deny.

In this case, the user enters their password and responds to this push notification on their smartphone or smart watch. If the user chooses approve, access is granted; if the user chooses deny, access is denied. This method works well as it eliminates the need to provide a physical authenticator (hardware token). It is convenient for the user and is not vulnerable to SIM-swapping attacks the way SMS-based authentication is.

Although it is more convenient, push-based authentication relies on the user to identify and deny any authentication attempt that they did not initiate, which makes this method susceptible to prompt bombing attacks in a way that one-time passcodes are not.

A user can prove possession of a secondary device (e.g. a mobile phone or a security key) in a number of different ways. One-time passcodes are a common way to accomplish this, and the FIDO standard, which uses PKI, is quickly gaining popularity. The key here is to understand that different authentication methods have different strengths and weaknesses. In some cases, certain authentication methods trade security for convenience. Although it may sound like a bad trade-off, convenience helps drive adoption.

Let’s use my front door as an analogy. I could install four deadbolts on my door to make it harder for someone to break in. Is that increase in security worth the tradeoff in convenience or does a single deadbolt strike the right balance between security and convenience?

The key to a successful MFA implementation is to understand the strengths and weaknesses of different authentication methods and to strike the right balance by enabling more convenient authentication methods when appropriate and requiring stronger methods (which might be less convenient) when the risk dictates it.

Within the ID Plus platform, each authentication method is assigned to an assurance level. The administrator then creates policies that determine which assurance level is required. This policy engine is extremely flexible (you can read more about it here). Based on the assurance level required by the policy, the user is presented with a list of authentication options that meet the required assurance level.

In addition to using static policies to determine the required assurance level, ID Plus also has the ability to take a more dynamic approach. We call this feature Identity Confidence. The identity confidence engine analyzes each authentication attempt in real time using a variety of factors and returns a high or low confidence score. This result can also be used within policies to require a specific assurance level. The confidence score can be used alone or in combination with other conditions within the policy.

A practical application of this feature could be to allow a convenient push notification when the confidence score is high but require a stronger factor if the confidence score is low. A malicious authentication attempt using compromised credentials originating from an unrecognized device and an unfamiliar location would trigger a low confidence score. Based on the policy, the actor would be asked for an OTP or security key and would be unable to trigger a push notification to the legitimate user’s phone.

Another feature of ID Plus is the high-risk user list. This feature provides an interface for security tools to mark a user as high risk. Solutions like NetWitness or Azure Sentinel can be used to mark a user as high risk based on activity or alerts seen outside of the ID Plus platform. Using the policy engine, a high-risk user could be denied access to the application or required to provide a high-assurance authentication method to gain access.

Returning to the front door example, suppose instead of adding additional deadbolts, I installed a camera. The camera would allow me to monitor and be alerted to any attempts to defeat my deadbolt. Similarly, monitoring and alerting on authentication activity provides valuable insight. In the context of prompt bombing attacks, users will often deny the first unrecognized attempt(s) but could eventually approve one if the attacker sends enough attempts. By monitoring event logs and creating alerts on suspicious patterns, you can gain visibility and alert your security team to investigate potential or successful attacks.

Each authentication event in ID Plus is logged with specific details for each step in the process (the complete list is located here).  Below are some specific event IDs that we recommend monitoring, as repeated occurrences could be the sign of a prompt-bombing attack:

After successfully gaining access, whether through prompt-bombing or some other method, a common technique is to register a new MFA device. In addition to securing the enrollment process by requiring more than simply a password for MFA enrollment, RSA also recommends enabling email notifications, which provides an additional notification to a user who may have approved a malicious login that a new authenticator has been enrolled or that their existing authenticator has been deleted.

To protect against prompt bombing attacks and MFA fatigue:

• Educate users on the danger of approving an unrecognized authentication prompt and encourage them to report these to your security team and change their password if this occurs.
• Consider using alternative authentication methods for certain applications or situations. Identitify confidence and the high-risk user list can be a great help.
• Monitor logs for denied or timed-out push requests and generate alerts when they are spotted in succession.
• Secure the MFA device enrollment process.
• Enable email alerting for device changes.