Discovering and Blocking a Zero-Day Exploit: The Case of CVE-2023-36874

Originally published by CrowdStrike.

In July 2023, CrowdStrike discovered an unknown exploit kit leveraging a still-unknown vulnerability affecting the Windows Error Reporting (WER) component. Our team prepared to report this newly discovered vulnerability to Microsoft — only to discover that the Google Threat Analysis Group had independently discovered and disclosed it shortly before we did. Microsoft assigned the identifier CVE-2023-36874 to the vulnerability.

Given this vulnerability was a zero-day when we found it, we are sharing the story of how our team discovered this issue, as well as technical details and some indicators of compromise.

The Story

On June 22, 2023, we observed multiple binaries being dropped onto a system owned by a European technology entity via Remote Desktop Protocol (RDP) connection from an unmanaged host. We blocked and quarantined the execution of several of these binaries as we detected potential exploits for CVE-2021-24084. An initial analysis was conducted to determine the final objectives of these binaries; however, it was inconclusive. CrowdStrike Counter Adversary Operations was asked to assist, given the team’s expertise in both threat hunting and adversary intelligence, in order to accelerate the detection and remediation of threats.

During the first static analysis of these binaries, a string containing the Russian word 0дэй — translated as “0day” — indicated the binaries may be exploits related to an unknown vulnerability. A thorough analysis ensued to pinpoint the correct potential vulnerability used. The results indicated the use of an unknown vulnerability affecting the WER component. Hence, at the time of execution, we detected a still-unknown zero-day in the wild, along with an exploit kit using it.

The Technical Details

The WER service is a privileged service whose role is to analyze and report various software issues that may arise on a Windows host. This service can be interacted with through several undocumented COM interfaces, which can be found in wercplsupport.dll. In particular, by chaining the following function calls, it is possible to get a pointer to a IWerReport COM interface:

1. CoCreateInstance(CLSID_ERCLuaSupport, NULL, CLSCTX_LOCAL_SERVER, IID_IErcLuaSupport, (PVOID*)&pIErcLuaSupport);
2. pIErcLuaSupport->CoCreateIWerStoreFactory(&pIWerStoreFactory);
3. pIWerStoreFactory->CoCreateIWerStore(&pIWerStore);
4. pIWerStore->EnumerateStart()
5. pIWerStore->LoadReport(<reportName>, &pIWerReport); where reportName is the name of a directory containing a WER report to be processed

As a result of calling IWerReport->SubmitReport, the WER service will call the WerpSubmitReportFromStore function from wer.dll. This eventually leads, under conditions that were not analyzed, to the call of the UtilLaunchWerManager function, itself calling the CreateProcess API in order to start the C:\Windows\System32\wermgr.exe executable.

The core problem of this vulnerability lies in the fact that the CreateProcess API running under impersonation will follow any file system redirection set up by a threat actor but will use the calling process security token and not the impersonated token to set the security context of the process. In the case of the WER service, impersonation is indeed present when the wermgr process creation occurs, as highlighted in the following screenshot:

This means, in the case a prior file system redirection points to an attacker-controlled wermgr executable, this executable will be executed instead of the legitimate wermgr executable. This allows the attacker-controlled executable to be run with the privileges of the WER service (i.e., SYSTEM).

In the case of the observed exploit, the following steps are taken to achieve privilege escalation:

• The exploit sets up the necessary files on the system to achieve successful exploitation later. Two different objectives are followed at this step:
  • Set up a dummy Report.wer file in the directory C:\ProgramData\Microsoft\Windows\WER\ReportArchive\WER1CF4123. This dummy file will be referenced in the IWerReport->SubmitReport function at the start of the exploit chain.
  • Set up a fake C:\ root hierarchy under the C:\Users\public\test directory so the file system redirection will point to the attacker files instead of the legitimate ones. In this hierarchy, the exploit creates a copy of itself as C:\Users\public\test\Windows\System32\wermgr.exe as well as a dummy WER report Report.wer inside C:\Users\Public\test\ProgramData\Microsoft\Windows\WER\ReportArchive\WER1CF4123.
• Creates a redirection from the C:\ drive to C:\Users\public\test by calling the NtCreateSymbolicLink function, where the third and fourth parameters point respectively to \??\C: and \GLOBAL??\C:\Users\Public\Test. This redirection is created when changes are detected in the C:\\ProgramData\\Microsoft\\Windows\\WER\\ReportQueue directory.
• Triggers IWerReport->LoadReport() with WER1CF4123 as a parameter.
• Triggers IWerReport->SubmitReport() with WER1CF4123 as a parameter.
• Due to redirection, C:\Users\public\test\Windows\System32\wermgr.exe is executed instead of the legitimate wermgr.exe. The exploit binary is now executing with high privileges.

A Look at the Exploit Kit

In the exploit kit observed, all exploit binaries aim to spawn a privileged interpreter, either the traditional command interpreter cmd.exe, or powershell_ise.exe, in the interactive session from which the binary was launched. If this aim cannot be fulfilled, then a privileged scheduled task is created to serve as a proxy for the spawning of the privileged interpreter.

Within the exploit kit observed, some binaries are packed while others are not. Some contain C++ code while others appear to be pure C code. Some binaries were apparently able to launch multiple versions of the same exploit depending on the host’s OS version while others appear dedicated to a single OS. This information tends to indicate that the privilege escalation vulnerability was likely known to a group of different developers.

At the time of this writing, CrowdStrike Counter Adversary Operations does not attribute the activity to a particular actor.

Indicators of Compromise

The following table lists the different binaries that CrowdStrike observed being dropped. It should be noted the following indicators are of low fidelity. Indeed, several of them are packed, indicating the threat actor has the potential capability to generate new binaries, with different hashes, containing the exploit.

Conclusion

It is critical to ensure timely vulnerability patching in order to protect enterprise devices. However, when adversaries target unknown vulnerabilities, timely patching becomes irrelevant. This is why it’s essential for organizations to implement multiple layers of defense.