Protect local MS Exchange servers against webshell attacks with reverse proxy or WAF

Microsoft Exchange servers are “dangerous” servers. They host relatively valuable data (mails, calendars, contacts, etc.), are close to the domain controller, often insufficiently protected and separated from the danger of the Internet only by a NAT. They are 24/7 freely accessible from everywhere for everyone.

A potential entry point for uninvited guests, as the ProxyLogon vulnerability from spring 2021 or the recently disclosed ProxyNotLogon vulnerability impressively demonstrate. The extreme speed that attackers show to hide WebShells in affected servers is somehow impressive but also scary.

My experience with the ProxyLogon vulnerability has shown that you almost need to be Lucky Luke to close such a vulnerability before the server gets infected. Even with a lot of automation and centralized management, such a patch process takes 24-48 hours. Time which is shamelessly used by attackers.

Problem

Exchange setups of many SMEs are very simple: The Exchange server is running on a single host. HTTPS traffic is forwarded through a NAT directly and unfiltered to the Exchange server. Since this traffic is encrypted, filters on the firewall are useless. The firewall only “sees” encrypted traffic and is unable to analyze it, or even react to SQL injections etc.

In this configuration, every request is sent to the server unrestricted and unfiltered. Particularly this that allows the operation of WebShells, phishing sites and so on by attackers. Single-host Exchange servers contain a full-fledged web server: IIS.

WebShells are used by attackers for so-called lateral movement, whereby the network is further scouted in order to identify lucrative targets and, for example, to encrypt them using ransomware. It is not uncommon for weeks or even months to pass between the infection with a WebShell and the actual CryptoTrojander attack on important data targets.

Approach

First and foremost, you try to take the Echange server out of the “line of fire”. You put the server behind a reverse proxy that only forwards legitimate requests to the server. Faulty and illegitimate requests are rejected directly by the reverse proxy server and thus never reach the Exchange server. This does not directly close any security holes, but makes it difficult or impossible for attackers to use WebShells.

Reverse proxies are nothing new:

Ideally, the reverse proxy is located in a so-called DMZ, i.e. it communicates with both the Internet and the Exchange server (or other web servers) only via a firewall that restricts access to the necessary ports.

Schematic representation of a segmented network with web server zone and proxy in a DMZ. A request to the Exchange server is always routed through the firewall twice.

Reverse proxy as firewall service

Environments in which reverse proxies are operated in DMZ zones generate additional operating and maintenance costs due to the additional server (or VM) required for this purpose. In addition, they offer only basic but nevertheless effective protection.

Modern firewall appliances offer the possibility to run additional relay services. The most popular are mail relays or filters, VPN servers, web proxies but also reverse proxies (like Squid on pfSense).

Since the reverse proxy has the possibility to decrypt and inspect the received requests before forwarding them to internal networks, this is the ideal point to place a filtering solution which can identify and remove “bad” requests. Exactly here so-called Web Application Firewalls (WAF) come into play: Through patterns, provided by the firewall manufacturer itself or by an antivirus provider, malicious requests are detected and specifically blocked by the WAF. In addition, most WAF solutions also provide load balancing and source- or request-based routing.

Reverse proxy configuration: an art of its own

The configuration of reverse proxies or WAFs requires experience and is often very complex. This is particularly well illustrated by the example of Sophos XG WAF: Sophos’s instructions for configuring WAF for MS Exchange 2016 are very long. The creation of a functional pattern requires a very in-depth knowledge of the web application that needs to be protected. For web application firewalls, in addition, even the most common web applications generate false positives and must be whitelisted accordingly.

It would be great if this crucial component of WAF protection would be given more weight by the manufacturers. On the part of the WAF manufacturers, only a limited number of functioning ready-made configurations are available. But also on the side of the manufacturers of WebApps like Microsoft Exchange etc. the information is often poor. The lack of such information forces the admin to determine the appropriate settings in a time-consuming process using a test system or even in the monitor mode on a live system.