In the first blog of the series, we discussed in-depth details about CVE-2021-26855, which is an unauthenticated Server Side Request Forgery (SSRF) in the Microsoft Exchange Server. In this blog, we will take a look at CVE-2021-27065 and DearCry ransomware.


This is a post-auth, arbitrary file write vulnerability in the Exchange Server. An adversary can exploit this vulnerability and write or overwrite arbitrary files in the system. Since this is a post-auth vulnerability, the adversary should be authenticated as an user to abuse the same. 

Let’s look at the vulnerability details and link the SSRF vulnerability with this and create a perfect Remote Code Execution (RCE). We’ll be discussing CVE-2021-27065 for arbitrary file-write.

IReferences [1] and [2] mentioned at the end of the blog point towards the DDI service and try to modify an object’s Offline Address Book (OAB) Virtual Directories in the Exchange Server. They seem to be using an Exchange Server powershell (exchange management shell) for setting an object. In-the-wild exploitation logs in [2] clearly point to the vulnerability location. Refer [10] for more information about the logs.

Now, Here’s the flow to exploit this

  1. Elevate account privileges to admin level
  2. Set the external URL in the OAB Virtual Directory (add webshell here)
  3. Reset the external URL (add path here)

While setting the external URL, the server checks only for the schema, hostname and length of the URL (<256 bytes). so, we satisfied those checks by providing just that and appending our payload to it.

Figure 1: Changing External URL in OAB Virtual Directory

Now, when we reset the OAB Virtual Directory, the existing virtual directory will be deleted and a new virtual directory in the path specified by us will get created with all the properties of the directory and with the extension we prefer.

Figure 2: Resetting OAB Virtual Directory to a New Path 

Now, our payload is present inside this file with .aspx at an accessible location. So, when we execute this file, our payload gets executed. In a typical webshell.we can pass a command/function as parameter that executes the value on the system (like eval).

This looks easy in theory, but how do we link this to SSRF vulnerability and remotely exploit both of the vulnerabilities to achieve RCE?

Below are the steps involved to do that

  1. Retrieve LegacyDN through SSRF endpoint
  2. Use LegacyDN and pull the SID of admin
  3. Authenitcate with proxyLogon and retrieve sessionID and msExchEcpCanary cookie (using SSRF)
  4. Use the cookies to hit the DDI service and request for the OAB Virtual Directory. Retrieve OAB ID 
  5. Use the OAB ID and session cookies to inject webshell in the external URL
  6. Use the same session cookies and OAB ID to reset the virtual directory and include our path
  7. The path is then used to execute the webshell
Figure 3: Retrieving Server Name through SSRF (front-end proxy)

Retrieve the FQDN from the header

Figure 4: Exchange Server Info through autodiscover endpoint (front-end proxy)

Using FQDN, retrieve the LegacyDN through autodiscover endpoint

Figure 5: Retrieving Admin SID through legacyDN (backend)

Use LegacyDN to retrieve the SID of the admin.

We get an error message while trying to access OAB objects using the DDI service as shown in Figure 6.

Figure 6: Attempting to Access OAB Virtual Directory Objects

Error: The user isn’t assigned to any management roles. 

But, the same user is able to change the OABvirtualdirectory manually. Strange !!

This is the interesting part of the exploit. The /ecp endpoint (frontend proxy) allows arbitrary requests through SSRF and all the requests that are sent with X-BEResource cookie may not grant authenticated access to the entire application.

So, there is another vulnerable endpoint “/ecp/proxylogon.ecp” which lets us authenticate using a legit SID. We’ll have to bypass authentication using proxylogon and use the session to proceed further.

RbacSettings class in Microsoft.Exchange.Management.ControlPanel deals with authentication in HTTPproxy.

Figure 7: Authentication Mechanism at proxylogon endpoint

It expects additional headers and XML body for authentication.The body of the request will go into the SerializedAccessToken().

The header “msExchLogonMailbox” will be used to check for authentication and for creating new ECP identity. After parsing the headers, the code calls for authenticating the mentioned header for identity in GetInBoundProxyCaller().

Figure 8: Authentication Check for the Mentioned Security Identifier (SID) 

The code looks up the SID we have mentioned, through FindComputerBySid(). Upon meeting all the requirements, it will return the server name. 

From Figure 7, once the authentication is done, the code creates ECP identity and assigns cookies.

Figure 9: Adding New Cookies to the Response Header after Authentication
Figure 10: Cookie name for the Session in the Exchange Server

Now, authenticate using the Admin SID and retrieve ASP.NET_SessionId and MsExchEcpCanary cookies.

Figure 11: Authenticating using proxylogon with a legit SID

Retrieve these two cookies and hit GetObject in DDIService and retrieve rawIdentity (i.e., OAB ID).

Figure 12: Accessing OAB Virtual Directory Objects using Earlier Session Cookies

Now, using the OAB RawIdentity, we can change any object.

Using these three values, the externalURL for the OABvirtualdirectory is changed to our payload.

As discussed earlier, there are limited checks on externalURL. So, we’ll append our payload (total length <256 bytes) to a URL which follows the correct schema.

Figure 13:  Changing ExternalUrl in OAB Virtual Directory to our Payload
Figure 14: Updated External URL in the OAB Virtual Directory Configuration

Now, reset the OABvirtualdirectory. A new file gets created in the path and extension we mentioned. Our payload gets triggered when accessed as we injected Jscript payload in the external URL and our current file has an extension of .aspx.

So, let’s write the file where we can access via the network.

Figure 15: Resetting the OAB Virtual Directory and Creating it at a New Path

Here it is, 

Figure 16: New webshell ‘pop.aspx’ Created at the Mentioned Path
Figure 17: Accessing the New webshell Directly

These are properties of OABvirtualdirectory written into a different file at a different path and reloaded with the updated externalURL.

The file also has code, as we can see that it is in script tags.

Now, we can execute commands on the system when passed to the endpoint with exec_code parameter.

Figure 18: Executing System Commands through the webshell

This is a persistent webshell.


This is the check in WriteFileActivity class in DDI namespace.

Figure 19: Extension Checking of OAB Virtual Directory Properties while Resetting
Figure 20: Forcing the extension to .txt by resetting OAB Virtual Directory

This patch forces the written file to be of type .txt thus, preventing web shells.


This is an insecure de-serialization vulnerability in Unified Messaging Service (UMS). UMS is a component of the Exchange Server that deals with voice-related features. UMS enables users to use voice mail, call answering rules and show both voice and email message in one mailbox.

This vulnerability can only be exploited when UMS is enabled, which is not enabled by default in the Exchange Server. 

What is Insecure De-Serialization ?

Serialization is a process of converting objects and their fields into byte streams for writing/reading into a file or database. De-serialization is exactly the reverse of that. It restores the object from the stream of bytes. Web applications logic interacts with the stream of bytes while converting it to the object.

The adversaries can send manipulated objects to serialize which when de-serialized results in unexpected behaviour. This is often used to elevate privileges.

Figure 21: Serialization and Deserialization Workings

This vulnerability can also be used to elevate privileges of a limited user in the attack chain before exploiting the arbitrary file write. But, RCE can be achieved without exploiting this as well.

Let’s look at some file-diffs in Unified message dlls and see where the vulnerability is lying. 

Figure 22: Patch Code for Catching Exploitation of the Unsafe Function ‘BaseDeserializearray()’

The unsafe Base64Deserialize() is replaced with DeserializeObject(). The patch reconstructs the original function into multiple steps. First, by converting the data from base64 to memory stream and then, converting the serialized object data using DeserializeObject. Also, several exceptions are added to handle InsecureDeserialization vulnerability.


At the time of writing this blog, there were around 60,000 publicly exposed vulnerable Microsoft Exchange servers.

Figure 23: Shodan Stats for the Exchange Server Vulnerability

Post Exploitation

In the initial days, we have seen evidence of webshells and exporting mail information using Powercat, Nishang, etc.

Downloading Powercat 

Figure 24: Powercat commands found in in-the-wild exploitation

Using Nishang for reverse shell

Figure 25: Usage of Nishang for reverse shell and C&C found in in-the-wild exploitation (Image courtesy of Microsoft)

Soon after that, there were reports of malware authors exploiting 0-day Exchange Server vulnerabilities and dropping a ransomware post-exploitation. On 13th March, we saw the first  ransomware which is dubbed as DearCry exploited in the wild. Let’s look at the details of the ransomware.


Since the release of the OOB patch in March 1st week, a lot has been reported about DearCry ransomware, which was downloaded and executed on Exchange Servers, post-exploitation of the vulnerabilities discussed in the blog.  Here, we will discuss some basic working of the malware to aid the understanding of our readers. 

Ransomware begins its execution with calls to function that use anti-analysis techniques to check for the presence of debuggers.

Figure 26: Calls to Functions that Identify the Analysis Environment

If no debugger is present, the entry function then calls another function (renamed to main() in Figure 27), which uses StartServiceCtrlDispatcherA() to register ‘msupdate’ service. This might allow ransomware to maintain persistence on the system. StartServiceCtrlhandlerA() is used to set and update service status.

Figure 27: Call Graph in the DearCry Binary

Both main() and handler function, call Ransomware_Encryption() to encrypt the files as shown in Figure 27.

Ransomware has RSA Public Key hardcoded in the binary (Figure 28). The presence of AES related strings suggest that AES symmetric encryption algorithm is used to encrypt the files, and PKI, RSA (asymmetric encryption algorithm) is used to encrypt the symmetric key for AES.

Figure 28: RSA Public Key Hardcoded in the DearCry Binary
Figure 29: Strings Suggesting the Use of AES Encryption Algorithm

Ransomware enumerates the files using FindFirstFileA() and FindNextFileA() Windows APIs to identify interesting files and encrypt them.

Figure 30: Function to Traverse Directory

It identifies files with extensions shown in Figure 31 and encrypts and saves them with new extension ‘.CRYPT’.

Figure 31: File Extensions targeted by DearCry

Hex dump of an encrypted file header shows that the header starts with string ‘DEARCRY!’.  

Figure 32: File Header in the Encrypted File

The ransomware adds a ransom note along with threat actors’ contact address. The ransom note is shown below.

Figure 33: Ransom note on the Infected System

While we were working on this blog, there were already multiple reports of threat actors exploiting these vulnerabilities to gain access to the server.


  • Use VPN or limit access to your Exchange Server by placing it behind a firewall in your internal network. Also, do not expose your Exchange Server to the internet unless absolutely necessary
  • Turn on your firewall at all times
  • Avoid using the administrator account as the main account on critical machines
  • Ensure your systems are up-to-date for OS patches
  • Use a reputed security product like K7 Endpoint Security and K7 Total Security to stay protected from the latest threats


  • Install the patches if you haven’t already, from Microsoft here
  • Investigate your server for IOCs and exploitation
  • If you’d like to scan your servers for the vulnerability, microsoft has released an nmap script to detect any vulnerable exchange servers in your network : 
  • Disable Unified Messaging service, if not in use
  • Disable OAB Virtual Directory, if not in use

We at K7 Computing constantly monitor for such malware and vulnerabilities and ensure that we provide proactive protection against such attacks. Also our Generic Anti-Ransomware feature in our security product flags it before the ransomware can execute. As always, we recommend our customers to use the K7 security products to protect their data and keep it updated to stay protected from the latest threats. 

Indicators Of Compromise (IOCs)

  1. By Volexity
  • S:CMD=Set-OabVirtualDirectory.ExternalUrl=’
  • /ecp/DDI/DDIService.svc/SetObject
  1. Logs of in-the-wild exploitation, reported by Crowdstrike
  • /ecp/DDI/DDIservice.svc/SetObject?msExchEcpCanary=<redacted>&schema=ResetOABVirtualDirectory#
  • /ecp/DDI/DDIservice.svc/SetObject?msExchEcpCanary=<redacted>&schema=OABVirtualDirectory#
  1. Hashes of malicious files identified on compromised systems                                                       
File NameHashK7 Detection Name
1.exe10bce0ff6597f347c3cca8363b7c81a8bff52d2ff81245cd1e66a6e11aeb25daTrojan ( 005790de1 ) 
2b9.exe2b9838da7edb0decd32b086e47a31e8f5733b5981ad8247a2f9508e232589bffTrojan ( 005790de1 ) 
e044.exee044d9f2d0f1260c3f4a543a1e67f33fcac265be114a1b135fd575b860d2b8c6Trojan ( 005790ee1 ) 

Further Readings 


Like what you're reading? Subscribe to our top stories.

If you want to subscribe to our monthly newsletter, please submit the form below.

    0 replies on “Looters in the Wild, Patch your Exchange (Part 2)”