How to Prevent NTLM Relay Attacks on Your Windows Network

NTLM is a Windows authentication protocol from the early 1990s. Microsoft has been working to deprecate it for years, but in most SMB Active Directory environments it's still running and still being actively exploited.

Elad Shamir, Director of Research and Development at SpecterOps, wrote in a July 2025 analysis that NTLM relay attacks are "the easiest way for an attacker to compromise domain-joined hosts" and that prevalence has increased over the past few years, showing up in the majority of engagements his firm's consulting arm handles.

This guide explains exactly what NTLM relay is, which specific controls prevent it, and how to verify your mitigations are actually working rather than just configured on paper.

What Is an NTLM Relay Attack?

NTLM (NT LAN Manager) is a Windows authentication protocol that has been around since the 1990s. When a Windows machine authenticates to a network service, it uses a challenge-response exchange. The machine sends credentials, the server sends a challenge, and the machine responds with a hash of those credentials.

An NTLM relay attack intercepts that exchange and forwards it to a different service, one the attacker controls or wants to access. The target service sees a valid authentication attempt from the victim machine and grants access. No password cracking. No brute force. Just redirection.

The attacker needs two things to make this work.

  1. A way to coerce authentication. Tools like PetitPotam (which abuses MS-EFSRPC) and PrinterBug (which abuses the Windows print spooler, first documented by SpecterOps researcher Lee Christensen) trigger a Windows machine into initiating an NTLM authentication to the attacker's listener. They require nothing more than a standard domain user account.

  2. A target service that doesn't enforce signing or channel binding. Most services in default Windows configurations qualify.

Once both conditions are met, a single relay chain can produce a certificate for a domain controller machine account, a Kerberos ticket, LDAP write access, or direct code execution on a remote machine, depending on what service is targeted.

The threat surface grew further in 2025. CVE-2025-33073, disclosed in June 2025, is a high-severity NTLM reflection vulnerability in the Windows SMB client that allows an attacker to coerce a victim system into authenticating back to itself, achieving SYSTEM-level privilege escalation without touching a domain controller. Separately, CISA added CVE-2025-24054, a Windows NTLM hash disclosure vulnerability, to its Known Exploited Vulnerabilities catalog in March 2025 following confirmed active exploitation.

NTLM persists despite years of Microsoft pushing Kerberos because legacy applications are often hardcoded to use it, disabling it breaks things, and default configurations on Windows Server 2022 and below leave every protection turned off. According to SpecterOps' April 2025 research, most domain controllers in production today are vulnerable to NTLM relay via LDAP and SMB under default settings. Server 2025 DCs, which enforce these protections by default, remain rare in most SMB environments.

The Four Controls That Actually Prevent NTLM Relay

There is no single fix. NTLM relay requires a combination of controls, each of which closes a specific relay pathway. Implementing one without the others leaves gaps.

Control 1: Enable SMB Signing on All Domain Members

SMB signing requires that all SMB traffic be cryptographically signed, preventing an attacker from tampering with or replaying SMB authentication. Without it, relay to SMB shares, named pipes, and remote execution services remains viable.

How to check:

# PowerShell — check SMB signing on a remote host
Get-SmbServerConfiguration | Select RequireSecuritySignature

How to fix (Group Policy): - Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options - "Microsoft network server: Digitally sign communications (always)" → Enabled - "Microsoft network client: Digitally sign communications (always)" → Enabled

Windows Server 2025 and Windows 11 require SMB signing by default. Every older version does not. If you have Server 2022, 2019, or 2016 domain members, which covers most credit union environments, you need to set this explicitly.

Control 2: Enable LDAP Signing and Channel Binding on Domain Controllers

LDAP relay allows an attacker to authenticate to Active Directory's LDAP interface and perform operations as the relay victim: adding users to groups, modifying permissions, and creating computer accounts with delegation enabled. This is how most shadow credential attacks work.

How to fix (Group Policy, applied to Domain Controllers OU): - Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options - "Domain controller: LDAP server signing requirements" → Require signing - "Domain controller: LDAP server channel binding token requirements" → Always

Windows Server 2025 DCs enforce LDAP encryption by default. For mixed environments with older DCs, the Group Policy is still required.

Control 3: Harden Active Directory Certificate Services (ADCS)

This is the control most organizations skip entirely because they don't know ADCS is a relay target. The ADCS Web Enrollment HTTP endpoint, accessible at http://[CA-server]/certsrv/ by default, accepts NTLM authentication without any signing requirements because HTTP has no mechanism for session signing.

An attacker can relay any coerced authentication directly to the certificate authority and receive a certificate for the victim account. If the victim is a domain controller machine account, that certificate produces a Kerberos TGT for the DC, enabling DCSync within minutes.

How to check exposure: 1. Navigate to http://[your-CA-server]/certsrv/ from inside your network 2. If you see a login page or are automatically authenticated, ESC8 is likely exploitable

How to fix: - Enable HTTPS on the Web Enrollment service (required before EPA can be enabled) - Enable Extended Protection for Authentication (EPA) in IIS on the CA server - If Web Enrollment isn't actively used, disabling it entirely is the simplest mitigation

Vaadata's 2026 analysis of ESC8 confirmed that the four conditions enabling this attack are all default settings on Windows Server 2022 and below. If your CA runs on anything pre-2025, treat it as exposed until you verify otherwise.

Control 4: Disable NTLM Where It Isn't Needed

The most aggressive mitigation is disabling NTLM authentication entirely on high-value servers, particularly your AD CS servers. This prevents relay at the source rather than at each potential relay target.

How to fix (Group Policy): - Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options - "Network Security: Restrict NTLM: Incoming NTLM traffic" → Deny all domain accounts (on CA servers)

Warning: This requires careful testing. Some applications and services still depend on NTLM and will break if it's disabled without identifying and remediating those dependencies first. Inventory NTLM-dependent services before enabling this setting in production.

How to Verify You're Actually Protected

Configuring Group Policy is not the same as being protected. Policy misconfigurations, scope errors, and WMI filter failures are common. The only way to know your mitigations are working is to test them. See our full guide on Active Directory penetration testing for credit unions for what that testing should cover.

Quick validation steps:

  1. Check SMB signing on all domain members using a tool like NetExec or PowerShell's Get-SmbServerConfiguration across your domain, not just your DCs.

  2. Attempt LDAP signing validation by running ldap-checker or nmap --script ldap-rootdse against your DCs and verifying signing is enforced.

  3. Test ADCS HTTP enrollment manually by navigating to /certsrv/ and verifying EPA is enforced.

  4. Run a controlled coercion test using PetitPotam in a test environment to confirm your listener doesn't capture relayable authentication.

Scheduling a full internal penetration test that walks through the relay chain end-to-end gives you verified results rather than assumed ones.

Common Misconfigurations That Negate Mitigations

Even after enabling these controls, several common errors leave you re-exposed.

Scoping Group Policy to the wrong OU. SMB signing policy applied to Domain Controllers only does nothing for member servers and workstations. Relay victims usually originate there.

Leaving HTTP enrollment active after enabling HTTPS. If HTTPS is added but HTTP isn't explicitly disabled, attackers can still relay to the HTTP endpoint. Both must be configured.

Enforcing LDAP signing but not channel binding. Signing alone is insufficient for some relay variants. Both settings are required on domain controllers.

Not removing NTLM after testing. Some organizations disable NTLM for a test, confirm it works, then re-enable it for compatibility and never remove that dependency. NTLM should be on a deprecation timeline, not a toggle.

Frequently Asked Questions

Can NTLM relay attacks be detected without a SIEM? Some detection is possible with Windows Event Logs alone. Look for Event ID 4624 (logon) with unexpected source IPs, or Event ID 4648 (explicit credential logon) from unusual processes. Reliable detection requires correlation across multiple sources, which typically needs a SIEM or EDR with identity analytics.

Does Microsoft Defender for Identity detect NTLM relay? Yes. MDI alerts on suspicious NTLM authentication patterns and coercion attempts. Hardening the environment so relay isn't viable in the first place is the correct primary control. Detection supports that, but doesn't replace it.

How long does it take to implement these controls? SMB signing and LDAP channel binding can be enabled via Group Policy in an afternoon, with proper testing in a staging environment first. ADCS hardening, enabling EPA and switching to HTTPS, takes longer due to certificate and IIS configuration requirements. Plan for a full day with testing.

Sources

Stay sharp. Stay prepared. — ThreatForged AI

Want to know if your network is actually protected? ThreatForged AI runs the full NTLM relay chain against your environment under controlled conditions and shows you exactly what's exploitable.