If you have correctly configured Autodiscover records, then the “fail-up” behaviour should never be used, even if a particular add-in, client library or configuration setting can cause it.
And make sure that you know what clients consume Autodiscover, just in case there’s a real flaw lurking here that attackers can exploit across a range of Exchange server versions and clients.”
“ Check your Autodiscover settings to make sure that they comply with Microsoft guidance. In short, make sure you do as Tony recommended last week: What should you do to protect your organization? It’s also disappointing that this information hasn’t been shared publicly so organizations can resolve any underlying misconfiguration – but I’d suspect that the researcher doesn’t have access to the client environments sending credentials to perform some troubleshooting. As Tony says, without technical information describing the affected configuration, it’s difficult to say. Last week, Tony provided some insight into what might be happening, as clearly unusual behaviour was observed. However, as demonstrated last week, Outlook doesn’t appear to perform the “fail up” behaviour described when observing traffic using Fiddler to log actual HTTP and HTTPS requests issued by a standard, up to date, Outlook client. In the log excerpt Guardicore provided, a build of Outlook is shown – 1, dated approximately one month before the logs were recorded in May 2021. It wouldn’t be surprising to find third-party applications implementing fail-up or recursive behaviour in their applications, but not in Outlook itself. In particular, the SRV lookup is often missed, and non-Microsoft clients can ultimately do whatever they want. There could be seemingly valid reasons why someone would do this as a workaround – such as for cases where the User Principal Name didn’t match the email address (for example, a UPN of versus an email address of Why is a recent Outlook build shown in Guardicore’s logs?Īs most Exchange administrators know, but not all email clients (especially those on mobile devices) following Microsoft’s standards to the letter is incredibly important. So, the most obvious conclusion is that a developer has built an Autodiscover implementation that “fails up” – or potentially even recursively fails up. Therefore, unless a user enters an email such as or it should not attempt to query the TLD. Modern Outlook clients for Exchange Online go one step further and use the Direct Connect for Office 365 feature to bypass Autodiscover when a mailbox exists in the cloud. After querying Active Directory for a Service Connection Point (defined Autodiscover URLs contained within each server object in the Configuration Container) the next step should be two standard endpoints based only upon the domain name part of the user’s email address.įrom there, the client should try alternatives including an unauthenticated GET request to a HTTP endpoint, with an expectation of a 302 redirect response (as Exchange Online uses as part of the autodiscover process) and finally attempting a DNS query for SRV records. The developer documentation on the Autodiscover protocol is clear. One key point is that the purported flaw – a “fail up” behaviour – isn’t how Exchange Autodiscover is meant to function, pointing th a bug in implementation rather than the design of the protocol itself. The Autodiscover protocol isn’t mean to have the “fail-up” flaw Even though it seems so far, the issue is hard to replicate, it shouldn’t distract you from similar issues that aren’t new – and more importantly, the work you need to do to protect your organization from the underlying reason why people want your credentials. Last week, Tony provided insight into this and tested to see whether Outlook exhibits the purported flaws.
It’s helpful when security researchers such as Guardicore shed light on flaws in Microsoft Exchange.
0 kommentar(er)
