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


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

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

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

HTTP POST request with XML SOAP to start new process

Main payload portion that executes the calc.exe 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

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
47A0814408210E6FCA502B3799B3952B Glib-2.0.dll Malware hijack library Trojan.Win64.Dllhijacker
379F87DAA6A23400ADF19C1CDD6B0DC9 vmwarexferlogs.exe Dropped vulnerable binary for DLL hijack PDM:Exploit.Win32.Generic С2 server С2 server

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

Your email address will not be published. Required fields are marked *



Meet the GoldenJackal APT group. Don’t expect any howls

GoldenJackal is an APT group, active since 2019, that usually targets government and diplomatic entities in the Middle East and South Asia. The main feature of this group is a specific toolset of .NET malware, JackalControl, JackalWorm, JackalSteal, JackalPerInfo and JackalScreenWatcher.

APT trends report Q1 2023

For more than five years, the Global Research and Analysis Team (GReAT) at Kaspersky has been publishing quarterly summaries of advanced persistent threat (APT) activity. These summaries are based on our threat intelligence research; and they provide a representative snapshot of what we have published and discussed in greater detail in our private APT reports.

Tomiris called, they want their Turla malware back

We continued to track Tomiris as a separate threat actor over three new attack campaigns between 2021 and 2023, and our telemetry allowed us to shed light on the group. In this blog post, we’re excited to share what we now know of Tomiris with the broader community, and discuss further evidence of a possible connection to Turla.

Subscribe to our weekly e-mails

The hottest research right in your inbox