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.
Here are the privilege escalation scenarios:
Attack path to Global Admin
Attackers can exploit an application with AppRoleAssignment.ReadWrite.All permission to grant itself the RoleManagement.ReadWrite.Directory permission, allowing it to promote itself to Global Administrator (GA).
Attackers can escalate privileges by compromising an application with Application.ReadWrite.All permission, which allows them to add or update existing application secrets. They can then scan for highly privileged applications in the tenant, and add another secret to the privileged application to effectively use it and escalate their privileges.
Recommendations to protect your hybrid environments
We recommend the following steps for organizations to protect their hybrid environments:
Use the latest version of Azure AD Connect agent.
Consider the systems where the Azure AD Connect agent is installed to be Tier-0 (Control Plane) asset and restrict administrative access to these servers to only domain administrators or other tightly controlled security groups. Privileged Access Workstations (PAWs) should be used to manage these servers.
Do not assign Global Administrator or other high-privileged roles to the Connector accounts.
Limit the number of Global Administrators to less than 5.
Use cloud-only accounts to administer Azure AD and avoid using on-premises synced accounts for Azure AD role assignments.
Not all on-premises accounts need to be synced with Azure AD. Identify and sync only the required on-premises identities based on business needs.
Follow Microsoft’s best practices to harden Azure AD Connect deployments.
Turn on multi-factor authentication (MFA) for all accounts. At a minimum, require MFA for privileged AD and Azure AD users if not possible for all accounts.
Use Privileged Identity Management (PIM) to grant just-in-time access and monitor PIM activation of highly-privileged roles such as Global Administrators.
Enable unified audit logging (UAL) in the Security and Compliance Center. Enabling UAL allows administrators the ability to investigate and search for actions within Office 365.
Disable legacy protocol authentication when appropriate to reduce the organization’s attack surface. There are several legacy protocols associated with Exchange Online that do not support MFA features such as POP3 and IMAP. If possible, use Azure AD Conditional Access policies to limit the number of users who can use legacy protocol authentication methods.
As part of Logpoint’s Converged SIEM, customers can use SOAR to streamline their remediation process with its out-of-the-box playbooks.
Examples of such playbooks are:
AAD Get Risky User Status
AAD Reset User Credentials
AAD Revoke Sign-in Sessions
AAD Disable User
Block Indicators - Generic
Logpoint SOAR playbook to fetch user risk status
Result of AAD Get Risky User Status playbook
Our recently launched native endpoint agent, AgentX, can help customers enhance their EDR capabilities, detect and respond to security incidents, and gain access to additional playbooks such as:
Logpoint AgentX Isolate-Unisolate Host
Logpoint Agentx Retrieve File Hash
Osquery Get Logged In Users
Osquery Check Process Execution State
Osquery Get File Hash
AgentX playbook to isolate-unisolate endpoints
Prevention and Detection go hand-in-hand
In today's hybrid IT environments, it's crucial for enterprise defenders to properly defend against attacks that span across both on-premise and cloud domains. The recent attack by Mango Sandstorm is a stark reminder of the need for robust defenses to prevent lateral movement from on-premise to cloud and vice-versa.
We remind enterprise defenders not to overlook prevention measures in reducing their organization's attack surface. Prevention remains a critical component of cybersecurity, despite the current focus on detection. While detecting and responding to threats is important, the best way to protect your organization is by preventing breaches from occurring in the first place. By prioritizing prevention and implementing proper defense in depth, organizations can protect themselves against a constantly evolving threat landscape.
There are common attack paths that adversaries can take to compromise the cloud environment, but with the right tools and strategies in place, such as Logpoint, defenders can detect and prevent such attacks.