It's often helpful when security researchers like Guardicore shed light on flaws in Microsoft Exchange - however, the Autodiscover protocol isn't flawed in the way they describe. Even though the issue is hard to replicate, it shouldn't distract from the work you need to do to protect your organization from the underlying reason why people want your credentials.
Lots of excitement was generated when Guardicore revealed a purported vulnerability with the Exchange Autodiscover service. However, the almost total lack of detail about the configuration used for testing and to generate the reported results makes it impossible for Exchange administrators to check the theory against their own deployment. I don't think a problem exists with Exchange Online, but it's possible that poor DNS practice or flawed third-party clients could cause an issue with on-premises servers. The case remains to be proved.
How to fix Exchange Server Autodiscover failures for ActiveSync mobile devices due to HTTPS issues with root domain lookups.
Outlook clients may begin displaying a security alert warning dialog after an Exchange 2013 server installed into an existing organization.
Some considerations for Autodiscover when planning an Exchange 2013 deployment in an existing Exchange 2010 organization.
Using the Test-OutlookWebServices PowerShell cmdlet to test web services in Exchange Server 2013.
A run down of some of the common concerns people have when installing the first Exchange 2010 server into their production environment.
How to publish different Exchange ActiveSync URLs for multiple geographic locations with Autodiscover in Exchange Server 2010.
How to configure your Exchange 2010 SSL certificate to include the correct Autodiscover names.