Require SMB Signing to Prevent NTLM Relay and Man-in-the-Middle Attacks
Without SMB signing, attackers can relay captured NTLM authentication to authenticate to other servers as the victim — requiring signing makes relayed credentials unusable.
An attacker on the network can run Responder to capture NTLM authentication and ntlmrelayx to simultaneously relay those credentials to other servers. If the relayed account has local admin rights on the target, the attacker gains immediate code execution. This is one of the most effective lateral movement techniques in Windows environments and is extensively used by both penetration testers and real attackers.
SMB signing cryptographically signs SMB communications to prevent tampering and replay attacks. Without it, an attacker using tools like Responder, ntlmrelayx, or Impacket can intercept NTLM authentication attempts and relay them to authenticate to other servers in real time. This technique bypasses password knowledge entirely — the attacker never needs to know the password.
Probably yes if any of these apply:
Affected OS versions
SMB relay is listed as a finding in the vast majority of internal penetration test reports for Windows environments. A penetration tester on a standard workstation can compromise a Domain Controller within an hour using only Responder and ntlmrelayx in an environment where SMB signing is not required.
Manual remediation steps
⏱ 10 minutesCheck Current SMB Signing Status
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature
Require SMB Signing on Server
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force
Set-SmbClientConfiguration -RequireSecuritySignature $true -Force
Verification
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature
# Must return RequireSecuritySignature = True
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
# Must return RequireSecuritySignature = True
Group Policy Deployment
Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options:
No tested PowerShell script for this entry yet. We’re prioritising automation based on user demand.