Combatting MFA Fatigue and Preventing Prompt Bombing Attacks

We are now regularly seeing the jarring results of successful push bombing attacks as the tactic becomes a common attack method. Today, organizations are facing more multi-factor authentication (MFA) push bombing attacks, where an attacker generally already has one of the authentication factors, such as \username/password. The attacker then can request push notifications that will go to the user’s smartphone.

Prompt bombing attacks rely on MFA fatigue. Even though getting an unexpected push notification is not a normal occurrence, the user may approve the request. Even if the user makes the right choice and denies the request the first time, they may get worn down or confused by the messages. Just one ‘allow’ is needed and the attacker is then authenticated. Depending on the structure of the environment and other security controls in place, that may give the threat actor access to corporate applications, networks or files. We recently detailed the specifications that ID Plus uses to detect and protect against these attacks in a blog called Protect Against MFA Prompt Bombing Attacks.

Dealing with MFA fatigue is an interesting security challenge for most organizations. Although this type of attack should not be an everyday occurrence, if it happens, your security team needs to know about it and respond. Not only does it mean you are under attack, it also likely means some credentials are already compromised. Prompt bombing fits into the category of low occurrence and high risk. This post outlines some of the fundamental methods of dealing with this type of attack from the perspective of a security operations team.

To be prepared for Push Bombing and combatting MFA Fatigue, you need to start with the human element.

• User awareness. Users need to be more than aware: they need to be informed, vigilant, and concerned. But, at the same time, fostering cybersecurity awareness needs to be easy for them or they will fail. Taking a once-a-year security awareness training may satisfy compliance needs, and does provide some benefit, but it’s not enough to combat a sophisticated attack. Users should be told that if they did not initiate a communication, then they should consider it suspect. If users have the right tools and training, they may stand a chance.
• User education. Make sure that your end users know it is possible that they could get a bad push-to-auth request, and that they should not automatically click ‘ok’ on that same dialog they have seen 100 times. For this message to reach some or most users, your security program should have some type of regular communication to users along with a way to persist the communication—consider an e-mail alert, post the alert to a persistent blog page that all users can access, and add links to the alert in other company documentation, your security landing page, or make it a theme for Cyber Security Awareness Month.
• User resources. Remember that to successfully execute on MFA Fatigue and Prompt Bombing attacks, an attacker more than likely already has a user’s credentials. More advanced attackers will start the spear phishing and could send SMS, WhatsApp alerts, phone calls, or e-mails to the user to add confusion to the MFA Fatigue. For users to be able to counteract these attempts, they need to be confident in how to report an issue, and really understand how their Help Desk, Service Desk, and Security team communicate with them. Again, here the awareness is not about an annual training, but a persistence of communication to the users and a general understanding of how to find needed resources and how things should work. If every user knew to call the ServiceDesk immediately and the ServiceDesk has up-to-date documentation, or even if someone on the team just recalls this resource exists and can locate it, then your organization is well positioned.
• User actions. A user with no resources who is not trained is a good target. Do users know to always request contact the Service Desk via the appropriate tools (Teams, Slack, etc.) and not accept any phone calls without a verified communication coming in first? Set expectations and give a way to verify if the user is unsure.

To summarize, you should ask these questions about your security program and use the answers to enhance your processes as needed:

• Do users know what to do if they get an unexpected push auth request?
• Can users quickly report a security issue?
• Do all users know how to contact your Service Desk?
• Does your Service Desk know how to respond to a security issue?
• Do users have a means of reaching directly to the Security Team?
• Do users know how the Service Desk would legitimately contact them, and that contacts outside of that mechanism should not be trusted?
• Do users know how to validate a contact is legitimate?

The first way to prevent MFA fatigue is not to allow it to happen. Not using passwords eliminates the main attack vector: a username and password pair that can persist for months. Consider using FIDO for your primary factor. But FIDO may not be practical for everyone just yet—and if that’s the case, then what should you do instead?

As is often the case with security, the best technical prevention is a multi-layered defense. Here are a few of the things to consider. Pick the ones that best fit your environment:

• If you still rely on usernames and passwords, ensure you have at least a password vault in place or, even better, a full Privileged Authentication Management (PAM) solution for your most sensitive access. Also ensure that it’s being used properly; it may be time for a health check
• If there is any suspicion of compromised credentials, force a password reset. Doing a reset will prevent push bombing in the future.
• Even though it’s not best practice to arbitrarily change passwords (for a number of reasons), forcing a password change does limit the time that compromised credentials can be easily used for push bombing.
• Review your MFA configuration to ensure that the access patterns make sense. It is possible to configure even the best MFA solutions to allow too much access with limited verification.
• Common sense password best practices also apply. Educate users to explain why they should not share passwords between services. That way if a compromise does occur, it will limit the attack surface for push bombing.
• If you are relying on push authentication too much or to protect data that is too sensitive, consider increasing the frequency of requests for one-time passwords (OTP) using soft or hard tokens. OTP requests will be seen by the attacker in an attack scenario and not ever make it to the user.

To detect a false push authentication request programmatically, you may need a lot of things to work successfully. Logs from your authentication system must be set at the right level, sent to the proper log collector, parsed properly, and content must be in place to generate an appropriate alert. From there, a watchful 24/7 Security Operations Center (SOC) must receive and recognize this alert with an up-to-date runbook on what to do next. This doesn’t sound easy, and it’s not. A variety of tools and mechanisms can reduce the effort involved, but the main point is that you need to identify the log event you care about, consider the thresholds that matter to you, and figure out what actions you need to take when you get an alert and validate the whole process.

You may want to consider having a meaningful alert for one push auth rejection and tune down if that makes too much noise. Remember, if your users are well-trained, they may let you know of an issue very quickly. They may even be faster than a SIEM can parse the logs, get the alert out, and the SOC can detect and respond to it. It’s always good to have a backup plan and multiple layers of security and monitoring.

Review the log events and what-if scenarios based on an attack. You need to ensure that you identify and receive the right data. Check for a log event specific to a user denying a push request as the top item of interest. Another item of interest is abandoned push auth requests.

Remember that detecting a bad push request means that you likely have also detected a credential compromise. So, even if a user says “No” to the push request, you may already be at some risk if there is any place in your enterprise network that a username/password combination could allow access. If you have detection for bad push auth requests, it can serve as a detection mechanism for compromised credentials.

RSA users can see how ID Plus uses risk-based authentication and other features to detect and defend against prompt bombing.

The appropriate response to push-bombing depends on the threshold you are comfortable with. But even with one unexpected Push to Authenticate, a user should have sessions dropped and be forced to change their password. Remember, this should be a low-occurrence event. Be safe, not sorry. Changing the password will also prevent potential future attacks with those specific user credentials.

Even though passwords are showing their age, if they are part of the MFA in your organization, develop and document a trusted process to force a password reset and get advance leadership buy-in to pull the trigger on password change and session revocation at any suspected compromise. The longer an attacker has some access on your network, the more damage they can do. Factor in response time. Quickly and proactively reach out to users or their managers on a trusted channel if you receive an alert and determine the right contact mechanism for your organization, such as an e-mail form letter, to let users and their managers know what happened and get them on alert. Communication goes a long way in building trust that will pay dividends for any future security concerns.

Keep in mind that push-bombing is one type of attack, and you should prioritize any response to it in your overall program related to the likelihood and risk to your environment. If an attacker succeeds, you will have to rely on your other security controls to limit damage and ensure that you can quickly recover.