Exchange Server

How to Mitigate Microsoft Exchange Autodiscover Protocol Flaw That Leaks User Credentials

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:


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:

Sponsored Content

Maximize Value from Microsoft Defender

In this ebook, you’ll learn why Red Canary’s platform and expertise bring you the highest possible value from your Microsoft Defender for Endpoint investment, deployment, or migration.

  • 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.
Guardicore captured credentials for companies across various sectors (Image Credit: Guardicore)

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:


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

The Autodiscover ‘fail-up’ process (Image Credit: Guardicore)

In short, if you owned, 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 and, 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 ( 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.

Related Topics:


Don't have a login but want to join the conversation? Sign up for a Petri Account

Comments (4)

4 responses to “How to Mitigate Microsoft Exchange Autodiscover Protocol Flaw That Leaks User Credentials”

  1. This is an article that doesn’t come up to the standard expected from There’s no critical analysis of the reported exploit (did the author attempt to replicate the problem?) and the author appears to accept everything the researcher did as gospel truth. Within the wider Exchange community, this report has been debunked comprehensively because of its lack of detail which might allow people to understand how to reproduce the issue. It’s an example of a security company issuing a report about a purported flaw to attract attention to their work. I don’t know of anyone who has been able to reproduce the issue except using odd email addresses with a program based on Exchange Web Services. That’s definitely not the kind of normal situation people run into. It’s just so sad to see Petri resort to publishing clickbait.

    • Hi Tony. Thanks for your comment. I appreciate your point of view but this article simply covers what has already been widely reported elsewhere, including on our sister site and on other respectable publications. It isn’t designed to be clickbait but just a topic that might be of interest to Petri readers, who are free to interpret it as they like. It is neither a recommendation to take action or endorsement of the research. Readers must always decide whether to implement technical changes and test them in their own environments. I would personally wait for a response from Microsoft but the choice is in readers’ hands. As the author of this and other articles on Petri, I don’t have the time or technical capacity to reproduce every potential issue that we report on.

      As you say, it may well be a non-issue. And when Microsoft provides a response, I will publish another article so readers are aware of the official stance and maybe some of the controversy that the research has caused in the Exchange community. Regardless of the outcome, I believe it’s a story of interest to Petri readers and I will follow up on how it unfolds.

  2. I am similarly critical of the coverage on many sites, all of whom seem to accept the findings without any critical analysis. The report didn’t include enough detail for anyone to be able to conclude that this is a problem the average on-premises/online deployment is likely to meet. It didn’t give details of the test configurations or the repro steps. Yet sites went ahead and said "oh, this is a nice juicy story" and published essentially the same coverage. I expect more of Petri.

    Tagging a few lines from Steve Goodman to the end of the piece doesn’t address the issue I have with the text. After some 40 years working with email, I’ve learned to ask questions and understand the full context of a purported issue before making my mind up whether it’s so much hot air or a real problem. We still don’t have enough data to come to an intelligent conclusion.

  3. As we’ve discussed on Twitter, this article is simply me trying to interpret what was published by the researcher and to provide details of the supposed mitigation should readers deem it necessary, in a digestible way. And that actually took me several hours to do.

    As you say, and I guess the researcher has chosen not to reveal the full repo details at this stage to give Microsoft a chance to respond, it is difficult to piece together exactly what the claimed threat is. But that is what I’ve tried to do here to the best of my ability. I think readers understand that I’m not an Exchange security expert and that they should consider for themselves whether this is an issue before taking any action recommended by Guardicore.

    I hope that nobody, including the researcher, has malintent or is trying to purposefully misinform anyone. I could be wrong. Steve approached me, not the other way around. And I said that if he has something of value to add, I’d be happy to quote him. But one way or the other, nobody seems to have proved categorically that this is or isn’t an issue at this stage.

    Personally, I’m going to wait for Microsoft to tell us whether it considers this research to identify a real threat or not. In theory or otherwise. At which point, I will update Petri readers.

    I appreciate your point of view and the interesting conversation.

Leave a Reply

IT consultant, Contributing Editor @PetriFeed, and trainer @Pluralsight. All about Microsoft, Office 365, Azure, and Windows Server.
External Sharing and Guest User Access in Microsoft 365 and Teams

This eBook will dive into policy considerations you need to make when creating and managing guest user access to your Teams network, as well as the different layers of guest access and the common challenges that accompany a more complicated Microsoft 365 infrastructure.

You will learn:

  • Who should be allowed to be invited as a guest?
  • What type of guests should be able to access files in SharePoint and OneDrive?
  • How should guests be offboarded?
  • How should you determine who has access to sensitive information in your environment?

Sponsored by: