Hackers are more frequently using social engineering attacks to gain access to corporate credentials and breach large networks. With the rise of more default protection with the use of multi-factor authentication the MFA Fatigue technique is rising.

In the past months, multiple large enterprises are breached – in all cases the attacks start with social engineering and stolen/ captured employee login credentials to access VPNs and the internal network.

Note: Blog is written based on Microsoft technology – no other toolings/ products are evaluated outside the Microsoft product stack. All is written based on my own opinion.

Blog information:

Blog published: September 22, 2022
Blog latest updated: September 22, 2022

Attack story timeline

Let’s simulate the general attack story with Uber as an example. NOTE: Not all details are shared from the Uber breach. Use Twitter for finding some more screenshots/ detailed information. Uber is only added as an example. Multiple companies are breached recently using the same technique and steps. MFA fatigue received more notice because of breaches against companies like Uber, Cisco, Twitter, and Okta.

Step 1: Stolen credentials

It all starts with stolen credentials. It is far from difficult to get stolen credentials, which can be collected using phishing attacks, malware, or collected via data breaches. On dark web marketplaces, credentials can be purchased for various types of companies and large enterprises. With some hours of research it is simple to find the resources on the dark web where passwords can be purchased. And yes – also for the larger enterprises.

Hopefully, all companies are protected at least with MFA which makes the initial abuse a little harder. Currently reading this blog and no MFA configured – please enable it asap and don’t wait before the organization is breached for the first time. Without MFA it is only a matter of time until things go wrong.

Step 2: MFA bypass/ Social engineering

Companies are currently heavily adopting multi-factor authentication to protect users to access threat actors without any additional verification. Multiple methods are available to bypass multi-factor authentication:

  • Stealing cookies via malware
  • man-in-the-middle phishing Attacks ( Evilginx2)

Social engineering can be used. A technique called ‘MFA Fatigue, MFA push spam’ is rising and a new common technique for breaching into corporate networks. For MFA Fatigue no additional infrastructure or malware is required. More in-depth information later in this blog.

Example Uber:

A good example is the recent Uber breach; where the attacker used stolen/purchased credentials and spammed the user with many push authentication prompts for one hour. After one hour the attacker contacted the user and claimed to be from Uber IT with the message; if he wants to stop he must accept it. Finally, the employee approves the MFA and the attacker added a new device.

Image

Image source: Kevin Beaumont (Twitter)

The attacker then repeatedly tried to log in to the contractor’s Uber account. Each time, the contractor received a two-factor login approval request, which initially blocked access. Eventually, however, the contractor accepted one, and the attacker successfully logged in.

Uber Newsroom

Step 3: Access internal sources/ Cloud sources

When there is access with one of the MFA methods – there is a phase where the attacker is searching for internal sources which can be used for getting more sources.

For cloud-only environments: (Ideas for getting more access)

  • Validate of Okta is used
  • Check for Privileged Identity Toolings
  • Additional connected applications ( password toolings/ key-saves)

For on-premises environments: (Ideas for getting more access)

  • Connect with VPN
  • Sometimes Sharepoint or other intranet software will be used for scanning VPN/ Remote access manuals

When the VPN can be activated with the collected account – the attacker can discover more and scan the complete intranet.

Step 4: Discovery of the network

Step 4 is the initial discovery of the network. When there is access to cloud resources and on-premises intranet resources the discovery can start; searching for scripts/ passwords and additional credentials which results in access to other toolings.

Example Uber:

The existing VPN access is used for pivot to the internal network. The internal network is often significantly less audited and evaluated in compared to external infrastructures. In comparison with Azure; there are in the cloud more built-in protection toolings. In all cases don’t trust the defaults and audit each possible way of access to internal/ external or cloud environments.

During the discovery, the attacker found an internal network share where scripts with privileged credentials were published. One of the PowerShell scripts contained the username and password for a Privilege Access Management (PAM) tooling (Thycotic) which results in access to other useful resources ( Duo, Onelogin, Slack, EDR portal (SentinelOne), AWS, GSuite, and many more).

Some of the apps can require MFA again – where the attacker registered a new phone – so the authentication can be easily approved without the employee.

Security Update for Uber can be found here; Security update – Uber.com

Summarize in MITRE ATT&CK framework

The Uber breach mapped together with MITRE ATT&CK framework:

ComponentItemMITE ATT&CK
Credential Access2FA/ MFA spammingT1621: MFA Authentication Request
Initial AccessUsed Whatsapp for pushing user to get MFA request approvedT1566.003: Spearphishing via Service
Initial AccessVPN access via credentialsT1078: Valid account
ReconScanning infrastructureT1135: Scanning Uber Infrastructure
Privileged EscalationFounded cleartext credentials in PowerShell scriptsT1552.001: Credential in Files
Privileged EscalationAccess to PAM solution with founded cleartext credentialsT1078.00 Domain Account
Data ExfiltrationAccess to number of apps/ infra/ internal dataT1048: Exfiltration over Alternative Protocol

Useful source including visual with all MITRE ATT&CK mappings and the order of steps. Twitter

What is MFA Fatigue

MFA Fatigue (Mitre ATT&CK T1612) is not new and used by many hacker groups. Example; Lapsus$ and Cozy Bear. MFA Fatigue is rising and used more often to gain access to corporate credentials and breach networks where MFA fatigue is now part of the mainstream toolbox.

MFA fatigue refers to the overload of prompts the victim would receive via MFA applications. The technique works when the threat actor already has credentials for a targeted account. Phishing, brute forcing, data breach, password spraying, dark web and many more techniques can be used to get the initial credentials.

Once the credentials are available the threat actor starts requesting approval for sign-in for the MFA application. With the goal – of overloading the amount of MFA prompts and wait before the user approved the request. When the user does not approve the initial MFA notifications – social engineering can be used to message the user, and ask via e-mail/ Teams or WhatsApp for approving the MFA request imposed as an IT support employee/ IT administrator.

Protect against stolen credentials

There are multiple products available for protecting passwords and scanning for stolen compromised passwords.

First some basics;

  • Don’t forget to enable a Strong Password Policy across all systems and applications. When attackers cannot guess your strong password, they cannot send you multiple MFA requests.
  • Disable Legacy Authentication

Azure AD Password Protection

Azure AD Password Protection supports different protections. Azure AD Password Protection can be used to prevent users from picking poor/easily guessable/compromises passwords.

Microsoft maintains a global banned password list with stored passwords which are too common. This list is for safety reasons not published, in Azure AD Password Protection it is possible to add custom banned passwords.

For the feature make sure the following licenses are needed:

User typeAzure AD Password Protection with global banned password listAzure AD Password Protection with custom banned password list
Cloud-only usersAzure AD FreeAzure AD Premium P1 or P2
Users synchronized from on-premises AD DSAzure AD Premium P1 or P2Azure AD Premium P1 or P2

Azure AD Password Protection is already enabled for cloud users using the global password list, and it can’t be disabled. The configuration lockout and custom password list can be configured here:  Azure Portal -> Azure AD -> Security -> Authentication methods -> Password protection

For on-premises accounts, the following instructions can be applied: Enforce on-premises Azure AD Password Protection for Active Directory Domain Services

Identity Protection

Azure AD Identity Protection P2 can be used for detecting leaked credentials via user risk detections.

Microsoft finds leaked credentials in various places, including:

  • Public paste sites such as pastebin.com and paste.ca where bad actors typically post such material. This location is most bad actors’ first stop on their hunt to find stolen credentials.
  • Law enforcement agencies.
  • Other groups at Microsoft doing dark web research

User risks are calculated offline by Microsoft’s internal and external threat intelligence sources. Matches in the leaked credentials services will be checked against the used credential of the user.

Identity protection can be configured here:  Azure Portal -> Azure AD Identity Protection -> User Risk policy

Where the User Risk policy is based on leaked credentials/ Azure AD threat intelligence it is recommended to configure both User Risk and Sign-in Risk. Sign-in Risk is useful for detection attempts where the request isn’t authorized by the identity owner which can be detected in later stages of the MFA fatigue attack.

  • Atypical travel
  • Anomalous Token
  • Token Issuer Anomaly
  • Malware linked IP address
  • Suspicious browser
  • Unfamiliar sign-in properties
  • Malicious IP address
  • Suspicious inbox manipulation rules
  • Password spray
  • Impossible travel
  • New country
  • Activity from anonymous IP address
  • Suspicious inbox forwarding
  • Mass Access to Senstive Files

Explanation of risk detections: What is risk? | Azure AD Identity Protection

Configure risk policies/ automated response

Automated remediation actions can be configured using Azure AD Identity Protections policies or with the use of Conditional Access and the conditions User risk level and Sign-in risk level.

Note: Azure AD P2 required

Microsoft’s recommendation is to set the user risk policy threshold to High and the sign-in risk policy to Medium and above. It excludes Low and Medium risk detection from the policy, which may not block an attacker when the risk is detected as low. Selecting low gives more user impact.

PolicyAvailable remediation controls
User risk policy– Block access
– Allow access (require password change)
Sign-in risk policy– Block access
– Allow Access ( require multifactor authentication)

Enable additional MFA controls

Additional MFA controls can be configured for the Microsoft Authentication method. The additional enhanced settings are the way to mitigate MFA fatigue when using push notifications.

Important to configure the following additional settings:

  • Require number matching for push notifications
  • Show application name in push and passwordless notification
  • Show geographic location in push and passwordless authentication
  1. Go to Azure Active Directory -> Security -> Authentication Methods
  2. Within the blade Authentication methods click on Policies and select Microsoft Authenticator

Require number matching for push notifications

Number matching is currently in public preview. Microsoft gives the following explanations and marks the feature as a key security upgrade to traditional second-factor notifications in the Microsoft Authentication app.

Number matching is a key security upgrade to traditional second-factor notifications in the Microsoft Authenticator app that will be enabled by default for all tenants a few months after general availability (GA). We highly recommend enabling number matching in the near-term for improved sign-in security.

Microsoft

Number matching gives improvements against MFA fatigue and will increase the security posture of MFA Authentication prompts. When a user responds to an MFA push notification using Microsoft Authentication App, they will be presented with a number. The user needs to type that number into the app to complete the approval. Attackers don’t have access to the device/app where the code needs to be filled in. For the attacker the code is visible; only the code needs to be added manually in the app itself for completing the MFA request.

To enable number matching in the Azure AD portal, complete the following steps:

  1. Go to Azure Active Directory -> Security -> Authentication Methods
  2. Within the blade Authentication methods click on Policies and select Microsoft Authenticator
  3. Select Configure

Configure the control; Require number matching for push notifications (preview) and configure status to Enabled. Target All users or specific AzureAD groups.

Show application name in push and passwordless notification

Another improvement for the security posture is the enablement of the application name in notifications. When enabled the MFA prompt shows the end-user which application is performing the MFA request. OfficeHome for office.com

Configure the control; Show application name in push and passwordless notifications (Preview) and configure status to Enabled. Target All users or specific AzureAD groups.

Show geographic location in push and passwordless notifications

Show geographic location shows the geo-location ( based on IP) directly during the request. It is not always correct (VPN can be used).

Configure the control; Show geographic location in push and passwordless notifications (Preview) and configure status to Enabled. Target All users or specific AzureAD groups.

Result

Perform multiple attempts: viewed from the browser-session of the attacker.

Normal MFA prompt without additional MFA controls:

MFA prompt included above additional (preview) controls:

MFA Lockout option – is it protecting? -> No

Currently, there are many recommendations online for enabling MFA account lockout for failed MFA attempts in Azure against MFA spamming.

The MFA Lockout option is not protecting against MFA fatigue. MFA Account Lockout works only for MFA server, which is currently a legacy product and not supported anymore. More information: Configure Azure AD Multi-Factor Authentication – Azure Active Directory – Microsoft Entra | Microsoft Learn

Conditional Access / Compliant device

Additional configurations in Conditional Access can definitely help with some more strict Conditional Access configurations. Conditional Access can be useful when restricting only specific locations to sign in or use the compliant device control for allowing only access from compliant devices.

See the AiTM blog for more in-depth Conditional Access protections: Protect against AiTM/ MFA phishing attacks using Microsoft technology

FIDO2 authentication methods

Consider passwordless methods as an alternative to notification-based MFA. FIDO/ FIDO2 is configured to resist “man in the middle attacks”/ “MFA-spamming”.

Hunting in Sentinel/ Log Analytics

Currently, there is no built-in alert in AzureAD/ Defender or Sentinel for detecting MFA prompt attempts. With the usage of audit logs, KQL can be used for hunting for MFA abuse attempts.

SigninLogs contains all needed events. Can be connected using the Azure Active Directory – Signin logs connector in Sentinel.

Tip: No budget/ option for Sentinel? Events can be streamed via Azure AD Diagnostic Settings to Log Analytics workspace. On top of the Log Analytics workspace KQL can be used.

Go to Azure AD -> Diagnostic Settings and add a new diagnostic setting. Select the logs and destination Log Analytics workspace

KQL: MFA status denied by the user

SigninLogs 
| where ResultType == 500121 
| where Status has "MFA Denied; user declined the authentication" or Status has "MFA denied; Phone App Reported Fraud"

KQL: MFA status denied (user did not respond)

SigninLogs 
| where ResultType == 500121 
| extend AuthResult = tostring(parse_json(AuthenticationDetails)[1].authenticationStepResultDetail)
| where AuthResult in ("MFA denied; user declined the authentication","MFA denied; user did not respond to mobile app notification")

Matt Zorich published interesting queries which can be used for detecting MFA spam activity. Make sure to view the GitHub source for all related Sentinel/ KQL queries.

Below queries are created by Matt Zorich;

Summarize all denies or not responding in one-hour timeframe

The below queries summarizes all authentication request by UserPrincipalName and shows the results when more than 3 failures are generated in an hour timeframe.

KQL query:

Source: Sentinel-Queries/Identity-PotentialMFASpam.kql at main · reprise99/Sentinel-Queries (github.com)

SigninLogs
| project
    TimeGenerated,
    AuthenticationRequirement,
    AuthenticationDetails,
    UserPrincipalName,
    CorrelationId
| where AuthenticationRequirement == "multiFactorAuthentication"
| extend AuthResult = tostring(parse_json(AuthenticationDetails)[1].authenticationStepResultDetail)
| where AuthResult in ("MFA denied; user declined the authentication","MFA denied; user did not respond to mobile app notification")
| summarize ['Result Types']=make_list(AuthResult), ['Result Count']=count() by UserPrincipalName, bin(TimeGenerated, 60m)
//Find hits with greater than 3 failures in an hour
| where ['Result Count'] > 3

Detect when a user denies MFA several times

Useful query when the user denies MFA several times within a single sign-in attempt ( CorrelationId) and then completes the MFA. The below example shows (3 attempts) before the user successfully signed in.

KQL query:

Source: Sentinel-Queries/Identity-PotentialMFASpam.kql at main · reprise99/Sentinel-Queries (github.com)

let threshold=2;
SigninLogs
| project
    TimeGenerated,
    AuthenticationRequirement,
    AuthenticationDetails,
    UserPrincipalName,
    CorrelationId
//Include only authentications that require MFA
| where AuthenticationRequirement == "multiFactorAuthentication"
//Extend authentication result description
| extend AuthResult = tostring(parse_json(AuthenticationDetails)[1].authenticationStepResultDetail)
//Find results that include both denined and completed MFA
| where AuthResult in ("MFA completed in Azure AD", "MFA denied; user declined the authentication","MFA denied; user did not respond to mobile app notification")
//Create a list of completed and denied MFA challenges per correlation id
| summarize ['Result Types']=make_list(AuthResult) by CorrelationId, UserPrincipalName
//Ensure the list includes both completed and denied MFA challenges
| where ['Result Types'] has ("MFA completed in Azure AD") and ['Result Types'] has_any ("MFA denied; user declined the authentication", "MFA denied; user did not respond to mobile app notification")
| mv-expand ['Result Types'] to typeof(string)
//Expand and count all the denied challenges and then return CorrelationId's where the MFA denied count is greater or equal to your threshold
| where ['Result Types'] has_any ("MFA denied; user declined the authentication","MFA denied; user did not respond to mobile app notification")
| summarize ['Denied MFA Count']=count()by ['Result Types'], CorrelationId, UserPrincipalName
| where ['Denied MFA Count'] >= threshold

Cybersecurity Awareness

Educating users is important and part of preventing these types of MFA spamming in combination with some additional technical controls. Before getting any push notification, always think before clicking. With the use of additional context, users can make a better decision of approval is needed. In combination with number matching it gives some sort of mitigation. All there is no golden protection protecting against all forms of MFA fatigue..

Users must be trained on using Strong Passwords, Phishing, Social Engineering, Social Media Security, etc.

Conclusion

Consider passwordless methods as an alternative to notification-based MFA. FIDO2 is configured to resist “man in the middle attacks”. Of course there is no golden protection against all forms of social engineering / MFA abuse; important to track additional events such as MFA enrollment/ Device replacement/ MFA reset or credential resets.

Hopefully, this blog gives some tips/ hints which can be used. Of course; this is a small set of available security protections which can be used.

Stay safe; follow me on Twitter or LinkedIn for more quick insights and blogs around Microsoft security.

Sources

Uber related:

Security update | Uber.com

Twitter thread by @hacker_

Twitter thread by @BillDemirkapi

Twitter thread by @GossiTheDog

Microsoft:

DEV-0537 criminal actor targeting organizations for data exfiltration and destruction

Use number matching

From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud