21 May 2024
Eito Tamura
Introduction
As pentesters or red teamers, we've developed our Tactics, Techniques, and Procedures (TTPs) to target clients' Azure environments, with a particular focus on achieving lateral movement from on-premises infrastructure to the cloud. Microsoft Entra Connect (formerly Azure AD Connect) server has been a primary target for gaining initial access to Azure environments. Recently, Microsoft introduced a new synchronisation technology called Cloud Sync. In this blog, we will explore these two technologies, highlighting the differences from a hacker's perspective and explaining the necessary adjustments to TTPs.
Hybrid Identity
Before delving into Microsoft Entra Connect, let's briefly discuss hybrid identity for those who may not be familiar. In the context of Azure, hybrid identity involves seamlessly integrating on-premises Active Directory with Microsoft Entra ID, enabling users to access resources across both environments using a single set of credentials. Here are short descriptions of the three primary sign-in methods used for hybrid identity: Pass-through authentication (PTA), Password hash synchronisation (PHS), and Federated (AD FS). For detailed explanations, you can refer to the Microsoft official page on hybrid identity here.
Pass-through authentication (PTA) involves authenticating users directly against on-premises Active Directory using the aid of a PTA agent. This method allows users to sign in to both on-premises and cloud-based applications using the same passwords, without the need for password synchronisation.
Password hash synchronisation (PHS) is the simplest and most popular method for achieving a hybrid identity. It synchronises users and a hash of their account NTLM hash from on-premises Active Directory to Microsoft Entra ID. In Tier Zero Security lab, we have PHS with seamless SSO enabled.
Federated sign-in, facilitated by Active Directory Federation Services (AD FS), provides simplified, secured identity federation and Web single sign-on (SSO) capabilities. In federation, a trust is established between unrelated parties like on-premises Active Directory and Microsoft Entra ID. With federation, all authentication occurs in the on-premises environment, and the user experiences SSO across all the trusted environments.
Identifying Sync Technology
As I mentioned earlier, there are two types of synchronisation technology available for Microsoft Entra Connect: Connect Sync and Cloud Sync. In this section, we will cover the methodology for identifying and analysing analyse these technologies.
OSINT using AADInternals
This PowerShell module is described as the ultimate Entra ID (Azure AD) / Microsoft 365 hacking and admin toolkit. It boasts numerous useful functions, encompassing OSINT, authentication for obtaining access tokens, interaction with Azure via various Graph APIs, and a plenty of other functionalities that empower attackers, among other capabilities. The following command can be used to determine whether the target tenant is utilising cloud sync or not.
Invoke-AADIntReconAsOutsider -Domain <domain name>|Format-Table
The following information should also be recorded to aid further testing: Tenant name, Type (Federated), Desktop SSO status, and MDI instance.
Searching for MSOL account using AD PowerShell
During the installation of Entra Connect Sync application, it creates a high-privilege domain user with Replicating Directory Changes All permissions. The account is prefixed with "MSOL_". The following command can be used to determine if the account exists in the AD.
Get-ADUser -LDAPFilter "(description=*configured to synchronise to tenant*)" -Properties description | % { $_.description.SubString(142, $_.description.IndexOf(" ", 142) - 142)}
Searching for gMSA service account using AD PowerShell
During the installation of the Cloud Sync provisioning agent, a group Managed Service Account (provAgentgMSA) is created. This account possesses Replicating Directory Changes All permissions. The following command can be used to query the ground managed service account:
Get-ADServiceAccount -Filter "ObjectClass -like 'msDS-GroupManagedServiceAccount'"
Microsoft Entra Connect Sync
This is the traditional Synchronisation technology which leverages on-premises Microsoft Entra Connect server. As it was mentioned before, it creates a domain account with prefix MSOL_* which has the Replicate Directory Changes All permissions to enable password sync, and Sync_* account in the cloud to update user objects in Microsoft Entra ID. Let's take a look at how we can use this to attack the environment.
Obtaining cleartext credentials
As you can see in the above diagram, a SQL database is created on the Microsoft Entra Connect server. This database contains credentials for MSOL_* and Sync_* accounts. AADInternals has the capability to obtain cleartext credentials. However, due to its association with the threat group APT29 - Cozy Bear, the tool is now flagged as malicious, as shown below:
Furthermore, despite attempts to bypass AMSI, the tool gets blocked immediately when attempting to load the key for decryption. This occurs specifically within the following lines in AADSyncSettings.ps1:
$KeyMgr = New-Object -TypeName Microsoft.DirectoryServices.MetadirectoryServices.Cryptography.KeyManager
$KeyMgr.LoadKeySet($entropy, $instance_id, $key_id)
In the Microsoft Defender for Endpoint (MDE) console, alerts are raised to notify users of potential security threats.
The following technique which leverages adconnectdump and remote dumping was successful against the server with MDE installed. First, dump the SQL database file using the following command:python .\adconnectdump.py [domain.local]/administrator:<password>@192.168.10.80
Then, execute the following commands to use the local database that you downloaded instead of the remote one:
.\ADSyncQuery.exe C:\Users\eitot\Tools\adconnectdump\ADSync.mdf > out.txt
python .\adconnectdump.py [domain.local]/administrator:<password>@192.168.10.80 --existing-db --from-file out.txt
You can see the cleartext credentials for the Sync account and the MSOL account. Note that the above command accesses the LSASS memory on the remote host to acquire information necessary for decrypting the data. While this action does raise an alert on the MDE console, the process itself is not terminated.
Sync account as initial access to Azure
The obtained Sync account is the ideal option for performing authenticated enumeration of Entra ID. This is because the Sync account, by design, does not have MFA enabled. Additionally, the Sync account has the ability to modify any on-prem user objects, including their passwords. While it used to be capable of changing cloud user objects, Microsoft has since addressed this issue, as it often resulted in a full compromise of the Azure tenant by changing the password of the 'Emergency' global administrator accounts.
Analysing Connect Sync application
We discovered an interesting aspect regarding how the Sync account is utilised by the Connect Sync application. Using Proxifier and Burp Suite, we analysed the authentication request sent by the application, as shown below.
Notice that the scope of the access token is https://graph.windows.net/user_impersonation. This is interesting because it indicates an access token for the Azure AD Graph API. Microsoft announced the deprecation of the Azure AD Graph API and three PowerShell modules (Azure AD, Azure AD Preview, and MS Online). Initially announced in 2019, the deprecation was scheduled for March 1st, 2022, then postponed to December 15th, 2022, then to June 30th, 2023, and finally to March 30th, 2024. However, the latest Connect Sync application which uses the Azure AD Graph API is supported until at least April 2025. While it's possible that Microsoft could disable all Azure AD Graph API endpoints not used by the Sync account, if they decide not to do so, the Azure AD Graph API may remain available for a while longer.
Azure AD Graph API
The importance of the Azure AD Graph API lies in two key factors, which make it both advantageous for attackers and problematic for organisations. Firstly, it presents a challenge in terms of restricting access through Conditional Access Policies. While organisations can implement rules to block Sync account from accessing cloud applications like the Azure portal, there's no straightforward method to prevent attackers from leveraging the account to enumerate Entra ID via the Azure AD Graph API. Compounding this issue is Microsoft's decision to allow standard users to read Conditional Access Policies using the Azure AD Graph API 'by design'. From our observations, this has resulted in multiple compromises of high-privilege accounts due to weakness found in MFA bypass within the Conditional Access Policy rules. To illustrate, we will provide an example.
Let's assume we obtained cleartext credentials for the Sync account. We can use AADInternals to obtain the access token for Azure AD Graph API with the following commands:
Import-Module .\AADInternals.psd1
$passwd=ConvertTo-SecureString '<password>' -AsPlainText -Force
$creds=New-Object System.Management.Automation.PSCredential("Sync_AZCONNECT_1ed4c5a8722a@[domain].onmicrosoft.com",$passwd)
Get-AADIntAccessTokenForAADGraph -Credentials $creds
Now, this access token can be used to execute tools like Roadrecon, which is designed for exploring information within Entra ID:
roadrecon auth --access-token <access_token>
roadrecon gather
roadrecon gui
It also has the capability to generate a HTML file containing Conditional Access Policy rules:
roadrecon plugin policies
If any of the on-premises synchronised users are included in the MFA Bypass rule, an attacker would be able to change the password of such users and gain access to Azure as the compromised user.
Microsoft Entra Cloud Sync
As shown in the diagram above, Microsoft Entra Cloud Sync solution uses cloud provisioning agent instead of the Microsoft Entra Connect application. The agent communicates with the Microsoft Entra provisioning service in the cloud, over which users have no control. A Sync account named 'ADToAADSyncServiceAccount' is generated within Microsoft Entra ID. However, this account solely exists in the cloud, and the agent possesses no information regarding it. Additionally, a group Managed Service Account is created within the domain to handle the password sync operations.
Analysing provisioning agent service
To analyse the traffic between the provisioning agent and the provisioning service in the cloud, you would require the client TLS certificate to be imported on Burp Suite. This machine certificate is configured as a non-exportable certificate, so you would need to use Mimikatz to dump the certificate. The commands can be used:
crypto::capi
privilege::debug
crypto::certificates /systemstore:local_machine /store:my /export
Then import it from the Burp Suite as shown below:
One additional step you would need to take in Burp Suite is to configure it to use TLSv1.2, as shown in the screenshot below. By default, Burp Suite will attempt to use TLSv1.3 which is supported by *.syncfabric.bootstrap.his.msappproxy.net but not by *.connector.his.msappproxy.net, resulting in a connection reset.
Now, with the configuration in place, we can view the request in cleartext. The screenshot below illustrates the request for a new user creation, which includes the user's password hash.
Password exfiltration
One potential attack vector we explored in this scenario was password exfiltration. Given that the provisioning agent transmits user password hashes, it presumably converts the NTLM hash into the Microsoft Entra ID password hash format. After examining the decompiled source code, we identified a DLL tasked with password hash generation: Microsoft.Online.Passwordsynchronisation.dll.
We added a simple PoC code for credential exfiltration over HTTP to the method as shown below and recompiled the DLL.
After replacing the original DLL and restarting the service, we started receiving user's DN and the corresponding NTLM password hash on our HTTP listener as shown below. It's worth noting that the krbtgt account is synchronised to Entra ID if you don't apply the filter. With the NTLM hash of krbtgt, a golden ticket attack becomes feasible.
This type of attack can also be utilised by attackers to gain persistent access.
Note that when installing Cloud Sync, another service called 'Microsoft Azure AD Connect Agent Updater' is created which could overwrite the malicious DLL when a new version is released. You can prevent this by modifying one of the DLLs, 'Microsoft.Azure.ADConnect.AgentUpdater.Runtime.dll', and make the following changes to the QueryServerForUpdates method of the CheckForUpdateHandler class.
Compromising the provisioning agent host
Another potential attack vector involves targeting the gMSA service account present on all hosts running the provisioning agent service. If you were to obtain local administrative access to one of these hosts, you could attempt to impersonate the service account. Alternatively, if you compromise the machine account with the running agent, you could read the gMSA account password. This service account possesses Replicating Directory Changes All permissions, enabling an attacker to perform DC sync. The below screenshot shows pass-the-hash attack using Mimikatz then performing DC sync from the service account context.
Summary
In this blog, we explored the differences between traditional Microsoft Entra Connect Sync and Cloud Sync solutions and how they can impact attackers' TTPs. While Microsoft encourages users to transition to Cloud Sync by highlighting benefits such as high availability and support for synchronisation from a multi-forest, disconnected AD environment, users who do not need these features may be reluctant to undergo unnecessary migrations. As a red teamer, it's valuable to be aware of Cloud Sync's existence and understand the technology. Additionally, it may be worthwhile to take a deeper look at the communication between the provisioning agent and the provisioning service to identify any potential bugs that could be exploited.
Follow Us
Follow us on LinkedIn to stay updated with the latest news, announcements, and insights!
Eito Tamura - Principal Consultant