SMB Explained: Versions, Signing, and Why SMBv1 Has to Go

Server Message Block is the protocol behind Windows file and printer sharing. It is also, by a wide margin, the protocol most often involved when something goes badly wrong on a Windows network — ransomware propagation, credential relay, and the worm outbreaks of recent years all traveled over it. Knowing its versions and its hardening settings is worth real exam points.

What it does

SMB is a client-server protocol for accessing files, printers, and named pipes on a remote host as though they were local. A client connects, authenticates, negotiates a dialect, and then issues open, read, write, and close operations against shares. Windows administrative shares such as C$ and ADMIN$ exist by default and are how most remote management tooling reaches a machine.

Modern SMB runs directly over TCP 445. Legacy SMB rode on NetBIOS over TCP using 137, 138, and 139, which is why those ports still appear in hardening guides. Anchoring these in the wider set of port numbers to know is worth the five minutes.

The version history that matters

SMBv1 dates to the 1980s. It is chatty, slow over anything but a LAN, and — critically — it cannot be secured. It has no meaningful integrity protection, and it was the vehicle for the EternalBlue exploit that drove the WannaCry and NotPetya outbreaks. Microsoft has deprecated it, removed it from default installations, and recommends disabling it outright. If a scenario mentions SMBv1, the expected answer is to remove it.

SMBv2 cut the command set dramatically, added request pipelining, and performs far better over wide-area links. It introduced message signing as a practical option.

SMBv3 added end-to-end encryption, secure dialect negotiation that prevents an attacker from forcing a downgrade to v1, multichannel for using several network paths at once, and better recovery. SMB 3.1.1 strengthened the negotiation integrity check further. Encryption can be required per share or per server, and it protects data in transit without a VPN.

Signing and the relay problem

SMB signing attaches a cryptographic signature to each message, derived from the session key. An attacker who intercepts and forwards an authentication exchange cannot produce valid signatures, so the relayed session fails.

This matters because relay is the most common way SMB is abused on an internal network. An attacker poisons name resolution, a client authenticates to the attacker, and the attacker forwards that authentication to a real server. Where signing is required, the forwarded session breaks; where it is merely "enabled if the other side wants it," it does not. The full attack chain is covered under LLMNR and NBT-NS poisoning, and requiring signing is the specific control for its relay variant.

Require signing on both clients and servers. Domain controllers require it by default; ordinary member servers and workstations often do not.

Hardening checklist

Disable SMBv1 everywhere, and audit for it rather than assuming — old multifunction printers and scan-to-folder appliances are the usual holdouts, and they are also the usual reason someone re-enables it.

Block TCP 445 and the NetBIOS ports at the internet perimeter in both directions. Outbound matters too: a document that references a remote path can cause a client to attempt authentication to an external host, leaking credentials.

Require signing, enable SMB encryption for shares carrying sensitive data, and disable guest access and anonymous enumeration of shares and users. Apply least privilege to share and NTFS permissions, remembering that the effective permission is the more restrictive of the two.

Segment the network so that workstations cannot reach each other over 445. Lateral movement between peers is rarely legitimate and is exactly how ransomware spreads once one machine falls.

Monitoring

Workstation-to-workstation SMB connections, access to administrative shares from unexpected sources, and a single host opening SMB sessions to many others in a short window are the lateral movement signatures. Large-scale file access or rename activity on a share is a ransomware indicator worth alerting on directly. Feed share access auditing and connection logs into your SIEM and write rules for the fan-out pattern, which is distinctive and rare in normal operation.

Exam angles

Know that SMB uses TCP 445 and that 137 to 139 are the legacy NetBIOS ports. Identify SMBv1 as deprecated and insecure with removal as the fix, SMBv2 as the performance rewrite, and SMBv3 as the version bringing encryption and secure negotiation. Recognize SMB signing as the mitigation for relay attacks, and blocking 445 at the perimeter as standard practice. When a scenario describes ransomware spreading between workstations, the control is segmentation plus signing plus removal of SMBv1.