Published by Security Testing and Assurance on 30 May
Much has been written about Multi-Factor Authentication (MFA) in recent times. MFA is widely accepted as necessary in our threat-filled environment, and often forms a critical part of compliance frameworks. Once applied though, what assurance does an organisation have that its configuration is impermeable? Within CyberCX’s Security Testing and Assurance (STA) team, our consultants are having continual success in finding holes in MFA policies and breaking into companies with a good old-fashioned username and password. Whilst we have circumvented custom MFA implementations in various client web applications, there’s a concerning trend of MFA misconfigurations in ever-prevalent Microsoft 365 cloud environments.
Introduction
Modern Microsoft 365 and Azure AD environments use “Conditional Access Policies” (CAPs) to govern when a user should be granted access to a resource, including when to be prompted for MFA. A default tenancy includes general baseline security defaults created by Microsoft to ensure MFA is broadly applied. However, for large organisations, these generalised rules often need to be caveated with rulesets around mobile devices, service accounts, guest accounts, or specific enterprise applications – at which point weaknesses are introduced. Administrators often create new rules as problems arise, failing to take a step back to understand how the newly implemented rule applies within the context of every other cumulative CAP. However, administrators are not solely to blame as auditing CAP can be difficult, and it can be unclear in what order rules are applied. All these rules provide a guise of security, and may tick off the compliance requirement to enforce MFA, but how can organisations be sure that these policies are working as intended?
Here is a look at some recent CAP issues CyberCX has observed, how they can be used to bypass MFA, and how to patch them.
Permitting Mobile Devices
Whether intentional or not, CyberCX often finds mobile devices exempted from MFA CAP. This exemption is often added to reduce friction for users checking emails or documents on the go. However, the source of a device can be trivially spoofed by altering the request “User Agent”. An adversary on a Windows device could pose as an iPhone, bypassing MFA. Ensure MFA is enforced for all users (regardless of device), or utilise additional countermeasures like Mobile Device Management (MDM) or Mobile Application Management (MAM) compliance.
Inadvertently 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 by their nature are for non-interactive use, so they are unable to answer to an MFA request. Administrators often simply disable MFA for these accounts. However, during penetration tests, CyberCX consultants have had their fair share of authenticating to a service account from 2010 for which the password is simply `Password1`. Utilise Conditional Access Workload Identities (Microsoft, 2023) to block untrusted external authentication events for service accounts because they should largely only originate authentication requests from within an internal environment. Internally, utilise a PAM solution to ensure service accounts are secure with an extensive audit trail.
Opt-In Selective Enforcement
One of the variables that can be configured within a CAP is “to which groups should this apply to?”. Organisations may have an `ALL-STAFF` group they add new users to as part of the onboarding process for which MFA is enforced. However, if an old user is not retroactively added to this group, or slips through the onboarding process, they are left in a state for which MFA is not enforced. MFA enforcement should be opt-out by default rather than opt-in. Any exemptions should be carefully considered and audited.
Exempted Applications
Occasionally, MFA will be broadly applied to users and devices but fail to include all applications within an organisation. SaaS applications within a tenancy are also a variable within CAPs that can have exemptions. In one case, an organisation enforced MFA for the Microsoft suite, but not Confluence. On further review, this Confluence instance contained sensitive information that allowed CyberCX testers remote access to the internal network without MFA. Organisations should review application exemptions and ensure users are not storing credentials in widely readable knowledge bases.
“Trusted” Locations
Without fail, organisations will have an MFA exemption policy for users originating from “trusted” networks, such as their VPN or offices. These ranges however are often quite broad – occasionally overlapping with guest Wi-Fi networks. Threat actors could walk past an office, obtain an authentication token without MFA and continue to use that token remotely. Ensure “trusted” locations are minimal and are truly trustworthy.
Case Study – All Together Now!
On a Red Team, CyberCX 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 – such as by mimicking a mobile device – but this did not result in a bypass on this test. What is important to remember is that CAP are evaluated holistically. Many rules may be evaluated during a given authentication event. As a result, CyberCX 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.
Figure 1 Showing the output of trying combinations through an in-house purpose-built tool.
Conclusion
When implemented correctly, Microsoft Conditional Access Policies are extremely powerful and provide organisations with granular control and auditing over authentication events in-line with the principle of defence in depth. But their complexity can give rise to nested issues which may have surprising or unintended results. A static review of policies is always worthwhile, but it can also be beneficial to look at effective policies from an offensive perspective to ensure what is defined in theory is seen in practice. When defining CAPs, ensure they are: exclusive by default; clear in purpose; correctly labelled; applied consistently with minimal exceptions; and audited to identify abnormal login flows.
CyberCX has teams of experts that specialise in both designing and implementing secure M365 environments, and teams that specialise in offensive reviews (Penetration testing and Red Teaming) of these environments. Contact us and we can assist your organisation with your security requirements.
References
- Burrage, E. (2022, October 4). Increase security, enable quality collaboration for Linux desktops. Microsoft Intune Blog. https://techcommunity.microsoft.com/t5/microsoft-intune-blog/increase-security-enable-quality-collaboration-for-linux/ba-p/3640485
- Dafthack (2022, November 29). MFASweep. GitHub. Retrieved May 9, 2023, from https://github.com/dafthack/MFASweep
- Microsoft. (2023, April 4). Azure Active Directory Conditional Access for workload identities – Microsoft Entra. Microsoft Learn. https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/workload-identity
