CVE-2022-41082

What it actually does

This vulnerability is a remote code execution flaw in Microsoft Exchange Server associated with unsafe deserialization/PowerShell execution paths. A low-privileged authenticated attacker can trigger server-side code execution, commonly after first gaining access to the Exchange PowerShell endpoint through a companion vulnerability or stolen credentials. Successful exploitation can allow execution of commands in the Exchange server context, access to mailbox data, deployment of web shells, credential theft, lateral movement, and persistence. The CVSS score is 8.0, but the real-world risk is higher because exploitation is confirmed in the wild, EPSS is extremely high, it is listed in CISA KEV, and it has been used in ransomware campaigns.

Why it matters to the business

Compromise of an Exchange server can expose sensitive email, credentials, internal communications, and authentication material while also giving attackers a foothold inside the network. Because Exchange is often internet-facing and highly privileged within enterprise environments, exploitation can lead to business email compromise, data theft, service disruption, ransomware deployment, and broad internal compromise. This issue is long past the CISA KEV remediation deadline of 2022-10-21, has active exploitation maturity, and should be treated as an emergency if any affected Exchange exposure remains unpatched or unvalidated.

How an attack unfolds

An attacker typically starts by identifying an internet-facing Exchange server and determining whether the vulnerable code path is reachable. Because this vulnerability requires some level of authentication or an alternate path to the Exchange PowerShell endpoint, attackers commonly combine it with credential compromise, session abuse, or a related Exchange access-control bypass. Once access is achieved, the attacker sends crafted requests to Exchange endpoints such as Autodiscover and PowerShell to trigger server-side command execution. Post-exploitation activity often includes spawning PowerShell or cmd.exe from the Exchange worker process, writing ASPX web shells into Exchange-accessible web directories, dumping credentials, exporting mailbox content, creating persistence, and moving laterally. Known exploitation has been associated with active threat activity including StrikeShark and ransomware operations, so systems should be investigated for compromise even after patching.

How to fix it

Patch Microsoft Exchange Server immediately with the applicable Microsoft security update or a later cumulative/security update that fully remediates this vulnerability. Because this vulnerability is known-exploited and ransomware-associated, mitigation-only controls should be considered temporary and insufficient. If immediate patching is not possible, restrict external access to Exchange administrative and PowerShell endpoints, limit access to OWA/ECP/Autodiscover where operationally feasible, disable Remote PowerShell for non-administrative users, require MFA for all remote access, block direct internet access to Exchange management interfaces, and apply Microsoft-provided URL Rewrite/Emergency Mitigation Service protections where applicable. After patching, perform compromise assessment because patching does not remove web shells, stolen credentials, persistence, or attacker-created accounts. The provided affected product metadata lists Django/Debian packages and fixed versions such as django/django commit 04ac1624bdc2fa737188401757cf95ced122d26d and python-django 2:2.2.21-1; that package data does not align with this Exchange vulnerability, so remediation should be verified against Microsoft Exchange Server advisories and the actual Exchange versions deployed.

How to confirm the fix worked

Confirm all Exchange servers are running a supported cumulative update level plus the security update that remediates this vulnerability, or a later update. Use Microsoft Exchange Health Checker and Microsoft-provided mitigation/validation scripts where available. Verify that Exchange Emergency Mitigation Service is enabled and current, but do not rely on it as a replacement for patching. Confirm external access to /PowerShell, /ecp, /owa, /ews, and /autodiscover is appropriately restricted. Review installed Exchange build numbers, Windows Update history, and Exchange setup logs to ensure the update completed successfully on every Exchange role. Validate that no unexpected ASPX files, scheduled tasks, services, local users, mailbox export requests, or PowerShell remoting configurations remain after remediation. Run targeted log searches for historical exploitation before declaring the issue fully resolved.

Typical attack path

1. Scan for internet-facing Microsoft Exchange servers and enumerate exposed Outlook Web App, Autodiscover, EWS, and PowerShell endpoints.
2. Obtain a valid low-privileged account, reuse stolen credentials, or chain with another Exchange vulnerability to reach the vulnerable PowerShell execution path.
3. Send crafted HTTP requests to Exchange Autodiscover/PowerShell endpoints to trigger remote command execution.
4. Execute reconnaissance commands on the Exchange server and identify privileges, domain context, mailboxes, and security tooling.
5. Drop a web shell or establish another persistence mechanism under Exchange web-accessible directories.
6. Use the Exchange server as a foothold to access mail data, harvest credentials, impersonate users, or move laterally.
7. Stage data theft, deploy additional malware, or launch ransomware from the compromised environment.

How to detect it

Review historical and current logs for signs of Exchange exploitation, especially around Autodiscover and PowerShell endpoint access. Primary sources include IIS logs under Exchange FrontEnd and ClientAccess paths, Exchange HttpProxy logs, PowerShell Operational logs, Windows Security process creation events, Sysmon telemetry if deployed, EDR process trees, Exchange Management logs, antivirus alerts, and web directory file system timestamps. Look for suspicious requests containing both Autodiscover and PowerShell patterns, X-Rps-CAT tokens, unusual authenticated requests to /PowerShell, unexpected 200 responses to Exchange management endpoints, and abnormal user agents. On hosts, investigate w3wp.exe launching scripting or command interpreters, newly written ASPX files in Exchange web directories, suspicious scheduled tasks, new local users, mailbox export activity, credential dumping behavior, and outbound connections from Exchange servers to unusual IPs. Because threat actors including StrikeShark and ransomware operators have exploited this class of Exchange vulnerability, also hunt for post-exploitation behavior: web shells, Cobalt Strike-like beacons, archive creation, mailbox exfiltration, and lateral movement over SMB, WinRM, RDP, or PowerShell Remoting.

• /autodiscover/autodiscover.json
• /autodiscover/autodiscover.json?@
• /PowerShell/
• /powershell/
• X-Rps-CAT
• /autodiscover/autodiscover.json?@*/PowerShell/
• w3wp.exe -> powershell.exe
• w3wp.exe -> cmd.exe
• w3wp.exe -> rundll32.exe
• w3wp.exe -> regsvr32.exe
• w3wp.exe -> mshta.exe
• w3wp.exe -> certutil.exe
• C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\*.aspx
• C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ecp\auth\*.aspx
• C:\inetpub\wwwroot\aspnet_client\system_web\*.aspx
• 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\Logging\HttpProxy\Ecp\
• C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Owa\
• MSExchange Management
• Microsoft-Windows-PowerShell/Operational
• Event ID 4688
• New-MailboxExportRequest
• Set-OwaVirtualDirectory
• Set-OrganizationConfig
• Add-MailboxPermission
• New-ManagementRoleAssignment
• IEX (New-Object Net.WebClient).DownloadString
• Invoke-WebRequest
• FromBase64String
• -EncodedCommand

What your security team should do

• Immediately identify all Microsoft Exchange servers, especially internet-facing systems, and prioritize them for patch verification or emergency isolation.
• Treat any unpatched or historically exposed Exchange server as potentially compromised; begin forensic review before and after applying updates.
• Install the applicable Microsoft Exchange security update or later supported cumulative/security update across all Exchange servers.
• Restrict inbound internet access to Exchange PowerShell and administrative endpoints; allow only trusted management networks or VPN paths where possible.
• Disable Remote PowerShell for users who do not explicitly require it and enforce MFA for all administrative and remote email access.
• Search IIS, HttpProxy, PowerShell, Windows Security, Exchange Management, and antivirus/EDR telemetry for exploitation patterns and web shell activity.
• Hunt specifically for w3wp.exe spawning powershell.exe, cmd.exe, rundll32.exe, regsvr32.exe, mshta.exe, certutil.exe, or other unusual child processes.
• Inspect Exchange web directories for recently created or modified ASPX files and remove confirmed web shells only after collecting forensic evidence.
• Rotate credentials for accounts that authenticated to or were cached on affected Exchange servers, prioritizing administrators and service accounts.
• Because this issue is KEV-listed, ransomware-associated, and far beyond the 2022-10-21 remediation deadline, escalate unresolved exposure to incident-response leadership immediately.