What you need to know about the MERCURY cyberattack

The Microsoft Threat Intelligence team reported a successful cyberattack by a known nation-state actor called MERCURY. What happened?

The attackers used new methods to breach the target’s IT systems. Initial entry was through an unpatched vulnerable application and then a local user account was created to stay in the system. This could have been a targeted phishing email with a link to a malware site. Once they escalated their privilege to local administrator, they harvested credentials and moved to other environments on the network, harvesting additional credentials along the way. They patiently gathered information by “living off the land,” using common Windows tools. They were careful not to be detected, sometimes waiting for weeks before moving to the next phase of their attack.

The attackers gained access to Group Policy Objects (GPOs), editing them to interfere with security tools. This suggests that the target had weak security and monitoring controls on GPOs. With defenses weakened, they leveraged their GPO access to launch a ransomware attack that encrypted files and distributed ransom notes.

Before launching their wider attack, the invaders used compromised credentials of a privileged account obtained during their lateral movement. This gave them local administrator privileges on the server running the Azure Active Directory Connect (Azure AD Connect) agent. They used a readily available tool called AADInternals to extract the plaintext password of the privileged Azure AD Directory Sync account. This account had high-level Global Administrator access in Azure because it was originally set up for an older solution called DirSync deployed before Microsoft had developed more granular Azure roles.

The attackers then accessed another account with high-level access. Even though this account was configured for Multi-Factor Authentication, they were able to bypass it via an RDP session. They then used these accounts to perform considerable damage to the target’s Azure environment by deleting server farms, virtual machines, storage accounts, and virtual networks within a few hours.

The attackers also gave themselves full access to mailboxes through an existing OAuth application and performed numerous search activities. They granted themselves Send-As permissions to a senior executive’s mailbox and sent emails both internally and externally.

How can similar attacks be prevented?

In chatting with some of our customers, we discovered not all organizations fully appreciate the importance of protecting their Azure AD Connect service. This system should be protected as if it were a Domain Controller.

Installations of Azure AD Connect require at least two accounts with high privileges. The first is the one used by the Azure Active Directory connector. It is granted high-level privileges in your Azure Active Directory and can add/delete/modify Azure users and groups in Azure.

The second type of account runs the AD DS connector and has privileges on a par with a domain’s Administrator. If you have multiple forests, each has its own AD DS connectors and a privileged account in that forest. These accounts can add/delete/modify users and groups in the connected forest. When password hash sync is enabled, these accounts can read any user’s password hash in the domain.

When attackers use AADInternals or a similar tool, they can extract plaintext passwords. Once armed with the passwords, they can use the accounts to extract the password hashes and impersonate any account in your forest, including privileged administrators and senior executives. They can access files, applications, read and send emails acting as that user.

Recommendations to secure your Azure Active Directory Connect service

Ensure only highly trusted admins can log on the server; preferably users trusted to be Domain or Enterprise Admins. They should be familiar with the operation of Azure AD Connect. Once in the system, any local administrator can grant themselves access to Azure AD Connect service and potentially run AADInternals to retrieve plaintext passwords used by the service and its connected endpoints.
If Azure AD Connect is running in a virtual environment, the administrators of the virtual host must be trusted as well. They are an image copy away from elevating their privileges in the domain.
Treat the Azure AD Connect server as if it were a Domain Controller. Monitor all logons.
Ensure the computer has a unique local administrator password.
Ensure both Soft Matching and Hard Match Takeover are disabled in you Azure AD Connect configuration.

Recommendations to secure your on-premises environment

Randomize Local Administrator passwords with a tool like Local Administrator Password Solution (LAPS) to prevent lateral movement using local accounts with shared passwords.
Use a cloud-based identity security solution, such as Microsoft Defender for Identity or Azure AD Identity Protection, that leverages on-premises Active Directory signals get visibility into identity configurations and to identify and detect threats or compromised identities.
Enable Tamper Protection feature in Microsoft Defender for Endpoint.
For those utilizing Intune, 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. Enabling policies such as device compliance or trusted IP address requirements can limit exposure.
Enable Continuous Access Evaluation (CAE) to revoke access in real time when changes in user conditions trigger risks.
Search unified audit logs for the Send-As operation to identify and track emails sent on behalf of a user mailbox.
Deploy Azure AD Privileged Identity Management to manage privileged users in your Azure Active Directory and M365.

Another thing organizations can do to help prevent cyberattacks is to make sure they are fully leveraging the security capabilities included with their Microsoft 365 licenses. My Oxford Computer Group colleagues and I regularly see underutilized M365 licenses during our engagements and see money being spent on third-party tools when already licensed features of M365 could be doing the job.

Join us for a webinar on April 27th, Get the Most Out of Your Microsoft 365 Investment. OCG architect Frank Urena will discusses ways to strengthen security while streamlining IT operations and reducing costs.

Does your organization need assistance with planning and deploying Microsoft 365 security capabilities?

We will be happy to discuss the details with you. Contact Us.