Thanks to James Cope and Rajeev Kapur of Sophos IT for their help with this article.
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 researchers, 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.
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 duck@naksec.test, as shown above, the documentation suggests that you’d look for the following configuration files:
https://autodiscover.naksec.test/autodiscover/autodiscover.xml https://naksec.test/autodiscover/autodiscover.xml
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 naksec.test.)
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 duck@naksec.co.test rather than merely duck@naksec.test, as it might be in a country with a strictly 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 <--go back up one domain level autodiscover.test <--and then go back up one more as well
That could, in theory, expose you first to a sneakily registered third-party 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. .uk.)
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.
In 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 follow-up requests.
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 scoop up password and authentication data that it was not supposed to receieve at all.
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 word
autodiscover, using your web filtering firewall. That will stop any app inside your network from connecting inadvertently to 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 with a name that started with the word “Autodiscover”. - Consider activating Outlook’s
Disable Autodiscoverprotection 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 number by version] > Account Settings > Exchange. Click onDisable Autodiscover, choose[Enable]and turn onExclude 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: HKCUsoftwarepoliciesmicrosoftoffice[VERSIONNUMBER]outlookautodiscover 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 (necessarily 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 and watched Outlook run through its autodiscover list – our result was different from the behaviour described by Guardicore.
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!