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

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

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

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.

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