Skip to content
Menu
ChrisOnSecurity
  • Blog
  • Microsoft Security portals
  • Presentations
  • GitHub
  • About me
  • Impressum
  • Disclaimer
ChrisOnSecurity

Counter MFA spam attacks with Azure Active Directory

Posted on 14. April 202214. April 2022

Recently, Microsoft and other vendors have been successfully targeted by the LAPSUS$ attack group using MFA spam as Microsoft describes in this blog post on the MSRC: https://www.microsoft.com/security/blog/2022/03/22/dev-0537-criminal-actor-targeting-organizations-for-data-exfiltration-and-destruction/

Analysis

One of the techniques that were used in the attacks is “MFA spamming” which basically means that the attackers prompted users with MFA requests until they finally accepted them. Sooner or later this WILL happen, so again, the password only is enough to get access.

Of course, the attack chain was a bit more complex but this key point is why I’d like to cover how susceptible Azure AD is to MFA spamming and how you can still use MFA in more secure configurations.

The second big threat: MFA phishing

One aspects remains correct: using MFA in combination with regular password-based authentication is still more secure than no MFA at all. Still, MFA can also be attacked by phishing if you think about the following scenario:

The attacker fakes a Microsoft modern authentication prompt and relays both the password and the code (sent by SMS or taken from the Authenticator app) to the valid microsoftonline authentication endpoint. While MFA is in place, it didn’t prevent the attack.

Strong authentication options and their security level

Azure MFA offers multiple methods to perform MFA. Together with the passwordless offerings we have, they make up the list of strong authentication option. The following table is intended to give an overview about each option and the respective security level:

MethodDescriptionCan be used forVulnerable to
SMSCode sent via text that must be enteredPrimary authentication, MFA, SSPRPhishing, SIM spoofing
VoiceCode spoken that must be entered or push-#-to-acceptMFA, SSPRPhishing, SIM spoofing, MFA spamming
Microsoft Authenticator codeCode generated by the app that must be enteredMFA, SSPRPhishing, malware
Microsoft Authenticator codeless without number matchingPrompt that can be approved or deniedMFA, SSPRPhishing, malware, MFA spamming
Microsoft Authenticator codeless with number matchingPrompt that can be approved or denied if number matches the one generated during sign-inMFA, SSPRForce
OATH tokensSoftware or hardware code generatorsMFA, SSPRPhishing, malware
FIDO2Hardware token (USB, NFC, BT), secured by biometrics and/or PINPrimary authentication (including MFA claim)Force
Windows Hello for BusinessLocal authentication to Windows 10 and 11Primary authentication (including MFA claim)Force
Microsoft Authenticator in passwordless modePrompt that can be approved or denied if number matches the one generated during sign-inPrimary authentication (including MFA claim)Force

As you can see, there is no method that is 100% safe. But they differ in the ways they are susceptible to attacks. Please note that some are basically (from what we know at the moment) only vulnerable if an attacker applies physical force to the person that holds the authentication method.

All in all, the following MFA method remains as the one to be most secure:

  • Microsoft Authenticator codeless with number matching: the number is generated by the authentication endpoint, so the user must enter it correctly or else the MFA accept won’t be successful. This basically turns the traditional approach around by entering the number in the app instead of entering an app code to the browser. MFA phishing is therefor not possible

That’s it for the classic MFA scenario. All other options officially belong to the passwordless category which still means that these methods are also considered as strong authentication and contain the MFA claim after authentication, therefor, fulfilling all Azure AD MFA requirements automatically:

  • FIDO2: No MFA spam possible as the authentication can only be started by the physical owner of the key. Also, no codes can be entered to the authentication endpoint so MFA phishing is also prevented.
  • Windows Hello for Business: Same aspects as with FIDO2
  • Microsoft Authenticator in passwordless mode: Same aspects as with FIDO2, the number that must be matched is generated by the Azure AD authentication endpoint and exclusively entered in the app.

Enabling Microsoft Authenticator to use “secure” MFA

As you have seen in the table above, the only classic MFA methods resilient against MFA spam and MFA phishing is the Microsoft Authenticator app in codeless mode + number matching.

While codeless mode is an option that can only be globally allowed or prohibited, number matching can be enabled on an individual basis by using Azure AD’s authentication method policies that can be found here: https://portal.azure.com/#blade/Microsoft_AAD_IAM/AuthenticationMethodsMenuBlade/AdminAuthMethods

After selecting “Microsoft Authenticator”, the user scope (all users or a subset) can be further configured:

This includes “Require number matching” (which we need to improve security) and “Show addtional context in notifications” (including location of the original sign-in and the app that is being signed-in to):

Detecting MFA spam

For most customers I know, more MFA options are used that the ones that are resilient to MFA spam or MFA phishing. Therefor, it is good practice (especially since LAPSUS$) to track events that might indicate one of the attack types already described.

One great option is to use Microsoft Sentinel where we have access to all Azure AD sign-in logs. What I can recommend is this set of queries by Matt Zorich:

https://github.com/reprise99/Sentinel-Queries/blob/main/Azure%20Active%20Directory/Identity-PotentialMFASpam.kql

What also can help is this query by Microsoft that looks for IP address teleportation:

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/SigninLogs/UserLoginIPAddressTeleportation.yaml

Summary

As you can, not all MFA methods are equal when it comes to their vulnerability to attacks like MFA spam or MFA phishing. The road Microsoft takes at the moment is to go passwordless, which I already covered in a post series I started back in 2019: https://chrisonsecurity.net/2019/07/28/going-passwordless-with-azure-active-directory/

If you can’t go passwordless yet, there remains only one secure option for standard MFA: using the Microsoft Authenticator in codeless mode + number matching.

Still, as I said before, using MFA is more secure than using it not at all.

Thanks for reading!

Chris

Note

Please note that all content on this blog is provided ‘as is’ without any warranty.

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

@ChrisOnSecurity@infosec.exchange

Recent posts

  • What’s new: Microsoft 365 Security & Compliance December 2022
  • What’s new: Microsoft 365 Security & Compliance November 2022
  • Counter MFA spam attacks with Azure Active Directory
  • Windows 11 security – a first look
  • Conditional Access – device identification using certificates

@ChrisOnSecurity

Tweets by ChrisOnSecurity

Recent posts

  • What’s new: Microsoft 365 Security & Compliance December 2022
  • What’s new: Microsoft 365 Security & Compliance November 2022
  • Counter MFA spam attacks with Azure Active Directory
  • Windows 11 security – a first look
  • Conditional Access – device identification using certificates

Tags

Administration Administrative Units Android AV Azure Active Directory Azure AD Azure Sentinel Client Security Conditional Access Conditional Access App Control Defender ATP Delegation EDR EMS Enterprise Mobility + Security Identity Protection Information Protection & Compliance Linux M365 M365 E3 Mail Security MCAS MDAPT MDATP MFA Microsoft 365 Microsoft 365 E3 Microsoft 365 Security Microsoft Cloud App Security Microsoft Defender ATP Microsoft Ignite Mobile Security Monitoring Network Control Office 365 Office ATP passwordless Perimeter Security Baseline Session Control Sysmon Unified Incidents User submissions Web Content Filtering Windows 10 Enterprise
©2023 ChrisOnSecurity | WordPress Theme by Superbthemes.com
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
Cookie settingsACCEPT
Manage consent

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT