With MFA Bombing/Prompt Bombing, What do you do?

This is contributed by Christopher Laasch, Lead Security Analyst at Cal Poly Pomona having been there for 23 years.  I have provided some edits to make it flow in a blog.

We are seeing an uptick of Multifactor Authentication (MFA) Bombing or "Prompt Bombing" Attacks, and I was given a wonderful elaborate breakdown from my Colleague Christopher Laasch, who kindly allowed us to share on our blog this week.  This is a high level breakdown of how to explain this attack to users and executives alike and improve security in the face of attackers trying to compromise your MFA.


Overview from the users perspective:

MFA prompt bombing is an attempt to trick a user into completing an MFA security request. In these cases, the threat actor has the users password and username. They then social engineer the user into helping them bypass MFA. The methods used are:  

  • Sending a series of MFA push requests to the users device hoping the targeted user finally accepts one to make the noise stop.
  • Sending one or two prompts per day similar to avoid raising suspicion.  This method 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.

Question: How do Attackers know who to target?

Recall from the REN-ISAC lists that there are known lists of usernames and passwords available on the internet. Once hacking groups decide they have the right targets, they will then attack those targets. As we have seen with several of the DUO alerts, there have been users who have been previously compromised in phishing scams so their usernames and passwords are known and they have pushed the fraud alert in Duo.

Push Notification Targeting Methods:

  • Transport Layer Attacks and Social Engineering
  •  Data Extraction & Credential Theft
  •  Eventbot malware / malware apps that masquerade as other apps
  • Recon from public help desk pages.


Universities that use Duo and have been managing this attack:


Groups known to be using this attack: APT29, Cozy Bear, Lapsu$

Companies that have been compromised with this attack: Nvidia, Okata, Microsoft,  Solarwinds.  

A video example of the attack (could not find one for Duo)

Recommendations to mitigate the attacks:

  1. Audit your existing MFA configuration.
    • Geo IP filtering
    • Fail Close Policy
    • Deny Self-Enrollment Procedures
  2. Avoid Push-style MFA Solutions.
    • Opt for Time-based One-time Password (TOTP) Tools. See DUO- https://help.duo.com/s/article/2112?language=en_US where they recommend against TOTP.
    • This was an interesting topic of discussion in the Ren-ISAC meeting for the schools that had been victims because TOTP is time based and can have issues with users because of drift. However, TOTP-based MFA will put access out of reach for most actors as it is time based. TOTP code generation function of an MFA app or a physical token code generator. 
    • This mitigates the problem of threat actors  directing MFA prompts to telephone numbers they added to a user’s account, these are still relatively rare and usually reflect a more strategic, rather than opportunistic, attack on a target.
    • In general the current recommendation I am finding is for organizations to not allow MFA via app-based push, telephone call or SMS text and only allow MFA via the physical token or TOTP app. 
  3. Act on Every Impossible Travel Style Alert. (this is resources intensive on staff particularly in EDU)
    • It is important to regularly review Azure sign-in logs for logins that are not consistent with authorized access to a user account.
    • Impossible travel alerts can be an excellent early indicator that actors were able to capitalize on a gap in MFA coverage or bypass MFA requirements in some way, e.g., by exploiting a software vulnerability, such as CVE-2019-11510 (Pulse Secure).
    • Adopt the posture that a successful MFA approval does not necessarily mean that the user is the user you are expecting.
  4. Audit new and unknown devices registered to your MFA service.
    • With user-level access, threat actors can surreptitiously add devices to a user’s MFA profile, allowing the actors to easily gain and maintain access to your network as they continue to approve MFA pushes or generate codes on their own, actor-controlled devices.
    • Keep an inventory of all devices registered to your MFA service and review any and all new and unknown devices in a routine manner. (Would this be plausible for L1 users?)
  5. Monitor MFA alerts and act based on information accordingly.
    • When you see anomalies while reviewing your MFA alerts, act quickly to track down whether or not it is an attacker, or if it is a user in a strange / non-standard location.
    • Better to block a potentially malicious user, than to allow a malicious user unfettered access.
  6. Post an internal help page with information for users to raise awareness.
    • Many users benefit and will read IT Emails that give information regarding ongoing threats, as well as potential knowledge base articles.  Additionally, work with management to help educate users.