Nov 2, 2021
0 0

Microsoft Exchange Autodiscover flaw reveals users’ passwords

Written by

We research. You level up.
Protect your devices, your data, and your privacy—at home or on the go.
“Thanks to the Malwarebytes MSP program, we have this high-quality product in our stack. It’s a great addition, and I have confidence that customers’ systems are protected.”
Featured Event: RSA 2021
Activate Malwarebytes Privacy on Windows device.
Cybersecurity Month: Save 25% on EP and EDR for your business – BUY NOW

Exploits and vulnerabilities
Posted: by
Last updated:
Researchers have been able to get hold of 372,072 Windows domain credentials, including 96,671 unique credentials, in slightly over 4 months by setting up a Microsoft Exchange server and using Autodiscover domains.
The credentials that are being leaked are valid Windows domain credentials used to authenticate to Microsoft Exchange servers.
From Microsoft’s site we learn that “the Autodiscover service minimizes user configuration and deployment steps by providing clients access to Exchange features. For Exchange Web Services (EWS) clients, Autodiscover is typically used to find the EWS endpoint URL. However, Autodiscover can also provide information to configure clients that use other protocols. Autodiscover works for client applications that are inside or outside firewalls and in resource forest and multiple forest scenarios”.
Which boils down to a feature of Exchange email servers that allows email clients to automatically discover email servers, provide credentials, and then receive proper configurations. Designed to make the user’s life easier while forgetting that such designs need to be done with security in mind. Because cybercriminals love such features and use them for their own purposes.
The protocol’s goal is to make an end-user be able to completely configure their Outlook client solely by providing their username and password and leave the rest of the configuration to Microsoft Exchange’s Autodiscover protocol.
To accomplish this the Autodiscover protocol looks for a valid Autodiscover URL in these formats, where the is replaced by the domain name (the part after the @) in the users’s email address:
This means that to start with, Autodiscover is looking for a URL at a domain or subdomain that is owned by the organization the user belongs to, so mistakes are contained and unlikely to cause problems. But, and here it comes, if none of the above send a valid response the process gets wonky, where it should probably have given up.
If those attempts fail, the next attempt to build an Autodiscover URL drops the part that confines lookups to the user’s organization and looks here:
This gives whoever owns the domain a huge opportunity.
And the same is true for other Autodiscover top-level domains (TLDs) too, such as, which will receive requests from all unresponsive .es domains.
To complete the mess, there is no login procedure required on the server side. The unsuspecting user trying to set up their Exchange account is just sending their credentials to an unknown server. There is also no attempt on the client’s side to check if the resource is available, or even exists on the server, before sending an authenticated request.
It is important to understand that since Microsoft Exchange is part of the Microsoft domain suite of solutions, the credentials that are necessary to login to an Exchange-based inbox are in most cases the same as their domain credentials. The possible consequences of a domain credential leak at such a scale are enormous, and can put entire organizations in danger. Especially in the light of the ongoing ransomware attacks that are daily news. What easier way could an attacker ask for than to gain entry into an organization by using legitimate and valid credentials?
A quick search on my part learned that in most of the big TLDs the autodiscover domains have already been picked up.
Some of the most dangerous ones have been registered by the researchers to do their testing.
Organizations can protect themselves by establishing their own Autodiscover domains, and blocking Autodiscover.TLD domains at the firewall or in their local DNS. Users can block Autodiscover.TLD domains in their hosts file.
Software vendors and developers who are implementing the Autodiscover protocol in their products should make sure that they are not letting it “fail upwards”, meaning that domains such as autodiscover. should never be constructed by the “back-off” algorithm.
When deploying or configuring Exchange server setups, organizations should also make sure that support for basic authentication is disabled. Using HTTP basic authentication sends credentials in clear text, making them easy to intercept.
When a user is being redirected to an Autodiscover.TLD server trying to make use of the leak, a security alert might pop up if it doesn’t have a security certificate, or if it has one that is self-signed. This could easily be avoided by the attacker if they deploy a valid TLS certificate though.
Microsoft was not informed of the problem before the credential harvesting was set in motion and the results were already published, so they are still investigating and promised to take appropriate steps to protect customers.
Stay safe, everyone!
A week in security
October 4, 2021 – A roundup of the previous week’s important security news and related happenings, for the week of September 27 – October 3.

Malware Intelligence Researcher
Was a Microsoft MVP in consumer security for 12 years running. Can speak four languages. Smells of rich mahogany and leather-bound books.
Silouette of person

Threat Center

Book with bookmark

Suspicious person

Write for Labs

Want to stay informed on the latest news in cybersecurity? Sign up for our newsletter and learn how to protect your computer from threats.
Imagine a world without malware. We do.
© All Rights Reserved
Select your language
Cybersecurity basics
Your intro to everything relating to cyberthreats, and how to stop them.


Article Categories:

Comments are closed.