Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
Server Message Block (SMB) is the workhorse protocol behind Windows file sharing, print services, and a good deal of inter-host authentication traffic on internal networks, which makes it one of the highest-value protocols on almost every internal penetration test and one of the most consequential to secure. Its security story has three distinct threads that are often conflated: SMBv1, the original, decades-old dialect that should no longer exist on any modern network; SMB signing, which protects message *integrity* and is the direct defense against NTLM relay attacks; and SMB encryption, introduced with SMBv3, which protects *confidentiality* of data in transit.
None of these three is optional in a well-run environment, but they are commonly left partially configured because each has a real operational cost — SMBv1 removal can break legacy appliances, signing can affect throughput on high-latency links, and encryption has a small CPU cost. Understanding exactly what each protects against, and what a lapse in each one actually enables an attacker to do, is what separates a checkbox SMB hardening pass from one that actually closes the relay and downgrade paths red teams use every day.
Attack Prerequisites
The SMB attack surface breaks into a few distinct scenarios:
- SMBv1-specific exploitation requires SMBv1 still enabled and reachable — on a modern, patched estate this is now rare, but legacy print servers, NAS appliances, and old line-of-business servers still expose it.
- NTLM relay via SMB requires a way to coerce or capture NTLM authentication (LLMNR/NBT-NS poisoning,
PetitPotam-style coercion, a malicious file share) plus at least one relay target where SMB signing is not required — signing enforcement on the relay target is what actually stops the relayed session from being accepted. - Confidentiality exposure requires SMB encryption not negotiated between client and server, combined with an attacker in a position to capture traffic (shared L2 segment, compromised switch, on-path position).
- Downgrade/negotiate tampering requires a peer that does not support SMB 3.1.1 pre-authentication integrity, which is what binds the negotiated dialect and capabilities to the session and prevents an on-path attacker from forcing a weaker negotiated dialect.
How It Works
SMBv1 is functionally obsolete: it lacks modern integrity protections, its signing implementation is comparatively weak, and it was the protocol exploited by the EternalBlue remote code execution vulnerability (CVE-2017-0144) fixed in Microsoft’s MS17-010 bulletin, which underpinned the 2017 WannaCry and NotPetya outbreaks. Beyond RCE risk, SMBv1’s design predates the security expectations of a hostile internal network entirely, which is why Microsoft has disabled it by default since Windows 10 1709/Server 2016 and treats its continued presence as a hardening finding independent of any specific CVE.
SMB signing adds a cryptographic signature (HMAC-based in SMB2/3, weaker in SMB1) to every message in a session, which an on-path attacker cannot forge without the session key. This is the direct countermeasure to NTLM relay: without signing enforced, an attacker who captures or coerces a victim’s NTLM authentication attempt (via LLMNR/NBT-NS poisoning or an authentication-coercion technique) can relay that authentication live to a *different* SMB server the victim has privileges on, completing the handshake and gaining a session as the victim, all without ever learning the victim’s password or hash. If the target server requires signing, the relayed session fails, because the attacker cannot produce a valid signature without the underlying session key it never possessed. Historically, SMB signing defaulted to “if the client agrees” rather than “required” on most Windows hosts, which is precisely the gap relay tooling exploits; Windows Server domain controllers have required signing by default for a long time, but member servers and workstations frequently have not, which is why relay to non-DC targets remains a common finding.
SMB encryption, added in SMBv3 (Windows 8/Server 2012) using AES-CCM and later AES-GCM, is a separate, opt-in property that protects the confidentiality of data in transit — signing alone still lets an on-path observer read message contents, just not tamper with them undetected. SMB 3.1.1 additionally introduced pre-authentication integrity, which hashes the negotiation and session-setup messages themselves and binds that hash into session key derivation — this specifically defends against an on-path attacker tampering with the dialect-negotiation exchange to force a weaker dialect or capability set before encryption/signing keys are even derived.
Vulnerable Code / Configuration
SMBv1 left enabled is a registry/feature-level setting, and is the first thing to check on any host:
# VULNERABLE: SMBv1 server component still enabled
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
# State : Enabled
# Remediate:
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
SMB signing is controlled by Group Policy / local security policy and by two distinct registry values for server and client roles — “if client agrees” is the permissive, exploitable default seen on many non-DC hosts:
; VULNERABLE: signing negotiated only if the client requests it, not required
HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters
RequireSecuritySignature = 0 ; server does not REQUIRE signing
EnableSecuritySignature = 1 ; will sign only if asked
; Hardened: require signing on both server and client roles
HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters
RequireSecuritySignature = 1
HKLM\SYSTEM\CurrentControlSet\Services\LanManWorkstation\Parameters
RequireSecuritySignature = 1
SMB encryption is per-share (or server-wide) and off unless explicitly enabled; an unencrypted share on a sensitive file server leaves contents readable to anyone who can capture the traffic:
# VULNERABLE: share created without encryption
New-SmbShare -Name Finance -Path D:\Finance
# Hardened: require encryption for this share, or set -EncryptData $true
# server-wide with Set-SmbServerConfiguration
Set-SmbShare -Name Finance -EncryptData $true
Set-SmbServerConfiguration -EncryptData $true -RejectUnencryptedAccess $true
Walkthrough / Exploitation
Enumerate SMB dialect support and signing enforcement across a target subnet with netexec (the actively maintained fork of CrackMapExec):
netexec smb 10.0.0.0/24 --gen-relay-list relay_targets.txt
# netexec flags hosts where signing is NOT required as viable relay targets
Coerce or capture NTLM authentication (e.g. via LLMNR/NBT-NS poisoning with Responder) and relay it to a non-signing target using Impacket’s ntlmrelayx.py:
Responder.py -I eth0
ntlmrelayx.py -tf relay_targets.txt -smb2support
# A relayed authenticated session lands on any target from relay_targets.txt
# where the victim account has access and signing was not enforced.
Where SMBv1 is still present, confirm and, if in an authorized lab context reproducing a patched historical issue, validate exposure with a scanner rather than a live exploit against production:
nmap --script smb-protocols -p445 target.example
netexec smb target.example --shares -u '' -p '' # anonymous/null session check
Note: SMB signing stops relay because it stops *tampering and forged sessions*, not because it hides authentication material — the NTLM challenge/response is still visible on the wire. Signing and encryption solve different problems and both should be enforced; enabling one is not a substitute for the other.
Opsec:
netexec‘s relay-list generation and Responder’s poisoning are both detectable — LLMNR/NBT-NS poisoning generates anomalous multicast responses, and a burst of SMB authentication attempts against many hosts in a short window from a single source is a standard lateral-movement detection pattern.
Detection and Defense
SMB hardening should treat all three properties as required, not optional:
- Disable SMBv1 everywhere, server and client components, via Group Policy or
Remove-WindowsFeature/Disable-WindowsOptionalFeaturefleet-wide. - Require SMB signing on both server and client roles across all hosts, not just domain controllers — the GPO paths are *Microsoft network server/client: Digitally sign communications (always)*.
- Enable SMB encryption for sensitive shares at minimum, and server-wide with
RejectUnencryptedAccesswhere legacy client compatibility allows it. - Monitor for LLMNR/NBT-NS poisoning and NTLM relay indicators — Event ID 4624/4625 patterns showing NTLM authentication from unexpected sources, and network IDS signatures for known coercion/relay tool traffic.
- Patch and inventory SMB-speaking devices — legacy NAS, printers, and appliances are the most common source of lingering SMBv1 exposure long after Windows hosts have been remediated.
Real-World Impact
SMBv1’s risk was proven at global scale by the 2017 WannaCry and NotPetya outbreaks, both of which propagated via the EternalBlue SMBv1 exploit (CVE-2017-0144) across unpatched networks, causing billions of dollars in combined damage and remaining among the most cited examples of legacy protocol risk in security awareness material to this day. Independently of that history, NTLM relay against SMB targets missing signing enforcement remains one of the single most common critical findings on internal penetration tests, because it requires no vulnerability at all — only a default that was never tightened.
Conclusion
SMBv1 removal, signing enforcement, and encryption are three separate controls addressing three separate risks — legacy-protocol exploitation, message tampering/relay, and confidentiality — and all three need to be explicitly enforced rather than left at historical defaults. The recurring theme across SMB hardening failures is the same one across most of network security: the protocol has supported the secure option for years, and the gap is almost always deployment, not the protocol itself.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments