Why SMB Signing Matters and How to Secure Your Environment

SMB (Server Message Block) signing plays a critical role in protecting your network communications. Two of its biggest security benefits are,

Ensuring message integrity
Preventing NTLM relay attacks

Both threats typically involve an adversary-in-the-middle (AiTM). Let’s walk through how these attacks happen—and more importantly, how to defend against them.

How Attackers Get in the Middle?

When people think of AiTM attacks, they often imagine someone physically lurking in a server room. In reality, attackers usually compromise a device remotely and gain control. Once on the network, they use tools like Responder to listen for broadcast name resolution traffic.

Here’s what happens.

A device fails to resolve a name using DNS.
It falls back to LLMNR (Link-Local Multicast Name Resolution) or NBT-NS (NetBIOS Name Service).
The attacker’s system (running Responder) responds, pretending to be the device the client is trying to reach.
The client then starts a session with the attacker's machine.

From here, attackers can steal credentials or relay them to access legitimate systems.

How to Reduce the Risk?

Disable LLMNR and NBT-NS

LLMNR: Easy to disable via Group Policy, Intune, or registry.
- Registry key: HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\EnableMulticast=0
- If DNS works properly, this change won’t affect your network. But less structured environments (like home networks) might notice issues like not finding printers.
NBT-NS: Harder to manage because it’s configured per NIC.
- A better solution is setting the NodeType to P-node, which disables NetBIOS broadcasts.
- Registry key: HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\NodeType=2.

Note. You don’t need to bring back WINS servers. This is just a trick to suppress NetBIOS broadcasts.

You can also manage NodeType with SecGuide.admx from the Microsoft Security Compliance Toolkit.

Why Message Integrity Matters?

Like LDAP signing, SMB signing uses a session key negotiated during authentication. Each message is hashed and signed using that key. The recipient re-hashes the message to verify it wasn’t modified in transit.

This ensures that even if an attacker intercepts the message, they can’t alter it without detection—because they don’t have the session key.

Understanding NTLM Relay Attacks

NTLM is a challenge-response protocol.

The client connects to a resource.
The server issues a random challenge (nonce).
The client encrypts the challenge using the user's NTLM hash and returns it.
The server forwards the response to the domain controller for verification.

Here’s where an attacker can strike.

If a victim mistypes a server name, the device may try to broadcast to find it.
The attacker pretends to be that resource.
Instead of creating a new challenge, the attacker connects to a real server and relays the challenge back to the victim.
The victim signs it, and the attacker forwards it to authenticate as the victim.

Where SMB Signing Saves the Day?

Here’s the key point: NTLM authentication traffic often travels over SMB.

If SMB signing is required, the attacker’s relayed message will fail. Why? Because they don’t have the session key needed to sign the SMB messages—even though they tricked the victim into signing the challenge.

SMB signing enforces authenticity. If the attacker can’t sign the traffic, the session won’t be established.

Even More Protection: Disable NTLMv1 and Strengthen Passwords

Attackers might try a pre-computed challenge and compare the response to a rainbow table of NTLM hashes.
Mitigate this by:
- Disabling NTLMv1
- Enforcing strong password policies
- Using Microsoft Entra Password Protection to block weak passwords

How to Enforce SMB Signing?

You can find detailed guidance in the official documentation, but here’s a quick summary.

SMB signing is supported as far back as Windows NT 4.0.
Signing is negotiated if either the client or server supports it.
Use these Group Policy settings to enforce signing (not just allow it):
- Microsoft network client: Digitally sign communications (always)
- Microsoft network server: Digitally sign communications (always)
Avoid relying on,
- (if server/client agrees) – These only apply to SMBv1 and don’t enforce anything.
Performance concerns are outdated. With SMBv3, the impact is minimal.

Audit SMB Signing Adoption

Until recently, SMB signing usage was hard to audit. But starting with,

Windows 11 24H2
Windows Server 2025

New event logs make it easier to track.

Event ID 3021: Logs when a client doesn’t support signing
Event ID 31998: Logs when a server doesn’t support signing

Older systems? Use Wireshark with these filters.

SMBv1 unsigned: smb.flags2.sec_sig == 0 && !(smb.cmd == 0x72)
SMBv2+ unsigned: smb2.flags.signature == 0 && smb2.cmd != 0x00 && smb2.cmd != 0x01 && smb2.cmd != 0x0F.

Do’s and Don’ts

Enforce SMB signing—don’t delay.
Start by requiring signing for clients, then move to servers.
Disable LLMNR and NBT-NS everywhere.
Use the latest Windows builds and enable auditing.
Harden authentication by disabling NTLMv1.
Expect signing to be required by default in modern Windows versions.

DON’T

Ignore 3rd-party devices: old printers and appliances often don’t support signing.
Only enforce signing on domain controllers: endpoints and member servers matter too.
Assume enforcement will break everything: most modern systems support SMB signing just fine.

By enabling SMB signing and removing outdated name resolution methods, you’re making your environment significantly harder to exploit. It’s not just a checkbox—it’s a foundational step in defending against real-world attacks.

Ready to make your SMB traffic bulletproof?