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:
| Method | Description | Can be used for | Vulnerable to |
| SMS | Code sent via text that must be entered | Primary authentication, MFA, SSPR | Phishing, SIM spoofing |
| Voice | Code spoken that must be entered or push-#-to-accept | MFA, SSPR | Phishing, SIM spoofing, MFA spamming |
| Microsoft Authenticator code | Code generated by the app that must be entered | MFA, SSPR | Phishing, malware |
| Microsoft Authenticator codeless without number matching | Prompt that can be approved or denied | MFA, SSPR | Phishing, malware, MFA spamming |
| Microsoft Authenticator codeless with number matching | Prompt that can be approved or denied if number matches the one generated during sign-in | MFA, SSPR | Force |
| OATH tokens | Software or hardware code generators | MFA, SSPR | Phishing, malware |
| FIDO2 | Hardware token (USB, NFC, BT), secured by biometrics and/or PIN | Primary authentication (including MFA claim) | Force |
| Windows Hello for Business | Local authentication to Windows 10 and 11 | Primary authentication (including MFA claim) | Force |
| Microsoft Authenticator in passwordless mode | Prompt that can be approved or denied if number matches the one generated during sign-in | Primary 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:
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.