How Quickly do Threats leak from a Compromised AD into the Cloud?

As organizations move to the cloud, on-premises environments (and their security) are put in the background as the focus shifts to the cloud. Nevertheless, most organizations I know are in a hybrid scenario where the on-premises environment holds the master data and synchronizes everything into Azure Active Directory. This blog explores how an on-premises environment is connected to the cloud and how an attacker might move from on-premises to the cloud laterally (moving between two different systems/platforms). After the lateral movement, an attacker is able to move its attack from the on-premises environment to the cloud. This attack could potentially impact Exchange, Sharepoint, and Teams.

Your Crown Jewel: Azure AD Connect

Both on-premises and cloud environments are connected using an application to synchronize directory objects. The application used is either Azure AD Connect or Cloud Sync. Cloud Sync is the newer variant of Azure AD Connect, but it does not have feature parity at the time of writing. A complete comparison of all features is available here.

Because Azure AD Connect is responsible for replicating identities between the two environments, it must have permissions in both environments. This means the application has permissions to update identities in both on-premises AD and Azure Active Directory. If a threat actor breaches the server hosting the Azure AD Connect application, the effects could be disastrous. This is why an Azure AD Connect server should be secured with the same care as Domain Controllers. They are considered a tier-0 servers and should only be administrated by as few people as possible.

Dr. Nestori Syynimaa shares a great deep-dive example of Azure AD Connect abuse. In this presentation, he shares how the two environments are connected and how a user with on-premises access can reset the account of a global administrator, or even completely delete the account. This goes to show you how much power the on-premises service account has, as it has a direct connection between your on-premises and cloud environment.

Administrator Accounts

Because many organizations synchronize identities from the on-premises environment to the cloud, this is an easy way for attackers to execute the lateral movement. If an on-premises account is breached, it is much easier to pivot to the cloud account if they share the same set of credentials. This is because an attacker does not have to guess the password of the cloud account, as it will be the same as the on-premises one. That is why it’s of paramount importance to use cloud-only accounts for your administrators. Having separate administrator accounts is a good step to take, but the accounts should not be synced at all costs. Synchronized administrator accounts are the easiest way to pivot between the two environments (as it creates a dangerous connection between the two environments), and coping with this inconvenience of having two sets of credentials is a small price to pay compared to the risks it remediates.

Treating the Office as a Public Network

Many organizations I work with still have an MFA whitelist configured to avoid MFA requests if a user logs in from a corporate office. This is often done to avoid too many MFA requests, but it is not a setup I recommend. If we are looking at this setup from a zero-trust perspective, the fact that a connection originates from the public IP of your office does not mean that a sign-in is more secure. Some organizations don’t distinguish between their corporate and guest network, which means sign-ins originating from the guest network might not be subject to MFA.

To strengthen the organization’s identity posture, configuring Conditional Access to exempt office locations from MFA challenges should be avoided as it creates additional risk. By treating your offices as a public network (and thus requiring MFA), you are decreasing the chances of a threat actor jumping from the on-premises environment to the cloud.

Script Security

Engineers commonly create scheduled tasks to automate certain jobs. If you are executing Active Directory tasks, it is easy to configure a service account with permissions and have the task run in the context of that service account. When using cloud services, authentication happens differently, and an app registration with a client secret or certificate is required. Far too often, I see those secrets saved in plain text in the script. This means a threat actor can easily extract the credentials from the script and use them to access the cloud.

The recommended approach is to shift from scheduled tasks to Azure Functions or Automation Accounts. There are two main advantages to this approach. Firstly, running scripts on the Azure platform is relatively cheap if you keep the load low enough. Secondly, built-in Azure Resources such as Automation Accounts and Function apps are able to access cloud resources securely using a Managed Identity, as explained by Tony Redmond in this article. Using Managed Identities means there are no plain-text credentials to be abused.

The other advantage of hosting your scripts in the cloud is that there are built-in access logs, which allow you to know when a change happens or an actor receives unauthorized access. A great example of this advantage is described in the following article about Wiper Malware. This malware is targeted specifically to Microsoft 365 but can be easily traced by using the built-in audit logs from Azure AD and Office 365.

Remember the Basics

The goal of this article is to demonstrate which connections exist between an on-premises and cloud environment. While we have covered quite a few topics, we have only scratched the surface. It is important to remember that a hybrid connection means there is an entry point into your cloud environment from your on-premises AD environment. Just because the cloud is all nice and shiny doesn’t mean there aren’t other things to worry about.