SBN

Security Advisory Regarding Exchange Marauder / HAFNIUM

Hurricane Labs is aware of the recent reports from Volexity and Microsoft regarding Operation Exchange Marauder. Microsoft refers to the threat actors utilizing these vulnerabilities as HAFNIUM. At the present time, Microsoft Exchange 2013 through 2019 have been confirmed to be vulnerable, while Microsoft Office 365 is not impacted.

The chain of vulnerabilities–CVE 2021-26855, 26857, 26858, 27065–are all related to a server-side request forgery vulnerability in Microsoft Exchange 2010 through 2019, according to the Microsoft Security Response Center.

What is a Server Side Request Forgery?

Server-Side Request Forgery (SSRF) attacks occur when there are vulnerabilities in web applications that expose access to other applications or resources unintentionally through insecure parameters. If a client/attacker can modify these parameters, they can request access to other services on the web server or those on the same local network as the web server. 

PortSwigger–known for the web application testing tool, Burp Suite–has a wonderful blog post that demonstrates the impact of SSRF vulnerabilities. 

Detection and Mitigation

The Volexity and Microsoft blog posts–as well as the updates released by Microsoft Security Response Center–contain a complete collection of both network and host indicators that can be used to detect and/or mitigate this threat. Within these posts, you will find details that can be used to detect exploitation attempts as well as post-exploitation actions the attackers have taken. 

Actions such as dropping and accessing web shells on the Exchange server for initial access, pivoting to other hosts, dumping LSASS memory and/or NTDS.dit for additional credentials as well as the multiple log files where these attacks and post-exploitation operations can be observed. 

These threat actors do not appear to be concerned with covering their tracks or maintaining quiet persistence. As a result, there are a large amount of log files that can be analyzed to detect malicious activity. 

Below is a highlight reel of things to look for and logs to enable and/or review:

Consider either deploying Microsoft Sysmon, or enabling Process Creation Auditing logs. I’ve talked at length about both Sysmon and EID4688 logs and how much of a wealth of information they are, but if resources and time are scarce, prioritize deploying and collecting Sysmon (or EID 4688) logs from your Microsoft Exchange servers. 

In particular, try looking for:

  • Instances where w3wp.exe is the parent process and generating very unusual child processes. In fact, this blog post by Microsoft demonstrates how the parent/child process relationship works as well as what attacks on exchange Servers typically look like in similar situations.
  • Use of LOLBAS, applications that are considered “admin tools,” or otherwise classified as benign such as psexec, procdump64, and 7-zip.

The Volexity blog post Identifies a whole host of HTTP user-agents associated with the threat actors for this campaign:

Copy to Clipboard

Bear in mind that changing HTTP user-agents for web requests is a trivial process. This means that these indicators alone should not be considered sole proof that an organization has been targeted by this threat group.

The Volexity blog post also identifies a whole host of HTTP URIs that are targeted by the threat actors for the exploit, initial access, as well as post-exploitation actions:

Copy to Clipboard

Consider enabling PowerShell logging–or making use of sysmon/EID4688–logs to discover instances of unusual PowerShell activity. The report cites several instances of post-exploitation activity using PowerShell:

  • Using Nishang Invoke-PowerShellTCPOneLine reverse shell
  • Downloading and executing PowerCat (a PowerShell version of Netcat)
  • Running Exchange PowerShell snap-ins to export data from user mailboxes

Review the Exchange ECP Server Logs for entries similar to the following:

Copy to Clipboard

As mentioned in the Volexity blog, these logs are typically found at [Exchange Installation Path]\Logging\ECP\Server.

The Microsoft HAFNIUM report provides a host of other Exchange server logs that can be analyzed for indicators of compromise. Check out the section, Scan Exchange log files for indicators of compromise.

Hurricane Labs’ Recommended Actions 

Hurricane Labs is committed to assisting our customers in protecting themselves as fully as possible. 

Steps we have taken to ensure customer protection

  • Hurricane Labs has gathered IP address and file hash indicators from both the Volexity and Microsoft reports for Command and Control IP addresses as well as webshells actors have been observed using. 
  • Hurricane Labs Threat Intelligence customers will automatically receive an update to their threat intelligence feeds. This update will contain both the actionable file hashes and network-based indicators.

Further recommendations

  • Per the Microsoft Security Response Center post (linked above), patches have been made available for Microsoft Exchange 2010 through Exchange 2019. As usual, patching is the ounce of prevention crucial to mitigating the threat effectively with the least amount of effort.
  • At the time of this post, a proof of concept (PoC) vulnerability has not been discovered, but the level of effort required to exploit this vulnerability appears to be very low. This means that PoC is likely to be available very soon. Therefore, patching the vulnerability before the PoC occurs is extremely important and should take a high priority.

The post Security Advisory Regarding Exchange Marauder / HAFNIUM appeared first on Hurricane Labs.

*** This is a Security Bloggers Network syndicated blog from Hurricane Labs authored by Tony Robinson. Read the original post at: https://hurricanelabs.com/security-advisory/security-advisory-regarding-exchange-marauder-hafnium/?utm_source=rss&utm_medium=rss&utm_campaign=security-advisory-regarding-exchange-marauder-hafnium