2025-11-17 –, Westin - Partenkirchen
For nearly two decades, Windows has been plagued with NTLM reflection vulnerabilities. This special case of NTLM authentication relay has historically led to local privilege escalation or even remote command execution, although with some limitations. Over time, mitigations against this class of vulnerability were implemented, leading to a false assumption that NTLM reflection attacks were relics of the past. This presentation will shatter that assumption by covering the research that led to the discovery of CVE-2025-33073, a logical vulnerability leading to authenticated RCE as SYSTEM on almost any Windows machine and without any user interaction.
In this talk, fundamental concepts about authentication relay attacks will be explained, as well as the context surrounding the research and the accidental discovery of the vulnerability. Afterwards, a methodical investigation of the root cause of the vulnerability will be presented, first by analysing network captures and then by performing a thorough reverse-engineering of LSASS internals and its NTLM authentication provider.
Subsequently, we will shift our attention to Kerberos, where we will demonstrate that CVE-2025-33073 is not restricted to NTLM and that it also affects Kerberos. After a brief reminder of the protocol, in-depth insights in its integration within LSASS will be discussed as well as an undocumented behavior, to understand why this vulnerability also applies to Kerberos.
Finally, the patch analysis will be presented. We will detail how it fixes the specific attack vector described in this presentation and how it may not be enough to completely eradicate this class of vulnerability. We will conclude by explaining how the exploitation of this vulnerability could have been prevented even before it was found and the current state Windows machine hardening.
Brief Outline
- Introduction
- Vulnerability discovery and root cause analysis
- Applying the vulnerability to Kerberos
- Patch analysis, thoughts on the fix and other mitigations
Detailed Outline
Introduction
In the introduction, we will give a brief reminder on the NTLM protocol and its messages. Afterwards, we will introduce authentication relay attacks and specifically focus on NTLM reflection attacks, where the initial authentication is relayed back the same machine. To illustrate this class of vulnerability, we will give examples of previous vulnerabilities of this kind and how they were patched.
In a second phase, we will present the context of this research and the reason why we started digging into the subject. Security researcher @D1iv3 explained in a tweet (https://x.com/D1iv3/status/1762438159357657404) that no protection against authentication reflection existed for Kerberos. This tweet did not gain much attention at the time, but it made us wonder if this fact could be pushed further than just self relaying to ADCS.
Vulnerability discovery and root cause analysis
This section will describe our thought process during the research, what we tested and why. We will give a reminder on authentication coercion techniques, and more specifically the trick found by James Forshaw to coerce machines into authenticating to a controlled SMB server via Kerberos, by abusing CredMarshalTargetInfo and CREDENTIAL_TARGET_INFORMATION.
We will explain how we quickly (and rather accidentally) found the vulnerability and why we thought at first that it was only limited to NTLM. Afterwards, a demo will be given to the audience, demonstrating remote commande execution as SYSTEM on a fully patched Windows machine (before June 2025) with only a standard user account.
We will then describe our methodical approach to understand the root cause of the vulnerability. We will first begin by comparing network captures of working and failed NTLM reflection attempts to find out that NTLM local authentication was taking place when the reflection worked. At this moment, a slight digression will be made to explain how NTLM local authentication works. Subsequently, a deep dive into LSASS internals will be made, where a comprehensive analysis of the authentication logic, obtained via reverse engineering, will be presented. At the end of this part, the audience will have a strong understanding of the process the NTLM package goes through to decide whether to perform local NTLM authentication, and thus how the vulnerability works.
Applying the vulnerability to Kerberos
In this section, we will explain why and how this vulnerability also applies to Kerberos. To begin with, we will explain why our setup hinted us towards NTLM before Kerberos. We will detail how the Negotiate package works and why it selects NTLM over Kerberos in this specific case. Afterwards, we will show a simple modification to our relay server to actually make Kerberos reflection work.
This second part of this section will be dedicated to understanding why our relayed authentication gives us a SYSTEM token instead of the relayed identity, which is the machine account. Mechanics of local Kerberos authentication will be presented, some public parts will be reminded and other undocumented logic, obtained via reverse engineering, will be exposed. Contrary to what we initially believed, in this specific case, the information about the client's identity is not stored in the KERB-AD-RESTRICTION-ENTRY section of the AP-REQ message, but actually in the subkey field. This subkey is stored in LSASS when a client creates an authentication context, and is checked by the server when it receives a Kerberos authentication from its own machine account. As the security context of the client (SYSTEM in our case) is also stored in memory, a matching access token can be created by LSASS.
Patch analysis and thoughts on the fix
In this final section, we will take a look at the patch issued by Microsoft. As the official advisory mentioned a vulnerability in the SMB client, we diffed the mrxsmb.sys SMB kernel driver. It turned out that the patch was quite simple: if the SMB client receives a target containing a marshalled CREDENTIAL_TARGET_INFORMATION structure, it exits with an error.
We will detail how the patch prevents our specific exploitation scenario, but we will argue that it may not be sufficient for completely removing this attack vector. In addition, we will discuss about the importance of SMB signing, how it completely mitigates any authentication relay attacks and how it would have prevented the exploitation of this vulnerability, even before it was found. We will conclude on the current state of this mitigation on Windows machine and how it is slowly but surely improving.
Guillaume is a penetration tester and security researcher working at Synacktiv. During his career, he developed a healthy addiction to Windows systems and their internals. He is also passionate about Active Directory security, in which he gathered solid knowledge through several Red Team engagements and internal pentests.
Wilfried Bécard is a hacker and researcher working at Synacktiv. With a particular interest in Active Directory and Azure exploitation, his passion lies in uncovering new techniques to enhance cybersecurity in these areas. Constantly experimenting, testing, and collaborating with the security community, he aims at constantly improving his knowledge in these fields.