Az - PHS - Password Hash Sync
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
From the docs: Password hash synchronization is one of the sign-in methods used to accomplish hybrid identity. Azure AD Connect synchronizes a hash, of the hash, of a user's password from an on-premises Active Directory instance to a cloud-based Azure AD instance.
It's the most common method used by companies to synchronize an on-prem AD with Azure AD.
All users and a hash of the password hashes are synchronized from the on-prem to Azure AD. However, clear-text passwords or the original hashes aren't sent to Azure AD. Moreover, Built-in security groups (like domain admins...) are not synced to Azure AD.
The hashes syncronization occurs every 2 minutes. However, by default, password expiry and account expiry are not sync in Azure AD. So, a user whose on-prem password is expired (not changed) can continue to access Azure resources using the old password.
When an on-prem user wants to access an Azure resource, the authentication takes place on Azure AD.
PHS is required for features like Identity Protection and AAD Domain Services.
When PHS is configured some privileged accounts are automatically created:
The account MSOL_<installationID> is automatically created in on-prem AD. This account is given a Directory Synchronization Accounts role (see documentation) which means that it has replication (DCSync) permissions in the on-prem AD.
An account Sync_<name of on-prem ADConnect Server>_installationID is created in Azure AD. This account can reset password of ANY user (synced or cloud only) in Azure AD.
Passwords of the two previous privileged accounts are stored in a SQL server on the server where Azure AD Connect is installed. Admins can extract the passwords of those privileged users in clear-text.
The database is located in C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf.
It's possible to extract the configuration from one of the tables, being one encrypted:
SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;
The encrypted configuration is encrypted with DPAPI and it contains the passwords of the MSOL_* user in on-prem AD and the password of Sync_* in AzureAD. Therefore, compromising these it's possible to privesc to the AD and to AzureAD.
You can find a full overview of how these credentials are stored and decrypted in this talk.
If the server where Azure AD connect is installed is domain joined (recommended in the docs), it's possible to find it with:
You can also use adconnectdump to obtain these credentials.
Compromising the Sync_* account it's possible to reset the password of any user (including Global Administrators)
It's also possible to modify the passwords of only cloud users (even if that's unexpected)
It's also possible to dump the password of this user.
Another option would be to assign privileged permissions to a service principal, which the Sync user has permissions to do, and then access that service principal as a way of privesc.
It's possible to use Seamless SSO with PHS, which is vulnerable to other abuses. Check it in:
Az - Seamless SSOLearn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
