Preventing Recent Microsoft Exchange Vulnerabilities and Similar Attacks Using Netskope Private Access

On March 2, Microsoft released patches to address four zero-day vulnerabilities in Microsoft Exchange Server software. Those vulnerabilities, known collectively as ProxyLogon, affect on-premises Exchange Server 2013, Exchange Server 2016, and Exchange Server 2019. (Exchange Online, which is part of Microsoft 365, has not been affected.) 

This Exchange Server attack is the kind of industry-wide security event that may have even broader implications than the SolarWinds attack. Reports indicated that cybercriminals were already able to breach more than 30,000 organizations due to this active exploitation, and the number of attempted attacks observed against vulnerable Exchange Servers increased by orders of magnitude. Roughly 125,000 Exchange servers might still be vulnerable.

If you read into the technical details published about the attacks, you observe that essentially an entire kill chain occurred, meaning there were multiple vulnerabilities in Exchange Servers and an attacker would need to exploit several, or all of them, to achieve a successful attack. The first of the vulnerabilities, a remote code execution exploit, is a network-based vulnerability,  specifically referencing how attackers could connect to internet-facing Exchange Servers and escalate their level of access, without needing to steal a password or find another means of compromise. 

As the CVE notification explains, “The initial attack requires the ability to make an untrusted connection to the Exchange Server on Port 443. … This can be protected against by restricting untrusted connections, or by setting a VPN to separate the Exchange Server from external access.”

It’s important here to note that firewalls wouldn’t have prevented this attack in most cases, as it was a zero-day attack. Web application firewall (WAF) vendors are only now reactively rolling out updated rulesets to detect this attack, and those protections apply if the WAF is performing SSL decryption. It’s better to prevent attacks in the first place rather than catch them after the fact. 

Taking a Zero Trust approach to security prevents exposure to these types of attacks, because it stops unauthenticated access to sensitive resources, and it serves to provide protection against emergent threats such as what we have seen now that the exploit is in the wild. If you’re using Netskope, the Microsoft Exchange attack doesn’t happen, because the first vulnerability is completely mitigated. Applications that are not public-facing should not be on the internet. By putting corporate applications behind Netskope Private Access (NPA), vulnerable applications aren’t reachable by attackers.

With NPA, there are no untrusted connections, and zero trust principles are judiciously applied to every point of network access. If an Exchange Server sits behind NPA, it has no direct exposure to the public internet, and users would connect to it using a Netskope client. Once Netskope has authenticated that user—that is, Netskope has done a posture check, determined who the user is, and what the user’s characteristics are—the user can connect only to Exchange or to other services authorized by the user.

The advantages of NPA over a VPN

NPA provides Zero Trust Network Access (ZTNA) to private applications and data in hybrid IT (public cloud and data center) environments. It offers seamless connectivity for authenticated users, supports any application and protocol, reduces business risk, and simplifies IT infrastructure. 

NPA also goes well beyond the capabilities of a remote access VPN to deliver an exceptional user experience—something often lacking in standard VPN configurations trying to access key resources like Exchange. The chart below highlights some of the key advantages of NPA over typical remote access VPNs. 

If you’d like to get started with NPA, contact us today to schedule a demo.

• Learn more about Netskope Private Access
• Learn more about Netskope’s partnership with Microsoft