Exchange / Outlook Autodiscover Bug Revealed Over 100,000 Email Passwords



Enlarge / If you own the right domain, you can intercept hundreds of thousands of innocent third party email credentials just by using a standard web server.

Guardicore security researcher Amit Serper discovered serious flaw in Microsoft automatic discovery—The protocol that allows automatic configuration of an e-mail account with only the required address and password. The flaw allows attackers who purchase domains named “autodiscover” – for example or – to intercept the clear text account credentials of users who experience network problems (or whose administrators misconfigured DNS).

Guardicore bought several of these domains and exploited them as proof of concept identification traps from April 16 to August 25 of this year:

  • Automatic

A web server connected to these domains has received hundreds of thousands of e-mail credentials, many of which are also used as Windows Active Directory domain credentials, in clear text. Credentials are sent by clients requesting the URL /Autodiscover/autodiscover.xml, with an HTTP Basic authentication header that already includes the unfortunate user’s Base64-encoded credentials.

Three major flaws contribute to the overall vulnerability: the backoff and escalation behavior of the Autodiscover protocol when authentication fails, its inability to validate Autodiscover servers before giving out user credentials, and its willingness to use insecure mechanisms such as HTTP Basic in the first place. .

Fail up with Autodiscover

The real job of the Autodiscover protocol is the simplification of account setup – you might be able to rely on a normal user to remember their email address and password, but decades of computing have taught us than asking them to remember and correctly enter details like POP3 or IMAP4, TLS or SSL, TCP 465 or TCP 587, and the addresses of the actual mail servers are several bridges too far away.

The Autodiscover protocol allows normal users to set up their own e-mail accounts without assistance, by storing all non-private parts of the account setup on publicly accessible servers. When you set up an Exchange account in Outlook, you provide it with an email address and password: for example, [email protected] with password Hunter2.

Armed with the user’s email address, Autodiscover allows you to find configuration information in a published XML document. It will try both HTTP and HTTPS connections, to the following URLs. (To note: contoso is Microsoftism, representing an example domain name rather than a specific domain.)

  • http (s): //
  • http (s): //

So far all is well, we can reasonably assume that anyone who has permission to place resources in either or his Autodiscover subdomain received explicit trust from the owner of himself. Unfortunately, if these initial connection attempts fail, Autodiscover will retreat and try to find resources in a higher level domain.

In this case, Autodiscover’s next step would be to research /Autodiscover/Autodiscover.xml to himself, as well as If this fails, Autodiscover fails again, this time sending email and password information to himself.

It would be bad enough if Microsoft had– but the reality is considerably more murky. This domain was originally registered in 2002 and is currently owned by an unknown person or organization using the GoDaddy WHOIS Privacy Shield.

Guardicore’s results

In the roughly four months Guardicore ran its test id trap, it collected 96,671 unique sets of clear text messaging usernames and passwords. These credentials came from a wide variety of organizations: publicly traded companies, manufacturers, banks, power companies, etc.

Affected users do not see HTTPS / TLS errors in Outlook, when Autodiscover protocol fails from To, the protection offered by contosoownership of its own SSL certificate disappears. The one who bought– in this case Guardicore – simply provides its own certificate, which satisfies TLS warnings even if it does not belong to contoso at all.

In many cases, Outlook or a similar client will initially offer its user’s credentials in a more secure format, such as NTLM. Unfortunately, a simple HTTP 401 from the web server requesting HTTP Basic authentication in its place is all that is needed, which the client using Autodiscover will comply with (usually without errors or warnings to the user) and send the credentials. in Base64-encoded plain text, fully readable by the web server responding to the Autodiscover request.


The real bad news here is that, from the perspective of the general public, it is no mitigation strategy for this Autodiscover bug. If your organization’s Autodiscover infrastructure is having a bad day, your customer will “fail” as described, potentially exposing your credentials. This flaw has not yet been fixed. According to Jeff Jones, senior manager of Microsoft, Guardicore publicly disclosed the flaw before reporting it to Microsoft.

If you are a network administrator, you can mitigate the problem by denying DNS requests for Autodiscover domains. If every resolution request for a domain that begins with “Autodiscover” is blocked, the Autodiscover protocol will not be able to disclose credentials. You still have to be careful: you might be tempted to “block” such requests by returning, but it can allow a smart user to discover someone else’s email address and / or Active Directory credentials, if they can trick the target to connect to the PC from the user.

If you are an app developer, the solution is simpler: don’t implement the flawed part of the Autodiscover specification in the first place. If your app never tries to authenticate to an “upstream” domain, it won’t disclose your users’ credentials through Autodiscover.

For more technical details, we strongly recommend Guardicore’s own blog post as well as Microsoft’s Autodiscover Documentation.

List image by Just_Super via Getty Images


Leave A Reply

Your email address will not be published.