Introduction

During a recent incident response investigation, we encountered an interesting authentication issue in an on-premises Microsoft Exchange environment. The organization had implemented Hybrid Modern Authentication (HMA), allowing Microsoft Outlook to authenticate against Microsoft Entra ID using OAuth tokens. Multi-factor authentication was enforced through the organization’s Microsoft 365 configuration. However, while investigating the Exchange logs, we found thousands of successfully authenticated EWS requests from another client using NTLM.

How could NTLM authentication still succeed when the organization had implemented Hybrid Modern Authentication and required MFA? The answer was an externally accessible legacy authentication path that operated independently of Microsoft Entra ID.

Understanding Hybrid Modern Authentication

In a traditional on-premises Exchange deployment, clients can authenticate directly against Exchange using mechanisms such as Basic Authentication, NTLM or Kerberos. Authentication is handled locally, typically with the help of Active Directory. Hybrid Modern Authentication introduces an additional mechanism. Instead of authenticating directly to Exchange using Windows authentication, a supported client obtains an OAuth access token from Microsoft Entra ID. Exchange then validates the token and grants access to the mailbox. The mailbox itself remains on-premises. Only the authentication and token issuance process involves the cloud identity provider.

A simplified authentication flow looks like this:

1. Outlook attempts to access an on-premises Exchange mailbox.
2. Outlook is directed to Microsoft Entra ID for authentication.
3. Microsoft Entra ID evaluates the applicable authentication requirements, including Conditional Access and MFA.
4. Following successful authentication, Outlook receives an OAuth access token.
5. Outlook presents the token to the on-premises Exchange server.
6. Exchange validates the token and grants access to the mailbox.

Modern Authentication Is Not Necessarily Exclusive

One of the interesting details in Microsoft’s documentation is an example of an Exchange virtual directory configured with multiple authentication mechanisms (IISAuthenticationMethods):

• NTLM
• OAuth
• Negotiate

At first glance, this might appear contradictory. Why would NTLM still be enabled if the purpose of Hybrid Modern Authentication is to use OAuth? The explanation is that Exchange supports multiple client authentication mechanisms for compatibility. Enabling OAuth does not necessarily mean that every existing authentication mechanism is disabled. Microsoft explicitly documents the possibility of blocking legacy authentication in Exchange 2019 hybrid deployments through authentication policies. Importantly, Microsoft includes Windows authentication, meaning both NTLM and Kerberos, in the mechanisms that these policies can block.

Back To Our Incident Response Case

The Exchange server was configured to support Hybrid Modern Authentication, and ordinary Outlook clients were successfully authenticating using OAuth bearer tokens. However, an additional client was accessing Exchange Web Services (EWS) through the endpoint https://mail.example.com/EWS/Exchange.asmx. The IIS logs contained large numbers of requests with a Mozilla Thunderbird user-agent. The Thunderbird user-agent was unusual in this environment, where most users accessed Exchange through Outlook and other Microsoft clients. Its high request volume and prolonged activity made it stand out during the initial log analysis.

Nevertheless, an unusual user-agent alone does not establish which authentication method was used. IIS logs typically tell us which URL was requested, which account was associated with the request, and how the server responded. They do not necessarily provide sufficient information to distinguish OAuth from NTLM. For that, we turned to the Exchange HttpProxy logs.

Exchange HttpProxy Reveals the Authentication Method

During the available logging period, we identified 66,610 successfully authenticated EWS requests associated with the Thunderbird user-agent. All used NTLM authentication. Interestingly, the same mailbox was also accessed by legitimate clients using OAuth bearer tokens. The HttpProxy logs therefore demonstrated that Exchange accepted both authentication mechanisms for the same account.

Why NTLM Did Not Trigger MFA

NTLM uses a challenge-response authentication mechanism. Rather than sending an OAuth bearer token issued by Microsoft Entra ID, the client proves possession of suitable authentication material through an exchange of cryptographic messages. In a domain environment, Exchange can validate the authentication through Windows and Active Directory infrastructure. Crucially, this process does not require an OAuth access token from Microsoft Entra ID. As a consequence, Microsoft Entra Conditional Access policies are not evaluated as part of this NTLM authentication flow.

This does not mean that NTLM automatically bypasses every conceivable MFA solution. An organization could enforce additional authentication at a reverse proxy or another access layer. However, such a control was not established by the available evidence in this case. The distinction matters because it would be misleading to say that the attacker defeated MFA. We found no evidence of MFA fatigue, stolen OAuth tokens, adversary-in-the-middle phishing against Entra ID or a vulnerability in the MFA implementation. Instead, the Exchange server accepted a different authentication method that never invoked Entra MFA in the first place.

It is also important to distinguish NTLM from HTTP Basic Authentication. Although both are considered legacy authentication mechanisms in this context, NTLM does not transmit the user’s plaintext password as part of an ordinary challenge-response exchange.

Another Authentication Path: Outlook on the Web

The EWS access was not the only interesting finding. We also observed successful access through Outlook on the Web (OWA). The corresponding Exchange HttpProxy records contained:

• Protocol: OWA
• AuthenticationType: FBA
• IsAuthenticated: true
• HttpStatus: 200

FBA stands for Forms-Based Authentication, the traditional Exchange web login mechanism. In the investigated environment, OWA accepted authentication directly at the on-premises Exchange server instead of redirecting the user to Microsoft Entra ID. This constituted a second authentication path outside the organization’s Entra MFA flow. It is worth mentioning that this is not an inherent limitation of OWA. Microsoft supports Hybrid Modern Authentication for OWA and the Exchange Control Panel (ECP) on supported Exchange versions. With the appropriate configuration, users accessing OWA can be redirected to Microsoft Entra ID for authentication. However, enabling HMA for Outlook does not automatically mean that OWA and ECP use the same authentication method.

Microsoft introduced support for HMA on OWA and ECP with Exchange Server 2019 CU14, requiring the April 2024 Hotfix Update or a later update. Administrators must configure these endpoints separately, including disabling the existing authentication methods before enabling OAuth.

How to Identify This Configuration

The easiest starting point is to inspect the authentication settings of the Exchange virtual directories.

The following commands can be executed in the Exchange Management Shell:

Get-MapiVirtualDirectory |
Format-List Server,*url*,*auth*

Get-WebServicesVirtualDirectory |
Format-List Server,*url*,*auth*

Get-OwaVirtualDirectory |
Format-List Identity,*url*,*auth*

Get-EcpVirtualDirectory |
Format-List Identity,*url*,*auth*

For EWS, the objective is to determine whether OAuth is enabled and which other authentication methods remain available. However, the presence of WindowsAuthentication=True does not, by itself, prove that every user can successfully authenticate using NTLM. Authentication policies can block legacy authentication for individual users or across the organization. Consequently, virtual directory configuration is only part of the assessment.

Checking Authentication Policies

Exchange Server 2019 supports authentication policies that restrict legacy authentication on a per-protocol basis. The following commands provide an overview of the configured policies and their effective assignment:

Get-AuthenticationPolicy |
Format-List Name,BlockLegacyAuth*

Get-OrganizationConfig |
Format-List DefaultAuthenticationPolicy

Get-User -ResultSize Unlimited |
Where-Object {$_.AuthenticationPolicy -ne $null} |
Select-Object Name,AuthenticationPolicy

Blocking legacy authentication does not automatically migrate every client protocol to OAuth. Hybrid Modern Authentication is not supported for IMAP, POP or Outlook Anywhere (RPC/HTTP). Restricting legacy authentication for these protocols may therefore prevent affected clients from connecting entirely. Administrators should identify protocol dependencies before applying the policy. The organization-wide default authentication policy applies to users who do not have an explicitly assigned authentication policy. An administrator might correctly configure a restrictive default policy while a subset of accounts continues using a permissive exception. In environments with older integrations, service accounts and migration software, such exceptions may have accumulated over time.

How to Secure Hybrid Exchange

Microsoft provides an explicit mechanism for disabling legacy authentication in Exchange 2019 hybrid environments. The relevant parameter for EWS is -BlockLegacyAuthWebServices. According to Microsoft’s documentation, this setting blocks Basic Authentication, Digest Authentication and Windows Authentication, including NTLM and Kerberos, for the affected users.

An example of configuring a restrictive policy is:

Set-AuthenticationPolicy -Identity "OrgWideDefault" `
  -BlockLegacyAuthWebServices `
  -BlockLegacyAuthMapi `
  -BlockLegacyAuthActiveSync `
  -BlockLegacyAuthAutodiscover `
  -BlockLegacyAuthImap `
  -BlockLegacyAuthPop `
  -BlockLegacyAuthRpc `
  -BlockLegacyAuthOfflineAddressBook

This assumes that the OrgWideDefault policy already exists. The configuration should be tested before applying it in production because older clients, migration endpoints and custom applications may depend on legacy authentication. The policy also needs to be assigned correctly, either as the organization-wide default or directly to the appropriate accounts. OWA requires separate consideration. Administrators should either configure HMA for OWA and ECP according to Microsoft’s documented requirements or restrict access to those services appropriately.

ECP should also be assessed independently because it provides administrative capabilities. Finally, the external publishing architecture matters. A reverse proxy or WAF does not automatically enforce Microsoft Entra MFA. Unless the infrastructure implements an appropriate supported authentication control, it may simply forward requests to Exchange, including requests that use legacy authentication.

Conclusion

This case demonstrates that enabling Hybrid Modern Authentication does not necessarily eliminate legacy authentication paths in an on-premises Exchange environment. Although Outlook clients authenticated through Microsoft Entra ID with MFA enforced, the same mailbox remained accessible through EWS using NTLM. We identified 66,610 authenticated NTLM requests, demonstrating that this was not merely a theoretical configuration weakness. Additionally, OWA accepted Forms-Based Authentication independently of Microsoft Entra ID.

The attacker did not need to bypass MFA. Instead, they used authentication mechanisms that never invoked Microsoft Entra MFA in the first place. The key takeaway is simple: enabling MFA is not the same as enforcing MFA across every authentication path. Organizations running Hybrid Exchange should verify which authentication mechanisms are actually accepted, restrict legacy authentication, and independently assess OWA and ECP. Otherwise, a properly secured modern authentication flow can coexist with an exposed legacy entry point.

References

• Microsoft – How to configure Exchange Server to use Hybrid Modern Authentication
• Microsoft – Block legacy authentication in Exchange 2019 hybrid
• Microsoft – Set-AuthenticationPolicy