Nowadays, most companies enforce MFA (Multi-Factor Authentication) for initial and persistent authentication. Some companies claim to be secure once MFA is configured on all (non-service) accounts. However, the Uber hack of last week proves cloud-based MFA push notifications can be abused, even when conditional access is configured. IAM holds the keys to your kingdom (when no RCE is present;) so guard it well.
The APT (Advanced Persistent Threat) hackers group Lapsus$ and Cozy Bear recently compromised company employee accounts by leveraging MFA prompt bombing, also known as a Fatigue attack or MFA push spam. First, the malicious entity must obtain compromised credentials of a company account (username and password). Next, the hacker logins to generate/bomb/spam the user with MFA notifications to a secondary device such as a smartphone. According to industry threat intelligence, most malicious MFA requests are sent at night, or less frequent requests are sent over a few days, hoping a user unintentionally provides access or grows so frustrated that they will eventually approve one MFA request. Remember, only a single approved malicious MFA request is needed.
Social engineering is combined if the user does not fall for initial MFA bomb notifications. As an example, a user receives a (spoofed) e-mail or WhatsApp message urging to accept an MFA request imposed as an IT administrator or IT support.
This blog post explains how to detect MFA bombing if you have implemented Azure or M365 MFA together with Microsoft Sentinel as a SIEM solution.
MFA Bombing SIEM alert
Alert name: Possible IAM MFA bombing from Microsoft 2FA notifications.
Alert severity: High. MITRE category: Credential Access
//Cryptsus.com - we craft cyber security solutions
//Date: 20-09-2022
SigninLogs
//filter on Microsoft 2FA Authenticator errors
| where ResultType == 500121
//Parse the authentication details so we can query the data
| extend AuthResult = tostring(parse_json(AuthenticationDetails)[1].authenticationStepResultDetail)
//Collect all denied or ignored MFA requests
| where AuthResult in ("MFA denied; user declined the authentication", "MFA denied; user did not respond to mobile app notification") or Status has "MFA denied; Phone App Reported Fraud"
//Enable the below two filters if you have Conditional Access configured
//| where parse_json(AuthenticationDetails)[1].authenticationStepRequirement == "User, MultiConditionalAccess"
//| where isnotempty(AlternateSignInName)
//Count all denied and ignored alerts within a 12 hour time-frame
| summarize ['MFA_Actions']=make_list(AuthResult), ['MFATotalFailed']=count() by AppDisplayName, Identity, UserPrincipalName, bin(TimeGenerated, 12h)
//Detect MFA bombing 3 or more (>2) denied or ignored MFA tokens
| where ['MFATotalFailed'] > 2
| sort by MFATotalFailed
//Order the output in a logical order
| project TimeGenerated, Identity, UserPrincipalName, AppDisplayName, MFA_Actions, MFATotalFailed
Figure 1 shows the result of this KQL query when three MFA requests have been denied and one MFA request has been ignored by the user:
Figure 1: Sentinel KQL result MFA Bombing query
This KQL Kusto query can also be found on GitHub.
Further mitigations
Educate your colleagues to never accept unknown or strange MFA requests. Report strange notifications immediately. Your users should be aware of this relatively new attack path.
Second, you can replace MFA notifications with physical FIDO U2F (Universal 2nd Factor) keys. If your organisation is not ready for physical FIDO keys, you can replace "plain" Azure MFA notifications with MFA number, also known as number matching.
Furthermore, you can look into limiting the number of allowed MFA attempts. However, this can have business impact if the permitted number of MFA retries is set too low.
It is always essential to have a strong password policy where passphrases are used. Enforce least privilege across all platforms, applications, and data. Next, periodically check if any of your managed AD credentials are compromised with the help of the haveibeenpwned database.
