MERCURY and DEV-1084: Destructive attack on hybrid environment

Main / MERCURY and DEV-1084: Destructive attack on hybrid environment

Discription

> **April 2023 update** â Microsoft Threat Intelligence has shifted to a new threat actor naming taxonomy aligned around the theme of weather. **MERCURY** is now tracked as **Mango Sandstorm** and **DEV-1084** is now tracked as **Storm-1084**.
>
> To learn more about the new taxonomy represents the origin, unique traits, and impact of threat actors, to get complete mapping of threat actor names, read this blog: [**Microsoft shifts to a new threat actor naming taxonomy**]().

Microsoft Threat Intelligence has detected destructive operations enabled by [MERCURY](), a nation-state actor linked to the Iranian government, that attacked both on-premises and cloud environments. While the threat actors attempted to masquerade the activity as a standard ransomware campaign, the unrecoverable actions show destruction and disruption were the ultimate goals of the operation.

Previous MERCURY attacks have been observed targeting on-premises environments, however, the impact in this case notably also included destruction of cloud resources. Microsoft assesses that MERCURY likely worked in partnership with another actor that Microsoft tracks as DEV-1084, who carried out the destructive actions after MERCURYâs successful operations had gained access to the target environment.

MERCURY likely exploited known vulnerabilities in unpatched applications for initial access before handing off access to DEV-1084 to perform extensive reconnaissance and discovery, establish persistence, and move laterally throughout the network, oftentimes waiting weeks and sometimes months before progressing to the next stage. DEV-1084 was then later observed leveraging highly privileged compromised credentials to perform en masse destruction of resources, including server farms, virtual machines, storage accounts, and virtual networks, and send emails to internal and external recipients.

In this blog post, we detail our analysis of the observed actor activity and related tools. We also share information to the community and industry partners on ways to detect these attacks, including detection details of MERCURY and DEV-1084âs tools in Microsoft 365 Defender, Microsoft Defender for Identity, Microsoft Defender for Cloud Applications, Microsoft Defender Antivirus, and Microsoft Defender for Endpoint. As with any observed nation-state actor activity, Microsoft has directly notified targeted or compromised customers, providing them with important information needed to secure their environments.

Microsoft uses DEV-#### designations as a temporary name given to an unknown, emerging, or a developing cluster of threat activity, allowing Microsoft to track it as a unique set of information until we reach high confidence about the origin or identity of the actor behind the activity.

## Who is DEV-1084? __

Microsoft tracks the destructive actions documented in this blog post as DEV-1084. DEV-1084 likely worked in partnership with MERCURYâan Iran-based actor that the US Cyber Command has publicly linked to [Iranâs Ministry of Intelligence and Security (MOIS)](). DEV-1084 publicly adopted the DarkBit persona and presented itself as a criminal actor interested in extortion, likely as an attempt to obfuscate Iranâs link to and strategic motivation for the attack.

The link between the DEV-1084 cluster and MERCURY was established based on the following evidence:

* DEV-1084 operators were observed sending threatening emails from 146.70.106[.]89, an IP address previously linked to MERCURY.
* DEV-1084 used MULLVAD VPN, the same VPN provider historically used by MERCURY.
* DEV-1084 used Rport and a customized version of Ligolo. MERCURY has also been observed using Rport and a similar version of Ligolo in previous attacks.
* DEV-1084 used the _vatacloud[.]com_ domain for command and control (C2) during this incident. Microsoft assesses with high-confidence that the _vatacloud[.]com_ domain is controlled by MERCURY operators.

Microsoft assesses that MERCURY gains access to the targets through remote exploitation of an unpatched internet-facing device. MERCURY then handed off access to DEV-1084. It is not currently clear if DEV-1084 operates independently of MERCURY and works with other Iranian actors or if DEV-1084 is an âeffects basedâ sub-team of MERCURY that only surfaces when MERCURY operators are instructed to carry out a destructive attack.

## Early activities, related attacker tools and techniques

Microsoft assesses with moderate confidence that the threat actors attempted several times and succeeded to perform initial intrusion leveraging exposed vulnerable applications, for example, [continuing to exploit Log4j 2 vulnerabilities in unpatched systems]() in July 2022.

After gaining access, the threat actors deploy several tools and leverage techniques to maintain persistence, which provide effective and continued access to compromised devices, such as the following:

* Installing web shells
* Adding a local user account and elevating privileges to local administrator
* Installing legitimate remote access tools, such as [RPort](), Ligolo and [eHorus]()
* Installing a customized PowerShell script backdoor
* Stealing credentials

Once the persistence is established, the threat actors perform extensive discovery leveraging common native Windows tools and commands such as _netstat_ and _nltest_. Such reconnaissance activities were seen leveraged throughout the attack chain.

The threat actors consistently perform extensive lateral movement actions using the acquired credentials within a targeted environment. These actions mainly involved:

* Remote scheduled tasks to launch their customized PowerShell backdoor
* Windows Management Instrumentation (WMI) to launch commands on devices
* Remote services to run encoded PowerShell commands

After infecting the new devices, the threat actors often installed the same persistence mechanisms as described above. Interestingly, after each main attack step, the actors did not always immediately continue their operations but would wait weeks and sometimes months before moving to the next step.

For execution and communication, the threat actors leverage several C2 servers and sometimes deploy tunnelling tools, such as [Ligolo]() and [OpenSSH](), commonly leveraged to stay under the radar of security teams and solutions.

## On-premises destructive impact

In observed activity, the threat actors leveraged highly privileged credentials and access to domain controllers on on-premises destructive operations to prepare for large-scale encryption of targeted devices.

To do so, they first interfered with security tools using Group Policy Objects (GPO). With defenses impaired, the threat actors proceeded to stage the ransomware payload in the NETLOGON shares on several domain controllers.

GPO was leveraged again to register a scheduled task used to launch the ransomware payload. Finally, the ransomware payload encrypted files found on the file system of the targeted devices by changing the file name extension to _DARKBIT_ and dropped ransom notes.

![Attack flow of the threat actor through initial access, execution, discovery, persistence, credential access, lateral movement, execution, impact, and communications stages.](https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2023/04/Figure-1.-Attack-diagram-1-1024×604.png)Figure 1. On-premises attack flow

## Moving from on-premises to cloud

To move from on-premises to the cloud, the threat actors had to first compromise two privileged accounts and leverage them to manipulate the Azure Active Directory (Azure AD) Connect agent. Two weeks before the ransomware deployment, the threat actors first used a compromised, highly privileged account to access the device where the Azure Active Directory (Azure AD) Connect agent is installed. We assess with high confidence that the threat actors then used the AADInternals tool to extract the plaintext credentials of a privileged Azure AD account. The threat actors then used these credentials to pivot from the on-premises environment to the Azure AD environment.

[Azure AD Connect]() is an on-premises application for managing hybrid identities through features like [password hash synchronization](), [pass-through authentication](), [objects synchronization](), and others. As part of the express settings installation process, multiple accounts are created both in the on-premises (Windows Server Active Directory) and cloud (Azure AD) environments. The first account is the AD DS Connector Account. The account name is prefixed with _MSOL__ and it is created with a long complex password.

![AD DS Connector account example](https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2023/04/Figure-2-1024×43.png)Figure 2. Example of AD DS Connector account

This accountâs permissions are set based on features enabled during the serviceâs installation, but in most common scenarios, the account has permissions to replicate directory changes, modify passwords, modify users, modify groups, and so on (see all the permissions [here]()). In addition, during installation, an Azure AD account called the Azure AD Connector Account is also created. This account is used by the synchronization service to manage Azure AD objects. The account is created with a long complex password as well, and by default (if using the express settings) prefixed with _Sync_[ServerName]_. This user is assigned with the Directory Synchronization Accounts role (see detailed permissions of this role [here]()). In older versions, this account might be assigned with the Global Administrator role.

![Azure AD Connector account example](https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2023/04/Figure-3-1024×57.png)Figure 3. Example of an Azure AD Connector account

There are other entities detailed [here]() that are created but are less relevant to this topic.

### Extracting credentials

Two weeks before the ransomware deployment, the threat actors were observed using compromised credentials to access the Azure AD Connect device. Next, they set up an SSH tunnel to an attacker-controlled device. On a separate attacker-controlled compromised device, evidence indicates cloning of the AADInternals tool. One of the functions available in this toolâs library is [_Get-AADIntSyncCredentials_](), which allows any local administrator on a device where Azure AD Connect is installed to extract the plaintext credentials of both the Azure AD Connector account and the AD DS Connector account.

Shortly before the ransomware deployment, we observed authentication from a known attacker IP address into the Azure AD Connector cloud account. Investigating this sign-in showed that the threat actors were able to access the account on the first attempt without any guessing or modification of the password, indicating that the actors possessed the password for this account. The Azure AD Connector account is configured with single-factor authentication, making it easier for the attacker to gain entry and elevate privileges.

## Cloud destructive impact

On the day of the ransomware attack, the threat actors executed multiple actions in the cloud using two privileged accounts. The first account was the compromised Azure AD Connector account, which had Global Administrator permissions as it was set up for an old solution (DirSync). For the second account, which also had Global Administrator permissions, the threat actors leveraged RDP for access into the account. Even though this account had MFA in place, the threat actors accessed it through RDP, which is an open session that evades MFA blocking their activities.

![Diagram depicting how an attacker moves through the targeted devices, leverages an attacker-controlled device to extract passwords, access the admin and Azure AD Connector accounts to impersonate emails, dump emails using Exchange Web Server API, and mass delete Azure resources.](https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2023/04/Figure-4.-Cloud-pivot-diagram-1024×310.png)Figure 4. Pivoting to the cloud

### Mass Azure resource deletion

On the same day, a successful sign-in to the Microsoft Azure environment was observed. The threat actors claimed the Global Administrator permission through [Azure Privileged Identity Management (PIM)]() and [elevated]() access to get permissions to the targetâs management groups and Azure subscriptions. The Azure AD Connector account and the compromised administrator account were then used to perform significant destruction of the Azure environmentâdeleting within a few hours server farms, virtual machines, storage accounts, and virtual networks. We assess that the attackerâs goal was to cause data loss and a denial of service (DoS) of the targetâs services.

### Exchange Web Server API abuse

The actors went on to provide an existing legitimate OAuth application with both the _full_access_as_app_ permission and administrator consent, which granted the threat actors full access to mailboxes through Exchange Web Services.

![Screenshot of full_access_as_app permission being added to the legitimate OAuth app.](https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2023/04/Figure-5-1024×595.png)Figure 5. Adding access permission to the existing application

With the obtained cloud administrator privileges, the threat actors updated the OAuth application with certificates to conduct malicious activities. These newly added credentials could then be used to issue access tokens and authenticate on behalf of the application to access cloud resources.

We then observed the threat actors using this applicationâs permissions to perform [_GetItem_]() operations over many mailboxes in the target environment. They also performed thousands of search activities, which we suspect were attempts to dump mailboxes and/or search for sensitive data in them.

### Email impersonation

The threat actors used the compromised administrator account to grant SMTP _Send on behalf_ permissions to the Azure AD Connector account over a high-ranking employeeâs mailbox, using the _Set-Mailbox_ PowerShell cmdlet.

![Access granted to send emails on behalf of the target’s account](https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2023/04/Figure-7-1024×646.png)Figure 6. Threat actors granting access to send emails on behalf of the targetâs account

Emails were then created and sent both internally and externally.

![Email successfully sent through the targeted account](https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2023/04/Figure-8-2-1024×456.png)Figure 7. Threat actors successfully sent email through the targeted account

The timeline below summarizes the sequence of events:

![Attack flow timeline of the threat actors’ actions in the cloud environment](https://www.microsoft.com/en-us/security/blog/wp-content/uploads/2023/04/Figure-9.-Cloud-timeline-1-1024×169.png)Figure 8. Cloud attack flow timeline

## Mitigations for destructive attacks

The techniques used by the actors and described in this blog can be mitigated by adopting the following security measures:

**Recommendations to secure your on-prem environment**

* Refer to Microsoftâs blog [Ransomware as a service: Understanding the cybercrime gig economy and how to protect yourself]() for recommendations on building strong credential hygiene and other robust measures to defend against ransomware and human operated attacks.
* [Enable tamper protection]() â Tamper protection is a feature in Microsoft Defender for Endpoint that prevents antivirus tampering and misconfiguration by malicious apps and actors. Customers running Intune can [enable DisableLocalAdminMerge to prevent modification of antivirus exclusions via GPO]().

**Recommendations to secure your Azure AD environment**

* [Enable Conditional Access policies]() â Conditional Access policies are evaluated and enforced every time the user attempts to sign in. Organizations can protect themselves from attacks that leverage stolen credentials by enabling policies such as device compliance or trusted IP address requirements.
* [Enable continuous access evaluation]() â Continuous access evaluation (CAE) revokes access in real time when changes in user conditions trigger risks, such as when a user is terminated or moves to an untrusted location.
* Search unified audit logs for the _SendAs_ operation to identify and track emails sent on behalf of a user mailbox.
* Further steps and recommendation to manage, design, and secure your Azure AD environment can be found by referring to [Azure Identity Management and access control security best practices]().

## Detections

### Microsoft 365 Defender

The following alerts in [Microsoft 365 Defender]() can be used to detect suspicious operations in Azure related to the attacker activities described in this blog, including destructive activity:

* Access elevation by risky user
* Suspicious Azure resource deletions
* Suspicious Addition of an Exchange related App Role

In addition, the following alert can help detect compromised Azure AD Connect accounts:

* Unusual activities by Azure AD Connect sync account

### Microsoft Defender for Cloud Apps

For Microsoft Defender for Cloud Apps with [Azure Connector]() enabled, the following alerts can be used to detect destructive operations in Azure:

* Multiple storage deletion activities
* Multiple delete VM activities

### Azure AD Identity Protection

Monitor medium and high severity alerts for highly privileged accounts as they can indicate malicious activity. For example:

* Unfamiliar sign-in properties

Find details of Azure AD Identity Protection alerts [here]().

### Microsoft Defender for Identity

The following Microsoft Defender for Identity alerts can indicate associated threat activity:

* Suspicious additions to sensitive groups

For relevant accounts with Honeytoken configured, the following alert can indicate malicious activity:

* Honeytoken activity

### Microsoft Defender Antivirus

Microsoft Defender Antivirus detects attempted exploitation and post-exploitation activity and payloads. Turn on cloud-delivered protection to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block most new and unknown threats. Refer to the [list of detection names]() related to exploitation of Log4j 2 vulnerabilities. Detections for the IOCs listed above are listed below:

* Backdoor:PHP/Remoteshell.V
* HackTool:Win32/LSADump
* VirTool:Win32/RemoteExec
* Trojan:PowerShell/Downloader.SB
* Trojan:Win32/Nibtse.G!tsk
* Backdoor:ASP/Shellman.SA
* Ransom:Win64/DarkBit
* VirTool:Win32/AtExecCommand

### Microsoft Defender for Endpoint

Microsoft Defender for Endpoint alerts with the following titles can indicate possible presence of the indicators of compromise listed below.

* Mercury actor activity detected
* Ransomware-linked emerging threat actor DEV-1084 detected

**Reducing the attack surface**

Microsoft Defender for Endpoint customers can turn on the following attack surface reduction rule to block or audit some observed activity associated with this threat:

* Block executable files from running unless they meet a prevalence, age, or trusted list criterion.
* Implement [controlled folder access]() and add folders to the protected folders list to help prevent files from being altered or encrypted by ransomware. Set controlled folder access to [Enabled]().

**Detecting Log4j 2 exploitation**

Alerts that indicate threat activity related to the exploitation of the Log4j 2 exploitation should be immediately investigated and remediated. Refer to our Log4j related blogs to learn about this vulnerability and for a list of [Microsoft Defender for Endpoint alerts]() that can indicate exploitation and exploitation attempts.

**Detecting post-exploitation activity**

Alerts with the following titles may indicate post-exploitation threat activity related to MERCURY activity described in this blog and should be immediately investigated and remediated. These alerts are supported on both Windows and Linux platforms:

Any alert title related to web shell threats, for example:

* ‘WebShell’ backdoor was prevented on an IIS Web server

Any alert title that mentions the DarkBit ransomware threat or DEV-1084, for example:

* ‘DarkBitâ ransomware was blocked
* ‘DarkBitâ ransomware was detected
* ‘DarkBitâ ransomware was prevented
* Ransomware-linked emerging threat actor DEV-1084 detected

Any alert title that mentions suspicious scheduled task creation or execution, for example:

* Suspicious scheduled task

Any alert title that mentions suspected tunneling activity, for example:

* Suspicious SSH tunneling activity

Any alert title that mentions suspected tampering activity, for example:

* Suspicious Microsoft Defender Antivirus exclusion
* Microsoft Defender Antivirus tampering

Any alert title that mentions PowerShell, for example:

* Suspicious process executed PowerShell command
* A malicious PowerShell Cmdlet was invoked on the machine
* Suspicious PowerShell command line
* Suspicious PowerShell download or encoded command execution
* Suspicious remote PowerShell execution

Any alert title related to suspicious remote activity, for example:

* Suspicious RDP session
* An active ‘RemoteExec’ malware was blocked
* Suspicious service registration

Any alert related to persistence:

* Anomaly detected in ASEP registry
* User account created under suspicious circumstances

Any alert title that mentions credential dumping activity or tools, for example:

* Malicious credential theft tool execution detected
* Credential dumping activity observed
* Mimikatz credential theft tool
* ‘DumpLsass’ malware was blocked on a Microsoft SQL server

### Microsoft Defender Vulnerability Management

In addition to the mitigations above being presented and managed through Microsoft Defender Vulnerability Management, Microsoft 365 Defender customers can use threat and vulnerability management to identify and remediate devices that are vulnerable to Log4j 2 exploitation. More comprehensive guidance on this capability can be found on this blog: [Guidance for preventing, detecting, and hunting for exploitation of the Log4j 2 vulnerability]().

## Advanced hunting queries __

### Microsoft 365 Defender

To locate related activity, Microsoft 365 Defender customers can run the following advanced hunting queries:

// Advanced Hunting Query to surface potential Mercury PowerShell script backdoor installation

DeviceFileEvents
| where InitiatingProcessFileName =~ “powershell.exe”
| where FolderPath in~ (@”c:programdatadb.ps1″, @”c:programdatadb.sqlite”)
| summarize min(Timestamp), max(Timestamp) by DeviceId, SHA256, InitiatingProcessParentFileName

DeviceProcessEvents
| where InitiatingProcessFileName =~ “powershell.exe”
| where InitiatingProcessCommandLine has_cs “-EP BYPASS -NoP -W h”
| summarize makeset(ProcessCommandLine), min(Timestamp), max(Timestamp) by DeviceId

// Advanced Hunting Query to surface potential Mercury PowerShell script backdoor initiating commands

DeviceProcessEvents
| where InitiatingProcessFileName =~ “powershell.exe”
| where InitiatingProcessCommandLine contains_cs @”c:programdatadb.ps1″
| summarize makeset(ProcessCommandLine), min(Timestamp), max(Timestamp) by DeviceId

//Advanced Hunting Query for Azure resource deletion activity

let PrivEscalation = CloudAppEvents
| where Application == “Microsoft Azure”
| where ActionType == “ElevateAccess Microsoft.Authorization”
| where ActivityObjects has “Azure Subscription” and ActivityObjects has “Azure Resource Group”
| extend PrivEscalationTime = Timestamp
| project AccountObjectId, PrivEscalationTime ,ActionType;
CloudAppEvents
| join kind = inner PrivEscalation on AccountObjectId
| extend DeletionTime = Timestamp
| where (DeletionTime – PrivEscalationTime) )
* [Potential SSH Tunnel to AAD Connect Host]()
* [Suspicious Sign In by AAD Connect Sync Account]()
* [Malicious web application requests linked with Microsoft Defender for Endpoint]()
* [Web Shell Activity]()
* [Tracking Privileged Account Rare Activity]()
* [Mass Cloud resource deletions Time Series Anomaly]()
* [Consent to Application discovery]()
* [OAuth Application Required Resource Access Update]()
* [Rare application consent]()
* [Credential added after admin consented to Application]()[New access credential added to Application or Service Principal]()

Microsoft Sentinel customers can use the TI Mapping analytic (a series of analytics all prefixed with âTI mapâ) to automatically match the indicators mentioned in this blog post with data in their workspace. If the TI Map analytics are not currently deployed, customers can install the Threat Intelligence solution from the Microsoft Sentinel Content Hub to have the analytics rule deployed in their Sentinel workspace. More details on the Content Hub can be found here:

## Indicators of compromise (IOCs)

The below list provides IOCs observed during our investigation. We encourage our customers to investigate these indicators in their environments and implement detections and protections to identify past related activity and prevent future attacks against their systems.

**NOTE:** These indicators should not be considered exhaustive for this observed activity.

### Microsoft Defender Threat Intelligence

Community members and customers can find summary information and all IOCs from this blog post in the linked [Microsoft Defender Threat Intelligence article]().

## References

*
*
*
*
*

The post [MERCURY and DEV-1084: Destructive attack on hybrid environment]() appeared first on [Microsoft Security Blog]().Read More

References

Back to Main

Subscribe for the latest news: