August 05, 2022
Infosec Writeups

Microsoft Exchange Server-Side Forgery Request (Proxylogin)

microsoft exchange ssrf


Microsoft Exchange ServerSide Request Forgery (SSRF), popularly known as ProxyLogon, is the most well known Microsoft Exchange Server vulnerability. Discovered in 2021, this vulnerability allows anyone, without any prior authentication, to easily execute the exploit code on Microsoft Exchange Server through port 443. CVE-2021-26855 is a bug that results in authentication bypass by performing pre-authentication SSRF.

CVE ID: CVE-2021-26855
Severity: - CRITICAL
CVSS Score V3: 9.8
CVSS Vector - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H


Microsoft Exchange server has an architecture consisting of multiple building blocks designed for providing availability, load balancing, and communication between different servers. Each server runs multiple layers of protocols that are used for enabling access to the various clients and to communicate with the servers. Clients cannot directly communicate with backend services. Instead, they have to go via frontend APIs like Outlook Web Apps (OWA).

A proxy lies between the client and the backend service in order to transfer requests between OWA and the backend. OWA runs on port 443 whereas Exchange Backend service is bound to port 444.

This is where the ProxyLogon vulnerability exists

Exhibit: This is where the ProxyLogon vulnerability exists (source: BlackHat Conference)

The implementation code of the Exchange server consists of a method called “GetTargetBackEndServerUrl” which retrieves the Backend URL from the static resource handler and it directly assigns the Backend target with the use of cookies. The Frontend Proxy first makes use of the “GetTargetBackendServerURL” method to determine which Backend URL the HTTP request should be forwarded to. Then, it initializes a new HTTP Client request with the method “CreateServerRequest”.

 BlackHat Conference

Exhibit: This code (HttpProxy\OwaResourceProxyRequestHandler.cs) shows how the Backend URL is assigned using the value of Cookies like “X-AnonResource-Backend” (source: BlackHat Conference)


Exposed Instances of CVE-2021-26855

Exhibit: Exposed Instances of CVE-2021-26855

Exposed Instances of CVE-2021-26855 worldwide

Exhibit: Exposed Instances of CVE-2021-26855 worldwide

Exhibit: Run the nuclei command to scan the list of exchange URLs to check if the application is vulnerable to CVE-2021-26855 and intercept the request using Burp

Steps to exploitation

  1. Load the login page and intercept the request.
  2. Modify the HTTP request by adding the Burp Collaborator URL in place of the value present in the Cookie Header “X-AnonResource-Backend”, then send the request.
  3. A callback at the Burp Collaborator is received, both HTTP as well as DNS request. It can be observed that it discloses some internal information related to the Exchange Server.
  4. As observed below, an SSRF was executed and it was able to communicate with the external server to successfully retrieve the data.


The exploitation of this vulnerability may result in gaining the sensitive information present in the internal network, eventually allowing us to download user emails and gain full access of the mail server. With such privileges, anyone can redirect emails to reveal sensitive information outside the organization. This CVE has been assigned a severity of CRITICAL; if this vulnerability is combined with another CVE, CVE-2021-26857 (Unified Messaging Insecure Deserialization), or CVE-2021-26858 (Post-Authentication Arbitrary File Write), it can lead to remote code execution on the Exchange Server.


There are some ways through which we can detect this:

  1. MSERT (Microsoft Safety Scanner) and the Microsoft IoC Detection Tool for Exchange are tools in Windows Defender to detect Exchange Server-related vulnerabilities.
  2. Microsoft also released a Powershell script, Test-ProxyLogon, which searches for indicators of compromise. To learn more about this script, refer to Microsoft’s Github entry.


  1. Microsoft recommends users to install the security patch to consider mitigation complete. It does not affect any existing functionality.
  2. In the event that you are unable to install the patch, there are some interim mitigation techniques you can apply, such as implementation of the IIS Re-Write Rule for filtering malicious HTTPS requests. Additionally, you need to disable Unified Messaging (UM), Exchange Control Panel (ECP), VDir, and Offline Address Book (OAB). The mitigations suggested above can be applied by executing the ExchangeMitigation.ps1 script.
  3. Perform Backend Cookie Mitigation. It will filter the HTTPS requests containing malicious X-AnonResource-Backend and X-BEResource cookies which may be used in SSRF attacks.