On March 2nd 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 5th 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.
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.
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:
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.
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 your organization uses any version of premises-based Microsoft Exchange, you should assume you are currently breached. Only Exchange Online is not affected.
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.
Our highly experienced and diverse researchers are fluent in security intelligence practices, combining expertise in private security, military, and intelligence experience. Continuously examining the cyber-threat landscape, our experts deliver in-depth visibility into today’s threats and the actors behind them.