Discovering Exchange Servers: Leveling the Field Using Attack Surface Intelligence
Microsoft Exchange, the foundational server technology behind the world’s most popular enterprise email and scheduling ecosystem, has recently turned twenty-six. Over the years, the term “Exchange” has become synonymous with aspects of both work and personal life, like office integration or simplified calendar sharing; in short, a household name for all things productivity.
But with every rolling upgrade came the added complexities — in fact, Exchange Server’s long-standing, coexisting requirements and tightly coupled domain dependencies have routinely introduced important security challenges, making it a consistent target for threat actors worldwide. Last year alone, for example, several Exchange Server versions experienced a total of 18 remote code execution (RCE) vulnerabilities, from low to medium complexity, and spanning severity scores of 6.5 through 10 — two more RCEs than the last ten years combined. Racing to take advantage of some of these exploits, Advanced Persistent Threat (APT) groups like Hafnium were soon observed targeting public-facing Exchange infrastructure while forcing Microsoft to release a sleuth of out-of-band security patches and updates to contend with the emerging attack surface.
Following up on the recent two Exchange vulnerabilities, we’ll go into some detail to describe the tools and methodologies used to detect the presence of web-facing Exchange servers, particularly through the lens of Attack Surface Intelligence — a new attack surface reduction paradigm designed from the ground up to assist with continuous asset discovery and monitoring — as well as the different ways to spot any Exchange server using well-known paths, as any attacker would.
Exchange hosting: past vs. present
With the growing popularity of the cloud, Exchange servers that had previously been housed on-premise, or in a more legacy fashion (e.g., locally at a business site), are progressively starting to reap the expected benefits of hosted solutions. These new standards are primarily driven by the need to employ cost-sensitive measures while minimizing downtime and similar shortcomings.
Hosted Exchange, for instance, is usually carried through third parties and resellers, although you can procure these services directly from Microsoft via (you guessed it) Exchange Online. With no hardware or software to buy or maintain, these offerings are as appealing as they are reliable. Exchange Online, for example, is a subset of Office 365 that offers enterprise-class protection and data safeguarding. In true Software-as-a-Service (SaaS) fashion, admin portals provide a one-stop shop for a wide range of features beyond simple mail and calendar flows, while anti-malware and filtering mechanisms ensure mail undergoes rigorous scrutiny.
However, what is distinctive of hosted solutions doesn’t apply to in-house approaches. That is mainly because in-house Exchange servers require a considerable amount of IT resources to ensure that not only are they properly configured and maintained but also that security best practices are judiciously observed.
Figure 1: The Exchange Server exploit chain known as ProxyLogon - Source: Microsoft
ProxyLogon (CVE-2021-26855) is a case in point. An entire attack surface (see above) allowed threat actors to bypass authentication mechanisms and grab system privileges via an open 443 port — a port typically associated with web-facing components of on-prem Exchange servers — using a combination of additional critical CVEs to obtain complete control of the targeted endpoint.
Finding Exchange servers in the wild
Discovering servers that belong to the Exchange Web Services family could be as easy as taking advantage of a well-known configuration artifact or feature: the Autodiscover protocol. Introduced as part of Exchange 2016, its purpose is to assist email applications in locating Exchange servers with minimal user interaction, whether inside or outside firewalls, while automatically setting any corresponding user profile.
Last year, however, when user credentials began randomly reaching domains such as autodiscover[.]com or autodiscover[.]online, a massive credential leak problem ensued. As a result, organizations were advised to start blocking autodiscover TLDs at the perimeter level as a stopgap measure; and yet, by late August, researchers had managed to obtain over 370,000 Windows domain credentials through the faulty back-off mechanism.
Part of what makes finding web-based Exchange infrastructure so appealing to attackers is the technology’s close-knit integration with Internet Information Services (IIS). Historically, IIS — the extensible web server platform known as ground zero for a number of unspecified vulnerabilities — has been linked to a series of malicious extensions that can act as a persistence mechanism, providing a highly covert channel with low detection rates. More recently, in one sobering case termed “Owowa”, this IIS backdoor allowed for the passive collection and siphoning of OWA (Outlook Web Access) credentials from unsuspecting visitors trying to authenticate to the web portal.
Besides the described Autodiscover scenarios via TLDs, discovering Exchange endpoints can be accomplished using Nmap scripts (or NSEs). Fundamentally, this is no different from any other scanning method that relies on JSON input files, or some other format, for versioning purposes. We can use a similar approach to detect any potential CVEs using build names and release dates.
Search engines like Shodan or Wappalyzer can also help locate Exchange-related technologies. Once again, of particular interest are instances of Outlook Web App — in this case, with results upwards of 200K (see below), an HTTP response header value called “X-OWA-Version” is leveraged to pull versioning information.
Enter Attack Surface Intelligence
The barrier to conducting timely risk assessments using any of the above contingencies has been significantly lowered by platforms like Attack Surface Intelligence. And that’s because this new paradigm, by its very makeup, is designed to combine every pertinent element for visibility purposes.
In a recent analysis detailing two of Exchange’s latest CVEs, we established how our Attack Surface Intelligence Module can lead you in the speedy discovery of any public-facing Exchange infrastructure; if you’re a client with access to this feature, you’ll only be a few clicks away from doing so.
Another worth mentioning alternative includes the use of domain-specific tools like our very own SQL Explorer, which extends the discovery space far beyond the graphical user interface. Let’s illustrate the latter using two sample SQL queries:
In the above query, we’re interested in one thing: what domains may indicate email presence in the form of either “Exchange” or “Outlook” as part of the site’s title. The idea here is a rather simple one as well: sites that advertise page titles such as these are prone to be hosting some sort of Exchange-like technology; however, the results are by no means definitive, as both terms can easily be found outside the purview of mail services.
An improved query looks as follows inside the SQL Explorer interface:
Here, the focus shifts entirely in favor of tags — a handy feature that pivots on our vast data collection to identify assets speedily. Soon after, the results look much more promising than before, as the hostname portion now shows:
Summing up
Unparalleled visibility, real-time asset monitoring, and proactive vulnerability mapping; these are some of the net positives that Attack Surface Intelligence can afford modern organizations today.
If you find yourself, or your IT staff, plodding through your daily workload just to keep things under control, think again. As hinted in this article, think about the possibility of having unmanaged Exchange infrastructure lurking in your precious inventory. Proper knowledge of these proverbial “crown jewels” isn’t only good governance, it’s good risk management: the penalties of losing valuable employee and/or customer data as a consequence of such an oversight can be long-lasting and severe.
Under the hood, it may be tempting to devote a handful of resources here and there to manually locate these endpoints, given the open-source nature of some of the tools and applications involved, and remediate any issues if need be. But in reality, you’ll be risking missing critical assets as you try to consistently enumerate your constantly evolving digital workforce — a seemingly impossible task if you ask me.
Until next time...
Related