Conditional Access is widely used in Azure to prevent unauthorized access. When it works, it can shut down attacks, even if the user's password is known. However, it doesn't always work as intended. For this blog post I wanted to provide an in-depth look at common Conditional Access configurations in Azure, along with potential bypasses.

Common MFA Misconfigurations

Figure 1 is a default template provided by Microsoft to Require MFA for all your end-users. Also, by default, there are no conditions that need to be met for this enforcement. This is the ideal way of rolling out MFA to all end-users as it will prompt any user to enroll as soon as they authenticate to a cloud workload.

Unfortunately, in the real world, this may not be possible. Or, you may not have full buy-in due to constant MFA requests to end-users. What ends up happening is more like Figure 2. This policy excludes trusted IP addresses so registered MFA users don't need to accept an MFA request each time they log in to a cloud workload if they are working from a trusted location.

All seems to be great with this configuration, but what about non-mobile employees that never go outside the barrier of a trusted location? It happens more than you think and ends up leading to Figure 3 where a user may go unregistered with MFA. In some cases, end-users like these may be using weak passwords that allow entry into an Azure Active Directory environment.

During this process, offsite MFA registrations with accounts is something that is also encountered. If you would like to dive more into MFA, check out my previous blog on this at:

Common Device Misconfigurations

There are multiple scenarios that lead to unintended access to cloud workloads via device misconfiguration. One scenario is blocking access to Windows and MacOS devices and excluding trusted locations. A common device platform that gets missed is Linux operating systems. Blocking Linux operating systems used to not be available in Conditional Access. It's worth a review however because there have been times when I have gained unintended access simply by using a Linux operating system such as Ubuntu to log in. I can also just as easily switch my browser user-agent to a Linux-based device. As shown in Figure 4, Linux operating systems should be check marked in blocking non-trusted devices from your network.

This leads into the next topic of device trust, as Figure 4 may not be right for everyone, and employees may need to access cloud workloads from non-trusted IP addresses. Every organization is different and may have varying needs when it comes to accessing cloud workloads from non-trusted devices. At a minimum, an organization should be enabling Hybrid Azure Active Directory join.

By enabling Hybrid Azure Active Directory join, it ensures that devices which access cloud workloads are joined to an Active Directory domain and have been through a standardized build process. It will also eliminate headaches on making sure that Azure Active Directory registered or Azure Active Directory joined devices are not accessing company data.

To get started with Hybrid Azure Active Directory join,I recommend performing targeted deployments first using the following Microsoft document:

https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-control

Targeted deployments work great because you can target devices for testing and set up Conditional Access policies without affecting your entire organization. Figure 5 is a sample Conditional Access policy that requires Hybrid Azure Active Directory joined devices to access any cloud workload.

Once you are ready to switch from targeted to domain-wide deployments, you can make the changes in Azure Active Directory Connect. The following Microsoft document outlines this process:

https://docs.microsoft.com/en-us/azure/active-directory/devices/howto-hybrid-azure-ad-join

This will prevent unintended data exfiltration by requiring an attacker to pivot to a domain-joined machine to be able to exfiltrate data in the event an end-user's password is compromised.

Securing Common Sensitive Data Workloads

Power BI can be a very sensitive data workload and a gold mine for company secrets. I suggest having a Power BI Conditional Access policy by itself for this reason. Both IOS and Android have a Power BI app that can allow it to be used on a smartphone or tablet. This is also an application that is easy to misconfigure. Unless your organization has been implementing Hybrid Azure Active Directory join in Conditional Access along with MDM, the sample Conditional Access policy below is something that should be done relatively early in your cloud journey even if you are not using this service.

Using application enforced restrictions for unmanaged devices is another common problem. During a Cloud Penetration Test, data exfiltration is often tested since organizations need to know if they are prone to data leakage from an end-user compromise. Often times, I find that I can download data from workloads such as SharePoint Online, OneDrive for Business, and Microsoft Exchange Online. Microsoft has excellent documentation on how to prevent this from occurring. For SharePoint and OneDrive access controls, check out the following Microsoft document:

https://docs.microsoft.com/en-us/sharepoint/control-access-from-unmanaged-devices

For Microsoft Exchange Online access controls, look at the following document:

https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/secure-email-recommended-policies?view=o365-worldwide#limit-access-to-exchange-online-from-outlook-on-the-web&preserve-view=true

Once these two actions are complete, you can create a Conditional Access policy to use enforced restrictions from unmanaged devices from a Conditional Access policy template, as shown in Figure 8.

Unrestricted Azure Active Directory Access

Azure Active Directory contains information that can be very useful to threat actors who may be targeting your organization. By default, every user in your organization has access to Azure Active Directory. If an end-user is compromised with a weak password, then an attacker has access to all your email addresses and phone numbers. During a Cloud Penetration Test engagement, this is the most sought-after data to start expanding out password-spraying attacks.

Setting up the following Conditional Access policy will block access to the Microsoft Azure Management Portal:

When restricting this, make sure you set a condition to exclude trusted IP addresses before enabling. It's also a good idea to exclude an account such as a break glass account with global admin rights. Restricting Azure Management can be dangerous if done incorrectly.

After implementing this policy, I recommend restricting normal users from having access to Azure Active Directory. Figure 11 shows how to disable this access in user settings.

Keep in mind that this restriction does not prevent Azure Active Directory data from being exfiltrated with PowerShell. However, the combination of restricting access to the portal with Conditional Access and restricting it in user settings will make it more challenging for an attacker trying to exfiltrate this data from a compromised user ID from an untrusted location.

Closing

Addressing the common mistakes above can help an organization significantly improve their security posture in the cloud. Conditional Access can reach far and wide, so use caution on how many policies you are creating for your organization. Also, this type of testing is covered during a Cloud Penetration Test engagement with TrustedSec. If you have never had a Cloud Penetration Test, or if you have a small cloud footprint but are a M365 customer, please make sure a configuration review or penetration test is considered in your overall cloud strategy.

For more information on Cloud Penetration Testing, TrustedSec has an on-demand webinar that you can view at your convenience.