CVE-2024-21410: Critical Microsoft

The Vulnerability

Your Exchange Server trusts stolen credentials.

On 13 February 2024, Microsoft disclosed CVE-2024-21410 — a critical privilege escalation vulnerability in Microsoft Exchange Server with a CVSS score of 9.8 out of 10. The vulnerability had already been exploited in the wild as a zero-day before the patch was released. CISA immediately added it to its Known Exploited Vulnerabilities catalogue, mandating federal agencies to remediate by 7 March 2024.

The flaw allows a remote, unauthenticated attacker to relay captured Net-NTLMv2 hashes against a vulnerable Exchange Server and authenticate as the victim user. The attacker does not need to crack the hash. They do not need to know the password. They capture the hash in transit, relay it to Exchange, and the server accepts it as valid authentication — granting the attacker full access to the victim's mailbox and the ability to perform any operation the victim could perform on the Exchange server.

At the time of disclosure, Shadowserver identified approximately 97,000 potentially vulnerable Exchange servers exposed to the internet, of which 28,500 were confirmed vulnerable. Exchange Server remains one of the most widely deployed on-premises email platforms in the world, particularly in medium and large enterprises. The combination of critical severity, zero-day exploitation, a vast attack surface, and the high value of email data makes CVE-2024-21410 one of the most significant Exchange Server vulnerabilities since ProxyLogon and ProxyShell.

Immediate Action Required

If your organisation runs on-premises Exchange Server 2016 or 2019, verify immediately that Extended Protection for Authentication (EPA) is enabled. For Exchange 2019: install Cumulative Update 14 (CU14) or later — EPA is enabled by default from CU14. For Exchange 2016: install the latest security update for CU23, then run Microsoft's ExchangeExtendedProtectionManagement.ps1 script to enable EPA. Servers without EPA enabled remain vulnerable regardless of other patching.

The Technical Detail

How NTLM relay turns your Exchange into the attacker's tool.

CVE-2024-21410 is an NTLM relay attack against Exchange Server. To understand why it works — and why it is so dangerous — you need to understand three things: how NTLM authentication leaks occur, what NTLM relay is, and why Exchange Server was uniquely vulnerable.

CVE-2024-21410 — The Attack Flow
Step 1 — Credential Leak
  Attacker triggers an NTLM credential leak from the victim.
  Common methods:
    • Malicious email with external resource link (Outlook renders it automatically)
    • Compromised internal host running Responder/Inveigh
    • Man-in-the-middle on the local network (ARP spoofing, LLMNR/NBT-NS)
    • Exploiting another NTLM-leaking vulnerability (e.g., CVE-2023-23397 in Outlook)

  Victim's system sends a Net-NTLMv2 authentication response
  to the attacker-controlled server.

Step 2 — Relay to Exchange
  Attacker does NOT crack the hash.
  Instead, attacker relays the captured Net-NTLMv2 response
  directly to the vulnerable Exchange Server.

  Exchange Server (without EPA):
    ✗ Does NOT verify that the authentication originated from the actual client
    ✗ Does NOT bind the authentication to the TLS channel
    ✗ Accepts the relayed response as valid authentication

Step 3 — Authenticated as Victim
  Exchange grants the attacker a session with the victim's privileges.
  The attacker can now:
    ✓ Read, send, and delete email in the victim's mailbox
    ✓ Access shared mailboxes the victim has permission to
    ✓ Modify Exchange configuration (if victim has admin rights)
    ✓ Create mail flow rules to redirect or copy future email
    ✓ Use Exchange as a pivot for further network compromise

  Zero passwords cracked. Zero credentials known.
  The hash itself was the key — and it was never even stored.

The root cause is the absence of Extended Protection for Authentication (EPA) — also known as channel binding — on the Exchange Server. EPA ties the NTLM authentication to the specific TLS session between the client and the server. With EPA enabled, a relayed authentication attempt fails because the TLS channel binding token from the attacker's connection to Exchange does not match the token from the original client-to-attacker connection. Without EPA, Exchange has no mechanism to distinguish a legitimate authentication from a relayed one.

Affected Systems

What is vulnerable and what is not.

Exchange Version	Status	Remediation
Exchange Server 2019 (pre-CU14)	Vulnerable. EPA not enabled by default. NTLM relay attacks succeed against all Exchange services accepting NTLM authentication.	Install Cumulative Update 14 (CU14) or later. CU14 enables EPA by default during installation. Verify EPA status post-installation.
Exchange Server 2016 CU23	Vulnerable unless EPA has been manually enabled. EPA support was introduced in the August 2022 security update, but it is not enabled by default.	Install the latest security update for CU23. Run Microsoft's `ExchangeExtendedProtectionManagement.ps1` script to enable EPA. Verify with `Get-ExchangeServer \| Format-List Name,ExtendedProtectionTokenChecking`.
Exchange Server 2019 CU14+	Protected by default. EPA is enabled during CU14 installation unless explicitly disabled via installation switches.	Verify EPA remains enabled. Monitor for any configuration changes that could disable it.
Exchange Server 2013	End of support (April 2023). No further security updates. Vulnerable if still in service.	Migrate immediately. Exchange 2013 is unsupported and will not receive patches for this or future vulnerabilities.
Exchange Online (Microsoft 365)	Not affected. Microsoft manages EPA and NTLM relay protections for Exchange Online.	No action required for Exchange Online. However, hybrid deployments with on-premises Exchange servers require the on-premises component to be patched.

EPA Compatibility Considerations

Enabling Extended Protection requires all client-to-server connections to use TLS 1.2 or higher. Environments using SSL offloading (where TLS termination occurs at a load balancer rather than at the Exchange server) are not compatible with EPA and require architectural changes before enablement. Review Microsoft's documentation and run the ExchangeExtendedProtectionManagement.ps1 script in audit mode before enabling EPA in production to identify compatibility issues.

Exploitation in the Wild

This was not theoretical.

Microsoft confirmed that CVE-2024-21410 had been exploited in the wild before the February 2024 Patch Tuesday disclosure — making it a zero-day at the time of patch release. The vulnerability's exploitability assessment was updated to "Exploitation Detected" on 14 February 2024.

NTLM relay attacks against Exchange are not new to the threat landscape. Trend Micro reported that nation-state threat groups, including APT28 (Russia's GRU military intelligence) and Hafnium (China), have a documented history of exploiting NTLM relay vulnerabilities against Exchange. APT28 was linked to NTLM relay campaigns targeting high-value entities across foreign affairs, energy, defence, and transportation sectors as early as April 2022 — well before this specific CVE was disclosed.

The attack is particularly attractive to threat actors because it chains naturally with other NTLM credential-leaking vulnerabilities. CVE-2023-23397, a critical Outlook vulnerability disclosed in March 2023, allowed a specially crafted email to force Outlook to send the victim's Net-NTLMv2 hash to an attacker-controlled server — without any user interaction. An attacker combining CVE-2023-23397 (to leak the hash) with CVE-2024-21410 (to relay it to Exchange) has a two-step, zero-interaction path from crafted email to full mailbox access.

The Impact

What an attacker gains with your mailbox.

Successful exploitation of CVE-2024-21410 grants the attacker authenticated access to the Exchange Server as the victim user. The impact depends on the victim's role and permissions — but even a standard user's mailbox contains intelligence value that most organisations underestimate.

Scenario	Access Gained	Downstream Impact
Standard user compromised	Full read/write/delete access to the victim's mailbox. Access to shared mailboxes and distribution lists. Ability to send email as the victim.	Email data theft. Business email compromise — sending fraudulent instructions from a trusted account. Internal reconnaissance via email content (org charts, project details, credentials shared via email). Phishing escalation using the compromised account to target higher-value users.
IT administrator compromised	Mailbox access plus potential Exchange Server administrative capabilities. Transport rules, journaling, and mailbox permissions.	Creation of mail flow rules to copy or redirect all incoming email to an external address. Mailbox delegation changes granting persistent access. Server configuration modifications enabling further compromise.
Executive or privileged user compromised	Access to sensitive strategic communications — board decisions, M&A activity, contract negotiations, financial data, legal correspondence.	Strategic intelligence collection. Insider trading potential. Competitive intelligence. Targeted social engineering using knowledge of internal decisions. Reputational and regulatory consequences.
Service account or shared mailbox compromised	Access to automated mail flows, application-generated emails, and service account permissions.	Interception of automated notifications (password resets, MFA codes sent via email, system alerts). Abuse of application integrations that trust Exchange-delivered mail.

Beyond direct mailbox access, a compromised Exchange Server session provides a platform for further attacks. Attackers can use the Exchange server's network position (typically in a DMZ or internal network segment with broad connectivity) to pivot to other systems. Web shells can be deployed for persistent access — a technique extensively used following the ProxyLogon (CVE-2021-26855) and ProxyShell (CVE-2021-34473) vulnerabilities.

The Bigger Problem

NTLM — the protocol that will not die.

CVE-2024-21410 is not an isolated vulnerability. It is a symptom of a systemic problem: NTLM authentication remains enabled by default across Windows environments, and the protocol's fundamental design makes relay attacks possible wherever NTLM is accepted without channel binding protections. Exchange Server was simply the highest-value target without those protections enabled.

NTLM Is a Legacy Protocol

Kerberos replaced NTLM as the preferred Windows authentication protocol in Windows 2000 — over two decades ago. Yet NTLM remains enabled by default because applications, services, and configurations across enterprise environments still depend on it. Every NTLM authentication is a potential relay target.

Relay Attacks Are Fundamental

NTLM relay is not a bug — it is a consequence of how NTLM works. The protocol was designed before man-in-the-middle attacks were a primary concern. Channel binding (EPA) and SMB signing were added later as mitigations, but they are opt-in rather than enforced by default. Any NTLM-accepting service without these protections is relayable.

The Pattern Repeats

CVE-2024-21410 follows a pattern of NTLM relay vulnerabilities against Microsoft services: PetitPotam (2021) against AD CS, DFSCoerce (2022) against DFS, and numerous Outlook NTLM leaking vulnerabilities (CVE-2023-23397, CVE-2023-35636). Each new CVE exploits the same underlying weakness — NTLM without channel binding — against a different service.

Microsoft Is Deprecating NTLM

In October 2023, Microsoft announced plans to deprecate NTLM in future Windows versions. In October 2024, mandatory MFA was introduced for Azure sign-ins. The direction is clear: NTLM is being phased out. Organisations that begin reducing NTLM dependency now will be ahead of the curve when deprecation becomes enforcement.

Remediation

Fixing CVE-2024-21410 and the underlying problem.

Patching CVE-2024-21410 requires more than installing a cumulative update. The vulnerability is mitigated by enabling Extended Protection for Authentication (EPA) — a configuration change that the CU14 update enables by default for Exchange 2019 but that requires manual action for Exchange 2016. Organisations should approach remediation in two phases: immediate mitigation and strategic NTLM reduction.

Phase 1 — Immediate Mitigation
# ── Exchange Server 2019 ─────────────────────────────────
# Install CU14 or later (EPA enabled by default)
# Download from Microsoft Update Catalogue

# Verify EPA is enabled post-installation:
Get-ExchangeServer | Format-List Name,ExtendedProtectionTokenChecking
# Expected: ExtendedProtectionTokenChecking = Require

# ── Exchange Server 2016 CU23 ────────────────────────────
# Install latest Security Update for CU23

# Download and run the EPA management script:
# https://aka.ms/ExchangeEPScript

# Run in audit mode first to identify compatibility issues:
.\ExchangeExtendedProtectionManagement.ps1 -ShowExtendedProtection

# Enable EPA (after reviewing audit output):
.\ExchangeExtendedProtectionManagement.ps1

# ── Verify Protection ────────────────────────────────────
# Check all virtual directories have EPA set:
Get-WebConfigurationProperty -Filter '//security/authentication/windowsAuthentication/extendedProtection' \
  -PSPath 'IIS:' -Location 'Default Web Site/owa' -Name tokenChecking
# Expected: Require

# ── Exchange Server 2013 ─────────────────────────────────
# No patch available. End of support April 2023.
# MIGRATE IMMEDIATELY. No mitigation exists for this version.

Action	Priority	Detail
Enable EPA on all Exchange servers	Critical — immediate	This is the direct mitigation for CVE-2024-21410. Without EPA, the vulnerability remains exploitable regardless of other security controls. Verify EPA is enabled on every Exchange server, including those in DAG configurations.
Patch Outlook clients	Critical — immediate	Ensure all Outlook clients are patched against known NTLM credential-leaking vulnerabilities, particularly CVE-2023-23397 and CVE-2023-35636. These vulnerabilities provide the credential leak that feeds the relay attack.
Enable SMB signing across the domain	High — within 30 days	SMB signing prevents NTLM relay to SMB services. While not directly related to the Exchange vulnerability, it prevents the captured hash from being relayed to file servers, domain controllers, and other SMB-accepting targets.
Audit NTLM usage across the environment	High — within 30 days	Enable NTLM auditing via Group Policy: `Network security: Restrict NTLM: Audit NTLM authentication in this domain` and `Audit incoming NTLM traffic`. Identify every service, application, and system that still uses NTLM. Document exceptions and plan migration to Kerberos.
Disable LLMNR and NBT-NS	High — within 30 days	Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) are the most common mechanisms attackers use to capture NTLM hashes on internal networks. Disable both via Group Policy. There is almost no legitimate use case for either protocol in modern networks.
Plan NTLM deprecation	Strategic — within 6 months	Begin restricting NTLM where possible. Block NTLMv1 immediately — it provides no security. Restrict NTLMv2 to explicitly whitelisted services. Plan for Microsoft's eventual NTLM deprecation. Every NTLM authentication you eliminate is one fewer relay opportunity.

Detection

Identifying exploitation and exposure.

Detecting active exploitation of CVE-2024-21410 requires monitoring authentication patterns on Exchange servers and correlating with NTLM relay indicators across the network. Detection should cover both the credential leak phase and the relay phase.

Detection Point	Indicator	Implementation
Exchange authentication logs	NTLM authentication events from source IPs that are not the legitimate client. If a user authenticates to Exchange via NTLM from an IP address that does not match their workstation — particularly from a known attacker tool IP or internal pivot host — this is a relay indicator.	Correlate Exchange IIS logs (specifically authentication entries) with known client IP assignments. Alert on NTLM authentications from unexpected source addresses.
Network traffic analysis	NTLM authentication traffic patterns: a client sends NTLM credentials to one host, and within milliseconds the same authentication appears from that host to Exchange. This relay timing is detectable in network flow data.	Deploy network detection for NTLM relay patterns. Tools like Responder detection rules, ntlmrelayx signatures, and relay timing analysis in IDS/NDR products.
Outlook/client anomalies	Outlook making outbound connections to unexpected external hosts — particularly SMB (445) or HTTP (80/443) connections to IP addresses or domains not associated with legitimate services. This indicates an NTLM credential leak in progress.	Monitor for Outlook.exe making outbound SMB connections (this should never happen in normal operation). Alert on connections to file:// or \\UNC paths in emails or calendar items.
Post-exploitation indicators	Mailbox access from unusual client types or IP addresses. New mail flow (transport) rules created unexpectedly. Mailbox delegation changes. OWA access from previously unseen locations. Email forwarding rules sending to external addresses.	Exchange audit logging: enable mailbox audit logging and monitor for `MailboxLogin`, `SendAs`, `New-TransportRule`, and `Add-MailboxPermission` events from unexpected sources.
Vulnerability scanning	Identify Exchange servers without EPA enabled — these are vulnerable regardless of patch level.	Include EPA verification in vulnerability scan configurations. Microsoft's Health Checker script (`HealthChecker.ps1`) reports EPA status. Nmap NSE scripts can fingerprint Exchange version and patch level.

Penetration Testing Perspective

How we test for NTLM relay exposure.

NTLM relay testing is a standard component of internal penetration testing engagements. CVE-2024-21410 adds a specific, high-impact relay target to the tester's methodology, but the underlying test — can we capture and relay NTLM credentials? — has been part of competent internal assessments for years.

NTLM Relay Testing — Engagement Methodology
Phase 1 — NTLM Capture
  # Deploy Responder on the internal network
  responder -I eth0 -wrf
  # Captures Net-NTLMv2 hashes from:
  #   LLMNR/NBT-NS poisoning (if not disabled)
  #   WPAD proxy requests
  #   Misconfigured file share references

Phase 2 — Identify Relay Targets
  # Scan for Exchange servers without EPA
  # Scan for SMB services without signing required
  crackmapexec smb 10.0.0.0/24 --gen-relay-list relay_targets.txt
  # Any service accepting NTLM without channel binding is a target

Phase 3 — Relay Execution
  # Relay captured hashes to Exchange (if EPA not enabled)
  ntlmrelayx.py -t https://exchange.corp.local/EWS/Exchange.asmx
  # Or relay to other targets without signing/EPA
  ntlmrelayx.py -tf relay_targets.txt -smb2support

Phase 4 — Document Impact
  # If relay to Exchange succeeds:
  #   Document mailbox access achieved
  #   Demonstrate email access (screenshot, not exfiltrate)
  #   Report: CVE-2024-21410 — EPA not enabled
  #   Recommendation: Enable EPA, patch to CU14
  # If relay to SMB succeeds:
  #   Document file share access or code execution achieved
  #   Report: SMB signing not required
  #   Recommendation: Enforce SMB signing via GPO

In our experience, NTLM relay succeeds in the majority of internal engagements. LLMNR and NBT-NS are still enabled in most environments, providing the credential capture mechanism. SMB signing is not required on most member servers. And prior to the widespread awareness triggered by CVE-2024-21410, Extended Protection was rarely enabled on Exchange servers. The result is a reliable, low-complexity attack path from network position to authenticated mailbox access — often within the first hour of an internal engagement.

Lessons

What CVE-2024-21410 teaches us.

Default Configurations Are Not Secure

EPA has been available as an option since August 2022 but was not enabled by default until CU14 in February 2024. For nearly two years, the protection existed but most organisations did not enable it — because it was not the default. Security features that require manual enablement protect only the organisations that know to enable them. Vendors should default to the most secure configuration.

Vulnerability Chaining Is the Real Threat

CVE-2024-21410 alone requires a method to capture the victim's NTLM hash. Combined with CVE-2023-23397 (Outlook NTLM leak via crafted email), it becomes a zero-interaction attack from email to mailbox access. Defenders who patch Exchange but not Outlook — or vice versa — remain vulnerable to the chain. Patching must be comprehensive, not selective.

Legacy Protocols Create Systemic Risk

NTLM relay is not a new attack. It has been known and exploited for over two decades. CVE-2024-21410 exists because Exchange Server — a modern, actively maintained product — still accepted NTLM authentication without channel binding protections enabled by default. Legacy protocol support creates ongoing, systemic risk that individual patches cannot fully address.

Email Is a High-Value Target

Compromising a single mailbox provides access to sensitive communications, internal intelligence, contact relationships, and a trusted identity for social engineering. Nation-state groups target Exchange not because it is easy but because email data is extraordinarily valuable. Protecting Exchange deserves the same priority as protecting domain controllers.

Summary

The bottom line.

CVE-2024-21410 is a critical (CVSS 9.8) privilege escalation vulnerability in Microsoft Exchange Server that enables remote, unauthenticated attackers to relay captured Net-NTLMv2 hashes and gain full access to victim mailboxes. It was exploited as a zero-day before the February 2024 patch release, with an estimated 97,000 servers potentially vulnerable at disclosure. Nation-state groups including APT28 have a documented history of exploiting NTLM relay attacks against Exchange.

The fix is enabling Extended Protection for Authentication (EPA) — available since August 2022 but not enabled by default until Exchange Server 2019 CU14. If your organisation runs on-premises Exchange and has not verified that EPA is enabled, your email infrastructure is vulnerable to a known, actively exploited attack that requires no authentication and no user interaction beyond the initial credential leak.

Beyond the immediate patch, CVE-2024-21410 should be treated as a catalyst for broader NTLM remediation. Disable LLMNR and NBT-NS. Enforce SMB signing. Audit NTLM usage. Begin restricting NTLM to essential services only. The protocol that makes this vulnerability possible is being deprecated for good reason — and every NTLM authentication that remains in your environment is an attack surface waiting to be exploited.

Test Your NTLM Exposure

Can an attacker relay credentials in your network?

NTLM relay testing is a standard component of our internal penetration testing engagements. We identify where credential capture is possible, which services accept relayed authentication, and what access an attacker gains — then provide specific, actionable remediation guidance.

Commission a Penetration Test Read: APT33 — The Aerospace Stalker

All Posts Get in Touch