CVE-2022-41040 and CVE-2022-41082 – zero-days in MS Exchange
Discription

![](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2022/12/19160500/abstract_black_matrix-990×400.jpg)

## Summary

At the end of September, GTSC reported an attack on critical infrastructure that took place in August. During the investigation, experts found that two 0-day vulnerabilities in Microsoft Exchange Server were used in the attack. The first one, later identified as CVE-2022-41040, is a server-side request forgery (SSRF) vulnerability that allows an authenticated attacker to remotely trigger the next vulnerability – CVE-2022-41082. The second vulnerability, in turn, allows remote code execution (RCE) when MS Exchange PowerShell is accessible to the attacker. As noted in the GTSC report, both vulnerabilities were exploited together in the wild to create a backdoor on a vulnerable server, and perform lateral movement.

After CVE-2022-41040 and CVE-2022-41082 were revealed, Microsoft provided [mitigation guidance]() followed by a few updates. According to the company, the vulnerabilities affect MS Exchange Server 2013, MS Exchange Server 2016 and MS Exchange Server 2019.

On October 11, 2022, Microsoft released patches to cover these vulnerabilities as part of its Patch Tuesday update. After that, on November 17, a security researcher published the first working PoC. It was a Python script that accepts the following parameters: user, password, mail address and command line to be executed on the victim’s host.

The cybersecurity community dubbed the pair of vulnerabilities **ProxyNotShell**. The name refers to a recent ProxyShell attack chain containing similar vulnerabilities in Exchange Servers that were disclosed in 2021. ProxyShell is a set of three vulnerabilities: CVE-2021-34473, CVE-2021-34523 and CVE-2021-31207. Attackers used them to create web shells and execute arbitrary code on vulnerable Microsoft Exchange Servers.

## ProxyNotShell exploitation details

The first step in this attack is exploiting **CVE-2022-41040** to get access to the PowerShell API endpoint. Using an insufficient filtering of input data in the Exchange **Autodiscover** mechanism, an attacker with a known login and password combination for a registered account, can gain access to the privileged endpoint of the Exchange Server API (**https://%_exchange server domain%_/powershell)**. This access allows the attacker to execute PowerShell commands in Exchange’s environment on the server machine, passing them in the payload via the XML SOAP protocol.

At the next step, the attacker must get access to **Web-Based Enterprise Management (WBEM)** via the **WSMAN Protocol**. The attacker initiates the shell on the vulnerable system for further PowerShell script execution via **Windows Remote Management (PsRemoting)**.

[![HTTP POST request with XML SOAP to initiate PsRemoting](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2022/12/19083206/Vulnerabilities_CVE-2022-41040_and_CVE-2022-41082_in_MS_Exchange_01-1024×467.png)]()

**_HTTP POST request with XML SOAP to initiate PsRemoting_**

After initiation of the shell, the attacker should immediately extend its lifetime; otherwise, the shell will be closed as its expiration time is too short by default. This is necessary for further command execution on Exchange Server. To do that the attacker immediately sends a special request via **WSMAN** that enables the **keep alive** option.

[![HTTP POST request with XML SOAP to extend the shell’s lifetime](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2022/12/19083245/Vulnerabilities_CVE-2022-41040_and_CVE-2022-41082_in_MS_Exchange_02-1024×541.png)]()

**_HTTP POST request with XML SOAP to extend the shell’s lifetime_**

After that, the attacker exploits a second vulnerability – **CVE-2022-41082**. By using PowerShell Remoting the attacker sends a request to create an address book, passing encoded and serialized data with a special payload as a parameter. In a published PoC, this encoded data contains a gadget called **System.UnitySerializationHolder** that spawns an object of the **System.Windows.Markup.XamlReader** class. This class processes XAML data from a payload, which creates a new object of the **System.Diagnostics** class and contains a method call to open a new process on the target system. In the published PoC, this process is **calc.exe**.

[![HTTP POST request with XML SOAP to start new process](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2022/12/19083322/Vulnerabilities_CVE-2022-41040_and_CVE-2022-41082_in_MS_Exchange_03-1024×417.png)]()

**_HTTP POST request with XML SOAP to start new process_**

[![Main payload portion that executes the calc.exe process](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2022/12/19083400/Vulnerabilities_CVE-2022-41040_and_CVE-2022-41082_in_MS_Exchange_04.png)]()

**_Main payload portion that executes the calc.exe process_**

## ProxyNotShell post exploitation

A few weeks later after the vulnerability was disclosed, Kaspersky detected a successful exploitation of **ProxyNotShell** in the wild. The actor performed the following actions:

* Reconnaissance (users, groups, domains)
* Various hijack attempts (even dropping vulnerable binaries)
* Remote process injection
* Persistence
* Reverse shell

In this case, the attacker had the credentials to perform such an intrusion. They exploited the company’s Exchange Server and as a result were able to create any process they wanted on the Exchange machine, passing commands as a payload.

[![](https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2022/12/19095522/Vulnerabilities_CVE-2022-41040_and_CVE-2022-41082_in_MS_Exchange_05-1024×764.png)]()

On the server side all processes that are started via exploitation have a main parent process with certain parameters: **w3wp.exe -ap “msexchangepowershellapppool”.**

These post-exploitation steps of the attack are very similar to the steps in the attack reported by [TrendMicro](), with the only difference being the vulnerabilities that are exploited.

Our products protect against all of these post exploitation steps as well as other attacks leveraging the **CVE-2022-41040** and **CVE-2022-41082** vulnerabilities. The detection name for **ProxyNotShell** is **PDM:Exploit.Win32.Generic**.

## Our recommendations

A few words of advice to those worried about possible exploitation of ProxyNotShell or other 0-day vulnerabilities:

* Focus your defense strategy on detecting lateral movement and data exfiltration to the internet. Pay special attention to outgoing traffic to detect cybercriminal connections.
* Use the latest [Threat Intelligence]() data to stay aware of actual TTPs used by threat actors.
* Use a security solution with exploit prevention, vulnerability and patch management components, such as Kaspersky Endpoint Security for Business. Our [Exploit Prevention]() component monitors suspicious actions by applications and blocks the execution of malicious files.
* Use solutions like [Kaspersky Endpoint Detection and Response]() and [Kaspersky Managed Detection and Response]() that identify and stop attacks in the early stages.

## Indicators of compromise

F77E55FD56FDAD21766CAA9C896734E9 | LockDown.dll | Malware hijack library | Trojan.Win64.Dllhijacker
—|—|—|—
F9322EAD69300501356B13D751165DAA | mfeann.exe | Dropped vulnerable binary for DLL hijack | PDM:Exploit.Win32.Generic
A2FAE32F116870E5A94B5FAB50A1CB71 | Svchosts.exe | Malware reverse proxy | Trojan.Win64.Agent.qwibok
HEUR:HackTool.Win64.Proxy.gen
47A0814408210E6FCA502B3799B3952B | Glib-2.0.dll | Malware hijack library | Trojan.Win64.Dllhijacker
379F87DAA6A23400ADF19C1CDD6B0DC9 | vmwarexferlogs.exe | Dropped vulnerable binary for DLL hijack | PDM:Exploit.Win32.Generic
193.149.185.52:443 | С2 server
sync.service.auzreservices.com | С2 serverRead More

Back to Main

Subscribe for the latest news: