NTLM reflection is dead, long live NTLM reflection: Story of an accidental Windows RCE

NTLM reflection is dead, long live NTLM reflection: Story of an accidental Windows RCE

Speakers: Wilfried Bécard (Synacktiv)

Conference: Hexacon

YouTube: https://www.youtube.com/watch?v=rk33Hzu0h38

Overview

This talk, presented by Wilfried Bécard of Synacktiv, delves into the accidental discovery and intricate mechanics of a novel Windows remote code execution (RCE) vulnerability, initially misclassified by Microsoft as an elevation of privilege (EoP). The research, co-authored with his colleague Gum, uncovers a critical flaw in how Windows handles NTLM and Kerberos authentication reflection, leading to NT AUTHORITY\SYSTEM compromise on vulnerable machines. Bécard meticulously details how a specific crafted DNS record, leveraging a technique previously discovered by James Forshaw, bypasses long-standing mitigations against reflection attacks, enabling an attacker to coerce a machine into authenticating to itself with elevated privileges.

The significance of this vulnerability, assigned CVE-2023-28252 with a CVSS score of 8.8, lies in its high impact, relative simplicity, and stability. It demonstrates that even seemingly patched attack vectors can resurface through subtle logical bypasses. The talk emphasizes that this RCE can be exploited by any authenticated user on Windows machines where SMB signing is not explicitly enforced—a default configuration for many older and even some newer Windows installations. The fact that at least seven independent researchers or companies discovered and reported this flaw to Microsoft within a short timeframe underscores its inherent exploitability and potential widespread impact, making it a crucial topic for defenders and red teamers alike.

Background

▶ Watch: Vulnerability overview: Accidental Windows RCE (0:30)

The landscape of Windows authentication security has a rich history of NTLM relay and reflection attacks, dating back to at least 2008 and 2009. These attacks have consistently led to privilege escalation or remote code execution, prompting Microsoft to implement various patches and mitigations over the years. Despite these efforts, the underlying principles of coercing authentication and relaying credentials remain potent attack primitives. Bécard's research builds upon this legacy, exploring how modern techniques and configurations interact with these historical vulnerabilities.

To understand the core of this discovery, several foundational concepts are essential:

1. Authentication Coercion: This technique involves forcing an identity, whether a user or a machine account, to authenticate to an attacker-controlled server. Coercion methods can be deterministic or non-deterministic. A popular deterministic method involves performing an RPC (Remote Procedure Call) to a service like EFS RPC (EncryptFileSrv), specifying a UNC path (e.g., \\attacker_ip\share) as the target for a file operation. The target machine's SMB client then attempts to connect to the attacker's server, initiating an authentication handshake.

1. Authentication Relay: Once a client is coerced into authenticating to an attacker's server, the attacker receives the client's authentication blob (e.g., NTLM Challenge-Response). In an authentication relay attack, this blob is then forwarded or "relayed" to another legitimate service or machine, allowing the attacker to impersonate the original client on that secondary target.

1. Authentication Reflection: This is a specialized form of relay where the authentication blob is relayed back to the same machine from which it originated. Historically, this has been a powerful attack vector for local privilege escalation, as a machine could be coerced into authenticating to itself, and its own credentials then reflected to a local service to gain control. Microsoft has implemented specific mitigations to prevent such reflection attacks.

1. Kerberos Authentication Coercion: While NTLM attacks are well-understood, Kerberos coercion presents more challenges due to its reliance on DNS and Service Principal Names (SPNs). Kerberos tickets are requested for specific SPNs (e.g., CIFS/SRV1), which are constructed by the client based on the server's hostname or FQDN, resolved via DNS. An attacker typically lacks control over the target's DNS resolution, making direct Kerberos coercion to an arbitrary IP difficult. However, a significant breakthrough by James Forshaw demonstrated that a Marshall Credential Target Information structure (a long Base64-encoded string) can be appended to an SPN (e.g., CIFS/SRV1/<long_base64_string>). Crucially, the LSASS (Local Security Authority Subsystem Service) process discards this structure before making the Kerberos ticket request, yet the DNS system can still resolve a record pointing to the attacker's IP. This allows an attacker to register a crafted DNS record pointing to their IP, coerce a machine to authenticate to this record, and receive a Kerberos AP-REQ message for the desired SPN, effectively enabling Kerberos relay/reflection.

Key Findings

▶ Watch: Core concept: Authentication relay and reflection (4:00)

The discovery of this vulnerability, tracked as CVE-2023-28252, was serendipitous. While researching Kerberos reflection attacks using tools like pipotam for coercion and krbrelayx.py for relay, Wilfried Bécard encountered an unexpected error: unsupported mech type NLM SSP. This was puzzling because Kerberos is typically preferred over NTLM in Windows environments, and he was using hostnames/FQDNs, not IP addresses, which should favor Kerberos.

Switching to an NTLM relay tool, ntlmrelayx.py, for debugging purposes, yielded a surprising outcome: the NTLM authentication succeeded, and more alarmingly, resulted in a privileged SMB session. This directly contradicted the expectation that reflection attacks were patched by Microsoft, especially without any unusual registry settings in the test environment. This "accidental discovery" quickly escalated to a confirmed vulnerability when a colleague, initially skeptical, replicated the results.

The key findings are:

• Bypass of Existing Reflection Mitigations: The vulnerability effectively circumvents Microsoft's previous patches against NTLM and Kerberos reflection attacks by exploiting a specific interaction between the Marshall Credential Target Information structure and the SMB client's authentication logic.
• Remote Code Execution (RCE) via SYSTEM Privileges: Contrary to Microsoft's initial classification as an Elevation of Privilege (EoP), the attack consistently results in RCE with NT AUTHORITY\SYSTEM privileges. This is because the SMB client, which initiates the coerced authentication, runs in the System process, and the reflection allows the SMB server to impersonate this highly privileged token.
• Broad Applicability: The attack works on virtually all Windows machines that do not explicitly require SMB signing. This is a critical point, as SMB signing is often not enabled by default, especially on older Windows versions, leaving a vast attack surface.
• Authenticated User Requirement: Any authenticated user can trigger this vulnerability, making it a potent post-exploitation primitive for lateral movement and privilege escalation within a compromised network.
• Kerberos Reflection Also Possible: While the initial discovery was NTLM-based, the research confirmed that Kerberos reflection is also possible and yields SYSTEM privileges, provided the SMB server is configured not to advertise NTLM, forcing the client to use Kerberos.

This accidental discovery highlights the persistence of logical vulnerabilities in complex systems and the need for continuous scrutiny of security mechanisms, even those considered "patched."

Technical Deep Dive

▶ Watch: James Forshaw's Kerberos reflection discovery (6:00)

The core of this vulnerability lies in a subtle interaction within the Windows SMB client's authentication workflow, specifically how it decides to "hint" for local NTLM authentication when presented with a crafted SPN containing Marshall Credential Target Information.

The NTLM Reflection Bypass: Local NTLM Authentication Hinting

When Bécard observed the unsupported mech type NLM SSP error during Kerberos relay, it suggested that for some reason, NTLM was being preferred or triggered in a way that krbrelayx.py wasn't expecting. A deep dive using Wireshark to compare NTLM exchanges revealed critical differences:

• Using an IP Address for Coercion: When coercing using a direct IP address, the NTLM SSP challenge flags indicated "standard local NTLM authentication."
• Using the Crafted DNS Record: When coercing using the crafted DNS record (e.g., srv1.domain.com/<base64_string>), the flags indicated a "specific case for local NTLM authentication." Crucially, the CallingWorkstationDomain and CallingWorkstationName fields in the NTLM Negotiate message were populated with the machine's hostname and domain, which were empty when using an IP address. This was the "hint."

Understanding Local NTLM Authentication:

The NTLM authentication process involves several steps between the client, the LSASS service, and the NTLM SSP (Security Support Provider):

1. Client Initiates: The client calls InitializeSecurityContext, communicating with LSASS and the NTLM SSP.
2. Server Context Creation: The NTLM SSP, on the server side (which in a reflection attack is the same machine as the client), creates a local context in its memory with a unique identifier (e.g., 10002).
3. Challenge Exchange: The NTLM SSP sends an NTLM Challenge, including this context ID, back to the client.
4. Response with Context ID: The client responds with the NTLM Authenticate message, also including the context ID.
5. Token Handle Association: When the NTLM SSP receives this, it looks up the context ID in its memory. If found, it associates a token handle for the client's identity within that context structure.
6. Authentication Success: The authentication succeeds, and the service can then impersonate the client using this token handle.

The "Hinting" Mechanism:

The critical insight was why the SMB client decided to hint the server to perform local NTLM authentication when using the crafted DNS record. This decision occurs within the SMB client's authentication workflow:

1. Connection to Crafted DNS Record: The SMB client connects to the attacker-controlled IP resolved by the crafted DNS record.
2. LSASS Processing: The client's kernel driver (MRxSmb.sys) makes an LPC (Local Procedure Call) to LSASS.
3. SPN Transformation: LSASS, specifically the LSAP_CHECK_MARSHALL_TARGET_INFORMATION function, discards the Base64-encoded Marshall Credential Target Information structure from the SPN, effectively transforming CIFS/SRV1/<base64_string> into just CIFS/SRV1.
4. Client Local Authentication Hinting: This is where the decision is made. The SPN_GET_TARGET_NAME function extracts SRV1 as the target name. Windows then performs checks:

• Is the target name the machine's hostname, FQDN, or "localhost"? In this case, SRV1 matches the local machine's hostname.
• Are we requesting a new session? No.
• Are explicit credentials provided? No.

Because SRV1 matches the local machine's hostname and no explicit credentials or new session requests are made, the SMB client hints the server to perform local NTLM authentication. This hint, reflected in the CallingWorkstationDomain and CallingWorkstationName fields, causes the NTLM SSP to engage its local authentication path, which is vulnerable to reflection.

Privilege Escalation to SYSTEM:

The reason this leads to NT AUTHORITY\SYSTEM RCE is straightforward: the SMB client itself runs within the highly privileged System process. When the local NTLM authentication succeeds, the SMB server (also running on the same machine) impersonates the client's token. Since the client is the System process, the server gains the NT AUTHORITY\SYSTEM token, allowing it to perform any action on the machine.

Kerberos Reflection (Also SYSTEM):

The research also confirmed that Kerberos reflection is possible and similarly leads to SYSTEM privileges. The initial failure was due to NTLM's preference. If the SMB server is configured not to advertise NTLM, Kerberos will be used.

The Kerberos loopback workflow for NT AUTHORITY\SYSTEM clients is distinct:

1. Client Initiates: The client calls InitializeSecurityContext with LSASS and the Kerberos SSP.
2. Subkey Entry Creation: The Kerberos SSP creates a subkey entry in its memory, containing a LoID (referring to System), a randomly generated cryptographic key, and a SYSTEM token handle.
3. AP-REQ with Subkey: The Kerberos SSP sends an AP-REQ back to the client, which includes this subkey within the ticket.
4. Service Validation: The client sends the AP-REQ to the service. The service, interacting with LSASS and the Kerberos SSP, extracts the client name from the ticket (e.g., SRV1).
5. SYSTEM Token Retrieval: If the client name matches the local machine and the subkey from the ticket matches one of the subkey entries in the Kerberos SSP's memory, the authentication succeeds, and the associated SYSTEM token handle is used for impersonation.

This specialized loopback logic for SYSTEM clients is the reason Kerberos reflection also results in SYSTEM-level compromise.

Demo / Proof of Concept

▶ Watch: Practical steps for Kerberos reflection exploitation (6:40)

Wilfried Bécard provided a concise yet impactful demonstration of the vulnerability's remote code execution capabilities. The proof of concept involved using the ntlmrelayx.py tool, a component of the Impacket toolkit, configured to execute an arbitrary binary.

The setup was as follows:

1. An attacker machine was running a netcat listener on port 443, awaiting an incoming reverse shell.
2. On the attacker machine, ntlmrelayx.py was started with the -e option, specifying a command to execute a reverse shell binary that would connect back to the attacker's netcat listener.
3. A low-privilege user on the target Windows workstation was used to perform the authentication coercion. This was done by forcing the workstation to authenticate to the attacker's controlled IP, which was linked to a specifically crafted DNS record containing the Marshall Credential Target Information structure.

Upon initiating the coercion, the ntlmrelayx.py tool successfully intercepted the NTLM authentication, reflected it, and then proceeded with the RCE payload:

• It identified a writable share on the target machine, specifically the ADMIN$ share (which is typically accessible by SYSTEM).
• It wrote the reverse shell binary to this share.
• It then created and started a service on the target to execute the newly written binary.

Immediately after execution, the attacker's netcat listener received an incoming connection, providing a shell with NT AUTHORITY\SYSTEM privileges on the compromised workstation. This live demonstration unequivocally proved the remote code execution capability and the high impact of the vulnerability.

Defensive Implications

▶ Watch: Accidental vulnerability discovery during research (8:00)

The discovery of this NTLM/Kerberos reflection bypass has significant implications for defensive strategies. While Microsoft has released patches, understanding the underlying mechanisms is crucial for robust security.

1. Enable SMB Signing: This is the paramount recommendation. SMB signing (also known as message signing) ensures the integrity and authenticity of SMB traffic. If SMB signing is enforced, an attacker cannot relay or reflect authentication because the manipulated or reflected NTLM/Kerberos messages would lack the correct cryptographic signature, causing the authentication to fail. Crucially, SMB signing is often not enabled by default on Windows machines, particularly older versions, leaving them vulnerable. Organizations should prioritize enabling SMB signing across their entire Windows infrastructure.

• On Windows servers, this is typically configured via Group Policy under "Computer Configuration" > "Windows Settings" > "Security Settings" > "Local Policies" > "Security Options," specifically "Microsoft network server: Digitally sign communications (always)."
• For clients, the corresponding policy is "Microsoft network client: Digitally sign communications (always)."

1. Apply Microsoft Patches (CVE-2023-28252): Microsoft released a patch for this vulnerability in June 2023. Applying this patch is essential. The patch specifically targets the MRxSmb.sys driver, which is responsible for the SMB client's functionality.

• Patch Analysis: The patch introduces a new check within the Smb2CreateSrv function. This function is invoked when the SMB client attempts to access a resource. The new check specifically looks for the presence of the Marshall Credential Target Information structure within the target name. If this structure is detected, the authentication process is aborted, and no incoming authentication is received by the attacker. This effectively prevents the coercion mechanism that underpins the attack.

1. Impact on Kerberos Relay Primitives: A side effect of Microsoft's patch is that it also breaks the Kerberos relay primitive that relies on the Marshall Credential Target Information structure. While this specific primitive was useful for certain Kerberos relay attacks, its disruption is a positive outcome for overall security.

1. Network Segmentation and Least Privilege: While not directly addressing the vulnerability's technical bypass, foundational security practices like network segmentation can limit the blast radius of such attacks. Furthermore, adhering to the principle of least privilege for all user and service accounts can mitigate the impact of any successful privilege escalation.

1. Monitor for Authentication Coercion Attempts: Security teams should monitor for unusual authentication attempts, especially those involving RPC calls to services like EFS RPC with UNC paths pointing to suspicious external or internal IPs. While detection can be challenging, anomalies in authentication logs could indicate an ongoing attack.

In conclusion, this vulnerability underscores that logical flaws can persist even after multiple rounds of patching. SMB signing, often overlooked or deemed too disruptive, proves to be a robust defense against a class of high-impact relay and reflection attacks, including this accidental RCE.

Key Takeaways

• NTLM and Kerberos Reflection Remain Viable: Despite years of patches and mitigations, NTLM and Kerberos reflection attacks can still be successfully executed on Windows systems, leading to high-impact vulnerabilities.
• Marshall Credential Target Information is Key: The technique of appending a Marshall Credential Target Information structure to an SPN, originally identified by James Forshaw for Kerberos relay, is crucial for bypassing existing reflection mitigations in both NTLM and Kerberos contexts.
• Accidental Discovery, High Impact: The vulnerability (CVE-2023-28252) was an accidental discovery during Kerberos research but proved to be a critical RCE, allowing any authenticated user to achieve NT AUTHORITY\SYSTEM privileges on vulnerable Windows machines.
• SMB Signing is a Critical Defense: Enabling SMB signing is the most effective mitigation against this specific attack and a broader class of NTLM/Kerberos relay vulnerabilities. It prevents the exploitation of the SMB service by ensuring message integrity.
• Microsoft's Patch Breaks Coercion: The patch for CVE-2023-28252 in the MRxSmb.sys driver prevents the SMB client from coercing authentication when a Marshall Credential Target Information structure is present, effectively stopping this attack and related Kerberos relay primitives.
• Logical Flaws Persist: This research highlights that even seemingly simple logical vulnerabilities can have profound security implications and that continuous, in-depth analysis of authentication protocols is essential.

About the Speaker(s)

Wilfried Bécard is a security researcher at Synacktiv, where he specializes in red team and pentest exercises. His work involves identifying and exploiting vulnerabilities in complex systems to help organizations improve their security posture. This particular research, which he presented at Hexacon, was a collaborative effort with his colleague Gum, who unfortunately could not attend the conference. Bécard's presentation demonstrated a deep understanding of Windows authentication mechanisms and an ability to uncover subtle logical flaws with significant security implications.