The IIS virtual directory that won't stop bleeding

Microsoft pushed an out-of-band advisory for an actively exploited Exchange Server flaw. The pattern repeats. Frontend OWA endpoint reachable pre-auth, backend PowerShell remoting trusted, deserialization sink behind a serialized identity the frontend forged. Same architecture, different gadget chain. CVSS 9.8 territory because the path is internet-exposed and authenticated context is synthesised by the bug itself.

The Exchange attack surface that keeps producing zero-days is the Client Access frontend talking to the Mailbox backend over a trusted channel. /owa, /ecp, /autodiscover, /mapi, /ews - all of these are IIS virtual directories that accept unauthenticated or session-cookie-authenticated requests on the frontend and then proxy them to the backend over Kerberos-authenticated HTTP using the Exchange computer account. The backend assumes the frontend has authenticated the user. That assumption is the trust boundary. Every major Exchange CVE since 2021 has broken it.

CVE-2021-26855, ProxyLogon, was server-side request forgery in the frontend Autodiscover handler. The frontend constructed a URL using attacker-controlled X-AnchorMailbox or cookie values and made an HTTP request to an arbitrary backend resource as itself. The backend accepted the request as a fully authenticated Exchange computer account. CVE-2021-34473, ProxyShell, took a path normalisation bug in the Autodiscover URL parser and used it to reach /powershell on the backend, then chained CVE-2021-34523 to impersonate an admin in remote PowerShell and CVE-2021-31207 to write a webshell via New-MailboxExportRequest. CVE-2022-41040 and CVE-2022-41082, ProxyNotShell, refined the path. Authenticated low-privilege user, SSRF via Autodiscover, deserialization in remote PowerShell. CVE-2024-21410 was an NTLM relay against Exchange where the server requested authentication from clients and the relay coerced that auth back into Exchange Web Services. Same shape. Frontend coerced into trusting a backend interaction it should not.

The current advisory follows the family. Pre-authentication request reaches a frontend handler. The handler constructs state - a serialized identity, a deserialization payload, a path to a privileged backend endpoint - using fields the attacker controls. The state is forwarded to the backend. The backend, running as the Exchange machine account in NT AUTHORITY\SYSTEM context, executes the operation with full Exchange organisation privileges. The exploit primitive is not a memory corruption bug. It is a logic flaw - broken authorisation across a trust boundary, with .NET BinaryFormatter or DataContractSerializer or a similar deserialization sink at the end of the chain.

This class persists for a structural reason. Exchange is a twenty-year-old codebase carrying two decades of internal IPC, COM, RPC, and HTTP-tunnelled remoting. The product layers serialized .NET objects across process and host boundaries. Microsoft’s own guidance on BinaryFormatter has been do-not-use for years. Exchange still has formatter sinks reachable from internet-exposed endpoints through chains that require multiple parser quirks to line up. Each patch fixes the specific quirk. The sinks remain. The trust boundary remains. The attack class regenerates.

Exploitation against unpatched Exchange Servers does not require novel work. Once the request shape is known, weaponisation is a templating exercise. Public ProxyShell and ProxyNotShell tooling - proxyshell.py, the various Metasploit modules, the Exchange remoting wrappers in Impacket-adjacent code - provide the request scaffolding. An attacker swaps the path normalisation primitive or the SSRF gadget for the new one and the rest of the chain still works because the backend behaviour did not change. T1190, exploitation of public-facing application. T1505.003, web shell, when the post-exploitation step writes a .aspx into the Exchange OAB or FrontEnd virtual directory. T1078.004 if the chain produces a forged service account token. T1136.001 for new account creation via New-Mailbox.

Post-exploitation on Exchange is well-mapped. The webshell drops to disk in a directory served by IIS. C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\, the OAB directory, the ECP auth path. The shell runs as the Exchange app pool identity, typically NetworkService or a privileged Exchange service account, with effective access to the mailbox database and the Exchange permissions groups in Active Directory. From there: dump LSASS, extract Kerberos keys for the Exchange computer account, abuse Exchange Trusted Subsystem or Organization Management group memberships to escalate inside the domain. HAFNIUM did this in 2021. Multiple ransomware affiliates have done it since.

Telemetry. Exchange exploitation has signatures, and they fire if the controls are tuned. IIS logs are the first signal - W3SVC logs in C:\inetpub\logs\LogFiles\. ProxyShell-class chains leave POST and GET requests to /autodiscover/autodiscover.json with anchored URL parameters and to /powershell with X-Rps-CAT cookies that should not appear on internet traffic. The user-agent strings and the cs-uri-query lengths are anomalous. Exchange’s own HttpProxy logs, in V15\Logging\HttpProxy\, record the backend forwarding decisions and will show frontend requests being routed to /powershell or to internal RPC endpoints from anonymous sessions. ECP logs in V15\Logging\ECP\Server\ capture deserialization stack traces when payloads fail mid-gadget. Those stack traces are forensic gold.

EDR coverage of the post-exploitation is stronger than coverage of the initial chain. Sysmon Event ID 1 fires on w3wp.exe spawning cmd.exe, powershell.exe, or net.exe. w3wp.exe as a parent of a shell is the canonical Exchange-compromise indicator. Event ID 11 records the webshell file write into the OWA auth path. Event ID 3 captures egress from w3wp.exe to attacker infrastructure, which should never happen for a healthy Exchange process. Event ID 10 records LSASS access from non-standard processes - a post-exploitation step that follows almost every Exchange compromise. Defender for Endpoint, CrowdStrike, and SentinelOne all alert on the w3wp.exe-to-shell parent-child relationship as a high-fidelity detection. The gap is the initial request itself. Most EDR does not parse IIS request bodies. The exploit traffic looks like legitimate Autodiscover or EWS traffic at the process level. The deserialization gadget executes inside w3wp.exe without spawning a child process until the operator chooses to escalate.

Network detection is possible but rare in practice. The chain produces distinct request signatures - long URI paths with embedded SID fragments, anomalous SOAP envelopes, X-headers that legitimate Outlook clients do not send. Suricata and Snort rules for ProxyShell, ProxyNotShell, and CVE-2024-21410 exist in the ET Open and ET Pro rulesets. They fire reliably on unmodified public PoCs. Operators with capability modify the request shape - pad headers, rotate the SSRF primitive parameters, split the chain across sessions - and the signatures degrade. TLS inspection is required for any of this to work at the network layer. Without it, the chain is invisible to the IDS.

The patch boundary. Microsoft’s out-of-band update addresses the specific parser quirk and the specific deserialization sink. The trust boundary between Client Access frontend and Mailbox backend is unchanged. The PowerShell remoting backend remains reachable from the frontend by design. The serialization formats remain in use. Patching closes the named CVE. It does not close the class. The next variant will use a different parser quirk to reach the same sinks.

Residual exposure post-patch. Exchange Servers that were exposed and unpatched during the active exploitation window should be treated as compromised until proven otherwise. Webshells survive patches. Scheduled tasks survive patches. Forged Kerberos tickets - Golden Tickets minted from a stolen KRBTGT hash, or Silver Tickets minted from the Exchange computer account hash - survive patches and password resets unless the krbtgt account is rotated twice. Exchange Trusted Subsystem and Organization Management group memberships, if added during the intrusion, survive patches. Hash dumps of msExchActiveSyncDevices and the Exchange-relevant ACLs in Active Directory survive patches.

The operational reality. Internet-exposed on-premises Exchange continues to be one of the highest-yield targets in the enterprise estate. The product has not been re-architected. The trust model has not changed. CISA’s Known Exploited Vulnerabilities catalog lists Exchange CVEs across every year since 2020. Microsoft’s own guidance has shifted toward Exchange Online for a reason - the on-premises product is in extended support, not active feature development, and the bug class regenerates faster than the patch cadence. Servers that must remain on-premises should be behind a reverse proxy that terminates and inspects the Autodiscover, OWA, ECP, EWS, and PowerShell paths, with the management endpoints not exposed to the internet at all. /ecp and /powershell have no business being reachable from outside the management network. They are reachable on most deployments because the default install exposes them.

The out-of-band advisory closes one path into a sink that should not exist. The sink will be reached again. Patch, hunt for the indicators in the HttpProxy and ECP logs, validate that no w3wp.exe child processes were spawned during the exposure window, rotate the Exchange computer account secret, audit Exchange-relevant AD group memberships against a known-good baseline. Then assume the next one is already in the queue.