Examining Relay Attacks Through the Lens of CVE-2025-33073

Really? Another Relay Attack?  

Yes. Relay attacks are not a thing of the past. If anything, more relay attacks have been discovered and weaponized in recent years,  long after NTLM protocol was supposedly “dead.” Not to mention, Kerberos relay attacks were also introduced in recent years, so it’s no longer an NTLM only issue. 

Attackers keep exploiting old relay vectors and keep finding new ones (like the recent CVE-2025-33073) because it is an easy way to compromise entire domain environments, sometimes with a single successful relay attack. Regardless of the many patches and hardening mechanisms, organizations are still struggling to mitigate relay attacks in their environments. 

I would recommend reading Elad Shamir’s excellent writeup which surveys in-depth NTLM and Kerberos relay attacks in more detail.

CVE-2025-33073 Reflection Attack 

CVE-2025-33073 is the most recent relay attack, which enables an attacker to relay authentication back to the victim’s machine – making it a reflection attack. This attack is made possible because the attacker is “fooling” a target’s SMB client service into thinking it is performing local authentication. This is why it can only be used when the source and destination of the authentication are the same host. Once successful, the attacker gains local SYSTEM privileges on the compromised host, enabling them to – for example – dump SAM hashes on the compromised host (which can be used to impersonate privileged accounts on the host or in the entire domain).  

For a successful attack, one needs: 

1. A target with SMB signing disabled  
2. To create a specially crafted DNS record (via LDAP or DDNS) which contains the attacker’s IP and a name of localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA  
3. Trigger SMB authentication; this can be achieved via PetitPotam, or other coercion techniques

More technical details are available in this post by synactiv. 

CVE-2025-33073 Mitigation in Layers 

Over the years, relay attacks have usually featured a couple of common characteristics:  

• LDAP modification is often either a precursor or a target of relay attacks. 
• Coercion of the victim is required in order to control the target of the NTLM authentication stream.  

To see how those come into play, we set up a simple lab with both LDAPFirewall and RPCFirewall installed on audit mode. The attack includes 2 hosts: a domain controller with SMB signing disabled and the attacker-controlled host (including a compromised domain account).

At first, the attacker needs to create a special DNS record. This can be done over LDAP using dnstool.py. 

We can verify that this record was created and directs the traffic back to the attacker’s host:

From the defender’s perspective, the LDAP Firewall captures an add operation which created the DNS record: 

This operation can be also blocked by the LDAP Firewall, by simply blocking add operations (more granular blocks can be created to prevent operations against specific objects like Dns-Node, etc.).  

Once the DNS record is created, the attacker uses PetitPotam for the coercion, making the target initiate an SMB connection, which requires authentication against the attacker-controlled host: 

The RPC operation is captured by the RPC Firewall, showing the RPC interface MS-EFSR called with operation 0 (which is EfsRpcOpenFileRaw). We can also see the user who performed the operation and the host’s IP. Default configurations such as RpcFw.conf.FirewallOnly block this interface by default, and many other RPC coercion interfaces.  

Finally, if the previous 2 steps were not blocked, the attacker can perform the reflection attack and dump the credentials of the victim’s host:  

Conclusion 

Relay and reflection attacks are not going away. If anything, we should expect more of them in the foreseeable future. Getting rid of NTLM is not always possible; even if it were, this attack also works with Kerberos. As a defender, to protect against current and future relay attacks, you should:  

• Enable signing and sealing on all authentication protocols (NTLM / Kerberos / LDAP / RPC / HTTP …).  
• Remove DNS privileges from all users in your organization.  
• Add LDAP and RPC security layers to protect against common milestones of relay attacks.