Microsoft Exchange Server ProxyLogon and the Hafnium Attacks – Protecting Vulnerable Apps with ZTNA

Microsoft Exchange Server customers are having a rough month dealing with the new ProxyLogon exploit. An extremely aggressive and ongoing cyberattack by a Chinese espionage group dubbed “Hafnium” is targeting Microsoft Exchange servers. Hundreds of thousands of servers have been compromised. 

Microsoft Exchange is one of the most popular email applications worldwide. An estimated 43% of organizations that use Microsoft Exchange for email use Microsoft Exchange Server. Every one of these organizations who allow their users to access their Exchange application directly from the open internet has been at risk for some time. Attacks were discovered as early as January 6th, and several sources estimate that by March 9th 250,000 servers worldwide had fallen victim. 

Microsoft Exchange Server ProxyLogon 

ProxyLogon leads to a remote code execution (RCE) vulnerability, which grants a bad actor complete access with high privileges to the Microsoft Exchange server where they can access files, mailboxes, and potentially stored user credentials. A highly motivated attacker then uses this access to move laterally in the internal network of the organization; compromising the internal network and accessing other applications and data. 

These attacks are exploiting vulnerabilities that existed in all versions of the product from 2013 through 2019.  Microsoft has issued patch updates for these application vulnerabilities and IT security teams are scrambling to update their Exchange servers to mitigate the impact. Unfortunately, it’s too late for those 250,000 servers that have already been compromised in high probability. 

The Vulnerabilities

Hafnium targeted Microsoft Exchange servers by exploiting a chain of 4 different vulnerabilities ( CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065 ). Here’s a summary on how it works and a little good news for organizations using zero trust to isolate and broker access to their Microsoft Exchange Server application.

These Microsoft Exchange Server vulnerabilities will allow an attacker to implant  a SYSTEM privileged webshell on the remote server.  An attacker with remote access to this webshell can execute high privileged commands that will enable them to gain control of the server. All an attacker has to do to initiate an attack is to find an Exchange Login page on the internet and send a few requests. The attacker doesn’t need Login credentials and they can skip identity authentication altogether. This is a big problem for any organization who publishes their Exchange Login page to the internet and relies solely on user authentication to prevent access by bad actors.

The Attack Process

Here’s how the attack goes down. 

Step 1. 

A bad actor discovers an Exchange server to target. A simple 3rd party service like Shodan gives them all the information they need to discover the IP addresses of  internet facing Microsoft Exchange Servers and a passive DNS service helps them target victims by identifying the domain names associated with these IPs.   

Step 2. 

Using a script that can be found on github, the bad actor exploits a chain of vulnerabilities. The first, CVE-2021-26855, an SSRF vulnerability is used to bypass authentication. Then, exploitation of another vulnerability, CVE-2021-26857, elevates  their privileges to a SYSTEM user. Eventually, they’ll use their new privileged access to exploit two arbitrary file-write vulnerabilities, CVE-2021-26858 & 27065, to implant a highly privileged webshell to ensure persistence. Sounds complicated? It’s not. All of this can be achieved by a press of a button, thanks to publicly available exploitation scripts.

Step 3. 

The bad actor can now use this webshell to execute high privileged commands on the compromised server. Using lateral movement techniques, they can also try to spread in the company network. 

Break the Kill Chain

None of these organizations would have been compromised if their Microsoft Exchange Server application was not published directly to the internet. If direct access from any user on the public internet had never been enabled, then no bad actor ever finds that vulnerable Microsoft Exchange Server application to start the attack in the first place, and the kill chain falls apart at Step 1.  

Okay, so what if you keep that application only accessible via your internal network and you use a VPN? This is better than exposure to the wild public internet but still leaves an exposed and vulnerable application if a bad actor gets access to your internal network using another method, for example if they are able to get onto your VPN. 

It’s far safer to just keep your applications isolated from both the internet and your internal network. Hey, I understand. It’s important to the business to make resources like Microsoft Exchange easily accessible for authorized users and these servers compromised by ProxyLogon are set up to require user authentication for access…unfortunately this level of security isn’t enough if the platform has a vulnerability that can be exploited to bypass authentication.  

With a zero trust access approach that operates at the application-layer, you can enable remote access to applications and services without exposing these potentially vulnerable platforms to attacks like ProxyLogon. This is the good news for organizations using brokered, zero trust access for services like Microsoft Exchange Server. For organizations using the Axis Security Application Access Cloud with Application Isolation Technology, the vulnerable application is accessible for authorized remote users but is never published to the public internet or even directly accessible from the internal network and user requests to the server are always brokered at the application layer.

Read how Armis uses the Axis Security Application Access Cloud with Application Isolation Technology here.