Many organizations adopt an “MFA everywhere” approach, embracing Multi-Factor Authentication (MFA) to safeguard against account compromise and prevent additional access to compromised accounts. 

Organizations commonly deploy conditional access policies (CAPs) that mandate multi-factor authentication (MFA) in specific scenarios, such as when users are off-network, while exempting it in other cases, like accessing resources from corporate IP spaces. Obsidian’s Threat Research team has observed recent instances where MFA enforcement policies, though intended to enhance security, can inadvertently cause harm. 

In this blog post, we explore how these scenarios occur, drawing examples from our investigations in Microsoft environments. We then explore security measures that can prevent this from occurring within your organization. 

How attackers leverage MFA:

Upon gaining access to an account, an attacker frequently registers an MFA method so they can:

1. Freely move between services: Registering an MFA method allows the attacker to seamlessly move to other services, leveraging their own registered MFA method.
2. Gain persistence: If the attacker’s compromised session expires, they can regain access to the account by using the username and password along with their maliciously registered MFA method. This bypasses the need to compromise the victim’s MFA again.
3. Abuse SSPR: There is a growing trend of Self-Service Password Reset (SSPR) abuse linked to malicious MFA methods for persistence. After being evicted from an account, the attacker can employ the malicious MFA method to execute a single-factor verification SSPR flow, initiating a battle for account control between the victim and the attacker. 
   • You can learn more about SSPR abuse in this blog post, Behind The Breach: Self-Service Password Reset (SSPR) Abuse in Azure AD. 

Given these troubling implications, it’s important for security teams to not only enforce MFA but also have strict controls around the registration of MFA methods.

What we’ve observed: 

In our research, we discovered several concerning trends in organizations’ approach to MFA:

• Insufficient MFA requirements: 11% of Microsoft tenants restrict MFA registration to trusted locations and devices, impacting overall security.
• Inconsistent requirements: 39% of tenants mandate MFA from untrusted locations but not from trusted ones, leaving vulnerabilities in user accounts.
• Neglect of on-site users: Employees on-site, in “trusted environments” may lack MFA methods, making them vulnerable to conditional access policy flaws.
• Increased avenues for exploitation: Conditional access policies that enforce MFA during initial sign-on give attackers opportunities to gain and maintain access.

Scenarios:

The following scenarios are examples of conditional access policies that backfire when no MFA registration restrictions are in place.

1. CAP requires MFA or domain-joined devices for certain apps. A password spray attack against the OfficeHome app hits on a 2-year-old dormant account with no MFA registered. The password login succeeds, but since the OfficeHome application requires a domain-joined device, the login is blocked. The attacker tries logging in to a different app, “Application Management Gateway”, which triggers a policy that requires MFA, prompting the attacker to register an MFA method. The attacker continued using this application’s CAP to register MFA for each account compromised in the tenant. Now with MFA, they are able to access different applications, including the ability to access virtual desktop environments (VDI). The machines in the VDI environment are domain joined, satisfying the original requirements for accessing the OfficeHome application and allowing the threat actor further lateral movement.
2. CAP requires MFA when coming from untrusted locations. A group of users and admin accounts have only ever accessed core business applications from the corporate IP space. A compromised admin account resets the password for another account. The attacker logs in from a new location outside of the corporate IP space, triggering the policy that requires MFA. Since no MFA existed on the account, the attacker registers their own MFA method. Obsidian insights reveal that 39% of all Microsoft orgs have these types of policies enabled without any restrictions on how MFA can be registered.
3. CAP requires MFA if a risky sign-in is detected by Azure. 14% of Microsoft orgs take advantage of Azure sign-in or user risk levels in CAPs. If a risky sign-in is detected then the CAP can prompt for various actions like MFA or a password reset. A tenant had a policy in place that would require MFA if a high risk level was detected during a sign-in. A user without MFA only ever came from a trusted Windows machine and was never prompted for one. The account was compromised and accessed from a new location using a Mac. This triggered the policy, prompting for MFA in which the attacker registered their own method.
4. Logins to “My Sign-ins” triggers a Microsoft default setting that forces MFA enrollment. Regardless of what conditional access policies are in place, Microsoft will always prompt for MFA when attempting to access this application. Even if MFA is not enforced on the account, an MFA method must be registered to access it. This app allows you to view and modify different security settings for the account like devices, MFA, and applications. We’ve seen attackers run into this situation with this application where no CAPs were forcing the MFA enrollment.

What can I do to protect my organization?

1. Restrict how MFA methods can be registered. This a surefire way to slow down and prevent the scenarios described above. Only allow the registration of MFA methods from trusted locations, or, from a domain-joined device. Should a situation occur where one of your accounts does not have MFA and is compromised, the attacker must find their way onto a corporate IP or a device that is joined to the domain in order to register MFA. In a well managed tenant an account without MFA should have a hard time accomplishing these tasks. For existing users without MFA and coming from untrusted locations, you can utilize Microsoft’s Temporary Access Pass and allow access to set up their MFA methods.
2. Register temporary MFA methods during account provisioning. The IT provisioning process for new accounts needs to include the requirement of MFA setup. When a new user performs their first login to their account they must set up MFA. This will help reduce the possibility of active accounts without MFA existing amongst your user base. You can utilize Microsoft’s Temporary Access Pass and allow access so new users can set up their MFA methods.
3. Require MFA more frequently. Avoid exemptions for when MFA is needed, e.g. on a trusted network. Prompting for MFA more often, regardless of location or device, will slow attackers down if they are already on your network. We see this often with advanced adversaries. They compromise an on-prem device and are able to easily move through the environment without getting additional MFA prompts since the CAPs see the internal locations as trusted. More frequent prompts will also help decrease the amount of accounts without MFA registered, beating the attacker to the opportunity to easily enroll their own method when one does not exist.

Use these steps to create a conditional access policy in Microsoft Azure that limits MFA registration to trusted locations:

1. Navigate to the Azure admin panel for conditional access policies and create a new policy.
2. Name the policy something like “Restrict MFA registration to trusted locations only”
3. In the “Users” section select a test account to try the policy with.
4. In “Target resources” select “User actions” -> “Register security information”
5. In “Conditions” select “Locations” switch “Configure” to “Yes”
   1. Under “Include” select “Any location”
   2. Under “Exclude” select “Selected locations” then add the trusted named locations for your tenant.
6. In “Grant” select “Block access” -> “Select”
7. Enable the policy and click “Save”

Screenshot below illustrates CAP blocking access to MFA registration from an untrusted location:

Below is a screenshot of an Okta authenticator enrollment policy that would only allow MFA enrollment from trusted zones.

1. In your Okta admin portal, go to “Security” -> “Authenticators”
2. Select “Enrollment”
3. Either create a new policy if you do not have one, or add an additional rule to an existing policy.

The rule should look something like the below screenshot: 

Final thoughts:

The widespread adoption of security tools like MFA and conditional access policies is commendable and should not be underestimated. However, as this blog post explores, there are a number of steps you can take to derive even greater value from each. 

To learn more, schedule a demo with Obsidian today.