Researchers at a cybersecurity startup called Guardicore just published a report about an experiment they conducted over the past four months…
…in which they claim to have collected hundreds of thousands of Exchange and Windows passwords that were inadvertently uploaded to their servers by unsuspecting Outlook users from a wide range of company networks.
The problem, according to the rearchers, is down to a Microsoft feature known as Autodiscover, which is used by various parts of Windows, notably Outlook, to simplify the setup of new accounts.
For example, if I want to hook up Outlook on my laptop to “the Exchange server” that’s run by IT, I don’t need to know and type in a whole pile of technical specifications correctly before I get as far as setting up a password and sending my first email.
Left. Opening form in setup process.
Right. Next step in autodiscover setup.
If you’ve ever gone through the process, you’ve probably seen the two simple setup screens above, where you put in your email address, tell it you’re looking for an Exchange server, and Outlook goes out and autodiscovers the configuration details for you.
The Autodiscover process
Microsoft’s autodiscover process can include numerous different steps, as explained in its own Autodiscover documentation, and different apps may use slightly different variants on the Microsoft’s central theme.
For email accounts, Autodiscover typically involves creating a short list of URLs where configuration file data can be expected, and then trying to access those URLs and fetch the setup data that’s stored there, until one of them succeeds (or all of them fail).
For an email address such as
email@example.com, as shown above, the documentation suggests that you’d look for the following configuration files:
Indeed, when we tried setting up Outlook 2016 on a network with no autodiscover files or servers present, and where we therefore expected Outlook to go through its entire repertoire of possible autodiscover file locations, we observed it looking for the following sequence of network names within our own domain:
autodiscover.naksec.test naksec.test _autodiscover._tcp.naksec.test
(The last request above was a DNS lookup known as an SRV record, a common way of looking up server names for specific services, including autodiscover, in Microsoft domains. The the data returned by that SRV record is, like the previous two items, under the control of the owner of the
naksec.test domain, given that the DNS name is a subdomain of
Accoring to Guardicore, however, in their tests – perhaps conducted with an older version of Windows and Outlook, but we’re not sure – there was an extra step in the process, namely that if both of these sites failed…
autodiscover.naksec.test <--if this failed naksec.test <--and this failed
…then the autodiscover code would go up one more step in the domain hierarchy, and would also try:
autodiscover.test <--then Guardicore reported that this site was tried as well
External domains considered harmful
That looks dangerous, because the owner of the domain
naksec.test gets to control the usage of the servername
autodiscover.naksec.test, but the domain
autodiscover.test could belong to someone else entirely.
And that third-party owner could have registered it maliciously, specifically intending to keep an eye out for accidental “autodiscover request spillage” from inside other people’s networks.
We’re guessing that if the email address had actually been
firstname.lastname@example.org rather than merely
email@example.com, as it might be in a country with a striclty two-level commercial domain system such as New Zealand (
.co.nz) or South Africa (
.co.za), then Guardicore’s sequence might have been…
autodiscover.naksec.co.test naksec.co.test _autodiscover._tcp.naksec.co.test
…as in the example above, followed by:
autodiscover.co.test <--back up one domain level autodiscover.test <--and then one more as well
That could, in theory, expose you first to a sneakily registered domain called
autodiscover.co.test, followed (if that failed) by the same, uncertain
autodiscover.test domain referred to above. (Some two-level domain countries sell both second-level domains, e.g.
.co.uk, and top-level domains e.g.
Guardicore therefore went out and registered a whole raft of “autodiscover” domains in various two-level and one-level domain hierarchies, and set up listening web servers on all of them, including:
Autodiscover.com.br Autodiscover.com.cn Autodiscover.com.co Autodiscover.es Autodiscover.fr Autodiscover.in Autodiscover.it Autodiscover.sg Autodiscover.uk Autodiscover.xyz Autodiscover.online
The researchers claim that over the next four months, they collected more than 1,000,000 unsolicited and unexpected autodiscover requests, of which a significant minority included authentication tokens or plaintext passwords that could, in theory, give access to the leaked accounts.
Worse still, they say, their fake autodiscover servers, when faced with logon information such as NTLM credentials from which the orginal password could not be recovered, were frequently able to reply to the sender with a “please downgrade” response that caused the client software at the other end (presumably Outlook) to try again using HTTP
Basic Authentication, the password isn’t salted or hashed in any way to protect it from being reversed and recovered.
Instead, the password is merely encoded using the base64 algorithm, so that the original data can be extracted as needed.
How bad is this?
Clearly, for most companies with Outlook clients trying to autodiscover Exchange servers on the corporate network, this sort of data leakage can be considered unlikely.
All the internal locations where the autodiscover data would usually be found would need to fail first, leaving only the under-the-control-of-someone-else domains left to receive the request.
Additionally, the appropriate autodiscover domain would need to be registered, and active, and in the hands of an owner whose intention was to abuse it to collect rogue password and authentication data.
Nevertheless, Guardicore’s own researchers claim to have seen and collected a significant amount of traffic over a four-month period, plus tens or hundreds of thousands of unique passwords.
So the risk is worth thinking about, especially if your network is usually immune (because it has its own autodiscover servers that will usually answer first), but might “fail open” unexpectedly (if there’s an internal network outage that would suddenly cause clients to go looking for autodiscover servers externally).
What to do?
- Consider blocking external domains that start with the text
autodiscoverat your web filtering firewall. That will stop any app inside your network from hooking up with rogue, external autodiscover servers in the first place. Note that you will may need to add some legitimate cloud sites to your allowlist, e.g.
autodiscover.outlook.com, but we can’t ourselves remember ever visting a regular website or online property that was called “Autodiscover”.
- Consider activating Outlook’s Disable Autodiscover protection using Group Policy. In the GPEDIT policy editor or from the Group Policy Management Console, go to User Configuration > Administrative Templates > Microsoft Outlook 2016 [amend by version] > Account Settings > Exchange. Click on
Disable Autodiscover, choose
[Enable]and turn on Exclude the query for the AutoDiscover domain. According to Microsoft, this means that “Outlook [will] not use the following URL: https://autodiscover.[DOMAIN]]/autodiscover/autodiscover.xml”.
Note that you will need to install Microsoft’s Administrative Template files for Microsoft 365 and Office, or else the Microsoft Outlook Group Policy items described above above will not appear.
If you don’t have the template files installed, or don’t want to use GPEDIT or Group Policy for this process, you can turn on the setting in the registry yourself.
Registry Key: HKCU\software\policies\microsoft\office\[VERSIONNUMBER]\outlook\autodiscover Create Value: excludehttpsautodiscoverdomain Value type: DWORD Set value to: 1
What we observed
As simple as the Group Policy workaround might sound, and as much as Microsoft’s own help file for Office group policy settings seems to reassure you that the setting we’ve listed will suppress the use of “autodiscover” domain names…
…we have to say that this wasn’t how things worked out in our own (necessaril brief) tests.
The bad news is that, even after setting the
excludehttpsautodiscoverdomain option, we nevertheless observed Outlook 2016 trying to locate
autodiscover.naksec.test in our experiments. (We also tried with realistic external TLD and 2LD domains, e.g. .FR and .CO.ZA.)
The good news is that we were unable to provoke Outlook to visit any domains that would have been outside our own network.
In other words, using an email domain of
naksec.test, we were unable to get Outlook to try
autodiscover.test, even after
autodiscover.naksec.test had failed. (Once again, we also tested this behaviour with realistic external TLD and 2LD domains.)
So although we couldn’t get our own workaround (based on Microsoft’s documentation) to work…
… we simply couldn’t get the “Autodiscover Great Leak” hack to work in the first place either (based on Guardicore’s paper).
Whether that means you’re safe as long as you are using Office 2016, and Guardicore is wrong, we can’t be sure – we can only tell you that it’s what we observed on a standalone Windows 10 Enterprise computer when we tried to connect to a non-existent Exchange server.
If you have earlier versions of Outlook, or other email clients that you can try on your own network while monitoring the network requests from the relevant app, we’d love you to share your results below!