1. Remove SMBv1 everywhere. Uninstall the feature, not just disable it, and hunt down the legacy devices that still require it so you can replace or isolate them. 2. Require SMB signing on clients and servers. Set it to required, not optional, so the protocol never negotiates down to unsigned and NTLM relay loses its f

SMB Security: Signing, SMBv1 & Stopping Lateral Movement

Q: What SMB is and where it listens?

Modern SMB runs directly over TCP 445. Older deployments also used NetBIOS on TCP 139, which you still see in legacy environments. When a user opens a network share, maps a drive, or a service reaches \\server\share, that is SMB. The protocol also exposes administrative shares on a default Windows install: C$ maps to t

Server Message Block is the protocol that lets Windows machines share files, printers, and named pipes. It is quiet, ubiquitous, and central to how a Windows network functions. It is also, once an attacker is inside, one of the main roads they travel to turn a single compromised laptop into control of the domain.

SMB is not dangerous because it is exotic. It is dangerous because it is everywhere, it is trusted by default between internal hosts, and older versions of it were built in an era with very different threat assumptions. Getting SMB right is mostly about removing the legacy, verifying integrity, and limiting who can reach it.

What SMB is and where it listens

Modern SMB runs directly over TCP 445. Older deployments also used NetBIOS on TCP 139, which you still see in legacy environments. When a user opens a network share, maps a drive, or a service reaches \\server\share, that is SMB.

The protocol also exposes administrative shares on a default Windows install: C$ maps to the system drive, ADMIN$ maps to the Windows directory, and IPC$ supports inter-process communication. These exist for legitimate management, and they are exactly what attackers reuse to copy tools and execute code on other machines.

Over the years SMB has grown from a simple file-sharing protocol into a general transport that carries printer access, remote administration, and named-pipe communication used by many Windows services. That breadth is what makes it both indispensable and dangerous. A protocol that can move files, list drives, and start services on a remote host is enormously useful to an administrator and equally useful to an attacker who has borrowed an administrator's credentials.

How attackers abuse SMB

Once an attacker has valid credentials or a hijacked session on one host, SMB gives them a way to reach the next. They authenticate to a remote machine's administrative share, write a payload, and execute it, moving laterally without dropping obvious malware on the wire. On MITRE ATT&CK this is T1021.002, SMB/Windows Admin Shares.

This lateral movement over SMB is a shared habit across ransomware crews, and our threat group intelligence maps which active groups lean on SMB and admin-share abuse to spread, so you can prioritise the segmentation that blunts the techniques currently in use. The classic technique writes a service binary to the ADMIN$ share and registers it as a service on the remote host, which then executes it with SYSTEM privileges. Tools like PsExec formalised this pattern for administrators, and attackers use the exact same mechanism because it relies only on valid credentials and normal protocol features. Nothing about it is a bug. It is SMB working as designed, pointed at a hostile goal.

Two failure modes make this far easier than it should be:

SMBv1 exposure. The first version of the protocol has no modern integrity protection and carries memory-corruption bugs. The EternalBlue exploit targeted an SMBv1 flaw addressed by Microsoft bulletin MS17-010, and it powered the WannaCry and NotPetya outbreaks of 2017, which spread across networks with no user interaction at all.
Missing SMB signing. When messages are not signed, an attacker positioned between client and server can tamper with the exchange. This is the mechanism that makes NTLM relay attacks work, where captured authentication is forwarded to a target that accepts it.

The distinction between those two is worth holding onto. SMBv1 is a code-quality and design problem you fix by removing it. Missing signing is a configuration problem you fix by requiring it. Both are common, and both are fully within your control.

SMBv1 has to go

SMBv1 is obsolete. It predates the security expectations of a modern network, lacks the integrity and encryption features of SMBv2 and v3, and has a history of wormable remote code execution flaws. Current Windows disables it by default, and Microsoft has deprecated it for years.

The correct action is removal, not tolerance. A dormant SMBv1 component is still an installed component that can be re-enabled or exploited. Uninstall the feature where it exists, and audit for the small number of legacy devices (old printers, old NAS units, industrial equipment) that still demand it, then replace or isolate them. Microsoft documents how to detect, enable, and disable each SMB version, and the guidance is unambiguous: remove SMBv1.

Never let 445 face the internet

TCP 445 exposed to the internet is a standing invitation. The WannaCry and NotPetya outbreaks spread through SMB, and internet-facing SMB remains a routinely scanned target. Block 445 and 139 inbound at the perimeter without exception, and treat any external SMB listener as a finding.

What SMB signing prevents

SMB signing attaches a cryptographic signature to each message so the receiver can verify it was not altered in transit and genuinely came from the authenticated party. When signing is required, an attacker in the middle cannot silently modify or relay the traffic, because the tampered messages fail verification.

This is the direct defense against NTLM relay. If a server requires signing, captured authentication cannot be replayed against it, because the relayed session cannot produce valid signatures for the attacker's injected commands. Microsoft's overview of SMB signing covers the settings.

The important word is require, not merely enable. If signing is optional, a client and server will negotiate down to unsigned when either side does not insist. Requiring it on both clients and servers is what actually closes the relay path.

SMBv3 adds encryption on top of signing. Signing guarantees a message was not tampered with and came from the right party; encryption additionally hides the contents from anyone watching the wire. For shares that carry sensitive data, enabling SMB encryption means an attacker who can capture traffic learns nothing from it, which matters on networks where you cannot assume every segment is trustworthy. Newer Windows versions also strengthen the defaults over time, with signing required in more scenarios out of the box, so keeping systems current quietly improves your SMB posture even before you touch a setting.

SMB version	Status	Security posture
SMBv1	Deprecated, disable and remove	No modern integrity, wormable history (EternalBlue)
SMBv2	Supported	Signing available, major improvement over v1
SMBv3	Current	Signing plus encryption, pre-authentication integrity

Segmentation is the safety net

Application controls fail. Credentials leak, a host gets compromised, a control is misconfigured. Segmentation is what decides whether that becomes a single-host problem or a domain-wide one.

The goal is that a compromised workstation cannot freely reach SMB on every other workstation and server. Most endpoints have no legitimate reason to open SMB sessions to their peers. Restrict east-west SMB to the specific paths that need it (clients to file servers, management systems to their targets) and deny the rest. When lateral movement over SMB is blocked by the network, a foothold stays a foothold.

Host-based firewalls do a lot of this work cheaply. A rule that blocks inbound TCP 445 between workstations, while still allowing workstations to reach genuine file servers, removes the most common workstation-to-workstation spread path without touching legitimate use. Pair that with unique local administrator passwords across machines, so that even when an attacker can reach a peer over SMB, the credential they dumped does not authenticate to it. Reused local admin passwords are what let a single foothold cascade, because the same secret unlocks every machine that shares it.

Assume the endpoint will fall

Design SMB access as if one machine is already compromised. Ask what that machine can reach over 445 and whether it should. Host firewalls that block inbound SMB between workstations, plus network segmentation between tiers, remove most of the lateral movement an attacker was counting on.

How to secure SMB

Remove SMBv1 everywhere. Uninstall the feature, not just disable it, and hunt down the legacy devices that still require it so you can replace or isolate them.
Require SMB signing on clients and servers. Set it to required, not optional, so the protocol never negotiates down to unsigned and NTLM relay loses its footing.
Prefer SMBv3 and enable encryption for shares carrying sensitive data, so traffic is protected in transit as well as verified.
Block 445 and 139 at the perimeter. No SMB should ever cross the internet boundary in either direction.
Segment internal SMB. Limit east-west SMB to the paths that genuinely need it and deny workstation-to-workstation SMB by default with host firewalls.
Apply least privilege to administrative shares. Restrict who holds local administrator rights across machines, because those rights are exactly what SMB lateral movement consumes.
Monitor SMB access. Log and alert on unusual share access, especially writes to ADMIN$ and C$ and access from hosts that have no reason to connect.

A worked example: from one laptop to a second machine

Walking through how an attacker actually uses SMB makes the defenses concrete. Assume an attacker has already compromised one workstation and dumped a local administrator credential from it, and that the same local administrator password is reused across many machines.

The attacker enumerates other hosts on the subnet and finds a second workstation, WKS02, listening on TCP 445. Using the dumped credential, they open an authenticated SMB session to WKS02's ADMIN$ share. Because the local administrator password is shared, the credential works. They copy a payload into the Windows directory through that share. They then use SMB's named-pipe access to the service control interface to register a new service on WKS02 pointing at the payload, and they start it. The service runs as SYSTEM, so the payload executes with full privileges on the second machine. The attacker now controls WKS02 and repeats the process outward.

Nothing in this sequence exploits a software bug. It uses valid credentials, the built-in administrative shares, and the normal remote service control that SMB carries. Tools such as PsExec were written for administrators to do exactly this, and attackers reuse the same mechanism. This is why the defense is not a patch. It is removing the conditions the technique depends on: shared local admin passwords, unrestricted workstation-to-workstation SMB, and broad administrative rights. On MITRE ATT&CK the credential reuse that powers this maps to the use of valid accounts, and the spread itself is T1021.002.

Now change one variable. If the local administrator password on WKS02 were unique, the dumped credential would fail at the first authenticated session, and the chain would stop at the first machine. If host firewalls blocked inbound 445 between workstations, the attacker could not open the session at all. Each control removes a link.

SMB dialects and how they are negotiated

SMB is a family of dialects, and a connection begins with the client and server negotiating which one to speak. The client offers the dialects it supports, and the server selects the highest it also supports. This negotiation is itself a security-relevant step, because an attacker who can influence it may try to force both sides down to a weaker dialect.

SMBv3 addressed this with pre-authentication integrity, which protects the negotiation itself so that tampering with the dialect selection is detected before authentication completes. That is one reason keeping every host on SMBv3 matters beyond the features of the dialect: it protects the moment where the dialect is chosen. An environment that still allows SMBv1 anywhere weakens this, because SMBv1 has no such protection and its mere availability gives an attacker a weaker option to aim for.

Concern	Mechanism	Dialect that provides it
Message tamper detection	SMB signing	SMBv2 and SMBv3
Content confidentiality on the wire	SMB encryption	SMBv3
Protected dialect negotiation	Pre-authentication integrity	SMBv3
None of the above	(legacy design)	SMBv1

Detection signals: what SMB abuse looks like

SMB lateral movement generates observable events, and knowing them turns quiet spread into something a defender can catch.

Writes to the ADMIN$ and C$ shares from a host that has no administrative role are a strong signal, because ordinary users rarely, if ever, write to another machine's administrative shares. Service creation events on a remote host that follow an SMB session from an unusual source tie the file copy to the execution step of lateral movement. A single account authenticating over SMB to many machines in a short window, especially to hosts it never normally touches, fits the pattern of an attacker sweeping a subnet with a reused credential.

At the network level, inbound TCP 445 connections between workstations are worth flagging, because most workstations have no reason to open SMB sessions to their peers. Any SMB traffic crossing the internet boundary is a finding on its own. A negotiation that settles on SMBv1, or authentication that falls back to unsigned sessions on a server that should require signing, points to either a misconfiguration or a deliberate downgrade attempt.

Baseline normal SMB, then alert on the exceptions

Most environments have a small, stable set of legitimate SMB paths: workstations to file servers, management systems to their targets, backup systems to their sources. Once you know that baseline, the useful alerts are the exceptions to it: workstation-to-workstation sessions, writes to administrative shares from non-admin hosts, and one account reaching many machines in a short window. The signal lives in the deviations, so the baseline is what makes detection tractable.

Why named pipes and IPC$ matter

SMB is often thought of purely as file sharing, and the file part is only half of what it carries. SMB also transports named pipes, a form of inter-process communication, exposed through the IPC$ share. Many Windows management interfaces ride over named pipes on top of SMB: remote service control, remote registry, the task scheduler, and parts of remote administration all reach a machine this way.

This is why SMB is such a productive path for an attacker. Once an authenticated SMB session exists, it becomes a way to reach the remote service control manager to create and start services, to touch the registry, and to drive other administrative interfaces, all through named pipes over the same session, on top of reading and writing files. The service-creation step in the lateral movement example above travels over exactly this channel. It also explains why restricting who can open authenticated SMB sessions, and to which machines, does more than protect files. It closes access to a whole set of remote administration surfaces that share the same transport.

How SMB hardened over time

SMB's security history tracks the threats of its era. The first version was built when internal networks were treated as trusted and integrity protection was an afterthought, which is why it has no meaningful signing and a record of wormable bugs. SMBv2 rewrote the protocol with a cleaner design and made signing available. SMBv3 added encryption, pre-authentication integrity to protect the dialect negotiation, and stronger defaults. Across recent Windows releases, Microsoft has continued to tighten the out-of-the-box posture, requiring signing in more scenarios and disabling SMBv1 by default. The direction has been steady: fewer weak options available, stronger protections required rather than merely offered. Keeping systems current is therefore a quiet security win on its own, because the defaults improve underneath you even before you change a setting.

Common misconceptions

Several beliefs about SMB lead to weak configurations.

The first is that disabling SMBv1 is the same as removing it. Disabling turns it off, and the component is still installed and can be re-enabled or exploited. The correct action is to uninstall the feature so the code is gone.

The second is that enabling SMB signing is enough. If signing is merely enabled and not required, a client and server will negotiate down to unsigned whenever either side does not insist, which leaves the relay path open. The control that matters is requiring signing on both clients and servers.

The third is that SMB encryption and SMB signing do the same thing. Signing verifies that a message was not altered and came from the authenticated party, which stops tampering and relay. Encryption hides the message contents from anyone watching the wire. They solve different problems, and SMBv3 offers both.

The fourth is that blocking 445 at the perimeter secures SMB. It closes the internet exposure, which is essential, and it does nothing about lateral movement inside the network, which is where most SMB abuse actually happens. Internal segmentation is the control for that.

Frequently asked questions

Is SMBv1 the only version with security problems? SMBv1 is the version with fundamental design and code-quality problems, including a history of wormable remote code execution and no modern integrity protection, which is why it should be removed. SMBv2 and SMBv3 are supported and can be secured, but they still require correct configuration, chiefly required signing and, for sensitive data, encryption. Removing SMBv1 is necessary and not sufficient on its own.

What is the difference between SMB signing and SMB encryption? Signing attaches a cryptographic signature to each message so the receiver can confirm it was not tampered with and came from the authenticated party, which is the direct defense against NTLM relay. Encryption, available in SMBv3, additionally conceals the message contents from anyone capturing traffic. Signing protects integrity and authenticity, and encryption protects confidentiality.

Why should TCP 445 never face the internet? Internet-exposed SMB is continuously scanned and has been the vector for self-propagating outbreaks. An SMB service reachable from the internet exposes authentication and, on unpatched systems, memory-corruption bugs to the entire world. Block 445 and 139 inbound and outbound at the perimeter, and treat any external SMB listener as an incident to investigate.

Does requiring SMB signing hurt performance? Signing adds a small computational cost per message, and on modern hardware the impact is generally minor compared to the security benefit of closing the relay path. Current Windows versions increasingly require signing by default, reflecting the judgment that the tradeoff favors requiring it. Test in your environment, and in most cases the safe choice is to require it.

How does removing SMBv1 relate to EternalBlue? EternalBlue targeted a memory-corruption flaw in SMBv1, addressed by Microsoft bulletin MS17-010, and it powered the WannaCry and NotPetya outbreaks in 2017. Systems without SMBv1 present were not exposed to that specific exploit. Removing SMBv1 eliminates an entire class of wormable SMBv1 bugs, which is why the guidance to uninstall it is unambiguous.

Can segmentation replace patching and signing? No, they cover different failures. Patching removes known bugs, required signing closes the relay path, and segmentation limits how far a compromise can spread when the other controls fail. Segmentation is the safety net that turns a single foothold into a contained problem, and it works best layered with, not instead of, the other controls.

What role do local administrator passwords play? Reused local administrator passwords are what let a single dumped credential unlock many machines over SMB, turning one foothold into domain-wide spread. Giving each machine a unique local administrator password, managed automatically, means a credential lifted from one host does not authenticate to the next, which breaks the credential-reuse link that SMB lateral movement depends on.

SMB is load-bearing infrastructure for a Windows network, which is precisely why it deserves discipline. Kill the legacy version, require signing, keep it off the internet, and segment it internally. Do that and SMB stays what it is meant to be, a file-sharing service, instead of becoming the attacker's fastest route from one machine to all of them.