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 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:
| Component | Item | MITE ATT&CK |
|---|---|---|
| Credential Access | 2FA/ MFA spamming | T1621: MFA Authentication Request |
| Initial Access | Used Whatsapp for pushing user to get MFA request approved | T1566.003: Spearphishing via Service |
| Initial Access | VPN access via credentials | T1078: Valid account |
| Recon | Scanning infrastructure | T1135: Scanning Uber Infrastructure |
| Privileged Escalation | Founded cleartext credentials in PowerShell scripts | T1552.001: Credential in Files |
| Privileged Escalation | Access to PAM solution with founded cleartext credentials | T1078.00 Domain Account |
| Data Exfiltration | Access to number of apps/ infra/ internal data | T1048: 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 type | Azure AD Password Protection with global banned password list | Azure AD Password Protection with custom banned password list |
|---|---|---|
| Cloud-only users | Azure AD Free | Azure AD Premium P1 or P2 |
| Users synchronized from on-premises AD DS | Azure AD Premium P1 or P2 | Azure 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.
| Policy | Available 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
- Go to Azure Active Directory -> Security -> Authentication Methods
- 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:
- Go to Azure Active Directory -> Security -> Authentication Methods
- Within the blade Authentication methods click on Policies and select Microsoft Authenticator
- 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'] > 3Detect 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'] >= thresholdCybersecurity 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:
Twitter thread by @BillDemirkapi
Twitter thread by @GossiTheDog
Microsoft:
DEV-0537 criminal actor targeting organizations for data exfiltration and destruction
