Microsoft Exchange server exploitation: how to detect, mitigate, and stay calm

Multiple activity clusters

As we’ve begun analyzing the flurry of web shells stemming from suspected Exchange exploitation, we’ve noticed a few clusters of activity based on different TTPs and web shell names. Because none of these clusters overlap significantly with what Microsoft reported on as HAFNIUM, we are tracking them separately. We don’t know who is behind these clusters—we aren’t sure if it’s the same adversaries working together or different adversaries completely. We’re focusing narrowly on what we observe on victim servers for our clustering.

Other organizations are tracking different clusters as well. FireEye shared information about three “UNC” (uncategorized) clusters, and Unit 42 shared analysis of different patterns they have observed in recent China Chopper web shells. Because each organization has different visibility and methodology, it makes sense for everyone to track their own clusters to meet their team’s requirements.

The initial “random-eight-character” China Chopper cluster

From February 27 through at least March 3, we noticed a cluster of activity in which the China Chopper web shell was dropped onto Exchange servers in the directory `C:\inetpub\wwwroot\aspnet_client\system_web`. The web shell `.aspx` files would be named with eight random alphanumeric characters, for example:

Following the web shell file being dropped, we then observed follow-on activity that occurred some time between a few hours and a few days later. Though the exact eight-character web shell filename differed, the following commands were consistent across multiple victims:

The string &echo [S]&cd&echo [E] appears to be unique to the China Chopper web shell, based on previous research from FireEye and others.

Sapphire Pigeon

On March 5, we noticed a unique cluster of activity across multiple environments that didn’t match what we had we had previously seen—either in our own detections or in public reporting around these incidents. Since we use colors and birds for our activity clusters, we named this one “Sapphire Pigeon.”

This Sapphire Pigeon cluster also started with likely China Chopper web shells, but the filenames were not eight random characters. Adding to the complexity, we observed adversaries dropping multiple web shells on some victims, including the following filenames (note that these are not unique to the Sapphire Pigeon cluster on their own):

Interestingly, these shells were dropped on victims at different times, some days before we observed any follow-on activity. We have seen these same web shell names show up on many other machines in the absence of other Sapphire Pigeon indicators, so we’ve determined that these filenames alone are not sufficient to distinguish distinct clusters.

However, we observed unique follow-on activity after the web shells were dropped that we decided were useful for clustering. Sapphire Pigeon exhibited the following unique patterns, which we tweeted about on afternoon of March 5:

• Use of encoded PowerShell to connect to a remote host. powershell.exe was a child of cmd.exe, which spawned from w3wp.exe. (Check out the detection opportunities section below!)

• Creation of a scheduled task named Winnet:

Sapphire Pigeon activity overlaps significantly with activity reported by Carbon Black TAU in July 2019, including use of the domains p.estonine[.]com and cdn.chatcdn[.]net as well as the scheduled task name Winnet. However, unlike what Carbon Black previously observed, we did not observe DLTMiner being dropped as a follow-on payload. Huntress Labs also observed similar activity. In their analysis of follow-on payloads, they identified highly obfuscated PowerShell as well as Mimikatz, but there has been no indication of DLTMiner being delivered.

Other activity that didn’t cluster

We’ve also seen other web shell activity that we haven’t clearly been able to cluster. We want to have significant overlaps on multiple unique data points to cluster activity, and in some cases, we don’t have that. We don’t consider the following web shell filenames unique enough on their own to cluster with anything else right now, though we will likely identify new clusters over time. Here are a few of the many web shell names we’ve seen for reference (it appears the web shell names change frequently, so we don’t recommend relying solely on these—more durable detection opportunities are below!):

Detection opportunities

Given our endpoint-centric visibility, it’s difficult for us to determine without doubt the initial infection vector for all recent intrusions targeting Exchange servers. However, we’ve been able to consistently detect the abnormally high volumes of web shell activity over the last week or so with just a handful of detection analytics. The analytics are useful across the activity clusters described above, and we developed most of them prior to the start of this Exchange server exploitation activity, so these should be useful beyond just this activity.

IIS worker process spawning cmd.exe and net.exe

This first detection opportunity identifies instances of the Windows IIS worker process (w3wp.exe) spawning the Windows Command Processor (cmd.exe) and using net commands for initial reconnaissance purposes. You can detect this by looking for a process that appears to be w3wp.exe spawning a process that appears to be cmd.exe, which then spawns a process that appears to be net.exe. Looking for this process lineage is helpful because we have observed the specific net commands can differ from one victim to the next.

IIS worker process spawning cmd.exe with echo

A similar analytic that’s been helpful in detecting web shells is one that identifies a chain of execution from a Windows IIS worker process (w3wp.exe) spawning the Command Processor (cmd.exe) and using the echo command to send data back to a web shell. You can alert on this activity by looking for a process that is w3wp.exe spawning cmd.exe in tandem with a command line that includes the term echo. As noted above, the string &echo [S]&cd&echo [E] appears to be unique to China Chopper.

IIS worker process writing .asp and .aspx files

Another solid behavioral analytic looks for instances of the Windows IIS worker process (`w3wp.exe`) writing files that are typically associated with executable web server code to disk. Of all the detection ideas here, this one might be the most likely to generate false positives, so be prepared to tune this as needed. Narrowing down file paths where these files are written is a useful way to help refine this analytic. You can detect these behaviors by looking for the execution of a process that appears to be `w3wp.exe` along with the creation of files with webfile extensions like `.asp` and `.aspx` in any of the following file paths:

• inetpub\wwwroot\aspnet_client
• FrontEnd\HttpProxy\owa\auth

We recommend this approach to look for web shell files because we’ve observed that so many different web shell file names have been used. These two file paths are the most common ones we have observed, so we want to focus on those for simplicity’s sake, though other file paths are used as well. Check out the resources linked at the end of this for additional file paths other teams have observed.

IIS worker process spawning cmd.exe and powershell.exe

We now move on to detection opportunities for post-exploitation behavior we’ve observed after the initial web shells being dropped. In our Sapphire Pigeon cluster, we observed the adversary leveraging the IIS Worker process (w3wp.exe) to spawn the Command Processor in a manner that’s consistent with web shell activity. You can detect this activity by monitoring for a chain of process executions from a Windows IIS worker process (w3wp.exe) that spawns a process that appears to be the command processor (cmd.exe), which, in turn, launches PowerShell (powershell.exe or pwsh.exe). The following image shows activity we’ve observed with the cluster we call Sapphire Pigeon, but this analytic could help detect other malicious behavior as well:

Scheduled task execution with create and powershell

One detection opportunity is to alert on a process that appears to be schtask.exe executing with a corresponding command line that includes create and powershell. The following image shows Sapphire Pigeon activity, but this analytic is useful beyond detecting just that cluster:

Additional post-exploitation detection opportunities

While we wanted to focus detection opportunities on what we have observed recently, there are a wealth of other opportunities to detect any follow-on post-exploitation activity that might occur after these web shells are dropped. For more opportunities, check out the 2020 Threat Detection Report, this blog post, or the many excellent resources from other teams at the end of this post.