The threat actors were successful in pivoting from the on-premises environment to the Azure AD by compromising the system where the Azure AD Connect agent was installed.
Azure AD Connect is a free Microsoft tool for synchronizing your on-premises AD identities with Azure AD thereby enabling Single Sign-On (SSO) and federated identity services.
Hybrid identity using Azure AD Connect
Here we discuss common attack paths that adversaries can take to compromise the cloud environment (in this case Azure AD) from the initial breach of the on-premise Azure AD Connect server and how to detect such attacks in your enterprise using Logpoint.
Attack paths enabled by compromise of Azure AD Connect servers
In this incident, the threat actors obtained access to a highly privileged account that they used to access a system where the Azure AD Connect agent was installed. As mentioned, Azure AD Connect is an integral component of a hybrid environment that syncs your on-premises directories with Azure AD thereby providing a common identity for accessing both cloud and on-premises resources.
The Azure AD Connect express installation process will create multiple accounts in both on-premises AD and Azure AD. Two main accounts are the AD DS Connector account (having the prefix MSOL_) and the Azure AD Connector account (having the prefix Sync_[ServerName]_). Both accounts are armed with powerful permissions. The former has permission to replicate directory changes, modify passwords, modify users, etc, whereas the latter is assigned the Directory Synchronization Accounts role. In older versions, this account might be assigned with the Global Administrator (GA) role.
The Directory Synchronization Accounts role is a special built-in role that is used only by Azure AD Connect service.
Microsoft has assessed with high confidence the threat actors used the AADInternals [S0677] tool to extract the plaintext credentials of the privileged Azure AD connector account which was subsequently used to pivot from the on-premises AD environment to the Azure AD environment.
The AADInternals toolkit is an open-source PowerShell-based framework containing tools for administering and exploiting Azure AD and Office 365.
The threat actor used the Get-AADIntSyncCredentials Cmdlet, which allows any local administrator on the Azure AD Connect installed system to extract the plaintext credentials of both the AD DS Connector account and the Azure AD Connector account. The threat actor used the extracted plaintext credentials to sign in to Azure AD. Unfortunately for the victim, the Azure AD Connector account had the Global Administrator (GA) role as it was set up for an old solution (DirSync).
Detection using Logpoint
Let’s see how with Logpoint Converged SIEM, you can detect the attack scenarios mentioned above along with the accompanying post-compromise activities.
Log Sources Needed
It is advised that Logpoint customers install both the Entropy and JSON Parser plugins as they are used in the detection mentioned below.
Fetching Office 365, Azure AD and Defender for Cloud Apps logs into Logpoint
AADInternals requires local admin privilege in the Azure AD Connect server to dump the plaintext credentials of the connector accounts.
Using AADInternals to dump plaintext credentials of the AD and Azure AD connector accounts
As written by security researcher “imp hash” in this blog, under the hood, the cmdlet connects to the local Azure AD Connect DB via a named pipe which can be logged by Sysmon Event ID 18.
Searching for Named Pipe connection events
Logpoint provides a baseline Sysmon configuration that customers can use as a starting point to create their own configuration tuned to their specific environment.
We also have another alert—AADInternals PowerShell Cmdlet Execution—that detects the execution of AADInternals Cmdlets based on Script Block Logging events. If your administrators are using AADInternals then you will need to allowlist their privileged access devices to eliminate false positives.
Searching for AADInternals Cmdlet executions
However, analysts should keep in mind that a determined adversary can change the default cmdlet names to evade detection. An alternative generic way of detecting suspicious PowerShell script execution is using the entropy plugin to monitor scripts that have high entropy than the baseline threshold value.
It is crucial to note that this requires the analysts to have performed proper base-lining using sufficient historical events (90 days or more) and extensively filtered out legitimate scripts that are running on their network to reduce false positives.
Searching for suspicious high-entropy PowerShell script executions
Azure AD Connect provides several mechanisms such as Password Hash Synchronization (PHS), Pass-through Authentication (PTA), etc. As pointed out by Dirk-Jan Mollema, if an organization uses Password Hash Synchronization (PHS), Azure AD Connect has the privilege to perform a DCSync [T1003.006] to dump all password hashes from domain controllers.
Azure AD Connect sync with Password Hash Synchronization (PHS) enabled
Using on-premise AD connector account to perform DCSync using Mimikatz
We have an alert for detecting DCSync but you may notice that in its query, the user accounts having MSOL_ prefix are filtered out because MSOL_* accounts legitimately replicate directory information in a scheduled interval (2 minutes for our lab). You will need to identify the interval value and how many events are generated on each instance (3 for our lab). Seeing a higher event count than normal at a specific point warrants an investigation as seen below.
Searching for irregularity in timeline of directory replication events
Adversaries can and have used the extracted plaintext credentials of the Azure AD connector account to sign in to the cloud. Use the Office 365 Unified Audit Logs (UAL) to monitor for interactive sign-ins by the Azure AD Connector account which should not occur.
Searching for interactive sign-ins of Azure AD connector account
The UAL contains user, group, application, domain, and directory activities performed in the Microsoft 365 admin center or in the Azure management portal.
If you have not installed Azure AD Connect agents using the express method, then your Azure AD Connector accounts will not have a prefix of Sync_[ServerName]. This means you will have to obtain the list of Azure AD Connector accounts and plug them in accordingly in the above query.
For enterprises that have Azure AD Identity Protection licenses, risky sign-ins may be blocked by Identity Protection sign-in risk policy depending upon the policy configured.
Sign-in risk policy that prompts user for MFA when the sign-in risk is medium or above
Sign-in blocked prompt
Viewing Risky Sign-in Details in Azure Portal
The failed sign-in gets logged in the Office 365 Unified Audit Logs (UAL) as seen below.
Searching for failed interactive sign-ins of Azure AD connector account
Organizations can also fetch the Azure AD user risk events using our Azure Log Analytics fetcher, provided you have enabled forwarding of corresponding Azure AD diagnostic logs to the Log Analytics workspace.
Forwarding Azure AD diagnostic logs to Log Analytics workspace
Searching for Azure AD user risk events
Detecting post-privilege escalation activities from the Mango Sandstorm incident
The threat actors activated the Global Administrator role through Azure AD Privileged Identity Management (PIM) and elevated access to manage all Azure subscriptions and management groups of the target.
Searching for successful PIM activation of Global Administrator role
Searching for ElevateAccess event in Defender for Cloud Apps logs
The threat actors gained full access to user mailboxes through Exchange Web Services (EWS) by providing an existing legitimate Azure AD application with both the full_access_as_app permission and administrator consent. This activity can be traced in the Azure AD Audit logs as seen below.
Searching for new API permissions being added to Azure AD applications
With the newly obtained privileges, the threat actors added new certificates which then can be used to issue access tokens to authenticate on behalf of the application. In this way, the threat actors used the application’s permissions to access many mailboxes in the target environment.
New certificate added to existing Azure AD application
This activity again gets logged in the Azure AD Audit Logs as seen below.
Searching for new certificate and secrets additions to Azure AD applications
The threat actors also used the Set-Mailbox cmdlet using the compromised administrator account to grant SMTP Send on behalf permissions to the Azure AD Connector account over a high-ranking employee’s mailbox. You can hunt for these types of activities in the Office 365 Unified Audit Logs (UAL).
Searching for Set-Mailbox invocation with GrantSendOnBehalf parameter
General attack path from Azure AD connector account
Even without Global Administrator (GA) role, Azure AD connector accounts can still provide an attack path to GA or other high-privileged roles, as noted by security researchers Andy Robbins and Fabian Bader.
Previously we discussed the Azure AD connector account having the Directory Synchronization Accounts role. Among the several permissions the role has, the two important ones relevant for this discussion are the microsoft.directory/applications/owners/update and microsoft.directory/servicePrincipals/owners/update permissions which allow the Azure AD connector account to manage all service principals in Azure AD.
Privilege escalation is possible if the tenant has any applications with any of the following permissions in the Azure AD environment.
|Allows the app to manage permission grants for application permissions to any API and application assignments for any app, on behalf of the signed-in user.
|Allows the app to read and manage the role-based access control (RBAC) settings for your company's directory, on behalf of the signed-in user. This includes instantiating directory roles and managing directory role membership, and reading directory role templates, directory roles, and memberships.
|Allows the app to create, read, update, and delete applications and service principals on behalf of the signed-in user.