How to Find and Fix SMB Signing Disabled Vulnerability

SMB Signing Disabled is one of the most persistently exploited misconfigurations in Windows environments. It sits quietly in your network, invisible to most monitoring tools, yet it gives attackers the ability to intercept, relay, and manipulate authentication traffic without ever cracking a single password. If you run an Active Directory environment and SMB signing is not enforced, you are vulnerable to NTLM relay attacks that can lead to full domain compromise.

This guide walks you through exactly what SMB signing is, why it matters, how to detect it using industry-standard tools, and how to fix it across your environment. Every command is production-ready and tested in real penetration testing engagements.

If you want a team of expert pentesters to assess your SMB exposure and broader attack surface, Redfox Cybersecurity's penetration testing services are built for exactly this kind of deep infrastructure review.

What Is SMB Signing and Why Does It Matter

Server Message Block (SMB) is the protocol Windows uses for file sharing, printer access, and inter-process communication across a network. SMB signing is a security mechanism that digitally signs each SMB packet to verify that it has not been tampered with in transit and that it originates from a legitimate source.

When SMB signing is disabled or set to "not required," an attacker positioned between a client and server (a classic man-in-the-middle position) can relay authentication requests to other services, impersonate authenticated users, and in many cases, execute code with domain administrator privileges.

This is not theoretical. Tools like Responder, ntlmrelayx, and Impacket have made NTLM relay attacks trivially easy to execute, and SMB signing disabled is one of the primary prerequisites for these attack chains.

How SMB Signing Gets Misconfigured

By default, Windows domain controllers require SMB signing. However, workstations and member servers do not. This creates an asymmetry where a significant portion of your environment is exposed. Common reasons this vulnerability persists include:

Legacy application compatibility requirements that break when signing is enforced, Group Policy Objects that were never updated when the environment grew, and third-party devices such as NAS appliances, printers, and backup servers that do not support signed SMB connections.

Understanding where misconfigurations originate helps you fix them without breaking dependent systems. If you want a risk-prioritized view of where your environment is exposed, Redfox Cybersecurity offers infrastructure penetration testing that maps exactly this kind of attack path.

How to Detect SMB Signing Disabled

Using Nmap

Nmap with its SMB scripts is the fastest way to identify unsigned SMB hosts across a subnet.

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


Look for output like this:

| smb2-security-mode:
|   3:1:1:
|_    Message signing enabled but not required


The phrase "enabled but not required" means the vulnerability is present. An attacker can simply choose not to sign, and the server will still communicate with them.

To scan and output results to a file for review:

nmap -p 445 --script smb2-security-mode 192.168.1.0/24 -oN smb_signing_results.txt


Using CrackMapExec

CrackMapExec (CME) is a post-exploitation framework widely used during internal penetration tests. It handles large network ranges quickly and flags SMB signing status clearly.

crackmapexec smb 192.168.1.0/24 --gen-relay-list unsigned_hosts.txt


This command scans the subnet and writes every host with SMB signing disabled directly to unsigned_hosts.txt, which you can feed directly into ntlmrelayx. The output on screen will look like:

SMB   192.168.1.15   445   WORKSTATION01   [*] Windows 10 x64 (name:WORKSTATION01) (signing:False) (SMBv1:False)


The signing:False flag is your indicator.

Using Nessus or OpenVAS

If you run a vulnerability scanner, look for the following plugin IDs:

• Nessus Plugin ID 57608: "SMB Signing Disabled"
• Nessus Plugin ID 96982: "SMB Signing Not Required"

These will appear as medium-severity findings by default, but their exploitability in an NTLM relay chain elevates their real-world risk to critical.

Using PowerShell for Internal Auditing

If you have access to the domain and want to audit from inside without external tools, use this PowerShell one-liner across a range of hosts:

$hosts = @("192.168.1.10","192.168.1.11","192.168.1.12")
foreach ($h in $hosts) {
   $result = Invoke-Command -ComputerName $h -ScriptBlock {
       Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature
   }
   Write-Output "$h - RequireSigning: $($result.RequireSecuritySignature) | EnableSigning: $($result.EnableSecuritySignature)"
}


This returns a clean summary of signing state per host, which you can redirect to a CSV for reporting.

... | Export-Csv -Path smb_audit.csv -NoTypeInformation


How Attackers Exploit SMB Signing Disabled

Understanding the exploit chain helps you communicate risk to stakeholders and justify remediation effort. Here is a common attack scenario using Responder and Impacket's ntlmrelayx.

Step 1: Poison LLMNR/NBT-NS Responses

The attacker runs Responder on their machine to capture authentication attempts from misconfigured clients that broadcast before querying DNS.

sudo responder -I eth0 -rdwv


Step 2: Relay the Captured Hash

Rather than cracking the hash offline, the attacker relays it in real time to a target host with SMB signing disabled.

python3 ntlmrelayx.py -tf unsigned_hosts.txt -smb2support


If the captured credential belongs to a local admin on any of the target machines, ntlmrelayx will dump SAM hashes, execute commands, or establish a SOCKS proxy. If it belongs to a domain admin, the attacker has full domain compromise.

python3 ntlmrelayx.py -tf unsigned_hosts.txt -smb2support -c "whoami > C:\pwned.txt"


This is why SMB signing disabled is not a low-priority finding. The path from unsigned SMB to domain admin can take minutes on an undefended internal network.

If your team needs to validate how far an attacker could get in your environment, Redfox Cybersecurity's red team and penetration testing services simulate exactly these attack chains under controlled conditions.

How to Fix SMB Signing Disabled

Option 1: Fix via Group Policy (Recommended for Domain Environments)

Group Policy is the most scalable way to enforce SMB signing across your entire domain. Create or edit a GPO and navigate to:

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


Set the following four policies:

For SMB Servers (receiving connections):

• Microsoft network server: Digitally sign communications (always) -- Set to Enabled
• Microsoft network server: Digitally sign communications (if client agrees) -- Set to Enabled

For SMB Clients (initiating connections):

• Microsoft network client: Digitally sign communications (always) -- Set to Enabled
• Microsoft network client: Digitally sign communications (if server agrees) -- Set to Enabled

Apply this GPO to the root of your domain or at the OU level where servers and workstations reside, then force an update:

gpupdate /force


Verify the policy applied correctly:

Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature


Expected output after enforcement:

RequireSecuritySignature : True
EnableSecuritySignature  : True


Option 2: Fix via Registry (For Standalone or Non-Domain Hosts)

For machines not joined to a domain, configure SMB signing directly in the registry.

For SMB Server (server-side signing):

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


For SMB Client (client-side signing):

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


Restart the Server and Workstation services to apply without a reboot:

net stop server && net start server
net stop workstation && net start workstation


Option 3: Fix via PowerShell (Fastest for Bulk Remediation)

For rapid remediation across multiple hosts using PowerShell remoting:

$targets = Get-Content .\unsigned_hosts.txt

foreach ($target in $targets) {
   Invoke-Command -ComputerName $target -ScriptBlock {
       Set-SmbServerConfiguration -RequireSecuritySignature $true -EnableSecuritySignature $true -Force
       Set-SmbClientConfiguration -RequireSecuritySignature $true -EnableSecuritySignature $true -Force
   }
   Write-Output "Fixed: $target"
}


This script reads from the list of unsigned hosts you generated with CrackMapExec, enforces signing on both the server and client stacks, and confirms each host as it completes.

Handling Legacy and Non-Windows Devices

NAS devices, Linux Samba servers, and older print servers often do not support SMB signing. For these, your options are:

Isolate them on a dedicated VLAN with strict firewall rules that prevent lateral movement, disable NTLM authentication in favor of Kerberos wherever supported, and disable SMBv1 entirely since it does not support signing at all.

Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force


Verifying the Fix

After applying changes, re-scan with the same tools you used during detection.

crackmapexec smb 192.168.1.0/24 | grep -i "signing:False"


If the output is empty, no unsigned hosts remain. For a second verification pass using Nmap:

nmap -p 445 --script smb2-security-mode 192.168.1.0/24 | grep -A 3 "signing"


You should now see "Message signing enabled and required" across all hosts in scope.

Monitoring and Ongoing Detection

Fixing SMB signing once is not enough. New machines are provisioned, images get deployed without hardened baselines, and legacy devices get re-added. Build detection into your operations:

Schedule a weekly CrackMapExec scan as part of your internal vulnerability management cycle. Alert on any new host where signing:False appears. Integrate your SIEM to flag SMB sessions where the SigningRequired field is false in Windows Security event logs (Event ID 4624 with logon type 3 provides relevant context). Use Group Policy reporting to confirm GPO application coverage across all OUs.

If you want continuous assurance rather than point-in-time testing, Redfox Cybersecurity's managed penetration testing and security assessment services provide ongoing visibility into exactly these kinds of network-layer exposures.

Key Takeaways

SMB Signing Disabled is a deceptively simple misconfiguration with severe consequences. The detection is straightforward, the remediation is well-documented, and the tooling to exploit it is freely available to any attacker who wants to use it.

The attack chain from unsigned SMB to domain admin is short, reliable, and does not require any advanced malware or zero-day exploits. It is a foundational check in every internal penetration test for a reason.

Enforce SMB signing via Group Policy across your entire domain. Audit non-domain devices separately using registry changes or PowerShell remoting. Verify the fix with the same tools attackers use. And schedule regular rescans to catch regressions before they are exploited.

If you want a team of certified penetration testers to validate your SMB hardening, assess your NTLM relay attack surface, and uncover what else might be lurking in your internal network, reach out to Redfox Cybersecurity. Their assessments go beyond automated scanning to simulate real-world attack paths and give you actionable remediation guidance your team can act on immediately.