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:
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:
Details of OWASSRF
Current Scope of the Attack
Unit 42 Managed Threat Hunting Queries
Palo Alto Networks Product Protections for OWASSRF
Next-Generation Firewalls and Prisma Access With Advanced Threat Prevention
Cloud-Delivered Security Services for the Next-Generation Firewall
Indicators of Compromise
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.
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/[email protected][.]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 [email protected][.]com, as any email address would suffice.
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.
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.
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.
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:
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.
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.
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.
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.
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.
// Processes spawned by exploiting this vulnerability will have a parent process of w3wp.exe in the "MSExchangePowerShellAppPool" application pool. Review the results of this query for suspicious child processes.
config case_sensitive = false
| dataset = xdr_data
| filter event_type = ENUM.PROCESS AND event_sub_type = ENUM.PROCESS_START
| filter actor_process_image_name = "w3wp.exe" and actor_process_command_line contains "MSExchangePowerShellAppPool"
| filter action_process_image_name not in ("wermgr.exe","wmiapsrv.exe","dllhost.exe")
| fields _time, agent_id, agent_version, action_process_image_path,action_process_image_command_line,action_process_image_sha256, actor_process_command_line
// Description: In activity we observed in the wild, a w3wp.exe process belonging to the "MSExchangePowerShellAppPool" application pool spawned PowerShell one-liners with "frombase64string" in the command line.
config case_sensitive = false
| dataset = xdr_data
| filter event_type = ENUM.PROCESS AND event_sub_type = ENUM.PROCESS_START
| filter action_process_image_name = "powershell.exe" and action_process_image_command_line contains "frombase64string"
| filter (actor_process_image_name = "w3wp.exe" and actor_process_command_line contains "MSExchangePowerShellAppPool") or (causality_actor_process_image_name = "w3wp.exe" and causality_actor_process_command_line contains "MSExchangePowerShellAppPool")
| fields action_process_image_path, action_process_image_command_line , actor_process_command_line , causality_actor_process_command_line, agent_hostname
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 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:
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).
Known IPs and domains associated with this malicious activity are categorized as malicious by Advanced URL Filtering and DNS Security.
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 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 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.
Sign up to receive the latest news, cyber threat intelligence and research from us