When Multi-Factor Authentication Is Actually Single-Factor: The Enrollment Security Gap

Introduction

Multi-Factor Authentication (MFA) is an effective way to protect accounts from unauthorized access should an account’s password ever get compromised and is often a vital component of an organization’s security posture to mitigate against an external attacker gaining access to sensitive corporate infrastructure. Organizations can choose to implement MFA through numerous identity providers such as Microsoft, Duo, Okta or other security solutions to require a second factor to verify identity before accessing services such as Microsoft 365 and/or VPNs. However, a common security gap in many MFA implementations is the enrollment process where a user is allowed to enroll in MFA with only a password if they have not previously registered. With this article, I am hoping to describe what this issue is, provide typical examples of the types of users affected, and provide some recommended mitigations to address this security gap.

The Enrollment Gap

Through default or chosen configurations, MFA is commonly implemented by an organization which prompts the user to self-enroll in MFA upon their next login without any additional verifications. Insecure self-enrollment only requires single-factor authentication if you already know the username and password.

Often, during my external network assessments, this enrollment gap is a crucial part of an attack chain that leads to internal or cloud network access. While an organization’s password policy is often the first line of defense against account compromise it is frequently not enough to prevent an external attacker from compromising an account. Social engineering and phishing attacks are common methods for a threat actor to gain initial credentials and I could write another article on the common patterns I have seen that have led to successful password spray attacks, even when 15-character minimums are enforced with complexity requirements. Due to insecure single-factor MFA enrollment, if a compromised account has not yet enrolled, an attacker can register their own device to complete the enrollment process.

Common Types of Unenrolled Users

At this point one might ask what the major concern is regarding this enrollment gap. Shouldn’t the window for an attacker to abuse this gap be small and/or non-existent? Wouldn’t this be an acceptable risk for most organizations as users should be logging in shortly enough after MFA is enforced? Unfortunately for most organizations that might be relying on default MFA configurations, this gap is often larger than what might be presumed as there are several types of accounts that fall under the enrollment gap than an organization might not be considering and/or monitoring.

The most common patterns I see regarding the types of accounts that have weak enrollment are:

• Service accounts
• Contractor accounts
• Newly provisioned and/or password reset accounts

Other types of accounts that might be more prone to weak enrollment are on-premises accounts that do not have a mailbox configured. Examples of these type of accounts could be shared organizational accounts for departments and administrative accounts. Organizations not regularly auditing and disabling inactive accounts can also lead to a higher number of users that might be susceptible to weak enrollment. In short, organizations should ensure proper policies are in place to audit the enrollment status of all accounts within the organization. If an account from the above examples is also configured to have Microsoft 365 or VPN access, then insecure enrollment can be used to gain access to sensitive corporate information and potentially the internal network.

I also want to note that while I have occasionally directly compromised an account with insecure enrollment through password spraying and/or credential stuffing from breach data, more often it is the result of a chain of configuration gaps that allows me to target the accounts detailed above after compromising an initial user of an organization. After gaining access to a single valid Active Directory/Microsoft 365 credential, it is often possible to pull verbose information on all domain users due to Microsoft endpoints that do not require MFA to conduct more targeted password spraying attacks to discover weak enrollment accounts. These MFA access gaps are worthy of their own article, similar to insufficient password policies, but the important takeaway is that common and default MFA security configurations relied upon by many organizations lead to real gaps that can allow an attacker with sufficient time and determination to discover and compromise accounts with weak enrollment.

Some Recommendations

If you are an organization that enforces MFA but has been relying on default self-enrollment configurations until now, what can you do? Best practices would be to limit public enrollment by requiring the verification of a shared secret before enrolling or tie enrollment of users to expected emails, devices and/or phone numbers so that arbitrary devices are not allowed for enrollment on any account. If your organization onboards employees in physical offices, restricting MFA enrollment to the internal network can also mitigate this security gap. Just make sure that whatever form of credential you accept for enrollment, it’s not only a single factor. Examples might be username/password + internal network located source, username/password plus pre-verified email, username/password plus pre-verified phone number, or whatever combination of factors that best suites business needs.

While there are several different MFA security solutions, here are some example settings within Microsoft and Duo as reference for potential solutions to address this security gap. If you use a different solution, review the configuration and vendor documentation to ensure the enrollment process is secure.

Duo

Duo itself recommends using self-enrollment which is part of why I am writing this article. If self-enrollment was not the default setup for most MFA security solutions, this article would not be necessary because it is more difficult to securely configure the self-enrollment MFA process. This is a daunting task for any organization with limited resources. Instead of self-enrollment, utilize the Automatic or Manual enrollment options within Duo. For further information please refer to Duo’s docs located at https://duo.com/docs/enrolling-users. Ensure that each account has an expected device to send the enrollment link to that will naturally expire within 30 days. This can be supplemented by procedural policies regarding the onboarding and account creation processes as well as regularly auditing the “partially enrolled” group within Duo for accounts that might currently be susceptible to insecure enrollment if your organization currently utilizes Duo self-enrollment.

Microsoft

Unlike Duo, Microsoft services do not allow the option of completely restricting the default self-enrollment but it is possible to associate phone numbers prior to self-enrollment to prevent arbitrary device enrollment. There are some caveats to this approach, as it requires SMS to be the default method for the account and for SMS to be an enabled MFA authentication method.

This method can be less than ideal as it introduces more overhead as well as creates additional steps to migrate the user to a different authentication method that might be preferred by an organization on top of concerns of SMS being non-phishing resistant or vulnerable to SMS sim-swapping attacks. A related option could be auditing the Microsoft 365 tenant for unenrolled accounts and then only forcing those users to use SMS enrollment.

Alternatively, strict conditional access policies within Microsoft could be utilized to restrict logins for any account that has not yet enrolled after implementing an onboarding group that is allow-listed for an appropriate time for enrollment. Further, stricter conditional access policies should limit any login events for any service accounts (and any other accounts that cannot use MFA methods) unless they come from a trusted network. Microsoft also offers Microsoft Entra ID Protection which has automated protections against enrollment and sign-ins for any organizations with Microsoft Entra ID P2 licenses.

Conclusion

Insecure MFA enrollment can be a Catch-22 situation for organizations looking to implement MFA to prevent unauthorized access. Default configurations associated with self-enrollment often only require knowing the username and password to complete enrollment since the equivalent of requiring MFA to enroll in MFA is both a technical and procedural hurdle. Hopefully by highlighting what this issue is, how it can be a real risk to organizations, and some potential solutions, you can reduce the chance of an attacker breaching your external perimeter, accessing sensitive business functions, or gaining an internal foothold.