SMBv1 and Legacy Protocols: The 2017 Holes Still Open on Windows in 2026

WannaCry and NotPetya were 2017. SMBv1 — the protocol they rode — was deprecated by Microsoft that same year, and removed from fresh Windows installs not long after. Yet pull the configuration on a real estate of Windows machines in 2026 and you will still find SMBv1 features installed, NTLMv1 accepted, LM hashes stored, and TLS 1.0 negotiating happily with whatever asks. These are not exotic findings. They are the boring, decade-old defaults that survive because nobody ever went looking. A senior engineer's job is to go looking — and then to make sure they do not creep back.

Why legacy protocols outlive their obituaries

Old protocols persist for unglamorous reasons, and understanding them tells you where to hunt:

• In-place upgrades carry their baggage forward. A machine that started life on Windows 7 or Server 2012 and was upgraded keeps optional features and registry values that a clean install would never have set. The OS version looks modern; the attack surface is vintage.
• One device holds the whole network hostage. A single old NAS, a label printer, or a scanner that only speaks SMBv1 is often the excuse to leave the dialect enabled on the clients that talk to it — re-opening the door for everyone.
• Downgrade is the attacker's friend. Even when modern protocols are available, accepting the weak ones means an on-path attacker can force the negotiation down. NTLMv1 and LM hashes are trivially crackable or relayable; supporting them at all hands that capability to anyone who can coerce an authentication.

The risk is rarely the protocol you chose. It is the weak one you never explicitly turned off, quietly available for a downgrade you never see.

The four you should hunt first

1. SMBv1

SMBv1 is the headline. It should not be installed, let alone enabled. Check the optional feature and the server-side toggle, and confirm the protocol is actually disabled rather than merely unused:

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol

If it is present, remove it and turn it off explicitly. On a workstation with no legacy dependency this is a one-line fix that closes an entire historical class of worms:

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

2. NTLMv1 and LM authentication

The LmCompatibilityLevel value controls which authentication protocols a machine will send and accept. You want level 5 — send NTLMv2 only, and refuse LM and NTLMv1 outright. Anything lower leaves a downgrade path open:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevel
# Harden: NTLMv2 only, refuse LM & NTLMv1
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevel -Value 5

3. Stored LM hashes

LM hashes are a cryptographic relic — case-insensitive, split into two seven-character halves, crackable in seconds. Windows should never store them. Verify NoLMHash is enforced so no new ones are written:

Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name NoLMHash -Value 1

4. TLS 1.0 / 1.1 (and SSL 3.0)

SMB is the famous one, but the same "weak option left enabled" pattern lives in the SChannel stack. TLS 1.0, TLS 1.1, and SSL 3.0 are deprecated and should be disabled for both client and server roles under the SChannel Protocols key, leaving TLS 1.2 and 1.3 as the only acceptable choices. As with SMB, the goal is not just to prefer the strong protocol but to make the weak one impossible to negotiate.

Turning it off is easy. Keeping it off is the job.

Every control above is a few lines on a single box. The hard part is the same one that defeats most hardening: drift. A future in-place upgrade re-adds an optional feature. Someone re-enables SMBv1 for an afternoon to talk to that one old scanner and forgets. A new machine images from a stale gold template. Hardening you set once and never re-check has a half-life, and a single regressed host is all a relay or a worm needs.

On the machine in front of you, you do not need a subscription to stay honest. WinSentinel is free and runs at full power on a single machine — every module, no limits — so one command tells you whether SMBv1 is present, what LmCompatibilityLevel is set to, whether LM hashes can be stored, and which TLS versions SChannel will still negotiate, then folds those findings into your overall posture score:

winsentinel audit
winsentinel score

Re-run it after any change and the score moves the instant you regress — the audit is a fact you can check every day, not a memory of a Tuesday you hardened the box.

When one machine becomes a fleet

Across an organization, manually re-checking these registry values on 50 or 100 endpoints is precisely where good intentions die, and legacy protocols are the textbook case of a setting that silently comes back after an upgrade. That continuous, centralized assurance is what WinSentinel Pro is for: lightweight agents report each machine's posture to a central node, so a host that re-installs the SMBv1 feature or drops back to an unsafe LmCompatibilityLevel surfaces as a drift alert instead of an incident. Pro rolls the same per-machine findings into fleet-wide compliance evidence — the depth of each machine's audit is identical to the free single-machine scan; Pro adds the orchestration, history, and alerting you need to trust dozens of machines at once.

The takeaway

The protocols that powered 2017's worst Windows worms are not theoretical history — on many estates they are still installed, still accepted, still one coerced authentication or one downgrade away from mattering. Hunt the four: remove SMBv1, force NTLMv2-only, forbid LM hashes, and retire TLS 1.0/1.1. Then make the check continuous — free on the machine in front of you, fleet-wide with Pro when one machine becomes many. The holes are easy to close. The discipline is in verifying, every day, that they stayed closed.