Microsoft Entra Connect (formerly Azure AD Connect) supports user-friendliness when an on-premise Active Directory and Microsoft Entra (formerly Azure Active Directory) are in use at the same time. Once synchronization is set up, users only need to log in once to have access to both services. However, many administrators are not aware of this: When setting up Microsoft Entra Connect (formerly Azure AD Connect). A special account has been created that has extensive rights and therefore represents a worthwhile target for attackers. In this article we explain, how hackers can act in such an attack and how you can adequately protect yourself against it.
If you would like to first find out more about Microsoft Entra (formerly Azure AD), you can find all the basics in our basics article What is Microsoft Entra (formerly Azure) with lots of clear screenshots. You can find more attacks and protection options here:
Microsoft Entra Connect (formerly Azure AD Connect) is an application from Microsoft. With the Connect service, admins can Connect domains in a classic on-premise Active Directory to an Entra/Azure Active Directory within an M365 tenant. This has the advantage that users Log in to both services with an account name and password can. The boundary between the two services is often not even noticeable to users.
There are various options offered by Microsoft for this connection or synchronization. In our scenario, we are looking at a connection that is very common in reality because it is the simplest and quickest form of Microsoft Entra Connect (formerly Azure AD Connect).
In our scenario, our attack target is structured as follows: The admin connects an existing domain (secperts.com) in his AD (ON PREM) with the Microsoft Entra ID (formerly Azure AD) (also secperts.com). For this purpose he installs the “Microsoft Entra Connect” tool (formerly Azure AD Connect) on a dedicated Windows server that is part of the ON-PREM domain. By default, Microsoft Entra Connect uses “password hash synchronization”.
This default setting causes the domain controllers in the local domain and the Entra (formerly Azure) AD to use the password NT hash sync to an account. This allows users to log in to both services with the same password. For this purpose, Microsoft Entra Connect (formerly Azure AD Connect) uses the “DC-Sync” function. This is also used by local domain controllers to keep their hash database NTDS synchronized.
Using an entity with the appropriate rights, it is therefore possible to request the NTDS from any domain controller and receive it in full. An account with DC sync rights therefore has access to all NT hashes of all accounts in a domain.
In order for the synchronization between cloud and local AD to work, the Microsoft Entra Connect tool is installed a special account in the local AD created. This account has the DC sync rights mentioned above and therefore access to all NT hashes in the domain. This makes this account very interesting for attackers: The DC-Sync has special privileges that are usually only reserved for domain admins and the domain controllers themselves.
A possible scenario for abusing the functionality of the Entra (formerly Azure) sync is therefore a Attack on the special DC-Sync account. Attackers can identify this account by the following characteristics:
Attackers can easily find the account in a target domain based on these characteristics. Due to its rights, the account also represents a worthwhile target for privilege escalation to domain admin.
The goal of attackers is basically to take over the domain with domain admin rights. The approach here is therefore one local privilege escalationto abuse the server by increasing rights within the domain.
This scenario is realistic, because most admins are not aware of how dangerous DC Sync rights are and that this special account for Entra (Azure) Sync has these rights. It is often the case that the server and Azure AD Connect are set up and then work undisturbed without any further measures being taken to secure the system.
If we now manage to obtain the rights of a local administrator on the server (e.g. because LAPS is not used) and we were able to obtain the credentials for the local admin account elsewhere, there is no longer much chance of extending our rights Away.
Unless it's a good one Endpoint Protection is in use and no Credential Guard is used, can already be one LSASS dump via lsassy are enough to get the plain text password of the MSOL account. However, Lsassy is detected and prevented by most EPP solutions, including Windows Defender, which is activated by default.
The LSASS dump should therefore not be the path of our choice here, because with that Example below was “cheated” and Windows Defender was deactivated. However, below we present a simple 2-step attack that works even with Windows Defender activated.
In this section, we as penetration testers put ourselves in the perspective of malicious attackers. We will show that we can gain control of the domain admin account in just 2 simple steps.
In the first step we want to obtain the password of the special MSOL account with the DC-Sync rights. For this we used a tool called CrackMapExec (CME), in which we do this Module “msol” use. When executed, this runs a Powershell script on the target and can thereby extract the plain text password of the MSOL account. This variant is much less noticeable compared to the LSASS exe dump and is (at least as of today) not noticed or prevented by many EPP solutions.
We run the script with the following command and get the password of the MSOL account in the output:
cme smb TARGET-IP -u LOCAL-ADMIN-ACCOUNT -p PASSWORD --local-auth -M msol
Once we have the password we are just a single CME command away from full domain takeover. We used the following command to dump the domain's NTDS:
cme smb 10.1.1.10 -u MSOL_ac290fc6510f -d secperts.com -p '%uY*rI?
hfya{tb{.IpWrGFZ]Mcga^*v$a-b9V@*0/@x}NNwIn-1{^;*p*z*j/F*V%?^_iC!
b3=@AQI^*MG&UE=B9E^l(]hbtGiQ]1rM7/@V;3[(}H5;!BA:t5*Gk91W' --ntds
The command abuses the DC sync rights of the MSOL account and gives us all accounts and associated NT or LM hashes. About Pass the Hash We can now take over the domain with the NT hash of the account Administrator@secperts.com. Alternatively, we can create a Golden Tickets using the NT hash of the KRBTGT account.
In short: the domain is compromised and is defenseless against a potential attacker.
Now let's switch back to the perspective of the actual domain administrator: How can you protect yourself from such an attack? The system on which Microsoft Entra Connect (formerly Azure AD Connect) is running must be specially protected for this. The same applies to the account used for the synchronization service.
According to Microsoft's own tiering model, you should place both the system and the account in the so-called T 0 (Tier Zero). This permission level is reserved for particularly powerful and sensitive accounts.
This means that only accounts with domain administration rights are allowed to have corresponding rights on the server and, accordingly, the local administration account is particularly worthy of protection. Here is the common recommendation, LAPS (Local Admin Password Solution) so that the local administration account receives an individual password that only T0 accounts have access to.
In addition, on the server Credential Guard be used. A modern one Endpoint Protection is also mandatory.
With Microsoft Entra Connect (formerly Azure AD Connect), as with numerous other applications, the following applies: a functioning system is not necessarily a secure system. You have to actively deal with security aspectsto identify potential points of attack and protect them accordingly.
In the case of the Connect service, this is the one specifically for this purpose DC-Sync account set up in the local AD with the initial abbreviation MSOL. This account has Access to all NT hashes of all accounts in his domain and should therefore be given special protection.
A suitable protective measure is to keep this MSOL account in Tier Zero to locate. A common recommendation here is to use LAPS (Local Admin Password Solution). The use of Credential Guard on the server and one modern endpoint protection complete your protection.
This means you can use the convenience of Microsoft Entra Connect (formerly Azure AD Connect) without making yourself significantly more vulnerable.
We use cookies, and Google reCAPTCHA, which loads Google Fonts and communicates with Google servers. By continuing to use our website, you agree to the use of cookies and our privacy policy.