Multi-Factor Authentication in Microsoft 365: What You Need to Know

Multi-factor authentication (MFA) is a widely accepted security measure, but it is not foolproof. Even when MFA is enabled, organisations can still be vulnerable to attacks if their MFA policies are misconfigured.

Oreta has found that many organisations misconfigure MFA policies in their Microsoft 365 cloud environments. This can allow attackers to bypass MFA and gain unauthorised access to sensitive data.

Here are some of the most common MFA misconfigurations:

  • Enabling MFA for only some users. This leaves users who are not required to use MFA vulnerable to attack.
  • Allowing users to bypass MFA for certain applications or devices. This can make it easier for attackers to gain access to sensitive data.
  • Not enforcing MFA for all sign-in attempts. This can allow attackers to gain access to an account by simply guessing the user’s password.

Organisations should carefully review their MFA policies to ensure that they are properly configured. They should also regularly test their MFA policies to ensure that they are working as intended.

Conditional Access Policies (CAPs) are a powerful tool for controlling access to Microsoft 365 and Azure AD resources. However, CAPs can be complex to configure and manage, and misconfigurations can lead to security vulnerabilities.

We have observed several CAP issues that can be used to bypass MFA. These issues include:

  • Using the wrong conditions in a CAP rule. For example, a CAP rule that only applies to users in the United States could be bypassed by an attacker who logs in from another country.
  • Excluding certain users or devices from a CAP rule. For example, a CAP rule that requires MFA for all users could be bypassed by an attacker who uses a device that is excluded from the rule.
  • Not enforcing MFA for all sign-in attempts. For example, a CAP rule that requires MFA for all sign-in attempts could be bypassed by an attacker who uses a compromised password to log in.

Permitting Mobile Devices

Whether intentional or not, Oreta often finds mobile devices exempted from MFA CAP. This exemption is often made to reduce friction for users who need to check emails or documents on the go. However, the source of a device can be easily spoofed by changing the “User Agent” request. This means that an adversary on a Windows device could pose as an iPhone, bypassing MFA.

To mitigate this risk, it is important to enforce MFA for all users, regardless of the device they are using. Additionally, organisations can implement additional security measures such as Mobile Device Management (MDM) or Mobile Application Management (MAM) compliance.

Unintentionally Permitting Linux Devices

Only relatively recently (Burrage, 2022) has Microsoft added Linux as a device platform for rules to be applied against. Organisations are often surprised to find that Linux has been retroactively applied to rules in the “bypass” state. Review old rules to ensure Linux devices are not granted unexpected additional rights.

Exempted Service Accounts

Service accounts are not designed to interact with users, so they cannot respond to multi-factor authentication (MFA) requests. As a result, administrators often disable MFA for these accounts. However, this can leave them vulnerable to attack.

During penetration tests, Oreta consultants have found service accounts that have been in use since 2010 and have passwords like “Password1.” This is a major security risk.

To mitigate this risk, organisations should use Conditional Access Workload Identities (CAWI) to block untrusted external authentication events for service accounts. CAWI allows organisations to define policies that require service accounts to only authenticate from trusted locations.

In addition, organisations should use a privileged access management (PAM) solution to ensure that service accounts are secure. PAM solutions can help to manage service account passwords, enforce least privilege, and audit access to service accounts.

Opt-In Selective Enforcement

When configuring a conditional access policy (CAP), one of the variables that must be set is “to which groups should this apply to?”. Many organisations have an ALL-STAFF group that new users are added to as part of the onboarding process. This group is then used to enforce MFA for all new users. However, if an old user is not retroactively added to this group, or slips through the onboarding process, they will not be subject to MFA. This leaves these users in a vulnerable state.

To mitigate this risk, MFA enforcement should be set to opt-out by default. This means that all users will be required to use MFA, unless they are explicitly exempted. Any exemptions should be carefully considered and audited.

By setting MFA enforcement to opt-out by default, organisations can help to ensure that all users are protected, regardless of when they joined the organisation.

Exempted Applications

Sometimes, MFA may be implemented for users and devices on a wide scale, but it may not cover all applications within an organisation. Software as a Service (SaaS) applications within a given tenancy can also be subject to exceptions in terms of conditional access policies (CAPs). For instance, one organisation enforced MFA for the Microsoft suite but neglected to include Confluence. Upon closer examination, it was discovered that this Confluence instance contained sensitive information, which allowed Oreta testers to gain remote access to the internal network without MFA. It is essential for organisations to regularly review application exemptions and ensure that users do not store their credentials in easily accessible knowledge bases.

Trusted Locations

Organisations typically have an MFA exemption policy for users originating from “trusted” networks, such as their VPN or offices. However, these network ranges are often broad and sometimes overlap with guest Wi-Fi networks. This creates a potential security vulnerability where threat actors could walk past an office, obtain an authentication token without MFA, and then continue to use that token remotely. To mitigate this risk, it is important to ensure that the designation of “trusted” locations is minimal and that these locations are genuinely trustworthy.

Oreta ran a red team/blue team exercise on a client in the finance industry. In a red /blue team exercise, the red team is made up of offensive security experts who try to attack an organisation’s cybersecurity defences. The blue team defends against and responds to the red team attack. On a red team, Oreta obtained username and password credentials via a password spray. On authenticating to Microsoft 365 it was found that MFA was enforced through the browser. Typically, the tool MFASweep (dafthack, 2022) is executed to find low-hanging fruit in CAPs – by mimicking a mobile device – but this did not result in a bypass on this test. What is important to remember is that CAP is evaluated holistically. Many rules may be evaluated during a given authentication event. As a result, Oreta testers were able to brute-force combinations of known devices, applications, and Microsoft login endpoints to find the combination of CAP to obtain access. Upon authenticating with a Linux user agent and a spoofed “Windows Config Designer” source application ID to the Microsoft Graph API endpoint, the CAP were satisfied and provided the consultant access to the organisations cloud without the need for MFA.

Conclusion

Microsoft Conditional Access Policies, when properly implemented, offer organisations powerful capabilities for granular control and auditing of authentication events, aligning with the principle of defence in depth. However, the complexity of these policies can lead to nested issues that may result in unexpected or unintended outcomes. Conducting a static review of policies is always recommended, but it is also beneficial to evaluate effective policies from an offensive perspective to verify that what is defined in theory aligns with actual practice. When defining Conditional Access Policies, it is important to ensure that they are:

  • Exclusive by default
  • Clear in purpose
  • Properly labelled
  • Consistently applied with minimal exceptions
  • Regularly audited to detect abnormal login flows.

Contact us now to evaluate your MFA policies.