Inside the APT Attack on Microsoft Exchange: Techniques, PoC & Defense Strategies

On March 2^nd Microsoft announced that a Chinese Nation-State actor they called HAFNIUM had been utilizing four zero-day vulnerabilities on-premises version of Microsoft Exchange. Microsoft and other researchers say that the Chinese government had successfully penetrated and expanded into around 60,000 companies, globally. Microsoft released a patch on the same day of the announcement. Being well thought out and planned, the attack established backdoors that remain even if the breach is remediated. Furthermore, beyond the direct attack, researchers are already finding that other criminal groups have taken advantage of the now known vulnerabilities. They have found as of last Friday, March 5^th multiple web shells per target due to “automated deployment or multiple uncoordinated actors.”

Cymulate Labs has since released two Immediate threat attack simulations for customers to challenge and assess their defenses in addition to a full PoC of the Chinese attack in the Purple Team module as described below.

Full PoC and The Research Behind The Attack

A simulation of the APT attack is now available for Cymulate customers. Read on to understand how Cymulate labs reverse engineered the attack so that they can validate their protections

Research Tools

Socat proxy:

In order to better understand the inner communication of the exchange server to its backend services, we employed the socat proxy in order to log all of the requests the server was making to the local 444 port. The first thing we had to do is to change the IIS binding of the backend services from port 444 to a local port 1234:

Then, we export the Exchange Server certificate:

If you have a problem exporting the original certificate you can create one of our own and export it to a pfx file for use in the simulation.

After getting the pfx file, we create the relevant key and certificate:

openssl pkcs12 -in <path_to_pfx> -nokeys -out exchange.pem

openssl pkcs12 -in 'CERT_SYSTEM_STORE_LOCAL_MACHINE_My_1_Microsoft Exchange.pfx' -nocerts -out exchange-key.pem

The resulting files can then be used in socat:

socat -v openssl-listen:444,cert=exchange.pem,key=exchange-key.pem,verify=0,reuseaddr,fork openssl-connect:127.0.0.1:1234,verify=0 1> <socat_logfile> 2>&1

Now, every connection made to a local backend service is logged to a log file of your choosing Diffing:
One extremely effective way to finding the relevant code responsible for the vulnerability, is diffing the decompiled source code from both the dlls from the vulnerable server, and the dlls from the patch.

Which brings us straight to CVE-2021–26855:
By using the diff technique, and by using references from previous research on the subject (we’ll link it below), we were able to detect that a few changes were made to the DLL Microsoft.Exchange.FrontEndHttpProxy, especially in the class BEResourceRequestHandler.

This class is responsible for handling specific resource-types requests, and it implements a method named CanHandle ()

which checks for the following:

1. The use of a special cookie called X-BEResource.
2. The request ends with a resource file.

If both are true, the cookie is then given to the BackEndServer.FromString () method for further inspection of the relevant backend server.
The method looks for a “~” in the cookie, and splits the request in half, using the first half as the path to the backend server and the second half as “version”.

By examining the GetTargetBackEndServerUrl () we get a better understanding of the correct schema for this cookie:

FQDN/<backend service>~<version>, and the resulting url is as follows: https://FQDN/<backend service>:444/<original resource-file>.

And so, the final request looks something like this:

Apart from minor authentication issues, that is it! This Cookie is the key for CVE-2021–26855.
By using the correct schema, we can send unobstructed requests to any backend server of our choosing.

Now, with the ssrf at our disposal, lets get to CVE-2021-27065 to perform remote code execution (RCE):

From the various log files distributed, and by previous research, we know to focus the efforts on the ResetOAB feature in the admin center.

The ResetOAB functionality essentially allows us to manipulate virtual directories, of which a byproduct is that a config file is written to disk, and we can control where it is written to.
Not only that, but there is no validation on the file type, so nothing is blocking us from writing a .aspx file!

But wait, we have to be able to control the data written to the config file if we want to weaponize it.

Luckily, aside from reseting the virtual directory, we can also edit the default parameters, and make sure that when these fields are written to the file, they contain our code. And again, there is no input validation on the Internal and External Parameters, allowing us to write malicious Javascript into the .aspx file

As you can imagine, to perform these requests, the request must contain some sort of authentication, and in our case it is the msExchEcpCanary, and ASP.net session ID.

We are not going to go into details about how to acquire these at this stage as the vulnerability still exists in the wild, and in large numbers. When this is disclosed we will update with the details.

The result of this research recreates the attack in the Cymulate platform for you to validate your protections.

If You Run Premises-Based Microsoft Exchange – Assume You Are Breached.

If your organization uses any version of premises-based Microsoft Exchange, you should assume you are currently breached. Only Exchange Online is not affected.

1. Know that patching will not clean up an already compromised system.
2. Most security control vendors from AV/EDR/SOCaaS were unable block the breach and subsequent expand attack.
3. At the minimum, the expand portion of the attack included the implementation of backdoor web shells and subsequent exchange accounts created.
4. Remediation should include full account review of all accounts and password reset of all administrative accounts in Active Directory and in Exchange.
5. Note that both Microsoft and other researchers have detected other nation-state and criminal actors taking advantage of the exploits after the announcement on Tuesday, March 2^nd.
6. Validate remediation efforts by running a PoC of the attack from the Cymulate platform

What Can You Do to Defend Your Organization?

Carefully testing and monitoring your network for unusual activity is also critical, as the first sign of incursion may be when the threat actors try to remove data from your environment.

Other Resources

• US DHS (Department of Homeland Security) CISA (Cybersecurity and Infrastructure Security Agency): Mitigate Microsoft Exchange Server Vulnerabilities:
  https://us-cert.cisa.gov/ncas/alerts/aa21-062a
• Microsoft HAFNIUM hunting against indicators of compromise (IoCs):
  https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/
  https://www.crn.com/news/security/microsoft-exchange-vulnerability-much-larger-than-company-is-saying-huntress

Schedule a demo to test the effectiveness of your security controls.