CVE-2021-26855

What it actually does

CVE-2021-26855 is the Exchange Server “ProxyLogon” server-side request forgery flaw. An unauthenticated remote attacker can send crafted HTTPS requests to Exchange Client Access services and cause the server to make privileged backend requests on the attacker’s behalf. This can let the attacker impersonate privileged Exchange contexts, access mailbox data, and, when chained with related Exchange post-authentication file-write or deserialization flaws, deploy web shells and execute code on the Exchange server. The vulnerability is network-reachable, requires no credentials or user interaction, and has been heavily exploited in the wild.

Why it matters to the business

Successful exploitation can give attackers access to sensitive email, credentials, address books, and internal communications, and can lead to persistent compromise of the Exchange server. Because Exchange commonly has high trust, internet exposure, and access to authentication material, compromise can become a launch point for ransomware, data theft, lateral movement, and disruption of email services. This issue is listed in CISA KEV, has been used in ransomware campaigns, has an extremely high EPSS score, and was required for remediation by CISA by 2022-05-03, so any remaining exposure should be treated as urgent legacy risk.

How an attack unfolds

An attacker scans the internet for exposed Microsoft Exchange servers and sends crafted requests to Exchange endpoints such as Autodiscover, ECP, OWA, or MAPI. By abusing the SSRF behavior, the attacker causes the front-end Exchange service to proxy requests to internal backend Exchange services as if they originated from a trusted server component. The attacker then uses that access to enumerate information, obtain mailbox or configuration data, and often chains the flaw with other ProxyLogon-era Exchange vulnerabilities to write an ASPX web shell into a web-accessible directory. Once a shell is present, the attacker can run commands under the Exchange/IIS service context, dump credentials, archive mailboxes, install persistence, move laterally, or deploy ransomware. Public reporting and active exploitation have associated this vulnerability with broad criminal activity and actor/campaign labels including StrikeShark, along with widespread opportunistic exploitation after disclosure.

How to fix it

Apply the applicable Microsoft Exchange security updates immediately and move servers to supported cumulative update levels before applying security updates where required. For Exchange 2013, Exchange 2016, and Exchange 2019, install the latest supported Cumulative Update and Security Update from Microsoft; if a server is end-of-life or cannot receive security updates, remove it from service or isolate it until it can be replaced. Confirm that all externally reachable Exchange servers, including hybrid and standby systems, are patched. If immediate patching is not possible, restrict external access to Exchange endpoints to trusted networks or VPN, block direct internet access to OWA/ECP/EWS/Autodiscover, and use Microsoft’s recommended mitigation tooling only as a temporary measure. Because exploitation often results in web shells, patching alone is not sufficient: investigate for compromise, remove malicious files, rotate exposed credentials, and rebuild severely compromised servers when integrity cannot be trusted.

How to confirm the fix worked

Verify the installed Exchange build and security update level against Microsoft’s official Exchange Server build number documentation. Confirm the server is on a supported CU/SU path and that no unpatched Exchange hosts remain exposed through load balancers, reverse proxies, NAT rules, or hybrid configurations. Run Microsoft Exchange On-premises Mitigation Tool and Exchange Server Health Checker where appropriate, and review their findings. Test externally that unauthenticated requests to ECP/OWA/Autodiscover no longer exhibit ProxyLogon behavior and that administrative Exchange endpoints are not broadly internet-accessible. Inspect web-accessible Exchange directories for unexpected ASPX files, recent file writes, suspicious IIS child processes, and abnormal PowerShell execution before considering remediation complete.

Typical attack path

1. Identify internet-facing Microsoft Exchange Server instances.
2. Send crafted unauthenticated HTTPS requests to Exchange front-end endpoints to trigger SSRF behavior.
3. Use the Exchange server to proxy privileged backend requests and impersonate trusted Exchange components.
4. Enumerate server configuration, mailbox information, or authentication material.
5. Chain with related Exchange vulnerabilities to write an ASPX web shell or otherwise gain command execution.
6. Execute commands through the web shell, collect credentials and email data, and establish persistence.
7. Use the compromised Exchange server for lateral movement, data exfiltration, or ransomware deployment.

How to detect it

Review IIS logs on Exchange servers for suspicious unauthenticated requests to Autodiscover, ECP, OWA, MAPI, and related endpoints, especially requests containing X-BEResource, X-AnonResource, proxyLogon.ecp, or unusual backend host routing values. Correlate with HTTP 241/200/500 responses, odd user agents, and requests from unfamiliar internet IPs. Inspect Exchange and Windows event logs for abnormal PowerShell execution, Exchange Management Shell activity, new role assignments, mailbox export requests, OAB virtual directory changes, and suspicious service or scheduled task creation. Search the Exchange installation and IIS web roots for recently created or modified ASPX files, especially under aspnet_client, owa\auth, ecp, and FrontEnd\HttpProxy paths. Review EDR/process telemetry for w3wp.exe spawning cmd.exe, powershell.exe, net.exe, certutil.exe, bitsadmin.exe, rundll32.exe, regsvr32.exe, mshta.exe, or archiving tools. Look for outbound connections from Exchange servers to unknown IPs, especially immediately after suspicious IIS requests. If threat-intelligence labels such as StrikeShark are relevant to internal reporting, correlate observed source IPs, tooling, web shell names, and post-exploitation commands with current actor-specific intelligence rather than relying on actor name alone.

• X-BEResource=
• X-AnonResource=true
• X-AnonResource-Backend=
• /ecp/proxyLogon.ecp
• /ecp/DDI/DDIService.svc
• /ecp/default.flt
• /owa/auth/Current/themes/resources/
• /autodiscover/autodiscover.json
• /mapi/nspi/
• /aspnet_client/system_web/
• C:\\inetpub\\wwwroot\\aspnet_client\\system_web\\
• C:\\Program Files\\Microsoft\\Exchange Server\\V15\\FrontEnd\\HttpProxy\\owa\\auth\\
• C:\\Program Files\\Microsoft\\Exchange Server\\V15\\FrontEnd\\HttpProxy\\ecp\\
• C:\\Program Files\\Microsoft\\Exchange Server\\V15\\ClientAccess\\ecp\\
• C:\\Program Files\\Microsoft\\Exchange Server\\V15\\ClientAccess\\owa\\auth\\
• C:\\Program Files\\Microsoft\\Exchange Server\\V15\\Logging\\HttpProxy\\
• C:\\Program Files\\Microsoft\\Exchange Server\\V15\\Logging\\ECP\\Server\\
• C:\\Program Files\\Microsoft\\Exchange Server\\V15\\Logging\\OABGeneratorLog\\
• C:\\Program Files\\Microsoft\\Exchange Server\\V15\\Logging\\CmdletInfra\\Powershell-Proxy\\
• Set-OabVirtualDirectory
• ExternalUrl
• New-ManagementRoleAssignment
• New-MailboxExportRequest
• w3wp.exe spawned cmd.exe
• w3wp.exe spawned powershell.exe
• cmd.exe /c whoami
• powershell -enc
• powershell.exe -EncodedCommand
• certutil.exe -urlcache
• bitsadmin.exe /transfer
• rundll32.exe javascript:
• regsvr32.exe /s /n /u /i:
• mshta.exe http
• web.aspx
• shell.aspx
• cmd.aspx
• error.aspx
• help.aspx
• supp0rt.aspx
• aspnet_www.aspx
• owa.aspx
• authhead.aspx

What your security team should do

• Treat any unpatched or historically exposed Exchange server as potentially compromised, not merely vulnerable.
• Patch or retire all affected Exchange servers immediately; prioritize internet-facing, hybrid, and high-privilege mail infrastructure first.
• Hunt for ProxyLogon exploitation in IIS, Exchange, Windows Event, PowerShell, EDR, proxy, and firewall logs going back to at least the initial public exploitation window or the system’s deployment date if logs permit.
• Search Exchange web directories for unauthorized ASPX web shells and investigate any recent file creation under OWA, ECP, aspnet_client, FrontEnd, and HttpProxy paths.
• If compromise is suspected, isolate the server, preserve forensic evidence, collect volatile data, and follow an incident response process before cleanup.
• Rotate passwords and secrets that may have been exposed, especially Exchange service accounts, administrator accounts, and credentials used on the server.
• Review for lateral movement, mailbox export activity, suspicious inbox rules, new privileged role assignments, scheduled tasks, services, and remote access tools.
• Block direct internet access to Exchange administrative endpoints where business requirements allow and place access behind VPN, conditional access, or strong reverse-proxy controls.
• Ensure backups are clean and restorable, given documented ransomware use associated with this vulnerability.
• Continue monitoring for known ProxyLogon artifacts and web shell activity even after patching, because previously planted shells remain usable until removed.