Exchange Server hack fallout: Problems, solutions, and mitigations

The Microsoft Exchange Server hacking incident has left IT departments scrambling to repair and mitigate further damage. This article is intended for IT pros whose job is to administer Exchange servers on-premises and in the cloud. I’ve written this article somewhat hastily because of the urgency of the situation, so what’s presented here should be considered “as is.” Be sure to confirm any recommendations made here with information from the official bulletins released by Microsoft Support and the Microsoft Security Response Center (MSRC). As more of this story develops, I may update this article by adding comments to it. Feel free, too, if you’re an Exchange admin to add any helpful suggestions you may have, or clarifications, or even corrections. Thanks.

Exchange Server hack: What happened?

An allegedly Chinese state-sponsored cyber-espionage unit exploited four vulnerabilities (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065) recently discovered in Microsoft Exchange Server. These flaws were apparently first reported to Microsoft in early January, and the company began developing patches for the vulnerabilities. Then in February, reports began to be raised about Exchange Servers getting hacked and the attackers installing backdoor web shells on them that gave them total remote control over the compromised servers, including access to all users’ mailboxes. Along with Exchange’s Unified Messaging, this can also mean access to their voicemail. Targeted exploitation quickly ramped up at the end of February into mass-scanning of Exchange Servers all around the world, creating a serious zero-day “in the wild” situation for businesses and organizations relying on Exchange. Microsoft released patches for these vulnerabilities on March 2, but by this time, tens of thousands of Exchange servers around the world had been compromised.

Resulting problems

If your Exchange Server is not directly exposed to the online web, then you probably don’t have much to worry about. That’s because the attack targeted vulnerabilities in the HTTP interface used by Exchange Web Services (EWS) and Outlook Web Access (OWA). So, if your server exposes only SMTP and IMAP but not HTTP/HTTPS, then it probably hasn’t been compromised. But it should still be patched as described below.

If your Exchange Server does publish HTTP/HTTPS online, then you should probably consider it compromised, even if you applied the March 2 patches to it. How can you identify if it’s been compromised? This is difficult. Microsoft did release a script and some steps you can follow to query your Exchange log files for evidence of compromise, but the ingenuity of the attack may make this not 100 percent effective. For example, reports indicate that some of the web shells dropped by the attack have unpredictable random names making them difficult to detect. And because the vulnerability is in a proxy layer of the product, various malware filenames, including malformed ones, can probably be used for launching the attack. MSRC also has released a PowerShell script on GitHub that can help with malicious file detection for servers running Exchange 2013, 2016, or 2019.

If your Exchange Server has been compromised and your Active Directory (AD) environment is not properly secured against golden ticket attacks, then your entire AD forest may be compromised — and we don’t need to explain what that can mean. This article from FRSecure does a good job explaining what golden ticket attacks are, how to detect and remediate when they’ve occurred, and how to protect your AD infrastructure from them.

Recommended solutions

Begin by using the previously described scripts to identify whether your Exchange Server has already been compromised. If it has, the best course is probably to rebuild it and to further investigate whether the compromise has extended to your AD infrastructure. If your server doesn’t appear to have been compromised and is running Exchange 2013, 2016, or 2019, you should immediately apply the updates listed in this post on the Exchange Team Blog. Note that applying these patches to a compromised Exchange Server will not evict any adversary who has established control over the server.

If you’re running an older unsupported Cumulative Update (CU) of Exchange Server, the Exchange Team has some recommendations of steps you can perform to provide some temporary protection until you can update your server to the latest supported CU.

If for some reason you are not able to upgrade Exchange to the latest supported CU, then perform these mitigation steps that the MSRC recommends under such circumstances. Doing this can reduce the risk of compromise until you are able to patch Exchange properly. The scripts for performing these mitigations are also available on GitHub.

Full guidance from Microsoft about the security updates it released for dealing with the Exchange Server hack and vulnerabilities responsible can be found in this post on the MSRC Blog. Be sure to review this page frequently, as Microsoft will probably be updating it with further recommendations as their research into this exploit continues.

Featured image: Shutterstock