Most organizations have infrastructures that span both on-premise and the cloud. To manage identities across both domains, organizations implement hybrid identities to create a common user identity for authentication and authorization of all resources, regardless of location. This means there is added work for enterprise defenders to properly defend their hybrid environment.

Take a recent incident as an example. On April 7, 2023, Microsoft Threat Intelligence reported a destructive operation on a hybrid environment by Mango Sandstorm (formerly MERCURY)[G0069]— a nation-state actor linked to Iran’s Ministry of Intelligence and Security. The actor’s ultimate goal was destruction and disruption while attempting to masquerade as a generic ransomware attack. Microsoft has assessed that Mango Sandstorm presumably worked in partnership with Storm-1084 (formerly DEV-1084) who carried out the destructive actions after Mango Sandstorm had successfully breached the target network.

Bhabesh Rai
Bhabesh Rai

Security Research

Share This Story

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.

Global Administrators can elevate their access to obtain the User Access Administrator role, which grants access to all Azure resources within the tenant.

Analysts can use the query below to hunt for Global Administrator role activation in PIM.

Searching for successful PIM activation of Global Administrator role

The query above uses the recently released JSON Parser plugin.

However, currently, there is no native logging that records the toggling of the elevated access switch by Global Admins. The only known way is if you have Microsoft Defender for Cloud App (MCAS) license and connected your Azure account to it.

ElevateAccess activity log in Defender for Cloud Apps

If you wish to detect this with Logpoint Converged SIEM, stream Advanced Hunting events (CloudAppEvents to be specific) to Event Hubs, and use the Event Hubs collector to collect them.

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.

Permission Description
AppRoleAssignment.ReadWrite.All 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.
RoleManagement.ReadWrite.Directory 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.
Application.ReadWrite.All 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.

Streamlined remediation using Logpoint SOAR

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.