Skip to content
Naked Security Naked Security

How Outlook “autodiscover” could leak your passwords – and how to stop it

The Microsoft Autodiscover "Great Leak" explained - and how to prevent it

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.

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 duck@naksec.test, 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:


(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 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.)

According 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 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 ( or South Africa (, then Guardicore’s sequence might have been…

…as in the example above, followed by:      <--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, 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., 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:

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 original 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 receive 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 may need to add some legitimate cloud sites to your allowlist, e.g., 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 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 number 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”.
Group Policy setting for regulating Autodiscover
Group Policy setting that supposedly prevents “autodiscover” domain names being used.

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 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
Registry entry that supposedly prevents “autodiscover” domain names being used.

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

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!


Hi, could you please be more specific in how to block autodiscover urls in sophos webfilter?
We tried to create a category and add all the urls listed on the github page provided by guardicore but sophos XG says “Max “2000” URLs are allowed in custom category, remaining are discarded
Some invalid URLs are discarded”
Another way was to try to setup a wildcard but this is not allowed in categories and also not in url groups.
So we are wondering how to achiev a webfilter policy using the guardicore list or maybe just a autodiscover.* Wildcard?


I’m afraid we’re not in a position to give product support on Naked Security… you’ll need to go through your ususal support channels..

If you can’t cover all “autodiscover.*” domains in your blocklist (e.g. because there are too many possibilities now that top-level domains aren’t limited to countries but include companies, brand names, activities and more), you could simply limit your list to domains on which your company does operate email domains, given that users are unlikely – though admittedly not impossible – that a user looking to set up an account on “” would type in “” by mistake… and, of course, if they did that then they would be misdirecting their traffic to a domain someone else could already have registered anyway.

In other words, if you are worried about” turning into “” even though a user did everything correctly, because your true domain is “”, I suggest that blocking “” is probably a good starting point if you can’t block all of them. (FWIW, at the time of writing [2021-09-27T17:00Z], SophosLabs blocks as a suspicious domain anyway, along with various other domains that have apparently already been associated with dubious data collection, though I don’t have a complete list ATM.)

Hope this helps. Sorry I can’t give support directly here.


What about (the web version)?


Different kettle of fish – in that case the interaction is directly between your browser and, and the account setup and configuration data is handled directly by the site that you’ve already navigated to.

(Though you still need to be cautious for data-diversion trickery of course, just not the sort described in the article. You need to ensure you don’t end up on an imposter site that could capture your password instead of the real, for example, or that if you use a password manager to log you in every time, that you don’t let rogue apps get access to the password manager’s database.)


But could be accessing via Outlook Desktop App too.


The OP specifically asked about “the web version”.

AFAIK, setting up the Outlook Desktop App to use will not suffer at the hands of this trick (if indeed it still works with the current Desktop App version of Outlook) because will take care of the “discovery”.


And please, for the love of all that is good, limit your browser extensions. Because it doesn’t matter if you have a strongly encrypted connection to the real if you have “Super Happy Fun Free Extension” that “Can read and change data on all websites” – that’s a man in the middle right there.


Just confirming this is with on-premise Exchange Server or does that not matter? Also what can we do about non-domain joined computers? In this WFH era with MS365/Office365 it’s very difficult to control that if at all. I guess the other thing is that many organisations are still running Exchange on-premise even though everything has been migrated to EOL (Office 365) as AD attributes are still required for this until Microsoft release an official decommission of the last on-premise Exchange Server tool.

I also wonder about mobile devices and all other 3rd party email clients that have the ability to connect to Exchange or Office365 and if they do the same autodiscover?


I must admit that I don’t know what happens when you are a corporate customer with a user who’s hooking up to the corporate MS 365 email system but where they still need to get in touch with a company Exchange server first. If they happen to be on a network from which they can reach all of the internet *except* your company domains (e.g. because they are relying on a VPN tunnel that just crashed), is there any chance that their password might end up on a rogue site?

In my experiments with Outlook 2016, I suspect that the answer is no, for two reasons: [a] i didn’t observe this this weird “back up one level” autodiscover domain name behaivour in the first place [b] given that the autosdiscover failed, I got Outlook’s “something went wrong” message after entering my username but I had been asked to offer up a password.

Other email clients may well use a different approach to autodiscover (see the MS documentation link in the article), but if they have followed Microsoft’s guidelines on “where to look”, then they ought not to be doing the “back up one level” process either, because it’s not mentioned at all in the documentation. I haven’t tried any other SMTP clients (alpine, mutt and Thunderbird are the only ones I can think off the top of my head that are still going strong because I keep getting updates to them via my Linux distro :-) so I can’t tell you if any of them still have, or indeed ever had, the weird “back up” behaviour described by Guardicore.


“Disable AutoDiscover” – Enable
This is one of those badly designed options, where “disable” is in the name of the setting itself, instead of just letting the state tell us, well, the actual state of the setting.


I hear you, but the “not configured/enabled/disabled” radio-button actually applies to the Group Policy editor, and appears on every set of GP settings you can set (if that makes sense).

In other words, to anyone familiar with the exigencies of GPEDIT (which I am not defending, merely stating :-), the “Enabled” button will probably make sense, given that “Disable Autodiscover” is really the name of a family of sub-options, each of which can be adapted individually. So the confusion might not be as acute as it might first appear, at least for any sysadmins who have already got to grips with the almost unknowable sea of options that GPEDIT allows you to fiddle with. (If you have ever tried to use ‘menuconfig’ to review and decide on which Linux kernel options to set before compiling a kernel, you will have experienced the same sort of “unknowability” while ploughing through an interminable list of minutiae, many of which are probably irrelevant on your own computer hardware, but some of which might possibly matter enormously.)

I agree that enabling (verb) the “enabled” (adjective) option to activate the “disable” (verb) options for a “disabled” (adjective) feature would be better avoided. My own preference would be to avoid any linguistic confusion of this sort. In fact, I’d suggest that the “not configured” button is the worst of all – because all the options are set to *something*, even if it’s only the “use default setting if no explicit override is forced”. Letting you know clearly what setting is going to be used *given the current GPEDIT data* would IMO be the clearest way to present this data. You could then choose to “stick with default (may change at Microsoft’s discretion in future”, or “use this explicit setting at all times”).


Indeed reading it now probably know why after implementing the new exchange servers on office365 we get sophos catching all users on setup of outlook account the autodiscovery xml as Troj/ASPDoor-U. The templates for O365 was disabled so it makes some sense. Does anyone experienced it also?


This particular bug – the possible leakage of data to domains outside your network – is independent of what’s actually in the autodisover.xml that Outlook searches for. It’s the act of *searching* for the file that is the issue here, even if there is no autodiscover.xml at the end of it.

So I would treat this as a separate issue, namely that there seems to a file on your network that is being identified as backdoor malware. I suggest you contact Sophos Support and find out what risks it poses, what other side effects you might want to look for, how it might have got there, and so on.

(The fact that you are getting lots of detections right now may be down to the fact that computers on your network that do have Sophos on them are accessing the file, because of Outlook, and triggering the warning every time. One of my concerns, if this case were mine, would have nothing to do with Outlook, it would be this: how come the file was sitting there unnoticed until Outlook came along and caused the warnings to show up? Is there supposed to be an anti-virus on the server that should have noticed this suspicious file before now?)


I’ve done some research on this topic, too. Like many others, I don’t see Outlook doing anything along the lines of Guardicore’s claims, that is, going up the domain hierarchy beyond the original domain (naksec.test in your example) to contact some autodiscover.tld server (e.g. autodiscover.test) during the autodiscover process. That is, on a regular standalone Windows PC.
Therin lies the rub. I think the real problem only manifests itself when you go into corporate networks that make use of Microsoft’s Active Directory and its internal domain names. I haven’t figured out all the details, but I’ve got a hunch: when you use an internal Windows domain name that is the same as an internet top level domain name, this is what causes some Microsoft software to send autodiscover requests to servers outside the corporate network. So the wrong autodiscover.tld hostname that the information is leaked to is not constructed from going up the domain hierarchy too far, but from combining the “autodiscover” keyword with an internal domain name that is the same as a common internet top level domain. As you point out, the number of internet top level domains has increased heavily, so the chances of constructing a valid internet hostname from concatenating the string “autodiscover” with an internal Windows domain name are on the rise these days.

Here’s an example to illustrate my point:
When Guardicore collects login information that is inadvertently sent to their server at “”, this is not because someone tried to set up an email address for the long dead in Outlook and Outlook decided to go for “” because it couldn’t find “”. I believe this is because on some corporate network, there’s an internal Windows domain called “IT” (the IT department needs their own playground, after all), so there will be some guy whose Active Directory “User Principal Name” is “JohnDoe@IT”. Now if “Jane@HR” tries to reach out to John using some Microsoft tool from the Office/Exchange/Sharepoint sphere, this will cause a lookup for John’s contact details. For instance, Jane may try to set up a meeting and this requires a lookup of John’s free/busy information. Or something else along these lines — I don’t know exactly on which occasions autodiscover requests are being sent besides when setting up an email account in Outlook, but I do know that such requests are generated in larger Microsoft environments on a regular basis. So I think it’s Jane’s action that actually causes a request for autodiscover for “JohnDoe@IT”, and this request is now mistakenly sent to “” instead of the company’s own autodiscover server (which could be called “” and might have nothing to do with the internet “.it” domain at all). This means that Guardicore will be catching Jane’s login credentials, not John’s, as Jane will be the one prompted to put in her username and password, which will then be sent in Basic Auth format to “”.

My theory may be missing some bits and pieces, but I think the general scenario I described (there’s a leak of Jane’s login credentials, not John’s nor Gianni’s) is much closer to the truth than Guardicore’s “domain back-off” claims that nobody else can reproduce. So, in a nutshell, my research boils down to this: I accuse Microsoft that some piece of their software (probably not Outlook) falsely applies autodiscover to a user’s UPN when it should apply autodiscover only to that user’s email address. Most of the time, applying autodiscover to the UPN is fine (e.g. when the UPN is “”), but when the UPN uses an abbreviated format (e.g. “JohnDoe@IT”), doing so can have serious security implications.


Is exchange online affected by this vulnerability ?


If you mean Office 365, or Microsoft 365, the answer is “I am not sure.” The problem, such as it is, isn’t so much down to Exchange as to Outlook, and then to which Outlook version you are using. I assume that if your email is 100% cloud based that your users are either using a browser or a recent version of Outlook, in which case (in my tests) the bug didn’t show itself.


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!