Shooting Up: On-Prem to Cloud — Detecting “AADConnect” Creds Dump

7 min readDec 30, 2021

Assumption: It is assumed that the attacker has got hold of the local admin account on the domain controller (dc) where AAD Connect is installed and configured.

The Attack — The attack is about dumping the credential information from AAD Connect DB and using that information to move up from On-prem to Azure Cloud.

Background

We know that — AADConnect is used to synchronize users’ information between on-premises AD with the Azure AD on the cloud. This component typically installed on the on-premises domain controller. When AAD Connect gets installed on the system(dc) it creates two accounts for replication / synchronization on that on-prem system(dc) and create one account in Azure AD.

Two On-prem accounts are — MSOL Account and the other is created as a Managed Service Account. Please refer to the following screenshot.

Figure 1. MSOL Account (On-Prem Account 1)

Figure 2. Managed Service Account (On-Prem Account 2)

Azure AD Account — Sync_DC01_xxxx@azuresimuland.onmicrosoft.com. We can see that the account created in Azure AD follows a certain nomenclature.Sync_<Server_Name>_<RandomNumber>@domain.onmicrosoft.com. RandomNumber is a truncated Installation Identifier.

These accounts are used for synchronization between on-prem AD with Azure AD. These accounts have privileges to modify and manipulate the accounts in the Azure AD. It means if the attackers get hold of these accounts’ credentials they can create, modify passwords of the accounts in Azure AD and they can take over the cloud or they can move from on-prem to cloud.

The details related to these accounts (including username and passwords) are stored encrypted in the database (.mdf)on the disk by AAD Connect. The path to the database is shown in the screenshot below— the database name is ADSync.mdf

Figure 4. Path to the AADConnect Database

So, a typical attack consists of dumping of this information from the database and get it decrypted and use it to move vertically (on-prem to cloud).

This information along with other details related to the database gets stored in the registry under ADSync Service as parameters. This information is used later in the attack to connect to the local database to dump the encrypted information from it.

Figure 5. Information Related to AADConnect Database in the Registry

This sensitive information is encrypted with the keyset stored under the ADSync account’s (the account created as Managed Service Account) vault. The path to the Vault is as below

Figure 6. Location of the Credential File that contains the KeySet (used for decrypting the .mdf database)

Now, this keyset is protected/encrypted with DPAPI ( Data Protection API). That means — the keyset that is used to encrypt the AADConnect database (.mdf) is itself encrypted and protected by DPAPI masterkey.

Apparently, each user has its list of DPAPI masterkeys and one of them should be a current masterkey and used as DPAPI masterkey for vault encryption. The information about the masterkeys (that is used to encrypt the keyset) is stored under the ADSync’s account at the following location.

Figure 7. The file containing the DPAPI masterkey

The information about the current DPAPI masterkey is stored in the file name “Preferred” at this location. Using hexdump — we can get the GUID of the current masterkey. Please look at the hexdump of the “Preferred” file below — bytes from 0x24–0x33 gives the GUID of the current masterkey.

Figure 8. Identifying the GUID of the Current DPAPI masterkey

The value at the byte locations from 0x24 to 0x33 are as follows

0xdb, 0xea ,0x42, 0x1d, 0x4a, 0xdc, 0x30, 0x41, 0x80, 0x4d, 0x2f, 0x83, 0xea, 0xc3, 0x6c, 0x8b

We can use PowerShell to get the GUID of the current masterkey.

Figure 9. Getting the GUID of the current masterkey using PowerShell

Now, this is just the GUID of the masterkey and not the masterkey itself. To identify the corresponding masterkey file — we will have to look back to the directory. You can see the file corresponding to the GUID that we just got. That is the file containing the current DPAPI masterkey.

Figure 10. Identifying the file containing the DPAPI current masterkey

Note: you may have multiple files with different GUIDs as their name. In our case, we have only 1 file with guid-like name. If you have multiple files with guid-like names under this directory then using above method you can decide which one is the file corresponding to the current masterkey.

This masterkey needs to be decrypted using DPAPI systemkeys (which gets stored in the registry) as mentioned in the very insightful article by Dirk-jan Mollema — Updating adconnectdump — a journey into DPAPI — dirkjanm.io. Once the masterkey is decrypted, it can be used to decrypt the keyset (stored under the files in the “credentials” directory) and eventually decrypt the information in the .mdf database.

AADInternals — This entire multi-layer decryption process is automated by Dr Nestori Syynimaa (@DrAzureAD) in his tool AADInternals. The cmdlet Get-AADIntSyncCredentials does all the heavy lifting of decryption and gives you the decrypted relevant credential data from the AAD Connect database (.mdf)

The Attack

Performing this attack is very straightforward. Run the cmdlet Get-AADIntSyncCredentials on the machine where the database for AADConnect is residing. This is typically the same machine where AADConnect is installed. Run this cmdlet with the localadmin privileges. Please refer the following screenshot.

Figure 11. Use of AADInternals to dump the Creds

We can see the dump for on-prem account (MSOL) and Azure AD account including their passwords in plain-text.

You can further follow this blog from Dr. Nestori and modify the accounts in the cloud. I could change the display name of one of the cloud accounts in Azure AD. Similar way, I can change the passwords as well of the accounts.

Figure 12. Modification of the Azure Account Attribute from On-Prem

Detection

Now, the important part is detection. How do we detect such activities in our environment? Based on my experiment, I could come up with following detection opportunities for credential dump from AAD Connect database

Detection Opportunity 1 — namedpipe event

One of the steps that this script does it connect to local AAD Connect database to fetch the encrypted details. When it performs this step — it connects to the AAD Connect localdatabase (.mdf) via namedpipe. We get the Sysmon Event 18 for the same. You can notice the pipename, the InitiatingProcess and the UserContext under which this activity is performed.

Now, mind well — we can very well have the similar PipeEvent as legit activity but InitiatingProcess and the UserContext would be different. The Normal event look like below. Notice the differences!! This connection was made with miiserver.exe (ADSync Process) as InitiatingProcess under the ADSync ServiceAccount.

Detection Opportunity 2 — Discovery of Suspicious Information by the Suspicious Process

When you see a probs for the ADSync service.

Figure 15. Probing on ADSync Service by PowerShell by Suspicious Account

Figure 16. Probing on ADSync Service by PowerShell by Suspicious Account

Detection Opportunity 3 — When you see probs around ADSync Services’ parameters

Remember in the “Background” section — we saw the screenshot of the registry where all the parameters related to ADSync were listed. The attacker needs a few of these parameters to get connected to the database. So, if you see probs around these parameters then it is worth to look in to.

Figure 17. Retrieval of AADConnect DB Information (‘Server’)

Figure 18. Retrieval of AADConnect DB Information (‘SQLInstance’)

Figure 19. Retrieval of AADConnect DB Information (‘DBName’)

Once the required information is received (Server,DBName,SQLInstance) from the registry — the same is used for connecting to the database. You will have the logs for that as well.

Figure 20. Use of the retrieved information to connect to AADConnect DB

Detection Opportunity 4 — DPAPI Calls

If your EDR is capable of catching DPAPI calls then you should filter for any suspicious calls (by the process like PowerShell) with “MMS_ENCRYPTION_KEYSET_” as DataDescription and “SPCryptUnprotect” as OperationType.

Detection Opportunity 5 — Token Elevation and LSA Secret Dump

As mentioned by Dr.Nestori in his blog that his script elevates the token of lsass.exe process and then dumps the LSSecrets from the registry. I saw something like following which can be used for detection or atleast suspicious activities which are worth to investigate.

You can see multiple attempts to access LSASecrets by the powershell process.