This post is also available in: 日本語 (Japanese)

Executive Summary

On Dec. 20, 2022, CrowdStrike published a blog discussing a new exploit method for Microsoft Exchange Server, which they named OWASSRF, referring to server-side request forgery in relation to Outlook on the web. (Outlook on the web is known as both Outlook Web Access and Outlook Web Application.)

The OWASSRF exploit method involves two different vulnerabilities tracked by CVE-2022-41080 and CVE-2022-41082 that allow remote code execution (RCE) via Outlook Web Access (OWA). The CVE-2022-41082 vulnerability was previously used by the ProxyNotShell exploit. However, the OWASSRF exploit method bypasses mitigations previously provided by Microsoft for ProxyNotShell. OWASSRF requires authentication to the Exchange Server prior to exploitation, thus we are seeing isolated rather than mass exploitation attempts.

Unit 42 observed that active exploitation of the OWASSRF vulnerability was occurring in late November and early December 2022.

Unit 42 did observe threat actor activity exploiting these vulnerabilities, in which the actor used a PowerShell-based backdoor that we are tracking as SilverArrow to run commands on the Exchange Server. The actors ran commands to do the following:

  • Create an administrator account
  • Install the AnyDesk remote desktop application
  • Create an SSH tunnel using PuTTY Link to remotely access Windows Remote Desktop Protocol (RDP)
  • Dump memory of the LSASS process to harvest credentials

Our Cortex XDR customers were protected against the RCE portion of the OWASSRF vulnerability, as XDR prevented the PowerShell scripts from running in the event of exploitation.

Palo Alto Networks customers receive protections through a variety of products and services, including the following:

Vulnerabilities Discussed CVE-2022-41080, CVE-2022-41082

Details of OWASSRF

On Dec. 20, 2022, CrowdStrike published a blog discussing a new exploit method for Microsoft Exchange Server, which they named OWASSRF. The exploit method involves two different vulnerabilities tracked by CVE-2022-41080 and CVE-2022-41082 that allow remote code execution (RCE) via Outlook Web Access (OWA). The CVE-2022-41082 vulnerability was previously used by the ProxyNotShell exploit, however, the OWASSRF exploit method bypasses mitigations previously provided by Microsoft for ProxyNotShell.

Both ProxyNotShell and OWASSRF use a server side request forgery (SSRF) vulnerability. However, the ProxyNotShell method used an AutoDiscover endpoint to exploit CVE-2022-41040, while OWASSRF uses the OWA frontend endpoint to exploit CVE-2022-41080. Much like ProxyNotShell, the newly found exploit method requires the actor to be authenticated to the server prior to exploitation.

According to a tweet by @Purp1eW0lf on Dec. 14, 2022, actors exploiting the OWASSRF vulnerability left an open directory on their web server that contains several of their tools, including the Python script that contains code to exploit OWASSRF. Additionally, the open directory included a readme file. Its contents (see Figure 1) describe how to use the script to exploit ProxyNotShell, and also suggest that this was developed specifically to bypass hotfixes for the ProxyNotShell vulnerability.

Image 1 is a screenshot showing the readme.txt of the threat actors' open directly. It contains instructions for the exploit code exploiting OWASSRF.
Figure 1. readme.txt on actors' open directory that contains usage for the exploit code that exploits OWASSRF

Using the code found in this open directory, we were able to better understand how this exploit works. After successfully authenticating to the Exchange Server, the exploit code will issue POST requests to /owa/mastermailbox%40outlook.com/powershell as seen in Figure 2, which is the same URL structure mentioned in CrowdStrike’s OWASSRF blog.

The POST request also includes a header X-OWA-ExplicitLogonUser that has a value of owa/mastermailbox@outlook[.]com. The header value is removed from the URL during processing. The change in the URL is likely the cause of the server side request forgery tracked in CVE-2022-41080.

It should be noted that this traffic would occur over HTTPS so the POST request would be within an encrypted session. Also, we determined that the email address does not necessarily have to be mastermailbox@outlook[.]com, as any email address would suffice.

Image 2 is a screenshot of showing the OWASSRF exploit scripts initial POST request.
Figure 2. Initial POST request to Exchange Server from OWASSRF exploit script.

After exploitation, the exploit code will run supplied PowerShell in the form of a base64-encoded string. The exploit code replaces $$POWERSHELL_ENCODE_PAYLOAD_HERE$$ in the XML seen in Figure 3 with the base64-encoded PowerShell and will send this XML to the Exchange Server to run.

Image 3 is a screenshot of message data sent to the Microsoft Exchange server to run encoded PowerShell. Highlighted are the argument and the filename.
Figure 3. Message data sent to an Exchange Server to run encoded PowerShell after exploiting OWASSRF.

Current Scope of the Attack

At the time of writing, Unit 42 is aware of eight organizations that have seen exploitation activity. In exploit attempts we observed on Dec. 2 and 3, the actors attempted to run PowerShell that was base64-encoded, as seen in Figure 4. The decoded PowerShell code is a backdoor that we are tracking as SilverArrow.

Image 4 is a screenshot showing an example encoded PowerShell script seen in OWASSRF exploit attempts.
Figure 4. Example of the encoded PowerShell script seen in OWASSRF exploit attempts in early December 2022.

The SilverArrow backdoor – decoded from what is seen in Figure 5 – is effectively a remote shell. It connects to a remote server (0xd8809226 or 216.128.146[.]38 in this specific case) and enters a loop to receive additional PowerShell commands that it will run and then respond to the server with the result. This particular remote shell provides the actors with a shell prompt of SL>, which is the basis of the name SilverArrow.

Image 5 is a screenshot of many lines of code showing the decoded PowerShell script delivered by OWASSRF exploit attempts.
Figure 5. Decoded PowerShell script delivered in OWASSRF exploit attempts in early December 2022.

All OWASSRF exploit attempts observed by Unit 42 have resulted in the same PowerShell backdoor. We have observed the following IP addresses used as command and control (C2) servers for these backdoors:

  • 216.128.146[.]38
  • 95.179.162[.]125
  • 192.248.176[.]138
  • 140.82.52[.]35
  • 45.32.144[.]71

Several of our XDR customers experienced exploit attempts, in which the post-exploitation PowerShell activity was prevented (see Figure 6). The prevention of the PowerShell code from executing blocked the threat actors from carrying out any post-exploitation activities.

Image 6 is a screenshot of the Cortex XDR program showing prevented PowerShell activity. It details alerts and what processes were terminated.
Figure 6. PowerShell activity prevented by Cortex XDR after OWASSRF exploitation.

Unfortunately, one Exchange Server did not have XDR in blocking mode and the OWASSRF exploit was successful on Nov. 28, 2022, which resulted in the execution of PowerShell code. After exploitation, the threat actors used PowerShell to run several commands. The threat actors used the whoami command, created a user named Admon and added the Admon user to the local administrators and remote desktop users groups (see Figure 7).

The actors also downloaded PuTTY Link (pta.exe) and the AnyDesk remote desktop application to the server, the latter of which the actors installed to start up with Windows to persist reboots. The actors used PuTTY Link to create an SSH tunnel to 217.69.10[.]255 to be able to access RDP on the local server, which further shows the threat actors’ interest in using remote desktop tools to interact with the compromised server. We are also aware of the threat actors creating SSH tunnels to the IP address 45.76.246[.]112.

Image 7 is a screenshot of the Cortex XDR program showing a tree diagram where the threat actor activity is displayed post-exploitation of the PowerShell activity.
Figure 7. PowerShell activity post-exploitation showing threat actor activity.

Shortly after the activity seen in Figure 7, the threat actors used their newly created Admon user account and their remote desktop access to dump the memory of the LSASS process. The actor used the legitimate Task Manager application in Windows to dump the LSASS process memory, as seen in Figure 8. We believe the threat actors dumped the LSASS memory and exfiltrated the dump file to extract credentials rather than doing so locally on the server, as we saw no processing of the dump file on the server.

Image 8 is a screenshot of the Cortex XDR program showing an alert where the threat actor used Task Manager to dump LSASS memory for credential gathering.
Figure 8. Threat actor using Task Manager to dump the memory of LSASS for credential gathering.

Interim Guidance

Unit 42 recommends customers apply the Nov. 8, 2022, security update to their Exchange Servers. Palo Alto Networks Cortex XDR protected customers from the payloads deployed by this exploit using the Anti Webshell Protection module and behavioral threat protection.

Unit 42 Managed Threat Hunting Queries

The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit these CVEs across our customers, using Cortex XDR and the XQL queries below. Cortex XDR customers can also use these XQL queries to search for signs of exploitation.

Conclusion

Unit 42 observed active exploitation of the OWASSRF method in the wild via the exploitation of CVE-2022-41080 and CVE-2022-41082. We are not seeing mass exploitation attempts of OWASSRF as it requires authentication to the Exchange Server. We saw isolated OWASSRF attempts to exploit Exchange Server in which the threat actors likely used credentials previously stolen by unknown means.

In known successful exploitation attempts, the threat actors used PowerShell to run additional commands to gain remote desktop access to the Exchange Server. This involved the creation of a new administrator account, the creation of an SSH tunnel using PuTTY Link to access Windows Remote Desktop and the installation of the AnyDesk application. The actors used these remote desktop tools to gather credentials, but we are unsure of the actors’ goals as the server was quickly mitigated.

Due to the availability of a proof-of-concept exploit script for the OWASSRF method, Palo Alto Networks highly recommends applying Microsoft’s Nov. 8, 2022, security update to your Exchange Servers to mitigate this vulnerability. Palo Alto Networks and Unit 42 will continue to monitor the situation for updated information, release of proof-of-concept code and evidence of more widespread exploitation.

Palo Alto Networks Product Protections for OWASSRF

Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Next-Generation Firewalls and Prisma Access With Advanced Threat Prevention

Next-Generation Firewalls (PA-Series, VM-Series and CN-Series) or Prisma Access with an Advanced Threat Prevention security subscription can automatically block sessions related to CVE-2022-41080 using Threat ID 93319 (Application and Threat content update 8658).

Cloud-Delivered Security Services for the Next-Generation Firewall

Known IPs and domains associated with this malicious activity are categorized as malicious by Advanced URL Filtering and DNS Security.

Cortex XSOAR

The Cortex XSOAR playbook, “CVE-2022-41040 & CVE-2022-41082 - ProxyNotShell,” was updated with more hunting, remediation and mitigation tasks to identify and respond to exploitation attempts. This playbook is part of the Rapid Response Pack, which includes various playbooks for trending vulnerabilities and threats and is available on Cortex Marketplace.

Cortex XDR

Cortex XDR Agent protected customers from the payloads deployed by this exploit using the Anti Webshell Protection module and behavioral threat protection.

Cortex XDR Agent running on version 7.8 and above with content version 810-32342 and above will block the exploitation attempt of the exploitation chain that we have identified. Please make sure your agents are configured in blocking mode for Exploit Protection, behavioral threat protection and the Anti Webshell Protection module.

Prisma Cloud

Prisma Cloud has detection capabilities in place for CVE-2022-41080 and CVE-2022-41082. Prevention capabilities also exist with runtime defenses on virtual machines (VMs), serverless functions and containers performing malicious operations on vulnerable containers. Compute agents should be installed on container hosts, serverless functions and VM instances, and ensure they are configured with the latest Prisma Cloud Intelligence Stream (IS) offering and have runtime protection set to active.

Indicators of Compromise

Infrastructure

140.82.52[.]35
217.69.10[.]255
45.76.246[.]112
216.128.146[.]38
95.179.162[.]125
192.248.176[.]138
140.82.52[.]35
45.32.144[.]71

Enlarged Image