Securonix Threat Labs Security Advisory: ProxyNotShell Revisited: Detecting Latest Exploits Using Security Analytics
Threat Research
By Securonix Threat Labs, Threat Research: D.Iuzvyk, T.Peck, O.Kolesnikov
Introduction
One of the most important news in November’s Microsoft Patch Tuesday was the release of the patches for the ProxyNotShell RCE vulnerabilities (CVE-2022-41040, CVE-2022-41082). However, until recently, the exploits targeting these vulnerabilities were not available publicly. That said, working exploits have recently started to emerge. With a test Exchange Server setup in a lab environment, we can finally test and record data from the exploited Exchange Server, and contrast those to our detections that have existed since its release.
ProxyNotShell “in a nutshell”
For years, Microsoft Exchange has been a massive target for exploitation. In 2021, three new CVEs were released for critical vulnerabilities to the Microsoft Exchange platform (CVE-2021-34473, CVE-2021-34523, and CVE-2021-31207). The attack centered around the collection of vulnerabilities known as ProxyShell, which allowed an attacker to bypass authentication and execute code on the Exchange server with SYSTEM level privileges. The attack led to a widespread exploitation campaign from threat actors all over the world.
Later this year in 2022, two new critical CVEs were released following a similar method of the remote code execution (RCE) vulnerability to Exchange Servers that we saw with ProxyShell. These are tracked under CVEs: CVE-2022-41040 and CVE-2022-41082 and affect all versions of Microsoft Exchange Server 2013, Exchange Server 2016, and Exchange Server 2019. Since the new zero-day exploits are similar to that of the ProxyShell vulnerability, unofficially the exploit is now known as ProxyNotShell.
The ProxyNotShell exploitation attack chain is fairly trivial and consists of CVE-2022–41040, an authenticated server-side request forgery (SSRF) (Note – in contrast to ProxyShell, to exploit ProxyNotShell successfully, a user logon/password are needed, but second factor authentication is not required, so this can be effectively viewed as a “mid-auth” vulnerability) vulnerability found in the Exchange Autodiscover frontend, and CVE-2022-41082, a remote code execution vulnerability found in the Exchange PowerShell backend. Essentially, after bypassing exploitation using CVE-2022-41040, attackers exploit CVE-2022-41082 to gain remote code execution and run commands in vulnerable Exchange Servers.
Further details/attack examples
According to data provided by GTSC, which first reported the Exchange vulnerability, the exploit works by sending a specially-crafted request to the Exchange web server. The request follows the pattern:
autodiscover/[email protected]/<Exchange-backend-endpoint>&Email=autodiscover/autodiscover.json%[email protected]
If the request looks familiar, you’d be correct; the format and structure are nearly identical to that of the ProxyShell vulnerability from last year. Based on research so far, an attacker will execute code on the target Exchange server to download a webshell, oftentimes in the Exchange/auth directory.
Attack scope
For the two CVE’s listed under the ProxyNotShell attack, CVE-2022-41082 is particularly concerning as it allows for remote code execution. However, as mentioned, unlike ProxyShell, ProxyNotShell requires an authenticated user in order for the attack to be carried out successfully, thus reducing the overall severity and scope of the attack. As the IIS worker process runs as NT AUTHORITY\SYSTEM, successful RCE exploitation would execute code with the highest privilege level on the target server.
For a successful attack to be carried out, the attacker would need user account credentials to authenticate with the Exchange server first, before running the ProxyNotShell exploit. This adds complexity to the overall attack chain, therefore the overall attack chain would become twofold: ProxyNotShell combined with some form of password guessing/reuse, account theft, or malicious insider threat.
There are several known attacks that could be a precursor to ProxyNotShell. Today, social engineering is still a common way of obtaining secret company information. A threat actor could attempt to persuade a user in an organization to provide their email credentials, thus circumventing the “authenticated user” requirement of the ProxyNotShell attack chain. Account usernames and passwords can also be obtained through previous data breaches involving the target user.
Exploitation attack chain: w3wp.exe
For both ProxyShell and ProxyNotShell, the Windows process that becomes the subject of exploitation is the IIS process w3wp.exe which resides in the c:\Windows\System32\inetsrv\ directory.
Figure 1: IIS Worker Process Information
When it comes to CVE exploits regarding RCE, code is executed on the host in an unintended way. That executed code needs to come from somewhere, and in this case, it’s the aforementioned IIS web process. In our experience, most scripting related processes, or rare processes in general spawning from w3wp.exe should typically be considered suspicious and investigated.
The good news is that detections surrounding ProxyShell and ProxyNotShell will be similar. If your organization already has detections in place (see “Securonix Detections” below), you’re already one step ahead.
Exploitation attack chain (phase 1): ProxyNotShell exploit
As mentioned earlier, there’s been some publicly available exploits released for ProxyNotShell. One example that recently surfaced was an exploit for ProxyNotShell which was coded in the Python2 programming language. It requires very minimal effort to set up and as you can see in the figure below, it reported that our command “cmd.exe /c whoami > C:\poc_test.txt” ran successfully.
The exploit consists of four inputs, the target host name, a valid user account, password, and the command to execute.
Figure 2: ProxyNotShell PoC exploit in action
But did it actually execute? Let’s inspect the target host. If we’re “lucky” we should see a newly created file called “poc_test.txt” on the root directory of the C:\ drive containing the text: “nt authority\system”. Remember the System user is the default builtin account that the exchange process w3wp.exe runs as.
Figure 3: Successful ProxyNotShell exploitation
And sure enough, there it is! At this point the exploitation flow will be up to the attacker. A common path we see is to drop a webshell or a malicious payload that can call back to a C2 server under the attacker’s control.
Exploitation attack chain (phase 2): webshells
As mentioned earlier, a common method of persistent code execution following an Exchange zero-day exploit is dropping a webshell. With ProxyShell, Chinachopper was often used and it is still wreaking havoc today with ProxyNotShell.
As a quick recap, webshells allow for the attacker to easily perform a number of tasks on the target host. This includes but is not limited to code execution, file uploads, file downloads and directory enumeration.
The below image (Figure 4) shows a standard ASPX webshell that can be easily found online. The webshell in the example below was renamed to HttpRedirService.aspx, following the pattern found on the initial attack reported by GTSC.
Figure 4: Webshell running the command: “ipconfig /all & whoami”
Similar to that of CVE exploits that target vulnerable web server processes, a webshell will also leverage the webserver process to initiate code execution. Similar detections for webserver process exploitation and webshell code execution would be similar. The figure below shows the parent child relationship between the webserver process and spawned processes initiated by the webshell.
Figure 5: Webshell parent/child process
In another example, using Securonix, we can identify the webshell-initiated command “cmd.exe /c ipconfig /all & whoami” being executed on the target machine. Notice that the parent child jumps from w3wp.exe to cmd.exe. That by itself would always be suspicious!
Figure 6: Webshell – logged event in Securonix
This data can then be taken and easily converted into a policy which looks for cmd.exe or powershell.exe being called from w3wp.exe as a parent process. With the policy in place, we are able to detect a different, interesting and very actionable violation shown in the figure below.
Figure 7: Exploited w3wp.exe calling cmd.exe/powershell.exe
Testing Microsoft’s mitigation through URL rewrites
Recently Microsoft incorporated a new service into Exchange Server 2016 and 2019 versions called the Exchange Emergency Mitigation Service (EEMS). As the name suggests, the service provides emergency configuration changes to IIS/Exchange services in order to reduce risk of zero day attacks outside of regular patching.
When ProxyNotShell came to light, Microsoft was quick to leverage the EEMS service to mitigate the vulnerability. The mitigation can be found in the Exchange server’s IIS configuration and consists of a URL rewrite as seen in the figure below.
Figure 8: EEMS ProxyNotShell mitigation
Now that we have a working exploit, we’re able to verify that the EEMS mitigation works as intended. With the URL rewrite enabled, let’s rerun the exploit script and see what happens.
Figure 9: EEMS ProxyNotShell failed exploitation due to EEMS
With the only difference being EEMS enabled, we can see that the connection fails once the PoC code is executed. This proves that EEMS implementation of using a URL rewrite to mitigate ProxyNotShell is effective against a legitimate exploitation attempt.
Conclusion
As with any critical CVE it’s important to understand the scope and capabilities of the attack in your own environment. While ProxyNotShell does require an authenticated user for RCE to be successful, it’s crucial to not rely on that as any form of mitigation. To date, no official patch has been supplied from Microsoft.
Fortunately, Microsoft has provided mitigation steps that can be implemented on the IIS server to prevent the remote PowerShell redirect from functioning. Securonix customers can leverage Spotter threat hunt queries, and detections provided below.
Securonix recommendations and mitigations
- Deploy Microsoft’s mitigations strategies including the redirect rule and restricting PowerShell remoting to administrators only.
- Avoid exposing the Exchange Outlook Web application to the internet.
- Patch Exchange vulnerabilities as soon as they are provided.
- Monitor suspicious shell commands executed from the SYSTEM user.
- Examine the Exchange file structure and look for anomalous .aspx files which could indicate a webshell.
- Leverage Securonix Spotter queries and detections provided below.
Relevant Spotter queries
- rg_functionality = “Endpoint Management Systems” AND (deviceaction = “Process Create” OR deviceaction = “ProcessCreate” OR deviceaction = “Process Create (rule: ProcessCreate)” OR deviceaction = “ProcessRollup2” OR deviceaction = “SyntheticProcessRollUp2” OR deviceaction = “WmiCreateProcess” OR deviceaction = “Trace Executed Process” OR deviceaction = “Process” OR deviceaction = “Childproc” OR deviceaction = “Procstart” OR deviceaction = “Process Activity: Launched”) AND sourceprocessname = “w3wp.exe” AND (destinationprocessname = “cmd.exe” OR destinationprocessname = “powershell.exe” OR destinationprocessname = “pwsh.exe”)
- rg_functionality = “Endpoint Management Systems” AND (deviceaction ENDS WITH “Written” OR deviceaction = “File created”) AND customstring49 ENDS WITH “.aspx” AND customstring49 CONTAINS “inetpub\wwwroot” AND destinationprocessname = “System”
- rg_functionality = “Microsoft Windows” AND baseeventid = “1” AND message CONTAINS “New-MailboxExportRequest” AND message CONTAINS “-FilePath” AND message CONTAINS “c$\inetpub\wwwroot”
- rg_functionality = “Endpoint Management Systems” AND (deviceaction ENDS WITH “Written” OR deviceaction = “File created”) AND destinationprocessname = “w3wp.exe” AND resourcecustomfield1 CONTAINS “MSExchange” AND ((customstring49 ENDS WITH “.ps1” OR customstring49 ENDS WITH “.bat” OR customstring49 ENDS WITH “.exe” OR customstring49 ENDS WITH “.dll”) OR ((customstring49 ENDS WITH “.aspx” OR customstring49 ENDS WITH “.asp” OR customstring49 ENDS WITH “.ashx”) AND (customstring49 CONTAINS “FrontEnd\HttpProxy” OR customstring49 CONTAINS “inetpub\wwwroot\aspnet_client”)))
- (rg_functionality = “Next Generation Firewall” OR rg_functionality = “Web Application Firewall” OR rg_functionality = “Web Server” OR rg_functionality = “Web Proxy”) AND requestclientapplication STARTS WITH “antSword/”
- rg_functionality = “Web Server” AND requestcontext CONTAINS “autodiscover.json” AND requestcontext CONTAINS “@.” AND requestcontext CONTAINS “powershell.”
- rg_functionality = “Web Server” AND requestcontext CONTAINS “autodiscover.json” AND requestcontext CONTAINS “@” AND requestcontext CONTAINS “powershell.”
- rg_functionality = “Endpoint Management Systems” AND (deviceaction = “Process Create” OR deviceaction = “ProcessCreate” OR deviceaction = “Process Create (rule: ProcessCreate)” OR deviceaction = “ProcessRollup2” OR deviceaction = “SyntheticProcessRollUp2” OR deviceaction = “WmiCreateProcess” OR deviceaction = “Trace Executed Process” OR deviceaction = “Process” OR deviceaction = “Childproc” OR deviceaction = “Procstart” OR deviceaction = “Process Activity: Launched”) AND (sourceprocessname = “w3wp.exe” OR destinationprocessname = “w3wp.exe”) AND (resourcecustomfield1 CONTAINS “whoami” OR resourcecustomfield1 CONTAINS “echo” OR resourcecustomfield1 CONTAINS “&dir&” OR resourcecustomfield1 CONTAINS “&cd&” OR resourcecustomfield1 CONTAINS “&ipconfig&”)
Some examples of relevant Securonix detection policies
- EDR-ALL-925-RU
- EDR-ALL-81-ER
- WEB-ALL-819-RU
- PXY-ALL-930-RU
- EDR-ALL-1137-RU
- EDR-ALL-1136-RU
MITRE ATT&CK
| Tactic | Technique |
| Initial Access | T1190: Exploit Public-Facing Application |
| Persistence | T1505.003: Server Software Component: Web Shell |
| Execution | T1059.001: Command and Scripting Interpreter: PowerShell |
References:
- Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
- What is w3wp.exe? Learn the Basics About IIS Worker Processes https://stackify.com/w3wp-exe-iis-worker-process/
- ProxyNotShell — the story of the claimed zero days in Microsoft Exchange https://doublepulsar.com/proxynotshell-the-story-of-the-claimed-zero-day-in-microsoft-exchange-5c63d963a9e9
- NEW ATTACK CAMPAIGN UTILIZED A NEW 0-DAY RCE VULNERABILITY ON MICROSOFT EXCHANGE SERVER https://www.gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html
- ProxyNotShell – Two Critical Vulnerabilities Affecting MS Exchange https://www.cybereason.com/blog/threat-alert-proxynotshell-two-critical-vulnerabilities-affecting-ms-exchange
- Microsoft: Exchange Emergency Mitigation (EM) service
https://learn.microsoft.com/en-us/exchange/exchange-emergency-mitigation-service?view=exchserver-2019
