Fickle Multi-Factor Authentication in Microsoft 365
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.
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.
