How to patch Exchange Server for the Hafnium zero-day attack

Administrators who run on-premises Microsoft Exchange Server woke up on March 2 to a rude awakening: Some of them now have incidents to investigate. Starting on February 28 and possibly earlier, Exchange Servers were targeted in a widespread attack that relied on leveraging a zero-day server-side request forgery (SSRF) vulnerability. Microsoft has attributed the attack to Hafnium, a Chinese APT group.

While Microsoft originally indicated that this was a targeted attack against specific types of industries and businesses, I have reports from consultants for many small- to medium-sized businesses that have found evidence of exploitation.

Based on these reports, the attackers appear to have broadened their attack sequence once the zero-day became public. The White House confirmed this in its March 5 press briefing, and the US Cybersecurity and Infrastructure Security Agency (CISA) released an emergency directive with guidance and information about the attack on March 2.

Just because you aren’t normally a targeted business, take heed and investigate if you run an on-premises Exchange Server. If you have not patched, do so now. If you did patch, you may still need to take action to determine if you were impacted.

The attacks appear to have targeted more Exchange 2013 and 2016. This might be due to the number of servers that businesses have installed rather than targeting one version over another. Exchange 2019 is also at risk. Exchange 2010 does not have the same vulnerabilities as the other versions, but it is receiving patches as a defense-in-depth measure. Older versions of Exchange, while being out of support, are not vulnerable to this issue.

How to apply the emergency Exchange Server patches

If you haven’t yet patched for this, do so now and either turn off Exchange Server or block port 443 from that server until you are able to patch it. For those who cannot patch their systems, Microsoft has provided a mitigation process.

The best way to install patches on Exchange is from an elevated command prompt using the command line. Merely clicking on the patch to install it like a normal Windows update patch will not work. Make sure that you have elevated rights when updating, otherwise the patch won’t protect you. Furthermore, if you install the update and fail to elevate it during installation, it might leave services disabled and Outlook Web Access (OWA) non-functional. You may need to perform additional steps such as the following to get your server working again:

If OWA isn’t functional, run:

C:Program FilesMicrosoftExchange ServerV15BinUpdateCas.ps1 . This will fix Outlook Web Access

Follow these steps to correct the BinSearchFolders in the Internet Information Server (IIS) application settings to fix the Exchange Control Panel (ECP) after installing the update:

1. Open IIS Manager and expand to “Sites” and then to “Exchange Back End”.
2. Click on “ECP”. Open “Application Settings” in “/ECP Home”.
3. Check whether the value for “BinSearchFolders” is changed to not absolute paths. If so, change it to the correct path/drive to Exchange Server:

C:Program FilesMicrosoftExchange ServerV15bin;C:Program FilesMicrosoftExchange ServerV15binCmdletExtensionAgents;C:Program FilesMicrosoftExchange ServerV15ClientAccessOwabin

4. Run IISReset

How to tell if Exchange Server has been compromised

If you haven’t patched, start by taking your server offline to begin the investigation process to ensure that you haven’t been compromised. Next, run a script from Microsoft’s Exchange support that indicates whether you have suspicious files on your server. The script checks for signs of the intrusion. There are nuances though. IT administrators who have found signs of the attack on their systems say the evidence left behind ranges from signs of probes to system takeovers.

One administrator reported that when the PowerShell script indicated that it was “Checking for CVE-2021-26855 in the HttpProxy logs” in his environment, it alerted him to investigate the log file provided. That log file had references to “AnchorMailbox” and “GetObject”, so it appears to be merely a probe to see if the server is vulnerable for attack.

Susan Bradley

If, however, you review the folders in C:inetpubwwwrootaspnet_clientsystem_web and find eight-character aspx files, consider that you’ve been infiltrated by the attacker and that Exchange Server and potentially other servers in the network are suspect. Patching the machine in this state won’t remove the persistence that the attacker has established.

Examples of files in this location include:

C:inetpubwwwrootaspnet_clientsupp0rt.aspx

C:inetpubwwwrootaspnet_clientsystem_websKPt5ZmI.aspx

If you see these eight-character files in the root of the aspnet_client directory, it’s a sign that the attackers have potentially built persistence on that Exchange Server and other servers. If your firm has cyber insurance coverage, it’s unfortunately time to find out how good that insurance policy is.

The firm Huntress has been regularly updating a Reddit thread about its analysis of the situation. Huntress researchers have indicated that the attackers used ProcDump to capture credentials/hashes stored within LSASS process memory. You may need to determine how long the attackers were in your network and what actions they took while there.

If you believe that your system was impacted, at a minimum restore Exchange Server to a point in time before the incident. Review other servers in your network for evidence of lateral movement in the event logs. Review Active Directory (AD) for any accounts created in the last seven days or any accounts elevated to additional rights in your network in the last seven days. Next, change all AD passwords.

While you are reviewing passwords, consider your options for increasing password security and review the ability to use passwordless solutions such as Windows Hello or other two-factor options. You may need to review if you need to change to an Azure AD/hybrid solution to use modern authentication methods that will better protect and defend from password harvesting techniques.

CISA Alert (AA21-062A), Mitigate Microsoft Exchange Server Vulnerabilities, lists mitigation information and guidance to take a forensic image of the servers. It also has links to investigation tools. Microsoft has also updated its Safety Scanner to scan for traces of this attack. Another tool you can use to scan for issues is Nextron’s Thor lite scanner, and you can review IIS logs for traces of attacks. If your firm has been impacted by this attack, report it to the US Federal Bureau of Investigation (FBI).

Bottom line: Don’t assume this Exchange Server attack impacted the “big guys”. These attackers appear to have gone after anyone running an Exchange Server, large or small. If you run on-premises Exchange Server, take forensic action now to review if you’ve been impacted.