How Attackers Move from Azure Active Directory to On-Prem AD
Microsoft’s Active Directory (AD) continues to be a primary target for attackers, and as reliance on cloud increases, organizations are under increasing pressure to protect AD beyond just those on-premises deployments. Azure Active Directory (Azure AD) is Microsoft’s directory services platform for managing and securing identities in the cloud. And just like on-prem AD, Azure AD is vulnerable to attackers exploiting misconfigured user roles or access to move laterally, escalate privilege, access sensitive data and deploy malware. In hybrid environments where on-prem AD connects to Azure AD, one can even be abused to exploit the other.
Unfortunately, every Active Directory environment in the world is vulnerable to identity attack paths. To execute such an attack path (also commonly known as an identity snowball attack), the adversary uses phishing, or other tactics, to compromise a user with access to a machine on a network.
Once they have the ability to execute code, they use a variety of techniques (and tools like Mimikatz or Cobalt Strike) to move laterally and escalate privilege, getting credentials to users with more and more privilege until they get the access they need to accomplish their goals. Since these techniques abuse legitimate services and valid user credentials, they’re very difficult for defenders to detect.
But attack paths aren’t restricted to just on-prem, nor do they stay just in the cloud. In fact, part of why adversaries can rely on Attack Paths to take control of almost any enterprise’s AD environment is because they can cross between on-prem and the cloud.
Specifically, how an attacker moves from Azure AD to on-prem AD is not well documented by existing security research. But it is important to understand how this works because it opens the possibility of using an Azure AD tenant to bridge the gap between disparate environments that do not explicitly trust each other. This makes the prospect of taking over an Azure AD tenant even more attractive and impactful as an attacker.
Mind the Gap: Lateral Movement from Azure to On-Prem AD
One of these attack methods that my colleagues and I have researched abuses Microsoft Endpoint Manager to move laterally from an Azure tenant to an on-prem AD domain. Azure provides organizations with all the tools they need to manage user and service principal identities, including ConfigMgr, Intune and Endpoint Manager.
These tools allow admins to configure endpoints to a certain extent — it does not allow as much control as Group Policy, but the scope of systems that can be configured and controlled with these tools is significant. In addition, a computer can be joined to both an on-prem AD domain and an Azure AD domain — Microsoft calls this “Hybrid Azure AD join.” Many organizations do this because they want to manage as many endpoints through Azure as possible to reduce the number of separate administrative tools they need to use.
If an organization is using Hybrid Azure AD join to manage on-prem Windows systems, then an attacker with control of a “Global Admin” or “Intune Administrator” principal can execute arbitrary PowerShell scripts on those on-prem devices as the SYSTEM user. Because on-prem systems from different AD domains can be hybrid-joined to the same tenant, attack paths can start in one on-prem domain (or one of the many other identity platforms that can authenticate to Azure) and end in another on-prem domain, where absolutely no domain or forest trusts exist.
To put it more plainly, pivoting from an Azure AD tenant into an on-prem AD domain can enable attack paths between completely distinct identity management environments and platforms that do not explicitly trust each other, or even know about each other. This is the first attack vector we’ve discovered so far that allows turning control of an Azure tenant into code execution within an on-prem domain without needing to reset on-prem user passwords.
Protect and Mitigate the Gap: Auditing Roles Held by Service Principals and Users
To prevent this attack path, Azure admins should audit roles held by service principals and users and compare them to any other identities that have control over applications. This attack requires the adversary to have the Global Admin or Intune Administrator roles, so looking at who has these roles is a good place to start in terms of prevention. Defenders may be able to audit which users have those roles activated through the Azure Portal. Otherwise, the Azure AD PowerShell module can be used to take account of anyone who currently has those roles activated.
When examining principals that have the Global Admin role activated, defenders should assess whether all the users on that list are trusted to execute code as SYSTEM on their organization’s Endpoint Management-enrolled, hybrid-joined systems. Additionally, defenders can audit which systems within on-prem domains are being managed by Intune. There are several methods for doing this, depending on what sort of telemetry or information the defender has access to. There are also a number of AD security solutions that can help detect and prevent attacks in process or analyze an AD environment to find misconfigurations and overprivileged users that can be fixed to eliminate attack paths.
A more detailed write-up of the enumeration, execution and detection for this attack is available here.
Identity and access management on-prem and in the cloud are two sides of the same coin.
Hybrid environments allow adversaries to move from cloud services like Azure AD to on-prem AD and vice versa through new attack paths. As Microsoft continues to introduce more management capabilities that blur the line between the cloud and on-prem, the appearance of more attack primitives of this nature will be expected (if not guaranteed). For organizations with a hybrid infrastructure model, comprehensive protection — including the use of methods like attack path management — can help measure and mitigate an organization’s overall AD risk exposure to keep users and sensitive data safe.