Conditional Access is one of Microsoft's most powerful security features and the core engine of their Zero Trust architecture. In our opinion it should be the foundation of any Zero Trust strategy for organizations based on cloud. However, if you don't understand how conditional access works, it could give you a false sense of security. In this blog post, we'll show you why it's important to understand the process of evaluating conditional access policy and how to find and exploit flaws in strategy design.
About conditional access
Conditional access is a feature of Azure AD Premium and is disabled by default. There is a feature called security defaults that come into play if no policy is configured, but it is not in the scope of this article. Security defaults are also always disabled when you have one or more conditional access policies in place.
In conditional access, everything is allowed by default. And even if you create one, two or three policies, everything you don't explicitly block is allowed.
In almost every tenant we see, there are holes in the design of conditional access because administrators focus too much on the use cases they want to allow, not on what should be blocked. Conditional access policies are often designed backwards, leaving the tenant vulnerable to attack.
Passwords and conditional access
It is important to understand that conditional access policies in Azure AD are evaluated after the first factor, the user password, is approved. I won't go over password stealing techniques in this article, and everything I explain here happens after the password has been successfully verified by Azure AD (or the on-premisesAD with PTA or ADFS). It is after the first factor that the conditional access policies are evaluated, and the user is granted or denied access based on the requirements of the targeted policies.
Operation of several conditional access strategies
In conditional access, all strategies are evaluated at each connection. This also applies when the requirements of each policy are met. The sum of all requirements of all matching policies is what the user and device must meet to gain access. For example, one matching policy may require multi-factor authentication and another may require the device to comply with Intune. Since the two policies match, both requirements must be met.
The only priority among the policies is that blocking policies always win. This means that if one or more blocking policies match during a connection, the authentication attempt is blocked, even if other policies grant access at the same time.
Some common weaknesses
Of course, the best way to tackle conditional access is never to trigger it at all, to avoid it. There are common weak points in almost every organisation that can be abused.
Exclusion group abuse
It is recommended to always exclude a security group from all conditional access policies. This group should contain two "Break Glass Accounts" that you can use in an emergency. This group should not include any other accounts, but in fact it almost always does. Administrators get sloppy and add themselves, service accounts or complaining users to this group. By stealing the password of one of these accounts, we can ignore the conditional access.
Missing blocking strategies
Administrators tend to create policies to enforce multifactor authentication for some or all of a client's applications. But they often include conditions in these policies, such as allowed platforms or allowed locations. What they don't understand is that if we don't block unwanted scenarios with a corresponding blocking policy, an attacker can simply spoof the location or platform to bypass the policy and connect directly. This is largely what the rest of this guide will cover.
This is the general error message a user receives when access is denied by a blocking policy. Note that the blocking error message may differ depending on the conditions of the blocking strategy. This is to help the user understand what went wrong (see each condition below).
Use the More Information section to see if there are any clues to the condition that triggered the block, such as the location of the IP address, the management status of the device or the targeted application.
Abuse of condition
Conditions are used to determine whether or not a policy should apply. If all conditions are met at login, the access controls for that policy are applied, such as requiring multi-factor authentication or requiring a compliant device. Below are some examples of how each type of condition can be fooled.
User risk / Connection risk
User risk and login risk are part of Azure AD Identity Protection (Azure AD Premium P2). This means that most Microsoft 365 customers do not have it enabled and it will not be a problem for an attacker. But if it is enabled, the attacker should try to behave like the user who owns the stolen account used in the attack. Azure AD Identity Protection detects connections from new countries, anonymous IP addresses, leaked credentials marked in black, etc. An attacker would have to research the user, then use VPNs and other techniques to make the connection appear as legitimate as possible.
This is what you see if a blocking strategy is triggered by this condition:
Device platforms
The device platform is easy to spoof. It is based on the user agent string of the client applications. If a policy includes the platform condition that requires Windows, iOS or Android, you can simply replace your user agent string with anything else, such as a Mac device, a Linux device or a space station. It is simply a text string and Conditional Access interprets it to look for the operating system. It is recommended to have a blocking policy that blocks all unwanted platforms.
Here is how you can modify your user agent string with the developer tools in Microsoft Edge:
This is what you see if a blocking strategy is triggered by this condition:
Locations
The location condition is based on the IP address. These are called named locations in Azure AD and can be set to certain IP address ranges or countries. If there is a policy blocking certain countries, an attacker can easily circumvent this with a VPN service terminating in the same country as the organisation. If there is a policy that only allows particular IP addresses such as the company's public IP address, this becomes a bit trickier. If the attacker already has a foothold in the internal network, this would allow them to bypass this. Given that most attacks these days come from the On-Premise, this is very likely.
This is what you see if a blocking strategy is triggered by this condition:
Client applications
Client applications mean protocols. What protocol does the client use when authenticating to Azure AD. Many organisations are starting to block legacy protocols such as POP3, IMAP and SMTP by blocking Other and ActiveSync with Conditional Access. But there are almost always weaknesses such as excluded accounts, "Break Glass Account", excluded administrator roles, etc. Test different protocols to see if the attempt is blocked. This can help you understand what is allowed in the policy design.
Modern authentication can be blocked from unmanaged devices and, in this case, you can try to access a corporate device (if the site has been compromised) or you can try a tool like AAD Internals which includes the ability to add a fake Azure-enabled device AD and, if necessary, grant the target client. You might be lucky to pull such an attack from.
Access to the browser is almost never blocked by anyone, so the browser portals would probably be your way.
This is what you see if a blocking strategy is triggered by this condition:
Status of the device
The device status condition is not applicable as it excludes and only ever includes devices.
Abuse of access control
If you are lucky, you were able to bypass all the conditions implemented above. In that case, you are already logged in and won't need to read any further. But if there are stubborn policies in the way, your next step would be to abuse the access controls. This is more difficult and requires a bit more work.
When all the conditions in a policy match, the requirements under Access Controls in that policy must be met, otherwise the authentication attempt is blocked. A policy can have one or more requirements, and the policy can be set to require any or all of them to be met. As mentioned earlier, multiple policies can also match at the same time and require different checks. In this case, all the different requirements of the strategies must be met.
Requiring multi-factor authentication
This is by far the most commonly used access control. It requires the user to verify their identity with multi-factor authentication. There are many known MFA attacks such as token theft MFA, abuse of telecommunications (SMS OTP transfer) and various phishing techniques to trick the user into approving MFA. An attacker would have to succeed in one of these attack techniques to gain access. Note that the MFA access control always triggers when it is activated, even if one of the other access controls also applies but fails. These failure messages are displayed after the MFA check. This is to protect the tenant from conditional access fuzzing attacks.
You know you are targeted by this access control when you see this:
Require a hybrid device attached to Azure AD
This condition requires a hybrid tenant with synked devices on site. When you see this message, you know that the client is a hybrid. To bypass this requirement, you can run the attack on-premises. An on-premises device is probably already attached to Azure AD hybrid. Note that this access control error message always appears before the Intune compliance error message if both are enabled.
You know you are targeted by this access control when you see this:
Require the appliance to be marked as compliant
If the device is required to be policy compliant Intune, there are two ways to do this. You can use a compromised corporate device registered withIntune and run the attack from there, or you can try to register a fake device with a tool like AAD Internals to access it. Note that if you get this error message when you try to connect from an unmanaged device, there is no policy that requires Azure AD hybrid junction.
You know you are targeted by this access control when you see this:
Require an approved client application
This access control is for iOS and Android only and will not work with other platforms. It ensures that the user logs in with an approved Microsoft app from the App Store. Work around this by using Windows or Linux.
Require an application protection strategy
This requires application protection Intune. This can only be applied to Android and iOS so that an attacker can simply use Windows or Linux instead.
