How to Find and Fix SMB Signing Disabled Vulnerability

SMB signing disabled is one of the most commonly flagged findings in internal penetration tests and vulnerability scans, and for good reason. When SMB signing is not enforced, an attacker positioned on the network can relay authentication requests between a victim and a target server, often leading to full domain compromise through NTLM relay attacks. This guide walks through how to identify systems with SMB signing disabled, how attackers actually exploit it, and how to permanently remediate it across a Windows environment. If you want a deeper look at how Sagefox Cybersecurity approaches this during internal assessments, their team treats this exact finding as a priority item, not a footnote.

What Is SMB Signing and Why Does It Matter

SMB (Server Message Block) signing adds a cryptographic signature to each SMB packet, verifying that the packet came from the claimed sender and was not tampered with in transit. Without signing enforced, an attacker on the same network segment can capture NTLM authentication attempts and relay them to another machine, impersonating the original user without ever cracking a password.

This is not a theoretical risk. NTLM relay attacks that abuse unsigned SMB traffic remain one of the fastest paths from initial network access to domain admin in real-world engagements.

Where This Vulnerability Typically Shows Up

Legacy Windows servers that predate default signing enforcement
Print servers and file servers configured with minimal hardening
Workstations where Group Policy has not been applied consistently
Environments still supporting SMBv1 or mixed SMB versions

How to Find SMB Signing Disabled on Your Network

Before fixing anything, you need an accurate inventory of which hosts actually have signing disabled or merely "enabled but not required," which is functionally the same risk. Teams that run this kind of sweep regularly as part of an ongoing program, like the internal network assessments offered by Sagefox Cybersecurity, tend to catch drift long before an external scanner does.

Using Nmap to Scan for SMB Signing Status

Nmap's smb2-security-mode script is the fastest way to sweep a subnet.

nmap --script smb2-security-mode -p 445 192.168.1.0/24

Look for output that reads:

Message signing enabled but not required

Any host reporting this, or no signing requirement at all, is a candidate for remediation. For a more targeted scan against a single host with verbose output:

nmap -p 445 --script smb2-security-mode,smb-security-mode -Pn -v 10.10.10.25

Using CrackMapExec (or NetExec) for Enterprise-Scale Enumeration

For larger environments, CrackMapExec (now maintained as NetExec) is the go-to tool for identifying signing status across hundreds of hosts in a single pass.

netexec smb 192.168.1.0/24 --gen-relay-list relay_targets.txt

This command not only enumerates SMB signing status but automatically generates a list of relay-viable targets, which is the same list an attacker would build first. Reviewing this output is one of the fastest ways to see your exposure the way an adversary would.

netexec smb targets.txt -u '' -p '' --shares

Using PowerShell for Native Domain-Wide Checks

If you prefer to stay within native tooling, PowerShell can query the registry key that governs signing enforcement on each host remotely.

Invoke-Command -ComputerName (Get-Content .\hosts.txt) -ScriptBlock { Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters" -Name RequireSecuritySignature, EnableSecuritySignature }

A RequireSecuritySignature value of 0 confirms signing is not enforced on that host.

Confirming Exposure with Responder in Analyze Mode

Running Responder in analyze-only mode (no poisoning) on a test segment can confirm whether unsigned SMB traffic and NTLM authentication broadcasts are actually present on the wire, giving you real evidence for your remediation report rather than relying on scan output alone.

responder -I eth0 -A

How Attackers Exploit SMB Signing Disabled

Understanding the attack path helps justify remediation priority to stakeholders who may see this as a "low severity" scanner finding. This is exactly the kind of finding that reads as minor on paper but plays out very differently in a live attack simulation, which is why firms like Sagefox Cybersecurity walk clients through the full chain rather than just the scan result.

The NTLM Relay Attack Chain

Attacker sets up a relay listener targeting hosts identified as signing-not-required.
A victim machine or service account authenticates over SMB to a poisoned name resolution response (via LLMNR/NBT-NS poisoning).
The attacker relays that authentication to a target server instead of cracking the hash.
If the relayed account has local admin rights on the target, the attacker gains code execution or dumps credentials directly.

A typical relay setup using ntlmrelayx (part of the Impacket toolkit) looks like this:

ntlmrelayx.py -tf relay_targets.txt -smb2support --no-http-server -c "powershell -enc <base64_payload>"

Paired with LLMNR/NBT-NS poisoning:

responder -I eth0 -wrf

Why This Escalates Quickly

If any relayed account has administrative rights on a domain controller, or if the target is vulnerable to relaying into LDAP or ADCS enrollment endpoints, this single misconfiguration can lead directly to domain admin. Relay-to-LDAP and relay-to-ADCS attacks have made SMB signing enforcement even more critical since they bypass the need for local admin entirely.

How to Fix SMB Signing Disabled

Remediation involves enforcing signing at both the server and client sides through Group Policy, followed by validation.

Enforcing SMB Signing via Group Policy

Navigate to the following policy paths in Group Policy Management:

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

Enable both of the following settings:

Microsoft network client: Digitally sign communications (always)
Microsoft network server: Digitally sign communications (always)

For domain controllers specifically, also enforce:

Microsoft network server: Digitally sign communications (if client agrees)

Enforcing SMB Signing via Registry (for standalone or non-domain hosts)

reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters" /v RequireSecuritySignature /t REG_DWORD /d 1 /f reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanManWorkstation\Parameters" /v RequireSecuritySignature /t REG_DWORD /d 1 /f

Enforcing SMB Signing via PowerShell at Scale

For environments managing signing outside of Group Policy, PowerShell's SMB cmdlets allow direct enforcement:

Set-SmbServerConfiguration -RequireSecuritySignature $true -Force Set-SmbClientConfiguration -RequireSecuritySignature $true -Force

To push this across multiple servers remotely:

Invoke-Command -ComputerName (Get-Content .\servers.txt) -ScriptBlock { Set-SmbServerConfiguration -RequireSecuritySignature $true -Force }

Disabling SMBv1 While You Are In There

If SMBv1 is still enabled anywhere in the environment, disable it during the same maintenance window since it has no signing support worth relying on and carries its own well-documented risks.

Set-SmbServerConfiguration -EnableSMB1Protocol $false Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Validating the Fix

After deploying enforcement, re-run the same discovery scans to confirm remediation actually took effect.

netexec smb 192.168.1.0/24 --gen-relay-list post_fix_check.txt

A properly remediated environment should return an empty relay target list. Also re-run the Nmap script:

nmap --script smb2-security-mode -p 445 192.168.1.0/24

Look for confirmation that signing is now listed as required, not just enabled. Organizations running regular internal assessments through Sagefox Cybersecurity typically bake this validation step into their quarterly hardening review, since Group Policy drift and newly imaged machines can silently reintroduce the misconfiguration.

Common Mistakes That Leave Environments Still Exposed

Only Fixing Servers, Not Workstations

Attackers relay from workstation to workstation just as often as workstation to server. Both LanManServer and LanManWorkstation registry paths need enforcement, and both client-side and server-side GPO settings need to be applied.

Forgetting Newly Provisioned or Imaged Machines

If signing enforcement is not baked into the base image or provisioning script, every new machine reintroduces the gap. Bake the registry keys or GPO link into your imaging pipeline directly.

Ignoring LLMNR and NBT-NS Alongside SMB Signing

SMB signing enforcement removes the relay path, but LLMNR and NBT-NS poisoning can still be used for credential capture elsewhere. Disabling LLMNR via Group Policy and setting NetBIOS to disabled on network adapters closes the poisoning vector that typically feeds the relay attack in the first place.

When to Bring in External Validation

Internal teams often assume a GPO push resolves the issue completely, but inheritance conflicts, OU-level overrides, and legacy systems excluded from policy scope frequently leave gaps. A focused internal penetration test that specifically attempts SMB relay against your production environment, rather than just scanning for the setting, is the only way to confirm the fix holds under real attack conditions. Sagefox Cybersecurity performs this type of targeted validation as part of internal network penetration testing engagements, confirming both the configuration and the actual exploitability before signing off on remediation.

Key Takeaways

SMB signing disabled is a deceptively simple finding with an outsized impact on domain security. The fix itself is straightforward: enforce signing through Group Policy or registry keys on both servers and workstations, disable SMBv1, and address LLMNR and NBT-NS poisoning at the same time. The harder part is verification: confirming the setting actually took effect across every host, including new and legacy systems that often get missed.

If your organization needs help identifying which hosts are still exposed, or wants a real-world relay attack simulation to validate remediation, visit Sagefox Cybersecurity to see how their team can help you close the gap before an attacker finds it first.