ProxyNotShell What It Is, How It Works, and How to Fix It

If you run on-premises Microsoft Exchange (2013, 2016, 2019), you likely heard of ProxyNotShell.

Below is the clear, step-by-step path: understand the bug, patch correctly, verify mitigations, and check for compromise, plus how it differs from ProxyShell and OWASSRF.

Before You Start (Quick Prep)

• Confirm your Exchange version and build.
• Ensure you have server backups and a change window.
• Collect IIS and Exchange logs plus EDR telemetry for later review.
• Make sure you can run PowerShell as an Exchange admin.

1) Understand ProxyNotShell in Plain English

• CVE-2022-41040 is a server-side request forgery (SSRF) that requires authenticated access.
• CVE-2022-41082 is remote code execution when Exchange PowerShell is reachable.

Why it is dangerous: attackers authenticate using weak or stolen credentials, trigger SSRF, then reach Exchange PowerShell to run code. This is similar in nature to other proxy-related flaws like the Proxy Error 2606 issue, where incorrect server handling can expose attack surfaces.

Scope: On-premises Exchange 2013, 2016, 2019. Exchange Online is not affected.

2) Patch: Get to a Safe Baseline

1. Check your build in Exchange Management Shell:
   Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion
2. Install the latest Exchange Cumulative Update (CU) supported for your version.
3. Install the latest Security Update (SU) from Microsoft, released in November 2022 and later.
4. Reboot and re-run the build check to confirm.
5. Re-enable normal operation if you had emergency mitigations that were blocking traffic.

Why not rely on the old URL Rewrite? Those IIS rules were temporary and have known bypasses. They must not replace patching. If you have ever troubleshot cases like a Proxy Error 502, you know that relying on temporary fixes often creates blind spots.

3) Remove or Update Legacy Mitigations

1. Open IIS Manager, then your Exchange site, then URL Rewrite.
2. Document then remove any ProxyNotShell request-blocking rules, for example patterns combining autodiscover and powershell.
3. If you use Microsoft’s Exchange Emergency Mitigation or other tooling, ensure policies are updated.
4. Restart IIS:
   iisreset /restart

Misconfigured mitigations can cause strange behavior, much like when admins face a Proxy Error 407 authentication required on network devices.

4) Verify Exposure Is Reduced

1. Restrict remote PowerShell to admins only, using policy or RBAC.
2. Enable Extended Protection in IIS for Exchange virtual directories.
3. Enforce MFA for OWA and ECP sign-ins and publish Exchange behind a reverse proxy or WAF.
4. Disable legacy authentication, enforce strong password and lockout policies, and monitor brute-force attempts.

Exchange admins who skip these steps can run into scenarios similar to a Proxy Error 500, where backend services fail silently but attackers still exploit the gaps.

5) Hunt for Compromise

Look back to at least September through December 2022 and onward, depending on when patching occurred.

Where to Look

• IIS logs: C:\inetpub\logs\LogFiles\W3SVC*
• Exchange logs: ECP, OWA, PowerShell virtual directory logs
• Windows Event Logs: PowerShell operational, Security, Sysmon or EDR

What to Look For

• Requests involving Autodiscover and PowerShell patterns hitting Exchange VDirs.
• Suspicious OWA or ECP requests followed by PowerShell activity.
• Unexpected child processes spawned by w3wp.exe or powershell.exe.
• Web shell artifacts in Exchange paths or odd ASPX or JS files.

Strange log entries can mimic issues admins face when diagnosing errors like Proxy Error No Response from Bot PSGHAG2.

Quick Triage Commands

Recent PowerShell events:

Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" |
  Where-Object {$_.TimeCreated -gt (Get-Date).AddDays(-14)} |
  Select TimeCreated, Id, Message

Search IIS logs for suspect patterns:

Get-ChildItem "C:\inetpub\logs\LogFiles" -Recurse -Filter *.log |
  Select-String -Pattern "autodiscover","powershell","/owa/","/ecp/" |
  Select Path, Line

If you find indicators, isolate the server, export forensics, reset credentials, and follow your incident response plan. Exchange compromises can escalate quickly, just as unhandled Proxy Error 503 outages can cascade across services.

6) Understand the OWASSRF Bypass

Researchers observed a new exploit chain dubbed “OWASSRF” that pairs CVE-2022-41080 with CVE-2022-41082 to bypass URL-rewrite rules. Only proper Microsoft updates reliably protect Exchange, rewrite rules are insufficient. This is much like diagnosing a Could Not Proxy Request error, where underlying flaws demand real fixes instead of quick patches.

7) Post-Patch Ongoing Hygiene

1. Track CUs and SUs quarterly, subscribe to Microsoft Exchange release notes.
2. Monitor OWA and ECP authentication anomalies.
3. Baseline Exchange PowerShell usage and alert on deviations.
4. Segment Exchange from internet exposure with a reverse proxy or WAF.
5. Run periodic compromise sweeps on IIS and Exchange paths and Windows event logs.

Neglecting this can be like dealing with a Proxy Not Found error where you keep hitting walls without structured monitoring.

In some cases, Exchange misconfigurations behave similarly to a Proxy Not Controllable issue, where the system does not respond to administrative fixes until re-architected properly.

Comparison: ProxyNotShell vs ProxyShell vs OWASSRF

Vector	Year	CVEs	Auth Required	Technique	Impact	Mitigation Status
ProxyNotShell	2022	41040 + 41082	Yes	SSRF pivot to Exchange PowerShell	RCE	Patched via November 2022 updates
ProxyShell	2021	34473 + 34523 + 31207	No	Unauth chain to EWS or Autodiscover	RCE, web shells	Patched in 2021
OWASSRF	2022	41080 + 41082	Varies	OWA SSRF path bypassing rewrite	RCE	Requires latest patches

Comparison tables like this help admins prioritize risks, similar to using guides on Proxy Server Cannot Establish Connection with Target errors.

Tips

• Do not expose Exchange directly, front it with a proxy layer and strong authentication.
• Inventory hybrid servers, even minimal roles can be vulnerable if unpatched.
• Document emergency mitigations and review them post-patch. For network admins, this resembles the process of repairing an IP address proxy error to ensure stable configurations.

FAQ

Summary

1. Identify Exchange versions and back up.
2. Patch to the latest CU and SU.
3. Remove legacy URL-rewrite mitigations.
4. Harden PowerShell access and IIS.
5. Hunt for compromise in logs.
6. Monitor and schedule regular updates.

Conclusion

ProxyNotShell is a chain, SSRF to PowerShell-driven RCE, that affected on-premises Exchange. The definitive fix is up-to-date Microsoft patches. Treat URL-rewrite rules as history, not protection. Patch, verify, hunt, and then keep Exchange on a tight update and monitoring cadence.