Introduction

CVE-2025-33073

CVE-2025-33073 was a critical authentication reflection vulnerability leading to Remote Command Execution (RCE) on Windows systems. This class of vulnerability consists in forcing a client on a machine to authenticate to a controlled server and relaying its authentication back to a service of the same machine, to impersonate the coerced client. Reading our detailed analysis of CVE-2025-33073 is highly recommended before diving into this blogpost, to fully understand the technical details. However, the key insights of the inner workings of the vulnerability are reminded below:

• When authenticating to a target, it is possible to append additional target information to the target name, in the form of base64 data.
• This additional data is stripped off the target name by LSASS before constructing authentication blobs (NTLM or Kerberos). For instance, using the target name srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA results in LSASS generating authentication blobs for srv1. This technique will be called the CMTI (CredMarshalTargetInfo) trick in the blogposts.
• srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA is valid DNS record. In addition, by default, domain users can register DNS records in an Active Directory environment.
• When forcing a privileged service (LSASS for example, running as NT AUTHORITY\SYSTEM) to authenticate to a server pointed to by such a DNS record, interesting behaviours will occur for both the NTLM and Kerberos authentication packages:
  • For NTLM, as the sanitized target name equals the machine name, NTLM local authentication will happen. In addition, as the DNS record with additional target information points to a controlled IP address, it will therefore be possible to relay the NTLM local authentication back to the machine and impersonate the privileged service.
  • For Kerberos, as the target name was sanitized, the SPN used to request a service ticket (ST) will be CIFS/SRV1. Once again, as the DNS record with additional target information points to a controlled IP address, the client will send the AP-REQ to our server and the latter will be relayed back to the same machine to impersonate the privileged service.
• Different mechanisms are in place in the authentication packages to infer that the initial client was running as NT AUTHORITY\SYSTEM, but the important part is: after the relay succeeds, we will have an SMB session authenticated as NT AUTHORITY\SYSTEM on the target machine, which is enough to compromise it.

The patch

To mitigate the vulnerability, Microsoft decided to patch the SMB client (mrxsmb.sys) so that it refuses to connect to target with names containing additional target information. It immediately struck us as a strange way of mitigating the issue: if, by any means, another technique was discovered to receive a local NTLM authentication or a Kerberos AP-REQ to a controlled server, the vulnerability would be reintroduced! We therefore decided to investigate if it was indeed possible.

First, we will describe the generic and iterative bypass methodology that was followed during the research. The methodology will be immediately illustrated by disclosing the first vulnerability that we uncovered: a trivial local privilege escalation via NTLM reflection.

Methodology

Principle

The most important thing when trying to bypass a mitigation is thoroughly understanding what it does. Also, having a deep understanding of the original vulnerability is essential to find variants. In our case, it was easy as we already did this analysis a year ago when we reported the vulnerability to Microsoft.

Afterwards, the goal is to imagine as many theoretical lines of attack as possible, which are not covered by the patch. In this step, it is not important that they are viable attack strategies: they just need to be unaffected by the mitigation.

Finally, each attack strategy needs to be assessed based on various criteria: feasibility, prerequisites, etc. Except for the actual viability of the attack, most of the criteria are arbitrary and depend on preferences. For this research, we chose to stick to the following rules:

• The attack must work at least on the latest Windows 11 or Windows Server 2025 version (to be bounty-eligible).
• The attack must work on the default configuration.
• The attack must not require any user interaction.
• The attack must result in either RCE or LPE.

If an attack strategy meets all the predefined criteria, then it is selected and tested. This generic bypass methodology can be summarized by the following diagram:

Use other client protocols

As the patch only applies to the SMB client, we could try to use other client protocols for the authentication coercion. Indeed, the CMTI trick is not tied to the SMB protocol and can be theoretically applied to any protocol that uses NTLM or Kerberos authentication. Apart from SMB, two other protocols can be used for authentication coercion with varying levels of prerequisites: RPC (DCOM included) and HTTP.

RPC

RPC authentication coercion is often induced via DCOM by using a trick documented 10 years ago by James Forshaw. However, since October 2022, the DCOM client always authenticates with at least the RPC_C_AUTHN_LEVEL_PKT_INTEGRITY authentication level, which means that signing will be negotiated when relaying to SMB.

We could change the relay target to HTTP, which does not support integrity mechanisms (except for channel binding on HTTPS). However, by default, Windows machines do not expose any HTTP server that could be leveraged to compromise the machine, which does not match our "default configuration" criteria. There are some well-known HTTP services that can lead to machine (or domain) compromise, such as the ADCS web enrollment or the SCCM AdminService API, but we wanted an exploit applicable to Windows machines without any specific roles or software installed. Therefore, we decided to discard this attack line.

As a side note, this attack strategy was considered by @decoder_it and led to the discovery of CVE-2026-26119, which attacks the HTTP service of the Windows Admin Center.

HTTP

HTTP coerced authentications are mainly obtained via the WebClient service that implements a WebDAV client. For a machine to authenticate via WebDAV (and thus HTTP), the service must therefore be running. It is not the case for Windows desktops, although there are methods to start it, but they require user interaction, which does not fit our criteria. On Windows servers, the service is not even installed.

In addition, at least the majority of Windows HTTP clients will lowercase the target name before generating the authentication blob, which will break the CMTI trick, as it relies on base64 data (which is case-sensitive).

For the above reasons, we decided not to take this path either.

Play with the coercion target

Another possibility was to keep SMB as the relayed client and the relay target but to find other ways to coerce the client into authenticating to a controlled server, while keeping the local authentication aspect of the attack.

Coerce to localhost

Our first idea was to try localhost authentication coercion. Due to the target name being localhost (or a local IP address), the NTLM authentication package would start an NTLM local authentication, which we could relay to the SMB service. The only difficulty is to force the SMB client to authenticate to our SMB server instead of the default one. Additionally, it would mean the impact would be limited to LPE, but it still fits our criteria.

Find another Kerberos coercion primitive

The other obvious attack strategy would be to find an alternative technique to the CMTI trick, that would allow us to receive an AP-REQ message for an arbitrary service. Indeed, no specific mitigations exist for preventing Kerberos reflection attacks (except for integrity or privacy of the communications). The main challenge is to force a Kerberos authentication for an arbitrary service to an arbitrary IP address, as Kerberos is tied to domain names.

The two previous attack ideas were therefore selected. Our generic bypass methodology applied to CVE-2025-33073 is illustrated below:

Local reflection

SMB client arbitrary connect port

When researching this attack path, a previous blogpost from James Forshaw immediately came to mind. In this post, he describes an improvement to his older virtual memory access trap technique which used a remote SMB server to delay access to a file data. The improvement consists in using a relatively new feature, introduced in Windows 11 24H2 and Windows Server 2025, which allows specifying an arbitrary port when connecting to an SMB share. This is precisely what we need!

This new feature is available to any user on a Windows system. To mount a remote SMB share on port 12345, one can therefore run the following command:

C:\> net use \\192.168.56.3\share /tcpport:12345

In terms of implementation, components in both userland and kernel mode were modified to introduce the feature. To establish the connection to the remote share, the WNetAddConnection4W function must be called with an undocumented data buffer in the lpUseOptions parameter. The buffer is an array of the following structure:

struct USE_OPTION
{
  DWORD OptionType;
  DWORD Size;
  BYTE OptionData[];
};

Currently, there are four implemented values for OptionType:

• TraP: Transport parameters. This option type contains, among others, the arbitrary TCP port to use for the SMB connection.
• DefC: Deferred connection parameters.
• ComP: Compression parameters.
• BloN: Block NTLM parameters.

The Size parameter is equal to the USE_OPTION header size (8 bytes) + the size of the actual option data.

During this research, only the data structure for the transport parameters was reverse-engineered:

struct TRANSPORT_USE_OPTION
{
  DWORD TransportType;
  BOOLEAN SkipCertCheck;
  WORD TcpPort;
  WORD QuicPort;
  WORD RdmaPort;
  DWORD PortTypes;
};

The TransportType field has the following values:

• 1 for TCP.
• 2 for QUIC.

The PortTypes field is combination of the following values:

• 1 for TCP.
• 2 for QUIC.
• 4 for RDMA.

The data stored in lpUseOptions is passed to the ntlanman!LmCreateEABufferForUseOptions function. It will parse the buffer and create a new one that will be later passed to the kernel via an FSCTL. Eventually, the SMB client will receive the buffer and parse it in mrxsmb!MRxSmbSetNetUseSpecifiedTransportInfo to determine if the connection should be made on an alternative port.

Interestingly enough, when discussing this feature, James also mentioned:

I personally think making it enabled by default is a mistake that will come back to cause problems for Windows going forward.

Well, as often, he was right.

The attack idea is therefore to set up a local SMB server on a different port than 445 and force a privileged service to authenticate to it. However, the following problem arose: how to inform the privileged service that it must connect to our server on a custom port, instead of port 445? Indeed, to force a service to authenticate to an arbitrary SMB share, we typically instruct it to open a file by providing a file path with the UNC syntax: \\IP\SHARE. The UNC syntax does not support specifying a port (except for WebDAV shares). Furthermore, net use only affects the current user session: for obvious security reasons, a user must not be able to access the authenticated SMB session of another user.

SMB multiplexing

It turns out that this is actually not an issue! The official MS-SMB2 specification (section 3.2.4.2) states:

If a new session is being established, the client MAY reuse an existing connection such that multiple sessions are multiplexed on the same connection. If not reusing an existing connection, the client can establish a new connection for the new session.

In other words, SMB differentiates between the TCP connection and the authenticated session: multiple authenticated sessions can use the same TCP connection as transport. In addition, the Windows SMB client reuses TCP connections.

Local privilege escalation

The exploitation strategy consists of two main steps:

1. Start a local SMB server on port 12345 and mount it. It will make the SMB client establish a TCP connection to our share and keep it open for later use. Note that for this step, it is not necessary to have valid credentials, the local share can be set up to accept specific credentials (user:user for example) and net use can be instructed to authenticate with the same credentials.

2. Coerce a privileged service (LSASS for example) to authenticate to the same share that was previously mounted. It is mandatory to use the same share path, so that the SMB client reuses the same TCP connection that was established when mounting the specific share. The service will authenticate to our custom SMB server and the local NTLM authentication will be relayed to the true SMB service of the machine, resulting in a privileged SMB session and therefore compromise of the machine.

To build a working PoC, the following tools were used:

• smbserver.py from Impacket: Used to start an SMB service on a custom port, receive the privileged local NTLM authentication blob and forward it to the relay server. A few modifications were made to the tool to parse the privileged authentication blob which is received on the same TCP connection than the one on which the share was mounted.
• ntlmrelayx.py from Impacket: Used to relay the privileged authentication blob back to the built-in SMB service of the machine and execute commands as NT AUTHORITY\SYSTEM.
• net.exe: Used to mount the custom SMB share on a specified TCP port.
• PetitPotam.exe: Used to coerce LSASS into authenticating to the custom SMB service. A few modifications were made to make it work locally.

This vulnerability was assigned CVE-2026-24294 and was patched in March 2026 Patch Tuesday. It works by default on Windows Server 2025 but not on Windows 11 24H2 because SMB signing is enforced.

Conclusion

In this first blogpost, the key insights of CVE-2025-33073 were reminded and the context of the research was presented. We also described the generic bypass methodology that was followed and immediately applied it to derive two main attack paths that could yield potentially interesting results.

We then abused a new feature of recent Windows versions, namely the ability to connect to SMB shares on arbitrary TCP ports, to achieve local privilege escalation on up-to-date Windows Server 2025 machines. In parallel, it also proved that our initial assumption about the patch incompleteness was right: it did not address the root cause. The ability to relay local authentications still puts Windows machines at risk.

In the next part, we will tackle the other line of attack mentioned in the methodology section: finding another arbitrary Kerberos authentication primitive. Starting with total control of DNS, the attack vector will progressively be refined to finally achieve a full-blown RCE primitive as domain user, thus completing our quest to achieve a full bypass of CVE-2025-33073.