In this article, I explain how the recently discovered flaw in the Exchange Server Autodiscover protocol can leak user credentials. And how to mitigate the issue in your environment.

Microsoft Exchange Server Autodiscover protocol leaks thousands of user credentials

Researchers at security company Guardicore have released details of a security issue in the Autodiscover protocol that Microsoft Exchange Server clients, like Outlook, use for automatic configuration.

In the paper, Amit Serper reveals how Guardicore purchased multiple Autodiscover domains with a top-level domain (TLD) suffix. Domains purchased by Guardicore included:

• Autodiscover.com.br
• Autodiscover.fr
• Autodiscover.xyz

The domains were configured to connect to a web server under Guardicore’s control. And between April 16th, 2021 to August 25th, 2021 Guardicore says it captured:

• 372,072 Windows domain credentials in total.
• 96,671 UNIQUE credentials that leaked from various applications such as Microsoft Outlook, mobile email clients and other applications interfacing with Microsoft’s Exchange server.

How the Exchange Server Autodiscover protocol works

When users set up an Exchange email client for the first time, they are asked to provide their email address and password. Using the domain name from the user’s email address, Autodiscover constructs a URL to try and automatically discover the settings required to connect to the user’s Exchange Server.

Autodiscover constructs addresses in the format shown below, hoping to find the Autodiscover.xml file containing settings necessary to connect the email client to the user’s Exchange Server. If a user provides an email address like [email protected], then Autodiscover will construct links like so:

• https://Autodiscover.example.com/Autodiscover/Autodiscover.xml
• http://Autodiscover.example.com/Autodiscover/Autodiscover.xml
• https://example.com/Autodiscover/Autodiscover.xml
• http://example.com/Autodiscover/Autodiscover.xml

If none of the constructed URLs respond, Autodiscover switches to a ‘back-off’ procedure that attempts to ‘fail-up’. For instance, if http://example.com/Autodiscover/Autodiscover.xml doesn’t work, Autodiscover will try http://Autodiscover.com/Autodiscover/Autodiscover.xml instead.

In short, if you owned Autodiscover.com, you might be able to capture the credentials of users trying to connect to Exchange Server; specifically, those with email clients using the POX XML protocol implementation of Autodiscover.

The HTTP authentication process

Guardicore goes on to say about the requests it intercepted that “The most notable thing about these requests was that they requested the relative path of /Autodiscover/Autodiscover.xml with the Authorization header already populated with credentials in HTTP basic authentication.”

Web requests should follow the HTTP authentication process, which makes sure requests are not sent blindly and pre-authenticated. The client software should request access to secured resources first and then wait for the server to respond before sending authentication information.

Many Exchange Server email clients implement Autodiscover in such a way that there is no check to see if the Autodiscover.xml file is available on the remote server before asking to make an authenticated connection to the server.

When Exchange Server email clients don’t get a successful response from the server, they are downgraded to use HTTP Basic Authentication. This could allow an attacker to see the victim’s credentials in their web server log files.

How to mitigate the Exchange Server Autodiscover attack

While use of HTTP Basic Authentication is an issue, the crux of this attack is the way Autodiscover is often implemented in Exchange Server email clients, including Outlook.

Block Autodiscover domains at the firewall

While Microsoft hasn’t yet issued any mitigation advice, Guardicore recommends blocking Autodiscover domains, like Autodiscover.com and Autodiscover.com.cn, at your firewall.

Add Autodiscover domains to the local hosts file on each endpoint

Another way to block access to Autodiscover domains is to add them to the local hosts file on each of your endpoints; essentially creating a blackhole and ensuring that email clients can’t resolve to rogue Autodiscover domains.

Guardicore has prepared a text file that points all possible Autodiscover domain variations back to the local host (127.0.0.1). You can find the file on GitHub here.

And for more information on modifying the local hosts file, check out Easily Edit the Hosts File in Windows 10 and How to Easily Edit the Hosts File in Windows 11 on Petri.

Guardicore recommends developers disable the ‘fail-up’ part of the Autodiscover protocol

Guardicore recommends developers disable the ‘fail-up’ part of the Autodiscover protocol in their products. But while we wait for a response from Microsoft, and for vendors to potentially change the way Autodiscover is implemented in their software, Guardicore has provided a couple of workarounds that should protect against credential theft.

Steve Goodman, Petri contributor and Exchange expert with more than 20 years’ experience says: “So far, reproducing the Autodiscover flaw using Microsoft clients, like Outlook, has proved difficult. Therefore whilst it’s important to check your DNS configuration for Autodiscover is correct, and be mindful of general DNS-based attacks, it is important not to overreact. Better time and focus is spent on making sure the wider issue of credential harvesting is more difficult by adopting multi-factor authentication and better still, passwordless sign-in to either Microsoft 365 or Exchange Server using Hybrid Modern Authentication.”

For more details on the Autodiscover issue, check out Guardicore’s paper here.