Chris Stegh / / Categories: Microsoft Exchange Hybrid

Patch, then Pursue Hybrid Exchange Vulns

By now you've patched your Exchange Servers to mitigate the vulnerabilities exposed on 3/2/21. Now it's time to shut the back door that might have been set up before the patch. The backdoor has been known to allow adversaries to perform web shell implantation, code execution, and data exfiltration. Microsoft warned that their patches “are not a remediation if your Exchange servers have already been compromised, nor are they full protection against attack.” In other words, keep hunting!

Unfortunately, even organizations that have moved their Exchange mailboxes to Office 365 are not immune from this threat. In almost every case, there still is a hybrid Exchange Server on premises, brokering on-premises Active Directory identities with Exchange Online. See more for the need for this server below. Even though this server isn’t hosting mail and isn’t in the mail routing path, it is still vulnerable.

To determine if the backdoor was created, Microsoft recently published a script to determine if a server has been compromised. Test-ProxyLogon.Ps1 checks targeted Exchange Servers for signs of the proxy logon compromise. Proxy logon vulnerabilities are described in CVE-2021-26855, 26858, 26857, and 27065. This script is intended to be run via an elevated Exchange Management Shell.

Active exploitations of CVE-2021-26855 (ProxyLogon) have occurred since early January. So, if your server logs are not retained for more than the past two months, Test-ProxyLogon.Ps1 may miss potential indicators of compromise. Also, non-Exchange servers that may have been accessed are not checked by the script.

Hunting for Indicators of Compromise

For both cases, it’s necessary to hunt using other means. What to look for? Indicators of Compromise, typically a specific file, IP, URL, domain, etc. that is a known malicious entity or compromise. Microsoft published a list of IOCs, showing the malware hashes that have been deployed and the files that have been altered in known compromises. The list of hashes and files to look for are posted at https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/Sample%20Data/Feeds/MSTICIoCs-ExchangeServerVulnerabilitiesDisclosedMarch2021.csv

Just having a list of IOCs isn’t very helpful. You could manually search the C:\ of your Windows Servers for these files, but the cows will come home before that job is done. To scale, the IOCs must be imported into a Threat Intelligence solution to search to see if any of those indicators exist in your environment.

For instance, Azure Sentinel can import IOCs. Then you can use Sentinel’s Queries and Analytics to search activity in your systems: See Threat indicators for cyber threat intelligence in Azure Sentinel - Azure Example Scenarios | Microsoft Docs

Breaking down that list of compromises, the first 8 of 9 lines show hashes such as

2020-03-09,2021-01-24T12:59:40.6969216Z,65149e036fff06026d80ac9ad4d156332822dc93142cf1a122b1841ec8de34b5

which can be imported to scan for malware that is already present.

Later in the list, filenames such as:

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\logg.aspx,filepath,White

show files that have been known to be altered as an outcome of this vulnerability. Scanning for the presence of (or changes to) that list of files in your environment is necessary.

Defender for Endpoint also has a section to configure Indicators to block, allow, and/or alert. See Create indicators - Windows security | Microsoft Docs.

Aside from Advanced Hunting, What can be Done?

If you have confirmed that initial exploitation took place against an on-premises Exchange Server, Microsoft recommends that these factors should be evaluated:

  • Have any modified or created files, such as web shells and reverse shells, been identified and removed?
  • Did credential exfiltration take place? If so, account passwords may be compromised.
  • If network logs exist, check for abnormal amounts of network traffic from affected servers to abnormal sites.
  • Did lateral movement take place to move from the affected Exchange Server instance to elsewhere in the environment?

Trend Micro’s best practices for situations like this include monitoring for:

  • Unusual traffic going in and out of the network
  • Unknown files, applications, and processes in the system
  • Suspicious activity in administrator or privileged accounts
  • Irregular activities such as traffic in countries an organization doesn’t do business with
  • Dubious log-ins, access, and other network activities that indicate probing or brute force attacks
  • Anomalous spikes of requests and read volume in company files
  • Network traffic that traverses in unusually used ports
  • Tampered file, Domain Name Servers (DNS) and registry configurations as well as changes in system settings, including those in mobile devices
  • Large amounts of compressed files and data unexplainably found in locations where they shouldn’t be

An Exchange Server… but We're on Exchange Online?

As mentioned, even organizations whose mail is online very likely have an Exchange server on-premises. According to Microsoft, “Customers with a hybrid configuration often find after a period of time that all of their mailboxes have been moved to Exchange Online. At this point, they may decide to remove the Exchange servers from on-premises. However, they discover that they can no longer manage their cloud mailboxes.

When directory synchronization is enabled for a tenant and a user is synchronized from on-premises, most of the attributes cannot be managed from Exchange Online and must be managed from on-premises. This is not due to the hybrid configuration, but it occurs because of directory synchronization. In addition, even if you have directory synchronization in place without running the Hybrid Configuration Wizard, you still cannot manage most of the recipient tasks from the cloud. For more information, see this blog article.” There is a sliver-lined hope that this attack may hasten a final solution from Microsoft for this necessity.

 

Background of the Exploit

The exploit provides the ability to read all email and easy access to the victim organization’s other computers. The exploit has been attributed to HAFNIUM, a cyber espionage group, sometimes known as an advanced persistent threat, with alleged ties to China. They’ve created a unique vulnerability. Most zero-day attacks (for which there is no known vulnerability nor fix) are stealthy and directed at a valuable target. Zero days usually allow an adversary to compromise their target’s most valuable identities, data, or services, without a big splash. This time, it was anything but stealthy.

The vulnerabilities include:

  • CVE-2021-26855 is a server-side request forgery (SSRF) vulnerability in Exchange Server that allowed the threat actor to send arbitrary HTTP requests and authenticate as the Exchange Server computer account. This is an authentication bypass that affects Microsoft Exchange Server 2013, Exchange Server 2016, and Exchange Server 2019.
  • CVE-2021-26858 is a post-authentication file-write vulnerability in Exchange Server that can be combined with CVE-2021-26855 to elevate privileges. This allowed the threat actor to write web shells to the Exchange servers, which can later be leveraged for code execution. This vulnerability affects Microsoft Exchange Server 2013, Exchange Server 2016, and Exchange Server 2019.
  • CVE-2021-26857 is an insecure deserialization vulnerability. Exploiting this vulnerability gave the threat actor the ability to run code as SYSTEM on devices running Exchange Server. Exploiting this vulnerability required administrator permissions or another vulnerability, such as CVE-2021-26855, to exploit. This affects Microsoft Exchange Server 2010, Exchange Server 2013, and Exchange Server 2016.
  • CVE-2021-27065 is a post-authentication file-write vulnerability that can be combined with CVE-2021-26855 to elevate privileges. This affects Microsoft Exchange Server 2013, Exchange Server 2016, and Exchange Server 2019.

Organizations that have had these vulnerabilities exploited in their environment prior to installing the security updates should keep in mind that attackers could persist through web shells and other tools. These attack tools must be identified and removed from all affected devices. Additionally, credentials might have been accessed and compromised prior to the installation of security updates.

These vulnerabilities can be chained together to allow unauthenticated remote code execution on devices running Exchange Server. Microsoft has also observed subsequent web shell implantation, code execution, and data exfiltration activities during the attacks. This threat might be exacerbated by the fact that numerous organizations publish Exchange Server deployments to the public Internet to support mobile and work-from-home scenarios.

Attackers can perform various activities as shown in the diagram below (per Microsoft):

Exploitation, code execution, data exfiltration, and other attack activities during known attacks involving the Exchange Server vulnerabilities

Summary

The news about HAFNIUM was anything but stealthy. On the contrary, over 30,000 organizations are impacted, not only by the creator of the attack, but by opportunistic attackers worldwide.

To ensure you’re not a statistic on this list, take this short list of steps above, validate them against Microsoft and CISA’s recommendations, and keep hunting.

Work with our team of Cloud Computing Consultants who have done this so many times they know all of the “minefields” to prevent missteps.

Subscribe to Email Updates

Refine by

To expand the list, please click on the double arrows.

 

Search by Category or Author:

ref:_00D80KtFf._5000y1WwWQD:ref