MFA Bombing

Multi-Factor Authentication (MFA) adds an additional level of protection to user accounts and their applications, and is one of the most powerful tools we currently have against compromised credentials being exploited.

However, some implementations are weak and susceptible to a technique known as “MFA Bombing” in which a threat actor triggers several, repeated MFA push requests to a victim’s enrolled smart device. They do this in the hope that the user will eventually tire of pressing ‘reject’ and make the issue go away by clicking ‘accept’ – unwittingly allowing the threat actor to gain access to their digital identity and organization’s protected data.

We at CovertSwarm regularly and successfully use this method of attack within our Constant Cyber Attack service offering to breach our clients via ‘MFA fatigued’ staff members, and see the technique being increasingly used in the wild, with support personnel often being targeted by these types of attacks.

Multi Factor Authentication bombing

It is well-known that Multi-Factor Authentication adds a powerful level of protection to user accounts and their applications. In theory, MFA should stop attackers even if they have gained access to valid credentials by requiring one or more additional proofs of identification in addition to the usual username and password pair. MFA is often implemented as a pseudorandom or time-generated code; a One Time Password (OTP) valid for only one authentication transaction passed over a side channel; or a simple approval request from a trusted ‘enrolled’ device.

However, some implementations remain weakened by allowing the possibility of a threat actor to spam and send several spoofed MFA requests to targeted victims:

In some cases, we see that the identity verification process has been implemented in such a way that allows attackers that have already compromised an account the ability to spam several verification requests.

This attack vector is known as MFA fatigue or MFA Bombing. The attack relies upon the weakness of some users being unable to differentiate between valid and threat-originating prompts, and there are several reasons that influence this:

• The prompt does not provide adequate information for the user to identify valid requests.

• The user does not understand the information provided to help identify the prompt (they do not know what a hostname is, for example).

• The user receives too many MFA prompts daily and has become fatigued to the point of accepting them when they appear.

• The user has learnt that accepting this prompt makes the notification go away without understanding the data security implications.

As in our own ethical attacks, this method of breaching target data may also be supplemented by social engineering techniques aimed at causing confusion. By inducing repeated pressure, and relying upon low context awareness by the chosen target (often IT support personnel who provide a strong path for lateral data breach via their exploited credentials) they are often unaware that one of their authenticated sessions has then been hijacked.

Gaining Persistence After Exploitation

Our ethical hackers have observed that successful ‘in the wild’ attackers typically go on to establish breach persistence by enrolling new (secondary) MFA devices in their target’s account after initially bypassing MFA through this technique.

One post-MFA bypass scenario, and the most vulnerable and prone to exploitation, is that the organization allows its staff to enrol devices themselves to the MFA verification process. In this case, an attacker would simply have to gain access to the user’s account and enrol the attacker-controlled device to perform further sensitive actions on that account, such as a password change. There is no segregation of access to the enrolment process, which is bad practice, because once the attacker has gained access to the authenticated target session, they can add their own device themselves rendering ongoing MFA protection ineffective.

As a result, regular auditing of enrolled MFA-authentication devices is strongly recommended across your client authentication domains.

Another potential scenario is that a threat actor has exploited awareness loopholes in the MFA reset/invite process through several means including MFA Bombing to obtain an MFA reset from the organization’s IT support/helpdesk so they can then enrol their malicious device. This is usually done with a pretext in the form of a phishing email or leveraging instant messaging collaboration platforms. Support personnel are usually targeted for these types of attacks because they are the ones that hold control of who gets to enrol a device to the MFA system in the organization.

An example of the second scenario was enacted during a recent CovertSwarm offensive security engagement against one of our subscription clients:

Two user account authenticated sessions were compromised in an ‘Adversary in the Middle’ (AiTM) style of attack. With the obtained sessions, CovertSwarm’s ethical hackers were able to access internal resources without the need to go through the MFA approval verification. However, the internal VPN, which was the goal for breach during the engagement, remained locked-away behind the organization’s MFA smartphone verification process. This way, every time a member of the organization’s staff wanted to access the protected internal VPN, they would need to provide username, password as well as the MFA OTP code that is displayed in their MFA authenticator app or approve the push notification request.

In this scenario, even if we have an authenticated session as the target, the MFA verification process is still protecting against unauthorized access because control over the last piece of authorization remains in the target’s control, their enrolled MFA device. The only way to gain further access to the VPN is to somehow take over the enrolment process.

As attackers, luckily, we have options: with our authenticated SSO sessions we can attempt to move laterally to unprotected internal resources such as mail and instant messaging platforms to impersonate the hijacked target and request MFA device enrolment resets through social engineering. We can also fatigue our target with MFA Bombing requests to cause confusion and distraction strategically to obtain an MFA enrolment invitation from the IT internal support group to add our own attacker-controlled device.

CovertSwarm successfully emulated both techniques against this target. In one hand impersonating and requesting an MFA reset to the client’s IT support group over instant messaging while in the background sending sporadic spoofed MFA requests to prompt for quick, ad-hoc, rushed response actions from their IT group. These techniques proved effective in causing “awareness fog” to the target and IT group and resulted in a new MFA device enrolment invitation arriving in the compromised targets mailbox.

Immediately after receiving the new invitation, our device was then added by scanning the QR code from the authenticator app for a full account take over, now the attacker’s device will be the designated one for sending MFA approval requests. With this set up now we can simply approve our own VPN access requests. Leaving the target locked out of their account and us with access to the internal company VPN.

Mitigation

There are several recommendations for mitigating these types of attacks, covering both the technical and human elements.

• Consider requiring MFA verification for all potential sensitive services like mail, IM platforms, or any service that an attacker could use to impersonate communications be locked behind MFA authenticator.

• Ensure training is provided to users of MFA so that:

• They understand how to spot MFA requests that are not from them;

• They know what to do if they get MFA requests they are not expecting;

• They understand which channels/actions will request MFA, and which will not.

• Avoid push notification MFA implementations in favor of:

• TOTP (Time-Based One-Time Password input as verification);

• U2F / FIDO2.

As mentioned above strong training around MFA implementations and providers is important and creates awareness within the organization to these types of attacks, some key indications to become aware of are:

• Unsolicited MFA prompt requests;

• MFA prompt spam frequency;

• Receiving a call, email, or message from someone claiming to be from your IT team performing an MFA test and asking you to accept the MFA request notifications that you are receiving.

Additionally, CovertSwarm also recommends not to allow staff members to reset their own MFA, instead an internal support/security group within the organization should be responsible for performing these sensitive actions. Additionally, it is also recommended that upon receiving MFA reset/invite requests from potentially compromised ‘staff members,’ Support staff should go over a process control playbook in which:

1. All the requesting user’s active sessions are closed.

2. The legitimacy of the request is verified.

• • What channel was used for the request?

  • Is it the official channel?

  • An alternate secure channel of communication is established with the user

  • A password change of the account is performed

  • Accompanying the user through the reset process

Consider that the user’s mailbox could also be compromised if it were not initially protected behind a required MFA prompt. If the mailbox could be compromised, do not send an MFA reset request until the password has been rotated.     

The point of these measures is to not make the MFA reset an ad-hoc process but a monitored one given the impact that could arise if an MFA reset falls in a threat actors’ control. 

MFA is a security measure that should not be considered a set-and-forget control but should be considered as an extension of a user password policy, configured, and monitored accordingly.

It is also important to understand the current technologies and specifications that are less susceptible to MFA borne attacks. These are:

• TOTP

• FIDO2

• WebAuthn

Using TOTP based MFA tools means that users will eventually have to type a 6 code one-time-password from their phone or another device when authenticating to a protected service. An even more secure and practical method that does not contribute to fatigue are the FIDO2/WebAuthn standards that utilize a physical device typically USB HID (human interface device acting as a keyboard) with the role of a being a roaming cryptographic hardware authenticator.

This avoids the need for the user to install third-party special hardware driver software in the host computer and permits application software (such as a browser) to directly access the security features of the device by just possessing and inserting the U2F device. Once communication is established with the host machine requiring the MFA authentication, the application exercises challenge–response authentication with the device using public-key cryptography methods and a secret unique device key manufactured into the device.

Look out for our follow up post on what other factors you can use in MFA to increase the security of user accounts and applications.

About CovertSwarm

The team at CovertSwarm is driven by a single objective – to constantly compromise the security of our clients through the deep detection of blind spots within their cyber defences and technology stacks before real threat actors are able to exploit them.

Our continuous client-focused cyber intelligence gathering, simulated attack, clear vulnerability reporting, live ethical hacker interaction capability and follow-up education services challenge the status quo of a cyber market in desperate need of modernisation.

Organisations seeking higher degrees of cyber assurance and security confidence than those offered by ‘snapshot’ penetration testing and red team engagements are increasingly partnering with us. They agree that ‘point in time’ testing is no longer enough to secure their organisations, and it is through this shared ethos that CovertSwarm challenges everything that has so far been considered to be ‘standard’ in today’s cyber vendor market.