SMB signing on domain controllers has become standard practice across most Active Directory environments. But this hardening may have created a false sense of security. CVE-2025-33073 changes the calculus by removing the prerequisite of admin access, enabling NTLM relay attack Active Directory exploitation through unconstrained delegation.

Domain controllers enforce SMB signing by default. Workstations and member servers do not. However, this gap has existed for over a decade, and organizations have largely accepted it.

The Gap That Remained

Relay attacks against member servers were possible, but exploiting them required specific conditions: the relayed account needed privileges on the target, and machine account authentication, the easiest to coerce, generally provided no direct path to local admin.

CVE-2025-33073 changes that calculus by removing the prerequisite of admin access.

Disclosed in June 2025 by researchers at RedTeam Pentesting^[1] and Synacktiv^[2], this vulnerability resurrects NTLM reflection, an attack class that was widely considered mitigated. By abusing how Windows handles marshaled target information in DNS records, an attacker can trick the SMB client into triggering local NTLM authentication. The result: authenticated remote code execution as SYSTEM on any domain-joined machine without SMB signing enforced. The only prerequisites are network access and credentials for any domain user.

The worst-case scenario is quite straightforward: an unpatched domain controller that does not enforce SMB signing. Researchers have extensively documented this path; As a result, CVE-2025-33073 yields SYSTEM on the DC, and from there it is a short walk to DCSync and full domain compromise. But even organizations that have patched their domain controllers or confirmed SMB signing enforcement are not necessarily safe. The vulnerability works against any domain-joined system without SMB signing, and some of those systems offer their own paths to domain compromise.

Microsoft’s Enterprise Access Model^[3], an evolution of the AD Administrative Tier Model first published nearly a decade ago, offers clear guidance on protecting privileged assets. Organizations classify systems into tiers; Tier 0 for identity infrastructure, Tier 1 for enterprise servers, Tier 2 for workstations, and apply controls accordingly. Domain controllers sit at Tier 0. They receive the most restrictive policies, the most monitoring, and the most attention during security reviews.

This asset-centric approach makes intuitive sense. Identify the crown jewels, build walls around them, and monitor the gates. But it contains a subtle flaw: it focuses on what Tier 0 is rather than how attackers reach it.

Interestingly, the Enterprise Access Model acknowledges this limitation. The guidance provided also includes a principle that often gets overlooked in practice: “Any system or user account that can manage a higher tier is also a member of that tier, whether originally intended or not.”^[4] The documentation uses virtualization as the canonical example: a hypervisor admin who can snapshot a domain controller can extract credential material, making that hypervisor effectively Tier 0 regardless of how the organization has classified it.

The same logic applies to multiple such classes of systems. These are the one-hop systems: compromise them, and you are one step away from the keys to the kingdom.

Understanding One-Hop Systems

Among the most common, and potentially the most dangerous, one-hop configurations in Active Directory is unconstrained delegation. Systems configured for unconstrained delegation cache a copy of the Ticket Granting Ticket for any principal that authenticates to them, a design that dates back to Windows 2000. An attacker who exploits CVE-2025-33073 and gains SYSTEM privileges on such a host can coerce a domain controller to authenticate, capture the DC’s machine account TGT, and use it to perform a DCSync operation.

The critical observation here is that none of this requires compromising the domain controller itself. SMB signing on the DC prevents relay attacks against it but does nothing to stop the DC from authenticating to other systems when coerced. The TGT delegation is intended behavior and the security flaw is architectural. CVE-2025-33073 throws this known weakness into sharper relief. Organizations correctly hardened their domain controllers against relay attacks, but left unpatched the systems that could coerce those DCs and capture their credentials.

To demonstrate the full path from low-privilege domain user to domain compromise, we used Orange Cyberdefense’s GOAD lab environment^[5]. MEEREEN is the domain controller for ESSOS.LOCAL, BRAAVOS is a member server we configured for unconstrained delegation, and we started with credentials for a standard domain user.

Demonstrating the Attack

The first step is finding systems with unconstrained delegation that don’t enforce SMB signing. Previously, confirming whether a target was actually patched against a specific CVE required administrative access to the machine. It involved checking installed KBs, reading registry keys, or running vulnerability scanners with elevated credentials. For CVE-2025-33073, Depth Security’s RelayKing^[6][7] solves this by querying the Update Build Revision (UBR) from DCERPC, which is accessible with low-privilege domain credentials. This lets you determine whether a host’s patch level predates the June 2025 fix without needing admin on the target. Once a list of these hosts is compiled, we can use findDelegation to find systems configured for unconstrained delegation with an existing SPN.

Specifically, the vulnerability works by adding a DNS record through LDAP that contains marshaled target information in the hostname. Any authenticated domain user can do this because it’s a default permission in AD-integrated DNS. The crafted record name follows the format 1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA, which causes the target’s SMB client to interpret the resulting connection as local authentication.

Now positioned as SYSTEM on an unconstrained delegation host, we use the PrinterBug^[8] to force MEEREEN to authenticate to BRAAVOS. When the DC authenticates to a system trusted for unconstrained delegation, its TGT is included in the authentication and cached in LSASS.

This is the critical point: SMB signing on the domain controller does not help here. SMB signing prevents relay attacks to the DC, it does nothing to prevent the DC from authenticating outward when coerced. The TGT delegation is the protocol working as designed.

Rubeus, running with the SYSTEM access we obtained through CVE-2025-33073, captures the incoming TGT in real time. The ticket for [email protected] arrives with forwarded and forwardable flags; a delegated TGT for the domain controller’s machine account.

The secretsdump.py output confirms full domain compromise: krbtgt NTLM hash, AES-256, AES-128, and DES keys extracted. From here, crafting Golden Tickets for any account in the domain is trivial.

If a single member server with this configuration provides a one-hop path to domain compromise, the best course of action is to remove unconstrained delegation.

In practice, it is rarely that simple.

Unconstrained delegation was the only multi-hop Kerberos authentication mechanism available in Windows 2000 and Server 2003. A significant number of enterprise applications were architected around it, and many are still running. Line-of-business applications that predate newer delegation extensions often cannot be reconfigured without substantial rework. Vendor deployment guides that specify unconstrained delegation as a requirement (because it works universally and often reduces their support burden) make remediation a business negotiation, not just a technical change. These are often the applications no one wants to touch, attached to the systems no one wants to reboot.

The risks of unconstrained delegation have been understood since at least 2015, when Sean Metcalf presented on the topic at Black Hat^[9]]. What CVE-2025-33073 changes is the barrier to entry. Previously, exploiting an unconstrained delegation host required existing local administrator access or waiting for a privileged user to authenticate naturally. Now, any domain user with network access can obtain SYSTEM on an unpatched member server without SMB signing, and from there, the path to domain compromise is trivial.

For organizations that cannot remove unconstrained delegation today, the priority is reducing the blast radius. Patch CVE-2025-33073 immediately, and prioritize systems with unconstrained delegation. Enable SMB signing on those systems and block the relay even without the patch. Mark privileged user accounts as “Account is sensitive and cannot be delegated” to prevent their TGTs from being cached on delegation hosts, and add them to the Protected Users group for additional protections.

Beyond these mitigations, there are other defense-in-depth measures that can disrupt the attack chain at multiple points. Enabling LSASS to run as a Protected Process Light (RunAsPPL) on unconstrained delegation systems adds a meaningful barrier; it does not prevent the DC’s TGT from being cached, but it blocks the credential extraction step that makes the cached ticket usable to an attacker. On the detection side, CVE-2025-33073 relies on creating DNS records through LDAP with a distinctive marshaled target information pattern in the hostname. Monitoring for DNS record creation by non-administrative accounts, and for SMB authentication where a machine authenticates to itself, gives defenders visibility into the early stages of this attack before any tickets are captured.

The lesson from CVE-2025-33073^[10] is twofold: hardening domain controllers is important and SMB signing on DCs remains essential, but hardening the crown jewels without hardening the paths to them leaves the door open one hop away. The systems that can reach the crown jewels deserve the same scrutiny as the crown jewels themselves.