Since Russia’s invasion of Ukraine, companies based in the United States have been on alert for potential cyberattacks on IT infrastructure. Multi-Factor Authentication (MFA) has been one of the most recommended settings for organizations to turn on. Recently, the White House issued a FACT SHEET on how organizations can protect themselves against potential cyberattacks from Russia, and MFA is at the top of that list.

At TrustedSec, I am on the Cloud Force team where I specialize in Azure penetration testing. In this blog post, I'll go into detail about common ways that a penetration tester can gain access to an Azure tenant, including how we bypass MFA and Conditional Access policies. I will also describe how organizations can protect themselves through proper MFA implementation in Azure.

Open-Source Intelligence (OSINT) Gathering

Azure penetration testing begins with end-user enumeration. We use OSINT techniques to enumerate valid users. Some of those techniques include searching for employee information on social media sites such as LinkedIn or through data breach services such as DeHashed.

Enumeration Techniques

Armed with an email address gathered during the OSINT phase, we need to make sure that users are valid in the Azure tenant. I prefer to enumerate valid users without generating logs, if possible, before starting password spraying attacks and generating failed logins to an Azure tenant.

Tactic 1: Passive Enumeration Reconnaissance

Tools:

TREVORspray: https://github.com/blacklanternsecurity/TREVORspray

onedrive_user_enum: https://github.com/nyxgeek/onedrive_user_enum

Using a publicly available tool called TREVORspray, there is a submodule called RECON that I can use to perform some initial reconnaissance about the tenant I'm targeting. For this example, I am targeting my lab tenant and checking for the existence of a OneDrive instance.

Now that I've confirmed that a valid OneDrive instance for the tenant exists, I will start enumerating users with onedrive_user_enum written by our very own @nyxgeek.

Tactic 2: Password Spraying User Accounts

Tools:

o365enum: https://github.com/gremwell/o365enum

MSOLSpray: https://github.com/dafthack/MSOLSpray

There are two publicly available tools that can be used for password sprays with Azure accounts. On Linux OS, o365enum can be used, and on Windows devices, MSOLSpray can be used. Both tools support FireProx, which can be used to mask your IPv4 address during password spraying. FireProx rotates the IP address during the password spray so that Azure Active Directory smart lockout is not triggered. This is a very common password spraying method that I use when starting a Cloud Penetration Test, and this attack usually goes by month or season first. It's common (unfortunately) that this effort results in a valid password for a username.

Tactic 3: Bypassing MFA With Valid Username/Password

In this section, there are two scenarios I will review where bypassing MFA is achieved. I have encountered these scenarios in almost every testing engagement I've been part of. Before getting into either scenario, I complete a precheck to see if MFA is enabled on an account that has a valid username/password. Armed with this information, I use a tool called MFASweep to see if MFA is enabled for a particular account. If MFA is enabled, I proceed with the first scenario before moving on to the second one.

Tool:

MFASweep: https://github.com/dafthack/MFASweep

Scenario 1: MFA is enabled, but the end-user has not registered, and there are no IP address restrictions on where an end-user can register from. This scenario does happen often.

This is the first screen that's encountered:

If I see screen below, I know that I can successfully register for an MFA token on behalf of the user.

Scenario 2: MFA is enabled, but the end-user has registered with Microsoft Authenticator and push notifications.

Push notifications are very common. I will admit that at first, I thought push notifications would be a showstopper for getting into accounts. Through a couple of penetration test engagements, my observation has been that users will either blindly accept the push notification because they are not consciously thinking their account is being compromised, or they will get so annoyed with the prompts that they will click yes just to make the notification go away. These behaviors have resulted in the compromise of accounts that I shouldn’t have been able to access.

Remediation

In this post I wanted to provide remediation guidance to these issues and some settings you should either implement or possibly avoid when setting up MFA.

MFA Service Settings

These settings can be found in the Azure Active Directory Manage User's pane. Clicking on Per-user MFA will take you to the MFA service settings portal.

From here, click on service settings.

Once in the MFA service settings, there are two options I recommend configuring. The first option is not necessary but does ease the burden of rolling out MFA to end-users so that they are not accepting MFA requests or entering in codes multiple times a day. Trusted IP addresses can also be used to secure security information registration, which I will discuss later in this post.

The second setting is verification options you can set that will allow your end-users to enroll in MFA in a certain way. The only setting I can recommend is the highlighted setting below that makes users enter security codes to log in to an Azure/Microsoft Office service. If you have already deployed MFA and end-users are accepting authentication prompts, I will also explain how to secure this with number matching, which is in Preview now in Azure. Also, push authentication is not a safe MFA method to use and could compromise your organization if left in use.

Securing MFA With Conditional Access

Part of properly deploying MFA is securing it with Conditional Access. This requires a 5-step approach:

1. Secure security information registration
2. Require MFA for administrators
3. Require MFA for all users
4. Block legacy authentication
5. Turn on number matching (currently in Preview)

Some organizations may not be able to do this depending on how your network is configured, but this Conditional Access policy is effective at preventing offsite MFA registrations. Security information registration is probably the most critical and sensitive piece of access to any account that is synced to Azure. It is your house for MFA registrations so to speak. Access to it should be controlled through a set of trusted IP addresses, which prevents malicious MFA registrations from occurring from the outside if an account happens to be breached with a weak password. It will also prevent the compromise from going further. With just one compromised account, all your user account information in Azure can be exfiltrated, including highly-privileged memberships such as Global Admins.

Steps

Navigate to the Conditional Access Blade in Azure Active Directory.

Create new policy from templates (Preview).

Select Identities from the template category.

Select Securing security info registration.

Once selected, name the policy and set the policy state to Off or Report-only.

Once the policy has been created, go into the configuration of the policy in Conditional Access and change the following settings:

• Grant control to Block access.

• The Conditions settings on locations can be left as is just make sure you exclude your trusted locations from this policy.
• Trusted locations can be defined in the Named Location section as shown in Figure 17.

Before turning this on, I suggest either putting it in report only or testing it with a few end-users before deploying it to all of your end-users. This will effectively block any changes to someone’s security information unless they are coming from a trusted location.

I am sure not every organization can do this, but organizations that deploy company laptops and require their users to either be on the company network internally or through a VPN could utilize this type of setting.

Security information only needs to be accessed during an MFA setup or change of mobile phone. If you cannot implement this, then I suggest enrolling all end-users in MFA. Below is an example of someone trying to log in with a compromised account outside of a trusted IP address range.

If you have an end-user that has not enrolled in MFA and an attacker that has a valid user name and password, the attacker will not be able to enroll an MFA token on behalf of the user. This is because they would be trying to do so outside the bounds of the trusted IP address range, effectively shutting down this exploit path.

Next, you will need to require both your administrators and end-users to use MFA. You can do this under the same identity template category as before when creating a new policy from templates.

The defaults for these templates can be left as is. One minor suggestion for MFA for administrators and end-users is that if you are running a break glass Global Admin account for Azure Active Directory, exclude it from both of these policies. Azure Active Directory break glass accounts are designed for emergency use in case your main Global Admins get locked out of your Azure tenant or if there is a service outage with MFA. It should be highly guarded and monitored for use.

Number matching is currently in Preview. If you have notifications turned on in your verification options in MFA service settings, it is highly likely that end-users are enrolled in push notifications with the Microsoft Authenticator app.

As a penetration tester that works on cloud testing engagements, I run into this scenario often where MFA is deployed and I have a weak user credential. I discover the use of push notifications and prompt the user multiple times just so they accept the notification to make it go away.

Number matching can be turned on in the AdminAuthMethodsBlade in Azure Active Directory. You will need to enable Microsoft Authenticator. If you are rolling out MFA with Conditional Access, it’s normal if it is not turned on. At the time of this writing, you can only target all users for number matching.

Next, on the right side of Registration, click on the three dots to configure number matching (Preview).

You can set up number matching (Preview) in 'Push' authentication mode. It is not necessary to do number matching if end-users are putting in codes for an MFA request.

Once this is on, the end-user experience is painless. As a bonus, if you are showing additional context in notifications, you will see the geo request of its origin.

Lastly, you will need to button up any MFA shortfalls by blocking legacy authentication. Legacy authentication includes old protocols such as exchange ActiveSync, POP, IMAP, and SMTP. As of October 21, 2022, Microsoft will be deprecating legacy authentication in Azure tenants where it is not in use. I still believe doing this now is a good enforcement mechanism. You will also be able to show that it's enforced if you have tenants that get routinely security audited. To get started, we will head back over and create a new Conditional Access policy to block legacy authentication.

We can leave the defaults for the policy. What this will do is place a block on legacy protocols with a condition for client apps. As you can see in the screenshot below, legacy authentication clients are selected in the client apps section of the Conditional Access policy.

I recommend that you run this type of policy in Report-only mode for a few weeks so you can find out if critical applications are communicating over legacy protocols.

These are the minimum methods to secure your Azure tenants with MFA and protect your end-users as you roll out MFA in your organization.

MFA Reporting

MFA reporting is the last section to review. Because were taking a hands-off approach for MFA with Conditional Access, you will want to check in on your end-users to see who has registered for MFA. This will not only provide a good idea of who has registered but will allow you to focus on remaining users that have not yet registered. User registration details can be found at: https://portal.azure.com/#blade/Microsoft_AAD_IAM/AuthenticationMethodsMenuBlade/UserRegistrationDetails

The Methods Registered section will show which end-users have registered and the method(s) of registration.

Final Thoughts

In closing, I hope this detailed blog post gives some insight about an attacker's perspective and a defensive perspective when it comes to MFA implementations. Using this blog as a checklist can help you discover and remediate any gaps in your current Azure environment setup.