SMB Signing and NTLM Relay: Closing the Quiet Path to Lateral Movement

1. Introduction

SMB (Server Message Block) is the protocol behind Windows file shares, printer access, named pipes and much of the administrative tooling (PsExec-style remote execution, remote registry, service control). Because SMB carries authentication and because that authentication is frequently NTLM, SMB is the classic target for relay attacks. The single most important control — SMB signing — is often left unenforced on servers and workstations, leaving a wide, quiet path for privilege escalation and lateral movement inside otherwise well-patched networks.

2. How It Works

An SMB session begins with protocol negotiation, then authentication (Kerberos when an SPN/hostname is available, NTLM otherwise), then access to shares and named pipes.

Client                                   Server (SMB)
  |  NEGOTIATE (dialects, capabilities) --> |
  |  SESSION_SETUP (auth: Kerberos/NTLM) -->| authenticates the client
  |  TREE_CONNECT (\\server\share)      --> | checks share + NTFS ACLs
  |  CREATE / READ / WRITE              --> | serves the file / pipe

SMB signing places a cryptographic signature (keyed from the session) on every SMB message so the server and client can detect tampering and, critically, so a third party cannot relay the authenticated session to another host. Modern SMB (SMB 3.x) also supports encryption, which protects confidentiality on the wire. SMB signing has two policy dimensions per endpoint: whether it is enabled/negotiated and whether it is required.

3. The Security Problem

If SMB signing is not required, an attacker who can coerce or intercept a victim’s SMB authentication can relay it to another server and execute actions as the victim. The danger scales with privilege: relaying a domain admin or a privileged machine account to a sensitive server can mean immediate compromise. Signing is enforced by default on domain controllers, but frequently not required on member servers and workstations — exactly the machines used for lateral movement. Name-resolution poisoning (LLMNR/NBT-NS) is a common way to obtain the victim authentication in the first place.

4. How Attackers Abuse It

SMB relay (concept): The attacker positions between a victim and a server (often via LLMNR/NBT-NS poisoning or authentication coercion), receives the victim’s NTLM authentication, and forwards it to a target that does not require signing. The target validates the relayed session and the attacker gains the victim’s access — without ever knowing a password or hash. Cross-protocol relay (SMB in, LDAP or HTTP out) extends this further.

In an authorized engagement, the tester demonstrates in a controlled lab that a specific server accepts a relayed session because signing is not required, then hands the blue team the exact endpoints to remediate. The offensive detail stops at “this endpoint is relayable” — the fix is the deliverable.

5. How to Detect / Check SMB Configuration

Command

Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, RequireSecuritySignature, EnableSecuritySignature, EncryptData

What it does: Shows the SMB server-side signing and encryption posture of the local machine.

What to look for: RequireSecuritySignature = False means signing is not required — the relay-vulnerable state. EnableSMB1Protocol = True is a serious legacy risk and should be false.

Defensive use: Run across the fleet to produce a list of servers where signing must be enforced and SMBv1 removed.

Command

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature

What it does: Shows the SMB client-side signing requirements of the local machine.

What to look for: RequireSecuritySignature = False means the client will proceed without signing if the server does not require it.

Defensive use: Confirms clients will demand signing, closing the relay window from the initiating side.

Command

Invoke-Command -ComputerName (Get-ADComputer -Filter {OperatingSystem -like '*Server*'}).Name -ScriptBlock { Get-SmbServerConfiguration | Select-Object PSComputerName, RequireSecuritySignature } -ErrorAction SilentlyContinue

What it does: Fans out the signing check across all Windows Server computer objects in the domain.

What to look for: Any server returning RequireSecuritySignature = False.

Defensive use: Turns an ad-hoc check into a domain-wide inventory for prioritised remediation.

6. Why SMB Signing Matters

Signing is the property that makes a relayed session fail: the relayed traffic cannot be re-signed for a different session, so the target rejects it. Without it, every unsigned server is a potential landing spot for coerced authentication. This is why enforcing signing everywhere — not just on DCs — is the structural fix, complemented by disabling LLMNR/NBT-NS to remove the easy coercion vector.

7. How to Audit the Environment

• Inventory RequireSecuritySignature on every server and workstation (client and server config).
• Confirm SMBv1 is uninstalled/disabled everywhere.
• Verify LLMNR and NBT-NS are disabled via GPO to remove name-poisoning coercion.
• Check that privileged accounts are protected (Protected Users group, no interactive logon to low-trust hosts) so a relayed session is less valuable.
• Confirm SMB encryption is enabled on shares carrying sensitive data.

8. How to Fix / Harden It

• Set “Microsoft network server: Digitally sign communications (always)” and the client equivalent to Enabled via GPO.
• Remove the SMB 1.0/CIFS feature fleet-wide.
• Disable LLMNR (“Turn off multicast name resolution”) and NBT-NS.
• Enable SMB encryption for sensitive shares.
• Add sensitive accounts to Protected Users and enforce tiered administration so privileged auth never lands on relayable hosts.

9. Detection & Monitoring

• Event ID 4624 (Logon Type 3, NTLM) to servers that should be Kerberos-only can indicate relay or coercion.
• Event ID 5140/5145 (file share access / detailed share access) — unusual access to ADMIN$ or IPC$ from unexpected sources suggests lateral movement.
• SMBv1 usage events and any negotiation of the SMB1 dialect.
• Behavioural: one workstation authenticating to many servers over SMB in a short window; spikes correlated with LLMNR/NBT-NS traffic.

10. MITRE ATT&CK Mapping

Technique	ID
Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay	T1557.001
Remote Services: SMB/Windows Admin Shares	T1021.002
Lateral Tool Transfer	T1570
Valid Accounts: Domain Accounts	T1078.002

11. Practical Lab

In an isolated lab:

1. Use Get-SmbServerConfiguration to record a member server showing RequireSecuritySignature = False.
2. Apply the “sign always” GPO, re-run the check, and confirm the value flips to True.
3. Disable LLMNR/NBT-NS via GPO and confirm clients no longer emit multicast name queries.
4. Generate share access and observe Events 5140/5145 for ADMIN$ and IPC$.
5. Remove SMBv1 and verify no dialect negotiation falls back to SMB1.

12. Key Takeaways

• Relay succeeds where SMB signing is not required — enforce it on every endpoint, not just DCs.
• Disabling LLMNR/NBT-NS removes the easiest coercion vector for obtaining victim authentication.
• SMBv1 must be gone; it is both a relay and a wormable-exploit liability.
• Protect privileged accounts (Protected Users, tiering) so any relayed session is low value.

Continue learning: Active Directory security

This guide is part of our Active Directory Security series. Related guides:

• LDAP and LDAP Signing in Active Directory: Channel Binding, Relay, and Hardening
• NTLM Authentication: Pass-the-Hash, Relay, and Why Enterprises Are Retiring It
• Kerberos in Active Directory: How It Works, How It Is Abused, and How to Defend It