Continued Exploitation and Evolution of ProxyShell Vulnerabilities - The Monitor, Issue 22

In August 2021, threat actors started to exploit ProxyShell vulnerabilities in certain Microsoft Exchange Server versions. Today, not only is Kroll seeing actors continue to leverage ProxyShell in larger network intrusions but also now organizations must also be on guard for the so-called ProxyNotShell vulnerabilities, which surfaced in September 2022. 

ProxyShell, collectively known as CVE-2021-34473, CVE-2021-34523 and CVE-2021-31207, allows remote code execution (RCE) without authentication on vulnerable deployments. 

ProxyNotShell, collectively CVE-2022-41040 and CVE-2022-41082, allows RCE when Exchange PowerShell is open to a threat actor, but requires authenticated access. In these attacks, CVE-2022-41040, a server-side request forgery (SSRF) vulnerability, can enable an authenticated attacker to remotely trigger CVE-2022-41082, which allows RCE. 

From ProxyShell to ProxyNotShell 

Although Microsoft became aware of and issued a patch for ProxyShell in its May and July 2021 security updates, the associated CVE identifiers were not released until August 2021. At that time, Microsoft publicly advised customers running vulnerable versions of their Exchange Server software to install applicable security updates to prevent threat actor exploitation. 

Fast forward to September 29, 2022, when Microsoft released an advisory for two zero-day vulnerabilities reported via the Zero Day Initiative and collectively referred to by the security community as ProxyNotShell. Although a security update for the zero-day vulnerability was not immediately provided, Microsoft released a rule mitigation strategy. On November 8, 2022, Microsoft released the Exchange server security update for ProxyNotShell in their patch Tuesday release.  

ProxyShell CVEs Leveraged in Multiple Attack Types

Original CVE reports from NIST (National Institute of Standards and Technology) indicated that the ProxyShell vulnerability only existed in Microsoft Exchange Server (on-premises) 2016. However, Kroll has also observed ProxyShell being exploited on Microsoft Exchange Server 2010 as a lateral movement tactic when a newer version of on-premises Exchange Server is also available in the ecosystem. 

Kroll examiners have discovered threat actors leveraging ProxyShell for various malicious activities. For example, in our incident response work, Kroll investigators have often seen actors using ProxyShell to write malicious web shell code to various locations and to embed malicious web shell code inside virtual configuration files on Exchange Servers. For context, a web shell provides remote access to a web server, including file system access and command execution, through a web browser.

As Kroll reported in an earlier case study, threat actors have used CVE-2021-34523 to access the Exchange Web Services (EWS) application programming interface (API). Then, via the API, they deploy a script that programmatically locates active email message threads and uses them to remotely send spam that appears to originate from the victim organization. 

Our investigators have seen instances where threat actors compromise an NT AUTHORITY/SYSTEM account, which is a Windows account with the highest privileges, and use it to impersonate other email accounts in the tenant. They then can create an email message in the \Drafts folder of these email accounts that includes a text file attachment. Ultimately, the email message is exported into a web accessible directory on the Exchange server, where the message is decoded into a web shell that can facilitate unauthorized remote access. 

Kroll has also discovered that actors are further obfuscating their web shells by placing them in the registry hives as a New-ExchangeCertificate. The registry is a database that stores operating system settings and configurations for installed applications, and a New-ExchangeCertificate establishes trusted access. Therefore, this tactic enables actors to maintain persistence and the capability to interact with the web shell (Figure 1). In many of Kroll’s related incident response investigations, the web shell was placed by a threat actor only in the New-ExchangeCertificate. Even after organizations had deleted suspicious emails in the Drafts folders as well as suspicious mailbox accounts, a web shell in the New-ExchangeCertificate was identified by Kroll to still be active. In addition to the server-side script, the web shell can communicate to an external server and provide access to the actors. 

This is an example of an observed web shell written to a New-ExchangeCertificate cmdlet:

New-ExchangeCertificate, -GenerateRequest \"True\" -RequestFile \"C:\\inetpub\\wwwroot\\aspnet_client\\xcsgl.aspx\" 

The web shell was searched and detected in the Windows registry at the following location: 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\REQUEST\Certificates\

Figure 1 – Obfuscated Web Shell in New-ExchangeCertificate

Additionally, Kroll has observed ransomware groups, including Conti, Babuk, Cuba and LockFile, leveraging ProxyShell during their Intrusion Lifecycles. For example, in 2022, a member of group reportedly targeted Microsoft Exchange servers still vulnerable to ProxyShell so they could deploy multiple backdoors in order to steal important account credentials and data. 

ProxyNotShell Adding to Exchange Exploitation

At the end of September 2022, reports surfaced about two more Exchange vulnerabilities, quickly dubbed ProxyNotShell, that would enable remote code execution when PowerShell is accessible to the attacker on the server. Researchers noted that an attacker would require authenticated access to the vulnerable Exchange server in order to exploit CVE-2022-41040, which is then used to remotely trigger CVE-2022-41082. This authentication can be in the form of any email user; however, and so an attacker may use brute force, credential stuffing or phishing techniques to acquire a user logon first.

Microsoft subsequently released a series of rule mitigation measures after actors and researchers alike were able to bypass each measure in turn. On November 8, 2022, Microsoft released the Exchange server security update for ProxyNotShell in their patch Tuesday release.  

It is important to note that having a multifactor authentication (MFA) service for user logins does not protect against ProxyNotShell, as the "Autodiscover" frontend used to trigger the vulnerability can allow the attacker to use basic authentication to exploit the Exchange server with just a username and password.

Actors have reportedly been “heavily exploiting” ProxyNotShell, primarily for creating web shells and facilitating lateral movement, and the Cybersecurity & Infrastructure Security Agency (CISA) has listed the ProxyNotShell vulnerabilities in its Known Exploited Vulnerabilities Catalog. In addition, shortly after Microsoft patched for ProxyNotShell, a security researcher publicly released a proof-of-concept exploit for the vulnerability. As of this writing, Kroll has not observed the global volume of exploitation noted during 2021’s ProxyShell and ProxyLogon attacks. Kroll assesses that the widespread and low bar to operationalization of ProxyShell and ProxyLogon style attacks differed from ProxyNotShell patterns in that while only unpatched Internet-facing connectivity of an Exchange server was needed for the 2021 attack strategies, ProxyNotShell required authenticated access to a mailbox before the CVEs could be operationalized. 

While still potentially achievable through phishing or mass password spray attacks, the opportunistic nature of ProxyNotShell is diminished in comparison to earlier Intrusion Lifecycle patterns. 

Protecting Against ProxyShell and ProxyNotShell

For Exchange Server 2010, one of the first solutions to protect against ProxyShell is to upgrade to a supported version of the software because the 2010 Server no longer has free patching by Microsoft. For Exchange Server 2013, 2016 and 2019, in order to remove embedded web shell code, Kroll recommends removing the code directly from the configuration file and restarting Internet Information Services (IIS). Given that ProxyShell can be used to create mailboxes to deploy web shells, Kroll recommends searching for newly created mailbox accounts on the Exchange Server. Once the suspicious mailbox accounts are identified, organizations should preserve the account by exporting the data for analysis and then deleting the suspicious mailboxes as well as any suspicious draft messages found in other mailbox accounts. 

As mentioned earlier, Microsoft has also issued Exchange server security updates for ProxyNotShell. Kroll recommends organizations stay up to date with the Exchange server security updates and patches to ensure protection from vulnerabilities occurring in the environment. 

Experts Corner

Kroll incident response expert Becky Passmore recommends the following practices to help organizations best defend against the ProxyShell vulnerabilities: 

• Keep Microsoft Exchange servers up to date for all security updates and patches
• Enable and enforce MFA across all Exchange mailbox accounts, as this minimizes the effectiveness of password spray attacks and password reuse attacks
• Utilize endpoint detection and response (EDR) software to monitor endpoints as well as respond and investigate suspicious activity in a timely manner
• Verify logging is enabled and review the retention settings via regular assessments and testing to ensure they are appropriately adjusted to maintain logs for a time period consistent with your organization’s security policies

Microsoft Exchange server logs and IIS logs, as a foundational start, provide invaluable evidence for suspicious activity in the environment. Implement proper log aggregation and forwarding of IIS logs and Exchange server logs, at a minimum, to a centralized SIM/SIEM collector. Kroll can assist with additional logging and artifact types that would be useful in a digital forensics/incident response investigation. Ensuring a balance between managed detection and response and standard security patching can make the difference between your organization remaining secure or being susceptible to a threat actor’s intrusion. New vulnerabilities are emerging every day so it's important for your experts to remain vigilant and mitigate these threats as needed. 2022 saw approximately 1,000 more CVEs identified every quarter than in previous quarters and certain organized crime groups are prolific in their research and development operations to advance their intrusion lifecycles. Kroll continues to monitor critical CVEs and provide guidance accordingly.

Our experts are available 24x7 via our incident response hotlines or contact us page. 

The article above was extracted from The Monitor newsletter, a monthly digest of Kroll’s global cyber risk case intake. The Monitor also includes an analysis of the month’s most popular threat types investigated by our cyber experts. Subscription is available below.