TL;DR: A low-privileged domain user can still be turned into SYSTEM on vulnerable domain controllers by chaining coerced authentication with NTLM relay, bypassing channel binding and LDAP signing safeguards, according to CrowdStrike. The practical lesson is that hardening alone is not enough when identity flows remain relayable and session trust is weak.
At a glance
What this is: This is a technical analysis of CVE-2025-54918, showing how coerced authentication plus NTLM relay can elevate a low-privileged user to SYSTEM on a domain controller.
Why it matters: It matters because Active Directory protections that look sound on paper can still fail when machine and service identities are allowed to authenticate in relayable ways.
By the numbers:
- Attackers attempt access within an average of 17 minutes when AWS credentials are exposed publicly, and as quickly as 9 minutes in some cases.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
👉 Read CrowdStrike's analysis of CVE-2025-54918 and NTLM relay abuse
Context
NTLM relay remains a governance problem, not just a protocol problem. In Active Directory environments, the issue is that authentication can be intercepted and reused when signing, channel binding, and trust boundaries are not enforced consistently. For IAM and NHI teams, that means machine and service identities can become escalation paths rather than controlled assets.
CVE-2025-54918 shows how attacker-controlled coercion can force a domain controller to authenticate outbound, then relay that authentication back to the target with altered session flags. That creates an identity control failure at the transport layer, where the environment assumes the authentication flow is trustworthy simply because it originated from a domain controller. For teams mapping this to programme design, the NHI Lifecycle Management Guide is the right place to anchor review of account creation, exposure, and offboarding discipline.
The attack pattern described in the article is not unusual in principle, even if the specific vulnerability is new. Coercion and relay have long been part of Windows identity abuse, which is why environment hardening must be paired with continuous identity monitoring and protocol-level verification.
Key questions
Q: How should security teams reduce NTLM relay risk in Active Directory?
A: Teams should make relay paths unusable rather than merely harder to exploit. That means enforcing LDAP signing and channel binding, limiting where NTLM is accepted, and removing services that can be coerced into authenticating on behalf of an attacker. The goal is to prevent a captured session from being trusted anywhere else.
Q: Why do machine and service accounts increase identity risk?
A: Machine and service accounts often hold broad trust and can authenticate in ways that are not tightly supervised by human-centric IAM processes. If those identities can be coerced or relayed, they become escalation paths. Teams need lifecycle control, scope restriction, and telemetry for these accounts, not just password rotation.
Q: What is the difference between hardening and identity governance for NHIs?
A: Hardening reduces exposure in the environment, while identity governance controls who or what can authenticate, where, and under what conditions. Hardening might block one attack path, but governance reduces the number of identities and trust relationships that can be abused in the first place. Both are needed, but they solve different problems.
Q: When should organisations prioritise relay and coercion controls?
A: Organisations should prioritise them whenever privileged Windows infrastructure is present, because a single relayable trust path can expose the domain controller itself. If attackers can force outbound authentication from a trusted system, the blast radius is much larger than a normal credential theft event. That is a high-priority identity risk.
Technical breakdown
How NTLM relay turns trusted authentication into privilege abuse
NTLM relay works by capturing a valid authentication exchange and forwarding it to another service before the session can be bound to the original target. In Active Directory, this becomes dangerous when the target accepts the relayed session as legitimate and performs actions under the authenticated principal's privileges. Protections such as LDAP signing and channel binding are meant to break this chain, but they only work when enforced consistently across the estate. CVE-2025-54918 matters because it combines relay with coercion, so the attacker does not need to guess credentials or break cryptography. The weak point is the trust assumption built into the authentication path.
Practical implication: Audit where NTLM is still accepted and where signing or channel binding is optional rather than mandatory.
Why coerced authentication is an identity control failure
Coerced authentication forces a system, often a privileged one, to initiate an outbound login that the attacker can intercept. In the article's flow, the print spooler path is used to trigger the domain controller, which then authenticates with machine-account context that the attacker can manipulate. The technical issue is not just that a system authenticates, but that it can be induced to do so on the attacker's terms. That makes coercion a governance issue for NHI because service accounts and machine accounts are still identities with authority, yet many teams treat them as infrastructure side effects rather than governed principals.
Practical implication: Treat any service capable of initiating outbound authentication as part of the identity attack surface.
Why signing and sealing controls fail when session flags can be altered
The article shows that the attacker can manipulate NTLM negotiation flags, removing integrity and confidentiality requirements while preserving the semantics needed for the target to accept the session. That is a reminder that protocol controls are only as strong as the enforcement points around them. If an attacker can alter the negotiated session properties before relay, the receiving service may process a session that no longer has the protections defenders assumed were present. The architectural lesson is that identity assurance at the packet level must be paired with server-side enforcement and monitoring for anomalous authentication patterns.
Practical implication: Verify that enforcement is server-side, not dependent on the client or on assumed network trust.
Threat narrative
Attacker objective: The attacker wants to convert a low-privileged foothold into privileged control over the domain controller and the wider Active Directory estate.
- Entry occurs through a low-privileged domain user combined with access to a system that can reach the target domain controller.
- Escalation follows when the attacker coerces the domain controller into authenticating outbound, intercepts the exchange, and relays it after modifying security flags.
- Impact is domain controller compromise, with the attacker reaching SYSTEM-level authority in the Active Directory environment.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
NTLM relay is an NHI governance issue, not a niche Windows bug. The article shows that a single relayed authentication can turn a low-privileged account into SYSTEM when the environment still trusts the protocol flow. That is exactly the kind of boundary failure NHI governance exists to prevent. Practitioners should treat machine and service accounts as first-class identities with their own abuse paths.
Ephemeral hardening is not enough when protocol trust remains static. The core problem is not whether the environment has some hardening in place, but whether those controls are universally enforced across every authentication path. If signing, channel binding, or relay protections are inconsistent, the attacker will look for the weakest service. Practitioners should assume that partial enforcement creates exploitable identity asymmetry.
Identity blast radius, not just credential strength, should drive prioritisation. A low-privileged principal becomes a critical incident when it can be relayed into domain controller authority. That means the question is not only who can log in, but where that login can be redirected and what systems will trust it. Practitioners should reduce blast radius by eliminating relayable paths and tightening privileged service exposure.
Print-related and other coerced-authentication surfaces belong in identity risk registers. The article's attack path relies on a system being induced to call out under attacker control, which is a recurring pattern across Windows environments. Teams that only track credentials and not outbound authentication triggers are missing part of the abuse surface. Practitioners should inventory coercion-capable services alongside privileged accounts.
Protocol abuse will keep outpacing point fixes until identity telemetry closes the loop. The more defenders rely on single controls such as LDAP signing, the more attackers will pivot to manipulated session properties, alternate coercion paths, or unmanaged service identities. This is why NHI governance needs detection as well as prevention. Practitioners should pair hardening with continuous identity-level monitoring.
From our research:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
- Pair that with the NHI Lifecycle Management Guide when you need a practical path from discovery to rotation and offboarding.
What this signals
Identity blast radius is the right lens for prioritisation. With 44% of developers following security best practices for secrets management, the control gap starts upstream of the exploit and persists into operations. For programmes running Windows-heavy infrastructure, that means coercion and relay paths should be treated as systemic exposure, not edge-case tuning.
The practical signal is that teams should map where privileged systems can be induced to authenticate outward and then remove those trust edges before attackers test them. That work belongs alongside broader identity hygiene, lifecycle review, and secrets discipline, not as a separate hardening project.
Session trust debt: any environment that still depends on negotiated protocol trust is carrying hidden exposure. As identity systems become more automated, defenders need policy that makes unsafe sessions impossible rather than merely detectable. Align that work with NIST Cybersecurity Framework 2.0 and identity-specific guidance such as the Top 10 NHI Issues.
For practitioners
- Enforce LDAP signing and channel binding everywhere Remove optional trust by making LDAP signing, LDAPS channel binding, and related authentication protections mandatory on every domain controller and dependent service. Test for exceptions by service tier and eliminate fallback paths that still accept relayable sessions.
- Inventory coercion-capable services and RPC surfaces Identify services that can trigger outbound authentication, including print-related interfaces and similar RPC paths, then classify them as identity attack surface. Prioritise the endpoints that can force privileged systems to authenticate outside their intended trust boundary.
- Monitor for anomalous NTLM negotiation patterns Look for authentication sessions where expected signing or sealing flags are missing, altered, or inconsistent with the target service. Correlate those events with outbound connection attempts from privileged hosts to detect relay attempts early.
- Reduce reliance on relayable machine and service identities Review where domain controllers, service accounts, and other non-human identities can authenticate without tight scope controls. Constrain those identities to the minimum servers, protocols, and destinations required for operations.
- Use identity telemetry to shrink blast radius Tie privileged account monitoring to protocol-level events so you can see when a low-privilege login becomes a high-value control path. Use that visibility to drive remediation priority, not just to confirm that a vulnerability exists.
Key takeaways
- NTLM relay becomes a critical identity risk when a privileged system can be coerced into trusting a relayed session.
- Partial enforcement of signing, channel binding, and related safeguards leaves a larger attack surface than most teams assume.
- Security teams should focus on eliminating relayable trust paths, not just patching the vulnerability that exposes them.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers credential and session abuse in NHI contexts, which matches relay-based escalation. |
| NIST CSF 2.0 | PR.AC-4 | Access control enforcement applies directly to signing, channel binding, and privilege scope. |
| NIST Zero Trust (SP 800-207) | Zero trust requires continuous verification, which relayable sessions undermine. |
Apply zero-trust principles to internal authentication paths and deny implicit trust in privileged sessions.
Key terms
- NTLM Relay: NTLM relay is an attack technique where an authenticated challenge-response session is captured and forwarded to another service that accepts it as legitimate. The attacker does not need the password itself, only a reusable authentication exchange that the target will trust.
- Coerced Authentication: Coerced authentication is the act of forcing a system to initiate an outbound login to an attacker-controlled endpoint. In identity attacks, this turns a trusted host into the source of a valid authentication event that can be intercepted, relayed, or manipulated.
- Channel Binding: Channel binding ties an authentication session to the underlying secure transport so that the session cannot be replayed on a different channel. It is a control against relay attacks, but it only helps when the receiving service enforces it consistently.
- Identity Blast Radius: Identity blast radius is the scope of damage an attacker can reach after compromising or abusing a single identity. In NHI environments, it measures how far one relayed account, token, or service credential can move across systems before controls stop it.
Deepen your knowledge
NTLM relay, coerced authentication, and privilege escalation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is building identity controls for Windows-heavy environments, it is worth exploring.
This post draws on content published by CrowdStrike covering CVE-2025-54918 and NTLM relay abuse: From Domain User to SYSTEM: Analyzing the NTLM LDAP Authentication Bypass Vulnerability. Read the original.
Published by the NHIMG editorial team on 2026-05-22.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org