SMB Signing Enforcement: How to Stop NTLM Relay Attacks Before They Pivot Through Your Network
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
NTLM relay is consistently one of the top three findings in Active Directory penetration tests because most organizations have SMB signing set to optional on workstations and member servers. The attack chain is straightforward: trigger an NTLM authentication from a privileged machine using a coercion technique (PetitPotam sends an MS-EFSRPC call; PrinterBug abuses the print spooler), relay the captured NTLM auth to a target server via ntlmrelayx, and gain code execution on the target. No password cracking required. The fix is enforcing SMB signing required on every machine -- a Group Policy change that takes five minutes to configure.
The NTLM Relay Attack Chain
Understanding what you are blocking helps scope the policy correctly:
-
Coercion: The attacker triggers a machine to authenticate to the attacker's machine. Common techniques:
- Responder (passive): Answers LLMNR/NBT-NS/mDNS queries on the local network, capturing authentication from machines that broadcast names that do not resolve via DNS
- PetitPotam (active): Sends an MS-EFSRPC
EfsRpcOpenFileRawcall to a target, forcing it to authenticate to an attacker-specified UNC path - PrinterBug (active): Abuses the MS-RPRN
RpcRemoteFindFirstPrinterChangeNotificationcall to coerce authentication from domain controllers - DFSCoerce (active): Uses MS-DFSNM to coerce authentication from DCs
-
Relay: The attacker forwards the captured NTLM authentication to a target server before it expires. Impacket's
ntlmrelayx.pyhandles this automatically. -
Impact: The relay target authenticates the relayed credential. If the coerced machine is a DC and the relay target is LDAP, the attacker can add themselves to Domain Admins. If the relay target is SMB on a file server, the attacker gets file system access as the coerced machine's computer account.
SMB signing required breaks step 2 -- the relay target refuses to accept an unsigned connection, and the relayed auth cannot complete.
Enforce SMB Signing via Group Policy
Configure on all machines (workstations and servers) via a GPO applied to the domain root:
Group Policy path:
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
Server-side settings (make the machine require signing as a target):
- Microsoft network server: Digitally sign communications (always): Enabled
- Microsoft network server: Digitally sign communications (if client agrees): Enabled
Client-side settings (make the machine require signing when connecting to servers):
- Microsoft network client: Digitally sign communications (always): Enabled
- Microsoft network client: Digitally sign communications (if server agrees): Enabled
For full NTLM relay prevention, the critical setting is server: always -- this makes the target refuse unsigned connections. Client-side signing prevents your machines from connecting to rogue SMB servers that do not sign (defends against man-in-the-middle attacks where your clients are the victim).
Verify the setting is active:
# Check current SMB server signing configuration
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature
# RequireSecuritySignature = True means signing required (the strong setting)
# Check the client
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
Potential breakage: Very old SMB clients (Windows XP, some NAS devices, older printers with SMB) may not support signing and will fail to connect when signing is required on the server. Audit your environment for these devices before enforcing.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Enforce LDAP Signing and Channel Binding on Domain Controllers
NTLM relay to LDAP (used to add accounts or modify AD objects) requires a separate control because LDAP is a different protocol from SMB.
LDAP signing (prevents relay of NTLM auth to LDAP without signing):
GPO path on Domain Controllers OU:
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
- Domain controller: LDAP server signing requirements: Require signing
LDAP channel binding / EPA (Extended Protection for Authentication): This is a registry setting on DCs (no GPO control as of writing):
# On each domain controller
Reg Add HKLM\System\CurrentControlSet\Services\NTDS\Parameters `
/v LdapEnforceChannelBinding /t REG_DWORD /d 2 /f
# 0 = never, 1 = when supported, 2 = always required
LDAP signing for clients:
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
- Network security: LDAP client signing requirements: Require signing
Disable LLMNR and NBT-NS to eliminate passive coercion:
# LLMNR:
Computer Configuration > Administrative Templates > Network > DNS Client
> Turn off multicast name resolution: Enabled
# NBT-NS -- no Group Policy, must be done via registry or DHCP option 001:
Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{GUID} /v NetbiosOptions /t REG_DWORD /d 2 /f
# Or disable via NIC properties > IPv4 > Advanced > WINS tab > Disable NetBIOS over TCP/IP
Detect NTLM Relay Attempts in Event Logs
Detect Responder LLMNR/NBT-NS poisoning (passive coercion): Look for unusual authentication sources -- machines authenticating to IPs that do not belong to known servers:
# Event ID 4624 (successful logon) Logon Type 3 from unexpected source IPs
# If you see a machine account authenticating to an unfamiliar IP,
# that IP may be a Responder instance that just relayed the auth somewhere
Detect PetitPotam/coercion attempts: Enable audit on the RPC calls used for coercion:
# Event ID 5145 (network share object access) for IPC$ access patterns
# Alert on: Source IP not in known servers/admin workstations accessing IPC$
# on DCs, especially from workstations
Monitor for SMB signing negotiation failures:
# Event ID 31017 in Microsoft-Windows-SMBServer/Security:
# 'SMB session authentication request failed due to signing requirements'
# This fires when a client attempts to connect without signing to a server requiring it
# In a clean environment: these indicate either misconfigured legacy devices or relay attempts
Detect relay to LDAP (AD object modifications):
# Event ID 4741 (computer account created), 4728 (member added to group)
# from unexpected sources or service accounts -- potential successful relay outcome
# Especially: computer account creation followed immediately by group membership change
# in the Domain Admins or Enterprise Admins group
The bottom line
SMB signing required on all machines, LDAP signing required on DCs with channel binding enabled, and LLMNR/NBT-NS disabled together close the NTLM relay attack surface. The deployment order: enforce LLMNR/NBT-NS disable first (low breakage), then LDAP signing on DCs, then SMB signing required on servers, then workstations. Test each layer in a pilot OU before fleet-wide enforcement. Monitor Event 31017 after enabling SMB signing required to identify legacy devices that cannot negotiate signing.
Frequently asked questions
Does enforcing SMB signing break any common enterprise applications?
Rarely in modern environments. The most common compatibility issues are: older NAS appliances and storage arrays that use SMB 1.0 (which has limited signing support), some older printers that connect to share paths via SMB, and very old application servers running Windows Server 2003 or earlier. Most modern enterprise applications use SMB 2.0 or 3.0, both of which support signing without issues. Audit your environment for SMB 1.0 clients before enforcing: Get-SmbConnection | Where-Object {$_.Dialect -eq '1.0'} on file servers to see who is connecting via SMBv1.
Does disabling NTLM entirely replace the need for SMB signing?
Partially. Disabling NTLM authentication (setting Network security: Restrict NTLM > Deny all) prevents NTLM-based relay attacks, but NTLMv2 is still used in many environments for non-domain devices and some application authentication paths. Disabling NTLM entirely is a separate hardening step that breaks more applications and requires more testing than enforcing signing. The pragmatic path for most organizations: enforce SMB signing and LDAP signing first (closes relay), then audit NTLM usage and progressively restrict it.
Does SMB signing have a performance impact?
The signing overhead on modern hardware is negligible -- typically under 1% CPU overhead for most workloads. SMB 3.0 signing uses AES-CMAC, which is hardware-accelerated on CPUs with AES-NI (all Intel Sandy Bridge 2011+ and AMD Bulldozer 2011+ processors). For high-throughput file server workloads (bulk file copies, backup jobs), SMB 3.1.1 pre-authentication integrity provides similar protection to signing for the session setup phase with lower per-packet overhead. The performance concern that historically delayed SMB signing deployments was valid in the Windows XP era; it is not a practical concern on modern infrastructure.
Can PetitPotam be blocked without SMB signing?
Partially. Microsoft released a patch that blocks the unauthenticated EfsRpcOpenFileRaw variant of PetitPotam (KB5005413). However, there are authenticated variants of EFS coercion and other coercion techniques (PrinterBug, DFSCoerce, ShadowCoerce) that the patch does not address. Disabling the EFS service is sometimes recommended but breaks BitLocker in some configurations. The most complete defense is: apply the patch, enforce SMB signing required (breaks the relay regardless of coercion technique), and disable the print spooler on DCs (removes PrinterBug).
What is the difference between SMB signing and SMB encryption?
SMB signing adds a cryptographic signature to each SMB packet to verify integrity and prevent tampering during transit. It does not encrypt the data payload -- an attacker who captures SMB traffic can still read file contents. SMB encryption (SMB 3.0+) encrypts the entire SMB session payload using AES-CCM or AES-GCM, providing both confidentiality and integrity. For lateral movement prevention via relay attacks, SMB signing is sufficient. For protecting sensitive file data from network eavesdropping (inside a data center, between sites), SMB encryption is needed. Both can be configured simultaneously. Configure RequireSecuritySignature for signing and EncryptData for encryption on the share or server level.
How do I detect NTLM relay attacks in my environment using event logs?
NTLM relay attacks are difficult to detect purely from victim-side logs because the relay itself is invisible to the target server -- the target server sees a legitimate NTLM authentication from the attacker's relay tool, not from the victim. Detection requires combining multiple signals: on the authentication source side, watch for NTLM authentication events (Event ID 4776 on the authenticating DC) from a machine that is simultaneously being authenticated to another machine (lateral movement pattern). Microsoft Defender for Identity has a specific detection for NTLM relay (Suspected NTLM relay attack on AD CS, Event code 2013), which correlates Certificate Services enrollment requests with suspicious authentication patterns. Network-layer detection: look for NTLM challenges being received by the attacker machine and replayed to the target within milliseconds (requires network packet capture at the relay point). The most reliable detection is prevention: require SMB signing and LDAP signing enforced, and monitor for failed signing negotiations (Event ID 3008/3011 in the Lanman log) which may indicate relay attempts against machines that do not enforce signing.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.