It has been a tiring year for Exchange On-Premises and Hybrid administrators and unfortunately, it’s not getting any easier. The exploits dubbed HAFNIUM shone a spotlight on Microsoft Exchange and re-emphasized why email is a crucial part of any organization and that nothing, even products that have a good track record, can become targets.
During the last week, a security research professional from DevCore, Orange Tsai presented a talk at BlackHat USA 2021 on the underpinning attack surfaces that resulted in the exploit of Exchange Server earlier in the year. The attack surface responsible for HAFNIUM is known as ProxyLogon and two others exist, known as ProxyShell and ProxyOracle.
You can read about these in detail on Tsai’s blog as they explain the individual CVEs reported to Microsoft and the resulting patches that Microsoft released after responsible disclosure. The key takeaway regarding the most crucial of these, ProxyLogon – is that if you are fully patched on Exchange Server then you are in a reasonably OK position – for now.
However, as I discussed with Michael Van Horenbeeck, fellow MVP and Exchange Hybrid expert and now Microsoft 365 Security specialist – there are proof of concept attacks happening now in the ‘wild.’ Even though these attacks aren’t currently happening, as we understand it security researchers as well as groups looking to find and exploit Exchange Servers are already exploring what they might be able to do.
The BlackHat USA 2021 session by Tsai and the subsequent blog write-up is an interesting read for any Exchange admin, whether there’s just a single Hybrid server remaining or a full on-premises environment. In the posts, you’ll find diagrams that are familiar to most Exchange admins and explanations to other security researchers of the different components of Exchange Server and how they interact – such as the Client Access Service, the permissions that an Exchange Server’s computer account possesses and aspects such as the Client Access Front-End and Back-End and how they interact.
If you’ve not watched a recent session on Exchange Server architecture, it’s not a bad idea to refresh. For those that know it well, it may be worrying to read that the focus of both security researchers and bad actors are spending time understanding how Exchange Server processes and responds to requests at an intimate level.
On balance though, it is extremely positive that security researchers have a focus on Exchange Server. This makes it more likely that potential vulnerabilities will be found by people that will disclose them responsibly to Microsoft, in the same way Tsai and other researchers did in January this year.
As for now though, if you have Exchange Servers exposed to the internet it’s extremely likely they will be found by people looking to exploit it as soon as they can. Especially if you have a system that’s not up to date on the most recent security updates, because in the future should similar vulnerabilities be found.
Former Microsoft Senior Threat Intelligence Analyst Kevin Beaumont has been running honeypot Exchange Servers to collect insights into what type of activity is happening. What he’s shared is interesting, particularly if you don’t have access to the same tools.
For example, Shodan Monitor provides people with ability to view a heat-map on Exchange Servers exposed to the internet that are vulnerable to post-HAFNIUM attacks:
Using Azure Sentinel, Kevin has also been able to provide examples of what queries are currently being attempted against Exchange Servers that are potentially dangerous. Kevin’s feed provides quite a few examples as he actively monitors what’s going on, and he helpfully provides examples from his GitHub for those conducting Threat Hunting using Azure Sentinel to use:
What can you do to protect your organization?
Knowing that people are actively scanning for Exchange Servers and might attack yours is definitely worrisome. However, there are several things you can do now and plan for that will help you protect Exchange in the future. Michael and I discussed these in the video above, and our top recommendations are:
Patch Exchange NOW. If you are holding off in case of potential issues or think because you aren’t publishing it externally it’s not a risk, then reconsider your decision to do nothing. You also need to ensure you patch Exchange to the correct level with the right security updates. Microsoft has an online tool to guide you through this: https://aka.ms/ExchangeUpdateWizard
Increase your logging. Many organizations are using the default for security and other logs. Increase the amount of time you retain logs for as soon as you can. This will help you ensure that you can understand what happened if you are attacked.
Adopt an assumed breach mentality. If you begin with the view that someone could already have access to your organization, your mindset will be different from someone who assumes they are just keeping the door closed. It’s not far-fetched for credentials to be sold on the dark web, and even if you deploy some security tooling or multi-factor authentication today (assuming you have MFA, right?) then it might not remove threats already within the organization.
Stop publishing Exchange to the internet when you no longer need to. It comes natural for one to pose the question – “why are you publishing Exchange?” And there are a lot of people in the cybersecurity industry wondering exactly the same thing.
However, it is typical to publish Exchange Server to the internet for various valid reasons, and Microsoft has recommended ways to publish Exchange, even sold it as a product that enables people to work from anywhere without VPN – ActiveSync and HTTP over RPC (and MAPI-HTTP) being key examples. There are some key reasons why you may be though, and if you have (or are planning to) then consider the following:
- If you are running on-premises Exchange Server and are publishing it directly (or via NAT mappings, or an arm of the load balancer in the DMZ) then reconsider the overall approach. Load balancers from KEMP and F5, for example, include web application firewall, pre-authentication and multi-factor authentication integration.
You can integrate Exchange Server with Hybrid Modern Authentication to better protect sign-in in a modern way that supports Azure AD sign-in and use features in KEMP and other load balancers to use Azure AD sign-in as a pre-authentication method to protect any access from external clients.
- If you are running Exchange Hybrid for long-term co-existence with Exchange Online, or for usage of functionality like Calendaring in Microsoft Teams, then examine how you publish Exchange Server to the internet today for Hybrid functionality. If you are publishing endpoints such as Exchange Web Services for OAuth and the MRSProxy, and AutoDiscover for service access, and to allow clients off-network to find Exchange Online, then consider whether these endpoints can be scoped to only Microsoft 365 recommended IP address ranges for Exchange (and Teams, if you are using the calendar access).
Modern versions of Outlook are capable of bypassing Autodiscover when the mailbox is in Exchange Online, therefore you might find you no longer need to allow Exchange Server to be available to anyone on the Internet.
- If you’ve migrated to Exchange Online, then you should not need to publish Exchange Server externally – and almost certainly not HTTPS services. Whilst you cannot remove Exchange Server today whilst Azure AD Connect is linking your AD to Microsoft 365 & Azure AD, you can remove the Autodiscover Service Connection points from AD, and you can stop publishing Exchange Server to the outside world.
You may also want to consider (although there are some aspects, such as requirements for any to any firewall rules between Exchange and domain controllers) preventing internal access to Exchange after your migration too, except for trusted administrator machines, as the core purpose of using the Exchange Admin Center and Exchange PowerShell is for administration, not user access.
Invest in tooling and skills to improve your cyber security. It often takes an incident to get executive attention, but since there’s so much evidence that Exchange is at risk you should take a proactive stance and make the case to move to Exchange Online if you can. If and when you do, it’s important to properly invest in the right tooling, services, and skills to ensure you can protect your organization against attack.
Vendor choices aside, it’s likely you need EDR (Endpoint Detection and Response) tools and a SIEM (Security information and event management) product, along with skills to manage it or as a service.