d4rthmaulcop

Abusing AZUREADSSOACC for Pivoting From on Premises Active Directory to Azure

Published

Introduction

Most modern organizations today are hybrid environments consisting of both traditional on-premises Active Directory and Entra ID. Often times on-prem Active Directory accounts are synced with Entra ID. While this setup has it’s many benefits, it can also lead to Azure tenant compromise via the AZUREADSSOACC$ machine account. In this blog, we explore how threat actors can abuse this account to pivot from on-prem AD to Azure, leveraging synced Global Administrator accounts to compromise cloud resources. We’ll outline the attack methodology, highlight its impact, and provide actionable defenses to secure your hybrid identity environment.

Brief Overview of Hybrid Identity in Azure/Entra ID

Hybrid identity in Azure/Entra ID enables organizations to bridge their on-prem Active Directory (AD) with Azure/Entra ID, providing seamless access to both on-premises and cloud resources. This is achieved using tools like Microsoft Entra Connect, which synchronizes on-prem user objects to Azure/Entra ID and supports features like single sign-on (SSO). By integrating these environments, users can leverage a unified identity for authentication across hybrid workloads without having to put in a pesky password multiple times.

Attack Overview

Often times during an internal penetration test, domain administrator privileges are achieved and abused to perform DCSync attacks to get NTLM hashes for other high-privileged accounts. An account that’s often targeted is the AZUREADSSOACC$ Active Directory machine account object. This account is used by Active Directory to authenticate on-prem users to Microsoft Azure. If this account is compromised, it can be abused to construct Kerberos tickets for on-prem users, including Global Administrators that are synced from on-prem users.

Attack Prerequisites

  • Active Directory environment with Azure/Entra AD Connect enabled.
  • The AZUREADSSOACC$ NTLM hash.
  • A hybrid identity configuration with a synced Azure Global Administrator account.
  • Lax MFA or Conditional Access Policies (CAP) that allow for authentication without MFA
  • Often times, logins from inside the corporate network don’t get prompted for MFA.
  • An on-prem user synced with Azure/Entra along with their Active Directory domain SID.

Basic Recon

The first step in this attack is some basic Azure recon to verify Azure/Entra SSO is being used. There are several ways to go about this but we’ll use the AADInternals tools on the AADInternal website as well as the AADInternals PowerShell module Notice that DesktopSSO is enabled. The next step is to identify which on-prem Active Directory users are synced with Entra ID and if any of those users happen to be Global Administrators. The ROADtools toolset is an excellent way to do this recon. First authenticate to Azure/Entra with any valid user and then issue the gather command. Start up the GUI and navigate to “Directory Roles”. Look for any accounts that have the account type AD. This means that the accounts are synced with on-prem Active Directory Accounts. Clicking on the account in question can also reveal that it’s synced with AD. Using rpcclient on the internal network, we get get the SID for the dwight.schrute user account.

Pivoting to Azure as a Global Administrator

Using the AADInternal PowerShell toolset, we can create a Kerberos ticket for the dwight.schrute account to pivot to Azure. Take note that we do not need to be able to talk to the on-prem domain controller as we are issuing a Kerberos ticket via the cloud. We can obtain a Kerberos ticket via the dwight.schrute account’s SID and the NTLM hash of the AZUREADSSOACC$ machine account with the command $kerberosTicket=New-AADIntKerberosTicket -SidString <Internal AD SID> -Hash <SSOACC$ NTLM Hash>. We now have a Kerberos ticket for the dwight.schrute Global Administrator and can request additional tokens to authenticate to other Azure API endpoints. For example, the screenshots below using the command $AADGraphToken=Get-AADIntAccessTokenForAADGraph -KerberosTicket $kerberosTicket -Domain "example.com" to obtain a token for Azure AD Graph. From here, a threat actor could request additional tokens to compromise other Azure resources such as subscriptions, virtual machines or create other Global Administrators for persistence.

Accessing Azure Virtual Machines

Utilizing the same methodology as before, we can get administrative command execution on Azure virtual machines by assigning the “Virtual Machine Contributor”. First, let’s grab another Kerberos ticket and set the role while saving the tokens in $AccessToken. Remember to refresh the $AccessToken variable because the role assignment changed. If this is not done, then any commands that will run after will have an access token that does not have the new “Virtual Machine Contributor” assignment. Using the command Get-AADIntAzureVMs, we can list the virtual machines that are associated with this Azure subscription. Below we see three VMs, in particular, we see a CorpAppServer Linux virtual machines. While the “Virtual Machine Contributor” role doesn’t allow you to “access” the virtual machine or the virtual network, you can manage them. However, we can run commands on the virtual machines via Azure. Technically, any commands or scripts we run are executed by the Azure VM Agent that’s running on the Azure virtual machine. As a proof-of-concept, I simply ran a whoami and a uname command. But since the commands are run as root for Linux and NT Authority\System on Windows, we can basically do whatever we want on those hosts.

High Level Defensive Recommendations

On-Premises Active Directory

Azure/Entra ID

  • Enforce MFA for all privileged roles.
  • Use Conditional Access policies to limit access.
    • Test Conditional Access policies to ensure all gaps are covered.
    • Consider requiring MFA for administrators even if logins originate from inside the corporate network.
  • Enable Identity Protection and monitor risk-based sign-ins.
  • Monitor Azure roles such as “User Access Administrator” or “Virtual Machine Contributor”.
  • Ensure on-prem service accounts are not being synced to Azure/Entra. If they need to be, ensure MFA is in use and lock down access with strong conditional access policies.

General Monitoring

  • Use SIEM tools to correlate on-premises and Azure logs.
  • Detect unusual activity related to AZUREADSSOACC or synced accounts.

Conclusion

The integration of on-premises Active Directory with Azure/Entra ID through hybrid identity solutions is a powerful tool for enabling seamless access to modern workloads. However, as demonstrated, misconfigurations and overlooked accounts like AZUREADSSOACC can create significant security risks, allowing attackers to pivot between environments and escalate privileges. By understanding these vulnerabilities and implementing proactive defenses, organizations can secure their hybrid identity infrastructure and protect both on-premises and cloud resources. Regular audits, strong access controls, and robust monitoring are essential to staying ahead of potential threats in this evolving landscape.

Resources