It seems like months have passed since the news of the SolarWinds hack was published, and the damage of the hack was revealed. Roughly 18,000 companies around the world were attacked in what seems like one of the largest organized hacks in many years.

This hack is now dwarfed by the new recent hack, dubbed Exchange Marauder. In this case, Chinese hackers from a group called Hafnium targeted Microsoft Exchange servers around the world. The number of organizations affected by this attack has allegedly reached tens of thousands worldwide.

According to security firm Volexity, Hafnium have exploited zero-day vulnerabilities in Microsoft’s Exchange servers’ Outlook Web Access to indiscriminately compromise no fewer than tens of thousands of email servers.

According to Wired, the affected networks appear to have been hacked indiscriminately via automated scanning. The hackers planted a “web shell”—a remotely accessible, web-based backdoor foothold—on the Exchange servers they exploited, allowing them to perform reconnaissance on the target machines and potentially move to other computers on the network.

Reducing the Attack Surface of Such an Attack

So, the million-dollar question, could I have prevented this attack on my Exchange server?

Unfortunately, the answer is complex, since we need to look at two attack vectors in this case:

• Vector 1 – The hack of the Exchange server itself
• Vector 2 – Laterally moving from the Exchange server to other computers and servers in the network

Regarding the first vector, the hackers used zero-day vulnerabilities found in the Exchange server, so preventing the attack when it occurred was impossible. Luckily, Microsoft has since released patches addressing the vulnerabilities, so for now you are safe…until the next zero-day attack. However, chasing every vulnerability of an application is not practical due to the ever-emerging zero-day attacks, and this also causes you to be fully dependent on security patches provided by your 3^rd party software vendor (and, of course, internal procedures to install the patches ASAP).

The other approach is looking for a solution in the architecture level, meaning managing and protecting the access to resources in a centralized network-based perspective – both from the outside and to internal users.

This means that when looking at the initial attack vector, in addition to patching your Exchange server, you can also consider hiding it from the outside world by controlling access to it using a zero-trust network access (ZTNA) solution or a VPN in conjunction with a ZTNA solution.

Regarding the second vector, preventing lateral movement is highly complex. You require a combination of micro-segmentation as well as controlling access between different computers and servers on the network. A simple solution can be to add a centralized MFA solution which “sees” every user, system, server, and application in the network, so that when the attacker tries to access a server from the infected machine, their WebShell command would have invoked an MFA request that, until approved, would have prevented the command from executing.

Safe-T’s ZoneZero® Solution

As we saw above, there were two separate attack vectors to the Exchange Marauder attack, which require two different attack prevention solutions.

Luckily for you, we have a single solution for both attack vectors called ZoneZero. ZoneZero is a Perimeter Access Orchestration platform that provides central management of all secure access technologies and helps organizations achieve zero-trust network access (ZTNA) for all application access scenarios, from outside and within the network.

To combat the initial attack vector, you can deploy ZoneZero in your perimeter to “hide” your Exchange server from prying eyes. In this deployment, ZoneZero can either work on its own, controlling access to your Exchange server utilizing SDP concepts, or it can be deployed after your VPN, protecting both your VPN with ZTNA capabilities as well as access to your Exchange server.

To combat the second attack vector, you can deploy ZoneZero within your network. This will allow you to add centralized MFA to any corporate resource (system, server, data, application, etc.).

Safe-T’s ZoneZero centralized MFA approach allows customers to easily integrate multi-factor authentication (SMS, push messaging, biometric, telegram, WhatsApp, REST API) and identity awareness into all access scenarios – remote and internal users, VPNs, web and non-web applications.

With Safe-T ZoneZero® – You can block hackers from hacking your Exchange server and moving around your network!

By deploying ZoneZero in the network, it is now possible to prevent hackers from directly attacking your corporate applications (such as your Exchange server), and to ensure that any request from any user/application (e.g., a text message sent to an IT administrator) to any application (for example, the Exchange server in our case), will invoke an MFA action.  ZoneZero will prevent the execution command until the MFA is responded to.

Utilizing ZoneZero would have prevented and stopped the first attack vector (Exchange server hack), by controlling access using ZTNA concepts. The same goes for the second attack vector (lateral movement from the Exchange server), as the company’s IT would have been notified and the alarms would have started blaring at the first attempt to execute a WebShell command.

The Solution – ‘Safe-T ZoneZero®’

Business Benefits:

• Achieve ZTNA
• Create true separation of the data plane and the control plane
• Optimize cost of deployment and ownership
• Unify all access scenarios

Technical Benefits:

• Based on Safe-T’s patented Reverse Access technology
• Proven and highly secured network architecture designed to mitigate zero-day and N-day VPN vulnerabilities
• Seamless and fast integration into any existing VPN infrastructure with zero network changes
• Strong 2-Way-Message MFA as 2nd layer of defense after initial VPN authentication
• Restrict network access to resources until users approve MFA request, after their initial VPN authentication
• Enforce conditional secondary MFA policy to each resource individually when users perform access to backend services
• Break the standard VPN Layer 2 tunnels, allowing only Layer 3-4 application access
• Prevent end user lateral movement – no option for network scanning from end user
• No end point installation required – keeping the same user experience