SMB Signing: The One GPO That Would Have Stopped Me

Of all the hardening recommendations I write in penetration test reports, SMB signing enforcement is the one I wish every organization would implement immediately. In my experience, enabling SMB signing across all systems would have blocked or significantly slowed my attack path in roughly 70% of my engagements. It is a single Group Policy setting that eliminates an entire class of attacks, yet most organizations leave it at the insecure default.

SMB signing ensures that every SMB packet is cryptographically signed by the sender. When signing is enforced, I cannot intercept an authentication and replay it to a different server because the signature will be invalid for the new destination. It turns NTLM relay from a trivial attack into an impossibility for SMB-based targets.

Why the Default Configuration Is Dangerous

Microsoft's default SMB configuration has been a source of frustration for security professionals for years. Domain controllers require SMB signing by default, which is good. But all other Windows machines -- workstations, member servers, file servers -- only support signing without requiring it. That means if one side of the connection does not demand signing, the conversation happens unsigned.

In practical terms, this means every workstation-to-server SMB connection in a default environment is vulnerable to relay. When I run Responder on a network and capture an NTLM authentication headed for a file share, I can relay it to any server that does not require signing. Since most member servers inherit the default setting, I have a wide field of targets.

The situation becomes even worse when you consider authentication coercion. I do not need to wait for organic traffic. Using PetitPotam against a server forces it to authenticate to me via SMB, and if signing is not required on my target, I relay that authentication directly. I have used this exact flow to compromise backup servers, database servers, and SCCM distribution points -- all in environments that had significant security budgets.

The Performance Myth

The number one objection I hear against enabling SMB signing is performance impact. This concern is largely outdated. On modern hardware with AES-based signing, the overhead is minimal. Microsoft's own benchmarks show roughly 2-3% throughput reduction on sustained file copy operations. For typical business workloads like opening documents, saving files, and accessing shared folders, the impact is imperceptible.

Even in scenarios with heavy file server usage, the performance cost of SMB signing is dramatically less than the cost of a successful relay attack. I have watched organizations spend millions on ransomware recovery when a single GPO would have prevented the initial compromise. The performance argument does not survive a basic cost-benefit analysis.

If you have legacy systems that genuinely cannot support SMB signing, isolate them in a separate network segment with strict firewall rules. Do not let a handful of legacy devices compromise your entire domain.

Step-by-Step Deployment

Here is how I recommend organizations roll out SMB signing without causing disruption:

1. Audit first. Before enforcing signing, identify which devices in your environment currently negotiate unsigned SMB connections. Enable the "Audit" policy for SMB signing and review the logs. This will surface any legacy devices or applications that cannot handle signing.
2. Start with servers. Create a GPO that sets "Microsoft network server: Digitally sign communications (always)" to Enabled. Link it to your server OUs. Monitor for issues over one to two weeks.
3. Extend to workstations. Apply the same GPO to workstation OUs. Also enable the client-side equivalent: "Microsoft network client: Digitally sign communications (always)." This ensures signing is required regardless of which side initiates the connection.
4. Validate enforcement. Do not just trust that the GPO is applied. Use tools like CrackMapExec or NetExec with the --gen-relay-list option to scan your network and identify machines that still allow unsigned SMB connections. Any machine on that list is still vulnerable.

Beyond SMB Signing: Complementary Controls

SMB signing stops SMB-based relay, but attackers can still relay NTLM authentication to other protocols. To fully close the door on relay attacks, you need complementary controls:

• LDAP signing and channel binding: Prevents relay to LDAP/LDAPS. Set LdapEnforceChannelBinding to 2 and require LDAP signing on all domain controllers.
• EPA (Extended Protection for Authentication): Prevents relay to web-based services like ADCS web enrollment, Exchange OWA, and internal web applications.
• Disable NTLM progressively: The ultimate goal is eliminating NTLM entirely in favor of Kerberos. Use the "Restrict NTLM" GPO policies to audit and then block NTLM at the domain level.

Monitoring After Deployment

After enabling SMB signing, set up monitoring to detect any attempts to exploit NTLM relay. Even with signing enforced, detection is valuable because it reveals active attack activity in your network. Monitor for NTLM authentication events (Event ID 4624, logon type 3) where the source workstation name does not match the connecting IP address. This pattern is a strong indicator of relay attempts.

Additionally, watch for Responder-style attacks by monitoring for LLMNR and NBT-NS queries. These protocols are what attackers use to intercept name resolution and trigger NTLM authentication. Disable LLMNR and NBT-NS across your environment via GPO, and alert on any remaining traffic using these protocols.

SMB signing is not glamorous. It will not win you any awards or generate impressive dashboard metrics. But in my years of penetration testing, I have seen it stop more attacks than any EDR product, any firewall rule, or any security awareness training program. It is the foundation that everything else builds on. Enable it today.