There’s a Severe Privilege Escalation Vulnerability in Windows RPC Protocol That Microsoft Won’t Fix

Written by Bill Toulas
Last updated September 23, 2021

Researchers at SentinelOne warn about a severe privilege escalation flaw affecting all Windows systems, which is reportedly not in Microsoft’s patching plans. According to the detailed write-up of the Italian researchers who have made the discovery, it is practically possible to trigger an authenticated RPC/DCOM call and relay the NTLM authentication to other protocols, launching a man-in-the-middle (MITM) attack and capture everything that flies back and forth. For this to work, it would be enough for the attacker to be a low-privileged user with limited rights on the target machine.

Source: SentinelOne

The eight steps to exploit the capability to launch the cross-protocol mayhem are given below:

  1. An attacker has a shell in Session 0 on the “victim” machine with a low privileged account;
  2. On this machine, a privileged user, like a Domain Admin, is logged on interactively;
  3. The attacker triggers the DCOM activation service by unmarshalling an IStorage object, calling CoGetInstanceFromIstorage with one of the CLSIDs that impersonate the user logged on interactively and setting the IP of the attacker machine for Oxid resolution requests;
  4. The attacker implements a MITM by just listening on port 135 on his machine, which will receive the IObjectExporter::ResolveOxid2 authenticated call and be forwarded to the “fake” Oxid resolver. Even if this call is authenticated, the NTLM “Sign flag” is set so it will be skipped;
  5. The fake Oxid resolver returns a string binding for an RPC endpoint under the attacker’s control;
  6. The victim machine/user will make an authenticated call IRemUnknown2::RemRelease contacting the RPC server (without the Sign flag set);
  7. Authentication will be relayed to a privileged resource such as LDAP, SMB, HTTP, or other.
  8. Implemented the whole logic of the MITM and HTTP encapsulator in a POC (RemotePotato0). Then forward everything to ntlmrelayx and let it do the job by targeting the LDAP server running on the Domain Controller and adding a new domain admin (or elevate user privileges).
Source: SentinelOne

The researchers have even released a short demonstration of a proof of concept, as shown below. Source code for the PoC is also available on this GitHub repository.

Source: SentinelOne

If you’re wondering why Microsoft isn’t planning to fix this, the official explanation is that “Servers must defend themselves against NTLM relay attacks,” so the software giant finds this to be outside the scope of its responsibility. The researchers note that simply setting the sign flag in the NTLM provider as well as SPNEGO would have inhibited this exploit, so it appears that Microsoft simply wants to avoid creating a burdening precedent here.

If you’re worried about this flaw and its interaction-less exploitation potential, there are some things you can do to mitigate it. SentinelOne suggests the following:

This flaw was discovered in November 2020, so it’s been a while already. The researchers hadn’t disclosed it on February 2021, when the 90-day disclosure was reached, as Microsoft initially asked them to wait until April 13, 2021, which would be when the promised fix would land. SentinelOne agreed with this, but Microsoft changed its mind when its engineers looked deeper into this, and so the disclosure came.

For a better user experience we recommend using a more modern browser. We support the latest version of the following browsers: For a better user experience we recommend using the latest version of the following browsers: