SMB Vulnerabilities: From EternalBlue to Relay Attacks

The SMB vulnerabilities problem is not one old protocol bug. It is that teams patch EternalBlue and leave the relay conditions, legacy dialects, broad network reach, and excessive share rights that attackers use next.

Server Message Block carries file access, printer access, administration, software delivery, and parts of Windows identity operations. That makes it useful infrastructure. It also means an SMB weakness can become code execution, credential theft, data access, or a route to another machine. Those are different failure modes and they do not share one fix.

A practical program separates the problem before assigning work. Patch software flaws. Remove SMB1. Require message signing or Extended Protection for Authentication where relay is possible. Reduce NTLM. Limit port 445 between zones. Review who can read and change each share. Then verify the effective connection, not the intended policy.

What are SMB vulnerabilities?

SMB vulnerabilities include implementation flaws, unsafe protocol versions, weak authentication paths, unsigned sessions, exposed services, and permissions that grant more access than the workflow needs. A scanner may report some of these as CVEs. It will not reliably tell you that a finance share accepts writes from a broad user group or that an old appliance prevents signing enforcement.

Put each finding into one of four classes. A software defect needs an update and version proof. A legacy dialect needs removal or isolation. A relay condition needs authentication binding through signing, EPA, or enforced encryption. An authorization problem needs network and share scope changes. Calling every item an "SMB flaw" hides the owner and slows the repair.

SMB usually appears inside a larger lateral movement path. The source may be a user workstation. The identity may come from NTLM. The target may be a server that accepts the session. The share or remote service determines what the identity can do next. Defenders need all four facts.

Why does EternalBlue still matter?

EternalBlue exploited a remote code execution flaw in the SMB1 server, addressed by Microsoft bulletin MS17-010 in March 2017. It became famous because WannaCry and NotPetya turned reachable, unpatched systems into rapid propagation paths. The lesson is not that SMB is permanently broken. The lesson is that a network service with broad reach converts one software defect into fleet impact.

Patching stops the named defect. Disabling SMB1 removes an obsolete protocol from future attack paths. Network segmentation limits which sources can test the service at all. You want all three outcomes, but they are not interchangeable. A patched SMB1 server still carries avoidable legacy code. A segmented but unpatched server can still be reached from its allowed peers.

The same reasoning applies to SMBGhost and current Samba or Windows flaws. Start with affected product and version, confirm service reachability, identify the business dependency, apply the vendor fix, and retest. Our vulnerability reachability guide shows why a CVE match and a usable path are separate facts.

How does an SMB relay attack differ from a CVE?

An SMB relay attack abuses an authentication exchange rather than cracking the user's password first. The attacker causes or captures an NTLM authentication attempt and presents that attempt to another service that accepts it. If the target does not require the session to be bound through SMB signing, EPA, or another suitable control, the attacker may act with the relayed identity's rights.

The key distinction is operational. A relayable target may be fully patched. The weakness sits in the relationship between accepted authentication, protocol protection, target configuration, and identity rights. That is why another monthly update does not automatically close the route.

Name resolution poisoning and coerced authentication can supply attempts. NTLM supplies the challenge and response path. A target without required signing or EPA supplies the destination. Excessive rights supply the impact. Remove any required edge and the route breaks. The pass the hash guide covers a related but different case where an attacker replays a stolen NT hash rather than relaying a live exchange.

What changed for SMB security in 2025 and 2026?

Microsoft added a safer migration path on September 9, 2025. Windows updates released on and after that date added audit support for client compatibility with SMB server signing and EPA. The Microsoft SMB server hardening advisory lists event 3021 for an SMB2 or SMB3 client that does not support signing and event 3024 when a client does not send the service principal name needed for EPA. This closes a gap older hardening guides skip: finding broken dependencies before enforcement.

The threat side moved too. CISA added CVE-2025-33073 to its Known Exploited Vulnerabilities Catalog on October 20, 2025. The Windows SMB client flaw can be used to coerce a machine to authenticate to an attacker controlled system. Treat the CISA KEV entry for CVE-2025-33073 as a reminder that outbound SMB matters. Blocking internet inbound traffic on 445 is necessary, but it does not stop a client from making an unsafe outbound connection.

SMB risk is not Windows only. On July 28, 2026, Canonical published Ubuntu security notice USN-8621-1 for Samba updates across Ubuntu 22.04, 24.04, and 26.04 LTS. The notice includes remote denial of service paths in TSIG and kpasswd processing plus a local ownership problem. File sharing inventories must include Samba and appliances, not only Windows servers visible in Active Directory.

Which modern SMB defaults help?

Windows 11 24H2 and Windows Server 2025 changed the starting point. Microsoft's SMB security hardening documentation says Windows 11 24H2 requires inbound and outbound SMB signing by default, while Windows Server 2025 requires outbound signing by default. It also documents dialect controls, audit improvements, SMB over QUIC, and removal of old NetBIOS ports from built in firewall rules.

The same documentation describes an authentication rate limiter with a two second delay after each failed NTLM or Local KDC Kerberos attempt. That changes the economics of brute force against a modern server. It does not remove valid credential abuse, relay to an unsafe target, or weak share permissions.

Defaults apply to specific versions and roles. Mixed fleets keep older behavior for years. Assume nothing. Read effective state on clients and servers, observe actual dialects and signing, and inventory exceptions before calling the environment protected.

Which SMB hardening controls matter most?

Remove SMB1 unless a documented dependency still requires it. An exception should name the asset, workflow, owner, allowed peers, migration plan, and expiry date. Put the exception in a segment that cannot reach user networks or critical servers. "The scanner still needs it" is not a control.

Require SMB signing on clients and servers after an audit period. Signing protects integrity and prevents common relay paths because the attacker cannot produce the target session signature. Where supported, use EPA to bind authentication to the intended service. Enforced SMB encryption also protects the session and can block relay in configurations Microsoft documents, but encryption has compatibility and processing costs to test.

Reduce NTLM with a staged plan. Inventory where it is used, fix names and service principal names that cause Kerberos fallback, move services to supported authentication, then block narrower scopes before wider ones. Breaking NTLM everywhere on Friday and restoring it domain wide on Monday is not progress.

Restrict port 445 by source, target, and business service. User workstations rarely need SMB access to every server. Server tiers rarely need SMB access back to every user subnet. Domain controller and management flows deserve explicit rules. Pair network scope with share and NTFS rights, then test both read and write behavior using representative identities.

How can operators audit SMB configuration safely?

Begin with read only checks on representative servers and clients. The first command shows server protocol, signing, encryption, and audit state. The second shows the matching client controls:

On supported Windows versions, enable compatibility auditing before enforcement. Review results long enough to capture month end jobs, backup windows, patch distribution, device scans, and infrequent vendor work:

Suppose 3,000 endpoints produce 120 unique compatibility failures. That is 4 percent of the fleet, but the useful unit is not 4 percent. It is 120 dependencies with owners. Group them by product and path. Ten device models may explain 90 failures, turning a broad exception into a short migration queue.

How should signing be enforced without breaking file access?

Start with a pilot group that represents modern Windows, older Windows, Linux Samba, storage appliances, printers, backup systems, and line of business applications. Fix failed name resolution and Kerberos paths. Ask vendors for supported configurations. Isolate anything that cannot comply.

Then require signing on a narrow server group. Microsoft's documented PowerShell syntax is:

Treat that as a change, not a blog command to paste across production. Define expected event volume, application tests, rollback authority, and a deadline for exceptions. Verify new connections negotiate the intended protection. Expand only after the service owner signs off on both security and function.

What should SMB detection and response include?

Watch for new SMB listeners, SMB1 use, signing compatibility warnings, unusual outbound 445 connections, access from user networks to server tiers, new administrative share activity, and a burst of writes across many hosts. Identity context matters. A deployment service writing to 200 approved targets during a change window is not the same as a user account doing it at 2 a.m.

Correlate SMB with name resolution changes, credential events, service creation, scheduled tasks, remote registry use, and endpoint process activity. Relay and remote execution are sequences. A port event alone is weak. A new source, relayed identity, administrative share, and service start on the target is a case an operator can act on.

During response, block the source and unsafe route, disable affected identities, isolate targets, and preserve relevant logs. Patch confirmed flaws. Rotate secrets that may have been exposed. Review every target the identity could reach, not only the host that fired the first alert. Use the lateral movement prevention framework to shrink that route before reopening service.

Frequently asked questions

Is SMB1 safe if the server is patched?

Patching removes known implementation flaws, but SMB1 remains an obsolete protocol with weak security design and unnecessary code. Remove it or isolate the documented dependency while it is replaced.

Does SMB signing stop EternalBlue?

No. EternalBlue is a software vulnerability addressed by updates and SMB1 removal. Signing protects message integrity and blocks common relay paths. Keep the control classes separate.

What is the difference between SMB signing and encryption?

Signing proves message integrity and binds messages to the authenticated session. Encryption also protects data from being read in transit. Encryption has stronger confidentiality benefits and more compatibility requirements.

Should port 445 be blocked everywhere?

Block it at the internet boundary and deny unnecessary paths internally. Approved file, identity, backup, and management workflows may need it, so allow only named sources and targets and verify the resulting access.

The executive takeaway

Ask the team for four SMB lists: unpatched implementations, SMB1 dependencies, targets that do not require signing or EPA, and network or share paths that reach farther than the business process. Assign each list to the right owner. Turn on compatibility auditing before enforcement. Remove public exposure now. Then prove which identity can reach which share and what it can change. That is how SMB becomes managed infrastructure instead of a permanent movement lane.