Jason GarbisMarch 15, 2021
Hafnium, Zero Trust, and the Principle of Least Privilege
The impacts of the Hafnium group's Microsoft Exchange attack are still unraveling. But how did we get here? Simply, enterprise applications are still exposed to the Internet.
It’s been a very busy week in security, with the exploitation of Microsoft Exchange having a significant and still-unraveling impact. While the degree of exploitation and data theft is still unclear, but what we do know is this: the attack was purposefully designed to exploit a complex, valuable, and widely accessible software service – a company’s on-premises email server.
First and foremost, if you’re running an on-premises Exchange server, stop reading this blog and make sure that you’ve patched it based on the Microsoft guidelines below. Also, take the time to check and double-check whether or not it’s directly exposed to the Internet. Then make sure your IR team is in high gear and ready to remediate. Patching doesn’t remove the adversary in a compromised server.
The people responsible for the Exchange server shown below, likely through inattention or insufficient investment in IT and security, have put their organization at risk, and have probably been breached.
Note the 2010 copyright in this login screen is doubly troubling, for obvious reasons.
Understanding the Attack
Let’s take a step back and look at two things. First, the attack methods, and second, how a Zero Trust approach can be used to mitigate attacks such as this in the future.
Microsoft has put together clear writeups about the attack, in [1, 2] below. Essentially, the attackers – a group named HAFNIUM –chained together several 0-days in Exchange to achieve their goals of data exfiltration (from Exchange), as well as obtaining a long-term presence on the network for monitoring, reconnaissance, and lateral movement. The initial attack vector exploited a vulnerability in Exchange via Server-Side Request Forgery (SSRF), and only required an unauthenticated network connection to the Exchange OWA (Outlook Web Access) service.
What can we learn from this? Sadly, this is a lesson that enterprises should have learned a long time ago: Do not expose enterprise applications directly to the Internet. It is a bad idea to rely solely on authentication for defense, because malicious actors, both sophisticated and unsophisticated, have a proven track record of successfully breaching such applications. There’s a reason that Gartner chose to use such alarming language in their 2016 report “It's Time to Isolate Your Services from the Internet Cesspool.” Enterprise applications need to be placed behind security gateways of some sort, with appropriate authentication and authorization. Even a VPN (as much as we despise them) is better than directly exposed applications.
Now, let’s assume that you’ve taken that step and made Exchange only accessible to users on the internal network, or via remote access (such as VPN or, better yet, a Software-Defined Perimeter). This is a big help, but not a complete solution – you still want to secure this from potentially malicious code that has otherwise gotten a foothold on your network or user devices. The principle of least privileged access is one of the core tenets of Zero Trust and important to apply in this situation. With least-privileged accessed, users only have network access to resources they need to do their job, and nothing more. This is necessary for exactly the reasons illustrated by this SSRF vulnerability (not requiring authentication, just remote access).
But, of course, *every* employee needs access to Exchange for email, so an on-premises Exchange server is in fact one of the few services that “everyone” should get access to. This makes it an inviting target for attackers, since all they need is one employee to give them a foothold (e.g. via a phishing link). So, what are we to do, given that everyone needs access? Besides patching, there are a several things we can do to protect ourselves against the next vulnerability in servers like Exchange where everyone needs access.
MFA, the mighty MFA
While not a panacea, MFA will certainly help by making it much more difficult for an attacker to perform exploits from an unattended or idle machine. This is predicated on having a security enforcement point sitting in front of the application, which is what will be enforcing the MFA. Relying on the application to enforce MFA is not sufficient. Enforcing MFA prior to permitting a network connection will ensure that a human is actively accessing Exchange (or any resource) from that device.
Of course, an attacker with a foothold in a user’s machine may be able to exploit this after a user has responded to an MFA prompt but this is more technically difficult (and may be noticed by the user).
Risk-Based Access Control
This approach relies on a risk score calculation and acts on elevated risk by blocking access for a device if it exhibits anomalous behavior. This can use a variety of systems, such as a UEBA, EDR, etc. to act as the trigger. The important part is having the ability to connect this to a Zero Trust system with enforcement points that can take action. A thoughtfully designed security architecture will incorporate different types of intrusion detection systems, and include both network and host-based, as well as a SIEM. Taken together, these can provide a resilient system for detecting and quickly responding to compromise.
This should be a core element of any security infrastructure, as many malware components require DNS resolution of command-and-control systems or may even use DNS as a data exfiltration channel. Anomalous DNS requests, or requests to a known-bad site should be a red flag and warrant immediate action. This is especially true for servers, which should have an extremely predictable and boring set of DNS activities. Your security systems and processes need to be set up to rapidly respond to strange activity from a server.
While in this particular attack the Exchange server was both the entry point and the target, that’s not always the case. Much more frequently, attackers will use a low-value entry point to perform network reconnaissance and lateral movement. It’s important to understand and baseline your server-to-server communications patterns and put in place mechanisms to enforce the principle of least privilege for them. This should apply both to inbound and outbound network calls from servers
In summary, please take this latest attack as a serious indication that you should not be exposing any enterprise services directly to the Internet and put them behind a dedicated security component. Require authentication and ideally include multiple factors (e.g. device onboarding with out-of-band validation) before permitting access to anything at a network level. Enforce the principle of least privileged access when possible. For broadly accessible services such as email, consider enforcing MFA before allowing the network connection to ensure there’s a human operator. Monitor for and be able to respond to indicators of compromise or malicious activity – ideally with some degree of automation. And finally, remember “defense in depth”. No single solution can solve all problems, but when you take a dynamic and context-sensitive Zero Trust approach, your organization can be much more resilient to attacks. Sophisticated threat actors will continue to develop sophisticated methods, but attacks such as this one on Exchange were completely preventable.
4 - https://www.volexity.com/blog/2021/03/02/active-exploitation-of-microsoft-exchange-zero-day-vulnerabilities/ - firm that first publicized this