By now, you’ve almost certainly heard about the serious and ongoing attacks being conducted against on-premise Microsoft Exchange Server implementations. If you’re not familiar, we’re referring here to four zero-day vulnerabilities (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065) discovered back in January that impacted Exchange Server and the subsequent proliferation of attacks and remote compromise targeting Exchange that leveraged those issues. The fallout has been significant, with potentially tens of thousands of organizations compromised.
Practitioners (whether directly impacted or not) are understandably asking, “What next?” There are actually a few dimensions to that question. First, there’s the immediate term: evaluating whether you’re impacted. Next, there’s the short term of organizations who suspect compromise and need to respond. In the intermediate and long term, there’s also the “what next” as it pertains to how to incorporate lessons learned into our security planning.
With that in mind, let’s look at these dimensions and consider both the near and long term for next actions.
The near term: first things first
For most organizations, the most critical near-term actions will be twofold: determining if you’re impacted and patching. Fortunately, this is straightforward. If you’re running Exchange server outside of an Office 365 context, you’re impacted. This means you need to patch. Ideally, you’ve already done this, given the volume of attacker activity and the relative ease with which compromise occurs. These issues continue to be actively exploited by multiple threat actors, so patching this is priority one. If you’re not able to patch for whatever reason, understand what other options are available and immediately put stopgaps into place.
Patching (or a stopgap) is obviously the immediate first step, but it doesn’t end there – particularly if some time went by before you were able to deploy the patch. Because of the high volume of attacker activity and the rate at which compromise occurs, you’ll want to determine if you’ve already been compromised. To assist with this, Microsoft has released a detection tool to help you find indicators of compromise (IOCs) associated with the attackers (and the attack techniques) targeting these vulnerabilities.
This tool is a great resource, but it shouldn’t be your only one. You’ll want to examine the published IOCs and look for them in your environment, but you’ll also look in detail at your Exchange environment, such as by reviewing system activity. To the extent that you employ any security tools in your Exchange environment (file integrity monitoring, etc.), you will want to examine system logs and network traffic to look for unauthorized activity.
If you find that you have already been compromised, the long road to recovery begins. The specific path to remediation will vary from environment to environment, but in many cases it will involve a full rebuild of the Exchange environment as well as systematic examination and tracing of any post-compromise actions taken by the attackers—such as creation of accounts, exfiltration of data and lateral movement to other systems.
Longer-term actions
Once the immediate fires are put out, you’ll want to use these events as “learning moments” to the extent that you can. There are a few useful things to think about here. First, there’s the question of whether and when to locate critical and ubiquitous services (like mail) in the cloud. This might cause you to potentially re-evaluate the direction you’ve employed previously.
The choice of cloud or self-managed has always been a risk decision, but an event like this one can be the fulcrum for a risk-based examination of which option makes the most sense for you and your risk dynamics. Note that, in saying that, I’m absolutely not arguing that “cloud is better.” In fact, my opinion is to be a little skeptical of anyone using any specific event (like these vulnerabilities, the recent OVH datacenter fire, or any other event) to argue the relative merits of cloud vs. self-managed. While it’s true that, in this particular case, the cloud service had a better security outcome relative to a self-managed approach, the next time the reverse might be true. Instead, be realistic, stay objective, and keep it risk-based, based on your current level of comfort and experience with cloud solutions generally and Microsoft (or other applicable service providers) specifically.
By this, I mean be honest about what you can do well and what level of service your security operations team can deliver vs. what a cloud provider delivers under a shared responsibility model. If you have the capability and tooling in place for robust (and round-the-clock) security monitoring, redundancy/availability, rapid patch delivery, and all of the other operational elements that are included in a cloud deployment, a “traditional” deployment might still make the most sense for you from a risk control standpoint. However, if you don’t feel like you can provide the same level of monitoring and operational coverage, a cloud implementation might have advantages. It might have been some time since you re-evaluated the risks here and, lest we forget, many practitioners had some trepidation about cloud services when they were first gaining traction.
The second thing to think through is your overall level of exposure relative to nation-state actors. One thing that this event decisively highlighted is that any organization can be a target and, if conditions favor it, nation-state attackers can absolutely put your organization in their crosshairs. If there are areas of your business where you’ve assumed only low-sophistication adversaries will come knocking, these events may cause you to shift your calculations. As a result, you might choose to bolster monitoring capabilities, add additional defenses, or any number of potential alternative strategies.
As always and as a final learning opportunity, stay vigilant and be ready to react quickly when necessary. Staying alert to intelligence about threats and threat actors is always good advice.