Microsoft Reports New Attack Using Azure AD Connect

Important to Check Azure AD Tenants to Remove Possibility of Compromise by MERCURY Attack

If you celebrate Easter, you might have already been planning or executing your Easter egg hunt when the Microsoft Threat Intelligence team released their latest writeup on April 7, 2023. If you missed it, a quick summary: a “nation-state actor linked to the Iranian government,” which Microsoft has code-named MERCURY, penetrated a network and then handed off-network access to another group, code-named DEV-1084. The DEV-1084 group then used a variety of techniques to destroy data, both on-premises but also in Azure. The threat intelligence write-up goes into detail about how Microsoft linked the two, how you could use Microsoft security tools to look for similar attacks, and so on. It’s worth reading when you have time to dig into the subject matter, but it’s more important to understand where your own hybrid environment might be vulnerable so you can quickly fix it.

What is Lateral Movement?

You’ll often hear two terms used in discussions of attacks like this: escalation of privilege (which is pretty easy to understand) and lateral movement. This latter term sounds fancy, but it’s simple: it just means that an attacker has compromised one device or system in a network and uses that compromise as a springboard or pivot to get into other devices or systems. This movement may be immediate, but it is often delayed (as it was in this case)—a smart attacker will break in, establish persistence, and then wait a little while, studying the target network and avoiding any overt action that might alert defenders to their presence.

The attacks here appear to have started with exploits of the familiar log4j vulnerability, followed by establishing persistence, and then a steady but slow spread of lateral movement throughout the network. Once they were solidly established in the network, they followed two related plans of attack: one against on-premises resources and one against Azure.

The On-Premises Attacks

The attacker used group policy objects to “[interfere] with security tools,” and then to register a scheduled task and distribute ransomware via the NETLOGON shares on Active Directory domain controllers.

Although Microsoft didn’t say so, it’s hard to escape the conclusion that there was no anti-malware scanning deployed inside the network, and that controls on GPOs (including auditing and monitoring) were relatively weak. The first call to action from this attack that I’d recommend would thus be ensuring that you have adequate protection for your domain controllers and GPOs. This might be as simple as deploying Microsoft Defender for Endpoint on your DCs, but of course it could be significantly more complex (and expensive) depending on your network topology.

MERCURY Moves from On-Premises to Hybrid Attacks

It’s painful to say it, but there’s nothing especially unusual about a ransomware attack targeting on-premises systems. The novel part of this particular attack began when the threat actors began to nose around the hybrid portions of the target network.

First, a brief refresher is in order. When you install Azure AD Connect, it creates two privileged accounts: one for connecting to the cloud (the “Azure AD connector account”) and one for connecting to the on-prem AD (the “AD DS connector account”). Both accounts are created with a long, complex password, which the administrator doesn’t have direct access to. However, an account that has local admin privileges on the machine running Azure AD Connect will have access to the in-memory credentials for both of these accounts.

Microsoft says that the threat actors used the AADInternals tool to steal the credentials for the Azure AD Connector account. They verified these credentials by logging directly into the Azure AD connector account in the cloud. Microsoft says that they “observed authentication from a known attacker IP address” on this account, meaning that the attacker was able to verify that the credentials worked without leaving any of the telltale footprints of a password-spray attack.

That’s not the bad part, though. As you may remember, the DirSync tool, the predecessor of Azure AD Connect, required that its service account have Global Administrator rights. If you installed DirSync and then updated to Azure AD Connect, that service account will still have the same rights. In this case, the attacker compromised an account that gave them an unlimited run of Azure AD.

As a bonus, the attacker also compromised another GA account, this time by using RDP into a device where that account was logged in. This allowed them to evade MFA, since the user had already answered an MFA challenge for the device. This is roughly equivalent to walking over to an unlocked workstation and using its logged-in account.

Using both of these accounts, the attackers then deleted data from the target’s Azure network, including virtual machines, storage accounts, virtual networks, and other infrastructure objects. As a final insult, they then used Exchange Web Services impersonation to register an application that allowed them to read everyone’s mail, some of which was undoubtedly exfiltrated.

What You Should Do to Deflect a MERCURY Attack

There are a few practical things you can do immediately to protect yourself against similar attacks:

• Defender’s tamper protection features will help catch and block changes to your on-prem security environment. If you’re using Intune, you can also set the DisableLocalAdminMerge flag to block GPO changes from being applied.
• Immediately audit which accounts have Global admin permission in your Microsoft 365 estate. Removing GA rights from the Azure AD connector account wouldn’t have stopped this attack because the attacker also compromised a separate privileged account, but it would have made things more difficult.
• Ensure that you apply MFA to all privileged accounts.
• Exploit continuous access evaluation (CAE). This is a general good practice; it’s not clear that it would have prevented any part of the attack chain in this case, but it is absolutely useful because it immediately blocks access for accounts once you disable them, as you might while threat hunting or remediation activities are underway.
• Start monitoring for unusual activity on the Azure AD connector and AD DS connector accounts. In particular, you probably should track whether there are login attempts from IP address ranges that aren’t associated with your network (being mindful of the fact that Microsoft IP ranges may be in use here too).

One thing I didn’t see in Microsoft report is a discussion of whether the Defender for Identity product could reasonably have been expected to detect (and, hopefully, interfere with) this attack. Their report does cover some signals that other Defender products might have produced (such as “unusual activities by Azure AD connect sync account” or “multiple delete VM activities”). I think of these signals like the smoke alarm in your kitchen: it’s nice to have the notification as early as possible, but it’s no substitute for fire suppression.

When a nation-state decides to attack you, it’s certainly difficult to defend yourself. But the truth is that the vast majority of us face less serious threats. What’s also true is that today’s sophisticated nation-state-level attack is tomorrow’s run-of-the-mill script-kiddie attack—so it would be a good idea for you to quickly apply appropriate hardening against the measures these attackers used.