CVE-2024-21410

What it actually does

CVE-2024-21410 is a remotely exploitable Microsoft Exchange Server elevation-of-privilege vulnerability associated with NTLM relay-style abuse. An attacker can authenticate to Exchange as another user by relaying or abusing NTLM authentication against a vulnerable Exchange endpoint, potentially gaining mailbox access or administrative capability depending on the relayed account’s privileges. Because the flaw is network-reachable, requires no prior authentication, and has been added to CISA KEV with active exploitation observed, it should be treated as a high-priority exposed messaging infrastructure risk. The supplied package metadata also references Linux kernel fixed versions, which is inconsistent with the Microsoft Exchange vulnerability description; asset owners should validate product mapping before relying on package-only data.

Why it matters to the business

Successful exploitation can let an attacker access or manipulate corporate email, steal sensitive messages and attachments, impersonate users, create persistence through mailbox rules or delegated permissions, and potentially expand into broader domain or cloud identity compromise. For organizations running exposed Exchange services, the operational risk is high because Exchange is often internet-facing, business-critical, and deeply integrated with identity systems. This vulnerability is listed in CISA KEV with a remediation due date of 2024-03-07, which has long passed, so unremediated systems represent an overdue known-exploited exposure even though ransomware use is not specifically reported in the supplied data.

How an attack unfolds

An attacker first identifies an internet-facing or reachable Exchange Server that has not received the relevant security update or has not enabled the required hardening, especially Extended Protection for Authentication. The attacker then induces, captures, or relays NTLM authentication and forwards it to the vulnerable Exchange service. If the relay succeeds, Exchange treats the attacker’s session as the relayed user. The attacker can then access Exchange interfaces such as EWS, MAPI, OWA, ECP, or remote PowerShell according to that user’s permissions. Post-exploitation activity commonly focuses on reading mail, exporting mailbox data, creating forwarding or inbox rules, adding mailbox permissions, modifying transport settings, or using any obtained administrative privilege to establish persistence and pivot further.

How to fix it

Apply the Microsoft Exchange Server security updates that address CVE-2024-21410 and ensure Exchange is on a supported cumulative update before applying security updates. Enable and validate Extended Protection for Authentication on Exchange virtual directories where required by Microsoft guidance, and remove unsupported configurations that prevent EPA from working, such as incompatible TLS offload or inconsistent authentication settings. Restrict external access to Exchange administrative interfaces, especially ECP and PowerShell, to trusted networks or VPN. Disable unnecessary NTLM where feasible and prioritize Kerberos or modern authentication patterns. Review and harden Exchange virtual directory authentication settings after patching. The supplied fixed-version metadata lists `Kernel (Linux): fixed in 6.10.1` and Git commit `b9afbb9a0c734197c59c43610071041044bf1562`; because this conflicts with the Exchange-specific CVE description, verify the affected product mapping and separately update any Linux kernel assets if that metadata is relevant to a local advisory feed.

How to confirm the fix worked

Confirm the Exchange build level includes the security update addressing the vulnerability by checking Exchange Server build numbers against Microsoft’s official Exchange Server update matrix. Run Microsoft’s Exchange Health Checker script and verify it reports the server as patched and Extended Protection for Authentication as correctly configured where applicable. Validate that Exchange virtual directories do not accept unsafe or unexpected NTLM configurations and that administrative endpoints are not publicly reachable unless explicitly required and protected. Test from an external network perspective to confirm only intended Exchange services are exposed. For environments using package inventory data, verify whether any asset is actually running Microsoft Exchange versus the conflicting Linux kernel package metadata; if Linux kernel exposure is in scope, confirm kernel version is 6.10.1 or later or includes commit `b9afbb9a0c734197c59c43610071041044bf1562`.

Typical attack path

1. Discover internet-facing Exchange endpoints and identify servers missing the relevant Microsoft security update or authentication hardening.
2. Confirm NTLM authentication is accepted on Exchange virtual directories and Extended Protection for Authentication is absent, disabled, or inconsistently configured.
3. Coerce, capture, or relay NTLM authentication from a target user or privileged account to the vulnerable Exchange service.
4. Establish an authenticated Exchange session as the relayed identity.
5. Access mailboxes or administrative Exchange functions exposed to that identity.
6. Create persistence or expand access by adding mailbox permissions, inbox rules, forwarding rules, transport rules, OAuth/application changes, or remote PowerShell actions.
7. Exfiltrate email, attachments, address books, or configuration data and use the mailbox foothold for further phishing or internal compromise.

How to detect it

Investigate whether exploitation already occurred by correlating Exchange IIS logs, Exchange HttpProxy logs, EWS/MAPI/RPC/OWA/ECP logs, Windows Security event logs, domain controller NTLM events, Exchange admin audit logs, mailbox audit logs, PowerShell logs, and message tracking logs. Look for successful NTLM-based logons to Exchange from unusual external IP addresses, repeated access to multiple Exchange virtual directories by the same account, NTLM logons followed immediately by EWS, ECP, or PowerShell actions, and administrative changes such as new mailbox permissions, inbox forwarding, transport rules, role assignments, or remote PowerShell activity. Review Windows Event ID 4624 logon type 3 events on Exchange servers where the authentication package is NTLM, Event ID 4776 on domain controllers for NTLM validation, and Exchange management/audit records for commands such as Add-MailboxPermission, New-ManagementRoleAssignment, New-InboxRule, Set-Mailbox, Set-TransportRule, and New-TransportRule. Also hunt for post-compromise behavior: mailbox exports, mass message access, unusual EWS user agents, suspicious Outlook rule creation, new forwarding to external domains, and privileged Exchange configuration changes. Because this vulnerability enables impersonation rather than dropping a unique payload, there may be no single definitive file-based IOC; detection depends heavily on authentication and Exchange audit correlation.

• /EWS/Exchange.asmx
• /mapi/
• /rpc/
• /owa/
• /ecp/
• /PowerShell/
• AuthenticationPackageName: NTLM
• Package Name (NTLM only): NTLM V2
• Logon Type: 3
• Event ID 4624
• Event ID 4776
• Add-MailboxPermission
• New-ManagementRoleAssignment
• New-InboxRule
• Set-InboxRule
• Set-Mailbox
• Set-TransportRule
• New-TransportRule
• Set-ForwardingAddress
• ForwardingSmtpAddress
• Search-Mailbox
• New-MailboxExportRequest
• Exchange Management Shell
• MSExchange Management
• MSExchange HttpProxy
• MSExchangeIS
• IIS W3SVC

What your security team should do

• Treat this as an emergency remediation item for any internet-facing Exchange Server because it is in CISA KEV and active exploitation has been reported.
• Patch Exchange servers immediately and confirm the fix with Microsoft’s Exchange Health Checker and build-number validation.
• Enable and validate Extended Protection for Authentication across Exchange virtual directories according to Microsoft guidance.
• Restrict ECP, Exchange remote PowerShell, and other administrative Exchange endpoints to trusted administrative networks.
• Hunt for NTLM authentication anomalies, especially successful NTLM logons to Exchange from unusual source IPs or followed by Exchange administrative actions.
• Review Exchange admin audit logs, mailbox audit logs, inbox rules, forwarding rules, transport rules, and delegated mailbox permissions for unauthorized changes.
• Investigate any signs of mailbox access, email export, suspicious forwarding, or new persistence mechanisms after the likely exposure window.
• Rotate credentials and invalidate sessions for accounts suspected to have been relayed or abused, prioritizing Exchange administrators and high-value mailboxes.
• Resolve the metadata inconsistency between the Exchange vulnerability and Linux kernel fixed-version data before closing remediation based on package inventory alone.