I’ve marked this as difficult to exploit due to the number of conditions that must be met for an attacker to successfully leverage it.
Exploiting this vulnerability is not straightforward; there are multiple security restrictions in place to prevent exploitation.

1. The attacker needs the credentials of a valid user.
   

2. The attacker needs to be on the local area network.

   More specifically, the user needs to have access to the Domain Controller / KDC to authenticate to the Exchange service with Kerberos (tcp/88).

3. [loadFromRemoteSources](https://learn.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/dd409252(v=vs.100)) needs to be enabled in the Exchange server’s .NET application configuration.

   This is a discrepancy between what I have observed and what is stated in the public analysis. The translated statement “但是好在还可以通过SMB共享加载其他机器上的程序集。” (translation: “But fortunately, you can also load assemblies on other machines through SMB sharing.”) appears to be false. When using .NET Framework 4, Exchange Server 2019 CU12 is unable to load the FUSE.Paxos.dll library from an SMB server as specified by a UNC path. In the default settings, the server even raises a System.IO.FileLoadException exception when the path is local (e.g. C:\Shares ). Exchange Server 2019 requires .NET Framework version 4.8 to be installed, so there will not be any instances where an older version is in use that does not implement the loadFromRemoteSources setting.

   Furthermore, according to More Implicit Uses of CAS Policy: loadFromRemoteSources which states:

   For example, in .NET 3.5 the following code:

   Assembly internetAssembly = Assembly.LoadFrom(@"https://www.microsoft.com/assembly.dll");
   Assembly intranetAssembly = Assembly.LoadFrom(@"\\server\share\assembly.dll");
   

   Will by default load internetAssembly with the Internet permission set and intranetAssembly with the LocalIntranet permission set.   That was because the CLR would internally gather evidence for both assemblies and run that evidence though CAS policy in order to find the permission set to grant that assembly.

   Now that the sandboxing model has changed in the v4 CLR, there is no more CAS policy to apply the assembly’s evidence to by default, and  therefore default behavior of both of these loads would be to load the assemblies with a grant set of full trust.

   A UNC path would have the LocalIntranet permission set by the CLR and the CAS policy in .NET 3.5. In version 4.0 though, it is prevented from loading without enabling loadFromRemoteSources because it would receive a grant set of full trust. This is aligned with the observed behavior.

4. A crafted FUSE.Paxos.dll file must be placed in a location accessible from the target Exchange Server.

   Realistically, this will probably be on a network share that the attacker can write to that the Exchange Server can authenticate to and read from. Using default settings, the attacker can not host it on their own SMB server because Windows blocks shared folder access as unauthenticated guests.

If all of the necessary conditions are met, the vulnerability can be exploited reliably. The result is code execution in the context of NT AUTHORITY/SYSTEM as a new process is created. Starting a new process could be avoided by modifying the source of FUSE.Paxos.dll.

The vulnerability centers around the capability of Microsoft.Exchange.DxStore.Common.DxSerializationUtil.SharedTypeResolver to bypass system checks.

This vulnerability is exploited by leveraging the Microsoft.Exchange.DxStore.Common.DxSerializationUtil.SharedTypeResolver class to evade the .NET Framework’s default security restrictions. This class can be employed to load assemblies from remote locations, subsequently enabling the execution of arbitrary code on the victim’s system.

To exploit this vulnerability, an attacker must first gain LAN access to the victim’s Exchange server. Once this access is obtained, the attacker can send a specially crafted HTTP request to the server, triggering the exploitation of the vulnerability. If successful, the attacker gains the ability to execute arbitrary code on the victim’s system.

Security researcher N1k0la publicly disclosed the issue and shared a PoC of this vulnerability.