CVE-2022-41040

What it actually does

CVE-2022-41040 is an authenticated server-side request forgery vulnerability in Microsoft Exchange Server. An attacker with valid Exchange credentials can cause the Exchange front-end service to make crafted requests to internal back-end Exchange endpoints that are not intended to be directly reachable. By abusing this request-routing behavior, the attacker can elevate access within Exchange and, in common real-world attack chains, pair it with CVE-2022-41082 to reach Exchange PowerShell functionality and execute commands on the server. The CVSS 8.8 score reflects network reachability, low attack complexity, no user interaction, and high confidentiality, integrity, and availability impact once chained or successfully abused.

Why it matters to the business

Successful exploitation can lead to full compromise of Microsoft Exchange servers, exposure or theft of mailbox data, creation of persistence mechanisms, deployment of web shells, lateral movement into the Windows domain, and ransomware deployment. Because Exchange is often internet-facing and highly privileged within enterprise environments, compromise can disrupt email operations, expose sensitive communications, and provide attackers with a foothold for broader intrusion. This vulnerability is listed in CISA KEV, has extremely high EPSS likelihood, was actively exploited in the wild, and is associated with ransomware activity, so unpatched systems should be treated as urgent remediation priorities. CISA’s KEV remediation due date was 2022-10-21.

How an attack unfolds

An attacker first obtains valid Exchange credentials through phishing, password reuse, credential theft, or prior compromise. The attacker then sends crafted HTTPS requests to Exchange Autodiscover or related front-end endpoints that trigger the SSRF condition and cause Exchange to proxy traffic to internal back-end services, commonly targeting Exchange PowerShell endpoints. In observed attack chains, this access is combined with a second Exchange vulnerability such as CVE-2022-41082 to execute PowerShell commands on the server. After code execution or administrative access is achieved, the attacker may enumerate mailboxes, export data, drop web shells, add accounts or permissions, disable defenses, stage tools, and move laterally. In ransomware campaigns, Exchange compromise is used as the initial access or escalation point before credential harvesting, domain discovery, payload deployment, and encryption.

How to fix it

Install Microsoft’s security updates for all supported Microsoft Exchange Server versions and move servers to supported Cumulative Update and Security Update levels. For this vulnerability family, organizations should apply the November 2022 Exchange Server Security Updates or any later cumulative/security update that supersedes them; installing only URL Rewrite mitigations is not a complete long-term fix. Confirm that all internet-facing and internal Exchange servers are patched, including hybrid servers. Remove or disable obsolete temporary mitigations only after patching has been verified. Restrict external access to Exchange administrative and PowerShell endpoints where operationally feasible, require MFA for remote access, monitor and reduce privileged mailbox roles, and disable unnecessary services. If compromise is suspected, patching alone is insufficient: isolate the server, collect forensic evidence, remove persistence, rotate credentials, and review domain-level impact.

How to confirm the fix worked

Confirm the installed Exchange build against Microsoft’s official Exchange Server build number and security update guidance, ensuring each server has a security update level equal to or later than the fixes released for this issue. Verify that all Exchange servers, including passive DAG members, hybrid servers, and management-only servers, are updated. Review IIS and Exchange HttpProxy logs for historical requests containing Autodiscover paths with PowerShell-related query strings. From an external test perspective, verify that crafted Autodiscover-to-PowerShell SSRF-style requests do not reach internal PowerShell endpoints and are rejected or handled safely. Validate that Exchange Emergency Mitigation Service, antimalware, EDR, and centralized logging are functioning. If the server was exposed before patching, perform compromise assessment rather than relying only on version checks.

Typical attack path

1. Acquire valid Exchange user credentials through phishing, credential stuffing, malware, or prior intrusion.
2. Identify an exposed Microsoft Exchange Server reachable over HTTPS.
3. Send crafted requests to Exchange front-end endpoints such as Autodiscover that abuse the SSRF request-routing flaw.
4. Proxy the request to internal Exchange back-end services, often attempting to reach PowerShell-related endpoints.
5. If possible, chain with a remote code execution vulnerability to run commands under Exchange/IIS service context.
6. Establish persistence using web shells, scheduled tasks, new accounts, mailbox rules, or modified permissions.
7. Collect email data, credentials, and configuration information from the Exchange server and domain.
8. Move laterally to additional systems or deploy ransomware and other post-exploitation tooling.

How to detect it

Check for prior exploitation by correlating Exchange IIS logs, Exchange HttpProxy logs, Windows PowerShell logs, Exchange Management logs, Windows Security events, EDR telemetry, and web directory file changes. Primary log sources include IIS W3C logs under inetpub log directories, Exchange HttpProxy logs under the Exchange Logging directory, PowerShell Operational logs, Windows process creation events, and EDR process trees. Focus on authenticated requests to Autodiscover or related Exchange front-end endpoints that include PowerShell, ECP, or other internal back-end service paths in the query string. Look for unusual HTTP 200/401/500 patterns from the same source IP, requests with encoded characters around Autodiscover and PowerShell paths, and authenticated mailbox accounts making administrative-looking requests. Hunt for w3wp.exe or Exchange-related processes spawning scripting or living-off-the-land binaries. Inspect Exchange and IIS web directories for new .aspx files, unexpected modification times, or files with obfuscated code. Review Exchange admin audit logs for suspicious role assignments, mailbox exports, transport rule changes, inbox rule creation, and PowerShell activity. Because exploitation often involves chaining, absence of one indicator does not rule out compromise; investigate any combination of suspicious Autodiscover-to-PowerShell requests, abnormal process execution, and new web-accessible files.

• /autodiscover/autodiscover.json
• /autodiscover/autodiscover.json?
• /powershell
• /powershell/
• powershell
• Email=autodiscover/autodiscover.json
• Email=autodiscover/autodiscover.json%3f
• X-Rps-CAT
• /ecp/
• /owa/auth/
• w3wp.exe powershell.exe
• w3wp.exe cmd.exe
• w3wp.exe rundll32.exe
• w3wp.exe regsvr32.exe
• w3wp.exe mshta.exe
• w3wp.exe certutil.exe
• powershell.exe -EncodedCommand
• powershell.exe -enc
• New-MailboxExportRequest
• New-ManagementRoleAssignment
• Set-ManagementRoleAssignment
• New-InboxRule
• Set-InboxRule
• C:\inetpub\logs\LogFiles\W3SVC1\
• C:\inetpub\logs\LogFiles\W3SVC2\
• C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Autodiscover\
• C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\PowerShell\
• C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\
• C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ecp\
• C:\inetpub\wwwroot\aspnet_client\
• MSExchange Management
• Microsoft-Windows-PowerShell/Operational

What your security team should do

• Immediately identify all Microsoft Exchange Server instances and confirm they are running supported, fully patched builds.
• Prioritize internet-facing Exchange servers first, then patch all remaining Exchange servers, including hybrid and internal-only systems.
• Because this vulnerability is in CISA KEV, has near-certain EPSS probability, and is associated with ransomware, treat any unpatched exposed server as high risk and investigate for compromise.
• Search IIS, Exchange HttpProxy, PowerShell, Windows Event, EDR, and proxy logs for Autodiscover requests that reference PowerShell endpoints or other internal Exchange back-end paths.
• Hunt for suspicious child processes spawned by IIS or Exchange worker processes, especially w3wp.exe launching powershell.exe, cmd.exe, rundll32.exe, regsvr32.exe, mshta.exe, certutil.exe, or encoded PowerShell.
• Look for recently created or modified web-accessible files under Exchange and IIS web directories, especially .aspx files in OWA, ECP, aspnet_client, and FrontEnd HttpProxy paths.
• Review mailbox export requests, role assignments, inbox rules, new accounts, OAuth/application permissions, and Exchange administrator group membership for unauthorized changes.
• Rotate credentials for accounts observed authenticating to suspicious Exchange requests and for privileged accounts used on or from Exchange servers.
• Restrict inbound access to Exchange management and PowerShell endpoints using VPN, administrative jump hosts, firewall rules, and conditional access where possible.
• If exploitation indicators are found, preserve forensic evidence, isolate affected servers, run Microsoft-supported Exchange compromise assessment tooling, rebuild from trusted media if needed, and perform domain-wide incident response.