Modern Authentication, Legacy Problems

What it is

A DFIR field note on a hybrid on-premises Exchange environment where Hybrid Modern Authentication (HMA) and Entra MFA were in place, yet the same mailbox stayed reachable through two legacy paths that never called Entra ID. The authors found 66,610 successful EWS requests with a Mozilla Thunderbird user-agent, all using NTLM, plus OWA logins using Forms-Based Authentication (FBA). The page states there was no MFA bypass: Exchange accepted a method that never invoked MFA.

How it works

IIS logs show URL, account and response, but not whether a request used OAuth or NTLM. The Exchange HttpProxy logs do. The same account appeared with OAuth bearer tokens from Outlook and with NTLM from Thunderbird, so Exchange accepted both.

NTLM is a challenge-response validated through Windows and Active Directory. No Entra token is issued, so Conditional Access is not evaluated. The OWA records showed Protocol: OWA, AuthenticationType: FBA, IsAuthenticated: true, HttpStatus: 200. OWA authenticated directly on the Exchange server instead of redirecting to Entra ID.

Preconditions / Affected

• Exchange virtual directories with Windows authentication or FBA still enabled alongside OAuth.
• Exchange reachable externally, with no authentication policy blocking legacy auth for the account. The default policy applies only to users without an explicit assignment, so permissive per-user exceptions can persist.
• A reverse proxy or WAF does not enforce Entra MFA by itself and may forward legacy-auth requests unchanged.
• HMA for OWA and ECP needs Exchange Server 2019 CU14 with the April 2024 Hotfix Update or later. It must be configured separately from Outlook's HMA, and existing authentication methods must be disabled before OAuth is enabled.

What to do

Inspect virtual directory authentication 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*

Check which policies exist and who is assigned one:

Get-AuthenticationPolicy |
Format-List Name,BlockLegacyAuth*
Get-OrganizationConfig |
Format-List DefaultAuthenticationPolicy
Get-User -ResultSize Unlimited |
Where-Object {$_.AuthenticationPolicy -ne $null} |
Select-Object Name,AuthenticationPolicy

Block legacy authentication (assumes the OrgWideDefault policy already exists):

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

-BlockLegacyAuthWebServices blocks Basic, Digest and Windows authentication (NTLM and Kerberos) for EWS. Assign the policy as the organization default or directly to accounts. Handle OWA and ECP separately: configure HMA for them or restrict access. ECP gives administrative capability, so assess it on its own. To hunt for past abuse, search HttpProxy logs for NTLM on EWS and for FBA on OWA, and look for unusual user-agents.

Caveats

• WindowsAuthentication=True on a virtual directory does not prove every user can use NTLM, because authentication policies may block it. Configuration is only part of the assessment.
• HMA is not supported for IMAP, POP or Outlook Anywhere (RPC/HTTP). Blocking legacy auth for those protocols can cut off clients, so identify dependencies and test first. Older integrations, service accounts and migration tools are likely dependents.
• The authors say an organization could enforce extra authentication at a reverse proxy, but the evidence in this case did not show one.
• NTLM is not Basic authentication: it does not send the plaintext password in an ordinary exchange.
• The page does not say how the attacker got credentials or what they did with the mailbox.